BGP Classful Transport Planes
draft-ietf-idr-bgp-ct-39

The previous debate about SHOULD/MUST is closed; however in doing my final check before sending the document to the RFC Editor, I noticed that somehow version 38 has a regression in it.

Version 37:
Requirements Language

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
  "OPTIONAL" in this document are to be interpreted as described in BCP
  14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they
  appear in all capitals, as shown here.

Version 38:
Requirements Language

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  document are to be interpreted as described in RFC 2119 [RFC2119].

The version in 37 is correct, citing BCP 14 and not just RFC 2119. Can you revert to that language and publish an update? Thanks.

See https://mailarchive.ietf.org/arch/msg/idr/3GsnIynTucIv2ByhgAtmO8ApOMc/ although to be clear, either a revised I-D to take in the proposed change, or a reply that the authors/WG have considered it and prefer the document as written, is OK as a resolution.

[Ballot comment]
Thank you to Reese Enghardt for the GENART review.

Thank you for addressing my DISCUSS feedback.

** What’s the experiment to motivate the experimental status?  What does success look like?

** Section 4.3
  Reserved: 2-octet reserved bits field.
          This field MUST be set to zero on transmission.
          This field SHOULD be ignored on reception, and
          MUST be left unaltered.

Under what circumstances would the Reserved fields NOT be ignored on reception?

[Ballot discuss]
** Section 13.4 describes a registry and associated values, but then also says “IANA does not need to maintain this registry.”  What is the purpose of this sub-section if the entirety of Section 13 is guidance to IANA?  Have I misunderstood what that there isn’t an action for IANA?

[Ballot comment]
Thank you to Reese Enghardt for the GENART review.

** As a process check, I was surprised to see that there wasn’t an IETF LC or telechat review assigned from RTGDIR, OPSDIR, or SECDIR for this document.

** What’s the experiment to motivate the experimental status?  What does success look like?

** idnits reports:
  == The document seems to lack the recommended RFC 2119 boilerplate, even if
    it appears to use RFC 2119 keywords -- however, there's a paragraph with
    a matching beginning. Boilerplate error?

** Section 2.  Editorial.  Check this long list of acronyms for actual use in this document. 

-- I spot checked PHP and didn’t find it used

-- I spot checked iSN and it’s used exactly once; why use an acronym then?

-- Acronyms appear to be defined here but then again in the text.  Why twice?  For example, Ultimate Hop Pop (UHP) is expanded here but also in Section 8.3; BN is expanded here and then again in the definition of Tunnel Domain in this same section.

** Section 2.1.  Editorial.  Consider if you need to define “greenfield” and “brownfield” networks in this section and couldn’t do it inline.  The terms are used exactly once in a single paragraph in Section 1.  You’ve already read the term before you even get to their definition in Section 2.1 and they are never used again.

** Section 4.3
  Reserved: 2-octet reserved bits field.
          This field MUST be set to zero on transmission.
          This field SHOULD be ignored on reception, and
          MUST be left unaltered.

Under what circumstances would the Reserved fields NOT be ignored on reception?

[Ballot comment]
Thanks for working on this document. Thanks to Olivier Bonaventure the early TSVART review. Section 11.4 and 11.5 are good addition to this document.

[Ballot comment]
Many thanks to Magnus Nyström for his three secdir reviews.

Section 14, para 1:  The 'walled garden' approach is not mentioned anywhere else in the draft.  From the Yoav Nir's secdir review of the idr-bgp-car draft (where similar language was removed): 

    " a) Does the security text provide an adequate description of the formation
    of the "walled garden" via BGP TCP security, address considerations,
    preventing DOS service attacks, and strong BGP security (BGP origin and
    BGPsec).

    b) does the security text provide an adequate description of how to detect
    if traffic goes outside of the "walled garden"? "

[Ballot comment]
# Internet AD comments for draft-ietf-idr-bgp-ct-36
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

### S4

* In SR Policy terms, color is a non-zero 32-bit integer (RFC 9256 S2.1).
  Is the Transport Class ID similarly constrained to be non-zero?

  If so, that should probably be state here (in/around the last paragraph,
  perhaps).

  Aha, I see text in S4.3 and S7.9 about zero being reserved for
  "best effort".

  Seems like there could be some text somewhere (anywhere) warning the
  SR-Policy-aware reader of the subtlety here.

## Nits

### S3

* "between SN1 and PE11" ->
  "between SN11 and PE11"

### Appendix C

* "produced by networking industry" ->
  "produced by the networking industry"

### Appendix C.1

* "and SRv6 SID are planned" ->
  "and SRv6 SIDs are planned"

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-idr-bgp-ct-35. If any part of this review is inaccurate, please let us know.

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

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

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

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

the existing early registration for:

Value: 76
Description: Classful Transport SAFI

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

Second, in the BGP Transitive Extended Community Types in the Border Gateway Protocol (BGP) Extended Communities registry group located at:

https://www.iana.org/assignments/bgp-extended-communities/

the existing early registration for:

Type Value: 0x0a
Name: Transport Class

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

Third, in the BGP Non-Transitive Extended Community Types also in the Border Gateway Protocol (BGP) Extended Communities registry group located at:

https://www.iana.org/assignments/bgp-extended-communities/

the existing early registration for:

Type Value: 0x4a
Name: Non-Transitive Transport Class

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

Fourth, a new registry is to be created called the Transitive Transport Class Extended Community Sub-Types registry. The new registry will be located in the Border Gateway Protocol (BGP) Extended Communities registry group located at:

https://www.iana.org/assignments/bgp-extended-communities/

The registry procedure for the new registry will be:

Range Registration Procedure
------+-----------------------
0x00-0xBF First Come First Served
0xC0-0xFF IETF Review

The reference for the new registry will be [ RFC-to-be ]. There is a single initial registration in the new registry as follows:

Sub-Type Value: 0x02
Name: Route Target
Reference: [ RFC-to-be ]

A note will be added to the top of the registry with the following text:

This registry contains values of the second octet (the "Sub-Type" field) of an extended community when the value of the first octet (the "Type" field) is 0x0a.

Fifth, a new registry is to be created called the Non-Transitive Transport Class Extended Community Sub-Types registry. The new registry will be located in the Border Gateway Protocol (BGP) Extended Communities registry group located at:

https://www.iana.org/assignments/bgp-extended-communities/

The registry procedure for the new registry will be:

Range Registration Procedure
------+-----------------------
0x00-0xBF First Come First Served
0xC0-0xFF IETF Review

The reference for the new registry will be [ RFC-to-be ]. There is a single initial registration in the new registry as follows:

Sub-Type Value: 0x02
Name: Route Target
Reference: [ RFC-to-be ]

A note will be added to the top of the registry with the following text:

This registry contains values of the second octet (the "Sub-Type" field) of an extended community when the value of the first octet (the "Type" field) is 0x4a.

Sixth, in the Sub-TLVs for TLV Types 1, 16, and 21 sub-registry of the TLVs registry on the Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters registry page located at:

https://www.iana.org/assignments/mpls-lsp-ping-parameters/

the existing early registrations for:

Sub-Type: 31744
Sub-TLV Name: IPv4 BGP Classful Transport

Sub-Type: 31745
Sub-TLV Name: IPv6 BGP Classful Transport

will be made permanent and their references changed to [ RFC-to-be ].

Seventh, Section 13.4 refers to a registry for Transport Class IDs.

IANA Question --> Section 13.4 says, "IANA does not need to maintain this registry." However, it is not clear if the registry (and it's parent registry group) should be created on the IANA Matrix at:

https://www.iana.org/assignments/

Should this new registry be created with a note that all future Transport Class IDs will be allocated by Private Use as defined in [RFC8126)?

We understand that these seven 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 2025-02-07):

From: The IESG
To: IETF-Announce
CC: balajir@juniper.net, cy098d@att.com, dgowda@extremenetworks.com, draft-ietf-idr-bgp-ct@ietf.org, dreshma@juniper.net, gyan.s.mishra@verizon.com, idr-chairs@ietf.org, idr@ietf.org, ietf@nop.hu, israel.means@att.com, jgs@juniper.net, mazen.khaddam@cox.com, mrajesh@juniper.net, shares@ndzh.com, szarecki@google.com, xiaohu.xu@capitalonline.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (BGP Classful Transport Planes) to Experimental RFC


The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document: - 'BGP Classful Transport Planes'
  as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-02-07. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document specifies a mechanism referred to as "Intent Driven
  Service Mapping".  The mechanism uses BGP to express intent based
  association of overlay routes with underlay routes having specific
  Traffic Engineering (TE) characteristics satisfying a certain Service
  Level Agreement (SLA).  This is achieved by defining new constructs
  to group underlay routes with sufficiently similar TE characteristics
  into identifiable classes (called "Transport Classes"), that overlay
  routes use as an ordered set to resolve reachability (Resolution
  Schemes) towards service endpoints.  These constructs can be used,
  for example, to realize the "IETF Network Slice" defined in TEAS
  Network Slices framework.

  Additionally, this document specifies protocol procedures for BGP
  that enable dissemination of service mapping information in a network
  that may span multiple cooperating administrative domains.  These
  domains may be administered either by the same provider or by closely
  coordinating providers.  A new BGP address family that leverages RFC
  4364 ("BGP/MPLS IP Virtual Private Networks (VPNs)" procedures and
  follows RFC 8277 ("Using BGP to Bind MPLS Labels to Address
  Prefixes") NLRI encoding is defined to enable each advertised
  underlay route to be identified by its class.  This new address
  family is called "BGP Classful Transport", a.k.a., BGP CT.





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


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

  https://datatracker.ietf.org/ipr/6057/
  https://datatracker.ietf.org/ipr/6058/
  https://datatracker.ietf.org/ipr/4845/
  https://datatracker.ietf.org/ipr/4340/
  https://datatracker.ietf.org/ipr/4759/
  https://datatracker.ietf.org/ipr/5562/
  https://datatracker.ietf.org/ipr/5563/

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

Shepherd's note to AD note:  Please review the security section first and
consider the issues for both CAR and CT.

## Document History

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

The CT progression after adoption is tracked on both the IDR Wiki
and the IDR github repository: ietf-wg-idr/draft-ietf-idr-bgp-ct
https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues

Post 2nd WG LC Shepherd's review of -26.txt
https://mailarchive.ietf.org/arch/msg/idr/7PIQx2nE0Y4d-lR7bIpTPL_TMR0/

Summary of calls: (in reverse time order)
2nd WG LC: 2/16/2024 to 3/1/2024
https://mailarchive.ietf.org/arch/msg/idr/Ud2coGDvdXYy7x-SHPSK2Onwjx4/
Status: Consensus on publication of draft-ietf-idr-bgp-ct and draft-ietf-idr-bgp-ct-srv6
https://mailarchive.ietf.org/arch/msg/idr/oNY5gAcE21y1bke6tBzeb76uVo4/
https://mailarchive.ietf.org/arch/msg/idr/rJC4O726QqUoDEqFTffOF9EvX_U/

----
1st WG LC: draft-ietf-idr-bgp-ct-09.txt (6/26/2023 to 7/17/2023
https://mailarchive.ietf.org/arch/msg/idr/KYZbOsg2y4jcOfjV31pee5uhMjQ/
extension to 7/28: https://mailarchive.ietf.org/arch/msg/idr/Qr8GhdlEi8viaZxOCaWii3cA51s/
Extension to 8/01: https://mailarchive.ietf.org/arch/msg/idr/fC--NIU7VlyOjmNJwIcsXhXFvSk/
status: No consensus reached

The shepherd's write-up on this topic is available on the IDR wiki
https://wiki.ietf.org/e/en/group/idr/CT-WGLC

Email message notifying the WG of 1 WG LC Shepherd's report:
https://mailarchive.ietf.org/arch/msg/idr/klBUhMe9AsdflYhIYVEhSIps_lg/
---------
Adoption call results: (as part of status)
https://mailarchive.ietf.org/arch/msg/idr/0V6pBTQyCmh3t3h9cMqxZ3N0s7Q/

Adoption call: Time: 7/6/2022 to 7/27/2022 in 3 mail threads.
Part 1 of CAR/CT Adoption call (7/6 to 7/27): Informational Questions
​https://mailarchive.ietf.org/arch/msg/idr/FhoK04HsSy9tR7ioV7AD0Vv6Ir4/

Part 2 of CAR/CT Adoption call (7/6 to 7/27): Adoption call
​https://mailarchive.ietf.org/arch/msg/idr/AP_ClbZgpkX6CNy7TaZiU8SMD5w/

Part 3 of CAR/CT Adoption call (7/14 to 7/27) - Please note that Part 3 has a specific format for posting.
​https://mailarchive.ietf.org/arch/msg/idr/fTFYwF54WRHcj7PDt2t7sOQg6vo/

This adoption call was preceded by the following:
Email Discussion before IETF-113
​https://mailarchive.ietf.org/arch/msg/idr/e69NRd9i2aG0WUxFkShEfQHZsHo/

Note: The IDR chairs agree with Jeff Haas's (IDR Co-chair) summary posted on March 21, 2022,
that for route resolution and route origination/propagation,
BGP-CAR and BGP-CT are functionally identical but operationally different.

Presentations from IETF-108 to IETF-113
IDR interim on January 24, 2022
(​https://datatracker.ietf.org/meeting/interim-2022-idr-02/session/idr)


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


Rough Adoption decision:
The IDR chairs agree with Jeff Haas's (IDR Co-chair) summary posted on March 21, 2022,
that for route resolution and route origination/propagation,
BGP-CAR and BGP-CT are functionally identical but operationally different.

IDR WG could not come to a consensus on CAR vs. CT.  IDR Chairs elected to adopt
both CAR and CT drafts as experimental drafts.  Experience in the market
place will help determine which is better operationally.

Rough 1st WG LC of CAR/CT: The IDR WG LC for CAR and CT found the editors/authors/contributors
of CAR commenting on the CT draft (Just as CT authors commented on CAR draft).
In some ways, this lively debate helped find problems in the specifications.

2nd WG LC of CAR/CT: This WG LC did not have a lot of
CAR/CT editor discussions because the IDR Shepherding Chair had
a private discussion between editors prior to the 2nd WG LC.

During 2nd WG LC: Concern on Split of CT drafts into 3 drafts:
https://mailarchive.ietf.org/arch/msg/idr/29CYvVl0RnW0hJSU3il3p_cqt80/

Robert Raszuk raised a Concern regarding the splitting of the
CT draft into three parts (draft-ietf-idr-bgp-ct, draft-ietf-idr-bgp-ct-srv6,
and draft-ietf-idr-bgp-fwd-rr). Robert objected to the draft-ietf-idr-bgp-fwd-rr
being a WG draft.  The IDR chairs felt the text was in draft-ietf-idr-bgp-ct
since version -09, so Robert's concerns about being surprised as
WG draft was not justified.  However, it does point to the value of
the IDR chairs splitting this work out of the draft-ietf-idr-bgp-ct draft.

------
Dependencies on Spring:
a) Functional dependency - caused only theoretical scaling results
Due to a lack of adoption of the Spring Requirements document
draft-hr-spring-intentaware-routing-using-color-03, this WG
Shepherd allowed the scaling results to be theoretical without proof in CT.

b) Normative dependency on draft-ietf-idr-salih-spring-srv6-inter-domain-sids-04.
There is a normative dependency on an individual draft that is waiting for adoption. 
The Spring chairs have been notified that IDR draft-ietf-idr-bgp-ct-srv6
has normative dependencies on draft-ietf-idr-salih-spring-srv6-inter-domain-sids.

Dependencies with PCE
Dhruv Dhody reviewed the interactions with PCE drafts.
He sent comments to the CT authors. CT authors updated their drafts with changes. 

Dependencies with BESS:
BESS chairs were queried about reviewing the CAR and CT drafts.
No direct information was received.

-----
Alternatives for SRv6 without CAR or CT.
A third draft (draft-ietf-idr-cpr-00) was adopted as an informational draft.
This informational draft provides a way to encode intent for
SRv6 by operational practices rather than a new protocol.

## Directorate Reviews: (tracked by Datatracker) with comments from shepherd
RTG-DIR reviews:
Early Review of draft-ietf-idr-bgp-ct-09 (Med Boucadair)- status: has issues, excellent review
https://mailarchive.ietf.org/arch/msg/rtg-dir/aawFfvd29zERSBK4ydDDhxEQGRw
Early Review of draft-ietf-idr-bgp-ct-18 (Jonathan Hardwick) - status: has nits, good review
https://mailarchive.ietf.org/arch/msg/rtg-dir/FLGmC0-ufqPsZpH_LmgL2eWmWhY
Shepherd's follow-up: All NITs resolved by -30

OPS-DIR reviews:
Early Review of draft-ietf-idr-bgp-ct-12 (Bo Wu) - status: Has issues, Quality: good review, 4 issues mentioned
https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ct-12-opsdir-early-wu-2023-08-03/
Early Review of draft-ietf-idr-bgp-ct-18 (Bo Wu) - status: has nits, Quality: good review, 2nd review by the same reviewer as -12
https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ct-19-opsdir-early-wu-2024-01-05/
Shepherd's review: All Nits resolved by -30.

SEC-DIR Review:
Authors resolved in -30, except for NIT
email link: https://mailarchive.ietf.org/arch/msg/idr/fYulGchhf6oWPWhVWHxqx6WNupI/
github: assigned github issue #69
github link:https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/69
Status: Shepherd awaiting clarification email (sent 4/9))
Resolved by -32, but AD should look at the github issue #69 (closed issue)
https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/69


TSV-Review: (due date 3/6/2024) - On the Right Track.
https://mailarchive.ietf.org/arch/msg/tsv-art/hml_nr-BAbzXk7RnKCCy-EVXLuw/
TSV-DIR:
From the viewpoint of the transport area, there are two important points that
need to be discussed when considering such tunnels:
1)  MTU problems if the tunnel configurations differ, and
2) DSCP issues if DSPC is used to provide non-best effort services.
Status: -30 contained fixes for TSV-DIR, but no 2nd review.


Shepherd's comment for TSV-DIR: Please look at this draft from the viewpoint of having intent (color) aware customer traffic forwarded over a VPN overlay (tunnels) that forwarded over a set of intent (color) aware underlay of tunnels.  Please consider the problems with tunnels in your review of this text.

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

Andrew mentioned he received feedback that there would be discomfort
if the CAR and CT do not progress to the Experimental simultaneously.
See Andrew Alston for additional details.

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

    Implementation report:
    https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-bgp-ct
 
    Implementation of CT:  Juniper, Freertg
    Implementation of CT-srv6: (TBD)

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.

  Reviews requested from PCE, Spring, and BESS before 2nd WG LC.
  Received reviews from PCE: CT updated based on feedback (missing link in IDR Mail)
  Received feedback from Spring chairs (Alvaro Retana)
    The following drafts were in the option queue:
      draft-hr-spring-intentaware-routing-using-color
      draft-salih-spring-srv6-inter-domain-sids-04 (ct-srv6)
 
  Nothing was received from BESS.
  RTG-DIR reviews: 2 early reviews - (-18) "has nits" 
  OPS-DIR reviews: 2 early reviews - (-19) "has nits"
  SEC-DIR reviews: 2 early reviews - (-19) 6 problems + 4 questions (must be resolved)
  TSV-DIR review:  1 early review requested - no response.
  IANA Early review: IANA early review of draft-ietf-idr-bgp-ct-27 IANA section.
 
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 requirement for formal review (MIB, Yang, Media type, and URI)
  A yang module for CT will be added to the list of Yang modules to create for BGP.

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 in the document

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 automated checking

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

Checks completed:
  1) Pre-Adoption by Jeff Haas and discussion among chairs 
  2) Careful Adoption review resulted in a list of issues that needed to be resolved:
      (https://wiki.ietf.org/group/idr/CAR-CTAdoption)
  3) Adoption call issues added to github for draft-ietf-idr-bgp-ct-27 
      (https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues)
  4) 1st WG LC -
      Prior to 1st WG LC: Shepherd verified that issues were addressed
                          and early Early Directorate reviews requested,
      1st WG LC: Shepherd report written
      (see https://wiki.ietf.org/group/idr/CT-WGLC and                     
      https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues)       
      Review provided by IDR Chair team: Jie Dong, Keyur Patel, and Jeff Haas.
 
  5) 2nd WG LC
      Prior to 2nd WG LC:
        a) Shepherd verified that issues raised in 1st WG LC were addressed.
        b) Review provided by IDR Chair team: Jie Dong, Keyur Patel, and Jeff Haas.
        c) IDR Chair team resolutions were made - via email and meetings of
          technical issues.
        d) Early reviews requested (RTG-DIR, OPS-DIR, SEC-DIR, and TSV-DIR)
          open reviews: resolution of SEC-DIR and lack of TSV-DIR
        d) Meeting with CAR and CT editor teams during 2nd WGLC
        e) two interims in 2024 - January 29 and February 26 - review status
    6) Post WG LC
        a) Shepherd reports with editorial nits [resolved]
        b) Shepherd report loaded into github as issues [Resolved]
        c) Review issues with document editors before -27 submission [Resolved] 
        b) IANA review of -27 requested. [pending]
        c) github issue loaded with Security Directorate review comments

    7)Final Checks
        a) Response from IANA review of -27
        b) Response from SEC-DIR resolution check
        c) final NITS check
        d) RFC9012 issues

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?  All items addressed, but these are the key points

  RTG-DIR and OPS-IDR review examines whether these new "intent-aware" (color)
  are able to be created and used. The early review cycles ended with "OK with NITs".
  The NITs have been address (see github for tracking of NITs). 

  The Transport area review (TSV-DIR) was only looking at whether the network
  was on the right path to allow intents to create "intent" (color) network-wide
  paths of a certain type.  Applications through transport layers are the ones to signal
  a particular intent and need.  The desired answer from TSV-DIR is "on the right track".
   
  SEC-DIR review of CT and CTv6 mentioned that these drafts look to
  BGP security solutions (BGPsec and Origin validation) to provide additional security
  without giving the details on the solutions. During an investigation of the BGPsec
  a few things turned up about BGPSec. The shepherd notes that RFC8374 points out that BGPsec
  (RFC8205) only included the AFI in the "hash" to resolve a problem (see
  sections 2.2.1 and 6.2.1).  Section 2.2.1 includes the AFI/SAFI in Figure 8,
  but may assume only IPv4 (AFI=1) and IPv6 (AFI=2).

  Due to this unclear text, both BGP intent-based solutions (CAR and CT)
  merely state that BGPsec and Origin Validation could be extended.  It is beyond the
  scope of these individual drafts to raise the wider issue of BGPsec applications
  for many new AFI/SAFIs. It is an an issues that needs addressing by the IDR WG.

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?

    Experimental draft.  Why? IDR cannot settle on a single solution for Intent-based (Color) routing. 
    The top 2 solutions are forwarded as experimental drafts to allow operational deployment to give feedback.

    Do all Datatracker state attributes correctly reflect this intent? Yes .
   
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.

