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

[Amanda Baber <[e-mail]>]

Hi,

IANA currently makes ~230 YANG files available for download via rsync or FTP. Most of them are listed at https://www.iana.org/assignments/yang-parameters (the exception being older versions of IANA-maintained modules like iana-if-type, which are available in the repository but no longer linked from the registry). All of these files will be maintained permanently.

Are there different concerns associated with hosting SID files that IANA should be aware of? We understand that they'll be supplied to us by experts (unlike YANG files, which are extracted by us). 

Thanks,
Amanda

On 10/26/23, 6:18 AM, "iesg on behalf of Lars Eggert via Datatracker" <[e-mail] on behalf of [e-mail]> wrote:

    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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!PtGJab4!7ca56YR6TqhGGrzaeNc5yBYCgqXb6eID9CBMQWmOvk08BWZ_9l--3-EbAomx2xV-2EVnfAwWyMQyMC8Qk7sGrqI$ [ietf[.]org] 
    for more information about how to handle DISCUSS and COMMENT positions.


    The document, along with other ballot positions, can be found here:
    https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-core-sid/__;!!PtGJab4!7ca56YR6TqhGGrzaeNc5yBYCgqXb6eID9CBMQWmOvk08BWZ_9l--3-EbAomx2xV-2EVnfAwWyMQyMC8QWgKWI34$ [datatracker[.]ietf[.]org]



    ----------------------------------------------------------------------
    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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/gen-art/8dB4NrBDoGCKILyz2wvtvT6sqC0__;!!PtGJab4!7ca56YR6TqhGGrzaeNc5yBYCgqXb6eID9CBMQWmOvk08BWZ_9l--3-EbAomx2xV-2EVnfAwWyMQyMC8Q6lQ1z38$ [mailarchive[.]ietf[.]org]).

    ## 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://urldefense.com/v3/__https://github.com/larseggert/ietf-reviewtool__;!!PtGJab4!7ca56YR6TqhGGrzaeNc5yBYCgqXb6eID9CBMQWmOvk08BWZ_9l--3-EbAomx2xV-2EVnfAwWyMQyMC8QWiRP9Ms$ [github[.]com]), 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://urldefense.com/v3/__https://github.com/mnot/ietf-comments/blob/main/format.md__;!!PtGJab4!7ca56YR6TqhGGrzaeNc5yBYCgqXb6eID9CBMQWmOvk08BWZ_9l--3-EbAomx2xV-2EVnfAwWyMQyMC8QJBlff4g$ [github[.]com]
    [ICT]: https://urldefense.com/v3/__https://github.com/mnot/ietf-comments__;!!PtGJab4!7ca56YR6TqhGGrzaeNc5yBYCgqXb6eID9CBMQWmOvk08BWZ_9l--3-EbAomx2xV-2EVnfAwWyMQyMC8QnGLBSn4$ [github[.]com]
    [IRT]: https://urldefense.com/v3/__https://github.com/larseggert/ietf-reviewtool__;!!PtGJab4!7ca56YR6TqhGGrzaeNc5yBYCgqXb6eID9CBMQWmOvk08BWZ_9l--3-EbAomx2xV-2EVnfAwWyMQyMC8QWiRP9Ms$ [github[.]com]