Subject: [core] Comments on draft-ietf-core-yang-cbor-06

From: Robert Wilton <[email-masked]>
Date: Mon, 9 Jul 2018 16:00:28 +0100

Hi,

I've read this draft, and think that it is well written.

There is one area of the draft that is somewhat unclear to me when using 
SID encodings:  Is the root node(s) of a request or a response always an 
absolute SID value, or could it still be a delta?

In particular:

Sec 2.1 indicates that the translation to/from SID deltas is stateless, 
which implies to me that the root node(s) of a request/response would 
always be an absolute SID value.

Sec 4.2.1 gives an example using a absolute SID for the top node.  It 
then has this text: "

    On the other hand, if the serializer is aware of the parent SID, 1716
    in the case 'system-state' container, root data nodes are encoded
    using deltas.

"

I think that it is quite plausible that the serializer may know the SIDs 
for all nodes in the data tree, which the text implies it could then use 
a relative SID for the top node.  Particularly, if the top level node 
was explicit from the request.

Hence, I think that this draft could probably benefit in being more 
explicit on exactly when a top level node uses an absolute SID, and in 
what scenarios it may end up using a a relative SID. If this distinction 
is down to the protocol being used, then perhaps that could be stated?

One other nit:

Section 4.4.1 says "delta encoding can be performed", but I think that 
this should probably be "delta encoding MUST be performed".

Thanks,
Rob

---

From: Michel Veillette <[email-masked]>
Date: Mon, 9 Jul 2018 15:18:08 +0000

Hi Robert

Andy also asked for a clarification about the encoding of the root data node identifier (absolute vs. delta).
Section 4.4.1. have a sentence addressing this topic.
   It is important to note that the protocol or method
   using this mapping may carry a parent SID or may have the knowledge
   of this parent SID based on its context.  In these cases, delta
   encoding can be performed based on this parent SID which minimizes
   the size of the encoded data.

A similar sentence need to be added to section 4.2.1.
We also need to clarify that the protocol or method using this encoding must mandate which approach is implemented, the data serialized don’t carry this information.

Regards,
Michel

From: Robert Wilton [mailto:[email-masked]]
Sent: Monday, July 9, 2018 11:00 AM
To: [email-masked]; [email-masked]
Subject: Comments on draft-ietf-core-yang-cbor-06

Hi,

There is one area of the draft that is somewhat unclear to me when using SID encodings:  Is the root node(s) of a request or a response always an absolute SID value, or could it still be a delta?

In particular:

Sec 2.1 indicates that the translation to/from SID deltas is stateless, which implies to me that the root node(s) of a request/response would always be an absolute SID value.

Sec 4.2.1 gives an example using a absolute SID for the top node.  It then has this text: "

   using deltas.
"

I think that it is quite plausible that the serializer may know the SIDs for all nodes in the data tree, which the text implies it could then use a relative SID for the top node.  Particularly, if the top level node was explicit from the request.

Hence, I think that this draft could probably benefit in being more explicit on exactly when a top level node uses an absolute SID, and in what scenarios it may end up using a a relative SID.  If this distinction is down to the protocol being used, then perhaps that could be stated?

One other nit:

Section 4.4.1 says "delta encoding can be performed", but I think that this should probably be "delta encoding MUST be performed".
Thanks,
Rob

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 9 Jul 2018 17:23:06 +0200

It is much less confusing to always talk of deltas in the structure.

Just say that the context SID value (the one that the delta is computed from) is 0 at the root of a tree.

Grüße, Carsten

> On Jul 9, 2018, at 17:18, Michel Veillette <[email-masked]> wrote:
> 
> Hi Robert
>  
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Robert Wilton <[email-masked]>
Date: Mon, 9 Jul 2018 16:37:09 +0100

> Just say that the context SID value (the one that the delta is computed from) is 0 at the root of a tree.
Yes, I completely agree.

I'm not convinced that it is worth optimizing for the case where the 
protocol knows the SID of the parent node, and hence deltas can be used 
for the top node.  Always using 0 as the parent of the root node just 
seems to facilitate simpler interop.  However, it is worth adding a 
caveat to my statement that I'm reviewing the encoding more from a 
RESTCONF protocol perspective rather than constrained devices so 
simplicity is more important me to saving a small number of bytes.