Editors:
2nd WG LC -03
Kaliraj Vairavakkali (kaliraj@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/ZL7tOk3fgqeIRM5dfKfx_GbIh2w/

Natrajan Venkataraman (natv@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/eh3IdjyMjJVQSwOx2CD95iKg1-4/

CoAuthors:
Reshma Das (dreshma@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/Ei8WY3sVYAhnECr1w40Y8C5zQ-Y/

Israel Means (israel.means@att.com)
https://mailarchive.ietf.org/arch/msg/idr/iniOhZ1BknkBhe2l8DYL5aL_lGk/

Csaba Mates (ietf@nop.hu)
https://mailarchive.ietf.org/arch/msg/idr/NSxyfq98238jOIllMgIrBF54aeg/

Deepak J. Gowda (dgowda@extremenetworks.com) [2nd WG LC]
https://mailarchive.ietf.org/arch/msg/idr/FWf7jsy7mFJDiW3stAWeJ_DU0oU/

Contributors:
Balaji Rajagoplan (balajir@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/SfJQVDClw7y8vXYoG8wlLKRgyLQ/


Rajesh M (mrajesh@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/4T2BDGnaZUmtWUPjFVIOAFL-ZoI/

Chaitanya Yadlapalli (cy098d@att.com)
https://mailarchive.ietf.org/arch/msg/idr/M1c3trnvMiVn3_QQU9FqbkuvHA0/

Mazen Khaddam (mazen.khaddam@cox.com)
https://mailarchive.ietf.org/arch/msg/idr/lhBotT08JzICX-uPUfhMUSA7uzc/

Rafal Jan Szarecki (Google)
https://mailarchive.ietf.org/arch/msg/idr/r09fylzRRgssJqDoQnhy66qCr-g/

Xiaohu Xu (Captialonline) [from 1st WG LC]
https://mailarchive.ietf.org/arch/msg/idr/DBuobWpmj_ce0IOUWDTZU7m095E/
2nd WG LC
https://mailarchive.ietf.org/arch/msg/idr/Uh39xPb20FTsmORAjgRlce8bwfc/

Contributor for [-12] missing in [-27]
Gyan Mishra (gyan.s.mishra@verizon.com) - dropped as of [-11]
before 1st WG LC. Missing IPR statement.

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.

2 editors on front page.
All IPR statements good for -27 except for Xiahou Xu.
issue with Gyan Mishra - no longer contributor after -11

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

[pending] NITS - see github reference
https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/72


15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
 
    Each of IDR chairs have walked through Normative and Informative references.
    [Pending - Asking for RTG-AD (John Scudder) to do early review on
    normative/non-normative references. ] 

    Note: draft-ietf-idr-bgp-ct-27 references an informative reference: 
    BGP-CT-UPDATE-PACKING-TEST] which is a document on the IETF IDR WG Github.
    Read access is allowed for all. 
    see: https://raw.githubusercontent.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/1a75d4d10d4df0f1fd7dcc041c2c868704b092c7/update-packing-test-results.txt

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 normative references are freely available and published RFCs.
    See comment above regarding 1 informative reference at IETF IDR WG github.;

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

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

    There are no normative references that are not at RFC level.
    Informative references are RFCs, drafts, or one github reference (see #15 above). 

19. Will publication of this document change the status of any existing RFCs? No
    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? not applicable. 
    If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.- not applicable.

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. yes, confirmed 

    Confirm that any referenced IANA registries have been clearly identified. Yes, confirmed. 
    Confirm that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]). yes, Confirmed.

    [pending] Due to a complexity, an early request to review IANA allocation has
    been sent. 

    New registries:
      Transitive Transport Class Extended Community Sub-Types Registry
      Non-Transitive Transport Class Extended Community Sub-Types Registry
      BGP CT Parameters

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.

  No IANA registries that require Designated Expert Review are listed in this draft.

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

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

Shepherd's note to AD note:  Please review the security section first and
consider the issues for both CAR and CT.

## Document History

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

The CT progression after adoption is tracked on both the IDR Wiki
and the IDR github repository: ietf-wg-idr/draft-ietf-idr-bgp-ct
https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues

Post 2nd WG LC Shepherd's review of -26.txt
https://mailarchive.ietf.org/arch/msg/idr/7PIQx2nE0Y4d-lR7bIpTPL_TMR0/

Summary of calls: (in reverse time order)
2nd WG LC: 2/16/2024 to 3/1/2024
https://mailarchive.ietf.org/arch/msg/idr/Ud2coGDvdXYy7x-SHPSK2Onwjx4/
Status: Consensus on publication of draft-ietf-idr-bgp-ct and draft-ietf-idr-bgp-ct-srv6
https://mailarchive.ietf.org/arch/msg/idr/oNY5gAcE21y1bke6tBzeb76uVo4/
https://mailarchive.ietf.org/arch/msg/idr/rJC4O726QqUoDEqFTffOF9EvX_U/

----
1st WG LC: draft-ietf-idr-bgp-ct-09.txt (6/26/2023 to 7/17/2023
https://mailarchive.ietf.org/arch/msg/idr/KYZbOsg2y4jcOfjV31pee5uhMjQ/
extension to 7/28: https://mailarchive.ietf.org/arch/msg/idr/Qr8GhdlEi8viaZxOCaWii3cA51s/
Extension to 8/01: https://mailarchive.ietf.org/arch/msg/idr/fC--NIU7VlyOjmNJwIcsXhXFvSk/
status: No consensus reached

The shepherd's write-up on this topic is available on the IDR wiki
https://wiki.ietf.org/e/en/group/idr/CT-WGLC

Email message notifying the WG of 1 WG LC Shepherd's report:
https://mailarchive.ietf.org/arch/msg/idr/klBUhMe9AsdflYhIYVEhSIps_lg/
---------
Adoption call results: (as part of status)
https://mailarchive.ietf.org/arch/msg/idr/0V6pBTQyCmh3t3h9cMqxZ3N0s7Q/

Adoption call: Time: 7/6/2022 to 7/27/2022 in 3 mail threads.
Part 1 of CAR/CT Adoption call (7/6 to 7/27): Informational Questions
​https://mailarchive.ietf.org/arch/msg/idr/FhoK04HsSy9tR7ioV7AD0Vv6Ir4/

Part 2 of CAR/CT Adoption call (7/6 to 7/27): Adoption call
​https://mailarchive.ietf.org/arch/msg/idr/AP_ClbZgpkX6CNy7TaZiU8SMD5w/

Part 3 of CAR/CT Adoption call (7/14 to 7/27) - Please note that Part 3 has a specific format for posting.
​https://mailarchive.ietf.org/arch/msg/idr/fTFYwF54WRHcj7PDt2t7sOQg6vo/

This adoption call was preceded by the following:
Email Discussion before IETF-113
​https://mailarchive.ietf.org/arch/msg/idr/e69NRd9i2aG0WUxFkShEfQHZsHo/

Note: The IDR chairs agree with Jeff Haas's (IDR Co-chair) summary posted on March 21, 2022,
that for route resolution and route origination/propagation,
BGP-CAR and BGP-CT are functionally identical but operationally different.

Presentations from IETF-108 to IETF-113
IDR interim on January 24, 2022
(​https://datatracker.ietf.org/meeting/interim-2022-idr-02/session/idr)


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


Rough Adoption decision:
The IDR chairs agree with Jeff Haas's (IDR Co-chair) summary posted on March 21, 2022,
that for route resolution and route origination/propagation,
BGP-CAR and BGP-CT are functionally identical but operationally different.

IDR WG could not come to a consensus on CAR vs. CT.  IDR Chairs elected to adopt
both CAR and CT drafts as experimental drafts.  Experience in the market
place will help determine which is better operationally.

Rough 1st WG LC of CAR/CT: The IDR WG LC for CAR and CT found the editors/authors/contributors
of CAR commenting on the CT draft (Just as CT authors commented on CAR draft).
In some ways, this lively debate helped find problems in the specifications.

2nd WG LC of CAR/CT: This WG LC did not have a lot of
CAR/CT editor discussions because the IDR Shepherding Chair had
a private discussion between editors prior to the 2nd WG LC.

During 2nd WG LC: Concern on Split of CT drafts into 3 drafts:
https://mailarchive.ietf.org/arch/msg/idr/29CYvVl0RnW0hJSU3il3p_cqt80/

Robert Raszuk raised a Concern regarding the splitting of the
CT draft into three parts (draft-ietf-idr-bgp-ct, draft-ietf-idr-bgp-ct-srv6,
and draft-ietf-idr-bgp-fwd-rr). Robert objected to the draft-ietf-idr-bgp-fwd-rr
being a WG draft.  The IDR chairs felt the text was in draft-ietf-idr-bgp-ct
since version -09, so Robert's concerns about being surprised as
WG draft was not justified.  However, it does point to the value of
the IDR chairs splitting this work out of the draft-ietf-idr-bgp-ct draft.

------
Dependencies on Spring:
a) Functional dependency - caused only theoretical scaling results
Due to a lack of adoption of the Spring Requirements document
draft-hr-spring-intentaware-routing-using-color-03, this WG
Shepherd allowed the scaling results to be theoretical without proof in CT.

b) Normative dependency on draft-ietf-idr-salih-spring-srv6-inter-domain-sids-04.
There is a normative dependency on an individual draft that is waiting for adoption. 
The Spring chairs have been notified that IDR draft-ietf-idr-bgp-ct-srv6
has normative dependencies on draft-ietf-idr-salih-spring-srv6-inter-domain-sids.

Dependencies with PCE
Dhruv Dhody reviewed the interactions with PCE drafts.
He sent comments to the CT authors. CT authors updated their drafts with changes. 

Dependencies with BESS:
BESS chairs were queried about reviewing the CAR and CT drafts.
No direct information was received.

-----
Alternatives for SRv6 without CAR or CT.
A third draft (draft-ietf-idr-cpr-00) was adopted as an informational draft.
This informational draft provides a way to encode intent for
SRv6 by operational practices rather than a new protocol.

## Directorate Reviews: (tracked by Datatracker) with comments from shepherd
RTG-DIR reviews:
Early Review of draft-ietf-idr-bgp-ct-09 (Med Boucadair)- status: has issues, excellent review
https://mailarchive.ietf.org/arch/msg/rtg-dir/aawFfvd29zERSBK4ydDDhxEQGRw
Early Review of draft-ietf-idr-bgp-ct-18 (Jonathan Hardwick) - status: has nits, good review
https://mailarchive.ietf.org/arch/msg/rtg-dir/FLGmC0-ufqPsZpH_LmgL2eWmWhY
Shepherd's follow-up: All NITs resolved by -30

OPS-DIR reviews:
Early Review of draft-ietf-idr-bgp-ct-12 (Bo Wu) - status: Has issues, Quality: good review, 4 issues mentioned
https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ct-12-opsdir-early-wu-2023-08-03/
Early Review of draft-ietf-idr-bgp-ct-18 (Bo Wu) - status: has nits, Quality: good review, 2nd review by the same reviewer as -12
https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ct-19-opsdir-early-wu-2024-01-05/
Shepherd's review: All Nits resolved by -30.

SEC-DIR Review:
Authors resolved in -30, except for NIT
email link: https://mailarchive.ietf.org/arch/msg/idr/fYulGchhf6oWPWhVWHxqx6WNupI/
github: assigned github issue #69
github link:https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/69
Status: Shepherd awaiting clarification email (sent 4/9))
Resolved by -32, but AD should look at the github issue #69 (closed issue)
https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/69


TSV-Review: (due date 3/6/2024) - On the Right Track.
https://mailarchive.ietf.org/arch/msg/tsv-art/hml_nr-BAbzXk7RnKCCy-EVXLuw/
TSV-DIR:
From the viewpoint of the transport area, there are two important points that
need to be discussed when considering such tunnels:
1)  MTU problems if the tunnel configurations differ, and
2) DSCP issues if DSPC is used to provide non-best effort services.
Status: -30 contained fixes for TSV-DIR, but no 2nd review.


Shepherd's comment for TSV-DIR: Please look at this draft from the viewpoint of having intent (color) aware customer traffic forwarded over a VPN overlay (tunnels) that forwarded over a set of intent (color) aware underlay of tunnels.  Please consider the problems with tunnels in your review of this text.

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

Andrew mentioned he received feedback that there would be discomfort
if the CAR and CT do not progress to the Experimental simultaneously.
See Andrew Alston for additional details.

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

    Implementation report:
    https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-bgp-ct
 
    Implementation of CT:  Juniper, Freertg
    Implementation of CT-srv6: (TBD)

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.

  Reviews requested from PCE, Spring, and BESS before 2nd WG LC.
  Received reviews from PCE: CT updated based on feedback (missing link in IDR Mail)
  Received feedback from Spring chairs (Alvaro Retana)
    The following drafts were in the option queue:
      draft-hr-spring-intentaware-routing-using-color
      draft-salih-spring-srv6-inter-domain-sids-04 (ct-srv6)
 
  Nothing was received from BESS.
  RTG-DIR reviews: 2 early reviews - (-18) "has nits" 
  OPS-DIR reviews: 2 early reviews - (-19) "has nits"
  SEC-DIR reviews: 2 early reviews - (-19) 6 problems + 4 questions (must be resolved)
  TSV-DIR review:  1 early review requested - no response.
  IANA Early review: IANA early review of draft-ietf-idr-bgp-ct-27 IANA section.
 
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 requirement for formal review (MIB, Yang, Media type, and URI)
  A yang module for CT will be added to the list of Yang modules to create for BGP.

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 in the document

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 automated checking

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

Checks completed:
  1) Pre-Adoption by Jeff Haas and discussion among chairs 
  2) Careful Adoption review resulted in a list of issues that needed to be resolved:
      (https://wiki.ietf.org/group/idr/CAR-CTAdoption)
  3) Adoption call issues added to github for draft-ietf-idr-bgp-ct-27 
      (https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues)
  4) 1st WG LC -
      Prior to 1st WG LC: Shepherd verified that issues were addressed
                          and early Early Directorate reviews requested,
      1st WG LC: Shepherd report written
      (see https://wiki.ietf.org/group/idr/CT-WGLC and                     
      https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues)       
      Review provided by IDR Chair team: Jie Dong, Keyur Patel, and Jeff Haas.
 
  5) 2nd WG LC
      Prior to 2nd WG LC:
        a) Shepherd verified that issues raised in 1st WG LC were addressed.
        b) Review provided by IDR Chair team: Jie Dong, Keyur Patel, and Jeff Haas.
        c) IDR Chair team resolutions were made - via email and meetings of
          technical issues.
        d) Early reviews requested (RTG-DIR, OPS-DIR, SEC-DIR, and TSV-DIR)
          open reviews: resolution of SEC-DIR and lack of TSV-DIR
        d) Meeting with CAR and CT editor teams during 2nd WGLC
        e) two interims in 2024 - January 29 and February 26 - review status
    6) Post WG LC
        a) Shepherd reports with editorial nits [resolved]
        b) Shepherd report loaded into github as issues [Resolved]
        c) Review issues with document editors before -27 submission [Resolved] 
        b) IANA review of -27 requested. [pending]
        c) github issue loaded with Security Directorate review comments

    7)Final Checks
        a) Response from IANA review of -27
        b) Response from SEC-DIR resolution check
        c) final NITS check
        d) RFC9012 issues

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?  All items addressed, but these are the key points

  RTG-DIR and OPS-IDR review examines whether these new "intent-aware" (color)
  are able to be created and used. The early review cycles ended with "OK with NITs".
  The NITs have been address (see github for tracking of NITs). 

  The Transport area review (TSV-DIR) was only looking at whether the network
  was on the right path to allow intents to create "intent" (color) network-wide
  paths of a certain type.  Applications through transport layers are the ones to signal
  a particular intent and need.  The desired answer from TSV-DIR is "on the right track".
   
  SEC-DIR review of CT and CTv6 mentioned that these drafts look to
  BGP security solutions (BGPsec and Origin validation) to provide additional security
  without giving the details on the solutions. During an investigation of the BGPsec
  a few things turned up about BGPSec. The shepherd notes that RFC8374 points out that BGPsec
  (RFC8205) only included the AFI in the "hash" to resolve a problem (see
  sections 2.2.1 and 6.2.1).  Section 2.2.1 includes the AFI/SAFI in Figure 8,
  but may assume only IPv4 (AFI=1) and IPv6 (AFI=2).

  Due to this unclear text, both BGP intent-based solutions (CAR and CT)
  merely state that BGPsec and Origin Validation could be extended.  It is beyond the
  scope of these individual drafts to raise the wider issue of BGPsec applications
  for many new AFI/SAFIs. It is an an issues that needs addressing by the IDR WG.

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?

    Experimental draft.  Why? IDR cannot settle on a single solution for Intent-based (Color) routing. 
    The top 2 solutions are forwarded as experimental drafts to allow operational deployment to give feedback.

    Do all Datatracker state attributes correctly reflect this intent? Yes .
   
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.

Editors:
2nd WG LC -03
Kaliraj Vairavakkali (kaliraj@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/ZL7tOk3fgqeIRM5dfKfx_GbIh2w/

Natrajan Venkataraman (natv@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/eh3IdjyMjJVQSwOx2CD95iKg1-4/

CoAuthors:
Reshma Das (dreshma@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/Ei8WY3sVYAhnECr1w40Y8C5zQ-Y/

Israel Means (israel.means@att.com)
https://mailarchive.ietf.org/arch/msg/idr/iniOhZ1BknkBhe2l8DYL5aL_lGk/

Csaba Mates (ietf@nop.hu)
https://mailarchive.ietf.org/arch/msg/idr/NSxyfq98238jOIllMgIrBF54aeg/

Deepak J. Gowda (dgowda@extremenetworks.com) [2nd WG LC]
https://mailarchive.ietf.org/arch/msg/idr/FWf7jsy7mFJDiW3stAWeJ_DU0oU/

Contributors:
Balaji Rajagoplan (balajir@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/SfJQVDClw7y8vXYoG8wlLKRgyLQ/


Rajesh M (mrajesh@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/4T2BDGnaZUmtWUPjFVIOAFL-ZoI/

Chaitanya Yadlapalli (cy098d@att.com)
https://mailarchive.ietf.org/arch/msg/idr/M1c3trnvMiVn3_QQU9FqbkuvHA0/

Mazen Khaddam (mazen.khaddam@cox.com)
https://mailarchive.ietf.org/arch/msg/idr/lhBotT08JzICX-uPUfhMUSA7uzc/

Rafal Jan Szarecki (Google)
https://mailarchive.ietf.org/arch/msg/idr/r09fylzRRgssJqDoQnhy66qCr-g/

Xiaohu Xu (Captialonline) [from 1st WG LC]
https://mailarchive.ietf.org/arch/msg/idr/DBuobWpmj_ce0IOUWDTZU7m095E/
2nd WG LC
https://mailarchive.ietf.org/arch/msg/idr/Uh39xPb20FTsmORAjgRlce8bwfc/

Contributor for [-12] missing in [-27]
Gyan Mishra (gyan.s.mishra@verizon.com) - dropped as of [-11]
before 1st WG LC. Missing IPR statement.

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.

2 editors on front page.
All IPR statements good for -27 except for Xiahou Xu.
issue with Gyan Mishra - no longer contributor after -11

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

[pending] NITS - see github reference
https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/72


15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
 
    Each of IDR chairs have walked through Normative and Informative references.
    [Pending - Asking for RTG-AD (John Scudder) to do early review on
    normative/non-normative references. ] 

    Note: draft-ietf-idr-bgp-ct-27 references an informative reference: 
    BGP-CT-UPDATE-PACKING-TEST] which is a document on the IETF IDR WG Github.
    Read access is allowed for all. 
    see: https://raw.githubusercontent.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/1a75d4d10d4df0f1fd7dcc041c2c868704b092c7/update-packing-test-results.txt

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 normative references are freely available and published RFCs.
    See comment above regarding 1 informative reference at IETF IDR WG github.;

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

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

    There are no normative references that are not at RFC level.
    Informative references are RFCs, drafts, or one github reference (see #15 above). 

19. Will publication of this document change the status of any existing RFCs? No
    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? not applicable. 
    If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.- not applicable.

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. yes, confirmed 

    Confirm that any referenced IANA registries have been clearly identified. Yes, confirmed. 
    Confirm that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]). yes, Confirmed.

    [pending] Due to a complexity, an early request to review IANA allocation has
    been sent. 

    New registries:
      Transitive Transport Class Extended Community Sub-Types Registry
      Non-Transitive Transport Class Extended Community Sub-Types Registry
      BGP CT Parameters

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.

  No IANA registries that require Designated Expert Review are listed in this draft.

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

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

## Document History

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

The CT progression after adoption is tracked on both the IDR Wiki
and the IDR github repository: ietf-wg-idr/draft-ietf-idr-bgp-ct
https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues

Post 2nd WG LC Shepherd's review of -26.txt
https://mailarchive.ietf.org/arch/msg/idr/7PIQx2nE0Y4d-lR7bIpTPL_TMR0/

Summary of calls: (in reverse time order)
2nd WG LC: 2/16/2024 to 3/1/2024
https://mailarchive.ietf.org/arch/msg/idr/Ud2coGDvdXYy7x-SHPSK2Onwjx4/
Status: Consensus on publication of draft-ietf-idr-bgp-ct and draft-ietf-idr-bgp-ct-srv6
https://mailarchive.ietf.org/arch/msg/idr/oNY5gAcE21y1bke6tBzeb76uVo4/
https://mailarchive.ietf.org/arch/msg/idr/rJC4O726QqUoDEqFTffOF9EvX_U/

----
1st WG LC: draft-ietf-idr-bgp-ct-09.txt (6/26/2023 to 7/17/2023
https://mailarchive.ietf.org/arch/msg/idr/KYZbOsg2y4jcOfjV31pee5uhMjQ/
extension to 7/28: https://mailarchive.ietf.org/arch/msg/idr/Qr8GhdlEi8viaZxOCaWii3cA51s/
Extension to 8/01: https://mailarchive.ietf.org/arch/msg/idr/fC--NIU7VlyOjmNJwIcsXhXFvSk/
status: No consensus reached

The shepherd's write-up on this topic is available on the IDR wiki
https://wiki.ietf.org/e/en/group/idr/CT-WGLC

Email message notifying the WG of 1 WG LC Shepherd's report:
https://mailarchive.ietf.org/arch/msg/idr/klBUhMe9AsdflYhIYVEhSIps_lg/
---------
Adoption call results: (as part of status)
https://mailarchive.ietf.org/arch/msg/idr/0V6pBTQyCmh3t3h9cMqxZ3N0s7Q/

Adoption call: Time: 7/6/2022 to 7/27/2022 in 3 mail threads.
Part 1 of CAR/CT Adoption call (7/6 to 7/27): Informational Questions
​https://mailarchive.ietf.org/arch/msg/idr/FhoK04HsSy9tR7ioV7AD0Vv6Ir4/

Part 2 of CAR/CT Adoption call (7/6 to 7/27): Adoption call
​https://mailarchive.ietf.org/arch/msg/idr/AP_ClbZgpkX6CNy7TaZiU8SMD5w/

Part 3 of CAR/CT Adoption call (7/14 to 7/27) - Please note that Part 3 has a specific format for posting.
​https://mailarchive.ietf.org/arch/msg/idr/fTFYwF54WRHcj7PDt2t7sOQg6vo/

This adoption call was preceded by the following:
Email Discussion before IETF-113
​https://mailarchive.ietf.org/arch/msg/idr/e69NRd9i2aG0WUxFkShEfQHZsHo/

Note: The IDR chairs agree with Jeff Haas's (IDR Co-chair) summary posted on March 21, 2022,
that for route resolution and route origination/propagation,
BGP-CAR and BGP-CT are functionally identical but operationally different.

Presentations from IETF-108 to IETF-113
IDR interim on January 24, 2022
(​https://datatracker.ietf.org/meeting/interim-2022-idr-02/session/idr)


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


Rough Adoption decision:
The IDR chairs agree with Jeff Haas's (IDR Co-chair) summary posted on March 21, 2022,
that for route resolution and route origination/propagation,
BGP-CAR and BGP-CT are functionally identical but operationally different.

IDR WG could not come to a consensus on CAR vs. CT.  IDR Chairs elected to adopt
both CAR and CT drafts as experimental drafts.  Experience in the market
place will help determine which is better operationally.

Rough 1st WG LC of CAR/CT: The IDR WG LC for CAR and CT found the editors/authors/contributors
of CAR commenting on the CT draft (Just as CT authors commented on CAR draft).
In some ways, this lively debate helped find problems in the specifications.

2nd WG LC of CAR/CT: This WG LC did not have a lot of
CAR/CT editor discussions because the IDR Shepherding Chair had
a private discussion between editors prior to the 2nd WG LC.

During 2nd WG LC: Concern on Split of CT drafts into 3 drafts:
https://mailarchive.ietf.org/arch/msg/idr/29CYvVl0RnW0hJSU3il3p_cqt80/

Robert Raszuk raised a Concern regarding the splitting of the
CT draft into three parts (draft-ietf-idr-bgp-ct, draft-ietf-idr-bgp-ct-srv6,
and draft-ietf-idr-bgp-fwd-rr). Robert objected to the draft-ietf-idr-bgp-fwd-rr
being a WG draft.  The IDR chairs felt the text was in draft-ietf-idr-bgp-ct
since version -09, so Robert's concerns about being surprised as
WG draft was not justified.  However, it does point to the value of
the IDR chairs splitting this work out of the draft-ietf-idr-bgp-ct draft.

------
Dependencies on Spring:
a) Functional dependency - caused only theoretical scaling results
Due to a lack of adoption of the Spring Requirements document
draft-hr-spring-intentaware-routing-using-color-03, this WG
Shepherd allowed the scaling results to be theoretical without proof in CT.

b) Normative dependency on draft-ietf-idr-salih-spring-srv6-inter-domain-sids-04.
There is a normative dependency on an individual draft that is waiting for adoption. 
The Spring chairs have been notified that IDR draft-ietf-idr-bgp-ct-srv6
has normative dependencies on draft-ietf-idr-salih-spring-srv6-inter-domain-sids.

Dependencies with PCE
Dhruv Dhody reviewed the interactions with PCE drafts.
He sent comments to the CT authors. CT authors updated their drafts with changes. 

Dependencies with BESS:
BESS chairs were queried about reviewing the CAR and CT drafts.
No direct information was received.

-----
Alternatives for SRv6 without CAR or CT.
A third draft (draft-ietf-idr-cpr-00) was adopted as an informational draft.
This informational draft provides a way to encode intent for
SRv6 by operational practices rather than a new protocol.

## Directorate Reviews: (tracked by Datatracker) with comments from shepherd
RTG-DIR reviews:
Early Review of draft-ietf-idr-bgp-ct-09 (Med Boucadair)- status: has issues, excellent review
https://mailarchive.ietf.org/arch/msg/rtg-dir/aawFfvd29zERSBK4ydDDhxEQGRw
Early Review of draft-ietf-idr-bgp-ct-18 (Jonathan Hardwick) - status: has nits, good review
https://mailarchive.ietf.org/arch/msg/rtg-dir/FLGmC0-ufqPsZpH_LmgL2eWmWhY
Shepherd's follow-up: All NITs resolved by -30

OPS-DIR reviews:
Early Review of draft-ietf-idr-bgp-ct-12 (Bo Wu) - status: Has issues, Quality: good review, 4 issues mentioned
https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ct-12-opsdir-early-wu-2023-08-03/
Early Review of draft-ietf-idr-bgp-ct-18 (Bo Wu) - status: has nits, Quality: good review, 2nd review by the same reviewer as -12
https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ct-19-opsdir-early-wu-2024-01-05/
Shepherd's review: All Nits resolved by -30.

SEC-DIR Review:
Authors resolved in -30, except for NIT
email link: https://mailarchive.ietf.org/arch/msg/idr/fYulGchhf6oWPWhVWHxqx6WNupI/
github: assigned github issue #69
github link:https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/69
Status: Shepherd awaiting clarification email (sent 4/9))
Resolved by -32, but AD should look at the github issue #69 (closed issue)
https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/69


TSV-Review: (due date 3/6/2024) - On the Right Track.
https://mailarchive.ietf.org/arch/msg/tsv-art/hml_nr-BAbzXk7RnKCCy-EVXLuw/
TSV-DIR:
From the viewpoint of the transport area, there are two important points that
need to be discussed when considering such tunnels:
1)  MTU problems if the tunnel configurations differ, and
2) DSCP issues if DSPC is used to provide non-best effort services.
Status: -30 contained fixes for TSV-DIR, but no 2nd review.


Shepherd's comment for TSV-DIR: Please look at this draft from the viewpoint of having intent (color) aware customer traffic forwarded over a VPN overlay (tunnels) that forwarded over a set of intent (color) aware underlay of tunnels.  Please consider the problems with tunnels in your review of this text.

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

Andrew mentioned he received feedback that there would be discomfort
if the CAR and CT do not progress to the Experimental simultaneously.
See Andrew Alston for additional details.

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

    Implementation report:
    https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-bgp-ct
 
    Implementation of CT:  Juniper, Freertg
    Implementation of CT-srv6: (TBD)

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.

  Reviews requested from PCE, Spring, and BESS before 2nd WG LC.
  Received reviews from PCE: CT updated based on feedback (missing link in IDR Mail)
  Received feedback from Spring chairs (Alvaro Retana)
    The following drafts were in the option queue:
      draft-hr-spring-intentaware-routing-using-color
      draft-salih-spring-srv6-inter-domain-sids-04 (ct-srv6)
 
  Nothing was received from BESS.
  RTG-DIR reviews: 2 early reviews - (-18) "has nits" 
  OPS-DIR reviews: 2 early reviews - (-19) "has nits"
  SEC-DIR reviews: 2 early reviews - (-19) 6 problems + 4 questions (must be resolved)
  TSV-DIR review:  1 early review requested - no response.
  IANA Early review: IANA early review of draft-ietf-idr-bgp-ct-27 IANA section.
 
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 requirement for formal review (MIB, Yang, Media type, and URI)
  A yang module for CT will be added to the list of Yang modules to create for BGP.

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 in the document

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 automated checking

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

