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

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

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

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

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

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

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

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

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

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

        Once a module is declared stable

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

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

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

        like ships in the night.

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

-- What difficulty is expected in changing SID values?  

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

Thanks for working on this specification, I have no objection from TSV point of views.

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

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

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

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

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

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

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS

## Intended status

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

## YangCatalog.Org

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

## Section 1

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

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

## Section 2.1

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

## Section 2.2

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

## Section 2.4

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

## Section 3

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

## Section 6.4.3

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

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

## References

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

# GEN AD review of draft-ietf-core-sid-22

CC @larseggert

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

## Comments

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

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

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

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

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

## Nits

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

### Boilerplate

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

### Uncited references

Uncited references: `[RFC8792]`.

### Grammar/style

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

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

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

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

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

## Notes

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

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

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

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

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

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

Regards,
Rob