Advertisement of Segment Routing Policies using BGP Link-State
draft-ietf-idr-bgp-ls-sr-policy-17

[Ballot comment]
I have my usual gripe in Section 5.1 about use of SHOULD [NOT] without any guidance about how to decide when it might be reasonable to deviate from the advice given.  Can we provide some?

[Ballot comment]
Section 7, paragraph 0
>    The Existing BGP operational and management procedures apply to this
>    document.  No new procedures are defined in this document.  The
>    considerations as specified in [RFC9552] apply to this document.

Thanks to Susan Harris for the Shepherd review and to Tina Tsou for the OPSDIR review. Susan in her writeup highlights some of the operational considerations that come from the OPSDIR review. I would agree that some of those considerations should be taken up by the SRv6ops WG as possible work items, instead of trying to address them in this document. The chairs of SRv6ops have been looped into that discussion. At this time, I do not feel additional updates are needed in this document.

Check whether Expert Review is an appropriate registration policy here.

No reference entries found for these items, which were mentioned in the text:
[draft-ietf-pce-segment-routing-policy-cp].

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Terms "his" and "her"; alternatives might be "they", "them", "their"

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

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.

Section 1, paragraph 15
>    This extensions specified in this document complement the BGP SR
>    Policy SAFI [I-D.ietf-idr-sr-policy-safi] and
>    [I-D.ietf-idr-bgp-sr-segtypes-ext] that are used to advertise SR
>    Policies from controllers to the headend routers using BGP by
>    enabling the reporting of the operational state of those SR Policies
>    back from the headend to the controllers.

s/This extensions specified/The extensions specified/

These URLs in the document did not return content:

* https://ieeexplore.ieee.org/document/8766220

Section 1, paragraph 9
> Policy headend nodes) via PCEP NIT: This extensions specified in this documen
>                                    ^^^^
The singular determiner "this" may not agree with the plural noun "extensions".
Did you mean "these"?

Section 1, paragraph 11
> m the headend to the controllers. s/This extensions specified/The extensions
>                                    ^^^^
The singular determiner "this" may not agree with the plural noun "extensions".
Did you mean "these"?

Section 5.6.1, paragraph 3
>  their paths. The types disjointness are described in section 3 of [RFC8800]
>                                      ^^^
The verb form "are" does not seem to match the subject "disjointness".

Section 5.6.2, paragraph 2
> ndicates that the computation may fallback to a lower level of disjointness
>                                  ^^^^^^^^
The word "fallback" is a noun. The verb is spelled with a space.

Section 5.6.2, paragraph 3
> ndicates that the computation may fallback to the default best path (e.g. IG
>                                  ^^^^^^^^
The word "fallback" is a noun. The verb is spelled with a space.

Section 5.6.6, paragraph 8
> -Flag: Indicates the SID-List is comprised of SRv6 SIDs when set and indicate
>                              ^^^^^^^^^^^^^^^
Did you mean "comprises" or "consists of" or "is composed of"?

Section 5.6.6, paragraph 8
>  SIDs when set and indicates it is comprised of SR/MPLS labels when clear. -
>                                ^^^^^^^^^^^^^^^
Did you mean "comprises" or "consists of" or "is composed of"?

Section 8.3, paragraph 3
> d/or controllers/applications in a secure manner within this trusted SR domai
>                              ^^^^^^^^^^^^^^^^^^
Consider replacing this phrase with the adverb "securely" to avoid wordiness.

[Ballot comment]
Thanks for working on this specification.

I have one comment, I think it would improve the understanding of the ask if addressed.

# Section 5.6.3 and 5.7.3 mention -

    If multiple instances are present, then the first valid one is used
  and the rest are ignored.

  How is that validity check done? A reference to the validity check procedure would be helpful here.

# Document Shepherd Write-Up for Group Documents
*This version is dated 4 July 2022.*


## 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?

Strong consensus with good discussions.
https://mailarchive.ietf.org/arch/msg/idr/PndHjsj0nj6fFZ97inb8iz8_Qvk/
https://mailarchive.ietf.org/arch/msg/idr/0dL1E-C74DUgkjyOlvFStqingfg/


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

No.  The discussion was active and provided good refinements to the draft.
  https://mailarchive.ietf.org/arch/browse/idr/?q=draft-ietf-idr-sr-bgp-ls-sr-policy

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][3] recommends) or elsewhere
  (where)?
2 implementations: See
https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-te-lsp-distribution

One implementation does not have PCE and BGP co-resident, so it does not
transmit the code to indicate the "reported via PCE" code.  The
Shepherd does not feel this should hold up standardization.

Both Huawei and Cisco have implemented nine of the TLVs.
Cisco has implemented all 18 of the TLVs.  One group of
TLVs not implemented by Huawei are the Constraint related
TLVs (SR CP Constraints, SR AFfinity Constraint, SR SRLG Constraint,
SR Bandwidth Constraint, SR Disjoint Group Constraint,
SR Bidirectional Group Constraint, SR Metric Sontraint).
The second group is the SR Segment list Bandwidth and the
SR Segment list Bandwidth. 

#Shepherd review page:
https://wiki.ietf.org/group/idr/Shepherd-SR-BGP-LS/BGP-LS-SR/bgp-ls-sr-policy

[you also go through the IDR wiki - See BGP-LS and SR Shepherd REviews)
Shepherd Reviews on SR and BGP-LS drafts
[https://wiki.ietf.org/group/idr/Shepherd-SR-BGP-LS]

## Additional Early Direcorate Reviews  Reviews
RTG-DIR (Joel Halpern): Ready with a few comments
SEC-DIR (Net Smith, 2/5): Ready with Nits
GEN-ART (Meral Shirazipour, 2/21) Ready
OPS-DIR (Tina Tsou): Has Issues regarding Scaling - addressed by Ketan
https://mailarchive.ietf.org/arch/msg/idr/PRhis-VEcyVEjQItu2VUYNLtj0Y/

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.

The BGP-LS for SR technologies closely interact with the spring and the srv6ops WG.
These WG were directly queried on 11/10/2024.

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.

The need for Yang models modeling this work has been added to:
https://wiki.ietf.org/group/idr/BGP-Model-Features

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

Not applicable since this is not a Yang model.

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?

Links to Shepherd's report is on IDR wiki
https://wiki.ietf.org/group/idr/Shepherd-SR-BGP-LS/BGP-LS-SR/bgp-ls-sr-policy

Mail lists:
See Shepherd's review prior to WG LC:
https://mailarchive.ietf.org/arch/msg/idr/DLfvkhT7HOClFSfUzFNQ9z8bSFc/

See Shepherd's review of -08/
https://mailarchive.ietf.org/arch/msg/idr/JW8IIxVTMer5-Qq7ld5ZCHXQ2sk/

Please note the Shepherd requested AD review of 3 items:
https://mailarchive.ietf.org/arch/msg/idr/JW8IIxVTMer5-Qq7ld5ZCHXQ2sk/
and
https://mailarchive.ietf.org/arch/msg/idr/CvA1crVQJVfTDl2yvjNp_8kcXRo/


Ketant's viewpoint is that
#15 = Maximum that fits in packet resolved by RFC9552/section 5.3
#18 and #30 - Ketan believes the metric types are not being consumed in
BGP-LS. As new IANA code points are added, the implementers will know what is
range and what is not. 

John Scudder  agreed with this viewpoint:
https://mailarchive.ietf.org/arch/msg/idr/bje6-B888d6Eykk7Q7IJ-GMM7wA/

RTG-DIR review (Joel Halpern, and OK)
https://mailarchive.ietf.org/arch/msg/idr/iuD4n-9b4-dMI1SQa1vkCPK7nfA/

OPS-DIR review (Tina Tsou, Has Issues - Resolved )
https://mailarchive.ietf.org/arch/msg/idr/PRhis-VEcyVEjQItu2VUYNLtj0Y/
Ketan's response indicates that explanations ask for repetition of information in
RFC9552 and RFC95256.  For consumer validation, the BGP-LS restates
that consumer of the BGP-LS information is outside the scope of BGP.
[The Shepherd has been through these issues with the authors, but the
OPS-AD should be warned to review this OPS-DIR review during
the AD evaluation. Better an early discussion that a late discovery.]

GEN-DIR (2/5, Ned Smith): Ready with NITS
https://mailarchive.ietf.org/arch/msg/secdir/f3JFqPR978Jq9_ypAT1Dn2UlxaE/
- Ned Smith noted 3 conventions unique to the BGP-LS work. 
  Ketan explained these conventions in his response.

SEC-DIR Review (2/26, Meral Shirazipour): Ready with NITs
- Only editoral


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?
Yes - a few points from section 9 are summarized for Routing and Security lists:

This is an extension of BGP-LS to manage/monitor SR policy for a truster SR domain [RFC8402].
It states:
a) SR operates within a trusted SR domain [RFC8402), and the security
considerations apply to this document.
b) Controllers and application services using the BGP-LS information are expected to
be within the trusted SR domain,
c) SR Policy data is critical data "that constitutes
a risk to [the] confidentiality of mission-critical or commercially sensitive" data. 