If saving those few extra bytes for delta SIDs over absolute SIDs for 
the top level SIDs is critical then I think that another solution would 
be to put an extra non-presence container in the data model.  Hence the 
NP-container uses a absolute SID and all children use deltas again. Of 
course, this depends on the data model being written in CBOR+SID 
friendly way.

Thanks,
Rob

> .

---

From: Michel Veillette <[email-masked]>
Date: Mon, 9 Jul 2018 15:39:35 +0000

Hi Carsten

CoMI for example, uses delta for the first root data node based on the requested SID.
In the following example, the +2 is relative to SID 1721 which is part of the requested URI (i.e. a5).
This requested SID need to be maintained in the client state in order to process the response.

https://tools.ietf.org/html/draft-ietf-core-comi-03#section-5.2.3.1

   REQ: GET example.com/c/a5

   RES: 2.05 Content (Content-Format: application/yang-value+cbor)
   {
     +2 : "2014-10-26T12:16:51Z",   / current-datetime SID 1723 /
     +1 : "2014-10-21T03:00:00Z"    / boot-datetime SID 1722 /
   }

Regards,
Michel

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: Monday, July 9, 2018 11:23 AM
To: Michel Veillette <[email-masked]>
Cc: Robert Wilton <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [core] Comments on draft-ietf-core-yang-cbor-06

Grüße, Carsten

---

From: Andy Bierman <[email-masked]>
Date: Mon, 9 Jul 2018 08:58:27 -0700

On Mon, Jul 9, 2018 at 8:37 AM, Robert Wilton <
rwilton=[email-masked]> wrote:

> protocol knows the SID of the parent node, and hence deltas can be used for
> the top node.  Always using 0 as the parent of the root node just seems to
> facilitate simpler interop.  However, it is worth adding a caveat to my
> statement that I'm reviewing the encoding more from a RESTCONF protocol
> perspective rather than constrained devices so simplicity is more important
> me to saving a small number of bytes.
>
> If saving those few extra bytes for delta SIDs over absolute SIDs for the
> top level SIDs is critical then I think that another solution would be to
> put an extra non-presence container in the data model.  Hence the
> course, this depends on the data model being written in CBOR+SID friendly
> way.
>
>
IMO it is a really bad idea to make the payload completely unusable unless
the top-node SID is
saved in some implementation-specific way.   Toolchains have a way of
growing over time,
so even if there is just 1 monolithic application now (so of course it can
remember the SID),
that may not be the case in the future.

Thanks,
> Rob
Andy

>>>   Andy also asked for a clarification about the encoding of the root
>>> data node identifier (absolute vs. delta).
>>> We also need to clarify that the protocol or method using this encoding
>>> must mandate which approach is implemented, the data serialized don’t carry
>>> this information.
>>>   Regards,
>>> Michel
>>> for all nodes in the data tree, which the text implies it could then use a
>>> relative SID for the top node.  Particularly, if the top level node was
>>> explicit from the request.
>>>
>>> explicit on exactly when a top level node uses an absolute SID, and in what
>>> scenarios it may end up using a a relative SID.  If this distinction is
>>> down to the protocol being used, then perhaps that could be stated?
>>>
>>> One other nit:
>>>

---

From: Robert Wilton <[email-masked]>
Date: Mon, 9 Jul 2018 17:09:43 +0100

>       +1 : "2014-10-21T03:00:00Z"    / boot-datetime SID 1722 /
OK, so the JSON YANG encoding mitigates the equivalent issue by always 
including the name of the element being returned.

E.g. presumably something like this:

    a5 : {

But I presume that you have already considered this previously and have 
rejected it for compactness reasons.

I'm not sure that I'm a big fan of the ambiguity as to whether the top 
level nodes are using absolute or delta sids.  Another choice would be 
to define a CBOR tag that explicitly reports the parent SID, although 
that seems more convoluted that just always including the name ...

Thanks,
Rob

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 9 Jul 2018 18:17:16 +0200

Hi Michel,

>     +1 : "2014-10-21T03:00:00Z"    / boot-datetime SID 1722 /

I actually didn’t want to exclude this example (just wanted to make sure all those places in the tree are deltas), but the comments from Robert and Andy make me think again.

The idea of depending on the request path for decoding the response is akin to all the issues we have with base URIs and charsets in HTML files saved from the browser.

Turning this into

>     +1723 : “2014-10-26T12:16:51Z”,   / current-datetime SID 1723 /
>     +1722 : “2014-10-21T03:00:00Z"    / boot-datetime SID 1722 /
>   }

