Advertising Segment Routing Policies in BGP
draft-ietf-idr-sr-policy-safi-13

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-idr-sr-policy-safi-12
CC @evyncke

Thank you for the work put into this document.

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

Special thanks to Susan Hares for the shepherd's very terse write-up including the WG consensus and some justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS (non-blocking)

### Section 1

Unsure whether the meaning of "headend node" is well understood, it appears in RFC 8402 without any explanation though.

Who is the "we" in `While for simplicity we may write` ? The authors ? The WG ? The IETF ? The operator ? Let's be accurate in defined the subject of this sentence.

Bear with my lack of expertise about BGP... about `One or more IPv4 address-specific format route target extended community`, and knowing that section 3.2 of RFC 4360 only supports IPv4, does this mean that this specification supports only IPv4 "headends" or is this simply a 32-bit identifier and not an IPv4 locator?

### Section 2.2

In order to be consistent with "SRv6 Binding SID" suggest s/Binding SID/SR-MPLS Binding SID/ this will also remove any ambiguity.

### Section 2.4

Unsure whether the paragraph starting with `An early version of this document included` is really useful once this I-D is published. Consider removing it.

### Section 2.4.3

This may explain why the term "Binding SID" is used (cfr my comment about section 2.2)... as the "binding SID" can either be for SR-MPLS or for SRv6. But, it is unclear to me how to make a choice between the 2 TLV when sending a SRv6 BSID without the optional "Endpoint Behavior and SID Structure" beyond the 'RECOMMENDED' of section 2.4.2.

### Section 2.4.5

s/into an SR policy/into an SR-MPLS policy/ as this sub-TLV applies only to SR-MPLS ?

## NITS (non-blocking / cosmetic)

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg too to generate SVG graphics. It is worth a try ;-)