As always, BGP-ls traffic needs to be isolated from other BGP traffic (due to load)


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

Proposed Standard:
Why Proposed standard:  This draft augments proposed standards for
BGP-LS and SR in BGP (RFC9552, RFC9514, RFC9086).

Adding values to the following existing registries for BGP-LS:
a) BGP-LS NLRI-Types
b) BGP-LS Protocol-IDs
c) BGP-LS NLRI and Attribute TLV

The following registry related to BGP-LS and PCEP was
requested to be create: SR Policy Protocol Origin

The following new registries are created:
1.) BGP-LS SR Segment Descriptors
2) BGP-LS SR Policy Metric Type


12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? 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.

Ketan Talaulikar
https://mailarchive.ietf.org/arch/msg/idr/XNMFZ7_-GYwEVzALZF9aTylLWQQ/

Jie Dong:
https://mailarchive.ietf.org/arch/msg/idr/iuBOyS4Yuuiq1fgvbSZtPiHbLW4/

Jeff Tantsura
https://mailarchive.ietf.org/arch/msg/idr/9h3iYa7fzYE3lvNcOaeOeheBoiM/

Clarence Filsfils
https://mailarchive.ietf.org/arch/msg/idr/QaTiyYvGE5Yd6w1_JW_fz94ZpZs/


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][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

NITs check - just
https://mailarchive.ietf.org/arch/msg/idr/LyA6VOHdEJEuZjaV4HRaXnd8QzU/

NIT Check response:
https://mailarchive.ietf.org/arch/msg/idr/BwcU5Bmxd_7RyULcwQAcG5uTUmg/

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

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

No. All are RFCs.

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

No.

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?
No.

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][11]).

See IANA's early review of the document:
https://mailarchive.ietf.org/arch/msg/idr/Xw9HfBTseSO_2dfV7UDRwoqKNAM/

Adding values to the following existing registries
a) BGP-LS NLRI-Types
b) BGP-LS Protocol-IDs
c) BGP-LS NLRI and Attribute TLV

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.

1. SR Policy Protocol Origin registry - a new registry under "Segment Routing" 
with an allocation policy is "Expert Review" [RFC8126] using the guidelines for
Designated Experts as specified in [RFC9256].

2. SR Segment Descriptor Types - a new registry under "Border Gateway Protocol - Link State (BGP-LS) Parameters"
registry group with an allocation policy is "Expert Review" [RFC8126] using the guidelines for
Designated Experts as specified in [RFC9256].

3. BGP-LS SR Policy Metric Types - a new registry under "Border Gateway Protocol - Link State (BGP-LS) Parameters"
registry group with an allocation policy is "Expert Review" [RFC8126] using the guidelines for
Designated Experts as specified in [RFC9256].

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents
*This version is dated 4 July 2022.*


## 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?

Strong consensus with good discussions.
https://mailarchive.ietf.org/arch/msg/idr/PndHjsj0nj6fFZ97inb8iz8_Qvk/
https://mailarchive.ietf.org/arch/msg/idr/0dL1E-C74DUgkjyOlvFStqingfg/


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

No.  The discussion was active and provided good refinements to the draft.
  https://mailarchive.ietf.org/arch/browse/idr/?q=draft-ietf-idr-sr-bgp-ls-sr-policy

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][3] recommends) or elsewhere
  (where)?
2 implementations: See
https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-te-lsp-distribution

One implementation does not have PCE and BGP co-resident, so it does not
transmit the code to indicate the "reported via PCE" code.  The
Shepherd does not feel this should hold up standardization.

Both Huawei and Cisco have implemented nine of the TLVs.
Cisco has implemented all 18 of the TLVs.  One group of
TLVs not implemented by Huawei are the Constraint related
TLVs (SR CP Constraints, SR AFfinity Constraint, SR SRLG Constraint,
SR Bandwidth Constraint, SR Disjoint Group Constraint,
SR Bidirectional Group Constraint, SR Metric Sontraint).
The second group is the SR Segment list Bandwidth and the
SR Segment list Bandwidth. 

#Shepherd review page:
https://wiki.ietf.org/group/idr/Shepherd-SR-BGP-LS/BGP-LS-SR/bgp-ls-sr-policy

[you also go through the IDR wiki - See BGP-LS and SR Shepherd REviews)
Shepherd Reviews on SR and BGP-LS drafts
[https://wiki.ietf.org/group/idr/Shepherd-SR-BGP-LS]

## Additional Early Direcorate Reviews  Reviews
RTG-DIR (Joel Halpern): Ready with a few comments
SEC-DIR (Net Smith, 2/5): Ready with Nits
GEN-ART (Meral Shirazipour, 2/21) Ready
OPS-DIR (Tina Tsou): Has Issues regarding Scaling - addressed by Ketan
https://mailarchive.ietf.org/arch/msg/idr/PRhis-VEcyVEjQItu2VUYNLtj0Y/




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.

The BGP-LS for SR technologies closely interact with the spring and the srv6ops WG.
These WG were directly queried on 11/10/2024.

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.

The need for Yang models modeling this work has been added to:
https://wiki.ietf.org/group/idr/BGP-Model-Features

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

Not applicable since this is not a Yang model.

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?

Links to Shepherd's report is on IDR wiki
https://wiki.ietf.org/group/idr/Shepherd-SR-BGP-LS/BGP-LS-SR/bgp-ls-sr-policy

This may be an easy form to quick read.

Mail lists:
See Shepherd's review prior to WG LC:
https://mailarchive.ietf.org/arch/msg/idr/DLfvkhT7HOClFSfUzFNQ9z8bSFc/

See Shepherd's review of -08/
https://mailarchive.ietf.org/arch/msg/idr/JW8IIxVTMer5-Qq7ld5ZCHXQ2sk/

Please note the Shepherd requested AD review of 3 items:
https://mailarchive.ietf.org/arch/msg/idr/JW8IIxVTMer5-Qq7ld5ZCHXQ2sk/
and
https://mailarchive.ietf.org/arch/msg/idr/CvA1crVQJVfTDl2yvjNp_8kcXRo/


Ketant's viewpoint is that
#15 = Maximum that fits in packet resolved by RFC9552/section 5.3
#18 and #30 - Ketan believes the metric types are not being consumed in
BGP-LS. As new IANA code points are added, the implementers will know what is
range and what is not. 

John Scudder  agreed with this viewpoint:
https://mailarchive.ietf.org/arch/msg/idr/bje6-B888d6Eykk7Q7IJ-GMM7wA/

RTG-DIR review (and OK)
https://mailarchive.ietf.org/arch/msg/idr/iuD4n-9b4-dMI1SQa1vkCPK7nfA/

OPS-DIR review (Tina Tsou)
https://mailarchive.ietf.org/arch/msg/idr/PRhis-VEcyVEjQItu2VUYNLtj0Y/
Ketan's response indicates that explanations ask for repetition of information in
RFC9552 and RFC95256.  For consumer validation, the BGP-LS restates
that consumer of the BGP-LS information is outside the scope of BGP.
[The Shepherd has been through these issues with the authors, but the
OPS-AD should be warned to review this OPS-DIR review during
the AD evaluation. Better an early discussion that a late discovery.]


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?
Yes - a few points from section 9 are summarized for Routing and Security lists:

This is an extension of BGP-LS to manage/monitor SR policy for a truster SR domain [RFC8402].
It states:
a) SR operates within a trusted SR domain [RFC8402), and the security
considerations apply to this document.
b) Controllers and application services using the BGP-LS information are expected to
be within the trusted SR domain,
c) SR Policy data is critical data "that constitutes
a risk to [the] confidentiality of mission-critical or commercially sensitive" data. 

