YANG Schema Item iDentifier (YANG SID)
draft-ietf-core-sid-24

[Ballot comment]
You can regard all of these comments as non-blocking (against -23):

1. I think that the security reference to "The security and privacy considerations in Sections 5 and 6 of [I-D.bormann-t2trg-deref-id] apply." is somewhat dubious, since it would create a normative reference and block this doc and we don't know what they will eventually say.  Perhaps change this text to make this a softer recommendation, i.e., rather than they saying that they apply, say something like "please also see I-D.bormann-t2trg-deref-id for further considerations that may be applicable"?  This may then allow it the reference to bormann-t2trg-deref-id to be informational rather than normative (but I've not checked other usages).

2. The type-1, type-2, type-3 developers are not referenced very much in the doc, and I wonder whether referencing by name wouldn't be more helpful for most readers, e.g., SID-guiding, SID-oblivious, SID-aware).

3. The text in section 6.4.3, seems to be mostly written about drafts that are creating new YANG modules, and hence allocating new SID files.  There doesn't appear to be any text about new revisions of existing published YANG modules that would presumably also need to take into account any previously published SID file for that module previously published in IANA.

Regards,
Rob

[Ballot comment]
# GEN AD review of draft-ietf-core-sid-22

CC @larseggert

Thanks to Linda Dunbar for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/8dB4NrBDoGCKILyz2wvtvT6sqC0).

## Comments

### Section 6.3.3, paragraph 3
```
    The initial entry in this registry is allocated to IANA:

    +=============+=========+============+===================+==========+
    | Entry Point | Size    | Allocation | Organization      | URL      |
    |            |        |            | name              |          |
    +=============+=========+============+===================+==========+
    | 0          | 1000000 | Public    | IANA              | iana.org |
    +-------------+---------+------------+-------------------+----------+
```
I would have expected the initial allocation to IANA (and the regions
defined within) to be MUCH larger, given the overall size of the
namespace.

### Section 6.4.2, paragraph 11
```
    +=============+=========+==========================+
    | Entry Point | Size    | IANA policy              |
    +=============+=========+==========================+
    | 0          | 1,000  | IESG Approval            |
    +-------------+---------+--------------------------+
    | 1,000      | 59,000  | RFC Required            |
    +-------------+---------+--------------------------+
    | 60,000      | 40,000  | Experimental/Private use |
    +-------------+---------+--------------------------+
    | 100,000    | 900,000 | Reserved                |
    +-------------+---------+--------------------------+
```
These seem very small as well, given the overall size of the namespace.

### Section 6.5.1, paragraph 3
```
    *  The link to the ".sid" file which defines the allocation.  The
        ".sid" file is stored by IANA.
```
See above, unclear if IANA is able to host files.

### Section 6.5.3, paragraph 9
```
    Early Allocations are made with a one-year period, after which they
    need to be renewed or will expire.
```
In practice, that one year is too short and is already creating
frequent IESG management items for extension approvals. Given the
many more early allocations, this process will require, this will be
disruptive for the IESG.

## Nits

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.

### Boilerplate

Document still refers to the "Simplified BSD License", which was corrected in
the TLP on September 21, 2021. It should instead refer to the "Revised BSD
License".

### Uncited references

Uncited references: `[RFC8792]`.

### Grammar/style

#### Section 2.1, paragraph 6
```
: the SID management system is independent from any module versioning. 2.3. S
                              ^^^^^^^^^^^^^^^^
```
The usual collocation for "independent" is "of", not "from". Did you mean
"independent of"?

#### Section 3, paragraph 1
```
ANG module is optional but recommended to promote interoperability between d
                          ^^^^^^^^^^^^^^^^^^^^^^
```
The verb "recommended" is used with the gerund form.

#### Section 3, paragraph 3
```
s imported module(s) or included sub-module(s) is updated, a new ".sid" file
                                ^^^^^^^^^^
```
This word is normally spelled as one.

#### Section 5, paragraph 1
```
million SIDs assigned to IANA is sub-divided as follows: * The range of 0 to
                                  ^^^^^^^^^^^
```
This word is normally spelled as one.

#### Section 6.4.4, paragraph 2
```
iption, and will be cross-posted to the any other working group mailing lists
                                    ^^^^^^^
```
There appears to be a superfluous article here.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot comment]
(ballot revised based on telechat discussions; revised again after IESG Discussion at IETF 118)

When initially balloting as DISCUSS, I had hesitation about treating SID files differently than the YANG modules (i.e., would be end up with a clear technical specification).  After publication of the RFC, the former only lives in the IANA registry while the latter stays in the RFC and also goes into an IANA registry.  For new documents (that will include a YANG file and SID file), I believe there should consistency on how these models are handled.

In the IESG Review discussion (thanks Carsten Bormann and Rob Wilton), I heard that perhaps YANG modules should never have been put into the RFCs to begin with.  However, no wholistic approach currently exists to remedy this arrangement.  I also heard the need for a workflow of creating SID files for already published RFCs without making a substantial number of -bis documents or one massive RFC update.  Thanks for that perspective.  I’ve cleared based on this second issue.



====
** Section 2.4
    Objective 2 requires
      that there is only one SID assigner for each module.

While neither Objective 2 or this text uses formal normative language, by my read, Objective 2 does not “require” anything.  It suggests since (“SHOULD”) is used.

** Section 2.4  Editorial.  The text goes through the trouble of introducing “type-1”, “type-2”, etc.  However, this taxonomy is not used later in the document.  Is it needed?

** Section 5. The Security Considerations helpfully point out the criticality of retrieving the SID files from an authoritative source.  How would that work for an entity outside of the IETF?  The requirements of a “mega-range” allocations include a few requirements, but nothing explicitly says distribution of SID files.  Could something be said?

** Section 5. 
  Conceptually, SID files could be processed by less-constrained target
  systems such as network management systems.  Such systems need to
  take extra care to make sure that they are only processing SID files
  from authoritative sources, as authoritative as the YANG modules that
  they are using.

Thanks for flagging this as a security consideration.  Rob Wilton also mentioned it in his ballot.  I’m a puzzled by this use case.  Is this suggesting that “less constrained … systems” would download SID files based on some kind of real-time input?  If so, this seems highly problematic because (a) it could leak information to an outside party; and (b) seems like it could cause a DDoS on the distributor of the SID files or even the system itself (depending on the caching strategy).
Is the use case here that the SID file would be distributed “offline” by the system vendor or operator through configuration making it more akin to the developer use case mentioned previously?  I appreciate that CBOR is intended to be self-describing, but I’m not sure how a network management system would be parsing arbitrary formats.

** Section 6.3.3.  “iana.org” is provided as a URL for IANA, but that value is technically not a valid URL (as it is missing a schema).

** Section 6.5.3
  After Working Group Adoption, any modification of a ".sid" file is
  expected to be discussed on the mailing list of the appropriate
  Working Groups.  Specific attention should be paid to implementers'
  opinion after Working Group Last Call if a SID value is to change its
  meaning.  In all cases, a ".sid" file and the SIDs associated with it
  are subject to change before the publication of an internet draft as
  an RFC.

This text is here to bring clarity to an important issue, but it isn’t clear to me what it is.  The text appears to be describing what is true for any significant change to a WG document.

** Section 6.5.3
  Due to the difficulty in changing SID values during IETF document
  processing, it is expected that most documents will ask for SID
  allocations using Early Allocations [BCP100].  The details of the
  Early Allocation should be included in any Working Group Adoption
  call.
...
  In all cases, a ".sid" file and the SIDs associated with it
  are subject to change before the publication of an internet draft as
  an RFC.

-- I have no experience with early allocation of an IANA code point happening concurrent with a WG adoption of a document.  Is that common? 

-- What difficulty is expected in changing SID values? 

-- Why is early allocation happening if the draft is not stable (which seems unlikely at adoption time)?

[Ballot discuss]
** Section 6.4.3

  The ".sid" file MUST NOT be published as part of the RFC: the IANA
  Registry is authoritative and a link is to be inserted in the RFC.

Can the basis for this decision be explained.  Why isn't the authoritative source of the SID's coming from the RFC?

[Ballot comment]
(ballot revised based on telechat discussions)

** Section 2.4
    Objective 2 requires
      that there is only one SID assigner for each module.

While neither Objective 2 or this text uses formal normative language, by my read, Objective 2 does not “require” anything.  It suggests since (“SHOULD”) is used.

** Section 2.4  Editorial.  The text goes through the trouble of introducing “type-1”, “type-2”, etc.  However, this taxonomy is not used later in the document.  Is it needed?

** Section 5. The Security Considerations helpfully point out the criticality of retrieving the SID files from an authoritative source.  How would that work for an entity outside of the IETF?  The requirements of a “mega-range” allocations include a few requirements, but nothing explicitly says distribution of SID files.  Could something be said?

** Section 5. 
  Conceptually, SID files could be processed by less-constrained target
  systems such as network management systems.  Such systems need to
  take extra care to make sure that they are only processing SID files
  from authoritative sources, as authoritative as the YANG modules that
  they are using.

Thanks for flagging this as a security consideration.  Rob Wilton also mentioned it in his ballot.  I’m a puzzled by this use case.  Is this suggesting that “less constrained … systems” would download SID files based on some kind of real-time input?  If so, this seems highly problematic because (a) it could leak information to an outside party; and (b) seems like it could cause a DDoS on the distributor of the SID files or even the system itself (depending on the caching strategy).
Is the use case here that the SID file would be distributed “offline” by the system vendor or operator through configuration making it more akin to the developer use case mentioned previously?  I appreciate that CBOR is intended to be self-describing, but I’m not sure how a network management system would be parsing arbitrary formats.

