YANG-CBOR: Allocating SID ranges for PEN holders
draft-ietf-core-yang-sid-pen-06

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-core-yang-sid-pen-06; we had also reviewed -03 of this document in a previous Last Call. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which we must complete.

First, in the YANG-SID Mega-Ranges registry in the YANG SIDs registry group located at:

https://www.iana.org/assignments/yang-sid/

two new SID mega-ranges are allocated as follows:

Entry Point: 3 000 000 000
Size: 1 000 000 000
Allocation: Private
Org Name: IANA
URL: [ RFC-to-be ]

Entry Point: 300 000 000 000
Size: 100 000 000 000
Allocation: Private
Org Name: IANA
URL: [ RFC-to-be ]

Second, also in the YANG-SID Mega-Ranges registry in the YANG SIDs registry group located at:

https://www.iana.org/assignments/yang-sid/

IANA will mark the below ranges as reserved for documentation:

Entry Point: 3 324 730 000
Size: 10,000
Registration Procedure: Reserved for Documentation

Entry Point: 303 247 300 000
Size: 100,000
Registration Procedure: Reserved for Documentation

We understand that these are the only action 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.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2026-01-13):

From: The IESG
To: IETF-Announce
CC: core-chairs@ietf.org, core@ietf.org, draft-ietf-core-yang-sid-pen@ietf.org, marco.tiloca@ri.se, mbishop@evequefou.be
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (YANG-CBOR: Allocating SID ranges for PEN holders) to Proposed Standard


The IESG has received a request from the Constrained RESTful Environments WG
(core) to consider the following document: - 'YANG-CBOR: Allocating SID
ranges for PEN holders'
  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 2026-01-13. 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-CBOR (RFC 9254, "Encoding of Data Modeled with YANG in the
  Concise Binary Object Representation (CBOR)") defines YANG Schema
  Item iDentifiers (YANG SID), globally unique 63-bit unsigned integers
  used to identify YANG items.  RFC 9595 ("YANG Schema Item iDentifier
  (YANG SID)") defines ways to allocate these SIDs on the basis of IANA
  registries.

  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.


  // The present revision –06 is a resubmission of -05 with "Intended
  // Status: Standards Track", after IESG discussion pointed into this
  // direction.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-core-yang-sid-pen/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Writeup for draft-ietf-core-yang-sid-pen

Document status: https://datatracker.ietf.org/doc/draft-ietf-core-yang-sid-pen/

Document Shepherd: Marco Tiloca

Area Director: Mike Bishop


## Document Summary

Through IANA actions, this document allocates ranges of YANG Schema Item iDentifiers (YANG SIDs) for certain current or future holders of IANA-registered Private Enterprise Numbers (PENs). It builds on allocation mechanisms defined in RFC 9595.

Based on a DISCUSS ballot and the discussion at the IESG Telechat on 2025-12-18, the originally intended RFC status Informational changed to Proposed Standard and a new IETF Last Call was requested.


## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement?

  The WG has reached broad agreement and strong consensus on this document.

2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough?

  There has been no controversy during the development of this document.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize 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.

4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as RFC 7942 recommends) or elsewhere (where)?

  Not applicable, since this is not a protocol document.


### Additional Reviews

5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place.

  This document solidly builds on concepts and mechanisms also developed in the same Working Group CoRE (see RFC 9254 and RFC 9595). Careful consideration, feedback, and reviews have beeen provided by Working Group participants, including co-authors of the above mentioned specifications.

  Reviews from other IETF Working Groups or external organizations have not been deemed necessary.

6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  Not applicable.

7. If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation 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 RFC 8342?

  Not applicable.

8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.

  Not applicable.


### Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director?

  The Shepherd fully supports the document and believes it to be ready.

10. Several IETF Areas have assembled lists of common issues that their reviewers encounter. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews?

    None of the common issues from the IETF areas has been identified as applicable to this document.

11. What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent?

    Publication of the document was requested with intended RFC status Informational. The Working Group deemed it to be sufficient for the intent of the document, namely allocating ranges of YANG SIDs and specifically allocating SID mega-ranges as per RFC 9595, together with considerations that put such allocations in context.

    Based on a DISCUSS ballot, the discussion at the IESG Telechat on 2025-12-18 concluded that some ADs are uncomfortable seeing such a large allocation happen in an Informational document. Consequently, the intended RFC status was changed to Proposed Standard and a new IETF Last Call was requested.

    All Datatracker state attributes correctly reflect this intent.

12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in BCP 79? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable.

    Each author has stated that they do not have direct, personal knowledge of any IPR related to this document. The Shepherd is not aware of any IPR either, and no IPR discussion about this document has occurred in the CoRE WG.

13. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification.

    Yes.

14. Document any remaining I-D nits in this document. Simply running the idnits tool is not enough; please review the "Content Guidelines" on authors.ietf.org.

    The two comments raised by idnits tool can be safely ignored:

    * "Duplicate reference: RFC9595, mentioned in 'RFC9595', was also mentioned in 'RFC9254'." does not seem to match with the content of the document.

    * In Section 3, the reference to RFC 1065 (and not to RFC 1155 obsoleting it) is intentional, in order to confirm to the largest extent that "PENs have been around for decades".

    The document complies with the "Content Guidelines" on authors.ietf.org.

15. Should any informative references be normative or vice-versa? See the IESG Statement on Normative and Informative References.

    References are listed in the appropriate category.

16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references?

    All the normative references are freely available.

17. Are there any normative downward references (see RFC 3967 and BCP 97) that are not already listed in the DOWNREF registry? If so, list them.

    This document does not include any such normative reference.

18. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion?

    This document does not include any such normative reference.

19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed.

    No.

20. 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 aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see RFC 8126).

    The IANA considerations in Section 4 are about the requested allocations of SID mega-ranges, as per RFC 9595. These considerations are exhaustive, and they are supported by clarifications on the expected technical capacity for sustained operations in the involved IANA registries.

    Before IETF 124, version -02 of the document received an early review from IANA, asking to include the requested registrations to the YANG-SID Mega-Ranges also as a table. This request was addressed in version -03 of the document.