As always, BGP-ls traffic needs to be isolated from other BGP traffic (due to load)


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

Proposed Standard:

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? 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.

Ketan Talaulikar
https://mailarchive.ietf.org/arch/msg/idr/XNMFZ7_-GYwEVzALZF9aTylLWQQ/

Jie Dong:
https://mailarchive.ietf.org/arch/msg/idr/iuBOyS4Yuuiq1fgvbSZtPiHbLW4/

Jeff Tantsura
https://mailarchive.ietf.org/arch/msg/idr/9h3iYa7fzYE3lvNcOaeOeheBoiM/

Clarence Filsfils
https://mailarchive.ietf.org/arch/msg/idr/QaTiyYvGE5Yd6w1_JW_fz94ZpZs/


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][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

NITs check - just
https://mailarchive.ietf.org/arch/msg/idr/LyA6VOHdEJEuZjaV4HRaXnd8QzU/

NIT Check response:
https://mailarchive.ietf.org/arch/msg/idr/BwcU5Bmxd_7RyULcwQAcG5uTUmg/

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

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

No. All are RFCs.

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

No.

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?
No.

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][11]).

See IANA's early review of the document:
https://mailarchive.ietf.org/arch/msg/idr/Xw9HfBTseSO_2dfV7UDRwoqKNAM/

Adding values to the following existing registries
a) BGP-LS NLRI-Types
b) BGP-LS Protocol-IDs
c) BGP-LS NLRI and Attribute TLV

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.

1. SR Policy Protocol Origin registry - a new registry under "Segment Routing" 
with an allocation policy is "Expert Review" [RFC8126] using the guidelines for
Designated Experts as specified in [RFC9256].

2. SR Segment Descriptor Types - a new registry under "Border Gateway Protocol - Link State (BGP-LS) Parameters"
registry group with an allocation policy is "Expert Review" [RFC8126] using the guidelines for
Designated Experts as specified in [RFC9256].

3. BGP-LS SR Policy Metric Types - a new registry under "Border Gateway Protocol - Link State (BGP-LS) Parameters"
registry group with an allocation policy is "Expert Review" [RFC8126] using the guidelines for
Designated Experts as specified in [RFC9256].

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-idr-bgp-ls-sr-policy-14. If any part of this review is inaccurate, please let us know.

IANA understands that some of the actions requested in the IANA Considerations section of [ RFC-to-be ] are dependent upon the approval of and completion of IANA Actions in another document:

draft-ietf-pce-segment-routing-policy-cp

IANA understands that, upon approval of [ RFC-to-be ], there are six actions which we must complete.

First, in the BGP-LS NLRI Types registry in the Border Gateway Protocol - Link State (BGP-LS) Parameters registry group located at:

https://www.iana.org/assignments/bgp-ls-parameters/

the early registration for:

Type: 5
NLRI Type: SR Policy Candidate Path NLRI

will have its reference changed to [ RFC-to-be ].

Second, in the BGP-LS Protocol-IDs registry also in the Border Gateway Protocol - Link State (BGP-LS) Parameters registry group located at:

https://www.iana.org/assignments/bgp-ls-parameters/

the early registration for

Protocol-ID: 9
NLRI information source protocol: Segment Routing

will have its reference changed to [ RFC-to-be ].

Third, in the BGP-LS NLRI and Attribute TLVs registry in the Border Gateway Protocol - Link State (BGP-LS) Parameters registry group located at:

https://www.iana.org/assignments/bgp-ls-parameters/

the early registration for the following TLV Code Points will have their references changed to [ RFC-to-be ]:

TLV Code Point: 554 ; Description: SR Policy Candidate Path Descriptor
TLV Code Point: 1201 ; Description: SR Binding SID
TLV Code Point: 1202 ; Description: SR Candidate Path State
TLV Code Point: 1203 ; Description: SR Candidate Path Name
TLV Code Point: 1204 ; Description: SR Candidate Path Constraints
TLV Code Point: 1205 ; Description: SR Segment List
TLV Code Point: 1206 ; Description: SR Segment
TLV Code Point: 1207 ; Description: SR Segment List Metric
TLV Code Point: 1208 ; Description: SR Affinity Constraint
TLV Code Point: 1209 ; Description: SR SRLG Constraint
TLV Code Point: 1210 ; Description: SR Bandwidth Constraint
TLV Code Point: 1211 ; Description: SR Disjoint Group Constraint
TLV Code Point: 1212 ; Description: SRv6 Binding SID
TLV Code Point: 1213 ; Description: SR Policy Name
TLV Code Point: 1214 ; Description: SR Bidirectional Group Constraint
TLV Code Point: 1215 ; Description: SR Metric Constraint
TLV Code Point: 1216 ; Description: SR Segment List Bandwidth
TLV Code Point: 1217 ; Description: SR Segment List Identifier

Fourth, a new registry is to be created called the SR Policy Protocol Origin registry. The new registry will be located in the Segment Routing registry group located at:

https://www.iana.org/assignments/segment-routing/

IANA understands that this registry is being created in coordination with the approval of draft-ietf-pce-segment-routing-policy-cp and that, once approved, the reference for the registry should point to that document as well as the current [ RFC-to-be ]. The allocation policy for the new registry is Expert Review as defined in RFC8126. The new registry will have initial registrations from draft-ietf-pce-segment-routing-policy-cp. In addition, the new registry will have the following, initial allocations:

Code
Point Protocol Origin Reference
+---------+--------------------------------------+---------------+
0 Reserved (not to be used) [ RFC-to-be ]
1 PCEP [ RFC-to-be ]
2 BGP SR Policy [ RFC-to-be ]
3 Configuration (CLI, YANG model via [ RFC-to-be ]
NETCONF, etc.)
4-9 Unassigned
10 PCEP (In PCEP or when [ RFC-to-be ]
BGP-LS Producer is PCE)
11-19 Unassigned
20 BGP SR Policy (In PCEP or when [ RFC-to-be ]
BGP-LS Producer is PCE)
21-29 Unassigned
30 Configuration (CLI, YANG model via [ RFC-to-be ]
NETCONF, etc.) (In PCEP or when
BGP-LS Producer is PCE)
31-250 Unassigned
251-255 Private Use (not to be assigned by [ RFC-to-be ]
IANA

Fifth, a new registry is to be created called the SR Segment Descriptor Types registry. The new registry will be located in the Border Gateway Protocol - Link State (BGP-LS) Parameters registry group located at:

https://www.iana.org/assignments/bgp-ls-parameters/

The new registry is to be managed via Expert Review as defined in RFC8126. There are initial registrations in the new registry as follows:

Code Segment Description
Point Reference
--------+-----------------------------------------------------------+-------------
0 Reserved (not to be used) [ RFC-to-be ]
1 (Type A) SR-MPLS Label [ RFC-to-be ]
2 (Type B) SRv6 SID as IPv6 address [ RFC-to-be ]
3 (Type C) SR-MPLS Prefix SID as IPv4 Node Address [ RFC-to-be ]
4 (Type D) SR-MPLS Prefix SID as IPv6 Node Global Address [ RFC-to-be ]
5 (Type E) SR-MPLS Adjacency SID as IPv4 Node Address & [ RFC-to-be ]
Local Interface ID
6 (Type F) SR-MPLS Adjacency SID as IPv4 Local & Remote [ RFC-to-be ]
Interface Addresses
7 (Type G) SR-MPLS Adjacency SID as pair of IPv6 Global [ RFC-to-be ]
Address & Interface ID for Local & Remote nodes
8 (Type H) SR-MPLS Adjacency SID as pair of IPv6 Global [ RFC-to-be ]
Addresses for the Local & Remote Interface
9 (Type I) SRv6 END SID as IPv6 Node Global Address [ RFC-to-be ]
10 (Type J) SRv6 END.X SID as pair of IPv6 Global Address & [ RFC-to-be ]
Interface ID for Local & Remote nodes
11 (Type K) SRv6 END.X SID as pair of IPv6 Global Addresses [ RFC-to-be ]
for the Local & Remote Interface
12-255 Unassigned

Sixth, a new registry is to be created called the BGP-LS SR Policy Metric Type registry. The new registry will also be located in the Border Gateway Protocol - Link State (BGP-LS) Parameters registry group located at:

https://www.iana.org/assignments/bgp-ls-parameters/

The new registry is to be managed via Expert Review as defined in RFC8126. There are initial registrations in the new registry as follows:

Code
Point Metric Type Reference
---------+--------------------------------+---------------------
0 IGP [ RFC-to-be ]
1 Min Unidirectional Delay [ RFC-to-be ]
2 TE [ RFC-to-be ]
3 Hop Count [ RFC-to-be ]
4 SID List Length [ RFC-to-be ]
5 Bandwidth [ RFC-to-be ]
6 Avg Unidirectional Delay [ RFC-to-be ]
7 Unidirectional Delay Variation [ RFC-to-be ]
8 Loss [ RFC-to-be ]
9-127 Unassigned
128-255 User Defined [ RFC-to-be ]

We understand that these are the only actions required to be completed upon approval of [ RFC-to-be ].

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 2025-02-27):