Checks completed:
  1) Pre-Adoption by Jeff Haas and discussion among chairs 
  2) Careful Adoption review resulted in a list of issues that needed to be resolved:
      (https://wiki.ietf.org/group/idr/CAR-CTAdoption)
  3) Adoption call issues added to github for draft-ietf-idr-bgp-ct-27 
      (https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues)
  4) 1st WG LC -
      Prior to 1st WG LC: Shepherd verified that issues were addressed
                          and early Early Directorate reviews requested,
      1st WG LC: Shepherd report written
      (see https://wiki.ietf.org/group/idr/CT-WGLC and                     
      https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues)       
      Review provided by IDR Chair team: Jie Dong, Keyur Patel, and Jeff Haas.
 
  5) 2nd WG LC
      Prior to 2nd WG LC:
        a) Shepherd verified that issues raised in 1st WG LC were addressed.
        b) Review provided by IDR Chair team: Jie Dong, Keyur Patel, and Jeff Haas.
        c) IDR Chair team resolutions were made - via email and meetings of
          technical issues.
        d) Early reviews requested (RTG-DIR, OPS-DIR, SEC-DIR, and TSV-DIR)
          open reviews: resolution of SEC-DIR and lack of TSV-DIR
        d) Meeting with CAR and CT editor teams during 2nd WGLC
        e) two interims in 2024 - January 29 and February 26 - review status
    6) Post WG LC
        a) Shepherd reports with editorial nits [resolved]
        b) Shepherd report loaded into github as issues [Resolved]
        c) Review issues with document editors before -27 submission [Resolved] 
        b) IANA review of -27 requested. [pending]
        c) github issue loaded with Security Directorate review comments

    7)Final Checks
        a) Response from IANA review of -27
        b) Response from SEC-DIR resolution check
        c) final NITS check
        d) RFC9012 issues

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?  All items addressed, but these are the key points

  RTG-DIR and OPS-IDR review examines whether these new "intent-aware" (color)
  are able to be created and used. The early review cycles ended with "OK with NITs".
  The NITs have been address (see github for tracking of NITs). 

  The Transport area review (TSV-DIR) was only looking at whether the network
  was on the right path to allow intents to create "intent" (color) network-wide
  paths of a certain type.  Applications through transport layers are the ones to signal
  a particular intent and need.  The desired answer from TSV-DIR is "on the right track".
   
  SEC-DIR review of CT and CTv6 mentioned that these drafts look to
  BGP security solutions (BGPsec and Origin validation) to provide additional security
  without giving the details on the solutions. During an investigation of the BGPsec
  a few things turned up about BGPSec. The shepherd notes that RFC8374 points out that BGPsec
  (RFC8205) only included the AFI in the "hash" to resolve a problem (see
  sections 2.2.1 and 6.2.1).  Section 2.2.1 includes the AFI/SAFI in Figure 8,
  but may assume only IPv4 (AFI=1) and IPv6 (AFI=2).

  Due to this unclear text, both BGP intent-based solutions (CAR and CT)
  merely state that BGPsec and Origin Validation could be extended.  It is beyond the
  scope of these individual drafts to raise the wider issue of BGPsec applications
  for many new AFI/SAFIs. It is an an issues that needs addressing by the IDR WG.

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?

    Experimental draft.  Why? IDR cannot settle on a single solution for Intent-based (Color) routing. 
    The top 2 solutions are forwarded as experimental drafts to allow operational deployment to give feedback.

    Do all Datatracker state attributes correctly reflect this intent? Yes .
   
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.

Editors:
2nd WG LC -03
Kaliraj Vairavakkali (kaliraj@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/ZL7tOk3fgqeIRM5dfKfx_GbIh2w/

Natrajan Venkataraman (natv@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/eh3IdjyMjJVQSwOx2CD95iKg1-4/

CoAuthors:
Reshma Das (dreshma@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/Ei8WY3sVYAhnECr1w40Y8C5zQ-Y/

Israel Means (israel.means@att.com)
https://mailarchive.ietf.org/arch/msg/idr/iniOhZ1BknkBhe2l8DYL5aL_lGk/

Csaba Mates (ietf@nop.hu)
https://mailarchive.ietf.org/arch/msg/idr/NSxyfq98238jOIllMgIrBF54aeg/

Deepak J. Gowda (dgowda@extremenetworks.com) [2nd WG LC]
https://mailarchive.ietf.org/arch/msg/idr/FWf7jsy7mFJDiW3stAWeJ_DU0oU/

Contributors:
Balaji Rajagoplan (balajir@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/SfJQVDClw7y8vXYoG8wlLKRgyLQ/


Rajesh M (mrajesh@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/4T2BDGnaZUmtWUPjFVIOAFL-ZoI/

Chaitanya Yadlapalli (cy098d@att.com)
https://mailarchive.ietf.org/arch/msg/idr/M1c3trnvMiVn3_QQU9FqbkuvHA0/

Mazen Khaddam (mazen.khaddam@cox.com)
https://mailarchive.ietf.org/arch/msg/idr/lhBotT08JzICX-uPUfhMUSA7uzc/

Rafal Jan Szarecki (Google)
https://mailarchive.ietf.org/arch/msg/idr/r09fylzRRgssJqDoQnhy66qCr-g/

Xiaohu Xu (Captialonline) [from 1st WG LC]
https://mailarchive.ietf.org/arch/msg/idr/DBuobWpmj_ce0IOUWDTZU7m095E/
2nd WG LC
https://mailarchive.ietf.org/arch/msg/idr/Uh39xPb20FTsmORAjgRlce8bwfc/

Contributor for [-12] missing in [-27]
Gyan Mishra (gyan.s.mishra@verizon.com) - dropped as of [-11]
before 1st WG LC. Missing IPR statement.

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.

2 editors on front page.
All IPR statements good for -27 except for Xiahou Xu.
issue with Gyan Mishra - no longer contributor after -11

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

[pending] NITS - see github reference
https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/72


15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
 
    Each of IDR chairs have walked through Normative and Informative references.
    [Pending - Asking for RTG-AD (John Scudder) to do early review on
    normative/non-normative references. ] 

    Note: draft-ietf-idr-bgp-ct-27 references an informative reference: 
    BGP-CT-UPDATE-PACKING-TEST] which is a document on the IETF IDR WG Github.
    Read access is allowed for all. 
    see: https://raw.githubusercontent.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/1a75d4d10d4df0f1fd7dcc041c2c868704b092c7/update-packing-test-results.txt

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 normative references are freely available and published RFCs.
    See comment above regarding 1 informative reference at IETF IDR WG github.;

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

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

    There are no normative references that are not at RFC level.
    Informative references are RFCs, drafts, or one github reference (see #15 above). 

19. Will publication of this document change the status of any existing RFCs? No
    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? not applicable. 
    If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.- not applicable.

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. yes, confirmed 

    Confirm that any referenced IANA registries have been clearly identified. Yes, confirmed. 
    Confirm that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]). yes, Confirmed.

    [pending] Due to a complexity, an early request to review IANA allocation has
    been sent. 

    New registries:
      Transitive Transport Class Extended Community Sub-Types Registry
      Non-Transitive Transport Class Extended Community Sub-Types Registry
      BGP CT Parameters

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.

  No IANA registries that require Designated Expert Review are listed in this draft.

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

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

## Document History

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

The CT progression after adoption is tracked on both the IDR Wiki
and the IDR github repository: ietf-wg-idr/draft-ietf-idr-bgp-ct
https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues

Post 2nd WG LC Shepherd's review of -26.txt
https://mailarchive.ietf.org/arch/msg/idr/7PIQx2nE0Y4d-lR7bIpTPL_TMR0/

Summary of calls: (in reverse time order)
2nd WG LC: 2/16/2024 to 3/1/2024
https://mailarchive.ietf.org/arch/msg/idr/Ud2coGDvdXYy7x-SHPSK2Onwjx4/
Status: Consensus on publication of draft-ietf-idr-bgp-ct and draft-ietf-idr-bgp-ct-srv6
https://mailarchive.ietf.org/arch/msg/idr/oNY5gAcE21y1bke6tBzeb76uVo4/
https://mailarchive.ietf.org/arch/msg/idr/rJC4O726QqUoDEqFTffOF9EvX_U/

----
1st WG LC: draft-ietf-idr-bgp-ct-09.txt (6/26/2023 to 7/17/2023
https://mailarchive.ietf.org/arch/msg/idr/KYZbOsg2y4jcOfjV31pee5uhMjQ/
extension to 7/28: https://mailarchive.ietf.org/arch/msg/idr/Qr8GhdlEi8viaZxOCaWii3cA51s/
Extension to 8/01: https://mailarchive.ietf.org/arch/msg/idr/fC--NIU7VlyOjmNJwIcsXhXFvSk/
status: No consensus reached

The shepherd's write-up on this topic is available on the IDR wiki
https://wiki.ietf.org/e/en/group/idr/CT-WGLC

Email message notifying the WG of 1 WG LC Shepherd's report:
https://mailarchive.ietf.org/arch/msg/idr/klBUhMe9AsdflYhIYVEhSIps_lg/
---------
Adoption call results: (as part of status)
https://mailarchive.ietf.org/arch/msg/idr/0V6pBTQyCmh3t3h9cMqxZ3N0s7Q/

Adoption call: Time: 7/6/2022 to 7/27/2022 in 3 mail threads.
Part 1 of CAR/CT Adoption call (7/6 to 7/27): Informational Questions
​https://mailarchive.ietf.org/arch/msg/idr/FhoK04HsSy9tR7ioV7AD0Vv6Ir4/

Part 2 of CAR/CT Adoption call (7/6 to 7/27): Adoption call
​https://mailarchive.ietf.org/arch/msg/idr/AP_ClbZgpkX6CNy7TaZiU8SMD5w/

Part 3 of CAR/CT Adoption call (7/14 to 7/27) - Please note that Part 3 has a specific format for posting.
​https://mailarchive.ietf.org/arch/msg/idr/fTFYwF54WRHcj7PDt2t7sOQg6vo/

This adoption call was preceded by the following:
Email Discussion before IETF-113
​https://mailarchive.ietf.org/arch/msg/idr/e69NRd9i2aG0WUxFkShEfQHZsHo/

Note: The IDR chairs agree with Jeff Haas's (IDR Co-chair) summary posted on March 21, 2022,
that for route resolution and route origination/propagation,
BGP-CAR and BGP-CT are functionally identical but operationally different.

Presentations from IETF-108 to IETF-113
IDR interim on January 24, 2022
(​https://datatracker.ietf.org/meeting/interim-2022-idr-02/session/idr)


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


Rough Adoption decision:
The IDR chairs agree with Jeff Haas's (IDR Co-chair) summary posted on March 21, 2022,
that for route resolution and route origination/propagation,
BGP-CAR and BGP-CT are functionally identical but operationally different.

IDR WG could not come to a consensus on CAR vs. CT.  IDR Chairs elected to adopt
both CAR and CT drafts as experimental drafts.  Experience in the market
place will help determine which is better operationally.

Rough 1st WG LC of CAR/CT: The IDR WG LC for CAR and CT found the editors/authors/contributors
of CAR commenting on the CT draft (Just as CT authors commented on CAR draft).
In some ways, this lively debate helped find problems in the specifications.

2nd WG LC of CAR/CT: This WG LC did not have a lot of
CAR/CT editor discussions because the IDR Shepherding Chair had
a private discussion between editors prior to the 2nd WG LC.

During 2nd WG LC: Concern on Split of CT drafts into 3 drafts:
https://mailarchive.ietf.org/arch/msg/idr/29CYvVl0RnW0hJSU3il3p_cqt80/

Robert Raszuk raised a Concern regarding the splitting of the
CT draft into three parts (draft-ietf-idr-bgp-ct, draft-ietf-idr-bgp-ct-srv6,
and draft-ietf-idr-bgp-fwd-rr). Robert objected to the draft-ietf-idr-bgp-fwd-rr
being a WG draft.  The IDR chairs felt the text was in draft-ietf-idr-bgp-ct
since version -09, so Robert's concerns about being surprised as
WG draft was not justified.  However, it does point to the value of
the IDR chairs splitting this work out of the draft-ietf-idr-bgp-ct draft.

------
Dependencies on Spring:
a) Functional dependency - caused only theoretical scaling results
Due to a lack of adoption of the Spring Requirements document
draft-hr-spring-intentaware-routing-using-color-03, this WG
Shepherd allowed the scaling results to be theoretical without proof in CT.

b) Normative dependency on draft-ietf-idr-salih-spring-srv6-inter-domain-sids-04.
There is a normative dependency on an individual draft that is waiting for adoption. 
The Spring chairs have been notified that IDR draft-ietf-idr-bgp-ct-srv6
has normative dependencies on draft-ietf-idr-salih-spring-srv6-inter-domain-sids.

Dependencies with PCE
Dhruv Dhody reviewed the interactions with PCE drafts.
He sent comments to the CT authors. CT authors updated their drafts with changes. 

Dependencies with BESS:
BESS chairs were queried about reviewing the CAR and CT drafts.
No direct information was received.

-----
Alternatives for SRv6 without CAR or CT.
A third draft (draft-ietf-idr-cpr-00) was adopted as an informational draft.
This informational draft provides a way to encode intent for
SRv6 by operational practices rather than a new protocol.

## Directorate Reviews: (tracked by Datatracker) with comments from shepherd
RTG-DIR reviews:
Early Review of draft-ietf-idr-bgp-ct-09 (Med Boucadair)- status: has issues, excellent review
https://mailarchive.ietf.org/arch/msg/rtg-dir/aawFfvd29zERSBK4ydDDhxEQGRw
Early Review of draft-ietf-idr-bgp-ct-18 (Jonathan Hardwick) - status: has nits, good review
https://mailarchive.ietf.org/arch/msg/rtg-dir/FLGmC0-ufqPsZpH_LmgL2eWmWhY
Shepherd's follow-up: All NITs resolved by -30

OPS-DIR reviews:
Early Review of draft-ietf-idr-bgp-ct-12 (Bo Wu) - status: Has issues, Quality: good review, 4 issues mentioned
https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ct-12-opsdir-early-wu-2023-08-03/
Early Review of draft-ietf-idr-bgp-ct-18 (Bo Wu) - status: has nits, Quality: good review, 2nd review by the same reviewer as -12
https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ct-19-opsdir-early-wu-2024-01-05/
Shepherd's review: All Nits resolved by -30.

SEC-DIR Review:
Authors resolved in -30, except for NIT
email link: https://mailarchive.ietf.org/arch/msg/idr/fYulGchhf6oWPWhVWHxqx6WNupI/
github: assigned github issue #69
github link:https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/69
Status: Shepherd awaiting clarification email (sent 4/9))
Resolved by -32, but AD should look at the github issue #69 (closed issue)
https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/69


TSV-Review: (due date 3/6/2024) - On the Right Track.
https://mailarchive.ietf.org/arch/msg/tsv-art/hml_nr-BAbzXk7RnKCCy-EVXLuw/
TSV-DIR:
From the viewpoint of the transport area, there are two important points that
need to be discussed when considering such tunnels:
1)  MTU problems if the tunnel configurations differ, and
2) DSCP issues if DSPC is used to provide non-best effort services.
Status: -30 contained fixes for TSV-DIR, but no 2nd review.


Shepherd's comment for TSV-DIR: Please look at this draft from the viewpoint of having intent (color) aware customer traffic forwarded over a VPN overlay (tunnels) that forwarded over a set of intent (color) aware underlay of tunnels.  Please consider the problems with tunnels in your review of this text.

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

Andrew mentioned he received feedback that there would be discomfort
if the CAR and CT do not progress to the Experimental simultaneously.
See Andrew Alston for additional details.

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

    Implementation report:
    https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-bgp-ct
 
    Implementation of CT:  Juniper, Freertg
    Implementation of CT-srv6: (TBD)

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.

  Reviews requested from PCE, Spring, and BESS before 2nd WG LC.
  Received reviews from PCE: CT updated based on feedback (missing link in IDR Mail)
  Received feedback from Spring chairs (Alvaro Retana)
    The following drafts were in the option queue:
      draft-hr-spring-intentaware-routing-using-color
      draft-salih-spring-srv6-inter-domain-sids-04 (ct-srv6)
 
  Nothing was received from BESS.
  RTG-DIR reviews: 2 early reviews - (-18) "has nits" 
  OPS-DIR reviews: 2 early reviews - (-19) "has nits"
  SEC-DIR reviews: 2 early reviews - (-19) 6 problems + 4 questions (must be resolved)
  TSV-DIR review:  1 early review requested - no response.
  IANA Early review: IANA early review of draft-ietf-idr-bgp-ct-27 IANA section.
 
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 requirement for formal review (MIB, Yang, Media type, and URI)
  A yang module for CT will be added to the list of Yang modules to create for BGP.

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 in the document

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 automated checking

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

Checks completed:
  1) Pre-Adoption by Jeff Haas and discussion among chairs 
  2) Careful Adoption review resulted in a list of issues that needed to be resolved:
      (https://wiki.ietf.org/group/idr/CAR-CTAdoption)
  3) Adoption call issues added to github for draft-ietf-idr-bgp-ct-27 
      (https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues)
  4) 1st WG LC -
      Prior to 1st WG LC: Shepherd verified that issues were addressed
                          and early Early Directorate reviews requested,
      1st WG LC: Shepherd report written
      (see https://wiki.ietf.org/group/idr/CT-WGLC and                     
      https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues)       
      Review provided by IDR Chair team: Jie Dong, Keyur Patel, and Jeff Haas.
 
  5) 2nd WG LC
      Prior to 2nd WG LC:
        a) Shepherd verified that issues raised in 1st WG LC were addressed.
        b) Review provided by IDR Chair team: Jie Dong, Keyur Patel, and Jeff Haas.
        c) IDR Chair team resolutions were made - via email and meetings of
          technical issues.
        d) Early reviews requested (RTG-DIR, OPS-DIR, SEC-DIR, and TSV-DIR)
          open reviews: resolution of SEC-DIR and lack of TSV-DIR
        d) Meeting with CAR and CT editor teams during 2nd WGLC
        e) two interims in 2024 - January 29 and February 26 - review status
    6) Post WG LC
        a) Shepherd reports with editorial nits [resolved]
        b) Shepherd report loaded into github as issues [Resolved]
        c) Review issues with document editors before -27 submission [Resolved] 
        b) IANA review of -27 requested. [pending]
        c) github issue loaded with Security Directorate review comments

    7)Final Checks
        a) Response from IANA review of -27
        b) Response from SEC-DIR resolution check
        c) final NITS check
        d) RFC9012 issues

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?  All items addressed, but these are the key points

  RTG-DIR and OPS-IDR review examines whether these new "intent-aware" (color)
  are able to be created and used. The early review cycles ended with "OK with NITs".
  The NITs have been address (see github for tracking of NITs). 

  The Transport area review (TSV-DIR) was only looking at whether the network
  was on the right path to allow intents to create "intent" (color) network-wide
  paths of a certain type.  Applications through transport layers are the ones to signal
  a particular intent and need.  The desired answer from TSV-DIR is "on the right track".
   
  SEC-DIR review of CT and CTv6 mentioned that these drafts look to
  BGP security solutions (BGPsec and Origin validation) to provide additional security
  without giving the details on the solutions. During an investigation of the BGPsec
  a few things turned up about BGPSec. The shepherd notes that RFC8374 points out that BGPsec
  (RFC8205) only included the AFI in the "hash" to resolve a problem (see
  sections 2.2.1 and 6.2.1).  Section 2.2.1 includes the AFI/SAFI in Figure 8,
  but may assume only IPv4 (AFI=1) and IPv6 (AFI=2).

  Due to this unclear text, both BGP intent-based solutions (CAR and CT)
  merely state that BGPsec and Origin Validation could be extended.  It is beyond the
  scope of these individual drafts to raise the wider issue of BGPsec applications
  for many new AFI/SAFIs. It is an an issues that needs addressing by the IDR WG.

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?

    Experimental draft.  Why? IDR cannot settle on a single solution for Intent-based (Color) routing. 
    The top 2 solutions are forwarded as experimental drafts to allow operational deployment to give feedback.

    Do all Datatracker state attributes correctly reflect this intent? Yes .
   
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.