** Section 6.3.3.  “iana.org” is provided as a URL for IANA, but that value is technically not a valid URL (as it is missing a schema).

** Section 6.5.3
  After Working Group Adoption, any modification of a ".sid" file is
  expected to be discussed on the mailing list of the appropriate
  Working Groups.  Specific attention should be paid to implementers'
  opinion after Working Group Last Call if a SID value is to change its
  meaning.  In all cases, a ".sid" file and the SIDs associated with it
  are subject to change before the publication of an internet draft as
  an RFC.

This text is here to bring clarity to an important issue, but it isn’t clear to me what it is.  The text appears to be describing what is true for any significant change to a WG document.

** Section 6.5.3
  Due to the difficulty in changing SID values during IETF document
  processing, it is expected that most documents will ask for SID
  allocations using Early Allocations [BCP100].  The details of the
  Early Allocation should be included in any Working Group Adoption
  call.
...
  In all cases, a ".sid" file and the SIDs associated with it
  are subject to change before the publication of an internet draft as
  an RFC.

-- I have no experience with early allocation of an IANA code point happening concurrent with a WG adoption of a document.  Is that common? 

-- What difficulty is expected in changing SID values? 

-- Why is early allocation happening if the draft is not stable (which seems unlikely at adoption time)?

[Ballot discuss]
# GEN AD review of draft-ietf-core-sid-22

CC @larseggert

Thanks to Linda Dunbar for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/8dB4NrBDoGCKILyz2wvtvT6sqC0).

## Discuss

### Section 6.4.3, paragraph 4
```
    The designated experts then give the SID file to IANA to publish into
    the YANG SID Registry (Section 6.5) along with the YANG module.
```
Is there a precedent for IANA to be a file hoster? Is IANA prepared to
do this?

### Section 6.5.1, paragraph 4
```
    *  A link to the associated ".yang" file.  This file link must be
        present in the "File" column of the "YANG Module Names" registry.
```
Who is hosting these YANG files? Is IANA required to check that they
remain available (i.e., mirror them?)

### Section 6.5.3, paragraph 3
```
    After Working Group Adoption, any modification of a ".sid" file is
    expected to be discussed on the mailing list of the appropriate
    Working Groups.  Specific attention should be paid to implementers'
    opinion after Working Group Last Call if a SID value is to change its
    meaning.  In all cases, a ".sid" file and the SIDs associated with it
    are subject to change before the publication of an internet draft as
    an RFC.
```
So IANA is not only hosting immutable files, they are also supposed to
support (frequent?) changes if these files. Unsure if IANA is set up
for this.

[Ballot comment]
## Comments

### Section 6.3.3, paragraph 3
```
    The initial entry in this registry is allocated to IANA:

    +=============+=========+============+===================+==========+
    | Entry Point | Size    | Allocation | Organization      | URL      |
    |            |        |            | name              |          |
    +=============+=========+============+===================+==========+
    | 0          | 1000000 | Public    | IANA              | iana.org |
    +-------------+---------+------------+-------------------+----------+
```
I would have expected the initial allocation to IANA (and the regions
defined within) to be MUCH larger, given the overall size of the
namespace.

### Section 6.4.2, paragraph 11
```
    +=============+=========+==========================+
    | Entry Point | Size    | IANA policy              |
    +=============+=========+==========================+
    | 0          | 1,000  | IESG Approval            |
    +-------------+---------+--------------------------+
    | 1,000      | 59,000  | RFC Required            |
    +-------------+---------+--------------------------+
    | 60,000      | 40,000  | Experimental/Private use |
    +-------------+---------+--------------------------+
    | 100,000    | 900,000 | Reserved                |
    +-------------+---------+--------------------------+
```
These seem very small as well, given the overall size of the namespace.

### Section 6.5.1, paragraph 3
```
    *  The link to the ".sid" file which defines the allocation.  The
        ".sid" file is stored by IANA.
```
See above, unclear if IANA is able to host files.

### Section 6.5.3, paragraph 9
```
    Early Allocations are made with a one-year period, after which they
    need to be renewed or will expire.
```
In practice, that one year is too short and is already creating
frequent IESG management items for extension approvals. Given the
many more early allocations, this process will require, this will be
disruptive for the IESG.

## Nits

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.

### Boilerplate

Document still refers to the "Simplified BSD License", which was corrected in
the TLP on September 21, 2021. It should instead refer to the "Revised BSD
License".

### Uncited references

Uncited references: `[RFC8792]`.

### Grammar/style

#### Section 2.1, paragraph 6
```
: the SID management system is independent from any module versioning. 2.3. S
                              ^^^^^^^^^^^^^^^^
```
The usual collocation for "independent" is "of", not "from". Did you mean
"independent of"?

#### Section 3, paragraph 1
```
ANG module is optional but recommended to promote interoperability between d
                          ^^^^^^^^^^^^^^^^^^^^^^
```
The verb "recommended" is used with the gerund form.

#### Section 3, paragraph 3
```
s imported module(s) or included sub-module(s) is updated, a new ".sid" file
                                ^^^^^^^^^^
```
This word is normally spelled as one.

#### Section 5, paragraph 1
```
million SIDs assigned to IANA is sub-divided as follows: * The range of 0 to
                                  ^^^^^^^^^^^
```
This word is normally spelled as one.

#### Section 6.4.4, paragraph 2
```
iption, and will be cross-posted to the any other working group mailing lists
                                    ^^^^^^^
```
There appears to be a superfluous article here.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-shmoo-hackathon-07

Thank you for the work put into this document. I still have fond memories about this document when I was its shepherding AD for a while (replacing Francesca during her leave) ;-)

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Jaime Jimenez for the *refreshed* shepherd's detailed write-up including the WG consensus even of the justification of the intended status could be more detailed.

Other thanks to Stephen Farrell, the IoT directorate reviewer (at my request), please consider this IoT-dir review:
https://datatracker.ietf.org/doc/review-ietf-core-sid-21-iotdir-telechat-farrell-2023-10-06/ (thanks for the follow-up email messages on the use of the overloaded term 'identities')

Other thanks to Brian Haberman, the Internet directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-core-sid-21-intdir-telechat-haberman-2023-10-13/ (and the SID collision is indeed unfortunate)

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS

## Intended status

While I do like the intent of this draft, I am only uneasy about the intended status of "proposed standard", many mechanisms may face issues when put in real live: from global SID meta-range assignments to SID generation and use. Having an 'experimental' status would probably be better suited (and there is nothing wrong about an experimental I-D).

## YangCatalog.Org

As the previous YC.O liaison, please note that YC.O development efforts have culminated and there won't be any new features added to YC.O in the foreseeable future. I.e., even if there were plans 2-3-4 years ago to add SID features, this time has passed as this I-D was not published as a RFC. I.e., do not rely on YC.O.

## Section 1

`At the time of writing,` this won't age well. Please state "2023" or something similar.

What is meant by `Once considered "stable"` ? This should be defined here or a forward reference to section 3 added.

## Section 2.1

`immutably maps to EXACTLY one YANG name` what about the same YANG name but in a different revision ? AFAIK CBOR favours adjacent integers when doing compression, i.e., the same YANG name in different YANG module revision should not be immutable for compression sake. The text goes further on this topic. Moreover, AFAIK, a YANG name may change of type among revisions and may break interoperation (there is a good reason why YANG modules have a revision tag).

## Section 2.2

`objective 3* (MUST):  the SID management system is independent from any module versioning.` see my comment above.

## Section 2.4

The types 1-2-3 could be better presented by defining them one by one rather than being distributed into several paragraphs.

## Section 3

What is meant by 'final' in `When the specification is advanced to a final document` ?

## Section 6.4.3