From: The IESG
To: IETF-Announce
CC: draft-ietf-idr-bgp-ls-sr-policy@ietf.org, idr-chairs@ietf.org, idr@ietf.org, jgs@juniper.net, shares@ndzh.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Advertisement of Segment Routing Policies using BGP Link-State) to Proposed Standard


The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document: - 'Advertisement of Segment Routing Policies
using BGP Link-State'
  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 2025-02-27. 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


  This document describes a mechanism to collect the Segment Routing
  Policy information that is locally available in a node and advertise
  it into BGP Link-State (BGP-LS) updates.  Such information can be
  used by external components for path computation, re-optimization,
  service placement, network visualization, etc.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-sr-policy/



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

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*


## 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?

Strong consensus with good discussions.
https://mailarchive.ietf.org/arch/msg/idr/PndHjsj0nj6fFZ97inb8iz8_Qvk/
https://mailarchive.ietf.org/arch/msg/idr/0dL1E-C74DUgkjyOlvFStqingfg/


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

No.  The discussion was active and provided good refinements to the draft.
  https://mailarchive.ietf.org/arch/browse/idr/?q=draft-ietf-idr-sr-bgp-ls-sr-policy

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][3] recommends) or elsewhere
  (where)?
2 implementations: See
https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-te-lsp-distribution

One implementation does not have PCE and BGP co-resident, so it does not
transmit the code to indicate the "reported via PCE" code.  The
Shepherd does not feel this should hold up standardization.

Both Huawei and Cisco have implemented nine of the TLVs.
Cisco has implemented all 18 of the TLVs.  One group of
TLVs not implemented by Huawei are the Constraint related
TLVs (SR CP Constraints, SR AFfinity Constraint, SR SRLG Constraint,
SR Bandwidth Constraint, SR Disjoint Group Constraint,
SR Bidirectional Group Constraint, SR Metric Sontraint).
The second group is the SR Segment list Bandwidth and the
SR Segment list Bandwidth. 

## 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.

The BGP-LS for SR technologies closely interact with the spring and the srv6ops WG.
These WG were directly queried on 11/10/2024.

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.

The need for Yang models modeling this work has been added to:
https://wiki.ietf.org/group/idr/BGP-Model-Features

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

Not applicable since this is not a Yang model.

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?

Links to Shepherd's report is on IDR wiki
https://wiki.ietf.org/group/idr/Shepherd-SR-BGP-LS/BGP-LS-SR/bgp-ls-sr-policy

This may be an easy form to quick read.

Mail lists:
See Shepherd's review prior to WG LC:
https://mailarchive.ietf.org/arch/msg/idr/DLfvkhT7HOClFSfUzFNQ9z8bSFc/

See Shepherd's review of -08/
https://mailarchive.ietf.org/arch/msg/idr/JW8IIxVTMer5-Qq7ld5ZCHXQ2sk/

Please note the Shepherd requested AD review of 3 items:
https://mailarchive.ietf.org/arch/msg/idr/JW8IIxVTMer5-Qq7ld5ZCHXQ2sk/
and
https://mailarchive.ietf.org/arch/msg/idr/CvA1crVQJVfTDl2yvjNp_8kcXRo/


Ketant's viewpoint is that
#15 = Maximum that fits in packet resolved by RFC9552/section 5.3
#18 and #30 - Ketan believes the metric types are not being consumed in
BGP-LS. As new IANA code points are added, the implementers will know what is
range and what is not. 

John Scudder  agreed with this viewpoint:
https://mailarchive.ietf.org/arch/msg/idr/bje6-B888d6Eykk7Q7IJ-GMM7wA/

RTG-DIR review (and OK)
https://mailarchive.ietf.org/arch/msg/idr/iuD4n-9b4-dMI1SQa1vkCPK7nfA/

OPS-DIR review (Tina Tsou)
https://mailarchive.ietf.org/arch/msg/idr/PRhis-VEcyVEjQItu2VUYNLtj0Y/
Ketan's response indicates that explanations ask for repetition of information in
RFC9552 and RFC95256.  For consumer validation, the BGP-LS restates
that consumer of the BGP-LS information is outside the scope of BGP.
[The Shepherd has been through these issues with the authors, but the
OPS-AD should be warned to review this OPS-DIR review during
the AD evaluation. Better an early discussion that a late discovery.]


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?
Yes - a few points from section 9 are summarized for Routing and Security lists:

This is an extension of BGP-LS to manage/monitor SR policy for a truster SR domain [RFC8402].
It states:
a) SR operates within a trusted SR domain [RFC8402), and the security
considerations apply to this document.
b) Controllers and application services using the BGP-LS information are expected to
be within the trusted SR domain,
c) SR Policy data is critical data "that constitutes
a risk to [the] confidentiality of mission-critical or commercially sensitive" data. 

As always, BGP-ls traffic needs to be isolated from other BGP traffic (due to load)


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

Proposed Standard:

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? 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.

Ketan Talaulikar
https://mailarchive.ietf.org/arch/msg/idr/XNMFZ7_-GYwEVzALZF9aTylLWQQ/

Jie Dong:
https://mailarchive.ietf.org/arch/msg/idr/iuBOyS4Yuuiq1fgvbSZtPiHbLW4/

Jeff Tantsura
https://mailarchive.ietf.org/arch/msg/idr/9h3iYa7fzYE3lvNcOaeOeheBoiM/

Clarence Filsfils
https://mailarchive.ietf.org/arch/msg/idr/QaTiyYvGE5Yd6w1_JW_fz94ZpZs/


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][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

NITs check - just
https://mailarchive.ietf.org/arch/msg/idr/LyA6VOHdEJEuZjaV4HRaXnd8QzU/

NIT Check response:
https://mailarchive.ietf.org/arch/msg/idr/BwcU5Bmxd_7RyULcwQAcG5uTUmg/

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

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

No. All are RFCs.

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

No.

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?
No.

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][11]).

See IANA's early review of the document:
https://mailarchive.ietf.org/arch/msg/idr/Xw9HfBTseSO_2dfV7UDRwoqKNAM/

Adding values to the following existing registries
a) BGP-LS NLRI-Types
b) BGP-LS Protocol-IDs
c) BGP-LS NLRI and Attribute TLV

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.

1. SR Policy Protocol Origin registry - a new registry under "Segment Routing" 
with an allocation policy is "Expert Review" [RFC8126] using the guidelines for
Designated Experts as specified in [RFC9256].

2. SR Segment Descriptor Types - a new registry under "Border Gateway Protocol - Link State (BGP-LS) Parameters"
registry group with an allocation policy is "Expert Review" [RFC8126] using the guidelines for
Designated Experts as specified in [RFC9256].

3. BGP-LS SR Policy Metric Types - a new registry under "Border Gateway Protocol - Link State (BGP-LS) Parameters"
registry group with an allocation policy is "Expert Review" [RFC8126] using the guidelines for
Designated Experts as specified in [RFC9256].

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*


## 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?

Strong consensus with good discussions.
https://mailarchive.ietf.org/arch/msg/idr/PndHjsj0nj6fFZ97inb8iz8_Qvk/
https://mailarchive.ietf.org/arch/msg/idr/0dL1E-C74DUgkjyOlvFStqingfg/


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

No.  The discussion was active and provided good refinements to the draft.
  https://mailarchive.ietf.org/arch/browse/idr/?q=draft-ietf-idr-sr-bgp-ls-sr-policy

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][3] recommends) or elsewhere
  (where)?
2 implementations: See
https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-te-lsp-distribution

One implementation does not have PCE and BGP co-resident, so it does not
transmit the code to indicate the "reported via PCE" code.  The
Shepherd does not feel this should hold up standardization.