21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate.

    Not applicable.

Because this makes a substantial allocation, there was IESG feedback that this should happen in a PS document. That will entail an additional Last Call, but not a new IESG telechat.

[Ballot comment]
# Andy Newton, ART AD, comments for draft-ietf-core-yang-sid-pen-04
CC @anewton1998

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-core-yang-sid-pen-04.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

Thanks to Joseph Yee for his ARTART review.

## Comments

I support Eric's DISCUSS around the IANA issues.

[Ballot discuss]

# Éric Vyncke INT AD comments for draft-ietf-core-yang-sid-pen-04
CC @evyncke

Thank you for the work put into this document.

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

Special thanks to Marco Tiloca for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status (even if I do not agree with "informational").

Other thanks to Ines Robles, the IoT directorate reviewer (at my request) and on very short notice (I-D was placed late on the telechat agenda), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-core-yang-sid-pen-04-iotdir-telechat-robles-2025-12-14/ (the author has probably not yet time to reply)

I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues.

## DISCUSS (blocking)

As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise.

### Intended publication status

This I-D heavily modifies a registry (even if this specific registry is "expert review") by pre-allocating a huge amount of values and it should be "proposed standards" rather than "informational" as the registry was created by RFC 9595, which is standards track.

### Broken IANA reference

I have read the author's note about broken bib.ietf.org service for IANA.enterprise-numbers. This document should not progress with such a broken link. I.e., I am holding a DISCUSS until the problem is solved by the tools team.

### Use of the documentation PEN

I support Med's comment and I elevate to the DISCUSS level, please use the documentation PEN 32473.

### Ambiguity between < 100,000 and < 1,000,000