Thanks for updating this section from -21 to -22 (probably based on Rob Wilton's review). It is much clearer albeit I do not like too much the use of the term "team" in an IETF document (matter of taste -- no need to reply).

Now, this is also a drastic change in the I-D IMHO, should it go through another IETF Last Call ? I will trust the responsible AD on this topic.

## References

RFC 8792 should probably be normative as it is required to understand the appendix.

[Ballot comment]
Focusing again on Section 6 (IANA Considerations), which has got to be the most complex one I've ever seen:

* Please don't use BCP 14 keywords here, as this section isn't the place to discuss interoperability.  Lowercasing the ones you have should be fine.

* In 6.3.1, why is "policy of SID range" considered part of "contact information"?

* In 6.3.2, seems to me the first and last bullets both talk about sustainable operation and could be merged.

* Also in 6.3.2, how do you imagine the designated expert evaluating "technical capacity" to operate a registry?  I note that Robert raised a similar concern.

* Sections 6.4 and 6.5 create registries that are going to be complicated for the Designated Expert to work, and for the DE to present to the IESG proof that the process was followed if asked.  I have to trust that all this complexity is necessary.

* In 6.5.1, by "link", do you mean a URI?

[Ballot comment]
** Section 2.4
    Objective 2 requires
      that there is only one SID assigner for each module.

While neither Objective 2 or this text uses formal normative language, by my read, Objective 2 does not “require” anything.  It suggests since (“SHOULD”) is used.

** Section 2.4  Editorial.  The text goes through the trouble of introducing “type-1”, “type-2”, etc.  However, this taxonomy is not used later in the document.  Is it needed?

** Section 5. The Security Considerations helpfully point out the criticality of retrieving the SID files from an authoritative source.  How would that work for an entity outside of the IETF?  The requirements of a “mega-range” allocations include a few requirements, but nothing explicitly says distribution of SID files.  Could something be said?

** Section 5. 
  Conceptually, SID files could be processed by less-constrained target
  systems such as network management systems.  Such systems need to
  take extra care to make sure that they are only processing SID files
  from authoritative sources, as authoritative as the YANG modules that
  they are using.

Thanks for flagging this as a security consideration.  Rob Wilton also mentioned it in his ballot.  I’m a puzzled by this use case.  Is this suggesting that “less constrained … systems” would download SID files based on some kind of real-time input?  If so, this seems highly problematic because (a) it could leak information to an outside party; and (b) seems like it could cause a DDoS on the distributor of the SID files or even the system itself (depending on the caching strategy).
Is the use case here that the SID file would be distributed “offline” by the system vendor or operator through configuration making it more akin to the developer use case mentioned previously?  I appreciate that CBOR is intended to be self-describing, but I’m not sure how a network management system would be parsing arbitrary formats.

** Section 6.3.3.  “iana.org” is provided as a URL for IANA, but that value is technically not a valid URL (as it is missing a schema).

** Section 6.5.3
  After Working Group Adoption, any modification of a ".sid" file is
  expected to be discussed on the mailing list of the appropriate
  Working Groups.  Specific attention should be paid to implementers'
  opinion after Working Group Last Call if a SID value is to change its
  meaning.  In all cases, a ".sid" file and the SIDs associated with it
  are subject to change before the publication of an internet draft as
  an RFC.

This text is here to bring clarity to an important issue, but it isn’t clear to me what it is.  The text appears to be describing what is true for any significant change to a WG document.

** Section 6.5.3
  Due to the difficulty in changing SID values during IETF document
  processing, it is expected that most documents will ask for SID
  allocations using Early Allocations [BCP100].  The details of the
  Early Allocation should be included in any Working Group Adoption
  call.
...
  In all cases, a ".sid" file and the SIDs associated with it
  are subject to change before the publication of an internet draft as
  an RFC.

-- I have no experience with early allocation of an IANA code point happening concurrent with a WG adoption of a document.  Is that common? 

-- What difficulty is expected in changing SID values? 

-- Why is early allocation happening if the draft is not stable (which seems unlikely at adoption time)?

[Ballot comment]
The document states that SIDs for a name can never change, but then introduces
"unstable SIDs" that do exactly that. It specifies SIDs can also be "withdrawn"
which again goes against the Objectives carefully laid out earlier. Possibly
the text can be made more clear and consistent with this respect?

Are the Editor: contacts neccessary? These are all email addresses of people
at their dayjob, which are likely to be invalid within a few years.

        Once a module is declared stable

Where is this process described? I see no normative reference for this.
Without that, I cannot understand the process. Who or what defines a
module to be stable?

        While IANA ultimately maintains the registries that
        govern SIDs for IETF-defined modules, various support
        tools such as yangcatalog.org need to provide the support
        to enable SID assignment and use for modules still in
        IETF development. Developers of open-source or proprietary
        YANG modules also need to be able to serve as such entities
        autonomously, possibly forming alliances independent of the IETF,
        while still fitting in the overall SID number space managed by
        IANA. Obviously, this process has a number of parallels to the
        management of IP addresses, but also is very different.

Does this text really belong in an RFC? For example the note the use of
yangcatalog.org without it even being a reference? It would be best if the
goal of this text was met by whatever IANA registration page text would
be created.

        like ships in the night.

Replace this text with something international readers understand. I don't
think I understand this.

[Ballot discuss]
Hi authors,

Apologies for putting yet another discuss on this document - I promise that I support it and want to see it published - but there are a couple of process related aspects for creating/managing SID files in drafts that I want to ensure that the IESG is at very least aware of and happy with.

(1) p 23, sec 6.4.3.  Publication of the ".sid" file

  For a YANG module approved for publication as an RFC, a ".sid" file
  SHOULD be included in the Internet-Draft as a source code block.

I'm wondering if this is really the best approach.  I.e., I think to guarantee that the SID file is correct at the point of pulication (e.g., if names of YANG data nodes are changed using IESG review or later) will probably require the RFC-Editor (or IANA) to run some tooling to regenerate it and ensure that it is correct.  Hence for YANG modules that are not being directly used in constrained environments then would it be better to ask IANA (if they are willing, and if the tooling is easy) to generate it during AUTH-48?  Note, this discussion will presumably require IANA's input.


(2) p 27, sec 6.5.3.  Recursive Allocation of YANG SID Range at Document Adoption

  *  If the document is a published RFC, then the allocation of SIDs
      for its referenced YANG modules is permanent.  The Expert Reviewer
      provides the generated ".sid" file to IANA for registration.  This
      process may be time-consuming during a bootstrap period (there are
      over 100 YANG modules to date, none of which have SID
      allocations), but should quiet down once needed entries are
      allocated.

Would it not be easier just to go through all the published RFCs containing YANG modules and allocate SID files for them?

[Ballot comment]
You can regard all of these comments as non-blocking:


Minor level comments:

(3) p 4, sec 1.1.  Terminology and Notation

  *  schema-node path: A schema-node path is a string that identifies a
      schema node within the schema tree.  A path consists of the list
      of consecutive schema node identifier(s) separated by slashes
      ("/").  Schema node identifier(s) are always listed from the top-
      level schema node up to the targeted schema node and could contain
      namespace information. (e.g. "/ietf-system:system-state/clock/
      current-datetime")

BTW, is this definition the same or different to "6.5 Schema Node Identifier in RFC 7950"?


(4) p 15, sec 4.  ".sid" file format

        description
          "Information about the used revision during the .sid file
          generation of each YANG module that the module in
          'module-name' imported.";

"revision used" rather than "used revision"?


(5) p 15, sec 4.  ".sid" file format

        description
          "Information about the used revision during the .sid file
          generation of each YANG module that the module in
          'module-name' imported.";

I suspect that this will potentially introduce an itneresting case in the future where updating the grouping in an imported module will need the SID files for all the importing SID files that use that grouping to be regenerated.  "sid-file-version" would seem to handle this case nicely.


(6) p 19, sec 5.  Security Considerations

  Conceptually, SID files could be processed by less-constrained target
  systems such as network management systems.  Such systems need to
  take extra care to make sure that they are only processing SID files
  from authoritative sources, as authoritative as the YANG modules that
  they are using.

As a minor comment, and I'll leave it to the SEC ADs to decide whether they think that this may be issue, but I wonder if there is a small privacy consideration here that may be worth documenting?  E.g., if SID files were fetched dynamically rather than by being fetched offline by a developer or being cached locally, then there is a possibility that tracking which SID files are being requested may indirectly leak information about which models are being used.


(7) p 21, sec 6.3.2.  Allocation policy

  *  Technical capacity to ensure the sustained operation of the
      registry for a period of at least 5 years.  If Private
      Registrations are allowed, the period must be of at least 10
      years.

This criteria may be hard to evaluate.  E.g., if a startup company was to ask for a mega-range then would it be refused because they may go bust?


(8) p 41, sec Appendix B.  SID auto generation

  Note also that RPC or action "input" and "output" data nodes MUST
  always be assigned SID even if they don't contain data nodes.  The
  reason for this requirement is that other modules can augment the
  given module and those SIDs might be necessary.

Do you mean "data node" here or "schema node".  Specifically, the "input" and "output" nodes themselves are not data nodes because they don't appear in the data tree.  I wasn't quite sure what your use case was that needed these.


(9) p 43, sec Appendix C.  ".sid" file lifecycle

                      Figure 4: SID Lifecycle

Your SID lifecycle had "Open specification" being added to the IANA registry for SID files, but your IANA policy in 6.4.2 is effectively RFC required, and doesn't obviously allow for stable allocation for modules not defined in RFCs.



Nit level comments:

(10) p 18, sec 4.  ".sid" file format

            If the corresponding 'namespace' field is 'data',
            then this field MUST contain a valid schema node
            path.";
        }

"schema node path" => "schema-node path"?

Regards,
Rob

[Ballot comment]
After substantive changes were made in response to IESG Review (Rob's DISCUSS), this document was sent back to the working group, undergoing a second WG LC and IETF LC to confirm consensus.  It is returning to the IESG for a second review and prior ballot positions have been cleared.  Please see the History tab for your previous comments.

I see no reason not to approve the namespace, but I do have issues:

People defining a new file type should define a new (MIME) media type. I don't see any reason that this ".sid" format would be exempt.

Also, a nit: this document appears to use GOAT, which makes a horrible mess of SVG. I recommend aasvg as a drop-in replacement.

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

IANA has completed its review of draft-ietf-core-sid-21. IANA had also previously reviewed draft-ietf-core-sid-15 during a prior Last Call. If any part of this review is inaccurate, please let us know.

IANA has questions about the third, fourth, and fifth actions requested in the IANA Considerations section of this document.

We understand that, upon approval of this document, there are five actions which we must complete.

First, in the ns registry in the "IETF XML Registry" group located at:

https://www.iana.org/assignments/xml-registry/

a single new namespace will be registered as follows:

ID: yang:ietf-sid-file
URI: urn:ietf:params:xml:ns:yang:ietf-sid-file
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, in the YANG Module Names registry in the YANG Parameters registry group located at:

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

a single new YANG module will be registered as follows:

Name: ietf-sid-file
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-sid-file
Prefix: sid
Module:
Reference: [ RFC-to-be ]

While the YANG module name will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published.

Third, a new registry is to be created called the YANG SID Mega-Range registry.

IANA Question --> Where should this new registry be located? Should it be added to an existing registry group? If it needs a new registry group, does it also need a new category at http://www.iana.org/protocols (and if so, should the registry group and the category have the same name)?

The new registry will be managed via Expert Review as defined in RFC8126.

There is a single initial registration in the new registry as follows:

Entry Point Size Allocation Organization name URL Reference
-----------+---+----------+------------------+---+-------------
0 1000000 Public IANA iana.org [ RFC-to-be ]

Fourth, a new registry is to be created called the IETF YANG SID Range Registry.

IANA Question --> As before, where should this new registry be located? Should it be added to an existing registry group? If it needs a new registry group, does it also need a new category at http://www.iana.org/protocols (and if so, should the registry group and the category have the same name)?

IANA Question --> When IANA looks at the registration policy for this registry the text seems inconsistent with the information in the table (Table 3). For the range range of 1000 to 59,999 (size 59,000) it seems that the table is correct because an RFC is required in all registration cases. It seems to us that the "Expert Review" that comes in the text is an after-the-fact processing requirement for the Designated Expert. On our reading we believe the table is correct: "RFC Required" is correct for this range. It also occurs to us that the table still says that the IANA policy for the range of 60,000 to 99,999 (size 40,000) is Experimental/Private use. IANA is aware that the authors has had extensive discussions on this topic and we believe that the text is correct. Can the table be changed to match the text above?

There are initial entries in this new registry as follows:

Entry
Point Size Module Name Reference
----+----+--------------+------------
0 1 (Reserved: not a valid SID) [ RFC-to-be ]
1000 100 ietf-coreconf [I-D.ietf-core-comi]
1100 50 ietf-yang-types [RFC6991]
1150 50 ietf-inet-types [RFC6991]
1200 50 iana-crypt-hash [RFC7317]
1250 50 ietf-netconf-acm [RFC8341]
1300 50 ietf-sid-file [ RFC-to-be ]
1500 100 ietf-interfaces [RFC8343]
1600 100 ietf-ip [RFC8344]
1700 100 ietf-system [RFC7317]
1800 400 iana-if-type [RFC7224]
2400 50 ietf-voucher [RFC8366]
2450 50 ietf-constrained-voucher [I-D.ietf-anima-constrained-voucher]
2500 50 ietf-constrained-voucher-request[I-D.ietf-anima-constrained-voucher]

Fifth, a new registry is to be created called the IETF YANG SID registry.

IANA Question --> As before, where should this new registry be located? Should it be added to an existing registry group? If it needs a new registry group, does it also need a new category at http://www.iana.org/protocols (and if so, should the registry group and the category have the same name)?

The allocation policy for the new registry is Expert Review as defined by RFC 8126.

Each entry in this registry must include:

- The YANG module name. This module name must be present in the "Name" column of the "YANG Module Names" registry.
- A link to the associated ".yang" file. This file link must be present in the "File" column of the "YANG Module Names" registry.
- The link to the ".sid" file which defines the allocation. The ".sid" file is stored by IANA.
- The number of actually allocated SIDs in the ".sid" file.

At the time of initial creation of the registry, its contents will be empty.

We understand 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.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2023-10-16):

From: The IESG
To: IETF-Announce
CC: Carsten Bormann , core-chairs@ietf.org, core@ietf.org, draft-ietf-core-sid@ietf.org, francesca.palombini@ericsson.com, jaime@iki.fi
Reply-To: last-call@ietf.org
Sender:
Subject: Second Last Call:  (YANG Schema Item iDentifier (YANG SID)) to Proposed Standard

Following a first Last Call and following IESG evaluation, the document has seen substantial modifications.  As a result, a supplementary Last Call is being issue before allowing the document to continue toward publication.

The IESG has received a request from the Constrained RESTful Environments WG
(core) to consider the following document: - 'YANG Schema Item iDentifier
(YANG SID)'
  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 2023-10-16. 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


  YANG Schema Item iDentifiers (YANG SID) are globally unique 63-bit
  unsigned integers used to identify YANG items, as a more compact
  method to identify YANG items that can be used for efficiency and in
  constrained environments (RFC 7228).  This document defines the
  semantics, the registration, and assignment processes of YANG SIDs
  for IETF managed YANG modules.  To enable the implementation of these
  processes, this document also defines a file format used to persist
  and publish assigned YANG SIDs.



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



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

Document Writeup for Working Group Documents

--------------
Changes for draft-ietf-core-sid-21

Technical Summary:

The task remaining is to extract identifiers from the YANG document based on an enhanced understanding of YANG.
The document was missing an RPC example which has now been added.

draft-ietf-core-yang-cbor is RFC 9254 now.

Working Group Summary:

The document went through many changes during IESG review, therefore a new WGLC was done and the document was moved back to the WG.

Document Quality:

There were updates to the PYANG tool and there was a need to make sure that all the data node identifiers that the document contains are listed.
The SID file in the document was updated manually with respect to the one generated by PYANG, and we don’t want to do that for each of the SID files.

Reviews and automated checks performed by the Document Shepherd:

There were issues with the YANG toolscape and the need for updates to the PYANG tool.

IPR disclosures:

No IPR was raised at the moment. There might be cases where specific processes are needed for SID allocations, for example, LPWAN people needing more control over SID allocations.

New IANA registries:

There were questions from IANA differentiating private and experimental use, synchronization points, and versioning.
As per IANA process, since there is a new version, there will be a need for a new IANA review.

--------------

This is the write for the CORECONF document draft-ietf-core-sid-15 released on 2021-01-17.

> (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-yang-cbor, 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-yang-cbor 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-yang-cbor together provide the foundation to extend YANG-based management down to constrained devices (RFC 7228).

In particular, the present document defines 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, the document also defines a file format used to persist and publish assigned YANG SIDs.
 
The companion document draft-ietf-core-yang-cbor 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 October 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 also is a co-author of the draft-ietf-core-comi specification using the present document and the companion document draft-ietf-core-yang-cbor.

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:

Document Shepherd: Jaime Jiménez
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.

The YANG module ietf-sid-file 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?

This document has a normative reference to the other CORECONF document draft-ietf-core-yang-cbor. Also, it has informative references to the other CORECONF documents draft-ietf-core-comi and draft-ietf-core-yang-library.

> (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 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.

This document 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.

This document defines a YANG module ietf-sid-file that passes the validation provided by the datatracker.

> (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?

This document 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

--------------
Changes for draft-ietf-core-sid-21

Technical Summary:

The task remaining is to extract identifiers from the YANG document based on an enhanced understanding of YANG.
The document was missing an RPC example which has now been added.

draft-ietf-core-yang-cbor is RFC 9254 now.

Working Group Summary:

The document went through many changes during IESG review, therefore a new WGLC was done and the document was moved back to the WG.

Document Quality:

There were updates to the PYANG tool and there was a need to make sure that all the data node identifiers that the document contains are listed.
The SID file in the document was updated manually with respect to the one generated by PYANG, and we don’t want to do that for each of the SID files.

Reviews and automated checks performed by the Document Shepherd:

There were issues with the YANG toolscape and the need for updates to the PYANG tool.

IPR disclosures:

No IPR was raised at the moment. There might be cases where specific processes are needed for SID allocations, for example, LPWAN people needing more control over SID allocations.

New IANA registries:

There were questions from IANA differentiating private and experimental use, synchronization points, and versioning.
As per IANA process, since there is a new version, there will be a need for a new IANA review.

--------------

This is the write for the CORECONF document draft-ietf-core-sid-15 released on 2021-01-17.

> (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-yang-cbor, 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-yang-cbor 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-yang-cbor together provide the foundation to extend YANG-based management down to constrained devices (RFC 7228).

In particular, the present document defines 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, the document also defines a file format used to persist and publish assigned YANG SIDs.
 
The companion document draft-ietf-core-yang-cbor 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 October 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 also is a co-author of the draft-ietf-core-comi specification using the present document and the companion document draft-ietf-core-yang-cbor.

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:

Document Shepherd: Jaime Jiménez
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.

The YANG module ietf-sid-file 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?

This document has a normative reference to the other CORECONF document draft-ietf-core-yang-cbor. Also, it has informative references to the other CORECONF documents draft-ietf-core-comi and draft-ietf-core-yang-library.

> (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 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.

This document 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.

This document defines a YANG module ietf-sid-file that passes the validation provided by the datatracker.

> (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?

This document 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

--------------
Changes for draft-ietf-core-sid-21

Technical Summary:

The task remaining is to extract identifiers from the YANG document based on an enhanced understanding of YANG.
The document was missing an RPC example which has now been added.

Working Group Summary:

The document went through many changes during IESG review, therefore a new WGLC was done and the document was moved back to the WG.

Document Quality:

There were updates to the PYANG tool and there was a need to make sure that all the data node identifiers that the document contains are listed.

Reviews and automated checks performed by the Document Shepherd:

There were issues with the YANG toolscape and the need for updates to the PYANG tool.

IPR disclosures:

No IPR was raised at the moment. There might be cases where specific processes are needed for SID allocations, for example, LPWAN people needing more control over SID allocations.

New IANA registries:

There were questions from IANA differentiating private and experimental use, synchronization points, and versioning.
As per IANA process, since there is a new version, there will be a need for a new IANA review.

--------------

This is the write for the CORECONF document draft-ietf-core-sid-15 released on 2021-01-17.

> (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-yang-cbor, 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-yang-cbor 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-yang-cbor together provide the foundation to extend YANG-based management down to constrained devices (RFC 7228).

In particular, the present document defines 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, the document also defines a file format used to persist and publish assigned YANG SIDs.
 
The companion document draft-ietf-core-yang-cbor 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 October 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 also is a co-author of the draft-ietf-core-comi specification using the present document and the companion document draft-ietf-core-yang-cbor.

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:

Document Shepherd: Jaime Jiménez
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.

The YANG module ietf-sid-file 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?

This document has a normative reference to the other CORECONF document draft-ietf-core-yang-cbor. Also, it has informative references to the other CORECONF documents draft-ietf-core-comi and draft-ietf-core-yang-library.

> (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 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.

This document 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.

This document defines a YANG module ietf-sid-file that passes the validation provided by the datatracker.

> (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?

This document 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.

After discussion with the CORE WG chairs and authors of the core-sid draft, let's follow the process and send the I-D to the CORE WG to allow for the 2nd WGLC after important modifications to the document.

After discussion with the CORE WG chairs and authors of the core-sid draft, let's follow the process and send the I-D to the CORE WG to allow for the 2nd WGLC after important modifications to the document.

[Ballot discuss]
Updated position for -20 (just for my tracking):

(1) p 9, sec 3.  ".sid" file lifecycle

                                              When the specification is
  advanced to a final document, then status of the assignment is marked
  with the module-revision (a YYYY-MM-DD) when the assignment is
  finalized.

This text wasn't clear to me, since I interpreted this as a per SID module-revision, but the YANG module doesn't include such a field.  Was this idea dropped, or is the assignment logically done at the SID file level (which is also fine with me)?

[Ballot comment]
Minor level comments:

(2) p 14, sec 4.  ".sid" file format

      leaf sid-file-status {
        type enumeration {
            enum unpublished {
              description
                "This .sid file is unpublished [RFC8407], also called
                a work-in-progress or workfile.
                This may be when it accompanies an unpublished YANG
                module, or when only the .sid file itself is
                unpublished.
                The 'item' list MAY contain entries with a status
                value of 'unstable'.";
            }

I think that this means that tooling (e.g., YANG Catalog) may want to track two versions of SID files for a module:
(i) The latest published version, that only contains stable SIDs.
(ii) The latest 'unpublished' version, that also contains the unstable SID assignments.

I don't know if you want to mention this in section 2, or you may decide that this is outside the scope of this specification, as per the last paragraph of section 2.


(3) p 17, sec 4.  ".sid" file format

          description
            "The status field contains information about the stability
              of the allocation.  For each specific SID value, over time
              it can only transition from unstable to stable,
              and possibly from stable to obsolete.";

What happens to an unstable SID that is allocated during a development version, but ends up not being needed in the stable published version:
  (i) Is it okay for this SID to just be deleted?
  (ii) Is it okay for this SID to be assigned to a different stable path?
  (iii) Or does this SID get moved to obsolete?

Actually, I see that there is some text in section 3 that covers this.  My understanding is that the answer to my questions are, 1. Yes, 2. Yes, 3. No.  If so, then I think that you may want to expand that unstable is also allowed to be removed (i.e., become unallocated again), and hence potentially be used for a different YANG schema name/path.

[Ballot discuss]
Hi,

Updated discuss comments based on -19.

I think that my main concern is still how permanent or transient allocated SIDs are, particularly when YANG modules are being developed.

In particular, I think that it would be helpful for the allocated SIDs to be split into two (maybe three) lists:
(1) Permanent allocations that MUST never change once allocated (e.g., if the schema path changes, the old entry is retained and no reallocated).
(2) Temporary allocations that could change, e.g., when a file is being developed (either using a separate temporary SID range, or part of the permanent SID space allocated to the module).
(3) The optional third section could be obsolete SIDs.  I.e., ones that cannot be reallocated to a different path, but software generating a mapping between SIDs and schema paths should be able to just ignore them.  Alternatively, rather than having a different section, entries could be marked with an obsolete flag in the permanent section instead.

When IETF drafts containing YANG modules are being developed or updated then the authors can decide whether new SIDs are allocated from the permanent or temporary sections depending on how stable they think parts of the model are.  But authors would only ever be allowed to renumber temporarily assigned SIDs.

I also think that having a global flag on the SID file would be helpful to define whether the file is the canonical SID file produced with permission of the module controller (owner) or generated by a third party.  This meta data may help consumers of SIDs understand their permanence.  Of course, there is not guarantee that the generated meta-data will necessarily be correct.

Regards,
Rob

Previous discuss comments:

There are a couple of points that I would like to see discussed and perhaps addressed:

(1) I would like further discussion regarding whether SIDs are bound just to the schema name, or the schema item definition.  The draft states that if the definition is changed in a non-backwards-compatible (NBC) way then a new SID SHOULD be allocated.  But I don't understand how this will work.  Given that the .sid file would then contain exactly the same path but with different sids assigned (for every time the meaning of the definition changes), then how do consumers of the sid file know which sid to use for a given path (given that there is no indication in the .sid file)?  Instead, I think that this is the wrong way to be handling NBC changes, and SIDs should be bound only to the schema path (i.e., the name of the item), and a new SID is only allocated if the name/path changes, and otherwise the same SID is used, even if the definition changes in a non-backwards-compatible way.

(2) I think that this document should be clearer as to the relationship between SIDs and submodules (more details in the comment).

(3) This draft makes use of the rc:yang-data extension.  Was there any discussion about using "YANG Data Structure Extensions" (RFC 8791) instead, which is meant to be a cleaner formulation of the rc:yang-data extension, and without the dependency on RESTCONF?  I would suggest that using RFC 8791 would be preferable if possible.

(4) The policy in 7.4.2 for allocation a SID mega-range seems to aiming this towards organizations rather than individuals.  The policy in 7.6 for the "IETF YANG SID Registry" requires an RFC.  What is the mechanism if an individual or open source project wanted to get SIDs assigned for some of their YANG modules?  I.e., should we be defining a separate mega-range, managed by IANA, with just Expert Review or Specification Required so that these modules could use SIDs allocated?  Or do you envisage a separate entity taking up the responsibility for coordinating this?

Regards,
Rob

[Ballot comment]
Thanks for (largely) addressing my previous Discuss points!

Following up on what was previously my discuss point (3), I still see
MUST-level guidance to the expert in §7.5.2 to ensure that YANG items
are assigned the same SIDs as in any other ".sid" file that has
allocated SIDs for the YANG module in question.  It seems prudent to
qualify that on the YANG items having the same semantics as the already
allocated SIDs and/or refer to the discussion in Appendix B from this
location.

Section 7.4.3

  For a YANG module approved for publication as an RFC, a ".sid" file
  SHOULD be included in the Internet-Draft as a source code block.
  This ".sid" file is to be extracted by IANA/the expert reviewer and
  put into the YANG SID Registry (Section 7.5) along with the YANG
  module.  The ".sid" file MUST NOT be published as part of the RFC:
  the IANA Registry is authoritative and a link is to be inserted in
  the RFC.

Following up the "SHOULD be included in the I-D" with "is to be
extracted and put into the YANG SID registry" leaves some ambiguity
about what happens if the SHOULD is ignored (i.e., the ".sid" file is
not in the draft).  I think the intent is that something is created and
still goes into the YANG SID registry, but that might be worth
clarifying.

I'm also a bit ambivalent about using "MUST NOT" for "don't include the
".sid" file in the RFC" -- it's generally the right thing to do, but
who's it supposed to be binding on?  With no enforcement mechanism, it
might be easy to overlook, and what's the remedy if that happens?  It
also precludes any exceptional circumstance where we do feel a need to
put the file contents in the RFC.

Appendix A

The ruby one-liner provided to extract JSON from Figure 3 is really
evocative of the things people like to complain about perl code for.
I don't really know any Ruby, but have to ask if the quoting+escaping
is up to best practices for secure coding, and whether "\n" is going to
properly match line endings on all OSes.

[the following is retained from my previous ballot position]

Section 7.4.2

  In case a SID range is required before publishing the RFC due to
  implementations needing stable SID values, early allocation as
  defined in [BCP100] can be employed.  As specified in Section 4.6 of
  [RFC8126], RFCs and by extension documents that are expected to
  become an RFC fulfill the requirement for "Specification Required"
  stated in Section 2 of [BCP100], which allows for the early
  allocation process to be employed.

While the first bit of this is all true, the registry here doesn't use
the "Specification Required" policy for any range, and early allocations
are available for the "RFC Required" range.  So we should probably tweak
or remove the second sentence.
[ed. the response to my previous ballot position pointed to PR 103 but I
am failing to find a change that addressed this comment]

[Ballot discuss]
(1) I think there is a new security consideration with this work that is
important to document clearly -- not only do we define a new type of
identifier, but we define a file format and other mechanisms for
disseminating that information.  An entity that's processing
application/yang-data+cbor; id=sid information needs to ensure that the
.sid files (or other source of SID information) it uses for such
processing came from a trustworthy authority (or at least the same
source as the data file).  It would be possible for malicious
manipulation of .sid file contents to cause a message recipient to
mis-interpret the received message without any indication of such
tampering.
[ed. there seems to be some proposed text in
https://mailarchive.ietf.org/arch/msg/core/JS0uD9aUNwim_fwhBpGnZut9kns/ ]

(2) Per §7.4.2, YANG SID range registries with public ranges MUST
include a reference to the ".sid" file for such ranges, but the
IANA-managed YANG SID range registry established by §7.5 does not, in
and of itself, make such a provision.  This function seems to be served
by the "IETF YANG SIG Registry" created by §7.6, so we may just need to
point to the one registry from the other in order to remain internally
consistent.

(3) There may be another inconsistency to look into; Section 7.6.2 says
that:

  *  If another ".sid" file has already allocated SIDs for this YANG
      module (e.g. for older or newer versions of the YANG module), the
      YANG items are assigned the same SIDs as in the other ".sid" file.

But we are supposed to allocate a new SID for a YANG item if its
semantics change in a revision of the YANG module.  Perhaps it's just
the "for older or newer versions of the YANG module" phrase that needs
tweaking?

[Ballot comment]
Would RFC 8792 folding be suitable for Appendix A rather than using
a custom scheme/disclaimer?

I see that most mention of what to do with SID assignments if the
semantics of a node (name) changes, or a node name changes without
changing semantics, has been moved to Appendix B.  I'm not sure if
it's helpful to retain some mention that this discussion exists,
in the main body text (e.g., Section 1).

[The rest of this COMMENT section populated by taking the comment section from the -16
and removing a small handful of things that are clearly addressed.
Some items that are retained may have been addressed as well and no
longer applied]

The yangdoctors review mentioned the structure extension from RFC 8791,
and the authors (understandably) expressed reluctance to make such a
large change at this stage in the process.  I'll note that the DOTS WG
has recently completed work on a "bis" of RFC 8782, with primary aim of
replacing yang-data with structures and minimal other changes.  (A
yangdoctors review of a related document was sufficiently insistent that
structures are the right way to do this that the WG was convinced to put
in the effort.)

The yangdoctors review also asked why sid-file/module-name is optional,
which was tagged for follow-up.  I have the same question and am
interested in the outcome of the discussion amongst the authors.

If SIDs are supposed to be globally unique identifiers, the reference in
the YANG module to "namespace" identifiers for individual allocations is
puzzling to me.  The presence of a namespace would typically allow for
identifier reuse across namespaces (e.g., using the same SID integer value
for an identity and a data node within the same module).  I see how the
current list structure makes it easy to have a single flat list of all
identifier/sid mappings, but if the SIDs truly are globally unique, then
the "namespace" should not be a list key, and might be less confusingly
described as just indicating the type for which the SID is used.  (It
would also be possible to have separate lists for module SIDs, identity
SIDs, etc., but it's not clear that doing so is actually the right
approach.)

Section 4

If the scope of a sid-file-version-identifier resets when the module
revision is bumped, it seems highly unlikely that we'll need 64 bits of
identifier for it.

Section 5, 7.3

It's not entirely clear that we need to mention the
content-type/content-format in this document, as we only indicate use of
the JSON encoding for the .sid file and the use of SIDs in the
application/yang-data+cbor; id=sid case seems adequately described by
the existing treatment in draft-ietf-core-yang-cbor.

Section 7.4.1

I appreciate that the "mega-range" allocations are sized for the
appropriate SI prefix :)

  The information associated to the Organization name should not be
  publicly visible in the registry, but should be available.  This
  information includes contact email and phone number and change
  controller email and phone number.

Available to whom?

Section 7.5.2

  In case a SID range is required before publishing the RFC due to
  implementations needing stable SID values, early allocation as
  defined in [BCP100] can be employed.  As specified in Section 4.6 of
  [RFC8126], RFCs and by extension documents that are expected to
  become an RFC fulfill the requirement for "Specification Required"
  stated in Section 2 of [BCP100], which allows for the early
  allocation process to be employed.

While the first bit of this is all true, the registry here doesn't use
the "Specification Required" policy for any range, and early allocations
are available for the "RFC Required" range.  So we should probably tweak
or remove the second sentence.

Section 7.6.3

  Early Allocations are made with a one-year period, after which they
  are expired.  [BCP100] indicates that at most one renewal may be
  made.  For the SID allocation a far more lenient stance is desired.

  1.  An extension of a referencing documents Early Allocation should
      update any referenced Early Allocations to expire no sooner than
      the referencing document.

  2.  The [BCP100] mechanism allows the IESG to provide a second
      renewal, and such an event may prompt some thought about how the
      collection of documents are being processed.

The first point is rather curious, since it can have no normative force
(this is not a BCP that would override BCP 100) and is merely a
continnation of how a more lenient stance is desired.  It's rather odd
to see it written in this way.  The second point seems to be the only
really useful part, and in practice this IESG approval of second (and
more!) renewals has become rather common, to the extent where a revision
of BCP 100 has been discussed to change the discussion of extensions for
early renewals.

  This is driven by the very generous size of the SID space and the
  often complex and deep dependencies of YANG modules.  Often a core
  module with many dependencies will undergo extensive review, delaying
  the publication of other documents.

Having many *dependencies* and taking a while shouldn't delay
publication of anything else; however, having many other modules
dependent on a core module would be likely to do so.

Appendix A

IIRC the mismatch between "ietf-system@2014-08-06.yang" and the toplevel
"module-revision" of "2020-02-05" was noted by an earlier reviewer, but
I'll mention it here just in case I do not remember correctly.

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

Based on the authors’ reply, I have now cleared one of my previous blocking DISCUSS points (related to section 7.5.2 and other SDO / mega ranges see also https://mailarchive.ietf.org/arch/msg/core/SyG1Ax5V2KmYM8v1_CFOmghpUs0/ ). I have kept the previous DISCUSS points below for archive.

Please note that my COMMENT points are still unanswered as far as I can tell.

I hope that this helps to improve the document,

Regards,

-éric

== PREVIOUS DISCUSS ==

-- Section 3 --
As a YANG model can have several YANG modules, was there a discussion in the WG whether the SID range is assigned per module or per model ? The IANA section seems to refer to an allocation per RFC, i.e., per model and not per module.

-- Section 7.5.2 --
AFAIK, many YANG modules are not originating at the IETF (Open Config, vendor specifics modules, ...). How can those non-IETF modules get a SID as the two ways to get a SID are based on RFC (if I understand correctly this section).

== COMMENTS ==

I will let my OPS and Management AD to comment on the use of 'YANG schema' rather than 'YANG module' and about the word 'item' for many YANG-related concepts.

I know that Alex Pelov is an author but was there any discussion with LPWAN WG on this?

No need to reply but the use of ".sid" to qualify a file format reminded me of MS-DOS... ;-)

I am somehow concerned by having so many SIDs being generated as it requires being careful in generating them and having a scalability issue when using them as the 'mapping table' could become quite large.

-- Abstract --
Suggest to add the reason why using SID in constrained environments for people outside of CORE WG ;-)

-- Section 4 --
In addition to a reference to RFC 7951, why not simply adding that the the ".sid" file is encoded in JSON ?

-- Section 7.4.1 --
Out of sheer curiosity, why using a decimal million rather than the usual power of 2 ? Again just out of curiosity ;-)

-- Section 7.5.3 --
Suggest to either remove entries related to ietf-anima-constrained-voucher or move this I-D in the normative references section.

== NIT ==

-- Section 1 --
Suggest to expand "YANG SID" again as the abstract is not really part of the document.

[Ballot discuss]

This should be very easy to resolve and I want to make sure that we understand the situation here better -

*Section 3 : says -

    "The creation of this new version of the ".sid" file
  SHOULD be performed using an automated tool"
 
  If this is supposed to be the automation process written in appendix B then putting a reference here makes sense. If not, then as this is very important tool, more information need to be added here in this specification (like, where to find it, who create and maintains it, any reference to such an existing tools). Also I am missing what consequences one need to consider if the process is not automated. If this is same as written in the introduction -
 
  "Assignment of SIDs to YANG items can be automated.  For more details
  how this can be achieved, please consult Appendix B."

  Then we have two kind of instructions for the same thing - "can be" and a normative "SHOULD". Hence it need to be clarified which one should prevail.

[Ballot comment]
Thanks for the efforts in this document.

* I support Robert Wilton's Discuss and Benjamin Kaduk's discuss no.2

One more clarification comment -

* Section 7.5.2: says -

    "  The
  maximum SID range size is 1000.  A larger size may be requested by
  the authors if this recommendation is considered insufficient.  It is
  important to note that an additional SID range can be allocated to an
  existing YANG module if the initial range is exhausted."

  I have hard time understanding the mentioning of the maximum SID range here. does this mean this document sets the maximum range to 1000 but others can have more? please clarify.

[Ballot discuss]

This should be very easy to resolve and I want to make sure we understand the situation here better -

*Section 3 : says -

    "The creation of this new version of the ".sid" file
  SHOULD be performed using an automated tool"
 
  It this is supposed to be the automation process written in appendix B then putting a reference here makes sense. If not then as this is very important tool more information need to be added here in this specification (like, where to find it, who create and maintains it, any reference to such an existing tools). If this is same as written in the introduction -
 
  "Assignment of SIDs to YANG items can be automated.  For more details
  how this can be achieved, please consult Appendix B."

  Then we have two set of instructions for the same thing - "can be" and a normative "SHOULD". Hence it need to be clarified which one should prevail.

[Ballot comment]
Thanks for the efforts in this document.

* I support Robert Wilton's Discuss and Benjamin Kaduk's discuss no.2

One more clarification comment -

* Section 7.5.2: says -

    "  The
  maximum SID range size is 1000.  A larger size may be requested by
  the authors if this recommendation is considered insufficient.  It is
  important to note that an additional SID range can be allocated to an
  existing YANG module if the initial range is exhausted."

  I have hard time understanding the mentioning of the maximum SID range here. does this mean this document sets the maximum range to 1000 and others can have more? please clarify.

[Ballot comment]
Section 1:

It's a bit weird to have requirements language in an Introduction.

Section 7, generally:

Thanks for providing advice for the Designated Experts for each of the created registries.  This is a not-exactly-uncommon oversight.

Section 7.4.1:

* "The size of the registered SID block.  The size MUST be one million (1 000 000) SIDs." -- Seems a waste of a registry column if it's always this one value.  Maybe this should instead be the highest SID in the block?

* "The information associated to the Organization name should not be publicly visible in the registry, but should be available." -- Why not, and available how?

Section 7.5.2:

* "The maximum SID range size is 1000.  A larger size may be requested by the authors if this recommendation is considered insufficient." -- This is a contradiction.  Should "maximum" be "default"?

* "RFCs and by extension documents that are expected to become an RFC fulfill the requirement for "Specification Required" stated in..." -- I think you mean "RFC Required".

[Ballot comment]
I support the DISCUSS positions of Ben Kaduk, Éric Vyncke, and Rob Wilton.

** YANG module.  Typo. “list assignment-range”.  s/the the/the/

** Appendix B. 

Assignment of SIDs to YANG items can be automated, the recommended
  process to assign SIDs is as follows:

...
  4.  If the number of items exceeds the SID range(s) allocated to a
      YANG module, an extra range is added for subsequent assignments.

What’s the expected automated approach for adding extra ranges.  I was under the impression that getting more SIDs required an IANA request to allocate them them "YANG SID Range Registry"?

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

Please find below two blocking DISCUSS points (which are probably misunderstandings of mine), some non-blocking COMMENT points (but replies would be appreciated), and one nit.

I hope that this helps to improve the document,

Regards,

-éric


-- Section 3 --
As a YANG model can have several YANG modules, was there a discussion in the WG whether the SID range is assigned per module or per model ? The IANA section seems to refer to an allocation per RFC, i.e., per model and not per module.

-- Section 7.5.2 --
AFAIK, many YANG modules are not originating at the IETF (Open Config, vendor specifics modules, ...). How can those non-IETF modules get a SID as the two ways to get a SID are based on RFC (if I understand correctly this section).

[Ballot comment]
== COMMENTS ==

I will let my OPS and Management AD to comment on the use of 'YANG schema' rather than 'YANG module' and about the word 'item' for many YANG-related concepts.

I know that Alex Pelov is an author but was there any discussion with LPWAN WG on this?

No need to reply but the use of ".sid" to qualify a file format reminded me of MS-DOS... ;-)

I am somehow concerned by having so many SIDs being generated as it requires being careful in generating them and having a scalability issue when using them as the 'mapping table' could become quite large.

-- Abstract --
Suggest to add the reason why using SID in constrained environments for people outside of CORE WG ;-)

-- Section 4 --
In addition to a reference to RFC 7951, why not simply adding that the the ".sid" file is encoded in JSON ?

-- Section 7.4.1 --
Out of sheer curiosity, why using a decimal million rather than the usual power of 2 ? Again just out of curiosity ;-)

-- Section 7.5.3 --
Suggest to either remove entries related to ietf-anima-constrained-voucher or move this I-D in the normative references section.

== NIT ==

-- Section 1 --
Suggest to expand "YANG SID" again as the abstract is not really part of the document.

[Ballot discuss]
(1) I think there is a new security consideration with this work that is
important to document clearly -- not only do we define a new type of
identifier, but we define a file format and other mechanisms for
disseminating that information.  An entity that's processing
application/yang-data+cbor; id=sid information needs to ensure that the
.sid files (or other source of SID information) it uses for such
processing came from a trustworthy authority (or at least the same
source as the data file).  It would be possible for malicious
manipulation of .sid file contents to cause a message recipient to
mis-interpret the received message without any indication of such
tampering.

(2) Per §7.4.2, YANG SID range registries with public ranges MUST
include a reference to the ".sid" file for such ranges, but the
IANA-managed YANG SID range registry established by §7.5 does not, in
and of itself, make such a provision.  This function seems to be served
by the "IETF YANG SIG Registry" created by §7.6, so we may just need to
point to the one registry from the other in order to remain internally
consistent.

(3) There may be another inconsistency to look into; Section 7.6.2 says
that:

  *  If another ".sid" file has already allocated SIDs for this YANG
      module (e.g. for older or newer versions of the YANG module), the
      YANG items are assigned the same SIDs as in the other ".sid" file.

But we are supposed to allocate a new SID for a YANG item if its
semantics change in a revision of the YANG module.  Perhaps it's just
the "for older or newer versions of the YANG module" phrase that needs
tweaking?

[Ballot comment]
The yangdoctors review mentioned the structure extension from RFC 8791,
and the authors (understandably) expressed reluctance to make such a
large change at this stage in the process.  I'll note that the DOTS WG
has recently completed work on a "bis" of RFC 8782, with primary aim of
replacing yang-data with structures and minimal other changes.  (A
yangdoctors review of a related document was sufficiently insistent that
structures are the right way to do this that the WG was convinced to put
in the effort.)

The yangdoctors review also asked why sid-file/module-name is optional,
which was tagged for follow-up.  I have the same question and am
interested in the outcome of the discussion amongst the authors.

If SIDs are supposed to be globally unique identifiers, the reference in
the YANG module to "namespace" identifiers for individual allocations is
puzzling to me.  The presence of a namespace would typically allow for
identifier reuse across namespaces (e.g., using the same SID integer value
for an identity and a data node within the same module).  I see how the
current list structure makes it easy to have a single flat list of all
identifier/sid mappings, but if the SIDs truly are globally unique, then
the "namespace" should not be a list key, and might be less confusingly
described as just indicating the type for which the SID is used.  (It
would also be possible to have separate lists for module SIDs, identity
SIDs, etc., but it's not clear that doing so is actually the right
approach.)

Section 1

  [...] If the
  meaning of an item changes, for example as a result from a non-
  backward compatible update of the YANG module, a new SID SHOULD be
  assigned to it.  A new SID MUST always be assigned if the new meaning
  of the item is going to be referenced using a SID.

That predicate seems in general unknowable ("you can't prove a
negative", etc.), so it's tempting to just require that if the old
semantics had a SID that the new semantics get one as well.

Section 4

If the scope of a sid-file-version-identifier resets when the module
revision is bumped, it seems highly unlikely that we'll need 64 bits of
identifier for it.

Section 5, 7.3

It's not entirely clear that we need to mention the
content-type/content-format in this document, as we only indicate use of
the JSON encoding for the .sid file and the use of SIDs in the
application/yang-data+cbor; id=sid case seems adequately described by
the existing treatment in draft-ietf-core-yang-cbor.

Section 7.4.1

I appreciate that the "mega-range" allocations are sized for the
appropriate SI prefix :)

  The information associated to the Organization name should not be
  publicly visible in the registry, but should be available.  This
  information includes contact email and phone number and change
  controller email and phone number.

Available to whom?

Section 7.5.2

  The size of the SID range allocated for a YANG module is recommended
  to be a multiple of 50 and to be at least 33% above the current
  number of YANG items.  This headroom allows assignment within the
  same range of new YANG items introduced by subsequent revisions.  The
  maximum SID range size is 1000.  A larger size may be requested by
  the authors if this recommendation is considered insufficient.  [...]

If there's a maximum size for a range, then asking for a larger one is
pointless.  Please reword to indicate the actual intent (maybe
s/maximum/typical expected/ or similar).

  In case a SID range is required before publishing the RFC due to
  implementations needing stable SID values, early allocation as
  defined in [BCP100] can be employed.  As specified in Section 4.6 of
  [RFC8126], RFCs and by extension documents that are expected to
  become an RFC fulfill the requirement for "Specification Required"
  stated in Section 2 of [BCP100], which allows for the early
  allocation process to be employed.

While the first bit of this is all true, the registry here doesn't use
the "Specification Required" policy for any range, and early allocations
are available for the "RFC Required" range.  So we should probably tweak
or remove the second sentence.

Section 7.6.3

  Early Allocations are made with a one-year period, after which they
  are expired.  [BCP100] indicates that at most one renewal may be
  made.  For the SID allocation a far more lenient stance is desired.

  1.  An extension of a referencing documents Early Allocation should
      update any referenced Early Allocations to expire no sooner than
      the referencing document.

  2.  The [BCP100] mechanism allows the IESG to provide a second
      renewal, and such an event may prompt some thought about how the
      collection of documents are being processed.

The first point is rather curious, since it can have no normative force
(this is not a BCP that would override BCP 100) and is merely a
continnation of how a more lenient stance is desired.  It's rather odd
to see it written in this way.  The second point seems to be the only
really useful part, and in practice this IESG approval of second (and
more!) renewals has become rather common, to the extent where a revision
of BCP 100 has been discussed to change the discussion of extensions for
early renewals.

  This is driven by the very generous size of the SID space and the
  often complex and deep dependencies of YANG modules.  Often a core
  module with many dependencies will undergo extensive review, delaying
  the publication of other documents.

Having many *dependencies* and taking a while shouldn't delay
publication of anything else; however, having many other modules
dependent on a core module would be likely to do so.

Appendix A

IIRC the mismatch between "ietf-system@2014-08-06.yang" and the toplevel
"module-revision" of "2020-02-05" was noted by an earlier reviewer, but
I'll mention it here just in case I do not remember correctly.

NITS

Section 1

  SIDs are assigned permanently, items introduced by a new revision of
  a YANG module are added to the list of SIDs already assigned.  If the

comma splice

Section 5

        Each .sid file contains the mapping between the different
        string identifiers defined by a YANG module and a
        corresponding numeric value called YANG SID.";

singular/plural mismatch "numeric value called YANG SID"/"string
identifiers"

[Ballot discuss]
Hi,

Thank you for this work, I believe that it likely to be useful, perhaps not only for constrained devices, it may also turn out to be popular for streaming telemetry.

There are a couple of points that I would like to see discussed and perhaps addressed:

(1) I would like further discussion regarding whether SIDs are bound just to the schema name, or the schema item definition.  The draft states that if the definition is changed in a non-backwards-compatible (NBC) way then a new SID SHOULD be allocated.  But I don't understand how this will work.  Given that the .sid file would then contain exactly the same path but with different sids assigned (for every time the meaning of the definition changes), then how do consumers of the sid file know which sid to use for a given path (given that there is no indication in the .sid file)?  Instead, I think that this is the wrong way to be handling NBC changes, and SIDs should be bound only to the schema path (i.e., the name of the item), and a new SID is only allocated if the name/path changes, and otherwise the same SID is used, even if the definition changes in a non-backwards-compatible way.

(2) I think that this document should be clearer as to the relationship between SIDs and submodules (more details in the comment).

(3) This draft makes use of the rc:yang-data extension.  Was there any discussion about using "YANG Data Structure Extensions" (RFC 8791) instead, which is meant to be a cleaner formulation of the rc:yang-data extension, and without the dependency on RESTCONF?  I would suggest that using RFC 8791 would be preferable if possible.

(4) The policy in 7.4.2 for allocation a SID mega-range seems to aiming this towards organizations rather than individuals.  The policy in 7.6 for the "IETF YANG SID Registry" requires an RFC.  What is the mechanism if an individual or open source project wanted to get SIDs assigned for some of their YANG modules?  I.e., should we be defining a separate mega-range, managed by IANA, with just Expert Review or Specification Required so that these modules could use SIDs allocated?  Or do you envisage a separate entity taking up the responsibility for coordinating this?

Regards,
Rob

[Ballot comment]
1. Regarding the relationship between sids and submodules, I think is best summed up by this comment in the appendix: "Note that ".sid" files can only be generated for YANG modules and not for submodules."  I.e., I don't think that sids should be allocated for the name of the submodule, and any items within a submodule are effectively allocated sids as part of processing the module that includes them.  This topic should be addressed early in the document, and probably the existing references to submodule in the introduction and the YANG module can be removed.

[Ballot comment]
It caught my attention that the names of the editors in the module don't match the names of the document authors.  Is there a reason for that?

[Ballot comment]
Section 1. , paragraph 13, comment:
>    If the
>    meaning of an item changes, for example as a result from a non-
>    backward compatible update of the YANG module, a new SID SHOULD be
>    assigned to it.

Why is this not a MUST? When would it be OK to not use a new SID?

Section 4. , paragraph 21, comment:
>        reference
>          "[I-D.ietf-core-sid] YANG Schema Item iDentifier (YANG SID)";

Should the reference not be "RFC XXXX"? (Also below.)

Found terminology that should be reviewed for inclusivity:
* Term "his"; alternatives might be "they", "them", "their".
* Term "native"; 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 1. , paragraph 2, nit:
-    unique identifier.  In both Network Configuration Protocol(NETCONF)
+    unique identifier.  In both Network Configuration Protocol (NETCONF)
+                                                              +

Section 3. , paragraph 1, nit:
> ANG module is optional but recommended to promote interoperability between d
>                            ^^^^^^^^^^^^^^^^^^^^^^
The verb "recommended" is used with the gerund form.

Section 4. , paragraph 32, nit:
> available value is entry-point and the the last available value in the range
>                                    ^^^^^^^
Two determiners in a row. Choose either "the" or "the".

Section 7.5.3. , paragraph 3, nit:
> istration. This process may be time consuming during a bootstrap period (ther
>                                ^^^^^^^^^^^^^^
This word is normally spelled with a hyphen.

Section 7.5.3. , paragraph 3, nit:
>  will list the other allocations in it's description, and will be cross-post
>                                    ^^^^
Did you mean "its" (possessive pronoun) instead of "it's" (short for "it is")?

Section 7.5.3. , paragraph 3, nit:
>  module which references a module in an document which has not yet been adop
>                                      ^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

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

Document references draft-ietf-anima-constrained-voucher-11, but -12 is the
latest available revision.

These URLs in the document can probably be converted to HTTPS:
* http://datatracker.ietf.org/wg/core/

Document Writeup for Working Group Documents

This is the write for the CORECONF document draft-ietf-core-sid-15 released on 2021-01-17.

> (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-yang-cbor, 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-yang-cbor 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-yang-cbor together provide the foundation to extend YANG-based management down to constrained devices (RFC 7228).

In particular, the present document defines 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, the document also defines a file format used to persist and publish assigned YANG SIDs.
 
The companion document draft-ietf-core-yang-cbor 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 October 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 also is a co-author of the draft-ietf-core-comi specification using the present document and the companion document draft-ietf-core-yang-cbor.

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:

Document Shepherd: Jaime Jiménez
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.

The YANG module ietf-sid-file 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?

This document has a normative reference to the other CORECONF document draft-ietf-core-yang-cbor. Also, it has informative references to the other CORECONF documents draft-ietf-core-comi and draft-ietf-core-yang-library.

> (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 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.

This document 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.

This document defines a YANG module ietf-sid-file that passes the validation provided by the datatracker.

> (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?

This document 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.

Approved by XML experts, but the CoAP Content-Formats expert has identified the following issues:

Section 7.3 of draft-ietf-core-sid-15 registers a new CoAP
Content-Format ID for the Content Type
"application/yang-data+cbor;id=sid", i.e., for the Media Type
"application/yang-data+cbor" with a specific set of choices for
its parameters, namely the "id" parameter set to the value "sid".

There are the following problems with this registration:

1) CoAP Content-Format IDs can only be registered for Media Types that
have been registered in the IANA Media Types registry. I don't see
"application/yang-data+cbor" in
https://www.iana.org/assignments/media-types/media-types.xhtml yet.

2) The draft lists only "RFC XXXX" (this draft) as a reference.
However, it seems that the Media Type "application/yang-data+cbor" is
actually defined in draft-ietf-core-yang-cbor-15. It would therefore
be good to include a reference to that in the registration as well.

3) The Media Type "application/yang-data+cbor" as defined in Section
9.1 of draft-ietf-core-yang-cbor-15 doesn't define any parameters. In
particular, there is no parameter "id" defined that could be set to
the value "sid".

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

The IANA Functions Operator has completed its review of draft-ietf-core-sid-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 six actions which we must complete.

First, in the ns registry on the IETF XML Registry page located at:

https://www.iana.org/assignments/xml-registry/

a new namespace will be registered as follows:

ID: yang:ietf-sid-file
URI: urn:ietf:params:xml:ns:yang:ietf-sid-file
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the YANG Module Names registry on the YANG Parameters registry page located at:

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

a new YANG module will be registered as follows:

Name: ietf-sid-file
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-sid-file
Prefix: sid
Module:
Reference: [ RFC-to-be ]

While the YANG module name will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published.

Third, 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 new registration is to be made as follows:

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

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

Fourth, a new registry is to be created called the YANG SID Mega-Range registry. The new registry is to be created on a new registry page called the YANG SID Mega-Range.

The allocation policy for the new registry is Expert Review as defined in RFC 8126.

There is an initial registration in the new registry as follows:

+-------------+---------+------------+-------------------+----------+---------------+
| Entry Point | Size | Allocation | Organization name | URL | Reference |
+-------------+---------+------------+-------------------+----------+---------------+
| 0 | 1000000 | Public | IANA | iana.org | [ RFC-to-be ] |
+-------------+---------+------------+-------------------+----------+---------------+

Fifth, a new registry is to be created called the IETF YANG SID Range registry. The new registry will be located on a new registry page for YANG SID Mega-Range.

The registration policy for the new registry is as follows:

+-------------+---------+-------------------------------+
| Entry Point | Size | IANA policy |
+-------------+---------+-------------------------------+
| 0 | 1,000 | Reserved |
| 1,000 | 59,000 | Expert Review or RFC Required |
| 60,000 | 40,000 | Experimental use |
| 100,000 | 900,000 | Reserved |
+-------------+---------+-------------------------------+

There are initial registrations in the new registry as follows:

+-------+------+---------------------------+-------------------------------------+
| Entry | Size | Module name | Reference |
| Point | | | |
+-------+------+---------------------------+-------------------------------------+
| 1000 | 100 | ietf-coreconf | [I-D.ietf-core-comi] |
| 1100 | 50 | ietf-yang-types | [RFC6991] |
| 1150 | 50 | ietf-inet-types | [RFC6991] |
| 1200 | 50 | iana-crypt-hash | [RFC7317] |
| 1250 | 50 | ietf-netconf-acm | [RFC8341] |
| 1300 | 50 | ietf-sid-file | [ RFC-to-be ] |
| 1500 | 100 | ietf-interfaces | [RFC8343] |
| 1600 | 100 | ietf-ip | [RFC8344] |
| 1700 | 100 | ietf-system | [RFC7317] |
| 1800 | 400 | iana-if-type | [RFC7224] |
| 2400 | 50 | ietf-voucher | [RFC8366] |
| 2450 | 50 | ietf-constrained-voucher | [I-D.ietf-anima-constrained-voucher |
| 2500 | 50 | ietf-constrained-voucher- | [I-D.ietf-anima-constrained-voucher |
+-------+------+---------------------------+-------------------------------------+

Sixth, a new registry is to be created called the IETF YANG SID registry. The new registry will be located on a new registry page for YANG SID Mega-Range.

The registry will be managed via Expert Review as defined in RFC 8126.

There are no initial allocations in this new registry but its structure is intended to be:

|-------+-------------+-------------+--------------+--------------+
YANG Associated Associated Number of
Module YANG .sid SIDs
Name File File Allocated Reference
|-------+-------------+-------------+--------------+--------------+
| | | | | |
--------+-------------+-------------+--------------+--------------+

We understand that a tool for SID file validation will be provided. If this is not correct, please let us know how files will be validated.

The IANA Services 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-sid@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (YANG Schema Item iDentifier (YANG SID)) to Proposed Standard


The IESG has received a request from the Constrained RESTful Environments WG
(core) to consider the following document: - 'YANG Schema Item iDentifier
(YANG SID)'
  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


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




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



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.

Changed document external resources from:

['yc_entry https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-sid-file@2020-02-05.yang (Yang catalog entry for ietf-sid-file@2020-02-05.yang)', 'yc_impact https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-sid-file@2020-02-05.yang&recurse=0&rfcs=1&show_subm=1&show_dir=both (Yang impact analysis for draft-ietf-core-sid)']

to:

yc_impact https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-sid-file@2020-02-05.yang&recurse=0&rfcs=1&show_subm=1&show_dir=both (Yang impact analysis for draft-ietf-core-sid)
github_repo https://github.com/core-wg/yang-cbor (Working Group Repo)
yc_entry https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-sid-file@2020-02-05.yang (Yang catalog entry for ietf-sid-file@2020-02-05.yang)