[Ballot comment]
The IANA questions in the shepherd writeup were not completed (they're marked "[NA]").

Why is the SHOULD in Section 2.4.5 there?  What guidance do we have to implementers around deciding whether to do what it says?

[Ballot comment]
Thanks for adding a separate manageability section to outline how the feature is going to be managed. And thanks to Roman for catching the fact that the referenced YANG module draft had expired.

Looking at draft-ietf-spring-sr-policy-yang and granted it is still a draft, I could not help noticing the paucity of statistics being maintained for the feature supported by this draft. Granted, this comment is more for the other draft, but I wonder if enough thought has been given to what would be required to manage the feature in the network. For example, these are the only counters associated with policies that I could find.

        description
          "Counters containing stats related to forwarding";

        leaf pkts {
          type yang:counter64;
          description "Number of packets forwarded";
        }
        leaf octets {
          type yang:counter64;
          units "byte";
          description "Number of bytes forwarded";
        }

Description or lack of it aside, what it appears to be counting is the number of packets or octets forwarded when the policy is successfully installed. How do these stats help with debugging if the policy was learned by the headend in the first place or the number of candidate paths it learned?

[Ballot comment]
Thanks for adding a separate manageability section to outline how the feature is going to be managed.

Looking at draft-ietf-spring-sr-policy-yang and granted it is still a draft, I could not help noticing the paucity of statistics being maintained for the feature supported by this draft. Granted, this comment is more for the other draft, but I wonder if enough thought has been given to what would be required to manage the feature in the network. For example, these are the only counters associated with policies that I could find.

        description
          "Counters containing stats related to forwarding";

        leaf pkts {
          type yang:counter64;
          description "Number of packets forwarded";
        }
        leaf octets {
          type yang:counter64;
          units "byte";
          description "Number of bytes forwarded";
        }

How do these stats help with debugging if the policy was learned by the headend or the number of candidate paths?

[Ballot comment]
I'd recommend either adding an acronym/terminology section, or pointing to one in another rfc.
  - Terms like NLRI should be expanded upon first use. 
  - Definitions of 'color extended community' would be lovely.

[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-idr-sr-policy-safi-11

# Many thanks for to Zhaohui 'Jeffrey' Zhang and Mohamed 'Med' Boucadair for the RTGDIR reviews

# Many thanks to the authors to fix the blocking DISCUSS and resolve/responded to the non-blocking observations

[Ballot comment]
# Internet AD comments for draft-ietf-idr-sr-policy-safi-10
CC @ekline

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

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

## Comments

### S2.1, S3

* Policy Color: might be worth a reminder that RFC 9256 says that SR Policy
  color values must be non-zero.

[Ballot discuss]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-idr-sr-policy-safi-10

# The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-idr-sr-policy-safi-10.txt

# Many thanks for to Zhaohui 'Jeffrey' Zhang and Mohamed 'Med' Boucadair for the RTGDIR reviews

# There is one observed easy to resolve DISCUSS asking for clarification regarding the ASCII character set used by this specification.

# DISCUSS
# =======

# The document suggests a "Policy Name" and "Policy Candidate Path Name" encoding in ASCII, however it is unclear which specific ASCII encoding is assumed. Maybe you intent to suggest ASCII defined by ISO/IEC 646:1991 (https://www.iso.org/standard/4777.html). I suggest to clarify and add your suggested encoding as Normative Reference

[Ballot comment]
# Detailed Review
# ===============

18   A Segment Routing (SR) Policy is an ordered list of segments (i.e.,
19   instructions) that represent a source-routed policy.  An SR Policy
20   consists of one or more candidate paths, each consisting of one or
21   more segment lists.  A headend may be provisioned with candidate
22   paths for an SR Policy via several different mechanisms, e.g., CLI,
23   NETCONF, PCEP, or BGP.

25   This document specifies how BGP may be used to distribute SR Policy
26   candidate paths.  It introduces a BGP SAFI to advertise a candidate
27   path of a Segment Routing (SR) Policy and defines sub-TLVs for the
28   Tunnel Encapsulation Attribute for signaling information about these
29   candidate paths.

31   This documents updates RFC9012 with extensions to the Color Extended
32   Community to support additional steering modes over SR Policy.

GV> proposed:

"
A Segment Routing (SR) Policy is an ordered list of segments (also referred to as instructions) that define a source-routed policy. An SR Policy consists of one or more candidate paths, each comprising one or more segment lists. A headend can be provisioned with these candidate paths using various mechanisms, such as CLI, NETCONF, PCEP, or BGP.

This document specifies how BGP can be used to distribute SR Policy candidate paths. It introduces a new BGP SAFI for advertising a candidate path of an SR Policy and defines sub-TLVs for the Tunnel Encapsulation Attribute to signal information related to these candidate paths.

Furthermore, this document updates RFC9012 by extending the Color Extended Community to support additional steering modes over SR Policy.
"

128   While [RFC8754] and [RFC8986] describe the same for SRv6 with the use
129   of the Segment Routing Header (SRH).

GV> What about draft-ietf-spring-srv6-srh-compression?

141   *  Associating a Binding SID (BSID) to the selected candidate path of
142       an SR Policy.
143
144   *  Installation of the selected candidate path and its BSID in the
145       forwarding plane.

GV> it could be worthwhile to indicate that a BSID is optional

181   defined in this document.  The policy advertisement is, in most but
182   not all cases, tailored for a specific policy headend; such an
183   advertisement may be sent on a BGP session to that headend and not
184   propagated any further.

GV> I suspect that the intent is to indicate that the policy can be sent of a BGP session without any intermediate BGP hops? What about the following:

"
In most cases, the policy advertisement is tailored for a specific policy headend; consequently, it may be transmitted over a direct BGP session (i.e., without intermediate BGP hops) to that headend and is not propagated any further.
"

186   Alternatively, a router (i.e., a BGP egress router) advertises SR
187   Policies representing paths to itself.  In this case, it is possible
188   to send the policy to each headend over a BGP session to that
189   headend, without requiring any further propagation of the policy.

GV> I have no history awareness of this statement and this reads rather confusing as result.
Are you trying to say the following:

"
Alternatively, a BGP egress router may advertise SR Policies that represent paths terminating on itself. In such cases, the router can send these policies directly to each headend over a dedicated BGP session, without necessitating any further propagation of the policy.
"

191   An SR Policy intended only for the receiver will, in most cases, not
192   traverse any Route Reflector (RR, [RFC4456]) (see Section 4.2.3).

GV> In earluer sections it was mentioned that it was for SR policy headend routers. Is this not a duplicate phrase from line 181?


222   The SR Policy SAFI route updates use the Tunnel Encapsulation
223   Attribute to signal an SR Policy - which is a tunnel itself.  Its
224   usage of this attribute is hence very different from [RFC9012] where
225   this attribute is associated with a BGP route update (e.g., for
226   Internet or VPN routes) to specify the tunnel which is used for
227   forwarding traffic for that route.  This document does not update or
228   change the usage of the Tunnel Encapsulation Attribute as specified
229   in [RFC9012] for existing AFI/SAFIs as specified in that document.
230   The details of processing of the Tunnel Encapsulation Attribute for
231   the SR Policy SAFI are specified in Section 2.2 and Section 2.3.

GV> WHat about the following proposed textblob:

"
The SR Policy SAFI route updates utilize the Tunnel Encapsulation Attribute to signal an SR Policy, which itself functions as a tunnel. This usage differs notably from the approach described in [RFC9012], where the Tunnel Encapsulation Attribute is associated with a BGP route update (e.g., for Internet or VPN routes) to specify the tunnel used for forwarding traffic. This document does not modify or supersede the usage of the Tunnel Encapsulation Attribute for existing AFI/SAFIs as defined in [RFC9012]. Details regarding the processing of the Tunnel Encapsulation Attribute for the SR Policy SAFI are provided in Section 2.2 and Section 2.3.
"

297   *  Endpoint: value identifies the endpoint of a policy.  The Endpoint
298       may represent a single node or a set of nodes (e.g., an anycast
299       address).  The Endpoint is an IPv4 (4-octet) address or an IPv6
300       (16-octet) address according to the AFI of the NLRI.  The address
301       can be either a unicast or an unspecified address (0.0.0.0 for
302       IPv4, :: for IPv6), known as null endpoint, as specified in
303       section 2.1 of [RFC9256].

GV> Can the endpoint be a SRv6 locator? Maybe clarify in the textblob.

319   The next-hop network address field in SR Policy SAFI (73) updates may
320   be either a 4-octet IPv4 address or a 16-octet IPv6 address,

GV> May this next-hop address be an address carved from an SRv6 locator address space?

330   It is important to note that any BGP speaker receiving a BGP message
331   with an SR Policy NLRI, the SRPM will process it only if the NLRI is
332   among the best paths as per the BGP best-path selection algorithm.

GV> What does exactly 'among' mean? WOuld it not be if the NLRI represents is the best path?
Would removing the word "among" not be more accurate and moe specific indicate that it has to be the best path?

334   In other words, this document leverages the existing BGP propagation
335   and best-path selection rules.  Details of the procedures are
336   described in Section 4.

GV> If the existing propagation paradigms are used, maybe indicate here shortly where things may be deviated if there is a full section 4 is dedicated to explain procedure.

419   The Tunnel Egress Endpoint and Color Sub-TLVs of the Tunnel
420   Encapsulation Attribute [RFC9012] are not used for SR Policy
421   encodings and therefore their value is irrelevant in the context of
422   the SR Policy SAFI NLRI.  If present, the Tunnel Egress Endpoint sub-
423   TLV and the Color sub-TLV MUST be ignored by the BGP speaker and MAY
424   be removed from the Tunnel Encapsulation Attribute during
425   propagation.

427   Similarly, any other sub-TLVs (including those defined in [RFC9012])
428   whose applicability is not specifically defined for the SR Policy
429   SAFI MUST be ignored by the BGP speaker and MAY be removed from the
430   Tunnel Encapsulation Attribute during propagation.

GV> proposed rewrite:

"
The Tunnel Egress Endpoint and Color sub-TLVs of the Tunnel Encapsulation Attribute, as defined in [RFC9012], are not utilized for SR Policy encodings. Consequently, their values are not relevant within the context of the SR Policy SAFI NLRI. If these sub-TLVs are present, a BGP speaker MUST ignore them and MAY remove them from the Tunnel Encapsulation Attribute during propagation.

Similarly, any other sub-TLVs, including those specified in [RFC9012], that do not have explicitly defined applicability to the SR Policy SAFI MUST be ignored by the BGP speaker and MAY be removed from the Tunnel Encapsulation Attribute during propagation.
"

515   When the Binding SID sub-TLV is used to signal an SRv6 SID, the
516   choice of its SRv6 Endpoint Behavior [RFC8986] to be instantiated is
517   left to the headend node.  It is RECOMMENDED that the SRv6 Binding
518   SID sub-TLV defined in Section 2.4.3, that enables the specification
519   of the SRv6 Endpoint Behavior, be used for signaling of an SRv6
520   Binding SID for an SR Policy candidate path.

GV> Suggest the following text for a more readable textblob

"
When the Binding SID sub-TLV is used to signal an SRv6 SID, the selection of the corresponding SRv6 Endpoint Behavior [RFC8986] to be instantiated is determined by the headend node. It is RECOMMENDED that the SRv6 Binding SID sub-TLV, as defined in Section 2.4.3, be used to explicitly specify the SRv6 Endpoint Behavior when signaling an SRv6 Binding SID for an SR Policy candidate path.
"

1111       Policy Candidate Path Name: Symbolic name for the SR Policy
1112       candidate path without a NULL terminator as specified in section
1113       2.6 of [RFC9256].

GV> how is the symbolic name encoded? is this ascii. I suggest to add details on the encoding specifics

1160       Policy Name: Symbolic name for the policy.  It SHOULD be a string
1161       of printable ASCII characters, without a NULL terminator.

GV> I suggest to add details on the ascii encoding specifics

1171   (Ethernet VPN, usually known as EVPN).  Use of the Color Extended
1172   Community in BGP UPDATE messages of other AFI/SAFIs is outside the
1173   scope of this document.

GV> "this document". Is that suggetsing rfc9012 or draft-ietf-idr-sr-policy-safi-10? i suspect rfc9012. Maybe be more explicitly.

1187   The CO bits together form the Color-Only Type field which indicates
1188   the various matching criteria between BGP NH and SR Policy endpoint
1189   in addition to the matching of the color value.  Following types are
1190   defined:

GV> Would adding the following table encodings be more accurate to correlate the types with a specific CO bit configuration:

CO bits
-------
00 Type 0
01 Type 1
10 Type 2
11 Type 3

1255   The selected best route is "propagated" (Section 9.1.3 of [RFC4271])
1256   as described in Section 4.2.3 irrespective of its "usability" by the
1257   local router.

GV> I suspect that he term "usability" is potentially misused?

"
The selected best route is propagated as specified in Section 9.1.3 of [RFC4271], as described in Section 4.2.3, regardless of whether it is utilized by the local router.
"

IESG/Authors/WG Chairs:

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

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

First, in the Subsequent Address Family Identifiers (SAFI) Parameters registry in the Subsequent Address Family Identifiers (SAFI) Parameters registry group located at:

https://www.iana.org/assignments/safi-namespace/

The existing early allocation for Value: 73; Description: SR TE Policy SAFI will be made permanent and have its reference changed to [ RFC-to-be ].

Second, in the BGP Tunnel Encapsulation Attribute Tunnel Types registry in the Border Gateway Protocol (BGP) Tunnel Encapsulation registry group located at:

https://www.iana.org/assignments/bgp-tunnel-encapsulation/

The early registration for Value: 15 will be changed as follows:

Value: 15
Description: SR Policy
Reference: [ RFC-to-be ]
Change Controller: IETF

Third, in the BGP Tunnel Encapsulation Attribute sub-TLVs registry in the Border Gateway Protocol (BGP) Tunnel Encapsulation registry group located on:

https://www.iana.org/assignments/bgp-tunnel-encapsulation/

The following values have had early registrations and will be made permanent and have their references changed to [ RFC-to-be ]:

Value Description Reference
------------------------------------------------------------
12 Preference sub-TLV [ RFC-to-be ]
13 Binding SID sub-TLV [ RFC-to-be ]
14 ENLP sub-TLV [ RFC-to-be ]
15 Priority sub-TLV [ RFC-to-be ]
20 SRv6 Binding SID sub-TLV [ RFC-to-be ]
128 Segment List sub-TLV [ RFC-to-be ]
129 Policy Candidate Path Name sub-TLV [ RFC-to-be ]
130 Policy Name sub-TLV [ RFC-to-be ]

Fourth, in the Color Extended Community Flags registry in the Border Gateway Protocol (BGP) Tunnel Encapsulation registry group located at:

https://www.iana.org/assignments/bgp-tunnel-encapsulation/

The early allocation for bit positions 0 and 1 are to be made permanent and their references changed changed to [ RFC-to-be ].

Fifth, a new registry is to be created called the SR Policy Segment List Sub-TLVs registry. The new registry will be located in the Border Gateway Protocol (BGP) Tunnel Encapsulation registry group located at:

https://www.iana.org/assignments/bgp-tunnel-encapsulation/

The new registry will be managed via IETF Review as defined RFC8126. The new registry will have initial registrations as follows:

Value Description Reference
-----------------------------------------------------
0 Reserved [ RFC-to-be ]
1 Segment Type A sub-TLV [ RFC-to-be ]
2 Deprecated [ RFC-to-be ]
3-8 Unassigned
9 Weight sub-TLV [ RFC-to-be ]
10 Deprecated [ RFC-to-be ]
11 Deprecated [ RFC-to-be ]
12 Deprecated [ RFC-to-be ]
13 Segment Type B sub-TLV [ RFC-to-be ]
14-255 Unassigned

Sixth, a new registry is to be created called the SR Policy Binding SID Flags registry. The new registry will be located in the Border Gateway Protocol (BGP) Tunnel Encapsulation registry group located at:

https://www.iana.org/assignments/bgp-tunnel-encapsulation/

The new registry will be managed via Standards Action as defined RFC8126. The new registry will have initial registrations as follows:

Bit Description Reference
-----------------------------------------------------------------
0 Specified-BSID-Only Flag (S-Flag) [ RFC-to-be ]
1 Drop Upon Invalid Flag (I-Flag) [ RFC-to-be ]
2-7 Unassigned

Seventh, a new registry is to be created called the SR Policy SRv6 Binding SID Flags registry. The new registry will be located in the Border Gateway Protocol (BGP) Tunnel Encapsulation registry group located at:

https://www.iana.org/assignments/bgp-tunnel-encapsulation/

The new registry will be managed via Standards Action as defined RFC8126. The new registry will have initial registrations as follows:

Bit Description Reference
----------------------------------------------------------------
0 Specified-BSID-Only Flag (S-Flag) [ RFC-to-be ]
1 Drop Upon Invalid Flag (I-Flag) [ RFC-to-be ]
2 SRv6 Endpoint Behavior &
SID Structure Flag (B-Flag) [ RFC-to-be ]
3-7 Unassigned

Eighth, a new registry is to be created called the SR Policy Segment Flags registry. The new registry will be located in the Border Gateway Protocol (BGP) Tunnel Encapsulation registry group located at:

https://www.iana.org/assignments/bgp-tunnel-encapsulation/

The new registry will be managed via IETF Review as defined RFC8126. The new registry will have initial registrations as follows:

Bit Description Reference
-----------------------------------------------------------
0 Segment Verification Flag (V-Flag) [ RFC-to-be ]
1-2 Unassigned
3 SRv6 Endpoint Behavior & SID Structure Flag (B-Flag) [ RFC-to-be ]
4-7 Unassigned

Ninth, a new registry is to be created called the Color Extended Community Color-Only Types registry. The new registry will be located in the Border Gateway Protocol (BGP) Tunnel Encapsulation registry group located at:

https://www.iana.org/assignments/bgp-tunnel-encapsulation/

The new registry will be managed via Standards Action as defined RFC8126. The new registry will have initial registrations as follows:

Type Description Reference
-----------------------------------------------------------
0 Specific Endpoint Match [ RFC-to-be ]
1 Specific or Null Endpoint Match [ RFC-to-be ]
2 Specific, Null, or Any Endpoint Match [ RFC-to-be ]
3 Unassigned

Tenth, new registry is to be created called the SR Policy ENLP Values registry. The new registry will be located in the Segment Routing registry group located at:

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

The new registry will be managed via Standards Action as defined in RFC8126. There are initial registrations in the new registry as follows:

| Value | Description | Reference |
+------+------------+-----------+
| 0 | Reserved (not to be used). | [ RFC-to-be ] |
+----------+--------------------------------------------+----------------+
| 1 | Push an IPv4 Explicit NULL label on an | [ RFC-to-be ] |
| | unlabeled IPv4 packet, but do not push an | |
| | IPv6 Explicit NULL label on an unlabeled | |
| | IPv6 packet. | |
+----------+--------------------------------------------+----------------+
| 2 | Push an IPv6 Explicit NULL label on an | [ RFC-to-be ] |
| | unlabeled IPv6 packet, but do not push an | |
| | IPv4 Explicit NULL label on an unlabeled | |
| | IPv4 packet. | |
+----------+--------------------------------------------+----------------+
| 3 | Push an IPv4 Explicit NULL label on an | [ RFC-to-be ] |
| | unlabeled IPv4 packet, and push an IPv6 | |
| | Explicit NULL label on an unlabeled IPv6 | |
| | packet. | |
+----------+--------------------------------------------+----------------+
| 4 | Do not push an Explicit NULL label. | [ RFC-to-be ] |
+----------+--------------------------------------------+----------------+
| 5 - 255 | Reserved. | [ RFC-to-be ] |
+----------+--------------------------------------------+----------------

We understand that these ten actions are the only ones required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

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

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-11-11):

From: The IESG
To: IETF-Announce
CC: draft-ietf-idr-sr-policy-safi@ietf.org, idr-chairs@ietf.org, idr@ietf.org, rdd@cert.org, shares@ndzh.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Advertising Segment Routing Policies in BGP) to Proposed Standard