I second Ines in her IoT-directorate review about the ambiguity of the first < 100,000 and < 1,0000,000 PEN holders, do they have both ranges ? It seems so but then guidance should be given.

[Ballot comment]

## COMMENTS (non-blocking)

### Section 1

It is very hard to understand the logic for non CORE/SID readers... please state in the text that 32-bit SIDs are better compressed than 63-bit SIDs (if not mistaken), i.e., 32-bit SIDs have "more value". Else, the logic completely is unclear.

Suggest to start the final bullet list with the 'small PEN' for better understanding.

### Section 4

Please use a URI as a reference to the IANA registry to avoid any ambiguity, e.g., https://www.iana.org/assignments/yang-sid/yang-sid.xhtml#sid-mega-range (if not mistaken)

Please add a reference to section 6.3.2 of RFC 9595 after `The allocation policy inside the mega-range is "private"`

[Ballot comment]
# Internet AD comments for draft-ietf-core-yang-sid-pen-04
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

* NOTE: full disclosure, I am the registrant of a PEN.

[Ballot comment]
Hi Carsten,

Thanks for the continued effort to work on YANG-CBOR/SIDs, and this document in particular.

Thanks to both Dhruv and Nabeel for their reviews and Carsten for engaging and changes.

The approach looks good to me. Please find below some few comments:

# 32473

As a side effect of this policy, two SIDs ranges are thus available for documentation purposes as well. I would call out these explicitly in the document.

# Please use 32473 for this example + companion range explanation

CURRENT:
  The Department for Mathematics and Computer Science of Universität
  Bremen holds PEN 30810.

Refer to the IESG statement on the matter: https://datatracker.ietf.org/doc/statement-iesg-statement-on-assignable-codepoints-for-examples-in-ietf-specifications/ (see the first sentence of the last para of the statement).

# nits: The abstract should be self-contained. Please add RFC titles in the abstract.

Cheers,
Med

[Ballot comment]
Hi Carsten,

Thanks for the continued effort to work on YANG-CBOR/SIDs, and this document in particular.

Thanks to both Dhruv and Nabeel for their reviews and Carsten for engaging and changes.

The approach looks good to me. Please find below some few comments:

# 32473

As a side effect of this policy, two SIDs ranges are thus available for documentation purposes as well. I would call out these explicitly in the document.

# Please use 32473 for this example + companion range explanation

CURRENT:
  The Department for Mathematics and Computer Science of Universität
  Bremen holds PEN 30810.

Refer to the IESG statement on the matter: https://datatracker.ietf.org/doc/statement-iesg-statement-on-assignable-codepoints-for-examples-in-ietf-specifications/

# nits: The abstract should be self-contained. Please add RFC titles in the abstract.

Cheers,
Med

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-core-yang-sid-pen-03. If any part of this review is inaccurate, please let us know.

IANA has a question about the action requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there is a single action which we must complete.

In the YANG-SID Mega-Ranges registry in the YANG SIDs registry group located at:

https://www.iana.org/assignments/yang-sid/

two new SID mega-ranges are allocated as provided by [RFC9595] as follows:

Entry Point: 3 000 000 000 up to 3 999 999 999
Size: 1 000 000 000
Allocation: Private
Org Name: IANA
URL: [ RFC-to-be ]

Entry Point: 300 000 000 000 up to 399 999 999 999
Size: 100 000 000 000
Allocation: Private
Org Name: IANA
URL: [ RFC-to-be ]

IANA Question -> Should a note be added to the registry that indicates how the management of the SID blocks is intended to work (for instance, the third and fourth paragraphs after Table 1 in Section 4 of the current draft)?

We understand that this is the only action required to be completed upon approval of this document.

NOTE: The action 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 action that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-12-05):

From: The IESG
To: IETF-Announce
CC: core-chairs@ietf.org, core@ietf.org, draft-ietf-core-yang-sid-pen@ietf.org, marco.tiloca@ri.se, mbishop@evequefou.be
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (YANG-CBOR: Allocating SID ranges for PEN holders) to Informational RFC


