[auth48] Re: Final Review: RFC-to-be 9997 (draft-ietf-core-yang-sid-pen) in markdown

[Carsten Bormann <[e-mail]>]

On 2026-06-03, at 03:52, [e-mail] wrote:
> 
> Authors,
> 
> While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the source file.
> 
> 1) <!-- [rfced] We are having trouble parsing this text.  Please consider whether
> the suggested text conveys the intended meaning.  We suggest moving "also" to
> clarify they PEN holders are allocated an additional range.
> 
> Original:
>   The present specification employs these SID allocation mechanisms to
>   allocate ranges with 100 000 SIDs (representation size 64 bits) each
>   for each of the holders of IANA-registered Private Enterprise Numbers
>   (PENs) < 1 000 000, as well as ranges with 10 000 SIDs
>   (representation size 32 bits) each for each of the holders of PENs <
>   100 000.
> 
> Perhaps: 
>   The present specification employs these SID allocation mechanisms to
>   allocate ranges of 100 000 SIDs (representation size 64 bits) 
>   to each IANA Private Enterprise Number (PEN) holder of a value 
>   between 100 000 and 1 000 000.  Per this document, PEN holders of
>   values smaller than 100 000 are also allocated ranges of 10 000 SIDs 
>   (representation size 32 bits).
> -->

Thanks. The phrasing “each for each” is indeed suboptimal.
There is a problem with the “Perhaps” sentence: The 64-bit ranges are allocated to PEN holders of values < 1 000 000, which includes the range below 100 000.

Maybe:
  The present specification employs these SID allocation mechanisms to
  allocate ranges of 100 000 SIDs (representation size 64 bits) 
  to each holder of a IANA Private Enterprise Number (PEN) of a value 
  below 1 000 000.  Per this document, holders of PENs of
  values smaller than 100 000 are also allocated ranges of 10 000 SIDs 
  (representation size 32 bits).

(Compare approved document:

   The present specification employs these SID allocation mechanisms to
   allocate ranges with 100 000 SIDs (representation size 64 bits) each
   for each of the holders of IANA-registered Private Enterprise Numbers
   (PENs) < 1 000 000, as well as ranges with 10 000 SIDs
   (representation size 32 bits) each for each of the holders of PENs <
   100 000.
)

I could lose the “Per this document” as well, because that should be clear from the context as long as we stay in one paragraph, and maybe substitute the stronger “additionally":

Maybe2:
  The present specification employs these SID allocation mechanisms to
  allocate ranges of 100 000 SIDs (representation size 64 bits) 
  to each holder of a IANA Private Enterprise Number (PEN) of a value 
  below 1 000 000.  Holders of PENs of
  values smaller than 100 000 are additionally allocated ranges of 10 000 SIDs 
  (representation size 32 bits).

(But “<“ is still more economical than “of a value below”; note that we aren’t using “value” otherwise except when talking about SID deltas.)


> 2) <!-- [rfced] Perhaps the "Example" section title could be more descriptive?
> 
> Original:
>   2.  Example
> 
> Perhaps: 
>   2.  Example of SID Range Assignment for PEN 32473
> -->

Looks good, with two details:

* So far, the document uses “allocate” over “assign”.

(Note that the allocations don’t lead to individual assignments on http://www.iana.org/assignments .)

* We try to distinguish PENs from the holders of the PENs.

Maybe: 
  2.  Example: SID Range Allocation for Holder of PEN 32473

Maybe2: 
  2.  Example: SID Ranges for Holder of PEN 32473


> 3) <!-- [rfced] To highlight the PEN number in the SID range, we suggest the
> following update for clarity, rather than relying on a feature that displays
> differently in the various outputs:
> 
> Original:
>   *  3*03 247 3*00 000 up to 3*03 247 3*99 999, and
> 
>   *  3 *324 73*0 000 up to 3 *324 73*9 999.
> 
>   (The plaintext form of this document shows "*" characters around the
>   digits conveying the PEN, which are shown in *boldface* in the
>   typographic forms.)

While the difference in rendering is not a great outcome, the approved form seems to work very well visually in both.
Since that was a point of discussion in the approval process, I’d probably feel better if we could stick with them.