The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document: - 'Advertising Segment Routing Policies in
BGP'
  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 2024-11-11. 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


  A Segment Routing (SR) Policy is an ordered list of segments (i.e.,
  instructions) that represent a source-routed policy.  An SR Policy
  consists of one or more candidate paths, each consisting of one or
  more segment lists.  A headend may be provisioned with candidate
  paths for an SR Policy via several different mechanisms, e.g., CLI,
  NETCONF, PCEP, or BGP.

  This document specifies how BGP may be used to distribute SR Policy
  candidate paths.  It introduces a BGP SAFI to advertise a candidate
  path of a Segment Routing (SR) Policy and defines sub-TLVs for the
  Tunnel Encapsulation Attribute for signaling information about these
  candidate paths.

  This documents updates RFC9012 with extensions to the Color Extended
  Community to support additional steering modes over SR Policy.




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


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2984/
  https://datatracker.ietf.org/ipr/5890/
  https://datatracker.ietf.org/ipr/5891/



The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc4272: BGP Security Vulnerabilities Analysis (Informational - Internet Engineering Task Force (IETF) stream)
    draft-ietf-idr-bgp-ls-sr-policy: Advertisement of Segment Routing Policies using BGP Link-State (None - Internet Engineering Task Force (IETF) stream)
    draft-ietf-idr-bgp-sr-segtypes-ext: Segment Routing Segment Types Extensions for BGP SR Policy (None - Internet Engineering Task Force (IETF) stream)
    rfc6952: Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide (Informational - Internet Engineering Task Force (IETF) stream)

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

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

Post-WG LC reviews:
Post WG-LC issues are kept in:
https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues

Implementation report:
https://wiki.ietf.org/group/idr/BGP-Implementation-report/draft-ietf-idr-segment-routing-te-policy-implement


1) OPS-DIR directorate:
https://mailarchive.ietf.org/arch/msg/ops-dir/JFInEGfu1GpIgTuCTWsNMJbGwp0/
author: Nagendra Kumar
github tracking: all issues closed as of -05.txt
https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues/1


2) RTG-DIR Directorate:
https://mailarchive.ietf.org/arch/msg/idr/nrGNrGNn6_U7GiEGMYhQ0rBK2Y0/
github tracking:
full text: https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues/2
all issues: https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues
status of -05: open issues: S2-02, S2-03 (partial fixes) [7/25] 
Shepherd's review sent in response to -05:
https://mailarchive.ietf.org/arch/msg/idr/tlYtJwbNZYNatqUUasbxusHwWeE/
Status review for -06 text
https://mailarchive.ietf.org/arch/msg/idr/zOiZaKL98Z52mmsAx7SPWDHlmnM/
github issues for RTG-IR
Shepherd's review sent for -05 (tracked changes in github)
https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues/32

SEC-DIR Review:
original comment:
https://mailarchive.ietf.org/arch/msg/idr/BEdfxxbUD-lDmrmiljSJhnaYk8E/
response:
https://mailarchive.ietf.org/arch/msg/idr/WcJ_A2wHMBDNtzxdwf1WAnESEcA/

History of WG LCs:
6 steps: 1) 1st WG LC, 2) Wait for RFC7752, 3) AD review requires split (implemented/non-implemented), 
4) review split (2nd WG LC), 5) Shepherd notes RFC9012 issues, 6) 3rd WG LC

Please note that the shepherd noted after the 2nd WG LC the issues with RFC9012.
The final call was explicit that the RFC9012 format was used, but not the subTLVs and validation.

Dates: 1st: 8/06/2021, Split-IETF 3/15/2023, Split ok: 10/10-10/23/2023 (ok 10/23), 
3rd WG LC: 2/15-3/18/2024
https://mailarchive.ietf.org/arch/msg/idr/b8VABzT4fTyvY0j6_FuA04RYiHY/
Result of WG LC (3/19/2024)
https://mailarchive.ietf.org/arch/msg/idr/rLJzLz_U8ZUuBaTBg7LIOh6CZ0o/

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

At the 3rd WG LC, consensus was solid, but no comments were made on the
use of RFC9012.

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 discontent to 3rd WG LC.

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)?
6 implementations (details on 5 implementations)
https://wiki.ietf.org/en/group/idr/BGP-Implementation-report/draft-ietf-idr-segment-routing-te-policy-implement

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

Requested Early Review of RTGDIR, OPSDIR, TSVART, SECDIR
Why OPSDIR + SECDIR:  operational + security issues with the SR Candidate paths
OPS-DIR:
https://mailarchive.ietf.org/arch/msg/ops-dir/JFInEGfu1GpIgTuCTWsNMJbGwp0/
author: Nagendra KumarWhy TSVART: Link to the emerging Intent/Color routing work

SEC-DIR: Ready
https://mailarchive.ietf.org/arch/msg/secdir/NtawBFAsAZAXkH-FiwGc5rebzX4/

Review as draft-ietf-idr-sr-policy-safi: 
OPSDIR Early review (of -01 and -03) by Nagendra Nainar  Has issues
RTGDIR Early review (of -00 and -03)  by Zhaohui Zhang  Has issues
SECIDR Early review of (-04) - requested -04 (6/10/2024)
TSVART Early review (of -00) by David Black On the Right Track
INTDIR Early Review due 2024-02-29 Requested - not given.

Review a draft-ietf-idr-segment-routing-te-policy
RTGDIR Early review (of draft-ietf-idr-segment-routing-te-policy -18) by Mohamed Boucadair  Has issues
SECDIR Early review (of draft-ietf-idr-segment-routing-te-policy -18) by Vincent Roca Ready
INTDIR Early review (of draft-ietf-idr-segment-routing-te-policy -18) by Brian Haberman Ready w/issues

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.

No formal review criteria - MIB, Yang, Media type, URI
Another Yang module needs to add this to the BGP Base. 
Will add to IDR Wiki.

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

No Yang module.
Another Yang module needs to add this to the BGP Base. 
Will add to IDR Wiki.

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.

No formal review

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

Clearly rewritten.
Only one suggestion is outstanding.  We agreed that the AD would check if these definitions should be added to text:
========
Controller:  A controller, in a computing context, is a hardware device or a software program that manages or directs the flow of data between two entities.
BGP Controller: A Route Reflector (RR) [RFC4456] which has a function of controlling BGP routes sent between RR (BGP) and client BGP speakers. 
Provisioning BGP controller:  Per [RFC9256], that BGP Controller (RR) whose additional application helps provision the                                                Segment Routing (SR).
=========

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?

Shepherd's comments: all issues were reviewed and checked multiple times.  If AD finds one, please let the shepherd know.

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 - 6 implementations + SR work. 

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.

Call for IPR
https://mailarchive.ietf.org/arch/msg/idr/b8VABzT4fTyvY0j6_FuA04RYiHY/

1. Stefano Previdi
https://mailarchive.ietf.org/arch/msg/idr/URkVWm6k-mfSNqs9qYcfeISUR9c/

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

3.  Ketan Talaulikar, Ed.
https://mailarchive.ietf.org/arch/msg/idr/T2VaUQTIP0KqO5X3WGM6ThnlUQ8/

4. Paul Mattes
https://mailarchive.ietf.org/arch/msg/idr/TVTu_1hwgZozFLmHhfQnft5O7Kw/

5. Dhanendra Jain
https://mailarchive.ietf.org/arch/msg/idr/16MkEx6jVqfwUEGDtvtaKCPNBJg/

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.