The IESG has received a request from the Constrained RESTful Environments WG
(core) to consider the following document: - 'YANG-CBOR: Allocating SID
ranges for PEN holders'
  as Informational RFC

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 2025-12-05. 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-CBOR (RFC 9254) defines YANG Schema Item iDentifiers (YANG SID),
  globally unique 63-bit unsigned integers used to identify YANG items.
  RFC 9595 defines ways to allocate these SIDs on the basis of IANA
  registries.

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


  // The present revision –03 is intended to address the feedback from
  // the CoRE Working-Group last call.  Note that due to a regression
  // in the bib.ietf.org service (https://github.com/ietf-tools/bibxml-
  // service/issues/489 (https://github.com/ietf-tools/bibxml-service/
  // issues/489)), the reference [IANA.enterprise-numbers] may come out
  // as "*** BROKEN REFERENCE ***" in some CI systems; this will
  // certainly be fixed in the course of further processing.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-core-yang-sid-pen/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Writeup for draft-ietf-core-yang-sid-pen

Document status: https://datatracker.ietf.org/doc/draft-ietf-core-yang-sid-pen/

Document Shepherd: Marco Tiloca

Area Director: Mike Bishop


## Document Summary

Through IANA actions, this document allocates ranges of YANG Schema Item iDentifiers (YANG SIDs) for certain current or future holders of IANA-registered Private Enterprise Numbers (PENs). It builds on allocation mechanisms defined in RFC 9595.


## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement?

  The WG has reached broad agreement and strong consensus on this document.

2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough?

  There has been no controversy during the development of this document.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize 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.

4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as RFC 7942 recommends) or elsewhere (where)?

  Not applicable, since this is not a protocol document.


### Additional Reviews

5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place.

  This document solidly builds on concepts and mechanisms also developed in the same Working Group CoRE (see RFC 9254 and RFC 9595). Careful consideration, feedback, and reviews have beeen provided by Working Group participants, including co-authors of the above mentioned specifications.

  Reviews from other IETF Working Groups or external organizations have not been deemed necessary.

6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  Not applicable.

7. If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation 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 RFC 8342?

  Not applicable.

8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.

  Not applicable.


### Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director?

  The Shepherd fully supports the document and believes it to be ready.

10. Several IETF Areas have assembled lists of common issues that their reviewers encounter. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews?

    None of the common issues from the IETF areas has been identified as applicable to this document.

11. What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent?

    The intended RFC status is Informational, since the document is about allocating ranges of YANG SIDs and specifically allocating SID mega-ranges as per RFC 9595, together with considerations that put such allocations in context.

    All Datatracker state attributes correctly reflect this intent.

12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in BCP 79? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable.

    Each author has stated that they do not have direct, personal knowledge of any IPR related to this document. The Shepherd is not aware of any IPR either, and no IPR discussion about this document has occurred in the CoRE WG.

13. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification.

    Yes.

14. Document any remaining I-D nits in this document. Simply running the idnits tool is not enough; please review the "Content Guidelines" on authors.ietf.org.

    The two comments raised by idnits tool can be safely ignored:

    * "Duplicate reference: RFC9595, mentioned in 'RFC9595', was also mentioned in 'RFC9254'." does not seem to match with the content of the document.

    * In Section 3, the reference to RFC 1065 (and not to RFC 1155 obsoleting it) is intentional, in order to confirm to the largest extent that "PENs have been around for decades".

    The document complies with the "Content Guidelines" on authors.ietf.org.

15. Should any informative references be normative or vice-versa? See the IESG Statement on Normative and Informative References.

    References are listed in the appropriate category.

16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references?

    All the normative references are freely available.

17. Are there any normative downward references (see RFC 3967 and BCP 97) that are not already listed in the DOWNREF registry? If so, list them.

    This document does not include any such normative reference.

18. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion?

    This document does not include any such normative reference.

