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

On 09/07/2018 16:39, Michel Veillette 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 /
>     }
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:

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

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

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