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

Hi Michel,

> 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 /
>   }

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

> RES: 2.05 Content (Content-Format: application/yang-value+cbor)
>   {
>     +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 <Michel.Veillette@trilliant.com> wrote:
> 
> 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:cabo@tzi.org] 
> Sent: Monday, July 9, 2018 11:23 AM
> To: Michel Veillette <Michel.Veillette@trilliant.com>
> Cc: Robert Wilton <rwilton@cisco.com>; draft-ietf-core-yang-cbor@ietf.org; core@ietf.org
> Subject: Re: [core] Comments on draft-ietf-core-yang-cbor-06
> 
> 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 <Michel.Veillette@trilliant.com> wrote:
>> 
>> 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:rwilton@cisco.com] 
>> Sent: Monday, July 9, 2018 11:00 AM
>> To: draft-ietf-core-yang-cbor@ietf.org; core@ietf.org
>> Subject: Comments on draft-ietf-core-yang-cbor-06
>> 
>> 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
>> 
>> 
>> 
>> 
>> _______________________________________________
>> core mailing list
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core
> 
> 
> 