> Perhaps: 
> *  303 247 300 000 up to 303 247 399 999
>     (where "032473" are the digits conveying the PEN)
> 
> *  3 324 730 000 up to 3 324 739 999
>     (where "32473" are the digits conveying the PEN)
> 
> If not, we suggest updating this text to refer to "other typographic forms" or
> specify the HTML and PDF, because "typographic" seemingly includes the TXT file.

(The people from the Berthold type foundry I worked with in the 1980s would not have been amused…)

Maybe:
  (The plaintext form of this document shows "*" characters around the
  digits conveying the PEN, which are shown in *boldface* in the
  other renditions instead.)

> 4) <!-- [rfced] As we believe "this allocation" refers to the broader allocation
> of 100 000 and 10 000 SID ranges to PEN holders and does not refer to the
> example specified in the preceding section, we suggest updating the text for
> clarity.  

Right.
(“This allocation” could point to the process of allocating ranges to a PEN holder, to the actual individual allocation enabled by this process, or to the mega-range allocations in Section 4.
With each interpretation, the overall sentence means the same, but the ambiguity is still a weakness.)

> Please clarify "employing this number space" - does it mean use of
> SID values from these ranges?

Yes.
(The PEN holder would choose to use these values in SID files they generate for their YANG modules.)

> Original: 
>   This allocation provides an extremely-low-threshold (zero-
>   interaction) way for PEN holders to get number space for the YANG
>   SIDs used in their YANG modules.  If a PEN is not already available
>   to the entity needing such number space, it can be obtained in a very
>   low-threshold process.  Employing this number space is, however, not
>   always the approach to recommend to a module author:
> 
>   *  In the larger of the two spaces, each SID number needs a
>      ... 
> 
> Perhaps: 
>   Allocation of the two mega-ranges provides PEN holders with an extremely-low-threshold (zero-
>   interaction) way to get a number space for the YANG
>   SIDs used in their YANG modules.  If a PEN is not already available
>   to the entity needing such a number space, it can be obtained through a very
>   low-threshold process.  However, use of values in these mega-ranges is not
>   always the recommended approach for a module author:
> 
>   *  In the larger of the two spaces, each SID number needs a
>      ... 
> -->

Maybe: 
  This document assigns two mega-ranges to an extremely-low-threshold (zero-
  interaction) way for a PEN holder to obtain a number space for the YANG
  SIDs used in their YANG modules.  If a PEN is not already available
  to the entity needing such a number space, it can be obtained through a very
  low-threshold process.  However, use of values in these mega-ranges is not
  always the recommended approach for a module author:

> 
> 5) <!-- [rfced] May we update "< 100 000" for clarity? 

(< 100 000 is so much more clear than any English can be, but OK…)

> Original:
>   *  For the holders of PENs < 100 000, there additionally is a smaller
>      space where each SID number needs a representation size of 32 bits
>      ("32-bit SIDs").  PEN numbers that have access to this space (PEN
>      < 100 000) are likely to run out before or around 2040; the
>      expectation is that by that time there will be enough
>      opportunities to request SID ranges within mega-ranges allocated
>      by other registrants that this mechanism is less needed.
> 
> Perhaps:
>   * For the holders of PENs with values less than 100 000 in the 
>     "Private Enterprise Numbers (PENs)" registry, there is an another smaller 
>     space because each SID number needs a representation size of 32 bits 
>     ("32-bit SIDs"). By or around 2040, the PENs with a value less than 
>     100 000 are likely to be exhausted; the expectation is that there will be
>     enough opportunities by that time to request SID ranges within mega-ranges 
>     already allocated by other registrants that this mechanism is less needed.
> -->
> 

Maybe:
  * For the holders of PENs with values less than 100 000 in the 
    "Private Enterprise Numbers (PENs)" registry, there is another smaller 
    space of SID numbers that need a representation size of 32 bits 
    ("32-bit SIDs"). By or around 2040, the PENs with a value less than 
    100 000 are likely to be exhausted; the expectation is that there will be
    enough opportunities by that time to request SID ranges within mega-ranges 
    already allocated by other registrants that this mechanism is less needed.

(See also 1 above.)