19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed.

    No.

20. 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 aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see RFC 8126).

    The IANA considerations in Section 4 are about the requested allocations of SID mega-ranges, as per RFC 9595. These considerations are exhaustive, and they are supported by clarifications on the expected technical capacity for sustained operations in the involved IANA registries.

    Before IETF 124, version -02 of the document received an early review from IANA, asking to include the requested registrations to the YANG-SID Mega-Ranges also as a table. This request was addressed in version -03 of the document.

21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate.

    Not applicable.

# Document Shepherd Writeup for draft-ietf-core-yang-sid-pen

Document status: https://datatracker.ietf.org/doc/draft-ietf-core-yang-sid-pen/

Document Shepherd: Marco Tiloca

Area Director: Mike Bishop


## Document Summary

Through IANA actions, this document allocates ranges of YANG Schema Item iDentifiers (YANG SIDs) for certain current or future holders of IANA-registered Private Enterprise Numbers (PENs). It builds on allocation mechanisms defined in RFC 9595.


## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement?

  The WG has reached broad agreement and strong consensus on this document.

2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough?

  There has been no controversy during the development of this document.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize 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.

4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as RFC 7942 recommends) or elsewhere (where)?

  Not applicable, since this is not a protocol document.


### Additional Reviews

5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place.

  This document solidly builds on concepts and mechanisms also developed in the same Working Group CoRE (see RFC 9254 and RFC 9595). Careful consideration, feedback, and reviews have beeen provided by Working Group participants, including co-authors of the above mentioned specifications.

  Reviews from other IETF Working Groups or external organizations have not been deemed necessary.

6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  Not applicable.

7. If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation 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 RFC 8342?

  Not applicable.

8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.

  Not applicable.


### Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director?

  The Shepherd fully supports the document and believes it to be ready.

10. Several IETF Areas have assembled lists of common issues that their reviewers encounter. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews?

    None of the common issues from the IETF areas has been identified as applicable to this document.

11. What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent?

    The intended RFC status is Informational, since the document is about allocating ranges of YANG SIDs and specifically allocating SID mega-ranges as per RFC 9595, together with considerations that put such allocations in context.

    All Datatracker state attributes correctly reflect this intent.

12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in BCP 79? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable.

    Each author has stated that they do not have direct, personal knowledge of any IPR related to this document. The Shepherd is not aware of any IPR either, and no IPR discussion about this document has occurred in the CoRE WG.

13. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification.

    Yes.

14. Document any remaining I-D nits in this document. Simply running the idnits tool is not enough; please review the "Content Guidelines" on authors.ietf.org.

    The two comments raised by idnits tool can be safely ignored:

    * "Duplicate reference: RFC9595, mentioned in 'RFC9595', was also mentioned in 'RFC9254'." does not seem to match with the content of the document.

    * In Section 3, the reference to RFC 1065 (and not to RFC 1155 obsoleting it) is intentional, in order to confirm to the largest extent that "PENs have been around for decades".

    The document complies with the "Content Guidelines" on authors.ietf.org.

15. Should any informative references be normative or vice-versa? See the IESG Statement on Normative and Informative References.

    References are listed in the appropriate category.

16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references?

    All the normative references are freely available.

17. Are there any normative downward references (see RFC 3967 and BCP 97) that are not already listed in the DOWNREF registry? If so, list them.

    This document does not include any such normative reference.

18. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion?

    This document does not include any such normative reference.

19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed.

    No.

20. 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 aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see RFC 8126).

    The IANA considerations in Section 4 are about the requested allocations of SID mega-ranges, as per RFC 9595. These considerations are exhaustive, and they are supported by clarifications on the expected technical capacity for sustained operations in the involved IANA registries.

    Before IETF 124, version -02 of the document received an early review from IANA, asking to include the requested registrations to the YANG-SID Mega-Ranges also as a table. This request was addressed in version -03 of the document.

21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate.

    Not applicable.