Encoding of Data Modeled with YANG in the Concise Binary Object Representation (CBOR)
draft-ietf-core-yang-cbor-20

Document Writeup for Working Group Documents

This is the write for the CORECONF document draft-ietf-core-yang-cbor-16 released on 2021-06-25.

> (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

The document is intended for standards-track (Proposed Standard).

The set of documents composed by the present one, draft-ietf-core-sid, draft-ietf-core-comi and draft-ietf-core-yang-library provides the CORECONF
specification.

At the same time, the pair composed of the present document and draft-ietf-core-sid can also be used individually as interoperability protocols outside of that shared context.

> (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

* Technical Summary:

The present document and draft-ietf-core-sid together provide the foundation to extend YANG-based management down to constrained devices (RFC 7228).

In particular, the present document defines encoding rules for serializing YANG using the Concise Binary Object Representation (CBOR) [RFC8949], specifically configuration data, state data, RPC input and RPC output, action input, action output, notifications and yang-data extension defined within YANG modules.

The companion document draft-ietf-core-sid defines YANG Schema Item iDentifiers (YANG SID) and a file format used to persist and publish assigned YANG SIDs.

The two other documents draft-ietf-core-comi and draft-ietf-core-yang-library apply the two documents above, by using the CoAP protocol (RFC 7252) for access and providing information to be used in conjunction with CoRE resource discovery (RFC 6690).

* Working Group Summary:

The suite of documents spans specific areas of interest of several WGs, in particular NETMOD, CBOR, and CORE, as well as NETCONF. This required coordination between authors and reviewers that see different of these WGs as their central point of activity. While the documents were stable already for a while, a specific issue on representing YANG unions required somewhat unsavory resolutions, which held up the process considerably.

* Document Quality:

Since the document became a WG document in April 2016, several reviews were provided by members of the concerned WGs.

Of particular interest is the review by Jürgen Schönwälder :

Jürgen as well as Andy Bierman were very helpful in resolving remaining issues about this document as well. Andy is also is a co-author of the draft-ietf-core-comi specification using the present document and the companion document draft-ietf-core-sid.

Version -16 addressed Last-Call review comments received from Yangdoctors and Genart.

A review was requested on the media-types. No objections were raised.


* Personnel:

Document Shepherd: Marco Tiloca
Area Director: Francesca Palombini

Carsten Bormann served as Document Shepherd up until version -15 included, thus taking care of most of the shepherding process and especially providing the original version of this writeup.


> (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The original document shepherd actively followed the creation of this document and provided a shepherd review that included nits fixed in the most recent versions. The original document shepherd believes this document is ready for publication.

The current document shepherd has further reviewed the document, has no concerns and concurs with the judgdment of the original document shepherd.

> (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

> (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

The netconf/netmod perspective was mainly addressed in physical side meetings at IETFs and in personal reviews. Briefly, there was traffic on the mailing list yot@ietf.org, as well, approximately 100 messages by some 12 individuals.

> (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

(N/A)

> (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

All authors have confirmed that they do not have any direct, personal knowledge of any patent claim ("IPR") related to each of the drafts where they are listed as author.

> (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

As of 2021-06-21, no.

> (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Many members of the WG do not see YANG as a primary management interface for their work on constrained devices. There has been little opposition against pursuing this as an additional approach though. Between the individuals who want to make use of YANG for constrained devices, there is strong consensus.

> (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

> (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

ID nits found during the shepherd review were addressed in the most recent versions.

> (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

We are waiting for feedback on the request for media-type review (see above).

> (13) Have all references within this document been identified as either normative or informative?

Yes.

> (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

This document has normative references to RFCs only. Also, it has informative references to the other CORECONF documents draft-ietf-core-comi and draft-ietf-core-sid.

> (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

> (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

> (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

This document has a relatively plain IANA considerations section, only adding items to existing registries.

> (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

(N/A)

> (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

This document contains a single line of ABNF using a production from RFC 7950, which validates with "bap". It also contains many snippets of YANG that have been eyeball-verified only.

> (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

(N/A)

[Ballot comment]
Thanks for addressing my previous Discuss points!
With respect to my previous point (1) (relating to the handling of the
'bits' type if there are trailing bytes with no bits set), it now looks
like a recipient should be able to handle such things using the normal
rules without any issue, and given that, rejecting them doesn't make
much sense.  Do we want to say anything about how no special handling
on the recipient is needed in order to do the right thing if such zero
bytes are generated in violation of the requirement?

One new nit in the -17, in Section 7:

  This media-type represents a CBOR YANG document containing one or
  multiple data node values.  If the media-type parameter id is
  present, depending its value, each data node is identified by its
  associated namespace qualified name as defined in Section 3.3
  (id=name), by its associated YANG SID (represented as a SID delta or
  via tag 47) as defined in Section 3.2 (id=sid).  If no id parameter
  is given, both forms may be present.

This used to be a three-item list, but the last item is now a standalone
sentence.  That means that we need to replace the comma with the conjunction
"or".

The remainder of this comment section was generated by taking my comments
from the -16 and attempting to remove those that no longer apply.
It is possible I missed a change and erroneously left in some comments
that no longer apply.

I can see why it would not make sense to do so in this document that is
so tightly integrated with CORECONF, but is there any work to produce a
CBOR encoding for the "structure" extension from RFC 8791?

As a general note, I did not look particularly carefully at the example
CBOR encodings, on the assumption that they were automatically generated
as part of the document production process.

Section 4.2

  This specification supports two types of CBOR keys; SID as defined in
  Section 3.2 and names as defined in Section 3.3.

I suggest making an explicit statement about whether the two types of
keys can be comingled in the same container/etc, possibly just by
forward-reference to the media-type parameter.

Section 4.2.2

  [...] A namespace-qualified name
  MUST be used each time the namespace of a schema node and its parent
  differ.  In all other cases, the simple form of the name MUST be
  used.  [...]

We have a similar statement in §3.3 that is only "the simple form of the
name SHOULD be used" for the latter sentence.  It's not entirely clear
to me what causes the strength of requirement to be different between
the two cases.

Section 4.6

Do we want to explicitly acknowledge the mismatch between the "xml" in
"anyxml" and the actual CBOR contents?

Section 5.2

  The yang-data extensions encoded using names are carried in a CBOR
  map containing a single item pair.  The key of this item is set to
  the namespace qualified name of the yang-data extension container;
  the value is set to the CBOR encoding of this container as defined in
  Section 3.3.

I'm not sure if this is a nit or not, so putting it here: is §3.3 the
right reference for the encoding of the container (vs. §4.2)?

Section 6.6

Requiring the string form for enumeration constants in a union seems
like a big loss on encoded size.  Is it worth putting some discussion in
the document (or an appendix thereto) about why other options like
tagged integer are not usable?  (Similar discussion might be relevant
for the bits-in-union case.)

While it's banal, we might also put an example of the integer-encoded
form (as used by non-union contexts) so that the tagged-text-string
example isn't the only one given.

  Leafs of type enumeration MUST be encoded using a CBOR unsigned
  integer (major type 0) or CBOR negative integer (major type 1),
  depending on the actual value.  [...]

I think we should also mention the tagged-text-string case here.

Section 6.7

  In a number of cases the array would only need to have one element -
  a byte string with a small number of bytes inside.  For this case, it
  is expected to omit the array element and have only the byte array
  that would have been inside.  [...]

I think it is actually required (not just "expected") based on some
later text.

Section 6.10, 6.13

I strongly encourage explicit mention of the use of a CBOR tag when
these elements appear inside a union, analogous to the text in §6.6 and
6.7.  The list in §6.12 is pretty easy to miss, and the word "tag" does
not appear at all in these sections.

Section 7

  This specification defines the media-type "application/yang-
  data+cbor", which can be used without parameters or with the
  parameter "id=name" or "id=sid".

I think the media-type discussions should refer to the "id" parameter
and the two possible values for that parameter ('=' is not allowed in a
parameter name).
[ed. I was thinking something like "with the 'id' parameter set to
either 'name' or 'sid'" in this paragraph.  The subsequent paragraphs
look to be treated well in the -17; thanks!]

  This media-type represents a CBOR YANG document containing one or
  multiple data node values.  Depending on the presence and value of
  the media-type parameter "id", each data node is identified by its
  associated namespace qualified name as defined in Section 3.3
  ("id=name"), by its associated YANG SID (represented as a SID delta
  or via tag 47) as defined in Section 3.2 ("id=sid"), or either of
  these (no "id" parameter given).

I think that for identityref and instance-identifier we don't use the
tag 47 for absolute (non-delta) SIDs, at least outside of a union
context.

Section 8

It might be worth mentioning that when the 'id' parameter to the media
type is used, it's important to properly reject identifiers of the other
type, to avoid scenarios where different implementations interpret a
given content in different ways.

Section 10.1

It's not clear to me that RFC 6241 needs to be classified as normative,
at least based on the one place in the text where we reference it.


NITS

Section 2

  *  child: A schema node defined as a child node of a container, a
      list, a case, a notification, an RPC input, an RPC output, an
      action input, or an action output.

Is this enumeration of "parent" node types guaranteed to be fixed for
all time, or should we consider a more generic wording to describe it?
(Likewise for the "parent" definition.)

Section 4

The example from RFC 7317 may have truncated a little too much of the
content; "mandatory true" for choice transport, the "inet:" prefix for
"type inet:host" and "inet:port-number", etc.

Section 4.5

  *  CBOR map keys of any inner schema nodes MUST be set to valid
      deltas or names.

  *  The CBOR array MUST contain either unique scalar values (as a
      leaf-list, see Section 4.3), or maps (as a list, see Section 4.4).

I think a parallel list structure would be "CBOR arrays MUST contain
[...]".

  *  CBOR map values MUST follow the encoding rules of one of the
      datatypes listed in Section 4.

(A recursive reference, though I mostly trust the reader to pick out the
relevant subsections.)

[Ballot discuss]
Thanks for this document, it is good work, and I think that there specification is almost there, but that the text could be tightened up in a few places.

1. The document should be clearer on its use of terminology around schema nodes.  Mostly the encoding related to YANG data nodes, not YANG schema nodes.  I've provided more information in the comments section.

2. As also raised by Ben, this document should probably cover the YANG data structure extension in RFC 8791.  This could potentially be done in addition to rc:yang-data, but perhaps better in its place.

3. Did the WG consider supporting encoding YANG metadata (RFC 7952)?  Presumably this would be expected to be covered as future work?

4. How does the CBOR encoding of SIDs apply to YANG features?  This draft references features and the SID draft allows SIDs for them, but I don't understand how they are used in the encoding (since features don't appear in the instance data, they are only at the schema level).

5. I also support Ben's second discuss point.  I think that as written, this draft needs a normative reference to the SID draft.

[Ballot comment]
1. Abstract:
This document defines encoding rules for serializing configuration
  data, state data, RPC input and RPC output, action input, action
  output, notifications and the yang-data extension defined within YANG
  modules using the Concise Binary Object Representation (CBOR, RFC
  8949).
 
When I read the abstract, it raises the question about what is left out.  Hence, I am wondering whether it wouldn't be better to just describe it as encoding
YANG data tree instance data.  However, I see that the description effectively mirrors the abstract for the YANG JSON encoding (RFC 7951), so it is at least
consistent.


2. I find this document (along with the SID draft), somewhat confusing in that it references YANG schema nodes, but in most cases, it probably
only cares about the subset of YAND schema nodes that represent itemsthat are present in data tree instantiation.  RFC 7950 calls such 'schema nodes' as 'data nodes'.  For example, 'choice', 'case', 'input' and 'output' exist as nodes in the YANG schema tree, but are not data nodes and don't appear as instantiated data nodes.

Where this causes problems are in the definitions of: 'child' - (e.g., 'case' cannot be a child of a 'container' only a child of a 'choice', and equivalently for the definition of 'parent'.  This definitions are not heavily used and could perhaps be removed?

Hence my suggestion to clarify the text are:
- potentially import and use data node rather than schema node.  Note that data node, as defined in RFC 7950, is a subset of schema nodes, so you still need the text saying an instance of a data node.  Arguably, the RFC 7950 definition of a data node is somewhat confusing.
- please check everywhere where 'schema node' or 'data node' turns up in the text to ensure that you are referencing instances of that schema node rather than the schema node itself.  E.g., the second paragraph in section 3 states 'where each child schema node is encoded ...', but this should be an instance of child schema node.
- ensure that if you are referring to the parent or child of a 'schema node' that the logic skip out the schema nodes that don't get encoded in the data tree.  E.g., when calculating SIDs.


3. I think that some of the references to submodules are not quite right.  Basically, the CBOR encoding should not need to concern itself about submodules at all, since logically, it works with the module schema (which logically incorporates the submodules).  E.g., perhaps you could mention this in the introduction, referencing section 4.2.1 (4th paragraph in particular) of RFC 7950?

Hence:
In section 2:
  *  item: A schema node, an identity, a module, a submodule, or a
      feature defined using the YANG modeling language.

I think that this should exclude submodule (and possibly feature as well).

In section 3.2:
  YANG modules, submodules, and features

I don't think that you want submodules in this list (and perhaps not features either).

And in:
6.13.1.  SIDs as instance-identifier

  SIDs uniquely identify a schema node.  In the case of a single
  instance schema node, i.e., a schema node defined at the root of a
  YANG module or submodule or schema nodes defined within a container,
  the SID is sufficient to identify this instance.

I would remove "or submodule" from this text.  Effectively, the text about
modules already covers this.


4. Please check the text that describes how lists are encoded.  Section 4.2 seems to suggest that they are encoded as a CBOR Map, section 4.4 states that they are encoded as an array.  I presume that the answer is that they encode the list is an array, and each list entry is a Map.


5.
  Values of 'bits' types defined in a 'union' type MUST be encoded
  using a CBOR text string data item (major type 3) and MUST contain a
  space-separated sequence of names of 'bits' that are set
 
It might be helpful to have a quick sentence to justify why this is done.

Regards,
Rob

[Ballot comment]
I support Benjamin's second DISCUSS point.

Section 2 imports the term "schema tree" which is not used in this document.

In Section 9.1, "Required Parameters" should be "N/A", not "none".  See RFC 6838 Section 5.6.

The layout of the table in Section 9.3 is a little confusing.  For instance, the first two rows are collectively describing a single entry, I think, but that's not obvious given there are horizontal lines between them.

[Ballot comment]
Thank you for the work put into this document.

Special thanks to Marco Tiloca for his shepherd's write-up, which contains a good summary of the WG consensus and the doc reviews.

Please find below 2 non-blocking COMMENT points.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

A generic comment about the operational issue of supporting TWO ways to encode a data node: either normal string or the SID. This means that either there is a 2-way negotiation mechanism or that all CORE nodes must support both encoding and have agreed on a common SID mappings. Section 7 only briefly touches this issue with "Content-Type" but not with "Accept".

-- Section 4.2.1 & 4.4.1 --
BTW, I like the idea of encoding a container with sequential SID and the delta CBOR encoding ;-)

[Ballot comment]
[S4.6] [comment]

* If I'm understanding things correctly, it seems like the 'anyxml' name
  is straining the bounds of sensible naming -- in 7951 it seems to mean
  arbitrary JSON and here it seems to mean arbitrary CBOR.

  Oh well.

[Ballot discuss]
(1) The statement "Bytes with no bits set at the end of the byte string are
removed." in Section 6.7 seems confusing to the point of being
potentially harmful, and I'm not sure why it needs to be there.  In the
context it appears in, it seems to leave the value to be used for the
bit string offset in an ambiguous state.  If the intent is that such
strings should not be generated (and MAY/SHOULD/MUST be rejected by
recipients), that's okay, but having them silently ignored is very
surprising and may merit discussion.

(2) I think we should discuss the relationship between this document and
draft-ietf-core-sid, which are before the IESG at the same time.  This
document says that core-sid is "one example for" a specification
defining the management of SIDs, but draft-ietf-core-sid claims to be
the document that "defines the semantics, the registration, and
assignment processes of YANG SIDs".  I'm having a hard time seeing the
two statements as compatible with each other, but maybe I'm missing something.

(3) The second example of instance-identifier using SID (§6.13.1) seems
malformed, with "key name country" appearing under both "list user" and
"list authorized-key" and no "country" leaf within "list user" other
than the one under "list authorized-key".  (The actual identityref
example appears to correctly only use "name" as the key for "list
user" and not "list authorized-key".)

(4) Relatedly, the second example of instance-identifier by name (§6.13.2)
does not show a country for "authorized-key", and I'm not sure if that's
a valid way to represent the given YANG element.

[Ballot comment]
I can see why it would not make sense to do so in this document that is
so tightly integrated with CORECONF, but is there any work to produce a
CBOR encoding for the "structure" extension from RFC 8791?

As a general note, I did not look particularly carefully at the example
CBOR encodings, on the assumption that they were automatically generated
as part of the document production process.

Section 4.2

  This specification supports two types of CBOR keys; SID as defined in
  Section 3.2 and names as defined in Section 3.3.

I suggest making an explicit statement about whether the two types of
keys can be comingled in the same container/etc, possibly just by
forward-reference to the media-type parameter.

Section 4.2.1

  In the context of containers and other nodes from the data tree, CBOR
  map keys within inner CBOR maps can be encoded using deltas or SIDs.
  In the case of deltas, they MUST be encoded using a CBOR unsigned
  integer (major type 0) or CBOR negative integer (major type 1),
  depending on the actual delta value.  [...]

It's a little surprising that we only get this extended discussion on
SID use in §4.2.1, when we already had §4.1.1 "Using SIDs in keys" that
said almost nothing about it.

Section 4.2.2

  [...] A namespace-qualified name
  MUST be used each time the namespace of a schema node and its parent
  differ.  In all other cases, the simple form of the name MUST be
  used.  [...]

We have a similar statement in §3.3 that is only "the simple form of the
name SHOULD be used" for the latter sentence.  It's not entirely clear
to me what causes the strength of requirement to be different between
the two cases.

Section 4.6

Do we want to explicitly acknowledge the mismatch between the "xml" in
"anyxml" and the actual CBOR contents?

Section 5.2

  The yang-data extensions encoded using names are carried in a CBOR
  map containing a single item pair.  The key of this item is set to
  the namespace qualified name of the yang-data extension container;
  the value is set to the CBOR encoding of this container as defined in
  Section 3.3.

I'm not sure if this is a nit or not, so putting it here: is §3.3 the
right reference for the encoding of the container (vs. §4.2)?

Section 6.6

Requiring the string form for enumeration constants in a union seems
like a big loss on encoded size.  Is it worth putting some discussion in
the document (or an appendix thereto) about why other options like
tagged integer are not usable?  (Similar discussion might be relevant
for the bits-in-union case.)

While it's banal, we might also put an example of the integer-encoded
form (as used by non-union contexts) so that the tagged-text-string
example isn't the only one given.

  Leafs of type enumeration MUST be encoded using a CBOR unsigned
  integer (major type 0) or CBOR negative integer (major type 1),
  depending on the actual value.  [...]

I think we should also mention the tagged-text-string case here.

Section 6.7

  In a number of cases the array would only need to have one element -
  a byte string with a small number of bytes inside.  For this case, it
  is expected to omit the array element and have only the byte array
  that would have been inside.  [...]

I think it is actually required (not just "expected") based on some
later text.

Section 6.10, 6.13

I strongly encourage explicit mention of the use of a CBOR tag when
these elements appear inside a union, analogous to the text in §6.6 and
6.7.  The list in §6.12 is pretty easy to miss, and the word "tag" does
not appear at all in these sections.

Section 7

  This specification defines the media-type "application/yang-
  data+cbor", which can be used without parameters or with the
  parameter "id=name" or "id=sid".

I think the media-type discussions should refer to the "id" parameter
and the two possible values for that parameter ('=' is not allowed in a
parameter name).

  This media-type represents a CBOR YANG document containing one or
  multiple data node values.  Depending on the presence and value of
  the media-type parameter "id", each data node is identified by its
  associated namespace qualified name as defined in Section 3.3
  ("id=name"), by its associated YANG SID (represented as a SID delta
  or via tag 47) as defined in Section 3.2 ("id=sid"), or either of
  these (no "id" parameter given).

I think that for identityref and instance-identifier we don't use the
tag 47 for absolute (non-delta) SIDs, at least outside of a union
context.

Section 8

It might be worth mentioning that when the 'id' parameter to the media
type is used, it's important to properly reject identifiers of the other
type, to avoid scenarios where different implementations interpret a
given content in different ways.

Section 10.1

It's not clear to me that RFC 6241 needs to be classified as normative,
at least based on the one place in the text where we reference it.


NITS

Section 2

  *  child: A schema node defined as a child node of a container, a
      list, a case, a notification, an RPC input, an RPC output, an
      action input, or an action output.

Is this enumeration of "parent" node types guaranteed to be fixed for
all time, or should we consider a more generic wording to describe it?
(Likewise for the "parent" definition.)

Section 4

The example from RFC 7317 may have truncated a little too much of the
content; "mandatory true" for choice transport, the "inet:" prefix for
"type inet:host" and "inet:port-number", etc.

Section 4.4.1

  Deltas of list members are equal to the SID of the current schema
  node minus the SID of the 'list'.

This seems redundant with the list of "Delta values are computed as
follows" from §4.2.1.

Section 4.5

  *  CBOR map keys of any inner schema nodes MUST be set to valid
      deltas or names.

  *  The CBOR array MUST contain either unique scalar values (as a
      leaf-list, see Section 4.3), or maps (as a list, see Section 4.4).

I think a parallel list structure would be "CBOR arrays MUST contain
[...]".

  *  CBOR map values MUST follow the encoding rules of one of the
      datatypes listed in Section 4.

(A recursive reference, though I mostly trust the reader to pick out the
relevant subsections.)

Section 4.5.1

  In some implementations, it might be simpler to use the absolute SID
  tag encoding for the anydata root element.  The resulting encoding is
  as follows:

Pedantically, what follows is diagnostic notation, not a CBOR encoding.

Section 4.6

  An anyxml schema node is used to serialize an arbitrary CBOR content,
  i.e., its value can be any CBOR binary object. anyxml value MAY
  contain CBOR data items tagged with one of the tags listed in
  Section 9.3.  The tags listed in Section 9.3 SHALL be supported.

The second sentence seems to both not start with a capital letter and
have a singular/plural mismatch, both of which could be resolved by
adding "An" at the start.

Section 6.13.1

  Single instance schema nodes MUST be encoded using a CBOR unsigned
  integer data item (major type 0) and set to the targeted schema node
  SID.

Should we say something about the lack of a delta encoding in this
context, analogous to §6.10.1?

[Ballot comment]
Found terminology that should be reviewed for inclusivity:
* Term "natively"; alternatives might be "built-in", "fundamental",
  "ingrained", "intrinsic", "original".
See https://www.rfc-editor.org/part2/#inclusive_language for background and
more guidance.

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 3.3. , paragraph 7, nit:
>  Section 6. The following examples shows the encoding of a 'hostname' leaf u
>                                    ^^^^^
You should probably use "show".

Section 4. , paragraph 2, nit:
> ta item (major type 5). A map is comprised of pairs of data items, with each
>                              ^^^^^^^^^^^^^^^
Did you mean "comprises" or "consists of" or "is composed of"?

Section 4.1. , paragraph 5, nit:
> ection 3.3. The following examples shows the encoding of a 'system-state' co
>                                    ^^^^^
You should probably use "show".

Section 5.2. , paragraph 7, nit:
> e element -a byte string with a small number of bytes inside. For this case,
>                              ^^^^^^^^^^^^^^^^^
Specify a number, remove phrase, use "a few", or use "some".

Section 6.8. , paragraph 2, nit:
> ized-key/key-data" (SID 1734) for user name "bob" and authorized-key "admin"
>                                  ^^^^^^^^^
It"s more common nowadays to write this noun as one word.

Section 6.9. , paragraph 6, nit:
> user" (SID 1730) corresponding to user name "jack". CBOR diagnostic notation
>                                  ^^^^^^^^^
It"s more common nowadays to write this noun as one word.

Document references draft-ietf-core-sid-15, but -16 is the latest available
revision.

Document Writeup for Working Group Documents

This is the write for the CORECONF document draft-ietf-core-yang-cbor-16 released on 2021-06-25.

> (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

The document is intended for standards-track (Proposed Standard).

The set of documents composed by the present one, draft-ietf-core-sid, draft-ietf-core-comi and draft-ietf-core-yang-library provides the CORECONF
specification.

At the same time, the pair composed of the present document and draft-ietf-core-sid can also be used individually as interoperability protocols outside of that shared context.

> (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

* Technical Summary:

The present document and draft-ietf-core-sid together provide the foundation to extend YANG-based management down to constrained devices (RFC 7228).

In particular, the present document defines encoding rules for serializing YANG using the Concise Binary Object Representation (CBOR) [RFC8949], specifically configuration data, state data, RPC input and RPC output, action input, action output, notifications and yang-data extension defined within YANG modules.

The companion document draft-ietf-core-sid defines YANG Schema Item iDentifiers (YANG SID) and a file format used to persist and publish assigned YANG SIDs.

The two other documents draft-ietf-core-comi and draft-ietf-core-yang-library apply the two documents above, by using the CoAP protocol (RFC 7252) for access and providing information to be used in conjunction with CoRE resource discovery (RFC 6690).

* Working Group Summary:

The suite of documents spans specific areas of interest of several WGs, in particular NETMOD, CBOR, and CORE, as well as NETCONF. This required coordination between authors and reviewers that see different of these WGs as their central point of activity. While the documents were stable already for a while, a specific issue on representing YANG unions required somewhat unsavory resolutions, which held up the process considerably.

* Document Quality:

Since the document became a WG document in April 2016, several reviews were provided by members of the concerned WGs.

Of particular interest is the review by Jürgen Schönwälder :

Jürgen as well as Andy Bierman were very helpful in resolving remaining issues about this document as well. Andy is also is a co-author of the draft-ietf-core-comi specification using the present document and the companion document draft-ietf-core-sid.

Version -16 addressed Last-Call review comments received from Yangdoctors and Genart.

We are waiting for feedback on the media-types review request, archived at:


* Personnel:

Document Shepherd: Marco Tiloca
Area Director: Francesca Palombini

Carsten Bormann served as Document Shepherd up until version -15 included, thus taking care of most of the shepherding process and especially providing the original version of this writeup.


> (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The original document shepherd actively followed the creation of this document and provided a shepherd review that included nits fixed in the most recent versions. The original document shepherd believes this document is ready for publication.

The current document shepherd has further reviewed the document, has no concerns and concurs with the judgdment of the original document shepherd.

> (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

> (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

The netconf/netmod perspective was mainly addressed in physical side meetings at IETFs and in personal reviews. Briefly, there was traffic on the mailing list yot@ietf.org, as well, approximately 100 messages by some 12 individuals.

> (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

(N/A)

> (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

All authors have confirmed that they do not have any direct, personal knowledge of any patent claim ("IPR") related to each of the drafts where they are listed as author.

> (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

As of 2021-06-21, no.

> (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Many members of the WG do not see YANG as a primary management interface for their work on constrained devices. There has been little opposition against pursuing this as an additional approach though. Between the individuals who want to make use of YANG for constrained devices, there is strong consensus.

> (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

> (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

ID nits found during the shepherd review were addressed in the most recent versions.

> (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

We are waiting for feedback on the request for media-type review (see above).

> (13) Have all references within this document been identified as either normative or informative?

Yes.

> (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

This document has normative references to RFCs only. Also, it has informative references to the other CORECONF documents draft-ietf-core-comi and draft-ietf-core-sid.

> (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

> (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

> (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

This document has a relatively plain IANA considerations section, only adding items to existing registries.

> (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

(N/A)

> (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

This document contains a single line of ABNF using a production from RFC 7950, which validates with "bap". It also contains many snippets of YANG that have been eyeball-verified only.

> (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

(N/A)

Document Writeup for Working Group Documents

This is the write for the CORECONF document draft-ietf-core-yang-cbor-15 released on 2021-01-24.

> (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

The document is intended for standards-track (Proposed Standard).

The set of documents composed by the present one, draft-ietf-core-sid, draft-ietf-core-comi and draft-ietf-core-yang-library provides the CORECONF
specification.

At the same time, the pair composed of the present document and draft-ietf-core-sid can also be used individually as interoperability protocols outside of that shared context.

> (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

* Technical Summary:

The present document and draft-ietf-core-sid together provide the foundation to extend YANG-based management down to constrained devices (RFC 7228).

In particular, the present document defines encoding rules for serializing YANG using the Concise Binary Object Representation (CBOR) [RFC8949], specifically configuration data, state data, RPC input and RPC output, action input, action output, notifications and yang-data extension defined within YANG modules.

The companion document draft-ietf-core-sid defines YANG Schema Item iDentifiers (YANG SID) and a file format used to persist and publish assigned YANG SIDs.

The two other documents draft-ietf-core-comi and draft-ietf-core-yang-library apply the two documents above, by using the CoAP protocol (RFC 7252) for access and providing information to be used in conjunction with CoRE resource discovery (RFC 6690).

* Working Group Summary:

The suite of documents spans specific areas of interest of several WGs, in particular NETMOD, CBOR, and CORE, as well as NETCONF. This required coordination between authors and reviewers that see different of these WGs as their central point of activity. While the documents were stable already for a while, a specific issue on representing YANG unions required somewhat unsavory resolutions, which held up the process considerably.

* Document Quality:

Since the document became a WG document in April 2016, several reviews were provided by members of the concerned WGs.

Of particular interest is the review by Jürgen Schönwälder :

Jürgen as well as Andy Bierman were very helpful in resolving remaining issues about this document as well. Andy is also is a co-author of the draft-ietf-core-comi specification using the present document and the companion document draft-ietf-core-sid.

Version -16 addressed Last-Call review comments received from Yangdoctors and Genart.

We are waiting for feedback on the media-types review request, archived at:


* Personnel:

Document Shepherd: Marco Tiloca
Area Director: Francesca Palombini

Carsten Bormann served as Document Shepherd up until version -15 included, thus taking care of most of the shepherding process and especially providing the original version of this writeup.


> (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The original document shepherd actively followed the creation of this document and provided a shepherd review that included nits fixed in the most recent versions. The original document shepherd believes this document is ready for publication.

The current document shepherd has further reviewed the document, has no concerns and concurs with the judgdment of the original document shepherd.

> (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

> (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

The netconf/netmod perspective was mainly addressed in physical side meetings at IETFs and in personal reviews. Briefly, there was traffic on the mailing list yot@ietf.org, as well, approximately 100 messages by some 12 individuals.

> (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

(N/A)

> (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

All authors have confirmed that they do not have any direct, personal knowledge of any patent claim ("IPR") related to each of the drafts where they are listed as author.

> (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

As of 2021-06-21, no.

> (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Many members of the WG do not see YANG as a primary management interface for their work on constrained devices. There has been little opposition against pursuing this as an additional approach though. Between the individuals who want to make use of YANG for constrained devices, there is strong consensus.

> (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

> (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

ID nits found during the shepherd review were addressed in the most recent versions.

> (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

We are waiting for feedback on the request for media-type review (see above).

> (13) Have all references within this document been identified as either normative or informative?

Yes.

> (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

This document has normative references to RFCs only. Also, it has informative references to the other CORECONF documents draft-ietf-core-comi and draft-ietf-core-sid.

> (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

> (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

> (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

This document has a relatively plain IANA considerations section, only adding items to existing registries.

> (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

(N/A)

> (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

This document contains a single line of ABNF using a production from RFC 7950, which validates with "bap". It also contains many snippets of YANG that have been eyeball-verified only.

> (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

(N/A)

Document Writeup for Working Group Documents

This is the write for the CORECONF document draft-ietf-core-yang-cbor-15 released on 2021-01-24.

> (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

The document is intended for standards-track (Proposed Standard).

The set of documents composed by the present one, draft-ietf-core-sid, draft-ietf-core-comi and draft-ietf-core-yang-library provides the CORECONF
specification.

At the same time, the pair composed of the present document and draft-ietf-core-sid can also be used individually as interoperability protocols outside of that shared context.

> (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

* Technical Summary:

The present document and draft-ietf-core-sid together provide the foundation to extend YANG-based management down to constrained devices (RFC 7228).

In particular, the present document defines encoding rules for serializing YANG using the Concise Binary Object Representation (CBOR) [RFC8949], specifically configuration data, state data, RPC input and RPC output, action input, action output, notifications and yang-data extension defined within YANG modules.

The companion document draft-ietf-core-sid defines YANG Schema Item iDentifiers (YANG SID) and a file format used to persist and publish assigned YANG SIDs.

The two other documents draft-ietf-core-comi and draft-ietf-core-yang-library apply the two documents above, by using the CoAP protocol (RFC 7252) for access and providing information to be used in conjunction with CoRE resource discovery (RFC 6690).

* Working Group Summary:

The suite of documents spans specific areas of interest of several WGs, in particular NETMOD, CBOR, and CORE, as well as NETCONF. This required coordination between authors and reviewers that see different of these WGs as their central point of activity. While the documents were stable already for a while, a specific issue on representing YANG unions required somewhat unsavory resolutions, which held up the process considerably.

* Document Quality:

Since the document became a WG document in April 2016, several reviews were provided by members of the concerned WGs.

Of particular interest is the review by Jürgen Schönwälder :

Jürgen as well as Andy Bierman were very helpful in resolving remaining issues about this document as well. Andy is also is a co-author of the draft-ietf-core-comi specification using the present document and the companion document draft-ietf-core-sid.

Version -16 addressed Last-Call review comments received from Yangdoctors and Genart.

We are waiting for feedback on the media-types review request, archived at:


* Personnel:

Document Shepherd: Marco Tiloca
Area Director: Francesca Palombini

Carsten Bormann served as Document Shepherd up until version -15 included, thus taking care of most of the shepherding process and especially providing the original version of this writeup.


> (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The original document shepherd actively followed the creation of these two
document and provided a shepherd review that included nits fixed in the most recent versions. The original document shepherd believes this document is ready for publication.

The current document shepherd has further reviewed the document, has no concerns and concurs with the judgdment of the original document shepherd.

> (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

> (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

The netconf/netmod perspective was mainly addressed in physical side meetings at IETFs and in personal reviews. Briefly, there was traffic on the mailing list yot@ietf.org, as well, approximately 100 messages by some 12 individuals.

> (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

(N/A)

> (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

All authors have confirmed that they do not have any direct, personal knowledge of any patent claim ("IPR") related to each of the drafts where they are listed as author.

> (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

As of 2021-06-21, no.

> (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Many members of the WG do not see YANG as a primary management interface for their work on constrained devices. There has been little opposition against pursuing this as an additional approach though. Between the individuals who want to make use of YANG for constrained devices, there is strong consensus.

> (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

> (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

ID nits found during the shepherd review were addressed in the most recent versions.

> (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

We are waiting for feedback on the request for media-type review (see above).

> (13) Have all references within this document been identified as either normative or informative?

Yes.

> (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

This document has normative references to RFCs only. Also, it has informative references to the other CORECONF documents draft-ietf-core-comi and draft-ietf-core-sid.

> (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

> (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

> (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

This document has a relatively plain IANA considerations section, only adding items to existing registries.

> (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

(N/A)

> (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

This document contains a single line of ABNF using a production from RFC 7950, which validates with "bap". It also contains many snippets of YANG that have been eyeball-verified only.

> (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

(N/A)

Document Writeup for Working Group Documents

This is the write for the CORECONF document draft-ietf-core-yang-cbor-15 released on 2021-01-24.

> (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

The document is intended for standards-track (Proposed Standard).

The set of documents composed by the present one, draft-ietf-core-sid, draft-ietf-core-comi and draft-ietf-core-yang-library provides the CORECONF
specification.

At the same time, the pair composed of the present document and draft-ietf-core-sid can also be used individually as interoperability protocols outside of that shared context.

> (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

* Technical Summary:

The present document and draft-ietf-core-sid together provide the foundation to extend YANG-based management down to constrained devices (RFC 7228).

In particular, the present document defines encoding rules for serializing YANG using the Concise Binary Object Representation (CBOR) [RFC8949], specifically configuration data, state data, RPC input and RPC output, action input, action output, notifications and yang-data extension defined within YANG modules.

The companion document draft-ietf-core-sid defines YANG Schema Item iDentifiers (YANG SID) and a file format used to persist and publish assigned YANG SIDs.

The two other documents draft-ietf-core-comi and draft-ietf-core-yang-library apply the two documents above, by using the CoAP protocol (RFC 7252) for access and providing information to be used in conjunction with CoRE resource discovery (RFC 6690).

* Working Group Summary:

The suite of documents spans specific areas of interest of several WGs, in particular NETMOD, CBOR, and CORE, as well as NETCONF. This required coordination between authors and reviewers that see different of these WGs as their central point of activity. While the documents were stable already for a while, a specific issue on representing YANG unions required somewhat unsavory resolutions, which held up the process considerably.

* Document Quality:

Since the document became a WG document in April 2016, several reviews were provided by members of the concerned WGs.

Of particular interest is the review by Jürgen Schönwälder :

Jürgen as well as Andy Bierman were very helpful in resolving remaining issues about this document as well. Andy is also is a co-author of the draft-ietf-core-comi specification using the present document and the companion document draft-ietf-core-sid.

We are waiting for feedback on the media-types review request, archived at:


* Personnel:

Document Shepherd: Marco Tiloca
Area Director: Francesca Palombini

Carsten Bormann served as Document Shepherd up until version -15 included, thus taking care of most of the shepherding process and especially providing the original version of this writeup.


> (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The original document shepherd actively followed the creation of these two
document and provided a shepherd review that included nits fixed in the most recent versions. The original document shepherd believes this document is ready for publication.

The current document shepherd has further reviewed the document, has no concerns and concurs with the judgdment of the original document shepherd.

> (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

> (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

The netconf/netmod perspective was mainly addressed in physical side meetings at IETFs and in personal reviews. Briefly, there was traffic on the mailing list yot@ietf.org, as well, approximately 100 messages by some 12 individuals.

> (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

(N/A)

> (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

All authors have confirmed that they do not have any direct, personal knowledge of any patent claim ("IPR") related to each of the drafts where they are listed as author.

> (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

As of 2021-06-21, no.

> (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Many members of the WG do not see YANG as a primary management interface for their work on constrained devices. There has been little opposition against pursuing this as an additional approach though. Between the individuals who want to make use of YANG for constrained devices, there is strong consensus.

> (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

> (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

ID nits found during the shepherd review were addressed in the most recent versions.

> (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

We are waiting for feedback on the request for media-type review (see above).

> (13) Have all references within this document been identified as either normative or informative?

Yes.

> (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

This document has normative references to RFCs only. Also, it has informative references to the other CORECONF documents draft-ietf-core-comi and draft-ietf-core-sid.

> (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

> (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

> (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

This document has a relatively plain IANA considerations section, only adding items to existing registries.

> (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

(N/A)

> (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

This document contains a single line of ABNF using a production from RFC 7950, which validates with "bap". It also contains many snippets of YANG that have been eyeball-verified only.

> (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

(N/A)

Document Writeup for Working Group Documents

This is the write for the CORECONF document draft-ietf-core-yang-cbor-15 released on 2021-01-24.

> (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

The document is intended for standards-track (Proposed Standard).

The set of documents composed by the present one, draft-ietf-core-sid, draft-ietf-core-comi and draft-ietf-core-yang-library provides the CORECONF
specification.

At the same time, the pair composed of the present document and draft-ietf-core-sid can also be used individually as interoperability protocols outside of that shared context.

> (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

* Technical Summary:

The present document and draft-ietf-core-sid together provide the foundation to extend YANG-based management down to constrained devices (RFC 7228).

In particular, the present document defines encoding rules for serializing YANG using the Concise Binary Object Representation (CBOR) [RFC8949], specifically configuration data, state data, RPC input and RPC output, action input, action output, notifications and yang-data extension defined within YANG modules.

The companion document draft-ietf-core-sid defines YANG Schema Item iDentifiers (YANG SID) and a file format used to persist and publish assigned YANG SIDs.

The two other documents draft-ietf-core-comi and draft-ietf-core-yang-library apply the two documents above, by using the CoAP protocol (RFC 7252) for access and providing information to be used in conjunction with CoRE resource discovery (RFC 6690).

* Working Group Summary:

The suite of documents spans specific areas of interest of several WGs, in particular NETMOD, CBOR, and CORE, as well as NETCONF. This required coordination between authors and reviewers that see different of these WGs as their central point of activity. While the documents were stable already for a while, a specific issue on representing YANG unions required somewhat unsavory resolutions, which held up the process considerably.

* Document Quality:

Since the document became a WG document in April 2016, several reviews were provided by members of the concerned WGs.

Of particular interest is the review by Jürgen Schönwälder :

Jürgen as well as Andy Bierman were very helpful in resolving remaining issues about this document as well. Andy is also is a co-author of the draft-ietf-core-comi specification using the present document and the companion document draft-ietf-core-sid.

We are waiting for feedback on the media-types review request, archived at:


* Personnel:

Document Shepherd: Marco Tiloca
Area Director: Francesca Palombini

Carsten Bormann served as Document Shepherd up until version -15 included, thus taking care of most of the shepherding process and especially providing the original version of this writeup.


> (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The original document shepherd actively followed the creation of these two
document and provided a shepherd review that included nits fixed in the most recent versions. The original document shepherd believes this document is ready for publication.

The current document shepherd has further reviewed the document, has no concerns and concurs with the judgdment of the original document shepherd.

> (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

> (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

The netconf/netmod perspective was mainly addressed in physical side meetings at IETFs and in personal reviews. Briefly, there was traffic on the mailing list yot@ietf.org, as well, approximately 100 messages by some 12 individuals.

> (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

(N/A)

> (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

All authors have confirmed that they do not have any direct, personal knowledge of any patent claim ("IPR") related to each of the drafts where they are listed as author.

> (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

As of 2021-06-21, no.

> (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Many members of the WG do not see YANG as a primary management interface for their work on constrained devices. There has been little opposition against pursuing this as an additional approach though. Between the individuals who want to make use of YANG for constrained devices, there is strong consensus.

> (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

> (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

ID nits found during the shepherd review were addressed in the most recent versions.

> (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

We are waiting for feedback on the request for media-type review (see above).

> (13) Have all references within this document been identified as either normative or informative?

Yes.

> (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

This document has normative references to RFCs only. Also, it has informative references to the other CORECONF documents draft-ietf-core-comi and draft-ietf-core-sid.

> (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

> (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

> (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

This document has a relatively plain IANA considerations section, only adding items to existing registries.

> (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

(N/A)

> (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

This document contains a single line of ABNF using a production from RFC Pu7950, which validates with "bap". It also contains many snippets of YANG that have been eyeball-verified only.

> (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

(N/A)

Document Writeup for Working Group Documents

This is the write for the CORECONF document draft-ietf-core-yang-cbor-15 released on 2021-01-24.

> (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

The document is intended for standards-track (Proposed Standard).

The set of documents composed by the present one, draft-ietf-core-sid, draft-ietf-core-comi and draft-ietf-core-yang-library provides the CORECONF
specification.

At the same time, the pair composed of the present document and draft-ietf-core-sid can also be used individually as interoperability protocols outside of that shared context.

> (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

* Technical Summary:

The present document and draft-ietf-core-sid together provide the foundation to extend YANG-based management down to constrained devices (RFC 7228).

In particular, the present document defines encoding rules for serializing YANG using the Concise Binary Object Representation (CBOR) [RFC8949], specifically configuration data, state data, RPC input and RPC output, action input, action output, notifications and yang-data extension defined within YANG modules.

The companion document draft-ietf-core-sid defines encoding rules for serializing YANG using the Concise Binary Object Representation (CBOR) [RFC8949].

The two other documents draft-ietf-core-comi and draft-ietf-core-yang-library apply the two documents above, by using the CoAP protocol (RFC 7252) for access and providing information to be used in conjunction with CoRE resource discovery (RFC 6690).

* Working Group Summary:

The suite of documents spans specific areas of interest of several WGs, in particular NETMOD, CBOR, and CORE, as well as NETCONF. This required coordination between authors and reviewers that see different of these WGs as their central point of activity. While the documents were stable already for a while, a specific issue on representing YANG unions required somewhat unsavory resolutions, which held up the process considerably.

* Document Quality:

Since the document became a WG document in April 2016, several reviews were provided by members of the concerned WGs.

Of particular interest is the review by Jürgen Schönwälder :

Jürgen as well as Andy Bierman were very helpful in resolving remaining issues about this document as well. Andy is also is a co-author of the draft-ietf-core-comi specification using the present document and the companion document draft-ietf-core-sid.

We are waiting for feedback on the media-types review request, archived at:


* Personnel:

Document Shepherd: Marco Tiloca
Area Director: Francesca Palombini

Carsten Bormann served as Document Shepherd up until version -15 included, thus taking care of most of the shepherding process and especially providing the original version of this writeup.


> (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The original document shepherd actively followed the creation of these two
document and provided a shepherd review that included nits fixed in the most recent versions. The original document shepherd believes this document is ready for publication.

The current document shepherd has further reviewed the document, has no concerns and concurs with the judgdment of the original document shepherd.

> (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

> (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

The netconf/netmod perspective was mainly addressed in physical side meetings at IETFs and in personal reviews. Briefly, there was traffic on the mailing list yot@ietf.org, as well, approximately 100 messages by some 12 individuals.

> (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

(N/A)

> (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

All authors have confirmed that they do not have any direct, personal knowledge of any patent claim ("IPR") related to each of the drafts where they are listed as author.

> (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

As of 2021-06-21, no.

> (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Many members of the WG do not see YANG as a primary management interface for their work on constrained devices. There has been little opposition against pursuing this as an additional approach though. Between the individuals who want to make use of YANG for constrained devices, there is strong consensus.

> (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

> (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

ID nits found during the shepherd review were addressed in the most recent versions.

> (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

We are waiting for feedback on the request for media-type review (see above).

> (13) Have all references within this document been identified as either normative or informative?

Yes.

> (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

This document has normative references to RFCs only. Also, it has informative references to the other CORECONF documents draft-ietf-core-comi and draft-ietf-core-sid.

> (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

> (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

> (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

This document has a relatively plain IANA considerations section, only adding items to existing registries.

> (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

(N/A)

> (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

This document contains a single line of ABNF using a production from RFC Pu7950, which validates with "bap". It also contains many snippets of YANG that have been eyeball-verified only.

> (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

(N/A)

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-core-yang-cbor-15. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the application registration space on the Media Type registry page located at:

https://www.iana.org/assignments/media-types/

a single registration is to be made as follows:

Name: yang-data+cbor
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Second, in the CoAP Content-Formats registry on the Constrained RESTful Environments (CoRE) Parameters registry page located at:

https://www.iana.org/assignments/core-parameters/

a single, new registration is to be made as follows:

Media-Type: application/yang-data+cbor;id=name
Encoding:
ID: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

IANA Question --> Which range in the CoAP Content-Formats registry should this registration come from?

Third, in the Concise Binary Object Representation (CBOR) Tags registry located at:

https://www.iana.org/assignments/cbor-tags/

the four existing registrations:

Tag: 43
Data item: text string
Semantics: YANG bits datatype; see Section 6.7
Reference: [ RFC-to-be ]

Tag: 44
Data item: text string
Semantics: YANG enumeration datatype; see Section 6.6
Reference: [ RFC-to-be ]

Tag: 45
Data item: unsigned integer or text string
Semantics: YANG identityref datatype; see Section 6.10
Reference: [ RFC-to-be ]

Tag: 46
Data item: unsigned integer or text string or array
Semantics: YANG instance-identifier datatype; see Section 6.13
Reference: [ RFC-to-be ]

Tag: 47
Data item: unsigned integer
Semantics: YANG Schema Item iDentifier; see Section 3.2
Reference: [ RFC-to-be ]

will have their reference changed to [ RFC-to-be ].

Since there have been some changes to the "Data Item" field, we're asking the IESG-designated expert to confirm that these are OK. This review must be completed before the document's IANA state can be changed to "IANA OK."

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-03-17):

From: The IESG
To: IETF-Announce
CC: Carsten Bormann , barryleiba@gmail.com, cabo@tzi.org, core-chairs@ietf.org, core@ietf.org, draft-ietf-core-yang-cbor@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (CBOR Encoding of Data Modeled with YANG) to Proposed Standard


The IESG has received a request from the Constrained RESTful Environments WG
(core) to consider the following document: - 'CBOR Encoding of Data Modeled
with YANG'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-03-17. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines encoding rules for serializing configuration
  data, state data, RPC input and RPC output, action input, action
  output, notifications and yang-data extension defined within YANG
  modules using the Concise Binary Object Representation (CBOR, RFC
  8949).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/



No IPR declarations have been submitted directly on this I-D.

Document Writeup for Working Group Documents

This is a shared writeup for the first two of the four CORECONF drafts:

| name and version                |      date |
|---------------------------------|------------|
| draft-ietf-core-yang-cbor-15    | 2021-01-24 |
| draft-ietf-core-sid-15          | 2021-01-17 |

A second writeup will later be made available for the two other CORECONF drafts:

| name and version                |      date |
|---------------------------------|------------|
| draft-ietf-core-comi-11        | 2021-01-17 |
| draft-ietf-core-yang-library-03 | 2021-01-11 |

> (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Both documents are intended for standards-track (Proposed Standard),
as they together with the other two provide the CORECONF
specification, but also can be used individually as interoperability
protocols outside of that shared context.

> (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

* Technical Summary:

The two drafts provide the foundation to extend YANG-based management
down to constrained devices (RFC 7228).  The parts are:

yang-cbor:
:  encoding rules for serializing YANG using the Concise Binary Object
  Representation (CBOR) [RFC8949], specifically configuration data,
  state data, RPC input and RPC output, action input, action output,
  notifications and yang-data extension defined within YANG modules.

sid:
:  the semantics, the registration, and assignment processes of YANG
  Schema Item iDentifiers (YANG SIDs), globally unique 63-bit
  unsigned integers used to identify YANG items.  To enable these
  processes, also defines a file format used to persist and publish
  assigned YANG SIDs.

The other two drafts, comi and yang-library, apply these drafts by
using the CoAP protocol (RFC 7252) for access and providing
information to be used in conjunction with CoRE resource discovery
(RFC 6690).

* Working Group Summary:

The suite of documents spans specific areas of interest of several
WGs, in particular NETMOD, CBOR, and CORE, as well as NETCONF.
This required coordination between authors and reviewers that see
different of these WGs as their central point of activity.
While the documents were stable already for a while, a specific issue
on representing YANG unions required somewhat unsavory resolutions,
which held up the process considerably.

* Document Quality:

Since the documents became WG documents (in Apr 2016 and Oct 2016),
several reviews were provided by members of the concerned WGs.

Of particular interest are the reviews by Jürgen Schönwälder:
yang-cbor-12:
sid:
Jürgen as well as Andy Bierman were very helpful in resolving
remaining issues about these documents as well (Andy also is a
co-author on the comi specification using these two documents).

The SID process is implemented in PYANG modules.
Various parts of the protocol are implemented in proprietary software,
however there is no single go-to implementation that could be
mentioned here.

We are waiting for feedback on the media-types review request,
archived at:



* Personnel:

Carsten Bormann serves as Document Shepherd.
Barry Leiba is the Responsible Area Director for the CoRE WG.


> (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd has actively followed the creation of these two
document and has provided a shepherd review that included nits fixed
in the most recent versions.
The document shepherd believes these documents are ready for publication.

> (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

> (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

The netconf/netmod perspective was mainly addressed in physical side
meetings at IETFs and in personal reviews.  Briefly, there was traffic
on the mailing list yot@ietf.org, as well, approximately 100 messages
by some 12 individuals.

> (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

(N/A)

> (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

All authors have confirmed that they do not have any direct, personal
knowledge of any patent claim ("IPR") related to each of the drafts
where they are listed as author.

> (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

As of 2021-02-04, no.

> (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Many members of the WG don't see YANG as a primary management
interface for their work on constrained devices.  There has been
little opposition against pursuing this as an additional approach
though.  Between the individuals who want to make use of YANG for
constrained devices, there is strong consensus.

> (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

> (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

ID nits the shepherd found were addressed in the most recent versions.

> (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The YANG module in sid (a data format specification) does not have warnings.

We are waiting for feedback on the request for media-type review (see above).

> (13) Have all references within this document been identified as either normative or informative?

Yes.

> (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

yang-cbor has normative references to RFCs only.
sid has a normative reference to yang-cbor.
(Both have informative references to some of the other CORECONF documents.)

> (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

> (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

> (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

yang-cbor has a relatively plain IANA considerations section, only
adding items to existing registries.
sid has some real innovations in the interactions with IANA, which
were the result of extensive interactions between IANA and the
authors and WG chairs.

> (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

sid creates the "YANG SID Mega-Range" registry, the "IETF YANG SID
Range" registry, and the "IETF YANG SID Registry".  All require Expert
Review, both with respect to properly curating a somewhat limited
resource, and with respect to technical soundness of the registrations.

> (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

sid defines a YANG module ietf-sid-file that passes the validation
provided by the datatracker.
yang-cbor contains a single line of ABNF using a production from RFC
Pu7950, which validates with "bap".
yang-cbor also contains many snippets of YANG that have been
eyeball-verified only.

> (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

sid defines a YANG module ietf-sid-file that passes the validation
provided by the datatracker.
This YANG module does not define a datastore, so NMDA does not apply.

Document Writeup for Working Group Documents

This is a shared writeup for the first two of the four CORECONF drafts:

| name and version                |      date |
|---------------------------------|------------|
| draft-ietf-core-yang-cbor-15    | 2021-01-24 |
| draft-ietf-core-sid-15          | 2021-01-17 |

A second writeup will later be made available for the two other CORECONF drafts:

| name and version                |      date |
|---------------------------------|------------|
| draft-ietf-core-comi-11        | 2021-01-17 |
| draft-ietf-core-yang-library-03 | 2021-01-11 |

> (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Both documents are intended for standards-track (Proposed Standard),
as they together with the other two provide the CORECONF
specification, but also can be used individually as interoperability
protocols outside of that shared context.

> (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

* Technical Summary:

The two drafts provide the foundation to extend YANG-based management
down to constrained devices (RFC 7228).  The parts are:

yang-cbor:
:  encoding rules for serializing YANG using the Concise Binary Object
  Representation (CBOR) [RFC8949], specifically configuration data,
  state data, RPC input and RPC output, action input, action output,
  notifications and yang-data extension defined within YANG modules.

sid:
:  the semantics, the registration, and assignment processes of YANG
  Schema Item iDentifiers (YANG SIDs), globally unique 63-bit
  unsigned integers used to identify YANG items.  To enable these
  processes, also defines a file format used to persist and publish
  assigned YANG SIDs.

The other two drafts, comi and yang-library, apply these drafts by
using the CoAP protocol (RFC 7252) for access and providing
information to be used in conjunction with CoRE resource discovery
(RFC 6690).

* Working Group Summary:

The suite of documents spans specific areas of interest of several
WGs, in particular NETMOD, CBOR, and CORE, as well as NETCONF.
This required coordination between authors and reviewers that see
different of these WGs as their central point of activity.
While the documents were stable already for a while, a specific issue
on representing YANG unions required somewhat unsavory resolutions,
which held up the process considerably.

* Document Quality:

Since the documents became WG documents (in Apr 2016 and Oct 2016),
several reviews were provided by members of the concerned WGs.

Of particular interest are the reviews by Jürgen Schönwälder:
yang-cbor-12:
sid:
Jürgen as well as Andy Bierman were very helpful in resolving
remaining issues about these documents as well (Andy also is a
co-author on the comi specification using these two documents).

The SID process is implemented in PYANG modules.
Various parts of the protocol are implemented in proprietary software,
however there is no single go-to implementation that could be
mentioned here.

We are waiting for feedback on the media-types review request,
archived at:



* Personnel:

Carsten Bormann serves as Document Shepherd.
Barry Leiba is the Responsible Area Director for the CoRE WG.


> (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd has actively followed the creation of these two
document and has provided a shepherd review that included nits fixed
in the most recent versions.
The document shepherd believes these documents are ready for publication.

> (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

> (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

The netconf/netmod perspective was mainly addressed in physical side
meetings at IETFs and in personal reviews.  Briefly, there was traffic
on the mailing list yot@ietf.org, as well, approximately 100 messages
by some 12 individuals.

> (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

(N/A)

> (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

All authors have confirmed that they do not have any direct, personal
knowledge of any patent claim ("IPR") related to each of the drafts
where they are listed as author.

> (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

As of 2021-02-04, no.

> (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Many members of the WG don't see YANG as a primary management
interface for their work on constrained devices.  There has been
little opposition against pursuing this as an additional approach
though.  Between the individuals who want to make use of YANG for
constrained devices, there is strong consensus.

> (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

> (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

ID nits the shepherd found were addressed in the most recent versions.

> (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The YANG module in sid (a data format specification) does not have warnings.

We are waiting for feedback on the request for media-type review (see above).

> (13) Have all references within this document been identified as either normative or informative?

Yes.

> (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

yang-cbor has normative references to RFCs only.
sid has a normative reference to yang-cbor.
(Both have informative references to some of the other CORECONF documents.)

> (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

> (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

> (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

yang-cbor has a relatively plain IANA considerations section, only
adding items to existing registries.
sid has some real innovations in the interactions with IANA, which
were the result of extensive interactions between IANA and the
authors and WG chairs.

> (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

sid creates the "YANG SID Mega-Range" registry, the "IETF YANG SID
Range" registry, and the "IETF YANG SID Registry".  All require Expert
Review, both with respect to properly curating a somewhat limited
resource, and with respect to technical soundness of the registrations.

> (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

sid defines a YANG module ietf-sid-file that passes the validation
provided by the datatracker.
yang-cbor contains a single line of ABNF using a production from RFC
Pu7950, which validates with "bap".
yang-cbor also contains many snippets of YANG that have been
eyeball-verified only.

> (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

sid defines a YANG module ietf-sid-file that passes the validation
provided by the datatracker.
This YANG module does not define a datastore, so NMDA does not apply.

Request for posting confirmation emailed to previous authors: core-chairs@ietf.org, Ana Minaburo , Alexander Pelov , Michel Veillette , Ivaylo Petrov , Randy Turner , Abhinav Somaraju