Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2022-04-25
18 Marco Tiloca Added to session: interim-2022-core-05
2022-03-16
18 (System) Changed action holders to Carsten Bormann, Michael Richardson, Francesca Palombini, Alexander Pelov, Michel Veillette, Ivaylo Petrov (IESG state changed)
2022-03-16
18 Francesca Palombini IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation::AD Followup
2022-02-28
18 Marco Tiloca Added to session: interim-2022-core-04
2022-02-24
18 Marco Tiloca Added to session: interim-2022-core-03
2022-02-02
18 Marco Tiloca Added to session: interim-2022-core-02
2022-01-19
18 Marco Tiloca Added to session: interim-2022-core-01
2021-12-08
18 Benjamin Kaduk
[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 …
[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]
2021-12-08
18 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss
2021-12-06
18 Marco Tiloca Added to session: interim-2021-core-14
2021-11-18
18 (System) Changed action holders to Francesca Palombini (IESG state changed)
2021-11-18
18 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-11-18
18 Carsten Bormann New version available: draft-ietf-core-sid-18.txt
2021-11-18
18 (System) New version accepted (logged-in submitter: Carsten Bormann)
2021-11-18
18 Carsten Bormann Uploaded new revision
2021-11-15
17 Zaheduzzaman Sarker [Ballot comment]
Thanks for the addressing my DISCUSS in the -17 version of this document.
2021-11-15
17 Zaheduzzaman Sarker [Ballot Position Update] Position for Zaheduzzaman Sarker has been changed to No Objection from Discuss
2021-10-27
17 Francesca Palombini As discussed during the CoRE interim, another update is needed. https://datatracker.ietf.org/meeting/interim-2021-core-13/session/core
2021-10-27
17 (System) Changed action holders to Carsten Bormann, Michael Richardson, Francesca Palombini, Alexander Pelov, Michel Veillette, Ivaylo Petrov (IESG state changed)
2021-10-27
17 Francesca Palombini IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation::AD Followup
2021-10-26
17 Benjamin Kaduk
[Ballot discuss]
(1) I think there is a new security consideration with this work that is
important to document clearly -- not only do we …
[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?
2021-10-26
17 Benjamin Kaduk
[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 …
[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.
2021-10-26
17 Benjamin Kaduk Ballot comment and discuss text updated for Benjamin Kaduk
2021-10-26
17 Marco Tiloca Added to session: interim-2021-core-13
2021-10-25
17 (System) Changed action holders to Francesca Palombini (IESG state changed)
2021-10-25
17 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-10-25
17 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2021-10-25
17 Carsten Bormann New version available: draft-ietf-core-sid-17.txt
2021-10-25
17 (System) New version accepted (logged-in submitter: Carsten Bormann)
2021-10-25
17 Carsten Bormann Uploaded new revision
2021-10-19
16 Éric Vyncke
[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 …
[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.
2021-10-19
16 Éric Vyncke [Ballot Position Update] Position for Éric Vyncke has been changed to No Objection from Discuss
2021-10-13
16 Marco Tiloca Added to session: interim-2021-core-12
2021-07-20
16 Francesca Palombini Waiting on answers from authors to IESG evaluation comments.
2021-07-20
16 (System) Changed action holders to Carsten Bormann, Francesca Palombini, Alexander Pelov, Michel Veillette, Ivaylo Petrov (IESG state changed)
2021-07-20
16 Francesca Palombini IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation::AD Followup
2021-07-15
16 Cindy Morgan IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation
2021-07-15
16 Zaheduzzaman Sarker
[Ballot discuss]

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

*Section 3 …
[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.
2021-07-15
16 Zaheduzzaman Sarker
[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 - …
[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.
2021-07-15
16 Zaheduzzaman Sarker Ballot comment and discuss text updated for Zaheduzzaman Sarker
2021-07-15
16 Zaheduzzaman Sarker
[Ballot discuss]

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

*Section 3 : …
[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.
2021-07-15
16 Zaheduzzaman Sarker
[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 - …
[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.
2021-07-15
16 Zaheduzzaman Sarker [Ballot Position Update] New position, Discuss, has been recorded for Zaheduzzaman Sarker
2021-07-15
16 Murray Kucherawy
[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 …
[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".
2021-07-15
16 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2021-07-14
16 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2021-07-14
16 John Scudder [Ballot Position Update] New position, No Objection, has been recorded for John Scudder
2021-07-14
16 Roman Danyliw
[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 …
[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"?
2021-07-14
16 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2021-07-14
16 Amanda Baber IANA Experts State changed to Expert Reviews OK from Issues identified
2021-07-14
16 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2021-07-14
16 Amanda Baber Expert comments: the CoAP Content-Format registration has been moved to draft-ietf-core-yang-cbor. No issues with either document.
2021-07-13
16 Éric Vyncke
[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 …
[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).
2021-07-13
16 Éric Vyncke
[Ballot comment]
== COMMENTS ==

I will let my OPS and Management AD to comment on the use of 'YANG schema' rather than 'YANG module' …
[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.
2021-07-13
16 Éric Vyncke [Ballot Position Update] New position, Discuss, has been recorded for Éric Vyncke
2021-07-13
16 Benjamin Kaduk
[Ballot discuss]
(1) I think there is a new security consideration with this work that is
important to document clearly -- not only do we …
[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?
2021-07-13
16 Benjamin Kaduk
[Ballot comment]
The yangdoctors review mentioned the structure extension from RFC 8791,
and the authors (understandably) expressed reluctance to make such a
large change …
[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"
2021-07-13
16 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2021-07-13
16 Robert Wilton
[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 …
[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
2021-07-13
16 Robert Wilton
[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" …
[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.
2021-07-13
16 Robert Wilton [Ballot Position Update] New position, Discuss, has been recorded for Robert Wilton
2021-07-13
16 Alvaro Retana
[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 …
[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?
2021-07-13
16 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2021-07-12
16 Lars Eggert
[Ballot comment]
Section 1. , paragraph 13, comment:
>    If the
>    meaning of an item changes, for example as a result from …
[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/
2021-07-12
16 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert
2021-07-07
16 Amy Vezza Placed on agenda for telechat - 2021-07-15
2021-07-07
16 Francesca Palombini Ballot has been issued
2021-07-07
16 Francesca Palombini [Ballot Position Update] New position, Yes, has been recorded for Francesca Palombini
2021-07-07
16 Francesca Palombini Created "Approve" ballot
2021-07-07
16 (System) Changed action holders to Francesca Palombini (IESG state changed)
2021-07-07
16 Francesca Palombini IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup
2021-07-07
16 Francesca Palombini Ballot writeup was changed
2021-07-05
16 Marco Tiloca Added to session: interim-2021-core-09
2021-06-24
16 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-06-24
16 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2021-06-24
16 Carsten Bormann New version available: draft-ietf-core-sid-16.txt
2021-06-24
16 (System) New version approved
2021-06-24
16 (System) Request for posting confirmation emailed to previous authors: Alexander Pelov <a@ackl.io>, Ivaylo Petrov <ivaylo@ackl.io>, Michel Veillette <michel.veillette@trilliant.com>, core-chairs@ietf.org
2021-06-24
16 Carsten Bormann Uploaded new revision
2021-06-22
15 Jaime Jimenez
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 …
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 : <https://mailarchive.ietf.org/arch/msg/netmod/SMw0cJ_t-NcV6hfDNtf9lYqMp6U>

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:
<https://mailarchive.ietf.org/arch/msg/media-types/XMn1cIDryOtRbXdGJUHQCse1tGc>


* Personnel:

Document Shepherd: Jaime Jiménez <jaime@iki.fi>
Area Director: Francesca Palombini <francesca.palombini@ericsson.com>

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.
2021-06-22
15 Jaime Jimenez Notification list changed to Carsten Bormann <cabo@tzi.org>, jaime@iki.fi from Carsten Bormann <cabo@tzi.org> because the document shepherd was set
2021-06-22
15 Jaime Jimenez Document shepherd changed to Jaime Jimenez
2021-06-08
15 Amanda Baber
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 …
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".
2021-06-08
15 Amanda Baber IANA Experts State changed to Issues identified from Reviews assigned
2021-06-07
15 Amanda Baber Approved by XML experts. Waiting for CoAP Content-Format expert.
2021-06-07
15 Amanda Baber IANA Experts State changed to Reviews assigned from Expert Reviews OK
2021-03-25
15 Xufeng Liu Request for Last Call review by YANGDOCTORS Completed: Ready with Nits. Reviewer: Xufeng Liu. Sent review to list.
2021-03-19
15 Francesca Palombini Waiting for a doc update following last call comments (also pending YANGDOCTORS last call review).
2021-03-19
15 (System) Changed action holders to Francesca Palombini, Alexander Pelov, Michel Veillette, Ivaylo Petrov (IESG state changed)
2021-03-19
15 Francesca Palombini IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead
2021-03-18
15 Sabrina Tanamal IANA Experts State changed to Expert Reviews OK
2021-03-17
15 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2021-03-17
15 Sabrina Tanamal
(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 …
(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
2021-03-17
15 (System) Changed action holders to Francesca Palombini (IESG state changed)
2021-03-17
15 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2021-03-16
15 Linda Dunbar Request for Last Call review by GENART Completed: Not Ready. Reviewer: Linda Dunbar. Sent review to list.
2021-03-10
15 Cindy Morgan Shepherding AD changed to Francesca Palombini
2021-03-04
15 Jean Mahoney Request for Last Call review by GENART is assigned to Linda Dunbar
2021-03-04
15 Jean Mahoney Request for Last Call review by GENART is assigned to Linda Dunbar
2021-02-25
15 Tero Kivinen Request for Last Call review by SECDIR is assigned to Liang Xia
2021-02-25
15 Tero Kivinen Request for Last Call review by SECDIR is assigned to Liang Xia
2021-02-25
15 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Joel Jaeggli
2021-02-25
15 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Joel Jaeggli
2021-02-24
15 Mehmet Ersue Request for Last Call review by YANGDOCTORS is assigned to Xufeng Liu
2021-02-24
15 Mehmet Ersue Request for Last Call review by YANGDOCTORS is assigned to Xufeng Liu
2021-02-24
15 Acee Lindem Assignment of request for Last Call review by YANGDOCTORS to Acee Lindem was rejected
2021-02-24
15 Mehmet Ersue Request for Last Call review by YANGDOCTORS is assigned to Acee Lindem
2021-02-24
15 Mehmet Ersue Request for Last Call review by YANGDOCTORS is assigned to Acee Lindem
2021-02-24
15 Marco Tiloca Requested Last Call review by YANGDOCTORS
2021-02-24
15 Amy Vezza IANA Review state changed to IANA - Review Needed
2021-02-24
15 Amy Vezza
The following Last Call announcement was sent out (ends 2021-03-17):<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: Carsten Bormann <cabo@tzi.org …
The following Last Call announcement was sent out (ends 2021-03-17):<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: Carsten Bormann <cabo@tzi.org>, 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: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-core-sid-15.txt> (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)'
  <draft-ietf-core-sid-15.txt> 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.




2021-02-24
15 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2021-02-24
15 Amy Vezza Last call announcement was changed
2021-02-24
15 Barry Leiba Last call was requested
2021-02-24
15 Barry Leiba Last call announcement was generated
2021-02-24
15 Barry Leiba Ballot approval text was generated
2021-02-24
15 (System) Changed action holders to Barry Leiba (IESG state changed)
2021-02-24
15 Barry Leiba IESG state changed to Last Call Requested from AD Evaluation
2021-02-08
15 Barry Leiba Ballot writeup was changed
2021-02-08
15 Barry Leiba IESG state changed to AD Evaluation from Publication Requested
2021-02-08
15 Jaime Jimenez Changed consensus to Yes from Unknown
2021-02-08
15 Jaime Jimenez Intended Status changed to Proposed Standard from None
2021-02-05
15 Jaime Jimenez
Document Writeup for Working Group Documents

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

| name and version    …
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: <https://mailarchive.ietf.org/arch/msg/netmod/ls3iMlnJYtRg6NMIAZLGMcSMNpA>
sid: <https://mailarchive.ietf.org/arch/msg/netmod/SMw0cJ_t-NcV6hfDNtf9lYqMp6U>
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:
<https://mailarchive.ietf.org/arch/msg/media-types/XMn1cIDryOtRbXdGJUHQCse1tGc>


* 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.
2021-02-05
15 Jaime Jimenez Responsible AD changed to Barry Leiba
2021-02-05
15 Jaime Jimenez IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2021-02-05
15 Jaime Jimenez IESG state changed to Publication Requested from I-D Exists
2021-02-05
15 Jaime Jimenez IESG process started in state Publication Requested
2021-02-04
15 Carsten Bormann
Document Writeup for Working Group Documents

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

| name and version    …
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: <https://mailarchive.ietf.org/arch/msg/netmod/ls3iMlnJYtRg6NMIAZLGMcSMNpA>
sid: <https://mailarchive.ietf.org/arch/msg/netmod/SMw0cJ_t-NcV6hfDNtf9lYqMp6U>
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:
<https://mailarchive.ietf.org/arch/msg/media-types/XMn1cIDryOtRbXdGJUHQCse1tGc>


* 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.
2021-01-17
15 Ivaylo Petrov New version available: draft-ietf-core-sid-15.txt
2021-01-17
15 (System) New version accepted (logged-in submitter: Ivaylo Petrov)
2021-01-17
15 Ivaylo Petrov Uploaded new revision
2021-01-05
14 (System) Document has expired
2020-09-26
14 Marco Tiloca IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document
2020-09-10
14 Marco Tiloca
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 …
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)
2020-07-30
14 Marco Tiloca IETF WG state changed to WG Document from In WG Last Call
2020-07-25
14 Marco Tiloca Added to session: IETF-108: core  Fri-1410
2020-07-17
14 Marco Tiloca IETF WG state changed to In WG Last Call from WG Document
2020-07-04
14 Ivaylo Petrov New version available: draft-ietf-core-sid-14.txt
2020-07-04
14 (System) New version accepted (logged-in submitter: Ivaylo Petrov)
2020-07-04
14 Ivaylo Petrov Uploaded new revision
2020-06-04
13 Ivaylo Petrov New version available: draft-ietf-core-sid-13.txt
2020-06-04
13 (System) New version accepted (logged-in submitter: Ivaylo Petrov)
2020-06-04
13 Ivaylo Petrov Uploaded new revision
2020-05-04
12 Jaime Jimenez IETF WG state changed to WG Document from In WG Last Call
2020-03-27
12 Ivaylo Petrov New version available: draft-ietf-core-sid-12.txt
2020-03-27
12 (System) New version accepted (logged-in submitter: Ivaylo Petrov)
2020-03-27
12 Ivaylo Petrov Uploaded new revision
2020-03-09
11 Carsten Bormann IETF WG state changed to In WG Last Call from WG Document
2020-03-09
11 Carsten Bormann Notification list changed to Carsten Bormann <cabo@tzi.org>
2020-03-09
11 Carsten Bormann Document shepherd changed to Carsten Bormann
2020-03-04
11 Ivaylo Petrov New version available: draft-ietf-core-sid-11.txt
2020-03-04
11 (System) New version accepted (logged-in submitter: Ivaylo Petrov)
2020-03-04
11 Ivaylo Petrov Uploaded new revision
2020-02-12
10 Ivaylo Petrov New version available: draft-ietf-core-sid-10.txt
2020-02-12
10 (System) New version accepted (logged-in submitter: Ivaylo Petrov)
2020-02-12
10 Ivaylo Petrov Uploaded new revision
2020-01-23
09 Ivaylo Petrov New version available: draft-ietf-core-sid-09.txt
2020-01-23
09 (System) New version accepted (logged-in submitter: Ivaylo Petrov)
2020-01-23
09 Ivaylo Petrov Uploaded new revision
2020-01-08
08 Ivaylo Petrov New version available: draft-ietf-core-sid-08.txt
2020-01-08
08 (System) New version accepted (logged-in submitter: Ivaylo Petrov)
2020-01-08
08 Ivaylo Petrov Uploaded new revision
2019-07-08
07 Ivaylo Petrov New version available: draft-ietf-core-sid-07.txt
2019-07-08
07 (System) New version approved
2019-07-08
07 (System) Request for posting confirmation emailed to previous authors: Ivaylo Petrov <ivaylo@ackl.io>, Alexander Pelov <a@ackl.io>, Michel Veillette <michel.veillette@trilliant.com>
2019-07-08
07 Ivaylo Petrov Uploaded new revision
2019-03-28
06 Ivaylo Petrov New version available: draft-ietf-core-sid-06.txt
2019-03-28
06 (System) New version approved
2019-03-28
06 (System) Request for posting confirmation emailed to previous authors: Ivaylo Petrov <ivaylo@ackl.io>, Alexander Pelov <a@ackl.io>, Michel Veillette <michel.veillette@trilliant.com>
2019-03-28
06 Ivaylo Petrov Uploaded new revision
2018-12-19
05 Ivaylo Petrov New version available: draft-ietf-core-sid-05.txt
2018-12-19
05 (System) New version approved
2018-12-19
05 (System) Request for posting confirmation emailed to previous authors: Alexander Pelov <a@ackl.io>, core-chairs@ietf.org, Michel Veillette <michel.veillette@trilliant.com>
2018-12-19
05 Ivaylo Petrov Uploaded new revision
2018-12-06
04 (System) Document has expired
2018-06-04
04 Michel Veillette New version available: draft-ietf-core-sid-04.txt
2018-06-04
04 (System) New version approved
2018-06-04
04 (System) Request for posting confirmation emailed to previous authors: Michel Veillette <michel.veillette@trilliantinc.com>, core-chairs@ietf.org, Alexander Pelov <a@ackl.io>
2018-06-04
04 Michel Veillette Uploaded new revision
2018-06-04
03 (System) Document has expired
2017-12-01
03 Michel Veillette New version available: draft-ietf-core-sid-03.txt
2017-12-01
03 (System) New version approved
2017-12-01
03 (System) Request for posting confirmation emailed to previous authors: Michel Veillette <michel.veillette@trilliantinc.com>, Alexander Pelov <a@ackl.io>
2017-12-01
03 Michel Veillette Uploaded new revision
2017-10-30
02 Michel Veillette New version available: draft-ietf-core-sid-02.txt
2017-10-30
02 (System) New version approved
2017-10-30
02 (System)
Request for posting confirmation emailed to previous authors: core-chairs@ietf.org, Ana Minaburo <ana@ackl.io>, Alexander Pelov <a@ackl.io>, Michel Veillette <michel.veillette@trilliantinc.com>, …
Request for posting confirmation emailed to previous authors: core-chairs@ietf.org, Ana Minaburo <ana@ackl.io>, Alexander Pelov <a@ackl.io>, Michel Veillette <michel.veillette@trilliantinc.com>, Randy Turner <randy.turner@landisgyr.com>, Abhinav Somaraju <abhinav.somaraju@tridonic.com>
2017-10-30
02 Michel Veillette Uploaded new revision
2017-05-02
01 Michel Veillette New version available: draft-ietf-core-sid-01.txt
2017-05-02
01 (System) New version approved
2017-05-02
01 (System)
Request for posting confirmation emailed to previous authors: Michel Veillette <michel.veillette@trilliantinc.com>, Ana Minaburo <ana@ackl.io>, Alexander Pelov <a@ackl.io>, Abhinav Somaraju …
Request for posting confirmation emailed to previous authors: Michel Veillette <michel.veillette@trilliantinc.com>, Ana Minaburo <ana@ackl.io>, Alexander Pelov <a@ackl.io>, Abhinav Somaraju <abhinav.somaraju@tridonic.com>, Randy Turner <randy.turner@landisgyr.com>
2017-05-02
01 Michel Veillette Uploaded new revision
2016-10-31
00 Carsten Bormann This document now replaces draft-somaraju-core-sid instead of None
2016-10-31
00 Michel Veillette New version available: draft-ietf-core-sid-00.txt
2016-10-31
00 (System) WG -00 approved
2016-10-26
00 Michel Veillette Set submitter to "Michel Veillette <michel.veillette@trilliantinc.com>", replaces to draft-somaraju-core-sid and sent approval email to group chairs: core-chairs@ietf.org
2016-10-26
00 Michel Veillette Uploaded new revision