Total number of authors: 5, 
No contributors.

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 only find one out-of-date reference
draft-ietf-idr-bgp-ls-sr-policy-04 needs to be updated. It will be check in the next revision.

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

No all informative and normative references are valid.

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

All references are correct.

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.

None.

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?

all normative references are RFCs.

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.

Yes - [RFC9012]

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.

[TBD]

[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://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/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.* [RFC4758]

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

Post-WG LC reviews:
Post WG-LC issues are kept in:
https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues

Implementation report:
https://wiki.ietf.org/group/idr/BGP-Implementation-report/draft-ietf-idr-segment-routing-te-policy-implement


1) OPS-DIR directorate:
https://mailarchive.ietf.org/arch/msg/ops-dir/JFInEGfu1GpIgTuCTWsNMJbGwp0/
author: Nagendra Kumar
github tracking: all issues closed as of -05.txt
https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues/1


2) RTG-DIR Directorate:
https://mailarchive.ietf.org/arch/msg/idr/nrGNrGNn6_U7GiEGMYhQ0rBK2Y0/
github tracking:
full text: https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues/2
all issues: https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues
status of -05: open issues: S2-02, S2-03 (partial fixes) [7/25] 
Shepherd's review sent in response to -05:
https://mailarchive.ietf.org/arch/msg/idr/tlYtJwbNZYNatqUUasbxusHwWeE/
Status review for -06 text
https://mailarchive.ietf.org/arch/msg/idr/zOiZaKL98Z52mmsAx7SPWDHlmnM/
github issues for RTG-IR
Shepherd's review sent for -05 (tracked changes in github)
https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues/32

SEC-DIR Review:
original comment:
https://mailarchive.ietf.org/arch/msg/idr/BEdfxxbUD-lDmrmiljSJhnaYk8E/
response:
https://mailarchive.ietf.org/arch/msg/idr/WcJ_A2wHMBDNtzxdwf1WAnESEcA/

History of WG LCs:
6 steps: 1) 1st WG LC, 2) Wait for RFC7752, 3) AD review requires split (implemented/non-implemented), 
4) review split (2nd WG LC), 5) Shepherd notes RFC9012 issues, 6) 3rd WG LC

Please note that the shepherd noted after the 2nd WG LC the issues with RFC9012.
The final call was explicit that the RFC9012 format was used, but not the subTLVs and validation.

Dates: 1st: 8/06/2021, Split-IETF 3/15/2023, Split ok: 10/10-10/23/2023 (ok 10/23), 
3rd WG LC: 2/15-3/18/2024
https://mailarchive.ietf.org/arch/msg/idr/b8VABzT4fTyvY0j6_FuA04RYiHY/
Result of WG LC (3/19/2024)
https://mailarchive.ietf.org/arch/msg/idr/rLJzLz_U8ZUuBaTBg7LIOh6CZ0o/

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

At the 3rd WG LC, consensus was solid, but no comments were made on the
use of RFC9012.

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 discontent to 3rd WG LC.

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)?
6 implementations (details on 5 implementations)
https://wiki.ietf.org/en/group/idr/BGP-Implementation-report/draft-ietf-idr-segment-routing-te-policy-implement

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

Requested Early Review of RTGDIR, OPSDIR, TSVART, SECDIR
Why OPSDIR + SECDIR:  operational + security issues with the SR Candidate paths
OPS-DIR:
https://mailarchive.ietf.org/arch/msg/ops-dir/JFInEGfu1GpIgTuCTWsNMJbGwp0/
author: Nagendra KumarWhy TSVART: Link to the emerging Intent/Color routing work

SEC-DIR: Ready
https://mailarchive.ietf.org/arch/msg/secdir/NtawBFAsAZAXkH-FiwGc5rebzX4/

Review as draft-ietf-idr-sr-policy-safi: 
OPSDIR Early review (of -01 and -03) by Nagendra Nainar  Has issues
RTGDIR Early review (of -00 and -03)  by Zhaohui Zhang  Has issues
SECIDR Early review of (-04) - requested -04 (6/10/2024)
TSVART Early review (of -00) by David Black On the Right Track
INTDIR Early Review due 2024-02-29 Requested - not given.

Review a draft-ietf-idr-segment-routing-te-policy
RTGDIR Early review (of draft-ietf-idr-segment-routing-te-policy -18) by Mohamed Boucadair  Has issues
SECDIR Early review (of draft-ietf-idr-segment-routing-te-policy -18) by Vincent Roca Ready
INTDIR Early review (of draft-ietf-idr-segment-routing-te-policy -18) by Brian Haberman Ready w/issues

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.

No formal review criteria - MIB, Yang, Media type, URI
Another Yang module needs to add this to the BGP Base. 
Will add to IDR Wiki.

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

No Yang module.
Another Yang module needs to add this to the BGP Base. 
Will add to IDR Wiki.

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.

No formal review

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

Clearly rewritten.
Only one suggestion is outstanding.  We agreed that the AD would check if these definitions should be added to text:
========
Controller:  A controller, in a computing context, is a hardware device or a software program that manages or directs the flow of data between two entities.
BGP Controller: A Route Reflector (RR) [RFC4456] which has a function of controlling BGP routes sent between RR (BGP) and client BGP speakers. 
Provisioning BGP controller:  Per [RFC9256], that BGP Controller (RR) whose additional application helps provision the                                                Segment Routing (SR).
=========

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?

Shepherd's comments: all issues were reviewed and checked multiple times.  If AD finds one, please let the shepherd know.

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 - 6 implementations + SR work. 

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.

Call for IPR
https://mailarchive.ietf.org/arch/msg/idr/b8VABzT4fTyvY0j6_FuA04RYiHY/

1. Stefano Previdi
https://mailarchive.ietf.org/arch/msg/idr/URkVWm6k-mfSNqs9qYcfeISUR9c/

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

3.  Ketan Talaulikar, Ed.
https://mailarchive.ietf.org/arch/msg/idr/T2VaUQTIP0KqO5X3WGM6ThnlUQ8/

4. Paul Mattes
https://mailarchive.ietf.org/arch/msg/idr/TVTu_1hwgZozFLmHhfQnft5O7Kw/

5. Dhanendra Jain
https://mailarchive.ietf.org/arch/msg/idr/16MkEx6jVqfwUEGDtvtaKCPNBJg/

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.

Total number of authors: 5, 
No contributors.

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 only find one out-of-date reference
draft-ietf-idr-bgp-ls-sr-policy-04 needs to be updated. It will be check in the next revision.

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

No all informative and normative references are valid.

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

All references are correct.

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.

None.

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?

all normative references are RFCs.

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.

Yes - [RFC9012]

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.

[TBD]

[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://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/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.* [RFC4758]

1) implementation report check
https://wiki.ietf.org/group/idr/BGP-Implementation-report/draft-ietf-idr-segment-routing-te-policy-implement


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

Post-WG LC reviews:
Post WG-LC issues are kept in:
https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues

Implementation report:
https://wiki.ietf.org/group/idr/BGP-Implementation-report/draft-ietf-idr-segment-routing-te-policy-implement


1) OPS-DIR directorate:
https://mailarchive.ietf.org/arch/msg/ops-dir/JFInEGfu1GpIgTuCTWsNMJbGwp0/
author: Nagendra Kumar
github tracking: all issues closed as of -05.txt
https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues/1


2) RTG-DIR Directorate:
https://mailarchive.ietf.org/arch/msg/idr/nrGNrGNn6_U7GiEGMYhQ0rBK2Y0/
github tracking:
full text: https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues/2
all issues: https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues
status of -05: open issues: S2-02, S2-03 (partial fixes) [7/25] 
Shepherd's review sent in response to -05:
https://mailarchive.ietf.org/arch/msg/idr/tlYtJwbNZYNatqUUasbxusHwWeE/
Status review for -06 text
https://mailarchive.ietf.org/arch/msg/idr/zOiZaKL98Z52mmsAx7SPWDHlmnM/
github issues for RTG-IR
Shepherd's review sent for -05 (tracked changes in github)
https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues/32

SEC-DIR Review:
original comment:
https://mailarchive.ietf.org/arch/msg/idr/BEdfxxbUD-lDmrmiljSJhnaYk8E/
response:
https://mailarchive.ietf.org/arch/msg/idr/WcJ_A2wHMBDNtzxdwf1WAnESEcA/

History of WG LCs:
6 steps: 1) 1st WG LC, 2) Wait for RFC7752, 3) AD review requires split (implemented/non-implemented), 
4) review split (2nd WG LC), 5) Shepherd notes RFC9012 issues, 6) 3rd WG LC

Please note that the shepherd noted after the 2nd WG LC the issues with RFC9012.
The final call was explicit that the RFC9012 format was used, but not the subTLVs and validation.

Dates: 1st: 8/06/2021, Split-IETF 3/15/2023, Split ok: 10/10-10/23/2023 (ok 10/23), 
3rd WG LC: 2/15-3/18/2024
https://mailarchive.ietf.org/arch/msg/idr/b8VABzT4fTyvY0j6_FuA04RYiHY/
Result of WG LC (3/19/2024)
https://mailarchive.ietf.org/arch/msg/idr/rLJzLz_U8ZUuBaTBg7LIOh6CZ0o/

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

At the 3rd WG LC, consensus was solid, but no comments were made on the
use of RFC9012.

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 discontent to 3rd WG LC.

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)?
6 implementations (details on 5 implementations)
https://wiki.ietf.org/en/group/idr/BGP-Implementation-report/draft-ietf-idr-segment-routing-te-policy-implement

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

Requested Early Review of RTGDIR, OPSDIR, TSVART, SECDIR
Why OPSDIR + SECDIR:  operational + security issues with the SR Candidate paths
OPS-DIR:
https://mailarchive.ietf.org/arch/msg/ops-dir/JFInEGfu1GpIgTuCTWsNMJbGwp0/
author: Nagendra KumarWhy TSVART: Link to the emerging Intent/Color routing work

