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

On Mon, Jul 9, 2018 at 8:37 AM, Robert Wilton <
rwilton=40cisco.com@dmarc.ietf.org> wrote:

>
>
> On 09/07/2018 16:23, Carsten Bormann wrote:
>
>> 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.
>>
> 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.
>
>
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


>
>
>> Grüße, Carsten
>>
>>
>> On Jul 9, 2018, at 17:18, Michel Veillette <Michel.Veillette@trilliant.co
>>> m> 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
>>>
>> .
>>
>>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>