Subject: Re: [core] yang cbor comments

From: peter van der Stok <[email-masked]>
Date: Thu, 01 Dec 2016 09:50:18 +0100

Hi Michel,

Glad that you saw my point.
your text should be OK. thanks.

I still need to understand the text on anydata and anyxml

Peter

Michel Veillette schreef op 2016-11-30 22:59:
> Hi Peter
> 
> === About " My proposal: The following example shows the encoding of
> the value "eth1" assigned to the leaf 'interface-state-ref'."
> 
> All examples have been fixed with the following scheme:
>    The following example shows the encoding of an
> 'interface-state-ref' leaf instance set to "eth1".
> See diff at
> 
> https://github.com/core-wg/yang-cbor/commit/6f514542d5d09ec5c992e095dd609c68303cdb89#diff-083fd5e71ffd63b12d8cd2854c3ad1bf
> 
> Your proposed solution works fine for this specific example but was
> hard to apply to all examples.
> I'm also not sure about the use of "assigned" which seem to imply a
> previous PUT or POST.
> I'm open the revisit this wording if needed.
> 
> === About the into of section 5, I proposing the following text based
> on the intro present in https://tools.ietf.org/html/rfc7951#section-6
> 
> The CBOR encoding of an instance of a leaf or leaf-list data node
> depends on the built-in type of that data node. The following
> sub-section defined the CBOR encoding of each built-in type supported
> by YANG as listed in [RFC7950] section 4.2.4. Each subsection shows an
> example value assigned to a data node instance of the discussed
> built-in type.
> 
> The update draft is available at
> http://core-wg.github.io/yang-cbor/draft-ietf-core-yang-cbor-latest.txt
> 
> Regards,
> Michel
> 
> -----Original Message-----
> From: peter van der Stok [mailto:[email-masked]]
> Sent: Wednesday, November 30, 2016 3:29 AM
> To: Michel Veillette <[email-masked]>
> Cc: [email-masked]; Core <[email-masked]>
> Subject: RE: [core] yang cbor comments
> 
> Hi Michel,
> 
> Apologies for the late reaction, but I was occupied by other things,
> and almost forgot.
> 
> Let me give one example from section 5.9
> 
> The text says: The following example shows the encoding of leaf
> 'interface-state-
>     ref' set to the value "eth1".
> 
> However it is NOT the encoding of the leaf, but the encoding of the
> value of the leaf. (that's where my confusion comes from, sorry to
> seem to be nit-picking)
> 
> My proposal:
> 
> The following example shows the encoding of the value "eth1" assigned
> to the leaf 'interface-state-ref'.
> 
> I hope I made my point clearer.
> 
> You may start the sections 5, before section 5.1, with the following
> text:
> In the folowing examples values of the discussed type are assigned to
> an example leaf of the discussed type.
> Consectively, the CBOR encoding of the value is shown.
> (Or similar but much better text.)
>> 
> 
>>> ====> Examples of section 5. Do the examples not need an identifier
>>> (CBOR key)? We now are faced with values which do not belong 
>>> anywhere.
>>> Also the SID value needs to be specified. For example section 5.1 can
>>> be written as follows:
>>> The leaf mtu is assumed to have value 1280 The sid of mtu is 1350 The
>>> CBOR diagnostic notation of the pair is 1350: 1280, which results in
>>> Page 15 /signed integer/negative integer/
>>> 
>>> Same answer as above.
>>> None of the YANG Data Node Instances defined in section 4 (leaf,
>>> container, leaf-list, list, anydata, anyxml) is encoded with its
>>> identifier.
>>> Such identifiers are part of the instance-identifier carry in the
>>> request URI or within the payload.
>>> This is the job of CoMI
>>> 
>>>  ====>Section 5.10.1; it is unclear where the value 1180 comes from.
>> 
>> I seem to express myself badly.
>> It is only needed to say that mtu is assumed to have value 1280  and
>> that the CBOR encoding of 1280 is:
>> 
>> At this moment the scope of the example CBOR code is unclear.
>> 
>> [MV] in section 5.1, the example is introduced with the sentence:
>> [MV] "The following example shows the encoding of leaf 'mtu' set to
>> 1280 bytes."
>> [MV] Is it the part that is unclear?
>> [MV] Can you propose an updated text to clarify this example?
>> 
>>> ====> Section 5.13 is very unclear. There are many examples but it is
>>> not clear where all these values come from; what is the SID value,
>>> what was the leaf instance value, is one large puzzle. One example
>>> (instead of 3), but with more explanations would help. In my opinion
>>> the text in belongs in the FETCH content format document that still
>>> needs to be written.
>>> 
>>> The multiple examples have been requested by different peoples
>>> including Carsten.
>>> These examples show completely different use cases, single instance
>>> data node, list and list instance and are all useful.
>>> For the question, "what is the SID value", this will be resolved by
>>> the implementation of the registrars sharing a common database
>>> (blockchain) of .sid files.
>> 
>> please see my responses above.
>> Not the examples are questioned but an explanation is needed that says
>> that the CBOR code for the value is shown and not the whole leaf.
>> 
>> [MV] This topic is discussed in section
>> https://tools.ietf.org/html/draft-ietf-core-yang-cbor-03#section-3
>> [MV]
>> [MV]   "Basic schema nodes such as leaf, leaf-list, list, anydata and
>> anyxml can be encoded standalone.
>> [MV]    In this case, only the value of this schema node is encoded in
>> CBOR. Identification of this value needs
>> [MV]    to be provided by some external means when required.
>> [MV]    A collection such as container, list instance, notification,
>> RPC input, RPC output, action input and action
>> [MV]    output is serialized using a CBOR map in which each child
>> schema node is encoded using a key and a value."
>> [MV]
>> [MV] Can you propose an updated text to clarify this topic?
>>