> 6) <!-- [rfced] We suggest updating "This space" for clarity.  Perhaps "This
> process" or "This document"?
> 
> Original: 
>   *  This space has no infrastructure to discover the YANG module
>      behind a SID. 
> 
> Perhaps A:
>   *  This process does not have an infrastructure to discover the YANG module
>      behind a SID. 
> 
> Perhaps B: 
>   *  This document does not define infrastructure to discover the YANG module
>      behind a SID. 
> -->

Maybe:
  *  This document does not define infrastructure to discover the YANG module
     behind a SID in one of its ranges. 


> 7) <!-- [rfced] To provide the reader with more information, we suggest the
> following update:
> 
> Original:
>      -  Implementations that employ PEN-based SIDs can facilitate
>         information discovery by providing [I-D.ietf-core-yang-library]
>         or another form of YANG library [RFC8525].
> 
> Perhaps:
>      -  Implementations that employ PEN-based SIDs can facilitate
>         information discovery by providing a constrained version of 
>         the YANG library [core-yang-library]
>         or another form of YANG library [RFC8525].
> -->
> 

Looking at the sentence again:

Perhaps:
     -  Implementations that employ PEN-based SIDs can facilitate
        information discovery by providing a form of YANG library [RFC8525], such as a constrained version [core-yang-library].

(This looks like it de-emphasizes the unfinished draft a bit, but users of this document will already have other reasons to decide between the forms of YANG library.)


> 8) <!-- [rfced] Would you like to clarify the figurative use of "land grab" here?
> 
> Original:
>   Relying on the PEN registry might theoretically trigger a land-grab
>   by prospective writers of YANG modules.
> 
> Perhaps:
>   Relying on the PEN registry might theoretically trigger a land grab
>   (of PEN assignments) by prospective writers of YANG modules.
> -->

Good point.  Not sure we need to put this as a parenthesis:

Maybe:
  Relying on the PEN registry might theoretically trigger a land grab
  of PEN assignments by prospective writers of YANG modules.

> 9) <!-- [rfced] Note that we have removed #links per IANA's preference.  We also
> added a list to introduce the mega ranges.  Please review and let us know if
> any updates are needed. -->

I think by now everybody at RPC and IANA knows why I think this is a mistake, but we don’t need to replay the discussion...

> 10) <!--[rfced] Regarding preventing line breaks within numbers, we see that
> NARROW NO-BREAK SPACE (U+202F) was used within numbers in the original. 
> In RFCs, non-breaking space (U+00A0) has been used to prevent line
> breaks; do you want to use that? An example of where preventing line 
> breaks may be desired:
> 
> Current:
>   The management of each SID block of 100 000 SIDs, ranging from 3pp
>   ppp p00 000 to 3pp ppp p99 999, is delegated to the PEN holder for
>   PEN ppp ppp (i.e., the PEN holder for ppp ppp controls SID 3pp ppp
>   p00 000 to 3pp ppp p99 999).
> 
> Perhaps:
>   The management of each SID block of 100 000 SIDs, ranging from
>   3pp ppp p00 000 to 3pp ppp p99 999, is delegated to the PEN holder for
>   PEN ppp ppp (i.e., the PEN holder for ppp ppp controls SID
>   3pp ppp p00 000 to 3pp ppp p99 999)
> -->

I used U+202F because I wanted to combine two properties [1]:
* Non-breaking (which is also offered by U+00A0)
* Thin space (as in U+2009), keeping the number visually together (as opposed to the ASCII-like rendering your mail reader will probably show above).

[1]: https://jkorpela.fi/chars/spaces.html

U+00A0 certainly is the closest approximation in use by the RFC editor today.

Depending on what browser width I choose, with the rfc9997.x files I see rendering like:



The file rfc9997.md I got does not appear to have any non-ASCII characters in it except for the ä in Universität (echars is part of kramdown-rfc):

$ echars rfc9997.md
*** Latin-1 Supplement (Latin)
ä: U+00E4    1 LATIN SMALL LETTER A WITH DIAERESIS

So something seems to have been lost.

                          .oOo.

Thank you for these questions; I’ll do a full check of the changes when these answers have flown into a next revision.

Grüße, Carsten