Both Huawei and Cisco have implemented nine of the TLVs.
Cisco has implemented all 18 of the TLVs.  One group of
TLVs not implemented by Huawei are the Constraint related
TLVs (SR CP Constraints, SR AFfinity Constraint, SR SRLG Constraint,
SR Bandwidth Constraint, SR Disjoint Group Constraint,
SR Bidirectional Group Constraint, SR Metric Sontraint).
The second group is the SR Segment list Bandwidth and the
SR Segment list Bandwidth. 

## 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.

The BGP-LS for SR technologies closely interact with the spring and the srv6ops WG.
These WG were directly queried on 11/10/2024.

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.

The need for Yang models modeling this work has been added to:
https://wiki.ietf.org/group/idr/BGP-Model-Features

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

Not applicable since this is not a Yang model.

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?

Links to Shepherd's report is on IDR wiki
https://wiki.ietf.org/group/idr/Shepherd-SR-BGP-LS/BGP-LS-SR/bgp-ls-sr-policy

This may be an easy form to quick read.

Mail lists:
See Shepherd's review prior to WG LC:
https://mailarchive.ietf.org/arch/msg/idr/DLfvkhT7HOClFSfUzFNQ9z8bSFc/

See Shepherd's review of -08/
https://mailarchive.ietf.org/arch/msg/idr/JW8IIxVTMer5-Qq7ld5ZCHXQ2sk/

Please note the Shepherd requested AD review of 3 items:
https://mailarchive.ietf.org/arch/msg/idr/JW8IIxVTMer5-Qq7ld5ZCHXQ2sk/
and
https://mailarchive.ietf.org/arch/msg/idr/CvA1crVQJVfTDl2yvjNp_8kcXRo/


Ketant's viewpoint is that
#15 = Maximum that fits in packet resolved by RFC9552/section 5.3
#18 and #30 - Ketan believes the metric types are not being consumed in
BGP-LS. As new IANA code points are added, the implementers will know what is
range and what is not. 

John Scudder  agreed with this viewpoint:
https://mailarchive.ietf.org/arch/msg/idr/bje6-B888d6Eykk7Q7IJ-GMM7wA/

RTG-DIR review (and OK)
https://mailarchive.ietf.org/arch/msg/idr/iuD4n-9b4-dMI1SQa1vkCPK7nfA/


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?
Yes - a few points from section 9 are summarized for Routing and Security lists:

This is an extension of BGP-LS to manage/monitor SR policy for a truster SR domain [RFC8402].
It states:
a) SR operates within a trusted SR domain [RFC8402), and the security
considerations apply to this document.
b) Controllers and application services using the BGP-LS information are expected to
be within the trusted SR domain,
c) SR Policy data is critical data "that constitutes
a risk to [the] confidentiality of mission-critical or commercially sensitive" data. 

As always, BGP-ls traffic needs to be isolated from other BGP traffic (due to load)


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

Proposed Standard:

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? 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.

Ketan Talaulikar
https://mailarchive.ietf.org/arch/msg/idr/XNMFZ7_-GYwEVzALZF9aTylLWQQ/

Jie Dong:
https://mailarchive.ietf.org/arch/msg/idr/iuBOyS4Yuuiq1fgvbSZtPiHbLW4/

Jeff Tantsura
https://mailarchive.ietf.org/arch/msg/idr/9h3iYa7fzYE3lvNcOaeOeheBoiM/

Clarence Filsfils
https://mailarchive.ietf.org/arch/msg/idr/QaTiyYvGE5Yd6w1_JW_fz94ZpZs/


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][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

NITs check - just
https://mailarchive.ietf.org/arch/msg/idr/LyA6VOHdEJEuZjaV4HRaXnd8QzU/

NIT Check response:
https://mailarchive.ietf.org/arch/msg/idr/BwcU5Bmxd_7RyULcwQAcG5uTUmg/

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

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

No. All are RFCs.

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

No.

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?
No.

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][11]).

See IANA's early review of the document:
https://mailarchive.ietf.org/arch/msg/idr/Xw9HfBTseSO_2dfV7UDRwoqKNAM/

Adding values to the following existing registries
a) BGP-LS NLRI-Types
b) BGP-LS Protocol-IDs
c) BGP-LS NLRI and Attribute TLV

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.

1. SR Policy Protocol Origin registry - a new registry under "Segment Routing" 
with an allocation policy is "Expert Review" [RFC8126] using the guidelines for
Designated Experts as specified in [RFC9256].

2. SR Segment Descriptor Types - a new registry under "Border Gateway Protocol - Link State (BGP-LS) Parameters"
registry group with an allocation policy is "Expert Review" [RFC8126] using the guidelines for
Designated Experts as specified in [RFC9256].

3. BGP-LS SR Policy Metric Types - a new registry under "Border Gateway Protocol - Link State (BGP-LS) Parameters"
registry group with an allocation policy is "Expert Review" [RFC8126] using the guidelines for
Designated Experts as specified in [RFC9256].

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*


## 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?

Strong consensus with good discussions.
https://mailarchive.ietf.org/arch/msg/idr/PndHjsj0nj6fFZ97inb8iz8_Qvk/
https://mailarchive.ietf.org/arch/msg/idr/0dL1E-C74DUgkjyOlvFStqingfg/


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

No.  The discussion was active and provided good refinements to the draft.
  https://mailarchive.ietf.org/arch/browse/idr/?q=draft-ietf-idr-sr-bgp-ls-sr-policy

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][3] recommends) or elsewhere
  (where)?
2 implementations: See
https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-te-lsp-distribution

One implementation does not have PCE and BGP co-resident, so it does not
transmit the code to indicate the "reported via PCE" code.  The
Shepherd does not feel this should hold up standardization.

Both Huawei and Cisco have implemented nine of the TLVs.
Cisco has implemented all 18 of the TLVs.  One group of
TLVs not implemented by Huawei are the Constraint related
TLVs (SR CP Constraints, SR AFfinity Constraint, SR SRLG Constraint,
SR Bandwidth Constraint, SR Disjoint Group Constraint,
SR Bidirectional Group Constraint, SR Metric Sontraint).
The second group is the SR Segment list Bandwidth and the
SR Segment list Bandwidth. 

## 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.

The BGP-LS for SR technologies closely interact with the spring and the srv6ops WG.
These WG were directly queried on 11/10/2024.

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.

The need for Yang models modeling this work has been added to:
https://wiki.ietf.org/group/idr/BGP-Model-Features

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

Not applicable since this is not a Yang model.

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?

Links to Shepherd's report is on IDR wiki
https://wiki.ietf.org/group/idr/Shepherd-SR-BGP-LS/BGP-LS-SR/bgp-ls-sr-policy

This may be an easy form to quick read.

Mail lists:
See Shepherd's review prior to WG LC:
https://mailarchive.ietf.org/arch/msg/idr/DLfvkhT7HOClFSfUzFNQ9z8bSFc/

See Shepherd's review of -08/
https://mailarchive.ietf.org/arch/msg/idr/JW8IIxVTMer5-Qq7ld5ZCHXQ2sk/

Please note the Shepherd requested AD review of 3 items:
https://mailarchive.ietf.org/arch/msg/idr/JW8IIxVTMer5-Qq7ld5ZCHXQ2sk/
and
https://mailarchive.ietf.org/arch/msg/idr/CvA1crVQJVfTDl2yvjNp_8kcXRo/


Ketant's viewpoint is that
#15 = Maximum that fits in packet resolved by RFC9552/section 5.3
#18 and #30 - Ketan believes the metric types are not being consumed in
BGP-LS. As new IANA code points are added, the implementers will know what is
range and what is not. 

John Scudder  agreed with this viewpoint:
https://mailarchive.ietf.org/arch/msg/idr/bje6-B888d6Eykk7Q7IJ-GMM7wA/

RTG-DIR review (and OK)
https://mailarchive.ietf.org/arch/msg/idr/iuD4n-9b4-dMI1SQa1vkCPK7nfA/


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?
Yes - a few points from section 9 are summarized for Routing and Security lists:

This is an extension of BGP-LS to manage/monitor SR policy for a truster SR domain [RFC8402].
It states:
a) SR operates within a trusted SR domain [RFC8402), and the security
considerations apply to this document.
b) Controllers and application services using the BGP-LS information are expected to
be within the trusted SR domain,
c) SR Policy data is critical data "that constitutes
a risk to [the] confidentiality of mission-critical or commercially sensitive" data. 