Editors:
2nd WG LC -03
Kaliraj Vairavakkali (kaliraj@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/ZL7tOk3fgqeIRM5dfKfx_GbIh2w/

Natrajan Venkataraman (natv@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/eh3IdjyMjJVQSwOx2CD95iKg1-4/

CoAuthors:
Reshma Das (dreshma@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/Ei8WY3sVYAhnECr1w40Y8C5zQ-Y/

Israel Means (israel.means@att.com)
https://mailarchive.ietf.org/arch/msg/idr/iniOhZ1BknkBhe2l8DYL5aL_lGk/

Csaba Mates (ietf@nop.hu)
https://mailarchive.ietf.org/arch/msg/idr/NSxyfq98238jOIllMgIrBF54aeg/

Deepak J. Gowda (dgowda@extremenetworks.com) [2nd WG LC]
https://mailarchive.ietf.org/arch/msg/idr/FWf7jsy7mFJDiW3stAWeJ_DU0oU/

Contributors:
Balaji Rajagoplan (balajir@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/SfJQVDClw7y8vXYoG8wlLKRgyLQ/


Rajesh M (mrajesh@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/4T2BDGnaZUmtWUPjFVIOAFL-ZoI/

Chaitanya Yadlapalli (cy098d@att.com)
https://mailarchive.ietf.org/arch/msg/idr/M1c3trnvMiVn3_QQU9FqbkuvHA0/

Mazen Khaddam (mazen.khaddam@cox.com)
https://mailarchive.ietf.org/arch/msg/idr/lhBotT08JzICX-uPUfhMUSA7uzc/

Rafal Jan Szarecki (Google)
https://mailarchive.ietf.org/arch/msg/idr/r09fylzRRgssJqDoQnhy66qCr-g/

Xiaohu Xu (Captialonline) [from 1st WG LC]
https://mailarchive.ietf.org/arch/msg/idr/DBuobWpmj_ce0IOUWDTZU7m095E/
2nd WG LC
https://mailarchive.ietf.org/arch/msg/idr/Uh39xPb20FTsmORAjgRlce8bwfc/

Contributor for [-12] missing in [-27]
Gyan Mishra (gyan.s.mishra@verizon.com) - dropped as of [-11]
before 1st WG LC. Missing IPR statement.

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.

2 editors on front page.
All IPR statements good for -27 except for Xiahou Xu.
issue with Gyan Mishra - no longer contributor after -11

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

[pending] NITS - see github reference
(see https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/70)
    - 2 lines over 72 length, but it seems the tools.

-(2477): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding
-(2501): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
 
    Each of IDR chairs have walked through Normative and Informative references.
    [Pending - Asking for RTG-AD (John Scudder) to do early review on
    normative/non-normative references. ] 

    Note: draft-ietf-idr-bgp-ct-27 references an informative reference: 
    BGP-CT-UPDATE-PACKING-TEST] which is a document on the IETF IDR WG Github.
    Read access is allowed for all. 
    see: https://raw.githubusercontent.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/1a75d4d10d4df0f1fd7dcc041c2c868704b092c7/update-packing-test-results.txt

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 normative references are freely available and published RFCs.
    See comment above regarding 1 informative reference at IETF IDR WG github.;

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

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

    There are no normative references that are not at RFC level.
    Informative references are RFCs, drafts, or one github reference (see #15 above). 

19. Will publication of this document change the status of any existing RFCs? No
    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? not applicable. 
    If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.- not applicable.

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. yes, confirmed 

    Confirm that any referenced IANA registries have been clearly identified. Yes, confirmed. 
    Confirm that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]). yes, Confirmed.

    [pending] Due to a complexity, an early request to review IANA allocation has
    been sent. 

    New registries:
      Transitive Transport Class Extended Community Sub-Types Registry
      Non-Transitive Transport Class Extended Community Sub-Types Registry
      BGP CT Parameters

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.

  No IANA registries that require Designated Expert Review are listed in this draft.

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

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

Need information:
1) Check on Updates for RFC9012 - document in github

## Document History

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

The CT progression after adoption is tracked on both the IDR Wiki
and the IDR github repository: ietf-wg-idr/draft-ietf-idr-bgp-ct
https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues

Post 2nd WG LC Shepherd's review of -26.txt
https://mailarchive.ietf.org/arch/msg/idr/7PIQx2nE0Y4d-lR7bIpTPL_TMR0/

Summary of calls: (in reverse time order)
2nd WG LC: 2/16/2024 to 3/1/2024
https://mailarchive.ietf.org/arch/msg/idr/Ud2coGDvdXYy7x-SHPSK2Onwjx4/
Status: Consensus on publication of draft-ietf-idr-bgp-ct and draft-ietf-idr-bgp-ct-srv6
https://mailarchive.ietf.org/arch/msg/idr/oNY5gAcE21y1bke6tBzeb76uVo4/
https://mailarchive.ietf.org/arch/msg/idr/rJC4O726QqUoDEqFTffOF9EvX_U/

----
1st WG LC: draft-ietf-idr-bgp-ct-09.txt (6/26/2023 to 7/17/2023
https://mailarchive.ietf.org/arch/msg/idr/KYZbOsg2y4jcOfjV31pee5uhMjQ/
extension to 7/28: https://mailarchive.ietf.org/arch/msg/idr/Qr8GhdlEi8viaZxOCaWii3cA51s/
Extension to 8/01: https://mailarchive.ietf.org/arch/msg/idr/fC--NIU7VlyOjmNJwIcsXhXFvSk/
status: No consensus reached

The shepherd's write-up on this topic is available on the IDR wiki
https://wiki.ietf.org/e/en/group/idr/CT-WGLC

Email message notifying the WG of 1 WG LC Shepherd's report:
https://mailarchive.ietf.org/arch/msg/idr/klBUhMe9AsdflYhIYVEhSIps_lg/
---------
Adoption call results: (as part of status)
https://mailarchive.ietf.org/arch/msg/idr/0V6pBTQyCmh3t3h9cMqxZ3N0s7Q/

Adoption call: Time: 7/6/2022 to 7/27/2022 in 3 mail threads.
Part 1 of CAR/CT Adoption call (7/6 to 7/27): Informational Questions
​https://mailarchive.ietf.org/arch/msg/idr/FhoK04HsSy9tR7ioV7AD0Vv6Ir4/

Part 2 of CAR/CT Adoption call (7/6 to 7/27): Adoption call
​https://mailarchive.ietf.org/arch/msg/idr/AP_ClbZgpkX6CNy7TaZiU8SMD5w/

Part 3 of CAR/CT Adoption call (7/14 to 7/27) - Please note that Part 3 has a specific format for posting.
​https://mailarchive.ietf.org/arch/msg/idr/fTFYwF54WRHcj7PDt2t7sOQg6vo/

This adoption call was preceded by the following:
Email Discussion before IETF-113
​https://mailarchive.ietf.org/arch/msg/idr/e69NRd9i2aG0WUxFkShEfQHZsHo/

Note: The IDR chairs agree with Jeff Haas's (IDR Co-chair) summary posted on March 21, 2022,
that for route resolution and route origination/propagation,
BGP-CAR and BGP-CT are functionally identical but operationally different.

Presentations from IETF-108 to IETF-113
IDR interim on January 24, 2022
(​https://datatracker.ietf.org/meeting/interim-2022-idr-02/session/idr)


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


Rough Adoption decision:
The IDR chairs agree with Jeff Haas's (IDR Co-chair) summary posted on March 21, 2022,
that for route resolution and route origination/propagation,
BGP-CAR and BGP-CT are functionally identical but operationally different.

IDR WG could not come to a consensus on CAR vs. CT.  IDR Chairs elected to adopt
both CAR and CT drafts as experimental drafts.  Experience in the market
place will help determine which is better operationally.

Rough 1st WG LC of CAR/CT: The IDR WG LC for CAR and CT found the editors/authors/contributors
of CAR commenting on the CT draft (Just as CT authors commented on CAR draft).
In some ways, this lively debate helped find problems in the specifications.

2nd WG LC of CAR/CT: This WG LC did not have a lot of
CAR/CT editor discussions because the IDR Shepherding Chair had
a private discussion between editors prior to the 2nd WG LC.

During 2nd WG LC: Concern on Split of CT drafts into 3 drafts:
https://mailarchive.ietf.org/arch/msg/idr/29CYvVl0RnW0hJSU3il3p_cqt80/

Robert Raszuk raised a Concern regarding the splitting of the
CT draft into three parts (draft-ietf-idr-bgp-ct, draft-ietf-idr-bgp-ct-srv6,
and draft-ietf-idr-bgp-fwd-rr). Robert objected to the draft-ietf-idr-bgp-fwd-rr
being a WG draft.  The IDR chairs felt the text was in draft-ietf-idr-bgp-ct
since version -09, so Robert's concerns about being surprised as
WG draft was not justified.  However, it does point to the value of
the IDR chairs splitting this work out of the draft-ietf-idr-bgp-ct draft.

------
Dependencies on Spring:
a) Functional dependency - caused only theoretical scaling results
Due to a lack of adoption of the Spring Requirements document
draft-hr-spring-intentaware-routing-using-color-03, this WG
Shepherd allowed the scaling results to be theoretical without proof in CT.

b) Normative dependency on draft-ietf-idr-salih-spring-srv6-inter-domain-sids-04.
There is a normative dependency on an individual draft that is waiting for adoption. 
The Spring chairs have been notified that IDR draft-ietf-idr-bgp-ct-srv6
has normative dependencies on draft-ietf-idr-salih-spring-srv6-inter-domain-sids.

Dependencies with PCE
Dhruv Dhody reviewed the interactions with PCE drafts.
He sent comments to the CT authors. CT authors updated their drafts with changes. 

Dependencies with BESS:
BESS chairs were queried about reviewing the CAR and CT drafts.
No direct information was received.

-----
Alternatives for SRv6 without CAR or CT.
A third draft (draft-ietf-idr-cpr-00) was adopted as an informational draft.
This informational draft provides a way to encode intent for
SRv6 by operational practices rather than a new protocol.

## Directorate Reviews: (tracked by Datatracker) with comments from shepherd
RTG-DIR reviews:
Early Review of draft-ietf-idr-bgp-ct-09 (Med Boucadair)- status: has issues, excellent review
https://mailarchive.ietf.org/arch/msg/rtg-dir/aawFfvd29zERSBK4ydDDhxEQGRw
Early Review of draft-ietf-idr-bgp-ct-18 (Jonathan Hardwick) - status: has nits, good review
https://mailarchive.ietf.org/arch/msg/rtg-dir/FLGmC0-ufqPsZpH_LmgL2eWmWhY
Shepherd's follow-up: All NITs resolved by -30

OPS-DIR reviews:
Early Review of draft-ietf-idr-bgp-ct-12 (Bo Wu) - status: Has issues, Quality: good review, 4 issues mentioned
https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ct-12-opsdir-early-wu-2023-08-03/
Early Review of draft-ietf-idr-bgp-ct-18 (Bo Wu) - status: has nits, Quality: good review, 2nd review by the same reviewer as -12
https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ct-19-opsdir-early-wu-2024-01-05/
Shepherd's review: All Nits resolved by -30.

SEC-DIR Review:
Authors resolved in -30, except for NIT
email link: https://mailarchive.ietf.org/arch/msg/idr/fYulGchhf6oWPWhVWHxqx6WNupI/
github: assigned github issue #69
github link:https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/69
Status: Shepherd awaiting clarification email (sent 4/9))
Resolved by -32, but AD should look at the github issue #69 (closed issue)
https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/69


TSV-Review: (due date 3/6/2024) - On the Right Track.
https://mailarchive.ietf.org/arch/msg/tsv-art/hml_nr-BAbzXk7RnKCCy-EVXLuw/
TSV-DIR:
From the viewpoint of the transport area, there are two important points that
need to be discussed when considering such tunnels:
1)  MTU problems if the tunnel configurations differ, and
2) DSCP issues if DSPC is used to provide non-best effort services.
Status: -30 contained fixes for TSV-DIR, but no 2nd review.


Shepherd's comment for TSV-DIR: Please look at this draft from the viewpoint of having intent (color) aware customer traffic forwarded over a VPN overlay (tunnels) that forwarded over a set of intent (color) aware underlay of tunnels.  Please consider the problems with tunnels in your review of this text.

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

Andrew mentioned he received feedback that there would be discomfort
if the CAR and CT do not progress to the Experimental simultaneously.
See Andrew Alston for additional details.

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

    Implementation report:
    https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-bgp-ct
 
    Implementation of CT:  Juniper, Freertg
    Implementation of CT-srv6: (TBD)

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.

  Reviews requested from PCE, Spring, and BESS before 2nd WG LC.
  Received reviews from PCE: CT updated based on feedback (missing link in IDR Mail)
  Received feedback from Spring chairs (Alvaro Retana)
    The following drafts were in the option queue:
      draft-hr-spring-intentaware-routing-using-color
      draft-salih-spring-srv6-inter-domain-sids-04 (ct-srv6)
 
  Nothing was received from BESS.
  RTG-DIR reviews: 2 early reviews - (-18) "has nits" 
  OPS-DIR reviews: 2 early reviews - (-19) "has nits"
  SEC-DIR reviews: 2 early reviews - (-19) 6 problems + 4 questions (must be resolved)
  TSV-DIR review:  1 early review requested - no response.
  IANA Early review: IANA early review of draft-ietf-idr-bgp-ct-27 IANA section.
 
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 requirement for formal review (MIB, Yang, Media type, and URI)
  A yang module for CT will be added to the list of Yang modules to create for BGP.

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 in the document

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 automated checking

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

Checks completed:
  1) Pre-Adoption by Jeff Haas and discussion among chairs 
  2) Careful Adoption review resulted in a list of issues that needed to be resolved:
      (https://wiki.ietf.org/group/idr/CAR-CTAdoption)
  3) Adoption call issues added to github for draft-ietf-idr-bgp-ct-27 
      (https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues)
  4) 1st WG LC -
      Prior to 1st WG LC: Shepherd verified that issues were addressed
                          and early Early Directorate reviews requested,
      1st WG LC: Shepherd report written
      (see https://wiki.ietf.org/group/idr/CT-WGLC and                     
      https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues)       
      Review provided by IDR Chair team: Jie Dong, Keyur Patel, and Jeff Haas.
 
  5) 2nd WG LC
      Prior to 2nd WG LC:
        a) Shepherd verified that issues raised in 1st WG LC were addressed.
        b) Review provided by IDR Chair team: Jie Dong, Keyur Patel, and Jeff Haas.
        c) IDR Chair team resolutions were made - via email and meetings of
          technical issues.
        d) Early reviews requested (RTG-DIR, OPS-DIR, SEC-DIR, and TSV-DIR)
          open reviews: resolution of SEC-DIR and lack of TSV-DIR
        d) Meeting with CAR and CT editor teams during 2nd WGLC
        e) two interims in 2024 - January 29 and February 26 - review status
    6) Post WG LC
        a) Shepherd reports with editorial nits [resolved]
        b) Shepherd report loaded into github as issues [Resolved]
        c) Review issues with document editors before -27 submission [Resolved] 
        b) IANA review of -27 requested. [pending]
        c) github issue loaded with Security Directorate review comments

    7)Final Checks
        a) Response from IANA review of -27
        b) Response from SEC-DIR resolution check
        c) final NITS check
        d) RFC9012 issues

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?  All items addressed, but these are the key points

  RTG-DIR and OPS-IDR review examines whether these new "intent-aware" (color)
  are able to be created and used. The early review cycles ended with "OK with NITs".
  The NITs have been address (see github for tracking of NITs). 

  The Transport area review (TSV-DIR) was only looking at whether the network
  was on the right path to allow intents to create "intent" (color) network-wide
  paths of a certain type.  Applications through transport layers are the ones to signal
  a particular intent and need.  The desired answer from TSV-DIR is "on the right track".
   
  SEC-DIR review of CT and CTv6 mentioned that these drafts look to
  BGP security solutions (BGPsec and Origin validation) to provide additional security
  without giving the details on the solutions. During an investigation of the BGPsec
  a few things turned up about BGPSec. The shepherd notes that RFC8374 points out that BGPsec
  (RFC8205) only included the AFI in the "hash" to resolve a problem (see
  sections 2.2.1 and 6.2.1).  Section 2.2.1 includes the AFI/SAFI in Figure 8,
  but may assume only IPv4 (AFI=1) and IPv6 (AFI=2).

  Due to this unclear text, both BGP intent-based solutions (CAR and CT)
  merely state that BGPsec and Origin Validation could be extended.  It is beyond the
  scope of these individual drafts to raise the wider issue of BGPsec applications
  for many new AFI/SAFIs. It is an an issues that needs addressing by the IDR WG.

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?

    Experimental draft.  Why? IDR cannot settle on a single solution for Intent-based (Color) routing. 
    The top 2 solutions are forwarded as experimental drafts to allow operational deployment to give feedback.

    Do all Datatracker state attributes correctly reflect this intent? Yes .
   
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.

Editors:
2nd WG LC -03
Kaliraj Vairavakkali (kaliraj@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/ZL7tOk3fgqeIRM5dfKfx_GbIh2w/

Natrajan Venkataraman (natv@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/eh3IdjyMjJVQSwOx2CD95iKg1-4/

CoAuthors:
Reshma Das (dreshma@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/Ei8WY3sVYAhnECr1w40Y8C5zQ-Y/

Israel Means (israel.means@att.com)
https://mailarchive.ietf.org/arch/msg/idr/iniOhZ1BknkBhe2l8DYL5aL_lGk/

Csaba Mates (ietf@nop.hu)
https://mailarchive.ietf.org/arch/msg/idr/NSxyfq98238jOIllMgIrBF54aeg/

Deepak J. Gowda (dgowda@extremenetworks.com) [2nd WG LC]
https://mailarchive.ietf.org/arch/msg/idr/FWf7jsy7mFJDiW3stAWeJ_DU0oU/

Contributors:
Balaji Rajagoplan (balajir@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/SfJQVDClw7y8vXYoG8wlLKRgyLQ/


Rajesh M (mrajesh@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/4T2BDGnaZUmtWUPjFVIOAFL-ZoI/

Chaitanya Yadlapalli (cy098d@att.com)
https://mailarchive.ietf.org/arch/msg/idr/M1c3trnvMiVn3_QQU9FqbkuvHA0/

Mazen Khaddam (mazen.khaddam@cox.com)
https://mailarchive.ietf.org/arch/msg/idr/lhBotT08JzICX-uPUfhMUSA7uzc/

Rafal Jan Szarecki (Google)
https://mailarchive.ietf.org/arch/msg/idr/r09fylzRRgssJqDoQnhy66qCr-g/

Xiaohu Xu (Captialonline) [from 1st WG LC]
https://mailarchive.ietf.org/arch/msg/idr/DBuobWpmj_ce0IOUWDTZU7m095E/
2nd WG LC
https://mailarchive.ietf.org/arch/msg/idr/Uh39xPb20FTsmORAjgRlce8bwfc/

Contributor for [-12] missing in [-27]
Gyan Mishra (gyan.s.mishra@verizon.com) - dropped as of [-11]
before 1st WG LC. Missing IPR statement.

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.

2 editors on front page.
All IPR statements good for -27 except for Xiahou Xu.
issue with Gyan Mishra - no longer contributor after -11

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

[pending] NITS - see github reference
(see https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/70)
    - 2 lines over 72 length, but it seems the tools.

-(2477): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding
-(2501): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
 
    Each of IDR chairs have walked through Normative and Informative references.
    [Pending - Asking for RTG-AD (John Scudder) to do early review on
    normative/non-normative references. ] 

    Note: draft-ietf-idr-bgp-ct-27 references an informative reference: 
    BGP-CT-UPDATE-PACKING-TEST] which is a document on the IETF IDR WG Github.
    Read access is allowed for all. 
    see: https://raw.githubusercontent.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/1a75d4d10d4df0f1fd7dcc041c2c868704b092c7/update-packing-test-results.txt

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 normative references are freely available and published RFCs.
    See comment above regarding 1 informative reference at IETF IDR WG github.;

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

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

    There are no normative references that are not at RFC level.
    Informative references are RFCs, drafts, or one github reference (see #15 above). 

19. Will publication of this document change the status of any existing RFCs? No
    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? not applicable. 
    If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.- not applicable.

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. yes, confirmed 

    Confirm that any referenced IANA registries have been clearly identified. Yes, confirmed. 
    Confirm that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]). yes, Confirmed.

    [pending] Due to a complexity, an early request to review IANA allocation has
    been sent. 

    New registries:
      Transitive Transport Class Extended Community Sub-Types Registry
      Non-Transitive Transport Class Extended Community Sub-Types Registry
      BGP CT Parameters

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.

  No IANA registries that require Designated Expert Review are listed in this draft.

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

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

Shepherd's final check list:
1) Check on Updates for RFC9012 - document in github
2) Print final copy of the shepherd write-up

Note for AD review: Please read SEC-DIR review and SEC-DIR as first step.


## Document History

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

The CT progression after adoption is tracked on both the IDR Wiki
and the IDR github repository: ietf-wg-idr/draft-ietf-idr-bgp-ct
https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues

Post 2nd WG LC Shepherd's review of -26.txt
https://mailarchive.ietf.org/arch/msg/idr/7PIQx2nE0Y4d-lR7bIpTPL_TMR0/

Summary of calls: (in reverse time order)
2nd WG LC: 2/16/2024 to 3/1/2024
https://mailarchive.ietf.org/arch/msg/idr/Ud2coGDvdXYy7x-SHPSK2Onwjx4/
Status: Consensus on publication of draft-ietf-idr-bgp-ct and draft-ietf-idr-bgp-ct-srv6
https://mailarchive.ietf.org/arch/msg/idr/oNY5gAcE21y1bke6tBzeb76uVo4/
https://mailarchive.ietf.org/arch/msg/idr/rJC4O726QqUoDEqFTffOF9EvX_U/

----
1st WG LC: draft-ietf-idr-bgp-ct-09.txt (6/26/2023 to 7/17/2023
https://mailarchive.ietf.org/arch/msg/idr/KYZbOsg2y4jcOfjV31pee5uhMjQ/
extension to 7/28: https://mailarchive.ietf.org/arch/msg/idr/Qr8GhdlEi8viaZxOCaWii3cA51s/
Extension to 8/01: https://mailarchive.ietf.org/arch/msg/idr/fC--NIU7VlyOjmNJwIcsXhXFvSk/
status: No consensus reached

The shepherd's write-up on this topic is available on the IDR wiki
https://wiki.ietf.org/e/en/group/idr/CT-WGLC

Email message notifying the WG of 1 WG LC Shepherd's report:
https://mailarchive.ietf.org/arch/msg/idr/klBUhMe9AsdflYhIYVEhSIps_lg/
---------
Adoption call results: (as part of status)
https://mailarchive.ietf.org/arch/msg/idr/0V6pBTQyCmh3t3h9cMqxZ3N0s7Q/

Adoption call: Time: 7/6/2022 to 7/27/2022 in 3 mail threads.
Part 1 of CAR/CT Adoption call (7/6 to 7/27): Informational Questions
​https://mailarchive.ietf.org/arch/msg/idr/FhoK04HsSy9tR7ioV7AD0Vv6Ir4/

Part 2 of CAR/CT Adoption call (7/6 to 7/27): Adoption call
​https://mailarchive.ietf.org/arch/msg/idr/AP_ClbZgpkX6CNy7TaZiU8SMD5w/

Part 3 of CAR/CT Adoption call (7/14 to 7/27) - Please note that Part 3 has a specific format for posting.
​https://mailarchive.ietf.org/arch/msg/idr/fTFYwF54WRHcj7PDt2t7sOQg6vo/

This adoption call was preceded by the following:
Email Discussion before IETF-113
​https://mailarchive.ietf.org/arch/msg/idr/e69NRd9i2aG0WUxFkShEfQHZsHo/

Note: The IDR chairs agree with Jeff Haas's (IDR Co-chair) summary posted on March 21, 2022,
that for route resolution and route origination/propagation,
BGP-CAR and BGP-CT are functionally identical but operationally different.

Presentations from IETF-108 to IETF-113
IDR interim on January 24, 2022
(​https://datatracker.ietf.org/meeting/interim-2022-idr-02/session/idr)


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


Rough Adoption decision:
The IDR chairs agree with Jeff Haas's (IDR Co-chair) summary posted on March 21, 2022,
that for route resolution and route origination/propagation,
BGP-CAR and BGP-CT are functionally identical but operationally different.

IDR WG could not come to a consensus on CAR vs. CT.  IDR Chairs elected to adopt
both CAR and CT drafts as experimental drafts.  Experience in the market
place will help determine which is better operationally.

Rough 1st WG LC of CAR/CT: The IDR WG LC for CAR and CT found the editors/authors/contributors
of CAR commenting on the CT draft (Just as CT authors commented on CAR draft).
In some ways, this lively debate helped find problems in the specifications.

2nd WG LC of CAR/CT: This WG LC did not have a lot of
CAR/CT editor discussions because the IDR Shepherding Chair had
a private discussion between editors prior to the 2nd WG LC.

During 2nd WG LC: Concern on Split of CT drafts into 3 drafts:
https://mailarchive.ietf.org/arch/msg/idr/29CYvVl0RnW0hJSU3il3p_cqt80/

Robert Raszuk raised a Concern regarding the splitting of the
CT draft into three parts (draft-ietf-idr-bgp-ct, draft-ietf-idr-bgp-ct-srv6,
and draft-ietf-idr-bgp-fwd-rr). Robert objected to the draft-ietf-idr-bgp-fwd-rr
being a WG draft.  The IDR chairs felt the text was in draft-ietf-idr-bgp-ct
since version -09, so Robert's concerns about being surprised as
WG draft was not justified.  However, it does point to the value of
the IDR chairs splitting this work out of the draft-ietf-idr-bgp-ct draft.

------
Dependencies on Spring:
a) Functional dependency - caused only theoretical scaling results
Due to a lack of adoption of the Spring Requirements document
draft-hr-spring-intentaware-routing-using-color-03, this WG
Shepherd allowed the scaling results to be theoretical without proof in CT.

b) Normative dependency on draft-ietf-idr-salih-spring-srv6-inter-domain-sids-04.
There is a normative dependency on an individual draft that is waiting for adoption. 
The Spring chairs have been notified that IDR draft-ietf-idr-bgp-ct-srv6
has normative dependencies on draft-ietf-idr-salih-spring-srv6-inter-domain-sids.

Dependencies with PCE
Dhruv Dhody reviewed the interactions with PCE drafts.
He sent comments to the CT authors. CT authors updated their drafts with changes. 

Dependencies with BESS:
BESS chairs were queried about reviewing the CAR and CT drafts.
No direct information was received.

-----
Alternatives for SRv6 without CAR or CT.
A third draft (draft-ietf-idr-cpr-00) was adopted as an informational draft.
This informational draft provides a way to encode intent for
SRv6 by operational practices rather than a new protocol.

## Directorate Reviews: (tracked by Datatracker) with comments from shepherd
RTG-DIR reviews:
Early Review of draft-ietf-idr-bgp-ct-09 (Med Boucadair)- status: has issues, excellent review
https://mailarchive.ietf.org/arch/msg/rtg-dir/aawFfvd29zERSBK4ydDDhxEQGRw
Early Review of draft-ietf-idr-bgp-ct-18 (Jonathan Hardwick) - status: has nits, good review
https://mailarchive.ietf.org/arch/msg/rtg-dir/FLGmC0-ufqPsZpH_LmgL2eWmWhY
Shepherd's follow-up: All NITs resolved by -30

OPS-DIR reviews:
Early Review of draft-ietf-idr-bgp-ct-12 (Bo Wu) - status: Has issues, Quality: good review, 4 issues mentioned
https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ct-12-opsdir-early-wu-2023-08-03/
Early Review of draft-ietf-idr-bgp-ct-18 (Bo Wu) - status: has nits, Quality: good review, 2nd review by the same reviewer as -12
https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ct-19-opsdir-early-wu-2024-01-05/
Shepherd's review: All Nits resolved by -30.

SEC-DIR Review:
Authors resolved in -30, except for NITs.   
email link: https://mailarchive.ietf.org/arch/msg/idr/fYulGchhf6oWPWhVWHxqx6WNupI/
github: assigned github issue #69
github link:https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/69
Status: Shepherd awaiting clarification email (sent 4/9))
Resolved by -32, but AD should look at the github issue #69 (closed issue)
https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/69


TSV-Review: (due date 3/6/2024) - On the Right Track.
https://mailarchive.ietf.org/arch/msg/tsv-art/hml_nr-BAbzXk7RnKCCy-EVXLuw/
TSV-DIR:
From the viewpoint of the transport area, there are two important points that
need to be discussed when considering such tunnels:
1)  MTU problems if the tunnel configurations differ, and
2) DSCP issues if DSPC is used to provide non-best effort services.
Status: -30 contained fixes for TSV-DIR, but no 2nd review.


Shepherd's comment for TSV-DIR: Please look at this draft from the viewpoint of having intent (color) aware customer traffic forwarded over a VPN overlay (tunnels) that forwarded over a set of intent (color) aware underlay of tunnels.  Please consider the problems with tunnels in your review of this text.

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

Andrew mentioned he received feedback that there would be discomfort
if the CAR and CT do not progress to the Experimental simultaneously.
See Andrew Alston for additional details.

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

    Implementation report:
    https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-bgp-ct
 
    Implementation of CT:  Juniper, Freertg
    Implementation of CT-srv6: (TBD)

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.

  Reviews requested from PCE, Spring, and BESS before 2nd WG LC.
  Received reviews from PCE: CT updated based on feedback (missing link in IDR Mail)
  Received feedback from Spring chairs (Alvaro Retana)
    The following drafts were in the option queue:
      draft-hr-spring-intentaware-routing-using-color
      draft-salih-spring-srv6-inter-domain-sids-04 (ct-srv6)
 
  Nothing was received from BESS.
  RTG-DIR reviews: 2 early reviews - (-18) "has nits" 
  OPS-DIR reviews: 2 early reviews - (-19) "has nits"
  SEC-DIR reviews: 2 early reviews - (-19) 6 problems + 4 questions (must be resolved)
  TSV-DIR review:  1 early review requested - no response.
  IANA Early review: IANA early review of draft-ietf-idr-bgp-ct-27 IANA section.
 
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 requirement for formal review (MIB, Yang, Media type, and URI)
  A yang module for CT will be added to the list of Yang modules to create for BGP.

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 in the document

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 automated checking

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

