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