SEC-DIR: Ready
https://mailarchive.ietf.org/arch/msg/secdir/NtawBFAsAZAXkH-FiwGc5rebzX4/

Review as draft-ietf-idr-sr-policy-safi: 
OPSDIR Early review (of -01 and -03) by Nagendra Nainar  Has issues
RTGDIR Early review (of -00 and -03)  by Zhaohui Zhang  Has issues
SECIDR Early review of (-04) - requested -04 (6/10/2024)
TSVART Early review (of -00) by David Black On the Right Track
INTDIR Early Review due 2024-02-29 Requested - not given.

Review a draft-ietf-idr-segment-routing-te-policy
RTGDIR Early review (of draft-ietf-idr-segment-routing-te-policy -18) by Mohamed Boucadair  Has issues
SECDIR Early review (of draft-ietf-idr-segment-routing-te-policy -18) by Vincent Roca Ready
INTDIR Early review (of draft-ietf-idr-segment-routing-te-policy -18) by Brian Haberman Ready w/issues

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.

No formal review criteria - MIB, Yang, Media type, URI
Another Yang module needs to add this to the BGP Base. 
Will add to IDR Wiki.

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

No Yang module.
Another Yang module needs to add this to the BGP Base. 
Will add to IDR Wiki.

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.

No formal review

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

Clearly rewritten.
Only one suggestion is outstanding.  We agreed that the AD would check if these definitions should be added to text:
========
Controller:  A controller, in a computing context, is a hardware device or a software program that manages or directs the flow of data between two entities.
BGP Controller: A Route Reflector (RR) [RFC4456] which has a function of controlling BGP routes sent between RR (BGP) and client BGP speakers. 
Provisioning BGP controller:  Per [RFC9256], that BGP Controller (RR) whose additional application helps provision the                                                Segment Routing (SR).
=========

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?

Shepherd's comments: all issues were reviewed and checked multiple times.  If AD finds one, please let the shepherd know.

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 - 6 implementations + SR work. 

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.

Call for IPR
https://mailarchive.ietf.org/arch/msg/idr/b8VABzT4fTyvY0j6_FuA04RYiHY/

1. Stefano Previdi
https://mailarchive.ietf.org/arch/msg/idr/URkVWm6k-mfSNqs9qYcfeISUR9c/

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

3.  Ketan Talaulikar, Ed.
https://mailarchive.ietf.org/arch/msg/idr/T2VaUQTIP0KqO5X3WGM6ThnlUQ8/

4. Paul Mattes
https://mailarchive.ietf.org/arch/msg/idr/TVTu_1hwgZozFLmHhfQnft5O7Kw/

5. Dhanendra Jain
https://mailarchive.ietf.org/arch/msg/idr/16MkEx6jVqfwUEGDtvtaKCPNBJg/

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.

Total number of authors: 5, 
No contributors.

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 only find one out-of-date reference
draft-ietf-idr-bgp-ls-sr-policy-04 needs to be updated. It will be check in the next revision.

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

No all informative and normative references are valid.

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

All references are correct.

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.

None.

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?

all normative references are RFCs.

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.

Yes - [RFC9012]

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.

[TBD]

[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://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/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.* [RFC4758]

Blocking issues:
1) Directorate reviews have been resolved - except for partial resolution RTG-DIR S2-02, S2-03
2) NITs issues (on-06)
3) implementation report check

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

Post-WG LC reviews:
Post WG-LC issues are kept in:
https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues

1) OPS-DIR directorate:
https://mailarchive.ietf.org/arch/msg/ops-dir/JFInEGfu1GpIgTuCTWsNMJbGwp0/
author: Nagendra Kumar
github tracking: all issues closed as of -05.txt
https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues/1


2) RTG-DIR Directorate:
https://mailarchive.ietf.org/arch/msg/idr/nrGNrGNn6_U7GiEGMYhQ0rBK2Y0/
github tracking:
full text: https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues/2
all issues: https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues
status of -05: open issues: S2-02, S2-03 (partial fixes) [7/25] 
Shepherd's review sent in response to -05:
https://mailarchive.ietf.org/arch/msg/idr/tlYtJwbNZYNatqUUasbxusHwWeE/
github issues for RTG-IR
Shepherd's review sent for -05 (tracked changes in github)
https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues/32

SEC-DIR Review:
original comment:
https://mailarchive.ietf.org/arch/msg/idr/BEdfxxbUD-lDmrmiljSJhnaYk8E/
response:
https://mailarchive.ietf.org/arch/msg/idr/WcJ_A2wHMBDNtzxdwf1WAnESEcA/

History of WG LCs:
6 steps: 1) 1st WG LC, 2) Wait for RFC7752, 3) AD review requires split (implemented/non-implemented), 
4) review split (2nd WG LC), 5) Shepherd notes RFC9012 issues, 6) 3rd WG LC

Please note that the shepherd noted after the 2nd WG LC the issues with RFC9012.
The final call was explicit that the RFC9012 format was used, but not the subTLVs and validation.

Dates: 1st: 8/06/2021, Split-IETF 3/15/2023, Split ok: 10/10-10/23/2023 (ok 10/23), 
3rd WG LC: 2/15-3/18/2024
https://mailarchive.ietf.org/arch/msg/idr/b8VABzT4fTyvY0j6_FuA04RYiHY/
Result of WG LC (3/19/2024)
https://mailarchive.ietf.org/arch/msg/idr/rLJzLz_U8ZUuBaTBg7LIOh6CZ0o/

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

At the 3rd WG LC, consensus was solid, but no comments were made on the
use of RFC9012.

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 discontent to 3rd WG LC.

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)?
6 implementations (details on 5 implementations)
https://wiki.ietf.org/en/group/idr/BGP-Implementation-report/draft-ietf-idr-segment-routing-te-policy-implement

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

Requested Early Review of RTGDIR, OPSDIR, TSVART, SECDIR
Why OPSDIR + SECDIR:  operational + security issues with the SR Candidate paths
OPS-DIR:
https://mailarchive.ietf.org/arch/msg/ops-dir/JFInEGfu1GpIgTuCTWsNMJbGwp0/
author: Nagendra KumarWhy TSVART: Link to the emerging Intent/Color routing work

SEC-DIR: Ready
https://mailarchive.ietf.org/arch/msg/secdir/NtawBFAsAZAXkH-FiwGc5rebzX4/

Review as draft-ietf-idr-sr-policy-safi: 
OPSDIR Early review (of -01 and -03) by Nagendra Nainar  Has issues
RTGDIR Early review (of -00 and -03)  by Zhaohui Zhang  Has issues
SECIDR Early review of (-04) - requested -04 (6/10/2024)
TSVART Early review (of -00) by David Black On the Right Track
INTDIR Early Review due 2024-02-29 Requested - not given.

Review a draft-ietf-idr-segment-routing-te-policy
RTGDIR Early review (of draft-ietf-idr-segment-routing-te-policy -18) by Mohamed Boucadair  Has issues
SECDIR Early review (of draft-ietf-idr-segment-routing-te-policy -18) by Vincent Roca Ready
INTDIR Early review (of draft-ietf-idr-segment-routing-te-policy -18) by Brian Haberman Ready w/issues

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.

No formal review criteria - MIB, Yang, Media type, URI
Another Yang module needs to add this to the BGP Base. 
Will add to IDR Wiki.

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

No Yang module.
Another Yang module needs to add this to the BGP Base. 
Will add to IDR Wiki.

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.

No formal review

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

Clearly rewritten.
Only one suggestion is outstanding.  We agreed that the AD would check if these definitions should be added to text:
Controller:  A controller, in a computing context, is a hardware device or a software program that manages or directs the flow of data between two entities.

open text for definitions:/
BGP Controller: A Route Reflector (RR) [RFC4456] which has a function of controlling BGP routes sent between RR (BGP) and client BGP speakers. 

Provisioning BGP controller:  Per [RFC9256], that BGP Controller (RR) whose additional application helps provision the                                                Segment Routing (SR)./


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?

Shepherd's comments: all issues reviewed and checked multiple times.  If AD finds one, please let the shepherd know.

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 - 6 implementations + SR work.
Issues - BGP does not do full validation

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.

Call for IPR
https://mailarchive.ietf.org/arch/msg/idr/b8VABzT4fTyvY0j6_FuA04RYiHY/

1. Stefano Previdi
https://mailarchive.ietf.org/arch/msg/idr/URkVWm6k-mfSNqs9qYcfeISUR9c/

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

3.  Ketan Talaulikar, Ed.
https://mailarchive.ietf.org/arch/msg/idr/T2VaUQTIP0KqO5X3WGM6ThnlUQ8/

4. Paul Mattes
https://mailarchive.ietf.org/arch/msg/idr/TVTu_1hwgZozFLmHhfQnft5O7Kw/

5. Dhanendra Jain
https://mailarchive.ietf.org/arch/msg/idr/16MkEx6jVqfwUEGDtvtaKCPNBJg/

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.

Total number of authors: 5, 
No contributors.

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 - run nits on -06

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

No all informative and normative references are valid.

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

All references are correct.

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.

None.

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?

all normative references are RFCs.

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.

Yes - [RFC9012]

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.

[TBD]

[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://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/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.* [RFC4758]

Blocking issues:
1) Directorate reviews have issues (RTG-DIR, SEC-DIR, OPS-DIR). 
2) NITs issues
3) implementation report

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

Post-WG LC reviews:
Post WG-LC issues are kept in:
https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues

1) OPS-DIR directorate:
https://mailarchive.ietf.org/arch/msg/ops-dir/JFInEGfu1GpIgTuCTWsNMJbGwp0/
author: Nagendra Kumar
github tracking:
https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues/1