Checks completed:
  1) Pre-Adoption by Jeff Haas and discussion among chairs 
  2) Careful Adoption review resulted in a list of issues that needed to be resolved:
      (https://wiki.ietf.org/group/idr/CAR-CTAdoption)
  3) Adoption call issues added to github for draft-ietf-idr-bgp-ct-27 
      (https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues)
  4) 1st WG LC -
      Prior to 1st WG LC: Shepherd verified that issues were addressed
                          and early Early Directorate reviews requested,
      1st WG LC: Shepherd report written
      (see https://wiki.ietf.org/group/idr/CT-WGLC and                     
      https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues)       
      Review provided by IDR Chair team: Jie Dong, Keyur Patel, and Jeff Haas.
 
  5) 2nd WG LC
      Prior to 2nd WG LC:
        a) Shepherd verified that issues raised in 1st WG LC were addressed.
        b) Review provided by IDR Chair team: Jie Dong, Keyur Patel, and Jeff Haas.
        c) IDR Chair team resolutions were made - via email and meetings of
          technical issues.
        d) Early reviews requested (RTG-DIR, OPS-DIR, SEC-DIR, and TSV-DIR)
          open reviews: resolution of SEC-DIR and lack of TSV-DIR
        d) Meeting with CAR and CT editor teams during 2nd WGLC
        e) two interims in 2024 - January 29 and February 26 - review status
    6) Post WG LC
        a) Shepherd reports with editorial nits [resolved]
        b) Shepherd report loaded into github as issues [Resolved]
        c) Review issues with document editors before -27 submission [Resolved] 
        b) IANA review of -27 requested. [pending]
        c) github issue loaded with Security Directorate review comments

    7) Early Reviews by RTG-DIR, OPS-DIR, SEC-DIR, and TSV-DIR.
     
    8) NITS run on draft-ietf-idr-bgp-ct
        a) Line length problem - this is tools error.
        b) Additional RFC (RFC6811 and RFC9256) without links
              RFC6811 - relates to the SEC-DIR review. It would be good
                        to discuss the security review with the AD before adding
                        a pointer to this in the text. 
            RFC9256 - Segment Routing Policy Architecture
              Again, I agree with the authors that RFC9256 should be
              mentioned. It would be helpful to know if the AD wishes this
              reference in a particular place.

            out-of-date draft: draft-ietf-pce-pcep-color-02
              This will be updated in the next revision. 


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?  All items addressed, but these are the key points

  RTG-DIR and OPS-IDR review examines whether these new "intent-aware" (color)
  are able to be created and used. The early review cycles ended with "OK with NITs".
  The NITs have been address (see github for tracking of NITs). 

  The Transport area review (TSV-DIR) was only looking at whether the network
  was on the right path to allow intents to create "intent" (color) network-wide
  paths of a certain type.  Applications through transport layers are the ones to signal
  a particular intent and need.  The desired answer from TSV-DIR is "on the right track".
   
  SEC-DIR review of CT and CTv6 mentioned that these drafts look to
  BGP security solutions (BGPsec and Origin validation) to provide additional security
  without giving the details on the solutions. During an investigation of the BGPsec
  a few things turned up about BGPSec. The shepherd notes that RFC8374 points out that BGPsec
  (RFC8205) only included the AFI in the "hash" to resolve a problem (see
  sections 2.2.1 and 6.2.1).  Section 2.2.1 includes the AFI/SAFI in Figure 8,
  but may assume only IPv4 (AFI=1) and IPv6 (AFI=2).

  Due to this unclear text, both BGP intent-based solutions (CAR and CT)
  merely state that BGPsec and Origin Validation could be extended.  It is beyond the
  scope of these individual drafts to raise the wider issue of BGPsec applications
  for many new AFI/SAFIs. It is an an issues that needs addressing by the IDR WG.

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?

    Experimental draft.  Why? IDR cannot settle on a single solution for Intent-based (Color) routing. 
    The top 2 solutions are forwarded as experimental drafts to allow operational deployment to give feedback.

    Do all Datatracker state attributes correctly reflect this intent? Yes .
   
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.

Editors:
2nd WG LC -03
Kaliraj Vairavakkali (kaliraj@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/ZL7tOk3fgqeIRM5dfKfx_GbIh2w/

Natrajan Venkataraman (natv@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/eh3IdjyMjJVQSwOx2CD95iKg1-4/

CoAuthors:
Reshma Das (dreshma@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/Ei8WY3sVYAhnECr1w40Y8C5zQ-Y/

Israel Means (israel.means@att.com)
https://mailarchive.ietf.org/arch/msg/idr/iniOhZ1BknkBhe2l8DYL5aL_lGk/

Csaba Mates (ietf@nop.hu)
https://mailarchive.ietf.org/arch/msg/idr/NSxyfq98238jOIllMgIrBF54aeg/

Deepak J. Gowda (dgowda@extremenetworks.com) [2nd WG LC]
https://mailarchive.ietf.org/arch/msg/idr/FWf7jsy7mFJDiW3stAWeJ_DU0oU/

Contributors:
Balaji Rajagoplan (balajir@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/SfJQVDClw7y8vXYoG8wlLKRgyLQ/


Rajesh M (mrajesh@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/4T2BDGnaZUmtWUPjFVIOAFL-ZoI/

Chaitanya Yadlapalli (cy098d@att.com)
https://mailarchive.ietf.org/arch/msg/idr/M1c3trnvMiVn3_QQU9FqbkuvHA0/

Mazen Khaddam (mazen.khaddam@cox.com)
https://mailarchive.ietf.org/arch/msg/idr/lhBotT08JzICX-uPUfhMUSA7uzc/

Rafal Jan Szarecki (Google)
https://mailarchive.ietf.org/arch/msg/idr/r09fylzRRgssJqDoQnhy66qCr-g/

Xiaohu Xu (Captialonline) [from 1st WG LC]
https://mailarchive.ietf.org/arch/msg/idr/DBuobWpmj_ce0IOUWDTZU7m095E/
2nd WG LC
https://mailarchive.ietf.org/arch/msg/idr/Uh39xPb20FTsmORAjgRlce8bwfc/

Contributor for [-12] missing in [-27]
Gyan Mishra (gyan.s.mishra@verizon.com) - dropped as of [-11]
before 1st WG LC. Missing IPR statement.

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.

2 editors on front page.
All IPR statements good for -27 except for Xiahou Xu.
issue with Gyan Mishra - no longer contributor after -11

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

[pending] NITS - see github reference
(see https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/70)
    - 2 lines over 72 length, but it seems the tools.

-(2477): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding
-(2501): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
 
    Each of IDR chairs have walked through Normative and Informative references.
    [Pending - Asking for RTG-AD (John Scudder) to do early review on
    normative/non-normative references. ] 

    Note: draft-ietf-idr-bgp-ct-27 references an informative reference: 
    BGP-CT-UPDATE-PACKING-TEST] which is a document on the IETF IDR WG Github.
    Read access is allowed for all. 
    see: https://raw.githubusercontent.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/1a75d4d10d4df0f1fd7dcc041c2c868704b092c7/update-packing-test-results.txt

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 normative references are freely available and published RFCs.
    See comment above regarding 1 informative reference at IETF IDR WG github.;

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

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

    There are no normative references that are not at RFC level.
    Informative references are RFCs, drafts, or one github reference (see #15 above). 

19. Will publication of this document change the status of any existing RFCs? No
    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? not applicable. 
    If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.- not applicable.

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. yes, confirmed 

    Confirm that any referenced IANA registries have been clearly identified. Yes, confirmed. 
    Confirm that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]). yes, Confirmed.

    [pending] Due to a complexity, an early request to review IANA allocation has
    been sent. 

    New registries:
      Transitive Transport Class Extended Community Sub-Types Registry
      Non-Transitive Transport Class Extended Community Sub-Types Registry
      BGP CT Parameters

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.

  No IANA registries that require Designated Expert Review are listed in this draft.

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

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

Need information:
1) Check
2) Check on Updates for RFC9012 - document in github
3) Print final copy of the shepherd write-up

## Document History

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

The CT progression after adoption is tracked on both the IDR Wiki
and the IDR github repository: ietf-wg-idr/draft-ietf-idr-bgp-ct
https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues

Post 2nd WG LC Shepherd's review of -26.txt
https://mailarchive.ietf.org/arch/msg/idr/7PIQx2nE0Y4d-lR7bIpTPL_TMR0/

Summary of calls: (in reverse time order)
2nd WG LC: 2/16/2024 to 3/1/2024
https://mailarchive.ietf.org/arch/msg/idr/Ud2coGDvdXYy7x-SHPSK2Onwjx4/
Status: Consensus on publication of draft-ietf-idr-bgp-ct and draft-ietf-idr-bgp-ct-srv6
https://mailarchive.ietf.org/arch/msg/idr/oNY5gAcE21y1bke6tBzeb76uVo4/
https://mailarchive.ietf.org/arch/msg/idr/rJC4O726QqUoDEqFTffOF9EvX_U/

----
1st WG LC: draft-ietf-idr-bgp-ct-09.txt (6/26/2023 to 7/17/2023
https://mailarchive.ietf.org/arch/msg/idr/KYZbOsg2y4jcOfjV31pee5uhMjQ/
extension to 7/28: https://mailarchive.ietf.org/arch/msg/idr/Qr8GhdlEi8viaZxOCaWii3cA51s/
Extension to 8/01: https://mailarchive.ietf.org/arch/msg/idr/fC--NIU7VlyOjmNJwIcsXhXFvSk/
status: No consensus reached

The shepherd's write-up on this topic is available on the IDR wiki
https://wiki.ietf.org/e/en/group/idr/CT-WGLC

Email message notifying the WG of 1 WG LC Shepherd's report:
https://mailarchive.ietf.org/arch/msg/idr/klBUhMe9AsdflYhIYVEhSIps_lg/
---------
Adoption call results: (as part of status)
https://mailarchive.ietf.org/arch/msg/idr/0V6pBTQyCmh3t3h9cMqxZ3N0s7Q/

Adoption call: Time: 7/6/2022 to 7/27/2022 in 3 mail threads.
Part 1 of CAR/CT Adoption call (7/6 to 7/27): Informational Questions
​https://mailarchive.ietf.org/arch/msg/idr/FhoK04HsSy9tR7ioV7AD0Vv6Ir4/

Part 2 of CAR/CT Adoption call (7/6 to 7/27): Adoption call
​https://mailarchive.ietf.org/arch/msg/idr/AP_ClbZgpkX6CNy7TaZiU8SMD5w/

Part 3 of CAR/CT Adoption call (7/14 to 7/27) - Please note that Part 3 has a specific format for posting.
​https://mailarchive.ietf.org/arch/msg/idr/fTFYwF54WRHcj7PDt2t7sOQg6vo/

This adoption call was preceded by the following:
Email Discussion before IETF-113
​https://mailarchive.ietf.org/arch/msg/idr/e69NRd9i2aG0WUxFkShEfQHZsHo/

Note: The IDR chairs agree with Jeff Haas's (IDR Co-chair) summary posted on March 21, 2022,
that for route resolution and route origination/propagation,
BGP-CAR and BGP-CT are functionally identical but operationally different.

Presentations from IETF-108 to IETF-113
IDR interim on January 24, 2022
(​https://datatracker.ietf.org/meeting/interim-2022-idr-02/session/idr)


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


Rough Adoption decision:
The IDR chairs agree with Jeff Haas's (IDR Co-chair) summary posted on March 21, 2022,
that for route resolution and route origination/propagation,
BGP-CAR and BGP-CT are functionally identical but operationally different.

IDR WG could not come to a consensus on CAR vs. CT.  IDR Chairs elected to adopt
both CAR and CT drafts as experimental drafts.  Experience in the market
place will help determine which is better operationally.

Rough 1st WG LC of CAR/CT: The IDR WG LC for CAR and CT found the editors/authors/contributors
of CAR commenting on the CT draft (Just as CT authors commented on CAR draft).
In some ways, this lively debate helped find problems in the specifications.

2nd WG LC of CAR/CT: This WG LC did not have a lot of
CAR/CT editor discussions because the IDR Shepherding Chair had
a private discussion between editors prior to the 2nd WG LC.

During 2nd WG LC: Concern on Split of CT drafts into 3 drafts:
https://mailarchive.ietf.org/arch/msg/idr/29CYvVl0RnW0hJSU3il3p_cqt80/

Robert Raszuk raised a Concern regarding the splitting of the
CT draft into three parts (draft-ietf-idr-bgp-ct, draft-ietf-idr-bgp-ct-srv6,
and draft-ietf-idr-bgp-fwd-rr). Robert objected to the draft-ietf-idr-bgp-fwd-rr
being a WG draft.  The IDR chairs felt the text was in draft-ietf-idr-bgp-ct
since version -09, so Robert's concerns about being surprised as
WG draft was not justified.  However, it does point to the value of
the IDR chairs splitting this work out of the draft-ietf-idr-bgp-ct draft.

------
Dependencies on Spring:
a) Functional dependency - caused only theoretical scaling results
Due to a lack of adoption of the Spring Requirements document
draft-hr-spring-intentaware-routing-using-color-03, this WG
Shepherd allowed the scaling results to be theoretical without proof in CT.

b) Normative dependency on draft-ietf-idr-salih-spring-srv6-inter-domain-sids-04.
There is a normative dependency on an individual draft that is waiting for adoption. 
The Spring chairs have been notified that IDR draft-ietf-idr-bgp-ct-srv6
has normative dependencies on draft-ietf-idr-salih-spring-srv6-inter-domain-sids.

Dependencies with PCE
Dhruv Dhody reviewed the interactions with PCE drafts.
He sent comments to the CT authors. CT authors updated their drafts with changes. 

Dependencies with BESS:
BESS chairs were queried about reviewing the CAR and CT drafts.
No direct information was received.

-----
Alternatives for SRv6 without CAR or CT.
A third draft (draft-ietf-idr-cpr-00) was adopted as an informational draft.
This informational draft provides a way to encode intent for
SRv6 by operational practices rather than a new protocol.

## Directorate Reviews: (tracked by Datatracker) with comments from shepherd
RTG-DIR reviews:
Early Review of draft-ietf-idr-bgp-ct-09 (Med Boucadair)- status: has issues, excellent review
https://mailarchive.ietf.org/arch/msg/rtg-dir/aawFfvd29zERSBK4ydDDhxEQGRw
Early Review of draft-ietf-idr-bgp-ct-18 (Jonathan Hardwick) - status: has nits, good review
https://mailarchive.ietf.org/arch/msg/rtg-dir/FLGmC0-ufqPsZpH_LmgL2eWmWhY
Shepherd's follow-up: All NITs resolved by -30

OPS-DIR reviews:
Early Review of draft-ietf-idr-bgp-ct-12 (Bo Wu) - status: Has issues, Quality: good review, 4 issues mentioned
https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ct-12-opsdir-early-wu-2023-08-03/
Early Review of draft-ietf-idr-bgp-ct-18 (Bo Wu) - status: has nits, Quality: good review, 2nd review by the same reviewer as -12
https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ct-19-opsdir-early-wu-2024-01-05/
Shepherd's review: All Nits resolved by -30.

SEC-DIR Review:
Authors resolved in -30, except for NIT
email link: https://mailarchive.ietf.org/arch/msg/idr/fYulGchhf6oWPWhVWHxqx6WNupI/
github: assigned github issue #69
github link:https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/69
Status: Shepherd awaiting clarification email (sent 4/9))
Resolved by -32, but AD should look at the github issue #69 (closed issue)
https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/69


TSV-Review: (due date 3/6/2024) - On the Right Track.
https://mailarchive.ietf.org/arch/msg/tsv-art/hml_nr-BAbzXk7RnKCCy-EVXLuw/
TSV-DIR:
From the viewpoint of the transport area, there are two important points that
need to be discussed when considering such tunnels:
1)  MTU problems if the tunnel configurations differ, and
2) DSCP issues if DSPC is used to provide non-best effort services.
Status: -30 contained fixes for TSV-DIR, but no 2nd review.


Shepherd's comment for TSV-DIR: Please look at this draft from the viewpoint of having intent (color) aware customer traffic forwarded over a VPN overlay (tunnels) that forwarded over a set of intent (color) aware underlay of tunnels.  Please consider the problems with tunnels in your review of this text.

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

Andrew mentioned he received feedback that there would be discomfort
if the CAR and CT do not progress to the Experimental simultaneously.
See Andrew Alston for additional details.

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

    Implementation report:
    https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-bgp-ct
 
    Implementation of CT:  Juniper, Freertg
    Implementation of CT-srv6: (TBD)

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.

  Reviews requested from PCE, Spring, and BESS before 2nd WG LC.
  Received reviews from PCE: CT updated based on feedback (missing link in IDR Mail)
  Received feedback from Spring chairs (Alvaro Retana)
    The following drafts were in the option queue:
      draft-hr-spring-intentaware-routing-using-color
      draft-salih-spring-srv6-inter-domain-sids-04 (ct-srv6)
 
  Nothing was received from BESS.
  RTG-DIR reviews: 2 early reviews - (-18) "has nits" 
  OPS-DIR reviews: 2 early reviews - (-19) "has nits"
  SEC-DIR reviews: 2 early reviews - (-19) 6 problems + 4 questions (must be resolved)
  TSV-DIR review:  1 early review requested - no response.
  IANA Early review: IANA early review of draft-ietf-idr-bgp-ct-27 IANA section.
 
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 requirement for formal review (MIB, Yang, Media type, and URI)
  A yang module for CT will be added to the list of Yang modules to create for BGP.

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 in the document

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 automated checking

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

Checks completed:
  1) Pre-Adoption by Jeff Haas and discussion among chairs 
  2) Careful Adoption review resulted in a list of issues that needed to be resolved:
      (https://wiki.ietf.org/group/idr/CAR-CTAdoption)
  3) Adoption call issues added to github for draft-ietf-idr-bgp-ct-27 
      (https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues)
  4) 1st WG LC -
      Prior to 1st WG LC: Shepherd verified that issues were addressed
                          and early Early Directorate reviews requested,
      1st WG LC: Shepherd report written
      (see https://wiki.ietf.org/group/idr/CT-WGLC and                     
      https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues)       
      Review provided by IDR Chair team: Jie Dong, Keyur Patel, and Jeff Haas.
 
  5) 2nd WG LC
      Prior to 2nd WG LC:
        a) Shepherd verified that issues raised in 1st WG LC were addressed.
        b) Review provided by IDR Chair team: Jie Dong, Keyur Patel, and Jeff Haas.
        c) IDR Chair team resolutions were made - via email and meetings of
          technical issues.
        d) Early reviews requested (RTG-DIR, OPS-DIR, SEC-DIR, and TSV-DIR)
          open reviews: resolution of SEC-DIR and lack of TSV-DIR
        d) Meeting with CAR and CT editor teams during 2nd WGLC
        e) two interims in 2024 - January 29 and February 26 - review status
    6) Post WG LC
        a) Shepherd reports with editorial nits [resolved]
        b) Shepherd report loaded into github as issues [Resolved]
        c) Review issues with document editors before -27 submission [Resolved] 
        b) IANA review of -27 requested. [pending]
        c) github issue loaded with Security Directorate review comments

    7) Current waiting status:
        a) Response from IANA review of -27
        b) Response from SEC-DIR resolution check
        c) final NITS check

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?  All items addressed, but these are the key points

  RTG-DIR and OPS-IDR review examines whether these new "intent-aware" (color)
  are able to be created and used. The early review cycles ended with "OK with NITs".
  The NITs have been address (see github for tracking of NITs). 

  The Transport area review (TSV-DIR) was only looking at whether the network
  was on the right path to allow intents to create "intent" (color) network-wide
  paths of a certain type.  Applications through transport layers are the ones to signal
  a particular intent and need.  The desired answer from TSV-DIR is "on the right track".
   
  SEC-DIR review of CT and CTv6 mentioned that these drafts look to
  BGP security solutions (BGPsec and Origin validation) to provide additional security
  without giving the details on the solutions. During an investigation of the BGPsec
  a few things turned up about BGPSec. The shepherd notes that RFC8374 points out that BGPsec
  (RFC8205) only included the AFI in the "hash" to resolve a problem (see
  sections 2.2.1 and 6.2.1).  Section 2.2.1 includes the AFI/SAFI in Figure 8,
  but may assume only IPv4 (AFI=1) and IPv6 (AFI=2).

  Due to this unclear text, both BGP intent-based solutions (CAR and CT)
  merely state that BGPsec and Origin Validation could be extended.  It is beyond the
  scope of these individual drafts to raise the wider issue of BGPsec applications
  for many new AFI/SAFIs. It is an an issues that needs addressing by the IDR WG.

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?

    Experimental draft.  Why? IDR cannot settle on a single solution for Intent-based (Color) routing. 
    The top 2 solutions are forwarded as experimental drafts to allow operational deployment to give feedback.

    Do all Datatracker state attributes correctly reflect this intent? Yes .
   
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.

Editors:
2nd WG LC -03
Kaliraj Vairavakkali (kaliraj@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/ZL7tOk3fgqeIRM5dfKfx_GbIh2w/

Natrajan Venkataraman (natv@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/eh3IdjyMjJVQSwOx2CD95iKg1-4/

CoAuthors:
Reshma Das (dreshma@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/Ei8WY3sVYAhnECr1w40Y8C5zQ-Y/

Israel Means (israel.means@att.com)
https://mailarchive.ietf.org/arch/msg/idr/iniOhZ1BknkBhe2l8DYL5aL_lGk/

Csaba Mates (ietf@nop.hu)
https://mailarchive.ietf.org/arch/msg/idr/NSxyfq98238jOIllMgIrBF54aeg/

Deepak J. Gowda (dgowda@extremenetworks.com) [2nd WG LC]
https://mailarchive.ietf.org/arch/msg/idr/FWf7jsy7mFJDiW3stAWeJ_DU0oU/

Contributors:
Balaji Rajagoplan (balajir@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/SfJQVDClw7y8vXYoG8wlLKRgyLQ/


Rajesh M (mrajesh@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/4T2BDGnaZUmtWUPjFVIOAFL-ZoI/

Chaitanya Yadlapalli (cy098d@att.com)
https://mailarchive.ietf.org/arch/msg/idr/M1c3trnvMiVn3_QQU9FqbkuvHA0/

Mazen Khaddam (mazen.khaddam@cox.com)
https://mailarchive.ietf.org/arch/msg/idr/lhBotT08JzICX-uPUfhMUSA7uzc/

Rafal Jan Szarecki (Google)
https://mailarchive.ietf.org/arch/msg/idr/r09fylzRRgssJqDoQnhy66qCr-g/

Xiaohu Xu (Captialonline) [from 1st WG LC]
https://mailarchive.ietf.org/arch/msg/idr/DBuobWpmj_ce0IOUWDTZU7m095E/
2nd WG LC
https://mailarchive.ietf.org/arch/msg/idr/Uh39xPb20FTsmORAjgRlce8bwfc/

Contributor for [-12] missing in [-27]
Gyan Mishra (gyan.s.mishra@verizon.com) - dropped as of [-11]
before 1st WG LC. Missing IPR statement.

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.

2 editors on front page.
All IPR statements good for -27 except for Xiahou Xu.
issue with Gyan Mishra - no longer contributor after -11

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

[pending] NITS - see github reference
(see https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/70)
    - 2 lines over 72 length, but it seems the tools.

-(2477): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding
-(2501): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
 
    Each of IDR chairs have walked through Normative and Informative references.
    [Pending - Asking for RTG-AD (John Scudder) to do early review on
    normative/non-normative references. ] 

    Note: draft-ietf-idr-bgp-ct-27 references an informative reference: 
    BGP-CT-UPDATE-PACKING-TEST] which is a document on the IETF IDR WG Github.
    Read access is allowed for all. 
    see: https://raw.githubusercontent.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/1a75d4d10d4df0f1fd7dcc041c2c868704b092c7/update-packing-test-results.txt

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 normative references are freely available and published RFCs.
    See comment above regarding 1 informative reference at IETF IDR WG github.;

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

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

    There are no normative references that are not at RFC level.
    Informative references are RFCs, drafts, or one github reference (see #15 above). 

19. Will publication of this document change the status of any existing RFCs? No
    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? not applicable. 
    If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.- not applicable.

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. yes, confirmed 

    Confirm that any referenced IANA registries have been clearly identified. Yes, confirmed. 
    Confirm that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]). yes, Confirmed.

    [pending] Due to a complexity, an early request to review IANA allocation has
    been sent. 

    New registries:
      Transitive Transport Class Extended Community Sub-Types Registry
      Non-Transitive Transport Class Extended Community Sub-Types Registry
      BGP CT Parameters

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.

  No IANA registries that require Designated Expert Review are listed in this draft.

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

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

Need information:
1) Update github issues - SEC-DIR, NITS,
2) Check on Updates for RFC9012 - document in github
3) Print final copy of the shepherd write-up

## Document History

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

The CT progression after adoption is tracked on both the IDR Wiki
and the IDR github repository: ietf-wg-idr/draft-ietf-idr-bgp-ct
https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues

Post 2nd WG LC Shepherd's review of -26.txt
https://mailarchive.ietf.org/arch/msg/idr/7PIQx2nE0Y4d-lR7bIpTPL_TMR0/

Summary of calls: (in reverse time order)
2nd WG LC: 2/16/2024 to 3/1/2024
https://mailarchive.ietf.org/arch/msg/idr/Ud2coGDvdXYy7x-SHPSK2Onwjx4/
Status: Consensus on publication of draft-ietf-idr-bgp-ct and draft-ietf-idr-bgp-ct-srv6
https://mailarchive.ietf.org/arch/msg/idr/oNY5gAcE21y1bke6tBzeb76uVo4/
https://mailarchive.ietf.org/arch/msg/idr/rJC4O726QqUoDEqFTffOF9EvX_U/

