Re: [netmod] [core] 🔔 WG Last Call of CORECONF drafts: draft-ietf-core-yang-cbor-12, -sid-11, -comi-09, -yang-library-01 / -yang-cbor-12 review

[Ivaylo Petrov <[e-mail]>]

Hello Esko,

Thank you for your review and your comments! They truly help us improve
this document. Please find my answers below (prefixed with [IP]). Note that
the diff after handing your comments and those of Juergen Schoenwaelder can
be found at [1].

Best regards,
Ivaylo

[1]:
https://tools.ietf.org/rfcdiff?url1=draft-ietf-core-yang-cbor&url2=http://core-wg.github.io/yang-cbor/draft-ietf-core-yang-cbor-latest.txt
On Mon, Mar 30, 2020 at 2:24 PM Esko Dijk <[e-mail]>
wrote:

> Hello CoRE,
>
> I did a review of draft-ietf-core-yang-cbor-12 and some comments are
> below. I do support the publication of this document but feel a few updates
> of minor items are still needed! See the items below:
>
> Section 3: "This specification supports two type of CBOR keys" -> two
> types of CBOR keys
>

[IP]: Fixed

Section 3: This root CBOR map is provided only as a typical usage example
> and is
>    not part of the present encoding rules.  Only the value within this
> CBOR map is compulsory.
> -> Not fully clear to me, how can an example be compulsory? Other values
> within the CBOR map could also be used, right? Also it wasn't fully clear
> to me how the data structure would otherwise be encoded if not with a root
> CBOR map. Maybe good to give an example of how it would otherwise be
> encoded if not with a root CBOR map!
>

[IP]: This stems from the separation between CoMI and YANG to CBOR - in
CoMI we have complete examples with the complete encoding of elements that
were requested, whereas here we provide only instructions how particular
elements need to be encoded - regardless of the fact that they might be a
part of a bigger payload or part of a protocol that handles the external
wrapping. Where this causes issues is SID deltas for example - without the
wrapping elements, it would not be clear how that would work. Please let us
know if you could think of a better way to express this.


> Section 3.1: Table 1 uses both uppercase and lowercase in the last column
> for the CBOR encoding. Best practice is to use either uppercase or
> lowercase for hexadecimal, but not mixed I think.
>

[IP]: Fixed


> Section 4.5.2: "example-port: example-port-fault" :
> -> space after ':' is to be removed. At least I think a space isn't
> allowed there.
>

[IP]: Fixed


> Section 3.3 / 4.5.1 "as follow"
> -> as follows
>

[IP]: Fixed


> Section 4.6: "data items tagged with one of the tag listed"
> -> the tags listed
>

[IP]: Fixed

Section 4.6: the "anyxml bar" definition should have "# SID 60000" comment,
> like for the other YANG definitions that have a "# SID ....." comment .
>

[IP]: Fixed


> Section 5.1: "YANG template encoded using SIDs are carried in "
> -> YANG templates ...
>

[IP]: Changed request from Juergen Schoenwaelder made this look like:

The yang-data extensions encoded using SIDs are carried in a CBOR map
containing a single item pair. The key of this item is set to the SID
assigned to the YANG template container, the value is set the CBOR encoding
of this container as defined in {{container}}.



> Section 5.2 similar sentence as 5.1 above
>

[IP]: Fixed similarly to the above one.


> Section 6.6 example:
>   type union {
>      type int32;
>      type enumeration {
>        enum "unbounded";
>      }
>    }
>
> unclear why "unbounded" is within quotes? The CBOR encoding of this
> example encodes the word 'unbounded' without the quotes, which would look
> like:
>    type enumeration {
>        enum unbounded;
>      }
> An open question to me is whether RFC 7950 section 9.12.4 has the word
> unbounded in quotes on purpose, or by mistake. None of the other examples
> of enum statements use the quotes! Why would this example suddenly use the
> quotes? In any case if quotes are used then per RFC 7950 definitions the
> quotes must also be encoded as part of the yang-string.
>

[IP]: I believe that was copied indeed from RFC 7950 as it is. I could not
find a reason why it should be with quotes, so I removed them as you
suggested.


> Section 6.6: Tag 44 use - in section 8.1, the table states that the tag
> must mark a data item of type unsigned integer. Which is not the case here,
> it marks a string.
>

[IP]: It should be a "text string" in Section 8.1. This has changed
relatively recently and obviously we overlooked the values in the table.
Fixed now


> Section 6.7: similar to section 6.6, the tag 43 mentions data item "byte
> string" in Section 8.1 while in section 6.7 it is followed by a text string.
> Just to be clear: if a 'bits' type is encoded, it looks like the tag 43 is
> only used if followed by a text string as in 43("under-repair critical") ?
> Or should a tag 43 also be used in case a CBOR byte string follows?
> E.g. 43(h'06') instead of h'06' ? That doesn't seem to be the intention in
> the current text.
>

[IP]: It should be a "text string" in Section 8.1. Fixed now. My reading of
this is that the tag 43 can only be used inside unions.

Section 8.1: could indicate here what the column 'Data Item' means. E.g.
> make clear that the CBOR data item following the tag listed in the first
> column cell must be of one of the CBOR data types listed in the second
> column cell.
>

[IP]: This is the column title used in section 7.2 of RFC7049. If you
believe that the sentence right before the table is not clear enough,
please let us know how we could improve it.

Best regards
> Esko
>
>
> IoTconsultancy.nl  |  Email/Skype: [e-mail]
>
>
> -----Original Message-----
> From: core <[e-mail]> On Behalf Of Carsten Bormann
> Sent: Monday, March 9, 2020 14:05
> To: core <[e-mail]>
> Cc: [e-mail]
> Subject: [core] 🔔 WG Last Call of CORECONF drafts:
> draft-ietf-core-yang-cbor-12, -sid-11, -comi-09, -yang-library-01
>
> It took us a long time to get the four CORECONF drafts in sync,
> but now we are ready for WGLC.
>
> This starts a working group last call for
> — draft-ietf-core-yang-cbor-12
> — draft-ietf-core-sid-11
> — draft-ietf-core-comi-09
> — draft-ietf-core-yang-library-01
>
> ending on
>
>         24:00 UTC on Tuesday, March 31, 2020.
>
> (This includes some extra time for the IETF week and for cross-WG
> coordination.)
>
> This WGLC is copied to the netmod WG mailing list; please do have a look
> at these drafts as they are slated to become a part of the greater
> YANG/NETCONF/RESTCONF family.  We intend the discussion to be on the
> CoRE mailing list, but if you find a fundamental issue with YANG or
> RESTCONF, feel free to discuss that on netmod instead.
>
> Please start a new email thread for each major issue that will need
> discussion and make sure the subject line includes the draft name and
> some sort of name for the issue.  (Minor issues such as typos can also
> be sent to the authors.)
>
> If you read the draft and think it looks fine, please send a one line
> email to the list or to the chairs letting us know that so we can get
> a feel of how broad the review has been.
>
> (To reviewers and authors:)  If you are aware of any patent claims that
> might apply to systems that implement these drafts, please review BCP 78
> and BCP 79 and make any appropriate IPR declaration before the last-call
> ends. If you are not sure whether you need to make a declaration or not,
> please talk to the chairs and we will help.
>
> Grüße, Carsten
>
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core
>