2) RTG-DIR Directorate:
https://mailarchive.ietf.org/arch/msg/idr/nrGNrGNn6_U7GiEGMYhQ0rBK2Y0/
github tracking:
full text: https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues/2
all issues: https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues
status of -04: open issues: 12, 17, 19, 20, 24, 25, 26
Shepherd report sent in response:
https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues/32


History of WG LCs:
6 steps: 1) 1st WG LC, 2) Wait for RFC7752, 3) AD review requires split (implemented/non-implemented), 
4) review split (2nd WG LC), 5) Shepherd notes RFC9012 issues, 6) 3rd WG LC

Please note that the shepherd noted after the 2nd WG LC the issues with RFC9012.
The final call was explicit that the RFC9012 format was used, but not the subTLVs and validation.

Dates: 1st: 8/06/2021, Split-IETF 3/15/2023, Split ok: 10/10-10/23/2023 (ok 10/23), 
3rd WG LC: 2/15-3/18/2024
https://mailarchive.ietf.org/arch/msg/idr/b8VABzT4fTyvY0j6_FuA04RYiHY/
Result of WG LC (3/19/2024)
https://mailarchive.ietf.org/arch/msg/idr/rLJzLz_U8ZUuBaTBg7LIOh6CZ0o/

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

At the 3rd WG LC, consensus was solid, but no comments were made on the
use of RFC9012.

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 discontent to 3rd WG LC.

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)?
6 implementations (details on 5 implementations)
https://wiki.ietf.org/en/group/idr/BGP-Implementation-report/draft-ietf-idr-segment-routing-te-policy-implement

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

Requested Early Review of RTGDIR, OPSDIR, TSVART, SECDIR
Why OPSDIR + SECDIR:  operational + security issues with the SR Candidate paths
OPS-DIR:
https://mailarchive.ietf.org/arch/msg/ops-dir/JFInEGfu1GpIgTuCTWsNMJbGwp0/
author: Nagendra KumarWhy TSVART: Link to the emerging Intent/Color routing work

SEC-DIR: Ready
https://mailarchive.ietf.org/arch/msg/secdir/NtawBFAsAZAXkH-FiwGc5rebzX4/

Review as draft-ietf-idr-sr-policy-safi: 
OPSDIR Early review (of -01 and -03) by Nagendra Nainar  Has issues
RTGDIR Early review (of -00 and -03)  by Zhaohui Zhang  Has issues
SECIDR Early review of (-04) - requested -04 (6/10/2024)
TSVART Early review (of -00) by David Black On the Right Track
INTDIR Early Review due 2024-02-29 Requested - not given.

Review a draft-ietf-idr-segment-routing-te-policy
RTGDIR Early review (of draft-ietf-idr-segment-routing-te-policy -18) by Mohamed Boucadair  Has issues
SECDIR Early review (of draft-ietf-idr-segment-routing-te-policy -18) by Vincent Roca Ready
INTDIR Early review (of draft-ietf-idr-segment-routing-te-policy -18) by Brian Haberman Ready w/issues

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.

No formal review criteria - MIB, Yang, Media type, URI
Another Yang module needs to add this to the BGP Base. 
Will add to IDR Wiki.

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

No Yang module.
Another Yang module needs to add this to the BGP Base. 
Will add to IDR Wiki.

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.

No formal review

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

Clearly rewritten.
Shepherd's comments: (TBD after -05)

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?

Shepherd's comments: (TBD after -05)

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 - 6 implementations + SR work.
Issues - BGP does not do full validation

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.

Call for IPR
https://mailarchive.ietf.org/arch/msg/idr/b8VABzT4fTyvY0j6_FuA04RYiHY/

1. Stefano Previdi
https://mailarchive.ietf.org/arch/msg/idr/URkVWm6k-mfSNqs9qYcfeISUR9c/

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

3.  Ketan Talaulikar, Ed.
https://mailarchive.ietf.org/arch/msg/idr/T2VaUQTIP0KqO5X3WGM6ThnlUQ8/

4. Paul Mattes
https://mailarchive.ietf.org/arch/msg/idr/TVTu_1hwgZozFLmHhfQnft5O7Kw/

5. Dhanendra Jain
https://mailarchive.ietf.org/arch/msg/idr/16MkEx6jVqfwUEGDtvtaKCPNBJg/

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.

Total number of authors: 5, 
No contributors.

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 - run nits on -05

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

No all informative and normative references are valid.

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

All references are correct.

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.

None.

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?

all normative references are RFCs.

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.

Yes - [RFC9012]

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.

[TBD]

[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://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/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.* [RFC4758]

Blocking issues:
1) Directorate reviews have issues (RTG-DIR, SEC-DIR, OPS-DIR). 
2) NITs issues
3) implementation report

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

Post-WG LC reviews:
Post WG-LC issues are kept in:
https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues

1) OPS-DIR directorate:
https://mailarchive.ietf.org/arch/msg/ops-dir/JFInEGfu1GpIgTuCTWsNMJbGwp0/
author: Nagendra Kumar
github tracking:
https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues/1


2) RTG-DIR Directorate:
https://mailarchive.ietf.org/arch/msg/idr/nrGNrGNn6_U7GiEGMYhQ0rBK2Y0/
github tracking:
full text: https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues/2
all issues: https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues
status of -04: open issues: 12, 17, 19, 20, 24, 25, 26
Shepherd report sent in response:
https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues/32


History of WG LCs:
6 steps: 1) 1st WG LC, 2) Wait for RFC7752, 3) AD review requires split (implemented/non-implemented), 
4) review split (2nd WG LC), 5) Shepherd notes RFC9012 issues, 6) 3rd WG LC

Please note that the shepherd noted after the 2nd WG LC the issues with RFC9012.
The final call was explicit that the RFC9012 format was used, but not the subTLVs and validation.

Dates: 1st: 8/06/2021, Split-IETF 3/15/2023, Split ok: 10/10-10/23/2023 (ok 10/23), 
3rd WG LC: 2/15-3/18/2024
https://mailarchive.ietf.org/arch/msg/idr/b8VABzT4fTyvY0j6_FuA04RYiHY/
Result of WG LC (3/19/2024)
https://mailarchive.ietf.org/arch/msg/idr/rLJzLz_U8ZUuBaTBg7LIOh6CZ0o/

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

At the 3rd WG LC, consensus was solid, but no comments were made on the
use of RFC9012.

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 discontent to 3rd WG LC.

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)?
6 implementations (details on 5 implementations)
https://wiki.ietf.org/en/group/idr/BGP-Implementation-report/draft-ietf-idr-segment-routing-te-policy-implement

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

Requested Early Review of RTGDIR, OPSDIR, TSVART, SECDIR
Why OPSDIR + SECDIR:  operational + security issues with the SR Candidate paths
OPS-DIR:
https://mailarchive.ietf.org/arch/msg/ops-dir/JFInEGfu1GpIgTuCTWsNMJbGwp0/
author: Nagendra KumarWhy TSVART: Link to the emerging Intent/Color routing work

SEC-DIR:

Review as draft-ietf-idr-sr-policy-safi: 
OPSDIR Early review (of -01 and -03) by Nagendra Nainar  Has issues
RTGDIR Early review (of -00 and -03)  by Zhaohui Zhang  Has issues
SECIDR Early review of (-18) by Vincent Roca: Ready
https://datatracker.ietf.org/doc/review-ietf-idr-segment-routing-te-policy-18-secdir-early-roca-2022-0
7-18/TSVART Early review (of -00) by David Black On the Right Track
INTDIR Early Review due 2024-02-29 Requested - not given.

Requested SEC-DIR (of -04), but earlier review OKed the draft. 

Review a draft-ietf-idr-segment-routing-te-policy
RTGDIR Early review (of draft-ietf-idr-segment-routing-te-policy -18) by Mohamed Boucadair  Has issues
SECDIR Early review (of draft-ietf-idr-segment-routing-te-policy -18) by Vincent Roca Ready
INTDIR Early review (of draft-ietf-idr-segment-routing-te-policy -18) by Brian Haberman Ready w/issues

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.

No formal review criteria - MIB, Yang, Media type, URI
Another Yang module needs to add this to the BGP Base. 
Will add to IDR Wiki.

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

No Yang module.
Another Yang module needs to add this to the BGP Base. 
Will add to IDR Wiki.

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.

No formal review

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

[TBD - ]

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 - need Routing list]

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 - 6 implementations + SR work.
Issues - BGP does not do full validation

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.

Call for IPR
https://mailarchive.ietf.org/arch/msg/idr/b8VABzT4fTyvY0j6_FuA04RYiHY/

1. Stefano Previdi
https://mailarchive.ietf.org/arch/msg/idr/URkVWm6k-mfSNqs9qYcfeISUR9c/

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

3.  Ketan Talaulikar, Ed.
https://mailarchive.ietf.org/arch/msg/idr/T2VaUQTIP0KqO5X3WGM6ThnlUQ8/

4. Paul Mattes
https://mailarchive.ietf.org/arch/msg/idr/TVTu_1hwgZozFLmHhfQnft5O7Kw/

5. Dhanendra Jain
https://mailarchive.ietf.org/arch/msg/idr/16MkEx6jVqfwUEGDtvtaKCPNBJg/

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.

Total number of authors: 5, 
No contributors.

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.)
[run extensive I-D nits]

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?
[TBD]

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.
[TBD]

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?

[TBD]

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.

Yes - [RFC9012]

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.

[TBD]

[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://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/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.* [RFC4758]

Blocking issues:
1) Directorate reviews have issues (RTG-DIR, SEC-DIR, OPS-DIR). 
2) NITs issues
3) implementation report

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

History -
6 steps: 1) 1st WG LC, 2) Wait for RFC7752, 3) AD review requires split (implemented/non-implemented), 
4) review split (2nd WG LC), 5) Shepherd notes RFC9012 issues, 6) 3rd WG LC