----
1st WG LC: draft-ietf-idr-bgp-ct-09.txt (6/26/2023 to 7/17/2023
https://mailarchive.ietf.org/arch/msg/idr/KYZbOsg2y4jcOfjV31pee5uhMjQ/
extension to 7/28: https://mailarchive.ietf.org/arch/msg/idr/Qr8GhdlEi8viaZxOCaWii3cA51s/
Extension to 8/01: https://mailarchive.ietf.org/arch/msg/idr/fC--NIU7VlyOjmNJwIcsXhXFvSk/
status: No consensus reached

The shepherd's write-up on this topic is available on the IDR wiki
https://wiki.ietf.org/e/en/group/idr/CT-WGLC

Email message notifying the WG of 1 WG LC Shepherd's report:
https://mailarchive.ietf.org/arch/msg/idr/klBUhMe9AsdflYhIYVEhSIps_lg/
---------
Adoption call results: (as part of status)
https://mailarchive.ietf.org/arch/msg/idr/0V6pBTQyCmh3t3h9cMqxZ3N0s7Q/

Adoption call: Time: 7/6/2022 to 7/27/2022 in 3 mail threads.
Part 1 of CAR/CT Adoption call (7/6 to 7/27): Informational Questions
​https://mailarchive.ietf.org/arch/msg/idr/FhoK04HsSy9tR7ioV7AD0Vv6Ir4/

Part 2 of CAR/CT Adoption call (7/6 to 7/27): Adoption call
​https://mailarchive.ietf.org/arch/msg/idr/AP_ClbZgpkX6CNy7TaZiU8SMD5w/

Part 3 of CAR/CT Adoption call (7/14 to 7/27) - Please note that Part 3 has a specific format for posting.
​https://mailarchive.ietf.org/arch/msg/idr/fTFYwF54WRHcj7PDt2t7sOQg6vo/

This adoption call was preceded by the following:
Email Discussion before IETF-113
​https://mailarchive.ietf.org/arch/msg/idr/e69NRd9i2aG0WUxFkShEfQHZsHo/

Note: The IDR chairs agree with Jeff Haas's (IDR Co-chair) summary posted on March 21, 2022,
that for route resolution and route origination/propagation,
BGP-CAR and BGP-CT are functionally identical but operationally different.

Presentations from IETF-108 to IETF-113
IDR interim on January 24, 2022
(​https://datatracker.ietf.org/meeting/interim-2022-idr-02/session/idr)


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


Rough Adoption decision:
The IDR chairs agree with Jeff Haas's (IDR Co-chair) summary posted on March 21, 2022,
that for route resolution and route origination/propagation,
BGP-CAR and BGP-CT are functionally identical but operationally different.

IDR WG could not come to a consensus on CAR vs. CT.  IDR Chairs elected to adopt
both CAR and CT drafts as experimental drafts.  Experience in the market
place will help determine which is better operationally.

Rough 1st WG LC of CAR/CT: The IDR WG LC for CAR and CT found the editors/authors/contributors
of CAR commenting on the CT draft (Just as CT authors commented on CAR draft).
In some ways, this lively debate helped find problems in the specifications.

2nd WG LC of CAR/CT: This WG LC did not have a lot of
CAR/CT editor discussions because the IDR Shepherding Chair had
a private discussion between editors prior to the 2nd WG LC.

During 2nd WG LC: Concern on Split of CT drafts into 3 drafts:
https://mailarchive.ietf.org/arch/msg/idr/29CYvVl0RnW0hJSU3il3p_cqt80/

Robert Raszuk raised a Concern regarding the splitting of the
CT draft into three parts (draft-ietf-idr-bgp-ct, draft-ietf-idr-bgp-ct-srv6,
and draft-ietf-idr-bgp-fwd-rr). Robert objected to the draft-ietf-idr-bgp-fwd-rr
being a WG draft.  The IDR chairs felt the text was in draft-ietf-idr-bgp-ct
since version -09, so Robert's concerns about being surprised as
WG draft was not justified.  However, it does point to the value of
the IDR chairs splitting this work out of the draft-ietf-idr-bgp-ct draft.

------
Dependencies on Spring:
a) Functional dependency - caused only theoretical scaling results
Due to a lack of adoption of the Spring Requirements document
draft-hr-spring-intentaware-routing-using-color-03, this WG
Shepherd allowed the scaling results to be theoretical without proof in CT.

b) Normative dependency on draft-ietf-idr-salih-spring-srv6-inter-domain-sids-04.
There is a normative dependency on an individual draft that is waiting for adoption. 
The Spring chairs have been notified that IDR draft-ietf-idr-bgp-ct-srv6
has normative dependencies on draft-ietf-idr-salih-spring-srv6-inter-domain-sids.

Dependencies with PCE
Dhruv Dhody reviewed the interactions with PCE drafts.
He sent comments to the CT authors. CT authors updated their drafts with changes. 

Dependencies with BESS:
BESS chairs were queried about reviewing the CAR and CT drafts.
No direct information was received.

-----
Alternatives for SRv6 without CAR or CT.
A third draft (draft-ietf-idr-cpr-00) was adopted as an informational draft.
This informational draft provides a way to encode intent for
SRv6 by operational practices rather than a new protocol.

## Directorate Reviews: (tracked by Datatracker) with comments from shepherd
RTG-DIR reviews:
Early Review of draft-ietf-idr-bgp-ct-09 (Med Boucadair)- status: has issues, excellent review
https://mailarchive.ietf.org/arch/msg/rtg-dir/aawFfvd29zERSBK4ydDDhxEQGRw
Early Review of draft-ietf-idr-bgp-ct-18 (Jonathan Hardwick) - status: has nits, good review
https://mailarchive.ietf.org/arch/msg/rtg-dir/FLGmC0-ufqPsZpH_LmgL2eWmWhY

OPS-DIR reviews:
Early Review of draft-ietf-idr-bgp-ct-12 (Bo Wu) - status: Has issues, Quality: good review, 4 issues mentioned
https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ct-12-opsdir-early-wu-2023-08-03/
Early Review of draft-ietf-idr-bgp-ct-18 (Bo Wu) - status: has nits, Quality: good review, 2nd review by the same reviewer as -12
https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ct-19-opsdir-early-wu-2024-01-05/

SEC-DIR Review:

Authors resolved in -30, except for NIT
email link: https://mailarchive.ietf.org/arch/msg/idr/fYulGchhf6oWPWhVWHxqx6WNupI/
github: assigned github issue #69
github link:https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/69
Status: Shepherd awaiting clarification email (sent 4/9), but no response as of 4/17.

TSV-Review: (due date 3/6/2024) - On the Right Track.
https://mailarchive.ietf.org/arch/msg/tsv-art/hml_nr-BAbzXk7RnKCCy-EVXLuw/
TSV-DIR:
From the viewpoint of the transport area, there are two important points that
need to be discussed when considering such tunnels: - MTU problems if the
tunnel configurations differ - DSCP issues if DSPC is used to provide non-best
effort services.
Status: -30 contained fixes for TSV-DIR, but no 2nd review.  (change on 3/18).

Shepherd's comment for TSV-DIR: Please look at this draft from the viewpoint of having intent (color) aware customer traffic forwarded over a VPN overlay (tunnels) that forwarded over a set of intent (color) aware underlay of tunnels.  Please consider the problems with tunnels in your review of this text.

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

Andrew mentioned he received feedback that there would be discomfort
if the CAR and CT do not progress to the Experimental simultaneously.
See Andrew Alston for additional details.

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

    Implementation report:
    https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-bgp-ct
 
    Implementation of CT:  Juniper, Freertg
    Implementation of CT-srv6: (TBD)

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.

  Reviews requested from PCE, Spring, and BESS before 2nd WG LC.
  Received reviews from PCE: CT updated based on feedback (missing link in IDR Mail)
  Received feedback from Spring chairs (Alvaro Retana)
    The following drafts were in the option queue:
      draft-hr-spring-intentaware-routing-using-color
      draft-salih-spring-srv6-inter-domain-sids-04 (ct-srv6)
 
  Nothing was received from BESS.
  RTG-DIR reviews: 2 early reviews - (-18) "has nits" 
  OPS-DIR reviews: 2 early reviews - (-19) "has nits"
  SEC-DIR reviews: 2 early reviews - (-19) 6 problems + 4 questions (must be resolved)
  TSV-DIR review:  1 early review requested - no response.
  IANA Early review: IANA early review of draft-ietf-idr-bgp-ct-27 IANA section.
 
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 requirement for formal review (MIB, Yang, Media type, and URI)
  A yang module for CT will be added to the list of Yang modules to create for BGP.

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 in the document

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 automated checking

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

Checks completed:
  1) Pre-Adoption by Jeff Haas and discussion among chairs 
  2) Careful Adoption review resulted in a list of issues that needed to be resolved:
      (https://wiki.ietf.org/group/idr/CAR-CTAdoption)
  3) Adoption call issues added to github for draft-ietf-idr-bgp-ct-27 
      (https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues)
  4) 1st WG LC -
      Prior to 1st WG LC: Shepherd verified that issues were addressed
                          and early Early Directorate reviews requested,
      1st WG LC: Shepherd report written
      (see https://wiki.ietf.org/group/idr/CT-WGLC and                     
      https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues)       
      Review provided by IDR Chair team: Jie Dong, Keyur Patel, and Jeff Haas.
 
  5) 2nd WG LC
      Prior to 2nd WG LC:
        a) Shepherd verified that issues raised in 1st WG LC were addressed.
        b) Review provided by IDR Chair team: Jie Dong, Keyur Patel, and Jeff Haas.
        c) IDR Chair team resolutions were made - via email and meetings of
          technical issues.
        d) Early reviews requested (RTG-DIR, OPS-DIR, SEC-DIR, and TSV-DIR)
          open reviews: resolution of SEC-DIR and lack of TSV-DIR
        d) Meeting with CAR and CT editor teams during 2nd WGLC
        e) two interims in 2024 - January 29 and February 26 - review status
    6) Post WG LC
        a) Shepherd reports with editorial nits [resolved]
        b) Shepherd report loaded into github as issues [Resolved]
        c) Review issues with document editors before -27 submission [Resolved] 
        b) IANA review of -27 requested. [pending]
        c) github issue loaded with Security Directorate review comments

    7) Current waiting status:
        a) Response from IANA review of -27
        b) Response from SEC-DIR resolution check
        c) final NITS check

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?  See Early Review comments.
   
    For which does this still need to happen in subsequent reviews?

    3/12/2024 status: Pending resolution:
    SEC-DIR Early review resolution - check text + SEC-DIR Reviewer
    (https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/69)
    Pending reviews: TSV Early Review, IANA early review, IETF-119 RTG-AD discussion

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?

    Experimental draft.  Why? IDR cannot settle on a single solution for Intent-based (Color) routing. 
    The top 2 solutions are forwarded as experimental drafts to allow operational deployment to give feedback.

    Do all Datatracker state attributes correctly reflect this intent? Yes .
   
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.

Editors:
2nd WG LC -03
Kaliraj Vairavakkali (kaliraj@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/ZL7tOk3fgqeIRM5dfKfx_GbIh2w/

Natrajan Venkataraman (natv@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/eh3IdjyMjJVQSwOx2CD95iKg1-4/

CoAuthors:
Reshma Das (dreshma@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/Ei8WY3sVYAhnECr1w40Y8C5zQ-Y/

Israel Means (israel.means@att.com)
https://mailarchive.ietf.org/arch/msg/idr/iniOhZ1BknkBhe2l8DYL5aL_lGk/

Csaba Mates (ietf@nop.hu)
https://mailarchive.ietf.org/arch/msg/idr/NSxyfq98238jOIllMgIrBF54aeg/

Deepak J. Gowda (dgowda@extremenetworks.com) [2nd WG LC]
https://mailarchive.ietf.org/arch/msg/idr/FWf7jsy7mFJDiW3stAWeJ_DU0oU/

Contributors:
Balaji Rajagoplan (balajir@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/SfJQVDClw7y8vXYoG8wlLKRgyLQ/


Rajesh M (mrajesh@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/4T2BDGnaZUmtWUPjFVIOAFL-ZoI/

Chaitanya Yadlapalli (cy098d@att.com)
https://mailarchive.ietf.org/arch/msg/idr/M1c3trnvMiVn3_QQU9FqbkuvHA0/

Mazen Khaddam (mazen.khaddam@cox.com)
https://mailarchive.ietf.org/arch/msg/idr/lhBotT08JzICX-uPUfhMUSA7uzc/

Rafal Jan Szarecki (Google)
https://mailarchive.ietf.org/arch/msg/idr/r09fylzRRgssJqDoQnhy66qCr-g/

Xiaohu Xu (Captialonline) [from 1st WG LC]
https://mailarchive.ietf.org/arch/msg/idr/DBuobWpmj_ce0IOUWDTZU7m095E/
2nd WG LC
https://mailarchive.ietf.org/arch/msg/idr/Uh39xPb20FTsmORAjgRlce8bwfc/

Contributor for [-12] missing in [-27]
Gyan Mishra (gyan.s.mishra@verizon.com) - dropped as of [-11]
before 1st WG LC. Missing IPR statement.

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.

2 editors on front page.
All IPR statements good for -27 except for Xiahou Xu.
issue with Gyan Mishra - no longer contributor after -11

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

[pending] NITS - see github reference
(see https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/70)
    - 2 lines over 72 length, but it seems the tools.

-(2477): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding
-(2501): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
 
    Each of IDR chairs have walked through Normative and Informative references.
    [Pending - Asking for RTG-AD (John Scudder) to do early review on
    normative/non-normative references. ] 

    Note: draft-ietf-idr-bgp-ct-27 references an informative reference: 
    BGP-CT-UPDATE-PACKING-TEST] which is a document on the IETF IDR WG Github.
    Read access is allowed for all. 
    see: https://raw.githubusercontent.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/1a75d4d10d4df0f1fd7dcc041c2c868704b092c7/update-packing-test-results.txt

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 normative references are freely available and published RFCs.
    See comment above regarding 1 informative reference at IETF IDR WG github.;

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

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

    There are no normative references that are not at RFC level.
    Informative references are RFCs, drafts, or one github reference (see #15 above). 

19. Will publication of this document change the status of any existing RFCs? No
    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? not applicable. 
    If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.- not applicable.

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. yes, confirmed 

    Confirm that any referenced IANA registries have been clearly identified. Yes, confirmed. 
    Confirm that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]). yes, Confirmed.

    [pending] Due to a complexity, an early request to review IANA allocation has
    been sent. 

    New registries:
      Transitive Transport Class Extended Community Sub-Types Registry
      Non-Transitive Transport Class Extended Community Sub-Types Registry
      BGP CT Parameters

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.

  No IANA registries that require Designated Expert Review are listed in this draft.

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

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

Need information:
1) Check on Updates for RFC9012

## Document History

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

The CT progression after adoption is tracked on both the IDR Wiki
and the IDR github repository: ietf-wg-idr/draft-ietf-idr-bgp-ct
https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues

Post 2nd WG LC Shepherd's review of -26.txt
https://mailarchive.ietf.org/arch/msg/idr/7PIQx2nE0Y4d-lR7bIpTPL_TMR0/

Summary of calls: (in reverse time order)
2nd WG LC: 2/16/2024 to 3/1/2024
https://mailarchive.ietf.org/arch/msg/idr/Ud2coGDvdXYy7x-SHPSK2Onwjx4/
Status: Consensus on publication of draft-ietf-idr-bgp-ct and draft-ietf-idr-bgp-ct-srv6
https://mailarchive.ietf.org/arch/msg/idr/oNY5gAcE21y1bke6tBzeb76uVo4/
https://mailarchive.ietf.org/arch/msg/idr/rJC4O726QqUoDEqFTffOF9EvX_U/

----
1st WG LC: draft-ietf-idr-bgp-ct-09.txt (6/26/2023 to 7/17/2023
https://mailarchive.ietf.org/arch/msg/idr/KYZbOsg2y4jcOfjV31pee5uhMjQ/
extension to 7/28: https://mailarchive.ietf.org/arch/msg/idr/Qr8GhdlEi8viaZxOCaWii3cA51s/
Extension to 8/01: https://mailarchive.ietf.org/arch/msg/idr/fC--NIU7VlyOjmNJwIcsXhXFvSk/
status: No consensus reached

The shepherd's write-up on this topic is available on the IDR wiki
https://wiki.ietf.org/e/en/group/idr/CT-WGLC

Email message notifying the WG of 1 WG LC Shepherd's report:
https://mailarchive.ietf.org/arch/msg/idr/klBUhMe9AsdflYhIYVEhSIps_lg/
---------
Adoption call results: (as part of status)
https://mailarchive.ietf.org/arch/msg/idr/0V6pBTQyCmh3t3h9cMqxZ3N0s7Q/

Adoption call: Time: 7/6/2022 to 7/27/2022 in 3 mail threads.
Part 1 of CAR/CT Adoption call (7/6 to 7/27): Informational Questions
​https://mailarchive.ietf.org/arch/msg/idr/FhoK04HsSy9tR7ioV7AD0Vv6Ir4/

Part 2 of CAR/CT Adoption call (7/6 to 7/27): Adoption call
​https://mailarchive.ietf.org/arch/msg/idr/AP_ClbZgpkX6CNy7TaZiU8SMD5w/

Part 3 of CAR/CT Adoption call (7/14 to 7/27) - Please note that Part 3 has a specific format for posting.
​https://mailarchive.ietf.org/arch/msg/idr/fTFYwF54WRHcj7PDt2t7sOQg6vo/

This adoption call was preceded by the following:
Email Discussion before IETF-113
​https://mailarchive.ietf.org/arch/msg/idr/e69NRd9i2aG0WUxFkShEfQHZsHo/

Note: The IDR chairs agree with Jeff Haas's (IDR Co-chair) summary posted on March 21, 2022,
that for route resolution and route origination/propagation,
BGP-CAR and BGP-CT are functionally identical but operationally different.

Presentations from IETF-108 to IETF-113
IDR interim on January 24, 2022
(​https://datatracker.ietf.org/meeting/interim-2022-idr-02/session/idr)


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


Rough Adoption decision:
The IDR chairs agree with Jeff Haas's (IDR Co-chair) summary posted on March 21, 2022,
that for route resolution and route origination/propagation,
BGP-CAR and BGP-CT are functionally identical but operationally different.

IDR WG could not come to a consensus on CAR vs. CT.  IDR Chairs elected to adopt
both CAR and CT drafts as experimental drafts.  Experience in the market
place will help determine which is better operationally.

Rough 1st WG LC of CAR/CT: The IDR WG LC for CAR and CT found the editors/authors/contributors
of CAR commenting on the CT draft (Just as CT authors commented on CAR draft).
In some ways, this lively debate helped find problems in the specifications.

2nd WG LC of CAR/CT: This WG LC did not have a lot of
CAR/CT editor discussions because the IDR Shepherding Chair had
a private discussion between editors prior to the 2nd WG LC.

During 2nd WG LC: Concern on Split of CT drafts into 3 drafts:
https://mailarchive.ietf.org/arch/msg/idr/29CYvVl0RnW0hJSU3il3p_cqt80/

Robert Raszuk raised a Concern regarding the splitting of the
CT draft into three parts (draft-ietf-idr-bgp-ct, draft-ietf-idr-bgp-ct-srv6,
and draft-ietf-idr-bgp-fwd-rr). Robert objected to the draft-ietf-idr-bgp-fwd-rr
being a WG draft.  The IDR chairs felt the text was in draft-ietf-idr-bgp-ct
since version -09, so Robert's concerns about being surprised as
WG draft was not justified.  However, it does point to the value of
the IDR chairs splitting this work out of the draft-ietf-idr-bgp-ct draft.

------
Dependencies on Spring:
a) Functional dependency - caused only theoretical scaling results
Due to a lack of adoption of the Spring Requirements document
draft-hr-spring-intentaware-routing-using-color-03, this WG
Shepherd allowed the scaling results to be theoretical without proof in CT.

b) Normative dependency on draft-ietf-idr-salih-spring-srv6-inter-domain-sids-04.
There is a normative dependency on an individual draft that is waiting for adoption. 
The Spring chairs have been notified that IDR draft-ietf-idr-bgp-ct-srv6
has normative dependencies on draft-ietf-idr-salih-spring-srv6-inter-domain-sids.

Dependencies with PCE
Dhruv Dhody reviewed the interactions with PCE drafts.
He sent comments to the CT authors. CT authors updated their drafts with changes. 

Dependencies with BESS:
BESS chairs were queried about reviewing the CAR and CT drafts.
No direct information was received.

-----
Alternatives for SRv6 without CAR or CT.
A third draft (draft-ietf-idr-cpr-00) was adopted as an informational draft.
This informational draft provides a way to encode intent for
SRv6 by operational practices rather than a new protocol.

## Directorate Reviews: (tracked by Datatracker) with comments from shepherd
RTG-DIR reviews:
Early Review of draft-ietf-idr-bgp-ct-09 (Med Boucadair)- status: has issues, excellent review
https://mailarchive.ietf.org/arch/msg/rtg-dir/aawFfvd29zERSBK4ydDDhxEQGRw
Early Review of draft-ietf-idr-bgp-ct-18 (Jonathan Hardwick) - status: has nits, good review
https://mailarchive.ietf.org/arch/msg/rtg-dir/FLGmC0-ufqPsZpH_LmgL2eWmWhY

OPS-DIR reviews:
Early Review of draft-ietf-idr-bgp-ct-12 (Bo Wu) - status: Has issues, Quality: good review, 4 issues mentioned
https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ct-12-opsdir-early-wu-2023-08-03/
Early Review of draft-ietf-idr-bgp-ct-18 (Bo Wu) - status: has nits, Quality: good review, 2nd review by the same reviewer as -12
https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ct-19-opsdir-early-wu-2024-01-05/

SEC-DIR Review:

Authors resolved in -30, except for NIT
email link: https://mailarchive.ietf.org/arch/msg/idr/fYulGchhf6oWPWhVWHxqx6WNupI/
github: assigned github issue #69
github link:https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/69
Status: Shepherd awaiting clarification email (sent 4/9), but no response as of 4/17.

TSV-Review: (due date 3/6/2024) - On the Right Track.
https://mailarchive.ietf.org/arch/msg/tsv-art/hml_nr-BAbzXk7RnKCCy-EVXLuw/
TSV-DIR:
From the viewpoint of the transport area, there are two important points that
need to be discussed when considering such tunnels: - MTU problems if the
tunnel configurations differ - DSCP issues if DSPC is used to provide non-best
effort services.
Status: -30 contained fixes for TSV-DIR, but no 2nd review.  (change on 3/18).

Shepherd's comment for TSV-DIR: Please look at this draft from the viewpoint of having intent (color) aware customer traffic forwarded over a VPN overlay (tunnels) that forwarded over a set of intent (color) aware underlay of tunnels.  Please consider the problems with tunnels in your review of this text.

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

Andrew mentioned he received feedback that there would be discomfort
if the CAR and CT do not progress to the Experimental simultaneously.
See Andrew Alston for additional details.

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

    Implementation report:
    https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-bgp-ct
 
    Implementation of CT:  Juniper, Freertg
    Implementation of CT-srv6: (TBD)

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.

  Reviews requested from PCE, Spring, and BESS before 2nd WG LC.
  Received reviews from PCE: CT updated based on feedback (missing link in IDR Mail)
  Received feedback from Spring chairs (Alvaro Retana)
    The following drafts were in the option queue:
      draft-hr-spring-intentaware-routing-using-color
      draft-salih-spring-srv6-inter-domain-sids-04 (ct-srv6)
 
  Nothing was received from BESS.
  RTG-DIR reviews: 2 early reviews - (-18) "has nits" 
  OPS-DIR reviews: 2 early reviews - (-19) "has nits"
  SEC-DIR reviews: 2 early reviews - (-19) 6 problems + 4 questions (must be resolved)
  TSV-DIR review:  1 early review requested - no response.
  IANA Early review: IANA early review of draft-ietf-idr-bgp-ct-27 IANA section.
 
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 requirement for formal review (MIB, Yang, Media type, and URI)
  A yang module for CT will be added to the list of Yang modules to create for BGP.

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 in the document

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 automated checking

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

Checks completed:
  1) Pre-Adoption by Jeff Haas and discussion among chairs 
  2) Careful Adoption review resulted in a list of issues that needed to be resolved:
      (https://wiki.ietf.org/group/idr/CAR-CTAdoption)
  3) Adoption call issues added to github for draft-ietf-idr-bgp-ct-27 
      (https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues)
  4) 1st WG LC -
      Prior to 1st WG LC: Shepherd verified that issues were addressed
                          and early Early Directorate reviews requested,
      1st WG LC: Shepherd report written
      (see https://wiki.ietf.org/group/idr/CT-WGLC and                     
      https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues)       
      Review provided by IDR Chair team: Jie Dong, Keyur Patel, and Jeff Haas.
 
  5) 2nd WG LC
      Prior to 2nd WG LC:
        a) Shepherd verified that issues raised in 1st WG LC were addressed.
        b) Review provided by IDR Chair team: Jie Dong, Keyur Patel, and Jeff Haas.
        c) IDR Chair team resolutions were made - via email and meetings of
          technical issues.
        d) Early reviews requested (RTG-DIR, OPS-DIR, SEC-DIR, and TSV-DIR)
          open reviews: resolution of SEC-DIR and lack of TSV-DIR
        d) Meeting with CAR and CT editor teams during 2nd WGLC
        e) two interims in 2024 - January 29 and February 26 - review status
    6) Post WG LC
        a) Shepherd reports with editorial nits [resolved]
        b) Shepherd report loaded into github as issues [Resolved]
        c) Review issues with document editors before -27 submission [Resolved] 
        b) IANA review of -27 requested. [pending]
        c) github issue loaded with Security Directorate review comments

    7) Current waiting status:
        a) Response from IANA review of -27
        b) Response from SEC-DIR resolution check
        c) final NITS check

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?  See Early Review comments.
   
    For which does this still need to happen in subsequent reviews?

    3/12/2024 status: Pending resolution:
    SEC-DIR Early review resolution - check text + SEC-DIR Reviewer
    (https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/69)
    Pending reviews: TSV Early Review, IANA early review, IETF-119 RTG-AD discussion

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?

    Experimental draft.  Why? IDR cannot settle on a single solution for Intent-based (Color) routing. 
    The top 2 solutions are forwarded as experimental drafts to allow operational deployment to give feedback.

    Do all Datatracker state attributes correctly reflect this intent? Yes .
   
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.