As always, BGP-ls traffic needs to be isolated from other BGP traffic (due to load)


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

Proposed Standard:

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? 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.

Ketan Talaulikar
https://mailarchive.ietf.org/arch/msg/idr/XNMFZ7_-GYwEVzALZF9aTylLWQQ/

Jie Dong:
https://mailarchive.ietf.org/arch/msg/idr/iuBOyS4Yuuiq1fgvbSZtPiHbLW4/

Jeff Tantsura
https://mailarchive.ietf.org/arch/msg/idr/9h3iYa7fzYE3lvNcOaeOeheBoiM/

Clarence Filsfils
https://mailarchive.ietf.org/arch/msg/idr/QaTiyYvGE5Yd6w1_JW_fz94ZpZs/


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][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

NITs check - just
https://mailarchive.ietf.org/arch/msg/idr/LyA6VOHdEJEuZjaV4HRaXnd8QzU/

NIT Check response:
https://mailarchive.ietf.org/arch/msg/idr/BwcU5Bmxd_7RyULcwQAcG5uTUmg/

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

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

No. All are RFCs.

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

No.

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?
No.

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][11]).

See IANA's early review of the document:
https://mailarchive.ietf.org/arch/msg/idr/Xw9HfBTseSO_2dfV7UDRwoqKNAM/

Adding values to the following existing registries
a) BGP-LS NLRI-Types
b) BGP-LS Protocol-IDs
c) BGP-LS NLRI and Attribute TLV

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.

1. SR Policy Protocol Origin registry - a new registry under "Segment Routing" 
with an allocation policy is "Expert Review" [RFC8126] using the guidelines for
Designated Experts as specified in [RFC9256].

2. SR Segment Descriptor Types - a new registry under "Border Gateway Protocol - Link State (BGP-LS) Parameters"
registry group with an allocation policy is "Expert Review" [RFC8126] using the guidelines for
Designated Experts as specified in [RFC9256].

3. BGP-LS SR Policy Metric Types - a new registry under "Border Gateway Protocol - Link State (BGP-LS) Parameters"
registry group with an allocation policy is "Expert Review" [RFC8126] using the guidelines for
Designated Experts as specified in [RFC9256].

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*


## 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?

Strong consensus with good discussions.
https://mailarchive.ietf.org/arch/msg/idr/PndHjsj0nj6fFZ97inb8iz8_Qvk/
https://mailarchive.ietf.org/arch/msg/idr/0dL1E-C74DUgkjyOlvFStqingfg/


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

No.  The discussion was active and provided good refinements to the draft.
  https://mailarchive.ietf.org/arch/browse/idr/?q=draft-ietf-idr-sr-bgp-ls-sr-policy

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][3] recommends) or elsewhere
  (where)?
2 implementations: See
https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-te-lsp-distribution

One implementation does not have PCE and BGP co-resident, so it does not
transmit the code to indicate the "reported via PCE" code.  The
Shepherd does not feel this should hold up standardization.

Both Huawei and Cisco have implemented nine of the TLVs.
Cisco has implemented all 18 of the TLVs.  One group of
TLVs not implemented by Huawei are the Constraint related
TLVs (SR CP Constraints, SR AFfinity Constraint, SR SRLG Constraint,
SR Bandwidth Constraint, SR Disjoint Group Constraint,
SR Bidirectional Group Constraint, SR Metric Sontraint).
The second group is the SR Segment list Bandwidth and the
SR Segment list Bandwidth. 

## 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.

The BGP-LS for SR technologies closely interact with the spring and the srv6ops WG.
These WG were directly queried on 11/10/2024.

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.

The need for Yang models modeling this work has been added to:
https://wiki.ietf.org/group/idr/BGP-Model-Features

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

Not applicable since this is not a Yang model.

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?

Links to Shepherd's report is on IDR wiki
https://wiki.ietf.org/group/idr/Shepherd-SR-BGP-LS/BGP-LS-SR/bgp-ls-sr-policy

This may be an easy form to quick read.

Mail lists:
See Shepherd's review prior to WG LC:
https://mailarchive.ietf.org/arch/msg/idr/DLfvkhT7HOClFSfUzFNQ9z8bSFc/

See Shepherd's review of -08/
https://mailarchive.ietf.org/arch/msg/idr/JW8IIxVTMer5-Qq7ld5ZCHXQ2sk/

Please note the Shepherd requested AD review of 3 items:
https://mailarchive.ietf.org/arch/msg/idr/JW8IIxVTMer5-Qq7ld5ZCHXQ2sk/
and
https://mailarchive.ietf.org/arch/msg/idr/CvA1crVQJVfTDl2yvjNp_8kcXRo/


Ketant's viewpoint is that
#15 = Maximum that fits in packet resolved by RFC9552/section 5.3
#18 and #30 - Ketan believes the metric types are not being consumed in
BGP-LS. As new IANA code points are added, the implementers will know what is
range and what is not. 

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?
Yes - a few points from section 9 are summarized for Routing and Security lists:

This is an extension of BGP-LS to manage/monitor SR policy for a truster SR domain [RFC8402].
It states:
a) SR operates within a trusted SR domain [RFC8402), and the security
considerations apply to this document.
b) Controllers and application services using the BGP-LS information are expected to
be within the trusted SR domain,
c) SR Policy data is critical data "that constitutes
a risk to [the] confidentiality of mission-critical or commercially sensitive" data. 

As always, BGP-ls traffic needs to be isolated from other BGP traffic (due to load)


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

Proposed Standard:

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? 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.

Ketan Talaulikar
https://mailarchive.ietf.org/arch/msg/idr/XNMFZ7_-GYwEVzALZF9aTylLWQQ/

Jie Dong:
https://mailarchive.ietf.org/arch/msg/idr/iuBOyS4Yuuiq1fgvbSZtPiHbLW4/

Jeff Tantsura
https://mailarchive.ietf.org/arch/msg/idr/9h3iYa7fzYE3lvNcOaeOeheBoiM/

Clarence Filsfils
https://mailarchive.ietf.org/arch/msg/idr/QaTiyYvGE5Yd6w1_JW_fz94ZpZs/


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][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

NITs check
https://mailarchive.ietf.org/arch/msg/idr/LyA6VOHdEJEuZjaV4HRaXnd8QzU/


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

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

No. All are RFCs.

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

No.

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?
No.

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][11]).

See IANA's early review of the document:
https://mailarchive.ietf.org/arch/msg/idr/Xw9HfBTseSO_2dfV7UDRwoqKNAM/

Adding values to the following existing registries
a) BGP-LS NLRI-Types
b) BGP-LS Protocol-IDs
c) BGP-LS NLRI and Attribute TLV

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.

1. SR Policy Protocol Origin registry - a new registry under "Segment Routing" 
with an allocation policy is "Expert Review" [RFC8126] using the guidelines for
Designated Experts as specified in [RFC9256].

2. SR Segment Descriptor Types - a new registry under "Border Gateway Protocol - Link State (BGP-LS) Parameters"
registry group with an allocation policy is "Expert Review" [RFC8126] using the guidelines for
Designated Experts as specified in [RFC9256].

3. BGP-LS SR Policy Metric Types - a new registry under "Border Gateway Protocol - Link State (BGP-LS) Parameters"
registry group with an allocation policy is "Expert Review" [RFC8126] using the guidelines for
Designated Experts as specified in [RFC9256].

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*


## 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?

Strong consensus with good discussions.
https://mailarchive.ietf.org/arch/msg/idr/PndHjsj0nj6fFZ97inb8iz8_Qvk/


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

No.  The discussion was active and provided good refinements to the draft.
  https://mailarchive.ietf.org/arch/browse/idr/?q=draft-ietf-idr-sr-bgp-ls-sr-policy

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][3] recommends) or elsewhere
  (where)?
2 implementations: See
https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-te-lsp-distribution

One implementation does not have PCE and BGP co-resident, so it does not
transmit the code to indicate the "reported via PCE" code.  The
Shepherd does not feel this should hold up standardization.

Both Huawei and Cisco have implemented nine of the TLVs.
Cisco has implemented all 18 of the TLVs.  One group of
TLVs not implemented by Huawei are the Constraint related
TLVs (SR CP Constraints, SR AFfinity Constraint, SR SRLG Constraint,
SR Bandwidth Constraint, SR Disjoint Group Constraint,
SR Bidirectional Group Constraint, SR Metric Sontraint).
The second group is the SR Segment list Bandwidth and the
SR Segment list Bandwidth. 