Please note that the shepherd noted after the 2nd WG LC the issues with RFC9012. The final call was explicit that the RFC9012 format was used, but not the subTLVs and validation.

Dates: 1st: 8/06/2021, Split-IETF 3/15/2023, Split ok: 10/10-10/23/2023 (ok 10/23), 
3rd WG LC: 2/15-3/18/2024
https://mailarchive.ietf.org/arch/msg/idr/b8VABzT4fTyvY0j6_FuA04RYiHY/
Result of WG LC (3/19/2024)
https://mailarchive.ietf.org/arch/msg/idr/rLJzLz_U8ZUuBaTBg7LIOh6CZ0o/

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

At the 3rd WG LC, consensus was solid, but no comments were made on the
use of RFC9012.

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 discontent to 3rd WG LC.

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)?
6 implementations (details on 5 implementations)
https://wiki.ietf.org/en/group/idr/BGP-Implementation-report/draft-ietf-idr-segment-routing-te-policy-implement

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

Requested Early Review of RTGDIR, OPSDIR, TSVART, SECDIR
Why OPSDIR + SECDIR:  operational + security issues with the SR Candidate paths
Why TSVART: Link to the emerging Intent/Color routing work

Review as draft-ietf-idr-sr-policy-safi: 
OPSDIR Early review (of -01) by Nagendra Nainar  Has issues
RTGDIR Early review (of -00) by Zhaohui Zhang  Has issues
TSVART Early review (of -00) by David Black On the Right Track
INTDIR Early Review due 2024-02-29 Requested

Waiting for checks on RTG-DIR, OPS-DIR.
Requesting SEC-DIR.

Review a draft-ietf-idr-segment-routing-te-policy
RTGDIR Early review (of draft-ietf-idr-segment-routing-te-policy -18) by Mohamed Boucadair  Has issues
SECDIR Early review (of draft-ietf-idr-segment-routing-te-policy -18) by Vincent Roca Ready
INTDIR Early review (of draft-ietf-idr-segment-routing-te-policy -18) by Brian Haberman Ready w/issues

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.

No formal review criteria - MIB, Yang, Media type, URI
Another Yang module needs to add this to the BGP Base. 
Will add to IDR Wiki.

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

No Yang module.
Another Yang module needs to add this to the BGP Base. 
Will add to IDR Wiki.

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.

No formal review

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

[TBD - ]

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 - need Routing list]

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 - 6 implementations + SR work.
Issues - BGP does not do full validation

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.

Call for IPR
https://mailarchive.ietf.org/arch/msg/idr/b8VABzT4fTyvY0j6_FuA04RYiHY/

1. Stefano Previdi
https://mailarchive.ietf.org/arch/msg/idr/URkVWm6k-mfSNqs9qYcfeISUR9c/

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

3.  Ketan Talaulikar, Ed.
https://mailarchive.ietf.org/arch/msg/idr/T2VaUQTIP0KqO5X3WGM6ThnlUQ8/

4. Paul Mattes
https://mailarchive.ietf.org/arch/msg/idr/TVTu_1hwgZozFLmHhfQnft5O7Kw/

5. Dhanendra Jain
https://mailarchive.ietf.org/arch/msg/idr/16MkEx6jVqfwUEGDtvtaKCPNBJg/

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.

Total number of authors: 5, 
No contributors.

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.)
[run extensive I-D nits]

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?
[TBD]

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.
[TBD]

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?

[TBD]

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.

Yes - [RFC9012]

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.

[TBD]

[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://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/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.* [RFC4758]

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

History -
6 steps: 1) 1st WG LC, 2) Wait for RFC7752, 3) AD review requires split (implemented/non-implemented), 
4) review split (2nd WG LC), 5) Shepherd notes RFC9012 issues, 6) 3rd WG LC

Please note that the shepherd noted after the 2nd WG LC the issues with RFC9012. The final call was explicit that the RFC9012 format was used, but not the subTLVs and validation.

Dates: 1st: 8/06/2021, Split-IETF 3/15/2023, Split ok: 10/10-10/23/2023 (ok 10/23), 
3rd WG LC: 2/15-3/18/2024
https://mailarchive.ietf.org/arch/msg/idr/b8VABzT4fTyvY0j6_FuA04RYiHY/
Result of WG LC (3/19/2024)
https://mailarchive.ietf.org/arch/msg/idr/rLJzLz_U8ZUuBaTBg7LIOh6CZ0o/

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

At the 3rd WG LC, consensus was solid, but no comments were made on the
use of RFC9012.

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 discontent to 3rd WG LC.

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)?
6 implementations (details on 5 implementations)
https://wiki.ietf.org/en/group/idr/BGP-Implementation-report/draft-ietf-idr-segment-routing-te-policy-implement

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

Requested Early Review of RTGDIR, OPSDIR, TSVART, SECDIR
Why OPSDIR + SECDIR:  operational + security issues with the SR Candidate paths
Why TSVART: Link to the emerging Intent/Color routing work
RTG

Review as draft-ietf-idr-sr-policy-safi: 
OPSDIR Early review (of -01) by Nagendra Nainar  Has issues
RTGDIR Early review (of -00) by Zhaohui Zhang  Has issues
TSVART Early review (of -00) by David Black On the Right Track
INTDIR Early Review due 2024-02-29 Requested

Waiting for checks on RTG-DIR, OPS-DIR.
Requesting SEC-DIR.

Review a draft-ietf-idr-segment-routing-te-policy
RTGDIR Early review (of draft-ietf-idr-segment-routing-te-policy -18) by Mohamed Boucadair  Has issues
SECDIR Early review (of draft-ietf-idr-segment-routing-te-policy -18) by Vincent Roca Ready
INTDIR Early review (of draft-ietf-idr-segment-routing-te-policy -18) by Brian Haberman Ready w/issues



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.

No formal review criteria - MIB, Yang, Media type, URI
Another Yang module needs to add this to the BGP Base. 
Will add to IDR Wiki.

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

No Yang module.
Another Yang module needs to add this to the BGP Base. 
Will add to IDR Wiki.

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.

No formal review

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

[TBD - links to Shephd rreviews]

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 - need Routing list]

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 - 6 implementations + SR work.
Issues - BGP does not do full validation

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.

Call for IPR
https://mailarchive.ietf.org/arch/msg/idr/b8VABzT4fTyvY0j6_FuA04RYiHY/

1. Stefano Previdi
https://mailarchive.ietf.org/arch/msg/idr/URkVWm6k-mfSNqs9qYcfeISUR9c/

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

3.  Ketan Talaulikar, Ed.
https://mailarchive.ietf.org/arch/msg/idr/T2VaUQTIP0KqO5X3WGM6ThnlUQ8/

4. Paul Mattes
https://mailarchive.ietf.org/arch/msg/idr/TVTu_1hwgZozFLmHhfQnft5O7Kw/

5. Dhanendra Jain
https://mailarchive.ietf.org/arch/msg/idr/16MkEx6jVqfwUEGDtvtaKCPNBJg/

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.

Total number of authors: 5, 
No contributors.

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.)
[run extensive I-D nits]

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?
[TBD]

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.
[TBD]

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?

[TBD]

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.

Yes - [RFC9012]

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.

[TBD]

[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://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/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.* [RFC4758]

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

History -
6 steps: 1) 1st WG LC, 2) Wait for RFC7752, 3) AD review requires split (implemented/non-implemented), 
4) review split (2nd WG LC), 5) Shepherd notes RFC9012 issues, 6) 3rd WG LC

Please note that the shepherd noted after the 2nd WG LC the issues with RFC9012. The final call was explicit that the RFC9012 format was used, but not the subTLVs and validation.

Dates: 1st: 8/06/2021, Split-IETF 3/15/2023, Split ok: 10/10-10/23/2023 (ok 10/23), 
3rd WG LC: 2/15-3/18/2024
https://mailarchive.ietf.org/arch/msg/idr/b8VABzT4fTyvY0j6_FuA04RYiHY/
Result of WG LC (3/19/2024)
https://mailarchive.ietf.org/arch/msg/idr/rLJzLz_U8ZUuBaTBg7LIOh6CZ0o/

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

At the 3rd WG LC, consensus was solid, but no comments were made on the
use of RFC9012.

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 discontent to 3rd WG LC.

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)?
6 implementations (details on 5 implementations)
https://wiki.ietf.org/en/group/idr/BGP-Implementation-report/draft-ietf-idr-segment-routing-te-policy-implement

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

Requested Early Review of RTGDIR, OPSDIR, TSVART, SECDIR
Why OPSDIR + SECDIR:  operational + security issues with the SR Candidate paths
Why TSVART: Link to the emerging Intent/Color routing work
RTG

Review as draft-ietf-idr-sr-policy-safi: 
OPSDIR Early review (of -01) by Nagendra Nainar  Has issues
RTGDIR Early review (of -00) by Zhaohui Zhang  Has issues
TSVART Early review (of -00) by David Black On the Right Track
INTDIR Early Review due 2024-02-29 Requested

Waiting for checks on RTG-DIR, OPS-DIR.
Requesting SEC-DIR.

Review a draft-ietf-idr-segment-routing-te-policy
RTGDIR Early review (of draft-ietf-idr-segment-routing-te-policy -18) by Mohamed Boucadair  Has issues
SECDIR Early review (of draft-ietf-idr-segment-routing-te-policy -18) by Vincent Roca Ready
INTDIR Early review (of draft-ietf-idr-segment-routing-te-policy -18) by Brian Haberman Ready w/issues



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.

No formal review criteria - MIB, Yang, Media type, URI
Another Yang module needs to add this to the BGP Base. 
Will add to IDR Wiki.

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

No Yang module.
Another Yang module needs to add this to the BGP Base. 
Will add to IDR Wiki.

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.