Editors:
2nd WG LC -03
Kaliraj Vairavakkali (kaliraj@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/ZL7tOk3fgqeIRM5dfKfx_GbIh2w/

Natrajan Venkataraman (natv@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/eh3IdjyMjJVQSwOx2CD95iKg1-4/

CoAuthors:
Reshma Das (dreshma@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/Ei8WY3sVYAhnECr1w40Y8C5zQ-Y/

Israel Means (israel.means@att.com)
https://mailarchive.ietf.org/arch/msg/idr/iniOhZ1BknkBhe2l8DYL5aL_lGk/

Csaba Mates (ietf@nop.hu)
https://mailarchive.ietf.org/arch/msg/idr/NSxyfq98238jOIllMgIrBF54aeg/

Deepak J. Gowda (dgowda@extremenetworks.com) [2nd WG LC]
https://mailarchive.ietf.org/arch/msg/idr/FWf7jsy7mFJDiW3stAWeJ_DU0oU/

Contributors:
Balaji Rajagoplan (balajir@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/SfJQVDClw7y8vXYoG8wlLKRgyLQ/


Rajesh M (mrajesh@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/4T2BDGnaZUmtWUPjFVIOAFL-ZoI/

Chaitanya Yadlapalli (cy098d@att.com)
https://mailarchive.ietf.org/arch/msg/idr/M1c3trnvMiVn3_QQU9FqbkuvHA0/

Mazen Khaddam (mazen.khaddam@cox.com)
https://mailarchive.ietf.org/arch/msg/idr/lhBotT08JzICX-uPUfhMUSA7uzc/

Rafal Jan Szarecki (Google)
https://mailarchive.ietf.org/arch/msg/idr/r09fylzRRgssJqDoQnhy66qCr-g/

Xiaohu Xu (Captialonline) [from 1st WG LC]
https://mailarchive.ietf.org/arch/msg/idr/DBuobWpmj_ce0IOUWDTZU7m095E/
2nd WG LC
https://mailarchive.ietf.org/arch/msg/idr/Uh39xPb20FTsmORAjgRlce8bwfc/

Contributor for [-12] missing in [-27]
Gyan Mishra (gyan.s.mishra@verizon.com) - dropped as of [-11]
before 1st WG LC. Missing IPR statement.

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.

2 editors on front page.
All IPR statements good for -27 except for Xiahou Xu.
issue with Gyan Mishra - no longer contributor after -11

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

[pending] NITS - see github reference
(see https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/70)
    - 2 lines over 72 length, but it seems the tools.

-(2477): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding
-(2501): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
 
    Each of IDR chairs have walked through Normative and Informative references.
    [Pending - Asking for RTG-AD (John Scudder) to do early review on
    normative/non-normative references. ] 

    Note: draft-ietf-idr-bgp-ct-27 references an informative reference: 
    BGP-CT-UPDATE-PACKING-TEST] which is a document on the IETF IDR WG Github.
    Read access is allowed for all. 
    see: https://raw.githubusercontent.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/1a75d4d10d4df0f1fd7dcc041c2c868704b092c7/update-packing-test-results.txt

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 normative references are freely available and published RFCs.
    See comment above regarding 1 informative reference at IETF IDR WG github.;

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

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

    There are no normative references that are not at RFC level.
    Informative references are RFCs, drafts, or one github reference (see #15 above). 

19. Will publication of this document change the status of any existing RFCs? No
    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? not applicable. 
    If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.- not applicable.

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. yes, confirmed 

    Confirm that any referenced IANA registries have been clearly identified. Yes, confirmed. 
    Confirm that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]). yes, Confirmed.

    [pending] Due to a complexity, an early request to review IANA allocation has
    been sent. 

    New registries:
      Transitive Transport Class Extended Community Sub-Types Registry
      Non-Transitive Transport Class Extended Community Sub-Types Registry
      BGP CT Parameters

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.

  No IANA registries that require Designated Expert Review are listed in this draft.

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

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

Need information:
1) link to Dhruv's review of CT drafts (need to dig)
2) Waiting response on SecDir review of -30 (sent 4/9)
3) Check on Updates for RFC9012

## Document History

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

The CT progression after adoption is tracked on both the IDR Wiki
and the IDR github repository: ietf-wg-idr/draft-ietf-idr-bgp-ct
https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues

Post 2nd WG LC Shepherd's review of -26.txt
https://mailarchive.ietf.org/arch/msg/idr/7PIQx2nE0Y4d-lR7bIpTPL_TMR0/

Summary of calls: (in reverse time order)
2nd WG LC: 2/16/2024 to 3/1/2024
https://mailarchive.ietf.org/arch/msg/idr/Ud2coGDvdXYy7x-SHPSK2Onwjx4/
Status: Consensus on publication of draft-ietf-idr-bgp-ct and draft-ietf-idr-bgp-ct-srv6
https://mailarchive.ietf.org/arch/msg/idr/oNY5gAcE21y1bke6tBzeb76uVo4/
https://mailarchive.ietf.org/arch/msg/idr/rJC4O726QqUoDEqFTffOF9EvX_U/

----
1st WG LC: draft-ietf-idr-bgp-ct-09.txt (6/26/2023 to 7/17/2023
https://mailarchive.ietf.org/arch/msg/idr/KYZbOsg2y4jcOfjV31pee5uhMjQ/
extension to 7/28: https://mailarchive.ietf.org/arch/msg/idr/Qr8GhdlEi8viaZxOCaWii3cA51s/
Extension to 8/01: https://mailarchive.ietf.org/arch/msg/idr/fC--NIU7VlyOjmNJwIcsXhXFvSk/
status: No consensus reached

The shepherd's write-up on this topic is available on the IDR wiki
https://wiki.ietf.org/e/en/group/idr/CT-WGLC

Email message notifying the WG of 1 WG LC Shepherd's report:
https://mailarchive.ietf.org/arch/msg/idr/klBUhMe9AsdflYhIYVEhSIps_lg/
---------
Adoption call results: (as part of status)
https://mailarchive.ietf.org/arch/msg/idr/0V6pBTQyCmh3t3h9cMqxZ3N0s7Q/

Adoption call: Time: 7/6/2022 to 7/27/2022 in 3 mail threads.
Part 1 of CAR/CT Adoption call (7/6 to 7/27): Informational Questions
​https://mailarchive.ietf.org/arch/msg/idr/FhoK04HsSy9tR7ioV7AD0Vv6Ir4/

Part 2 of CAR/CT Adoption call (7/6 to 7/27): Adoption call
​https://mailarchive.ietf.org/arch/msg/idr/AP_ClbZgpkX6CNy7TaZiU8SMD5w/

Part 3 of CAR/CT Adoption call (7/14 to 7/27) - Please note that Part 3 has a specific format for posting.
​https://mailarchive.ietf.org/arch/msg/idr/fTFYwF54WRHcj7PDt2t7sOQg6vo/

This adoption call was preceded by the following:
Email Discussion before IETF-113
​https://mailarchive.ietf.org/arch/msg/idr/e69NRd9i2aG0WUxFkShEfQHZsHo/

Note: The IDR chairs agree with Jeff Haas's (IDR Co-chair) summary posted on March 21, 2022,
that for route resolution and route origination/propagation,
BGP-CAR and BGP-CT are functionally identical but operationally different.

Presentations from IETF-108 to IETF-113
IDR interim on January 24, 2022
(​https://datatracker.ietf.org/meeting/interim-2022-idr-02/session/idr)


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


Rough Adoption decision:
The IDR chairs agree with Jeff Haas's (IDR Co-chair) summary posted on March 21, 2022,
that for route resolution and route origination/propagation,
BGP-CAR and BGP-CT are functionally identical but operationally different.

IDR WG could not come to a consensus on CAR vs. CT.  IDR Chairs elected to adopt
both CAR and CT drafts as experimental drafts.  Experience in the market
place will help determine which is better operationally.

Rough 1st WG LC of CAR/CT: The IDR WG LC for CAR and CT found the editors/authors/contributors
of CAR commenting on the CT draft (Just as CT authors commented on CAR draft).
In some ways, this lively debate helped find problems in the specifications.

2nd WG LC of CAR/CT: This WG LC did not have a lot of
CAR/CT editor discussions because the IDR Shepherding Chair had
a private discussion between editors prior to the 2nd WG LC.

During 2nd WG LC: Concern on Split of CT drafts into 3 drafts:
https://mailarchive.ietf.org/arch/msg/idr/29CYvVl0RnW0hJSU3il3p_cqt80/

Robert Raszuk raised a Concern regarding the splitting of the
CT draft into three parts (draft-ietf-idr-bgp-ct, draft-ietf-idr-bgp-ct-srv6,
and draft-ietf-idr-bgp-fwd-rr). Robert objected to the draft-ietf-idr-bgp-fwd-rr
being a WG draft.  The IDR chairs felt the text was in draft-ietf-idr-bgp-ct
since version -09, so Robert's concerns about being surprised as
WG draft was not justified.  However, it does point to the value of
the IDR chairs splitting this work out of the draft-ietf-idr-bgp-ct draft.

------
Dependencies on Spring:
a) Functional dependency - caused only theoretical scaling results
Due to a lack of adoption of the Spring Requirements document
draft-hr-spring-intentaware-routing-using-color-03, this WG
Shepherd allowed the scaling results to be theoretical without proof in CT.

b) Normative dependency on draft-ietf-idr-salih-spring-srv6-inter-domain-sids-04.
There is a normative dependency on an individual draft that is waiting for adoption. 
The Spring chairs have been notified that IDR draft-ietf-idr-bgp-ct-srv6
has normative dependencies on draft-ietf-idr-salih-spring-srv6-inter-domain-sids.

Dependencies with PCE
Dhruv Dhody reviewed the interactions with PCE drafts.
He sent comments to the CT authors. CT authors updated their drafts with changes. 

Dependencies with BESS:
BESS chairs were queried about reviewing the CAR and CT drafts.
No direct information was received.

-----
Alternatives for SRv6 without CAR or CT.
A third draft (draft-ietf-idr-cpr-00) was adopted as an informational draft.
This informational draft provides a way to encode intent for
SRv6 by operational practices rather than a new protocol.

## Directorate Reviews: (tracked by Datatracker) with comments from shepherd
RTG-DIR reviews:
Early Review of draft-ietf-idr-bgp-ct-09 (Med Boucadair)- status: has issues, excellent review
https://mailarchive.ietf.org/arch/msg/rtg-dir/aawFfvd29zERSBK4ydDDhxEQGRw
Early Review of draft-ietf-idr-bgp-ct-18 (Jonathan Hardwick) - status: has nits, good review
https://mailarchive.ietf.org/arch/msg/rtg-dir/FLGmC0-ufqPsZpH_LmgL2eWmWhY

OPS-DIR reviews:
Early Review of draft-ietf-idr-bgp-ct-12 (Bo Wu) - status: Has issues, Quality: good review, 4 issues mentioned
https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ct-12-opsdir-early-wu-2023-08-03/
Early Review of draft-ietf-idr-bgp-ct-18 (Bo Wu) - status: has nits, Quality: good review, 2nd review by the same reviewer as -12
https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ct-19-opsdir-early-wu-2024-01-05/

SEC-DIR Review:

Authors resolved in -30, except for NIT
email link: https://mailarchive.ietf.org/arch/msg/idr/fYulGchhf6oWPWhVWHxqx6WNupI/
github: assigned github issue #69
github link:https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/69
Status: Shepherd awaiting clarification email (sent 4/9), but no response as of 4/17.

TSV-Review: (due date 3/6/2024) - On the Right Track.
https://mailarchive.ietf.org/arch/msg/tsv-art/hml_nr-BAbzXk7RnKCCy-EVXLuw/
TSV-DIR:
From the viewpoint of the transport area, there are two important points that
need to be discussed when considering such tunnels: - MTU problems if the
tunnel configurations differ - DSCP issues if DSPC is used to provide non-best
effort services.
Status: -30 contained fixes for TSV-DIR, but no 2nd review.  (change on 3/18).

Shepherd's comment for TSV-DIR: Please look at this draft from the viewpoint of having intent (color) aware customer traffic forwarded over a VPN overlay (tunnels) that forwarded over a set of intent (color) aware underlay of tunnels.  Please consider the problems with tunnels in your review of this text.

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

Andrew mentioned he received feedback that there would be discomfort
if the CAR and CT do not progress to the Experimental simultaneously.
See Andrew Alston for additional details.

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

    Implementation report:
    https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-bgp-ct
 
    Implementation of CT:  Juniper, Freertg
    Implementation of CT-srv6: (TBD)

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.

  Reviews requested from PCE, Spring, and BESS before 2nd WG LC.
  Received reviews from PCE: CT updated based on feedback (missing link in IDR Mail)
  Received feedback from Spring chairs (Alvaro Retana)
    The following drafts were in the option queue:
      draft-hr-spring-intentaware-routing-using-color
      draft-salih-spring-srv6-inter-domain-sids-04 (ct-srv6)
 
  Nothing was received from BESS.
  RTG-DIR reviews: 2 early reviews - (-18) "has nits" 
  OPS-DIR reviews: 2 early reviews - (-19) "has nits"
  SEC-DIR reviews: 2 early reviews - (-19) 6 problems + 4 questions (must be resolved)
  TSV-DIR review:  1 early review requested - no response.
  IANA Early review: IANA early review of draft-ietf-idr-bgp-ct-27 IANA section.
 
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 requirement for formal review (MIB, Yang, Media type, and URI)
  A yang module for CT will be added to the list of Yang modules to create for BGP.

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 in the document

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 automated checking

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

Checks completed:
  1) Pre-Adoption by Jeff Haas and discussion among chairs 
  2) Careful Adoption review resulted in a list of issues that needed to be resolved:
      (https://wiki.ietf.org/group/idr/CAR-CTAdoption)
  3) Adoption call issues added to github for draft-ietf-idr-bgp-ct-27 
      (https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues)
  4) 1st WG LC -
      Prior to 1st WG LC: Shepherd verified that issues were addressed
                          and early Early Directorate reviews requested,
      1st WG LC: Shepherd report written
      (see https://wiki.ietf.org/group/idr/CT-WGLC and                     
      https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues)       
      Review provided by IDR Chair team: Jie Dong, Keyur Patel, and Jeff Haas.
 
  5) 2nd WG LC
      Prior to 2nd WG LC:
        a) Shepherd verified that issues raised in 1st WG LC were addressed.
        b) Review provided by IDR Chair team: Jie Dong, Keyur Patel, and Jeff Haas.
        c) IDR Chair team resolutions were made - via email and meetings of
          technical issues.
        d) Early reviews requested (RTG-DIR, OPS-DIR, SEC-DIR, and TSV-DIR)
          open reviews: resolution of SEC-DIR and lack of TSV-DIR
        d) Meeting with CAR and CT editor teams during 2nd WGLC
        e) two interims in 2024 - January 29 and February 26 - review status
    6) Post WG LC
        a) Shepherd reports with editorial nits [resolved]
        b) Shepherd report loaded into github as issues [Resolved]
        c) Review issues with document editors before -27 submission [Resolved] 
        b) IANA review of -27 requested. [pending]
        c) github issue loaded with Security Directorate review comments

    7) Current waiting status:
        a) Response from IANA review of -27
        b) Response from SEC-DIR resolution check
        c) final NITS check

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?  See Early Review comments.
   
    For which does this still need to happen in subsequent reviews?

    3/12/2024 status: Pending resolution:
    SEC-DIR Early review resolution - check text + SEC-DIR Reviewer
    (https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/69)
    Pending reviews: TSV Early Review, IANA early review, IETF-119 RTG-AD discussion

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?

    Experimental draft.  Why? IDR cannot settle on a single solution for Intent-based (Color) routing. 
    The top 2 solutions are forwarded as experimental drafts to allow operational deployment to give feedback.

    Do all Datatracker state attributes correctly reflect this intent? Yes .
   
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.

Editors:
2nd WG LC -03
Kaliraj Vairavakkali (kaliraj@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/ZL7tOk3fgqeIRM5dfKfx_GbIh2w/

Natrajan Venkataraman (natv@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/eh3IdjyMjJVQSwOx2CD95iKg1-4/

CoAuthors:
Reshma Das (dreshma@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/Ei8WY3sVYAhnECr1w40Y8C5zQ-Y/

Israel Means (israel.means@att.com)
https://mailarchive.ietf.org/arch/msg/idr/iniOhZ1BknkBhe2l8DYL5aL_lGk/

Csaba Mates (ietf@nop.hu)
https://mailarchive.ietf.org/arch/msg/idr/NSxyfq98238jOIllMgIrBF54aeg/

Deepak J. Gowda (dgowda@extremenetworks.com) [2nd WG LC]
https://mailarchive.ietf.org/arch/msg/idr/FWf7jsy7mFJDiW3stAWeJ_DU0oU/

Contributors:
Balaji Rajagoplan (balajir@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/SfJQVDClw7y8vXYoG8wlLKRgyLQ/


Rajesh M (mrajesh@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/4T2BDGnaZUmtWUPjFVIOAFL-ZoI/

Chaitanya Yadlapalli (cy098d@att.com)
https://mailarchive.ietf.org/arch/msg/idr/M1c3trnvMiVn3_QQU9FqbkuvHA0/

Mazen Khaddam (mazen.khaddam@cox.com)
https://mailarchive.ietf.org/arch/msg/idr/lhBotT08JzICX-uPUfhMUSA7uzc/

Rafal Jan Szarecki (Google)
https://mailarchive.ietf.org/arch/msg/idr/r09fylzRRgssJqDoQnhy66qCr-g/

Xiaohu Xu (Captialonline) [from 1st WG LC]
https://mailarchive.ietf.org/arch/msg/idr/DBuobWpmj_ce0IOUWDTZU7m095E/
2nd WG LC
https://mailarchive.ietf.org/arch/msg/idr/Uh39xPb20FTsmORAjgRlce8bwfc/

Contributor for [-12] missing in [-27]
Gyan Mishra (gyan.s.mishra@verizon.com) - dropped as of [-11]
before 1st WG LC. Missing IPR statement.

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.

2 editors on front page.
All IPR statements good for -27 except for Xiahou Xu.
issue with Gyan Mishra - no longer contributor after -11

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

[pending] NITS - see github reference
(see https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/70)
    - 2 lines over 72 length, but it seems the tools.

-(2477): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding
-(2501): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
 
    Each of IDR chairs have walked through Normative and Informative references.
    [Pending - Asking for RTG-AD (John Scudder) to do early review on
    normative/non-normative references. ] 

    Note: draft-ietf-idr-bgp-ct-27 references an informative reference: 
    BGP-CT-UPDATE-PACKING-TEST] which is a document on the IETF IDR WG Github.
    Read access is allowed for all. 
    see: https://raw.githubusercontent.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/1a75d4d10d4df0f1fd7dcc041c2c868704b092c7/update-packing-test-results.txt

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 normative references are freely available and published RFCs.
    See comment above regarding 1 informative reference at IETF IDR WG github.;

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

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

    There are no normative references that are not at RFC level.
    Informative references are RFCs, drafts, or one github reference (see #15 above). 

19. Will publication of this document change the status of any existing RFCs? No
    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? not applicable. 
    If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.- not applicable.

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. yes, confirmed 

    Confirm that any referenced IANA registries have been clearly identified. Yes, confirmed. 
    Confirm that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]). yes, Confirmed.

    [pending] Due to a complexity, an early request to review IANA allocation has
    been sent. 

    New registries:
      Transitive Transport Class Extended Community Sub-Types Registry
      Non-Transitive Transport Class Extended Community Sub-Types Registry
      BGP CT Parameters

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.

  No IANA registries that require Designated Expert Review are listed in this draft.

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

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

Need information:
1) link to Dhruv's review of CT drafts (need to dig)
2) Waiting response on SecDir review of -30 (sent 4/9)
3) Check on Updates for RFC9012

## Document History

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

The CT progression after adoption is tracked on both the IDR Wiki
and the IDR github repository: ietf-wg-idr/draft-ietf-idr-bgp-ct
https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues

Post 2nd WG LC Shepherd's review of -26.txt
https://mailarchive.ietf.org/arch/msg/idr/7PIQx2nE0Y4d-lR7bIpTPL_TMR0/

Summary of calls: (in reverse time order)
2nd WG LC: 2/16/2024 to 3/1/2024
https://mailarchive.ietf.org/arch/msg/idr/Ud2coGDvdXYy7x-SHPSK2Onwjx4/
Status: Consensus on publication of draft-ietf-idr-bgp-ct and draft-ietf-idr-bgp-ct-srv6
https://mailarchive.ietf.org/arch/msg/idr/oNY5gAcE21y1bke6tBzeb76uVo4/
https://mailarchive.ietf.org/arch/msg/idr/rJC4O726QqUoDEqFTffOF9EvX_U/

----
1st WG LC: draft-ietf-idr-bgp-ct-09.txt (6/26/2023 to 7/17/2023
https://mailarchive.ietf.org/arch/msg/idr/KYZbOsg2y4jcOfjV31pee5uhMjQ/
extension to 7/28: https://mailarchive.ietf.org/arch/msg/idr/Qr8GhdlEi8viaZxOCaWii3cA51s/
Extension to 8/01: https://mailarchive.ietf.org/arch/msg/idr/fC--NIU7VlyOjmNJwIcsXhXFvSk/
status: No consensus reached

The shepherd's write-up on this topic is available on the IDR wiki
https://wiki.ietf.org/e/en/group/idr/CT-WGLC

Email message notifying the WG of 1 WG LC Shepherd's report:
https://mailarchive.ietf.org/arch/msg/idr/klBUhMe9AsdflYhIYVEhSIps_lg/
---------
Adoption call results: (as part of status)
https://mailarchive.ietf.org/arch/msg/idr/0V6pBTQyCmh3t3h9cMqxZ3N0s7Q/

Adoption call: Time: 7/6/2022 to 7/27/2022 in 3 mail threads.
Part 1 of CAR/CT Adoption call (7/6 to 7/27): Informational Questions
​https://mailarchive.ietf.org/arch/msg/idr/FhoK04HsSy9tR7ioV7AD0Vv6Ir4/

Part 2 of CAR/CT Adoption call (7/6 to 7/27): Adoption call
​https://mailarchive.ietf.org/arch/msg/idr/AP_ClbZgpkX6CNy7TaZiU8SMD5w/

Part 3 of CAR/CT Adoption call (7/14 to 7/27) - Please note that Part 3 has a specific format for posting.
​https://mailarchive.ietf.org/arch/msg/idr/fTFYwF54WRHcj7PDt2t7sOQg6vo/

This adoption call was preceded by the following:
Email Discussion before IETF-113
​https://mailarchive.ietf.org/arch/msg/idr/e69NRd9i2aG0WUxFkShEfQHZsHo/

Note: The IDR chairs agree with Jeff Haas's (IDR Co-chair) summary posted on March 21, 2022,
that for route resolution and route origination/propagation,
BGP-CAR and BGP-CT are functionally identical but operationally different.

Presentations from IETF-108 to IETF-113
IDR interim on January 24, 2022
(​https://datatracker.ietf.org/meeting/interim-2022-idr-02/session/idr)


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


Rough Adoption decision:
The IDR chairs agree with Jeff Haas's (IDR Co-chair) summary posted on March 21, 2022,
that for route resolution and route origination/propagation,
BGP-CAR and BGP-CT are functionally identical but operationally different.

IDR WG could not come to a consensus on CAR vs. CT.  IDR Chairs elected to adopt
both CAR and CT drafts as experimental drafts.  Experience in the market
place will help determine which is better operationally.

Rough 1st WG LC of CAR/CT: The IDR WG LC for CAR and CT found the editors/authors/contributors
of CAR commenting on the CT draft (Just as CT authors commented on CAR draft).
In some ways, this lively debate helped find problems in the specifications.

2nd WG LC of CAR/CT: This WG LC did not have a lot of
CAR/CT editor discussions because the IDR Shepherding Chair had
a private discussion between editors prior to the 2nd WG LC.

During 2nd WG LC: Concern on Split of CT drafts into 3 drafts:
https://mailarchive.ietf.org/arch/msg/idr/29CYvVl0RnW0hJSU3il3p_cqt80/

Robert Raszuk raised a Concern regarding the splitting of the
CT draft into three parts (draft-ietf-idr-bgp-ct, draft-ietf-idr-bgp-ct-srv6,
and draft-ietf-idr-bgp-fwd-rr). Robert objected to the draft-ietf-idr-bgp-fwd-rr
being a WG draft.  The IDR chairs felt the text was in draft-ietf-idr-bgp-ct
since version -09, so Robert's concerns about being surprised as
WG draft was not justified.  However, it does point to the value of
the IDR chairs splitting this work out of the draft-ietf-idr-bgp-ct draft.

------
Dependencies on Spring:
a) Functional dependency - caused only theoretical scaling results
Due to a lack of adoption of the Spring Requirements document
draft-hr-spring-intentaware-routing-using-color-03, this WG
Shepherd allowed the scaling results to be theoretical without proof in CT.

b) Normative dependency on draft-ietf-idr-salih-spring-srv6-inter-domain-sids-04.
There is a normative dependency on an individual draft that is waiting for adoption. 
The Spring chairs have been notified that IDR draft-ietf-idr-bgp-ct-srv6
has normative dependencies on draft-ietf-idr-salih-spring-srv6-inter-domain-sids.

Dependencies with PCE
Dhruv Dhody reviewed the interactions with PCE drafts.
He sent comments to the CT authors. CT authors updated their drafts with changes. 

Dependencies with BESS:
BESS chairs were queried about reviewing the CAR and CT drafts.
No direct information was received.

-----
Alternatives for SRv6 without CAR or CT.
A third draft (draft-ietf-idr-cpr-00) was adopted as an informational draft.
This informational draft provides a way to encode intent for
SRv6 by operational practices rather than a new protocol.

## Directorate Reviews: (tracked by Datatracker) with comments from shepherd
RTG-DIR reviews:
Early Review of draft-ietf-idr-bgp-ct-09 (Med Boucadair)- status: has issues, excellent review
https://mailarchive.ietf.org/arch/msg/rtg-dir/aawFfvd29zERSBK4ydDDhxEQGRw
Early Review of draft-ietf-idr-bgp-ct-18 (Jonathan Hardwick) - status: has nits, good review
https://mailarchive.ietf.org/arch/msg/rtg-dir/FLGmC0-ufqPsZpH_LmgL2eWmWhY

OPS-DIR reviews:
Early Review of draft-ietf-idr-bgp-ct-12 (Bo Wu) - status: Has issues, Quality: good review, 4 issues mentioned
https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ct-12-opsdir-early-wu-2023-08-03/
Early Review of draft-ietf-idr-bgp-ct-18 (Bo Wu) - status: has nits, Quality: good review, 2nd review by the same reviewer as -12
https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ct-19-opsdir-early-wu-2024-01-05/

SEC-DIR Review:
comments from the WG chair on SEC-DIR early review:
Intent (Color) could have security issues in this draft. The service data (customer data)
is being tracked by intent and placed over service quality tunnels. 
In one view, it is just more layering. In an alternate view, the color exposes some abstract qualities of the network.

Early review of draft-ietf-idr-bgp-ct-18 (by Magnus Nystrom)- status: has issues.
Issues stated:
1) Why does the definition of "new AFI/SAFI to pass routes" not change any underlying security characteristics?
  This should be explained better.
2) Where is it stated in the document - "Mechanisms described in this document follow a "Walled Garden" approach?
  This should be explained better.
3) It is stated that BGP origin validation "could" be used to "increase assurance" that information has not been falsified.
  Firstly, "could" does not say much to an implementer. Is this intended to be "SHOULD"?
  What's the risk of not using origin validation?
  And conversely, what assurance is given if BGP origin validation is not used (the "increased assurance" part).
