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

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

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!

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.

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.

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

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

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

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

Section 5.2 similar sentence as 5.1 above

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.

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.

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.

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.

Best regards
Esko

IoTconsultancy.nl  |  Email/Skype: esko.dijk@iotconsultancy.nl 

-----Original Message-----
From: core <core-bounces@ietf.org> On Behalf Of Carsten Bormann
Sent: Monday, March 9, 2020 14:05
To: core <core@ietf.org>
Cc: netmod@ietf.org
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
core@ietf.org
https://www.ietf.org/mailman/listinfo/core