No formal review

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

[TBD - links to Shephd rreviews]

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 - need Routing list]

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 - 6 implementations + SR work.
Issues - BGP does not do full validation

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.

Call for IPR
https://mailarchive.ietf.org/arch/msg/idr/b8VABzT4fTyvY0j6_FuA04RYiHY/

1. Stefano Previdi
https://mailarchive.ietf.org/arch/msg/idr/URkVWm6k-mfSNqs9qYcfeISUR9c/

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

3.  Ketan Talaulikar, Ed.
https://mailarchive.ietf.org/arch/msg/idr/T2VaUQTIP0KqO5X3WGM6ThnlUQ8/

4. Paul Mattes
https://mailarchive.ietf.org/arch/msg/idr/TVTu_1hwgZozFLmHhfQnft5O7Kw/

5. Dhanendra Jain
https://mailarchive.ietf.org/arch/msg/idr/16MkEx6jVqfwUEGDtvtaKCPNBJg/

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.

Total number of authors: 5, 
No contributors.

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.)
[run extensive I-D nits]

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?
[TBD]

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.
[TBD]

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?

[TBD]

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.

Yes - [RFC9012]

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.

[TBD]

[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://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/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.* [RFC4758]

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

History -
6 steps: 1) 1st WG LC, 2) Wait for RFC7752, 3) AD review requires split (implemented/non-implemented), 
4) review split (2nd WG LC), 5) Shepherd notes RFC9012 issues, 6) 3rd WG LC

Please note that the shepherd noted after the 2nd WG LC the issues with RFC9012. The final call was explicit that the RFC9012 format was used, but not the subTLVs and validation.

Dates: 1st: 8/06/2021, Split-IETF 3/15/2023, Split ok: 10/10-10/23/2023 (ok 10/23), 
3rd WG LC: 2/15-3/18/2024
https://mailarchive.ietf.org/arch/msg/idr/b8VABzT4fTyvY0j6_FuA04RYiHY/
Result of WG LC (3/19/2024)
https://mailarchive.ietf.org/arch/msg/idr/rLJzLz_U8ZUuBaTBg7LIOh6CZ0o/

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

At the 3rd WG LC, consensus was solid, but no comments were made on the
use of RFC9012.

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 discontent to 3rd WG LC.

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)?
6 implementations
https://wiki.ietf.org/group/idr/BGP-Implementation-report/draft-ietf-idr-segment-routing-te-policy-implement

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

Requested Early Review of RTGDIR, OPSDIR, TSVART, SECDIR
Why OPSDIR + SECDIR:  operational + security issues with the SR Candidate paths
Why TSVART: Link to the emerging Intent/Color routing work
RTG

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.

No formal review criteria - MIB, Yang, Media type, URI
Another Yang module needs to add this to the BGP Base. 
Will add to IDR Wiki.

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

No Yang module.
Another Yang module needs to add this to the BGP Base. 
Will add to IDR Wiki.

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.

No formal review

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

[TBD - links to Shephd rreviews]

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 - need Routing list]

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 - 6 implementations + SR work.
Issues - BGP does not do full validation

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.

Call for IPR
https://mailarchive.ietf.org/arch/msg/idr/b8VABzT4fTyvY0j6_FuA04RYiHY/

1. Stefano Previdi
https://mailarchive.ietf.org/arch/msg/idr/URkVWm6k-mfSNqs9qYcfeISUR9c/

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

3.  Ketan Talaulikar, Ed.
https://mailarchive.ietf.org/arch/msg/idr/T2VaUQTIP0KqO5X3WGM6ThnlUQ8/

4. Paul Mattes
https://mailarchive.ietf.org/arch/msg/idr/TVTu_1hwgZozFLmHhfQnft5O7Kw/

5. Dhanendra Jain
https://mailarchive.ietf.org/arch/msg/idr/16MkEx6jVqfwUEGDtvtaKCPNBJg/

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.

Total number of authors: 5, 
No contributors.

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.)
[run extensive I-D nits]

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?
[TBD]

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.
[TBD]

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?

[TBD]

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.

Yes - [RFC9012]

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.

[TBD]

[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://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/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.* [RFC4758]

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

History -
6 steps: 1) 1st WG LC, 2) Wait for RFC7752, 3) AD review requires split (implemented/non-implemented), 
4) review split (2nd WG LC), 5) Shepherd notes RFC9012 issues, 6) 3rd WG LC
Dates: 1st: 8/06/2021, Split-IETF 3/15/2023, Split ok: 10/10-10/23/2023 (ok 10/23), 
3rd WG LC: 2/15-3/18/2024
https://mailarchive.ietf.org/arch/msg/idr/b8VABzT4fTyvY0j6_FuA04RYiHY/
Result of WG LC (3/19/2024)
https://mailarchive.ietf.org/arch/msg/idr/rLJzLz_U8ZUuBaTBg7LIOh6CZ0o/

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

At the 3rd WG LC, consensus was solid.

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 discontent to 3rd WG LC.

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)?
6 implementations
https://wiki.ietf.org/group/idr/BGP-Implementation-report/draft-ietf-idr-segment-routing-te-policy-implement

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

Requested Early Review of RTGDIR, OPSDIR, TSVART, SECDIR
Why OPSDIR + SECDIR:  operational + security issues with the SR Candidate paths
Why TSVART: Link to the emerging Intent/Color routing work
RTG

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.

No formal review criteria - MIB, Yang, Media type, URI
Another Yang module needs to add this to the BGP Base. 
Will add to IDR Wiki.

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

No Yang module.
Another Yang module needs to add this to the BGP Base. 
Will add to IDR Wiki.

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.

No formal review

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

[TBD - links to Shephd rreviews]

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 - need Routing list]

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 - 6 implementations + SR work.
Issues - BGP does not do full validation

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.

Call for IPR
https://mailarchive.ietf.org/arch/msg/idr/b8VABzT4fTyvY0j6_FuA04RYiHY/

1. Stefano Previdi
https://mailarchive.ietf.org/arch/msg/idr/URkVWm6k-mfSNqs9qYcfeISUR9c/

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

3.  Ketan Talaulikar, Ed.
https://mailarchive.ietf.org/arch/msg/idr/T2VaUQTIP0KqO5X3WGM6ThnlUQ8/

4. Paul Mattes
https://mailarchive.ietf.org/arch/msg/idr/TVTu_1hwgZozFLmHhfQnft5O7Kw/

5. Dhanendra Jain
https://mailarchive.ietf.org/arch/msg/idr/16MkEx6jVqfwUEGDtvtaKCPNBJg/

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.

Total number of authors: 5, 
No contributors.

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.)
[run extensive I-D nits]

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?
[TBD]

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.
[TBD]

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?

[TBD]

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.

Yes - [RFC9012]

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.

[TBD]

[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://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/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?

History - 6 steps: a) 1st WG LC, b) Wait for RFc7752, c) require split,  d) review split, e) RFc9012 issues, f) 2nd WG LC
1st: 8/06/2021, Split-IETF 3/15/2023, Split ok: 10/10-10/23/2023 (ok 10/23),  3rd WG LC: 2/15-3/18/2024

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)?
6 implementations
https://wiki.ietf.org/group/idr/BGP-Implementation-report/draft-ietf-idr-segment-routing-te-policy-implement

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

Requested Early Review of RTGDIR, OPSDIR, TSVART, SECDIR
Why OPSDIR + SECDIR:  operational + security issues with the SR Candidate paths
Why TSVART: Link to the emerging Intent/Color routing work

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.

No formal review criteria - MIB, Yang, Media type, URI
Another Yang module needs to add this to the BGP Base. 
Will add to IDR Wiki.

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

No Yang module.
Another Yang module needs to add this to the BGP Base. 
Will add to IDR Wiki.

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.

No formal review

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

[TBD - links to Shephd rreviews]

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 - need Routing list]

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 - 6 implementations + SR work.
Issues - BGP does not do full validation

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.

Call for IPR
https://mailarchive.ietf.org/arch/msg/idr/b8VABzT4fTyvY0j6_FuA04RYiHY/

Missing IPR
1. Clarence Filsfils

2. Paul Mattes

3. Dhanendra Jain

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.)
[run extensive I-D nits]

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?
[TBD]

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.
[TBD]

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?

[TBD]

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.

Yes - [RFC9012]

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.

[TBD]

[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://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/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/

Request for Early review by TSVART Completed: On the Right Track. Reviewer: David Black. Sent review to list. Submission of review completed at an earlier date.

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

History - 6 steps: a) 1st WG LC, b) Wait for RFc7752, c) require split,  d) review split, e) RFc9012 issues, f) 2nd WG LC


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)?
6 implementations
https://wiki.ietf.org/group/idr/BGP-Implementation-report/draft-ietf-idr-segment-routing-te-policy-implement

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

Requested Early Review of RTGDIR, OPSDIR, TSVART, SECDIR
Why OPSDIR + SECDIR:  operational + security issues with the SR Candidate paths
Why TSVART: Link to the emerging Intent/Color routing work

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.

No formal review criteria - MIB, Yang, Media type, URI
Another Yang module needs to add this to the BGP Base. 
Will add to IDR Wiki.

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

No Yang module.
Another Yang module needs to add this to the BGP Base. 
Will add to IDR Wiki.

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.

No formal review

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

[TBD - links to Shephd rreviews]

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 - need Routing list]

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 - 6 implementations + SR work.
Issues - BGP does not do full validation

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.

Call for IPR
https://mailarchive.ietf.org/arch/msg/idr/b8VABzT4fTyvY0j6_FuA04RYiHY/

Missing IPR
1. Clarence Filsfils

2. Paul Mattes

3. Dhanendra Jain

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.)
[run extensive I-D nits]

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?
[TBD]

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.
[TBD]

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?

[TBD]

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.

Yes - [RFC9012]

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.

[TBD]

[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://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/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/