4) It is stated that:
      "In order to mitigate the risk of the diversion of traffic from its
      intended destination, [the] existing BGPsec solution could be extended, and
      supported for this SAFI."
  What does "could" mean here?
5) It is also stated that "as long as filtering [and other measures] are
  applied diligently, "risk of [traffic diversion] is eliminated". 
  Is this really the case? That it is entirely eliminated?
6) Not being an expert in this area, I just want to call out the
  following items that I ask the authors to ensure that they are covered:
      1. Is there anything in here which increases the risk of dDoS attacks?
      2. Do the mechanisms and constructs in this document introduce any
      new risks related to unintended information disclosure?
      3. Do the mechanisms and constructs in this document introduce any
      new risks due to spoofing of endpoint identities etc.?
      4. Do the mechanisms and constructs in this document introduce any
      new risks due to modification of information exchanged, e.g., between AS
      endpoints?

Early review of draft-ietf-idr-bgp-ct-19 (by Magnus Nystrom)- status: has issues. Authors did not resolve -18 issues
https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ct-19-secdir-early-nystrom-2024-01-15/

Authors resolved in -30, except for NIT
email link: https://mailarchive.ietf.org/arch/msg/idr/fYulGchhf6oWPWhVWHxqx6WNupI/
github: assigned github issue #69
github link:https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/69
Status: Shepherd awaiting clarification email (sent 4/9), but no response as of 4/17.

TSV-Review: (due date 3/6/2024) - no response from review
Shepherd's comment for TSV-DIR: Please look at this draft from the viewpoint of having intent (color) aware customer traffic forwarded over a VPN overlay (tunnels) that forwarded over a set of intent (color) aware underlay of tunnels.  Please consider the problems with tunnels in your review of this text.

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

Andrew mentioned he received feedback that there would be discomfort
if the CAR and CT do not progress to the Experimental simultaneously.
See Andrew Alston for additional details.

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

    Implementation report:
    https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-bgp-ct
 
    Implementation of CT:  Juniper, Freertg
    Implementation of CT-srv6: (TBD)

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.

  Reviews requested from PCE, Spring, and BESS before 2nd WG LC.
  Received reviews from PCE: [need link]
  Received feedback from Spring chairs (Alvaro Retana)
    The following drafts were in the option queue:
      draft-hr-spring-intentaware-routing-using-color
      draft-salih-spring-srv6-inter-domain-sids-04 (ct-srv6)
 
  Nothing was received from BESS.
  RTG-DIR reviews: 2 early reviews - (-18) "has nits" 
  OPS-DIR reviews: 2 early reviews - (-19) "has nits"
  SEC-DIR reviews: 2 early reviews - (-19) 6 problems + 4 questions (must be resolved)
  TSV-DIR review:  1 early review requested - no response.
  IANA Early review: IANA early review of draft-ietf-idr-bgp-ct-27 IANA section.
 
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 requirement for formal review (MIB, Yang, Media type, and URI)
  A yang module for CT will be added to the list of Yang modules to create for BGP.

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 in the document

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 automated checking

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

Checks completed:
  1) Pre-Adoption by Jeff Haas and discussion among chairs 
  2) Careful Adoption review resulted in a list of issues that needed to be resolved:
      (https://wiki.ietf.org/group/idr/CAR-CTAdoption)
  3) Adoption call issues added to github for draft-ietf-idr-bgp-ct-27 
      (https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues)
  4) 1st WG LC -
      Prior to 1st WG LC: Shepherd verified that issues were addressed
                          and early Early Directorate reviews requested,
      1st WG LC: Shepherd report written
      (see https://wiki.ietf.org/group/idr/CT-WGLC and                     
      https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues)       
      Review provided by IDR Chair team: Jie Dong, Keyur Patel, and Jeff Haas.
 
  5) 2nd WG LC
      Prior to 2nd WG LC:
        a) Shepherd verified that issues raised in 1st WG LC were addressed.
        b) Review provided by IDR Chair team: Jie Dong, Keyur Patel, and Jeff Haas.
        c) IDR Chair team resolutions were made - via email and meetings of
          technical issues.
        d) Early reviews requested (RTG-DIR, OPS-DIR, SEC-DIR, and TSV-DIR)
          open reviews: resolution of SEC-DIR and lack of TSV-DIR
        d) Meeting with CAR and CT editor teams during 2nd WGLC
        e) two interims in 2024 - January 29 and February 26 - review status
    6) Post WG LC
        a) Shepherd reports with editorial nits [resolved]
        b) Shepherd report loaded into github as issues [Resolved]
        c) Review issues with document editors before -27 submission [Resolved] 
        b) IANA review of -27 requested. [pending]
        c) github issue loaded with Security Directorate review comments

    7) Current waiting status:
        a) Response from IANA review of -27
        b) Response from SEC-DIR resolution check
        c) final NITS check

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?  See Early Review comments.
   
    For which does this still need to happen in subsequent reviews?

    3/12/2024 status: Pending resolution:
    SEC-DIR Early review resolution - check text + SEC-DIR Reviewer
    (https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/69)
    Pending reviews: TSV Early Review, IANA early review, IETF-119 RTG-AD discussion

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?

    Experimental draft.  Why? IDR cannot settle on a single solution for Intent-based (Color) routing. 
    The top 2 solutions are forwarded as experimental drafts to allow operational deployment to give feedback.

    Do all Datatracker state attributes correctly reflect this intent? Yes .
   
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.

Editors:
2nd WG LC -03
Kaliraj Vairavakkali (kaliraj@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/ZL7tOk3fgqeIRM5dfKfx_GbIh2w/

Natrajan Venkataraman (natv@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/eh3IdjyMjJVQSwOx2CD95iKg1-4/

CoAuthors:
Reshma Das (dreshma@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/Ei8WY3sVYAhnECr1w40Y8C5zQ-Y/

Israel Means (israel.means@att.com)
https://mailarchive.ietf.org/arch/msg/idr/iniOhZ1BknkBhe2l8DYL5aL_lGk/

Csaba Mates (ietf@nop.hu)
https://mailarchive.ietf.org/arch/msg/idr/NSxyfq98238jOIllMgIrBF54aeg/

Deepak J. Gowda (dgowda@extremenetworks.com) [2nd WG LC]
https://mailarchive.ietf.org/arch/msg/idr/FWf7jsy7mFJDiW3stAWeJ_DU0oU/

Contributors:
Balaji Rajagoplan (balajir@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/SfJQVDClw7y8vXYoG8wlLKRgyLQ/


Rajesh M (mrajesh@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/4T2BDGnaZUmtWUPjFVIOAFL-ZoI/

Chaitanya Yadlapalli (cy098d@att.com)
https://mailarchive.ietf.org/arch/msg/idr/M1c3trnvMiVn3_QQU9FqbkuvHA0/

Mazen Khaddam (mazen.khaddam@cox.com)
https://mailarchive.ietf.org/arch/msg/idr/lhBotT08JzICX-uPUfhMUSA7uzc/

Rafal Jan Szarecki (Google)
https://mailarchive.ietf.org/arch/msg/idr/r09fylzRRgssJqDoQnhy66qCr-g/

Xiaohu Xu (Captialonline) [from 1st WG LC]
https://mailarchive.ietf.org/arch/msg/idr/DBuobWpmj_ce0IOUWDTZU7m095E/
2nd WG LC
https://mailarchive.ietf.org/arch/msg/idr/Uh39xPb20FTsmORAjgRlce8bwfc/

Contributor for [-12] missing in [-27]
Gyan Mishra (gyan.s.mishra@verizon.com) - dropped as of [-11]
before 1st WG LC. Missing IPR statement.

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.

2 editors on front page.
All IPR statements good for -27 except for Xiahou Xu.
issue with Gyan Mishra - no longer contributor after -11

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

[pending] NITS - see github reference
(see https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/70)
    - 2 lines over 72 length, but it seems the tools.

-(2477): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding
-(2501): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
 
    Each of IDR chairs have walked through Normative and Informative references.
    [Pending - Asking for RTG-AD (John Scudder) to do early review on
    normative/non-normative references. ] 

    Note: draft-ietf-idr-bgp-ct-27 references an informative reference: 
    BGP-CT-UPDATE-PACKING-TEST] which is a document on the IETF IDR WG Github.
    Read access is allowed for all. 
    see: https://raw.githubusercontent.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/1a75d4d10d4df0f1fd7dcc041c2c868704b092c7/update-packing-test-results.txt

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 normative references are freely available and published RFCs.
    See comment above regarding 1 informative reference at IETF IDR WG github.;

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

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

    There are no normative references that are not at RFC level.
    Informative references are RFCs, drafts, or one github reference (see #15 above). 

19. Will publication of this document change the status of any existing RFCs? No
    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? not applicable. 
    If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.- not applicable.

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. yes, confirmed 

    Confirm that any referenced IANA registries have been clearly identified. Yes, confirmed. 
    Confirm that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]). yes, Confirmed.

    [pending] Due to a complexity, an early request to review IANA allocation has
    been sent. 

    New registries:
      Transitive Transport Class Extended Community Sub-Types Registry
      Non-Transitive Transport Class Extended Community Sub-Types Registry
      BGP CT Parameters

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.

  No IANA registries that require Designated Expert Review are listed in this draft.

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

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

Need information:
1) link to Dhruv's review of CT drafts (need to dig)
2) Waiting response on SecDir review of -30 (sent 4/9)
3) Check on Updates for RFC9012

## Document History

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

The CT progression after adoption is tracked on both the IDR Wiki
and the IDR github repository: ietf-wg-idr/draft-ietf-idr-bgp-ct
https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues

Post 2nd WG LC Shepherd's review of -26.txt
https://mailarchive.ietf.org/arch/msg/idr/7PIQx2nE0Y4d-lR7bIpTPL_TMR0/

Summary of calls: (in reverse time order)
2nd WG LC: 2/16/2024 to 3/1/2024
https://mailarchive.ietf.org/arch/msg/idr/Ud2coGDvdXYy7x-SHPSK2Onwjx4/
Status: Consensus on publication of draft-ietf-idr-bgp-ct and draft-ietf-idr-bgp-ct-srv6
https://mailarchive.ietf.org/arch/msg/idr/oNY5gAcE21y1bke6tBzeb76uVo4/
https://mailarchive.ietf.org/arch/msg/idr/rJC4O726QqUoDEqFTffOF9EvX_U/

----
1st WG LC: draft-ietf-idr-bgp-ct-09.txt (6/26/2023 to 7/17/2023
https://mailarchive.ietf.org/arch/msg/idr/KYZbOsg2y4jcOfjV31pee5uhMjQ/
extension to 7/28: https://mailarchive.ietf.org/arch/msg/idr/Qr8GhdlEi8viaZxOCaWii3cA51s/
Extension to 8/01: https://mailarchive.ietf.org/arch/msg/idr/fC--NIU7VlyOjmNJwIcsXhXFvSk/
status: No consensus reached

The shepherd's write-up on this topic is available on the IDR wiki
https://wiki.ietf.org/e/en/group/idr/CT-WGLC

Email message notifying the WG of 1 WG LC Shepherd's report:
https://mailarchive.ietf.org/arch/msg/idr/klBUhMe9AsdflYhIYVEhSIps_lg/
---------
Adoption call results: (as part of status)
https://mailarchive.ietf.org/arch/msg/idr/0V6pBTQyCmh3t3h9cMqxZ3N0s7Q/

Adoption call: Time: 7/6/2022 to 7/27/2022 in 3 mail threads.
Part 1 of CAR/CT Adoption call (7/6 to 7/27): Informational Questions
​https://mailarchive.ietf.org/arch/msg/idr/FhoK04HsSy9tR7ioV7AD0Vv6Ir4/

Part 2 of CAR/CT Adoption call (7/6 to 7/27): Adoption call
​https://mailarchive.ietf.org/arch/msg/idr/AP_ClbZgpkX6CNy7TaZiU8SMD5w/

Part 3 of CAR/CT Adoption call (7/14 to 7/27) - Please note that Part 3 has a specific format for posting.
​https://mailarchive.ietf.org/arch/msg/idr/fTFYwF54WRHcj7PDt2t7sOQg6vo/

This adoption call was preceded by the following:
Email Discussion before IETF-113
​https://mailarchive.ietf.org/arch/msg/idr/e69NRd9i2aG0WUxFkShEfQHZsHo/

Note: The IDR chairs agree with Jeff Haas's (IDR Co-chair) summary posted on March 21, 2022,
that for route resolution and route origination/propagation,
BGP-CAR and BGP-CT are functionally identical but operationally different.

Presentations from IETF-108 to IETF-113
IDR interim on January 24, 2022
(​https://datatracker.ietf.org/meeting/interim-2022-idr-02/session/idr)


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


Rough Adoption decision:
The IDR chairs agree with Jeff Haas's (IDR Co-chair) summary posted on March 21, 2022,
that for route resolution and route origination/propagation,
BGP-CAR and BGP-CT are functionally identical but operationally different.

IDR WG could not come to a consensus on CAR vs. CT.  IDR Chairs elected to adopt
both CAR and CT drafts as experimental drafts.  Experience in the market
place will help determine which is better operationally.

Rough 1st WG LC of CAR/CT: The IDR WG LC for CAR and CT found the editors/authors/contributors
of CAR commenting on the CT draft (Just as CT authors commented on CAR draft).
In some ways, this lively debate helped find problems in the specifications.

2nd WG LC of CAR/CT: This WG LC did not have a lot of
CAR/CT editor discussions because the IDR Shepherding Chair had
a private discussion between editors prior to the 2nd WG LC.

During 2nd WG LC: Concern on Split of CT drafts into 3 drafts:
https://mailarchive.ietf.org/arch/msg/idr/29CYvVl0RnW0hJSU3il3p_cqt80/

Robert Raszuk raised a Concern regarding the splitting of the
CT draft into three parts (draft-ietf-idr-bgp-ct, draft-ietf-idr-bgp-ct-srv6,
and draft-ietf-idr-bgp-fwd-rr). Robert objected to the draft-ietf-idr-bgp-fwd-rr
being a WG draft.  The IDR chairs felt the text was in draft-ietf-idr-bgp-ct
since version -09, so Robert's concerns about being surprised as
WG draft was not justified.  However, it does point to the value of
the IDR chairs splitting this work out of the draft-ietf-idr-bgp-ct draft.

------
Dependencies on Spring:
a) Functional dependency - caused only theoretical scaling results
Due to a lack of adoption of the Spring Requirements document
draft-hr-spring-intentaware-routing-using-color-03, this WG
Shepherd allowed the scaling results to be theoretical without proof in CT.

b) Normative dependency on draft-ietf-idr-salih-spring-srv6-inter-domain-sids-04.
There is a normative dependency on an individual draft that is waiting for adoption. 
The Spring chairs have been notified that IDR draft-ietf-idr-bgp-ct-srv6
has normative dependencies on draft-ietf-idr-salih-spring-srv6-inter-domain-sids.

Dependencies with PCE
Dhruv Dhody reviewed the interactions with PCE drafts.
He sent comments to the CT authors. CT authors updated their drafts with changes. 

Dependencies with BESS:
BESS chairs were queried about reviewing the CAR and CT drafts.
No direct information was received.

-----
Alternatives for SRv6 without CAR or CT.
A third draft (draft-ietf-idr-cpr-00) was adopted as an informational draft.
This informational draft provides a way to encode intent for
SRv6 by operational practices rather than a new protocol.

## Directorate Reviews: (tracked by Datatracker) with comments from shepherd
RTG-DIR reviews:
Early Review of draft-ietf-idr-bgp-ct-09 (Med Boucadair)- status: has issues, excellent review
https://mailarchive.ietf.org/arch/msg/rtg-dir/aawFfvd29zERSBK4ydDDhxEQGRw
Early Review of draft-ietf-idr-bgp-ct-18 (Jonathan Hardwick) - status: has nits, good review
https://mailarchive.ietf.org/arch/msg/rtg-dir/FLGmC0-ufqPsZpH_LmgL2eWmWhY

OPS-DIR reviews:
Early Review of draft-ietf-idr-bgp-ct-12 (Bo Wu) - status: Has issues, Quality: good review, 4 issues mentioned
https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ct-12-opsdir-early-wu-2023-08-03/
Early Review of draft-ietf-idr-bgp-ct-18 (Bo Wu) - status: has nits, Quality: good review, 2nd review by the same reviewer as -12
https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ct-19-opsdir-early-wu-2024-01-05/

SEC-DIR Review:
comments from the WG chair on SEC-DIR early review:
Intent (Color) could have security issues in this draft. The service data (customer data)
is being tracked by intent and placed over service quality tunnels. 
In one view, it is just more layering. In an alternate view, the color exposes some abstract qualities of the network.

Early review of draft-ietf-idr-bgp-ct-18 (by Magnus Nystrom)- status: has issues.
Issues stated:
1) Why does the definition of "new AFI/SAFI to pass routes" not change any underlying security characteristics?
  This should be explained better.
2) Where is it stated in the document - "Mechanisms described in this document follow a "Walled Garden" approach?
  This should be explained better.
3) It is stated that BGP origin validation "could" be used to "increase assurance" that information has not been falsified.
  Firstly, "could" does not say much to an implementer. Is this intended to be "SHOULD"?
  What's the risk of not using origin validation?
  And conversely, what assurance is given if BGP origin validation is not used (the "increased assurance" part).
4) It is stated that:
      "In order to mitigate the risk of the diversion of traffic from its
      intended destination, [the] existing BGPsec solution could be extended, and
      supported for this SAFI."
  What does "could" mean here?
5) It is also stated that "as long as filtering [and other measures] are
  applied diligently, "risk of [traffic diversion] is eliminated". 
  Is this really the case? That it is entirely eliminated?
6) Not being an expert in this area, I just want to call out the
  following items that I ask the authors to ensure that they are covered:
      1. Is there anything in here which increases the risk of dDoS attacks?
      2. Do the mechanisms and constructs in this document introduce any
      new risks related to unintended information disclosure?
      3. Do the mechanisms and constructs in this document introduce any
      new risks due to spoofing of endpoint identities etc.?
      4. Do the mechanisms and constructs in this document introduce any
      new risks due to modification of information exchanged, e.g., between AS
      endpoints?

Early review of draft-ietf-idr-bgp-ct-19 (by Magnus Nystrom)- status: has issues. Authors did not resolve -18 issues
https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ct-19-secdir-early-nystrom-2024-01-15/

Shepherd's note: Assigned github issue #69 to resolve before publication request sent to IESG.

TSV-Review: (due date 3/6/2024) - no response from review
Shepherd's comment for TSV-DIR: Please look at this draft from the viewpoint of having intent (color) aware customer traffic forwarded over a VPN overlay (tunnels) that forwarded over a set of intent (color) aware underlay of tunnels.  Please consider the problems with tunnels in your review of this text.

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

Andrew mentioned he received feedback that there would be discomfort
if the CAR and CT do not progress to the Experimental simultaneously.
See Andrew Alston for additional details.

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

    Implementation report:
    https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-bgp-ct
 
    Implementation of CT:  Juniper, Freertg
    Implementation of CT-srv6: (TBD)

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.

  Reviews requested from PCE, Spring, and BESS before 2nd WG LC.
  Received reviews from PCE: [need link]
  Received feedback from Spring chairs (Alvaro Retana)
    The following drafts were in the option queue:
      draft-hr-spring-intentaware-routing-using-color
      draft-salih-spring-srv6-inter-domain-sids-04 (ct-srv6)
 
  Nothing was received from BESS.
  RTG-DIR reviews: 2 early reviews - (-18) "has nits" 
  OPS-DIR reviews: 2 early reviews - (-19) "has nits"
  SEC-DIR reviews: 2 early reviews - (-19) 6 problems + 4 questions (must be resolved)
  TSV-DIR review:  1 early review requested - no response.
  IANA Early review: IANA early review of draft-ietf-idr-bgp-ct-27 IANA section.
 
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 requirement for formal review (MIB, Yang, Media type, and URI)
  A yang module for CT will be added to the list of Yang modules to create for BGP.

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 in the document

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 automated checking

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

Checks completed:
  1) Pre-Adoption by Jeff Haas and discussion among chairs 
  2) Careful Adoption review resulted in a list of issues that needed to be resolved:
      (https://wiki.ietf.org/group/idr/CAR-CTAdoption)
  3) Adoption call issues added to github for draft-ietf-idr-bgp-ct-27 
      (https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues)
  4) 1st WG LC -
      Prior to 1st WG LC: Shepherd verified that issues were addressed
                          and early Early Directorate reviews requested,
      1st WG LC: Shepherd report written
      (see https://wiki.ietf.org/group/idr/CT-WGLC and                     
      https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues)       
      Review provided by IDR Chair team: Jie Dong, Keyur Patel, and Jeff Haas.
 
  5) 2nd WG LC
      Prior to 2nd WG LC:
        a) Shepherd verified that issues raised in 1st WG LC were addressed.
        b) Review provided by IDR Chair team: Jie Dong, Keyur Patel, and Jeff Haas.
        c) IDR Chair team resolutions were made - via email and meetings of
          technical issues.
        d) Early reviews requested (RTG-DIR, OPS-DIR, SEC-DIR, and TSV-DIR)
          open reviews: resolution of SEC-DIR and lack of TSV-DIR
        d) Meeting with CAR and CT editor teams during 2nd WGLC
        e) two interims in 2024 - January 29 and February 26 - review status
    6) Post WG LC
        a) Shepherd reports with editorial nits [resolved]
        b) Shepherd report loaded into github as issues [Resolved]
        c) Review issues with document editors before -27 submission [Resolved] 
        b) IANA review of -27 requested. [pending]
        c) github issue loaded with Security Directorate review comments

    7) Current waiting status:
        a) Response from IANA review of -27
        b) Response from SEC-DIR resolution check
        c) final NITS check

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?  See Early Review comments.
   
    For which does this still need to happen in subsequent reviews?

    3/12/2024 status: Pending resolution:
    SEC-DIR Early review resolution - check text + SEC-DIR Reviewer
    (https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/69)
    Pending reviews: TSV Early Review, IANA early review, IETF-119 RTG-AD discussion

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?

    Experimental draft.  Why? IDR cannot settle on a single solution for Intent-based (Color) routing. 
    The top 2 solutions are forwarded as experimental drafts to allow operational deployment to give feedback.

    Do all Datatracker state attributes correctly reflect this intent? Yes .
   
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.

Editors:
2nd WG LC -03
Kaliraj Vairavakkali (kaliraj@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/ZL7tOk3fgqeIRM5dfKfx_GbIh2w/

Natrajan Venkataraman (natv@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/eh3IdjyMjJVQSwOx2CD95iKg1-4/

CoAuthors:
Reshma Das (dreshma@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/Ei8WY3sVYAhnECr1w40Y8C5zQ-Y/

Israel Means (israel.means@att.com)
https://mailarchive.ietf.org/arch/msg/idr/iniOhZ1BknkBhe2l8DYL5aL_lGk/

Csaba Mates (ietf@nop.hu)
https://mailarchive.ietf.org/arch/msg/idr/NSxyfq98238jOIllMgIrBF54aeg/

Deepak J. Gowda (dgowda@extremenetworks.com) [2nd WG LC]
https://mailarchive.ietf.org/arch/msg/idr/FWf7jsy7mFJDiW3stAWeJ_DU0oU/

Contributors:
Balaji Rajagoplan (balajir@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/SfJQVDClw7y8vXYoG8wlLKRgyLQ/


Rajesh M (mrajesh@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/4T2BDGnaZUmtWUPjFVIOAFL-ZoI/

Chaitanya Yadlapalli (cy098d@att.com)
https://mailarchive.ietf.org/arch/msg/idr/M1c3trnvMiVn3_QQU9FqbkuvHA0/

Mazen Khaddam (mazen.khaddam@cox.com)
https://mailarchive.ietf.org/arch/msg/idr/lhBotT08JzICX-uPUfhMUSA7uzc/

Rafal Jan Szarecki (Google)
https://mailarchive.ietf.org/arch/msg/idr/r09fylzRRgssJqDoQnhy66qCr-g/

Xiaohu Xu (Captialonline) [from 1st WG LC]
https://mailarchive.ietf.org/arch/msg/idr/DBuobWpmj_ce0IOUWDTZU7m095E/
2nd WG LC
https://mailarchive.ietf.org/arch/msg/idr/Uh39xPb20FTsmORAjgRlce8bwfc/

Contributor for [-12] missing in [-27]
Gyan Mishra (gyan.s.mishra@verizon.com) - dropped as of [-11]
before 1st WG LC. Missing IPR statement.

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.

2 editors on front page.
All IPR statements good for -27 except for Xiahou Xu.
issue with Gyan Mishra - no longer contributor after -11

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

[pending] NITS - see github reference
(see https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/70)
    - 2 lines over 72 length, but it seems the tools.

-(2477): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding
-(2501): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
 
    Each of IDR chairs have walked through Normative and Informative references.
    [Pending - Asking for RTG-AD (John Scudder) to do early review on
    normative/non-normative references. ] 

    Note: draft-ietf-idr-bgp-ct-27 references an informative reference: 
    BGP-CT-UPDATE-PACKING-TEST] which is a document on the IETF IDR WG Github.
    Read access is allowed for all. 
    see: https://raw.githubusercontent.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/1a75d4d10d4df0f1fd7dcc041c2c868704b092c7/update-packing-test-results.txt

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 normative references are freely available and published RFCs.
    See comment above regarding 1 informative reference at IETF IDR WG github.;

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

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

    There are no normative references that are not at RFC level.
    Informative references are RFCs, drafts, or one github reference (see #15 above). 

19. Will publication of this document change the status of any existing RFCs? No
    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? not applicable. 
    If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.- not applicable.

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. yes, confirmed 

    Confirm that any referenced IANA registries have been clearly identified. Yes, confirmed. 
    Confirm that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]). yes, Confirmed.

    [pending] Due to a complexity, an early request to review IANA allocation has
    been sent. 

    New registries:
      Transitive Transport Class Extended Community Sub-Types Registry
      Non-Transitive Transport Class Extended Community Sub-Types Registry
      BGP CT Parameters

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.

  No IANA registries that require Designated Expert Review are listed in this draft.

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