[core] Lars Eggert's Discuss on draft-ietf-core-sid-22: (with DISCUSS and COMMENT)

[Lars Eggert via Datatracker <[e-mail]>]

Lars Eggert has entered the following ballot position for
draft-ietf-core-sid-22: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-sid/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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

CC @larseggert

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

## Discuss

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

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

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


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

## Comments

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

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

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

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

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

## Nits

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

### Boilerplate

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

### Uncited references

Uncited references: `[RFC8792]`.

### Grammar/style

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

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

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

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

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

## Notes

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

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