## 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.

The BGP-LS for SR technologies closely interact with the spring and the srv6ops WG.
These WG were directly queried on 11/10/2024.

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.

The need for Yang models modeling this work has been added to:
https://wiki.ietf.org/group/idr/BGP-Model-Features

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

Not applicable since this is not a Yang model.

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?

Links to Shepherd's report is on IDR wiki
https://wiki.ietf.org/group/idr/Shepherd-SR-BGP-LS/BGP-LS-SR/bgp-ls-sr-policy

This may be an easy form to quick read.

Mail lists:
See Shepherd's review prior to WG LC:
https://mailarchive.ietf.org/arch/msg/idr/DLfvkhT7HOClFSfUzFNQ9z8bSFc/

See Shepherd's review of -08/
https://mailarchive.ietf.org/arch/msg/idr/JW8IIxVTMer5-Qq7ld5ZCHXQ2sk/

Please note the Shepherd requested AD review of 3 items:
https://mailarchive.ietf.org/arch/msg/idr/JW8IIxVTMer5-Qq7ld5ZCHXQ2sk/
and
https://mailarchive.ietf.org/arch/msg/idr/CvA1crVQJVfTDl2yvjNp_8kcXRo/


Ketant's viewpoint is that
#15 = Maximum that fits in packet resolved by RFC9552/section 5.3
#18 and #30 - Ketan believes the metric types are not being consumed in
BGP-LS. As new IANA code points are added, the implementers will know what is
range and what is not. 

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?
Yes - a few points from section 9 are summarized for Routing and Security lists:

This is an extension of BGP-LS to manage/monitor SR policy for a truster SR domain [RFC8402].
It states:
a) SR operates within a trusted SR domain [RFC8402), and the security
considerations apply to this document.
b) Controllers and application services using the BGP-LS information are expected to
be within the trusted SR domain,
c) SR Policy data is critical data "that constitutes
a risk to [the] confidentiality of mission-critical or commercially sensitive" data. 

As always, BGP-ls traffic needs to be isolated from other BGP traffic (due to load)


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

Proposed Standard:

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? 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.

Ketan Talaulikar
https://mailarchive.ietf.org/arch/msg/idr/XNMFZ7_-GYwEVzALZF9aTylLWQQ/

Jie Dong:
https://mailarchive.ietf.org/arch/msg/idr/iuBOyS4Yuuiq1fgvbSZtPiHbLW4/

Jeff Tantsura
https://mailarchive.ietf.org/arch/msg/idr/9h3iYa7fzYE3lvNcOaeOeheBoiM/

Clarence Filsfils
https://mailarchive.ietf.org/arch/msg/idr/QaTiyYvGE5Yd6w1_JW_fz94ZpZs/


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][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

NITs check
https://mailarchive.ietf.org/arch/msg/idr/LyA6VOHdEJEuZjaV4HRaXnd8QzU/


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

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

No. All are RFCs.

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

No.

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?
No.

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][11]).

See IANA's early review of the document:
https://mailarchive.ietf.org/arch/msg/idr/Xw9HfBTseSO_2dfV7UDRwoqKNAM/

Adding values to the following existing registries
a) BGP-LS NLRI-Types
b) BGP-LS Protocol-IDs
c) BGP-LS NLRI and Attribute TLV

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.

1. SR Policy Protocol Origin registry - a new registry under "Segment Routing" 
with an allocation policy is "Expert Review" [RFC8126] using the guidelines for
Designated Experts as specified in [RFC9256].

2. SR Segment Descriptor Types - a new registry under "Border Gateway Protocol - Link State (BGP-LS) Parameters"
registry group with an allocation policy is "Expert Review" [RFC8126] using the guidelines for
Designated Experts as specified in [RFC9256].

3. BGP-LS SR Policy Metric Types - a new registry under "Border Gateway Protocol - Link State (BGP-LS) Parameters"
registry group with an allocation policy is "Expert Review" [RFC8126] using the guidelines for
Designated Experts as specified in [RFC9256].

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*


## 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?

Strong consensus with good discussions.
https://mailarchive.ietf.org/arch/msg/idr/PndHjsj0nj6fFZ97inb8iz8_Qvk/


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

No.  The discussion was active and provided good refinements to the draft.
  https://mailarchive.ietf.org/arch/browse/idr/?q=draft-ietf-idr-sr-bgp-ls-sr-policy

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][3] recommends) or elsewhere
  (where)?
2 implementations: See
https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-te-lsp-distribution

One implementation does not have PCE and BGP co-resident, so it does not
transmit the code to indicate the "reported via PCE" code.  The
Shepherd does not feel this should hold up standardization.

Both Huawei and Cisco have implemented nine of the TLVs.
Cisco has implemented all 18 of the TLVs.  One group of
TLVs not implemented by Huawei are the Constraint related
TLVs (SR CP Constraints, SR AFfinity Constraint, SR SRLG Constraint,
SR Bandwidth Constraint, SR Disjoint Group Constraint,
SR Bidirectional Group Constraint, SR Metric Sontraint).
The second group is the SR Segment list Bandwidth and the
SR Segment list Bandwidth. 

## 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.

The BGP-LS for SR technologies closely interact with the spring and the srv6ops WG.
These WG were directly queried on 11/10/2024.

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.

The need for Yang models modeling this work has been added to:
https://wiki.ietf.org/group/idr/BGP-Model-Features

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

Not applicable since this is not a Yang model.

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?

Links to Shepherd's report is on IDR wiki
https://wiki.ietf.org/group/idr/Shepherd-SR-BGP-LS/BGP-LS-SR/bgp-ls-sr-policy

This may be an easy form to quick read.

Mail lists:
See Shepherd's review prior to WG LC:
https://mailarchive.ietf.org/arch/msg/idr/DLfvkhT7HOClFSfUzFNQ9z8bSFc/

See Shepherd's review of -08/
https://mailarchive.ietf.org/arch/msg/idr/JW8IIxVTMer5-Qq7ld5ZCHXQ2sk/

Please note the Shepherd requested AD review of 3 items:
https://mailarchive.ietf.org/arch/msg/idr/JW8IIxVTMer5-Qq7ld5ZCHXQ2sk/
and
https://mailarchive.ietf.org/arch/msg/idr/CvA1crVQJVfTDl2yvjNp_8kcXRo/


Ketant's viewpoint is that
#15 = Maximum that fits in packet resolved by RFC9552/section 5.3
#18 and #30 - Ketan believes the metric types are not being consumed in
BGP-LS. As new IANA code points are added, the implementers will know what is
range and what is not. 

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?
Yes - a few points from section 9 are summarized for Routing and Security lists:

This is an extension of BGP-LS to manage/monitor SR policy for a truster SR domain [RFC8402].
It states:
a) SR operates within a trusted SR domain [RFC8402), and the security
considerations apply to this document.
b) Controllers and application services using the BGP-LS information are expected to
be within the trusted SR domain,
c) SR Policy data is critical data "that constitutes
a risk to [the] confidentiality of mission-critical or commercially sensitive" data. 

As always, BGP-ls traffic needs to be isolated from other BGP traffic (due to load)


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

Proposed Standard:

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? 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.

Ketan Talaulikar
https://mailarchive.ietf.org/arch/msg/idr/XNMFZ7_-GYwEVzALZF9aTylLWQQ/

Jie Dong:
https://mailarchive.ietf.org/arch/msg/idr/iuBOyS4Yuuiq1fgvbSZtPiHbLW4/

Jeff Tantsura
https://mailarchive.ietf.org/arch/msg/idr/9h3iYa7fzYE3lvNcOaeOeheBoiM/

Clarence Filsfils
https://mailarchive.ietf.org/arch/msg/idr/QaTiyYvGE5Yd6w1_JW_fz94ZpZs/


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][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

NITs check
https://mailarchive.ietf.org/arch/msg/idr/LyA6VOHdEJEuZjaV4HRaXnd8QzU/


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

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

No. All are RFCs.

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

No.

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?
No.

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][11]).

See IANA's early review of the document:
https://mailarchive.ietf.org/arch/msg/idr/Xw9HfBTseSO_2dfV7UDRwoqKNAM/