by not using the context makes little difference in this specific example, but if the data items are not the heavyweight strings from this example but some numbers, it can make a difference.

If we had a way to put the context SID into the response, we would still waste a few bytes for that, but at least not for every single map key below that.

An alternative would be to keep it as is for the exchange but nail down a format for *saved* yang-cbor that includes the context SID.  Tools would then know to never save a naked body but instead wrap it into something like:

[“application/yang-value+cbor”,   
 1721,
 { +2 :…

I put in the media type there (we probably would really use the content-format number) as well to make it easier to understand stored yang-cbor.  (We could also spend a number of tags for the media types as in RFC 8152; long ones to turn them into a magic number as we did with 55799 in RFC 7049.)

Grüße, Carsten

> On Jul 9, 2018, at 17:39, Michel Veillette <[email-masked]> wrote:
> 
> Hi Carsten
>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 9 Jul 2018 18:20:22 +0200

On Jul 9, 2018, at 18:09, Robert Wilton <[email-masked]> wrote:
> 
> ambiguity as to whether the top level nodes are using absolute or delta sids

We don’t need to be able to include “absolute SIDs”(1) into the delta positions in the encoding.
The deltas are always deltas.  They just happen to be relative to a context SID at the top of the tree; mostly, that is 0 (but that’s what we are also discussing here).

Grüße, Carsten

(1) there is no need for this term; SIDs are SIDs and SID deltas are SID deltas.  The map key positions in YANG-CBOR are always SID deltas.

---

From: Robert Wilton <[email-masked]>
Date: Mon, 9 Jul 2018 17:39:05 +0100

> The deltas are always deltas.  They just happen to be relative to a context SID at the top of the tree; mostly, that is 0 (but that’s what we are also discussing here).
Apologies if my terminology was confusing.

I agree, that we are discussing whether the parent of the top level 
nodes should always have a SID of 0, or otherwise if it should be 
explicitly specified.

For me, one of the big advantages of CBOR over schema based encodings 
like protobuf, is that the structure of the encoded data is self 
describing.  I think that it is worth spending a few extra bytes in the 
encoding to get this property.  So, if I get a bad CBOR message that I 
can't interpret then I can easily convert it into a human readable 
structure to debug the problem (or know the CBOR itself is 
invalid/corrupt).  I see that requiring external knowledge for the 
parent SID of the top level nodes seems to take a step away from that.

E.g. if the device accidentally gives a response for the wrong node in 
the tree, and if the response relies on the SID in the request to be 
fully decodeable then the response will somewhat look like garbage and 
it will be harder to debug.  Is this worth saving a couple of bytes for?

Thanks,
Rob

---

From: Andy Bierman <[email-masked]>
Date: Mon, 9 Jul 2018 10:04:01 -0700

On Mon, Jul 9, 2018 at 9:39 AM, Robert Wilton <
rwilton=[email-masked]> wrote:

>> The deltas are always deltas.  They just happen to be relative to a
>> context SID at the top of the tree; mostly, that is 0 (but that’s what we
>> are also discussing here).
>>
> I agree, that we are discussing whether the parent of the top level nodes
> should always have a SID of 0, or otherwise if it should be explicitly
> specified.
>
> For me, one of the big advantages of CBOR over schema based encodings like
> protobuf, is that the structure of the encoded data is self describing.  I
> think that it is worth spending a few extra bytes in the encoding to get
> this property.  So, if I get a bad CBOR message that I can't interpret then
> I can easily convert it into a human readable structure to debug the
> problem (or know the CBOR itself is invalid/corrupt).  I see that requiring
> external knowledge for the parent SID of the top level nodes seems to take
> a step away from that.
>
>
I was thinking the same thing.
Do you really want to deploy a protocol that is near impossible to debug
with wireshark?

> E.g. if the device accidentally gives a response for the wrong node in the
> tree, and if the response relies on the SID in the request to be fully
> decodeable then the response will somewhat look like garbage and it will be
> harder to debug.  Is this worth saving a couple of bytes for?
>
>
Decoding SIDs incorrectly can crash the device or set the wrong object so I
would
say that correctness in NM is important no matter how many bytes it takes.

Andy

>
>
>
>> Grüße, Carsten
>>
>> (1) there is no need for this term; SIDs are SIDs and SID deltas are SID
>> deltas.  The map key positions in YANG-CBOR are always SID deltas.
>>
>>
>> .
>>
>>