Adding values to the following existing registries
a) BGP-LS NLRI-Types
b) BGP-LS Protocol-IDs
c) BGP-LS NLRI and Attribute TLV

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.

1. SR Policy Protocol Origin registry - a new registry under "Segment Routing" 
with an allocation policy is "Expert Review" [RFC8126] using the guidelines for
Designated Experts as specified in [RFC9256].

2. SR Segment Descriptor Types - a new registry under "Border Gateway Protocol - Link State (BGP-LS) Parameters"
registry group with an allocation policy is "Expert Review" [RFC8126] using the guidelines for
Designated Experts as specified in [RFC9256].

3. BGP-LS SR Policy Metric Types - a new registry under "Border Gateway Protocol - Link State (BGP-LS) Parameters"
registry group with an allocation policy is "Expert Review" [RFC8126] using the guidelines for
Designated Experts as specified in [RFC9256].

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*


## 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?

[TBD]

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

No.  The discussion was active and provided good refinements to the draft.
  https://mailarchive.ietf.org/arch/browse/idr/?q=draft-ietf-idr-sr-bgp-ls-sr-policy

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][3] recommends) or elsewhere
  (where)?
2 implementations: See
https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-te-lsp-distribution

One implementation does not have PCE and BGP co-resident, so it does not
transmit the code to indicate the "reported via PCE" code.  The
Shepherd does not feel this should hold up standardization.

Both Huawei and Cisco have implemented nine of the TLVs.
Cisco has implemented all 18 of the TLVs.  One group of
TLVs not implemented by Huawei are the Constraint related
TLVs (SR CP Constraints, SR AFfinity Constraint, SR SRLG Constraint,
SR Bandwidth Constraint, SR Disjoint Group Constraint,
SR Bidirectional Group Constraint, SR Metric Sontraint).
The second group is the SR Segment list Bandwidth and the
SR Segment list Bandwidth. 

## 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.

The BGP-LS for SR technologies closely interact with the spring and the srv6ops WG.
These WG were directly queried on 11/10/2024.

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.

The need for Yang models modeling this work has been added to:
https://wiki.ietf.org/group/idr/BGP-Model-Features

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

Not applicable since this is not a Yang model.

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?

Links to Shepherd's report is on IDR wiki
https://wiki.ietf.org/group/idr/Shepherd-SR-BGP-LS/BGP-LS-SR/bgp-ls-sr-policy

This may be an easy form to quick read.

Mail lists:
See Shepherd's review prior to WG LC:
https://mailarchive.ietf.org/arch/msg/idr/DLfvkhT7HOClFSfUzFNQ9z8bSFc/

See Shepherd's review of -08/
https://mailarchive.ietf.org/arch/msg/idr/JW8IIxVTMer5-Qq7ld5ZCHXQ2sk/

Please note the Shepherd requested AD review of 3 items:
https://mailarchive.ietf.org/arch/msg/idr/JW8IIxVTMer5-Qq7ld5ZCHXQ2sk/
and
https://mailarchive.ietf.org/arch/msg/idr/CvA1crVQJVfTDl2yvjNp_8kcXRo/


Ketant's viewpoint is that
#15 = Maximum that fits in packet resolved by RFC9552/section 5.3
#18 and #30 - Ketan believes the metric types are not being consumed in
BGP-LS. As new IANA code points are added, the implementers will know what is
range and what is not. 

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?
Yes - a few points from section 9 are summarized for Routing and Security lists:

This is an extension of BGP-LS to manage/monitor SR policy for a truster SR domain [RFC8402].
It states:
a) SR operates within a trusted SR domain [RFC8402), and the security
considerations apply to this document.
b) Controllers and application services using the BGP-LS information are expected to
be within the trusted SR domain,
c) SR Policy data is critical data "that constitutes
a risk to [the] confidentiality of mission-critical or commercially sensitive" data. 

As always, BGP-ls traffic needs to be isolated from other BGP traffic (due to load)


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

Proposed Standard:

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? 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.

Ketan Talaulikar
https://mailarchive.ietf.org/arch/msg/idr/XNMFZ7_-GYwEVzALZF9aTylLWQQ/

Jie Dong:
https://mailarchive.ietf.org/arch/msg/idr/iuBOyS4Yuuiq1fgvbSZtPiHbLW4/

Jeff Tantsura
https://mailarchive.ietf.org/arch/msg/idr/9h3iYa7fzYE3lvNcOaeOeheBoiM/

Clarence Filsfils
https://mailarchive.ietf.org/arch/msg/idr/QaTiyYvGE5Yd6w1_JW_fz94ZpZs/


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][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

NITs check
https://mailarchive.ietf.org/arch/msg/idr/LyA6VOHdEJEuZjaV4HRaXnd8QzU/


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

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

No. All are RFCs.

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

No.

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?
No.

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][11]).

See IANA's early review of the document:
https://mailarchive.ietf.org/arch/msg/idr/Xw9HfBTseSO_2dfV7UDRwoqKNAM/

Adding values to the following existing registries
a) BGP-LS NLRI-Types
b) BGP-LS Protocol-IDs
c) BGP-LS NLRI and Attribute TLV

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.

1. SR Policy Protocol Origin registry - a new registry under "Segment Routing" 
with an allocation policy is "Expert Review" [RFC8126] using the guidelines for
Designated Experts as specified in [RFC9256].

2. SR Segment Descriptor Types - a new registry under "Border Gateway Protocol - Link State (BGP-LS) Parameters"
registry group with an allocation policy is "Expert Review" [RFC8126] using the guidelines for
Designated Experts as specified in [RFC9256].

3. BGP-LS SR Policy Metric Types - a new registry under "Border Gateway Protocol - Link State (BGP-LS) Parameters"
registry group with an allocation policy is "Expert Review" [RFC8126] using the guidelines for
Designated Experts as specified in [RFC9256].

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*


## 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?

[TBD]

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

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][3] recommends) or elsewhere
  (where)?
2 implementations: See
https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-te-lsp-distribution

## 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.

The BGP-LS for SR technologies closely interact with the spring and the srv6ops WG.
These WG were directly queried on 11/10/2024.

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.

The need for Yang models modeling this work has been added to:
https://wiki.ietf.org/group/idr/BGP-Model-Features

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

Not applicable since this is not a Jang model.

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?

See shepherd's review prior to WG LC:
https://mailarchive.ietf.org/arch/msg/idr/DLfvkhT7HOClFSfUzFNQ9z8bSFc/


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

[TBD]

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

Proposed Standard:

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? 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.

Ketan Talaulikar
https://mailarchive.ietf.org/arch/msg/idr/XNMFZ7_-GYwEVzALZF9aTylLWQQ/

Jie Dong:
https://mailarchive.ietf.org/arch/msg/idr/iuBOyS4Yuuiq1fgvbSZtPiHbLW4/

Jeff Tantsura
https://mailarchive.ietf.org/arch/msg/idr/9h3iYa7fzYE3lvNcOaeOeheBoiM/

Clarence Filsfils
https://mailarchive.ietf.org/arch/msg/idr/QaTiyYvGE5Yd6w1_JW_fz94ZpZs/


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][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

[TBD]

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

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

No. All are RFCs.

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

No.

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?
No.

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][11]).

See IANA's early review of the document:
https://mailarchive.ietf.org/arch/msg/idr/Xw9HfBTseSO_2dfV7UDRwoqKNAM/

Adding values to the following existing registries
a) BGP-LS NLRI-Types
b) BGP-LS Protocol-IDs
c) BGP-LS NLRI and Attribute TLV

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.

1. SR Policy Protocol Origin registry - a new registry under "Segment Routing" 
with an allocation policy is "Expert Review" [RFC8126] using the guidelines for
Designated Experts as specified in [RFC9256].

2. SR Segment Descriptor Types - a new registry under "Border Gateway Protocol - Link State (BGP-LS) Parameters"
registry group with an allocation policy is "Expert Review" [RFC8126] using the guidelines for
Designated Experts as specified in [RFC9256].

3. BGP-LS SR Policy Metric Types - a new registry under "Border Gateway Protocol - Link State (BGP-LS) Parameters"
registry group with an allocation policy is "Expert Review" [RFC8126] using the guidelines for
Designated Experts as specified in [RFC9256].

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## 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?

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

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.)

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][3] recommends) or elsewhere
  (where)?

## 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.

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.

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

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.

## 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?

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

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do 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][7]? 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.

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.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

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

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

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

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?

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.

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][11]).

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.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/