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

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

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

Need information:
3) link to Dhruv's review of CT drafts
4) Ask for SecDir review of -30

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

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

Need information:
3) link to Dhruv's review of CT drafts
4) Resolve SEC-DIR issues (github issue 69) 
5) Pending Early Directorate reviews:  IANA (github issue 63) and TSV-DIR review
6) Check on nits issues (github issue 70)


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

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

Need information:
1) IPR - Xiahou Xu - IPR statement for -27, Gyan statement on IPR
2) Implementation report clarified - where SRv6 is concerned.
3) link to Dhruv's review of CT drafts
4) Resolve SEC-DIR issues (github issue 69) 
5) Pending Early Directorate reviews:  IANA (github issue 63) and TSV-DIR review
6) Check on nits issues (github issue 70)
7) Ask RTG-AD for normative/non-normative check.

## Document History

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

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/

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) IPR - Xiahou Xu - IPR statement for -27, Gyan statement on IPR
2) Implementation report clarified - where SRv6 is concerned.
3) link to Dhruv's review of CT drafts
4) Resolve SEC-DIR issues (github issue 69) 
5) Pending Early Directorate reviews:  IANA (github issue 63) and TSV-DIR review
6) Check on nits issues (github issue 70)
7) Ask RTG-AD for normative/non-normative check.

## Document History

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

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/
----
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/

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) IPR - Xiahou Xu - IPR statement for -27, Gyan statement on IPR
2) Implementation report clarified - where SRv6 is concerned.
3) link to Dhruv's review of CT drafts
4) Resolve SEC-DIR issues (github issue 69) 
5) Pending Early Directorate reviews:  IANA (github issue 63) and TSV-DIR review
6) Check on nits issues (github issue 70)
7) Ask RTG-AD for normative/non-normative check.

## Document History

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

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/
----
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/

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) IPR - Xiahou Xu - IPR statement for -27, Gyan statement on IPR
2) implementation report for CT-SRv6
3) link to Dhruv's review of CT drafts
4) Resolve SEC-DIR issues (https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/69) 
5) Pending: IANA and TSV-DIR review

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

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) IPR - Xiahou Xu - IPR statement for -27, Gyan statement on IPR
2) implementation report for CT-SRv6
3) link to Dhruv's review of CT drafts
4) Resolve SEC-DIR issues (https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/69) 
5) Pending: IANA and TSV-DIR review

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

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:
a) implementation report for ct-srv6
b) link to Dhruv's review of CT draft.
c)

## 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/
----
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 - see above, final one "has nits" 
  OPS-DIR reviews: 2 early reviews - see above, final one "has nits"
  SEC-DIR reviews: 2 early reviews - 6 problems + 4 questions for review - needs to 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 -26 [-27]
Kaliraj Vairavakkali (kaliraj@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/ZL7tOk3fgqeIRM5dfKfx_GbIh2w/

Natrajan Venkataraman (natv@juniper.net)

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

Csaba Mates (ietf@nop.hu)
[missing]

Deepak J. Gowda (dgowda@extremenetworks.com)
[missing]

Balaji Rajagoplan (balajir@juniper.net)
[missing]

Reshma Das (dreshma@juniper.net)
[missing]

Rajesh M (mrajesh@juniper.net)
[missing]

Chaitanya Yadlapalli (cy098d@att.com)
[missing]

Gyan Mishra (gyan.s.mishra@verizon.com)
[missing]

Mazen Khaddam (mazen.khaddam@cox.com)
[missing]

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

Xiaohu Xu (Captialonline)
[missing].


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

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

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

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

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

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

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

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

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

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

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

Need information:
a) implementation report for ct-srv6
b) link to Dhruv's review of CT draft.
c)

## 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/
----
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 - see above, final one "has nits" 
  OPS-DIR reviews: 2 early reviews - see above, final one "has nits"
  SEC-DIR reviews: 2 early reviews - 6 problems + 4 questions for review - needs to be resolved.
  TSV-DIR review:  1 early review requested - no response.
   
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]?

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

## Document Shepherd Checks

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

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

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

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

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

Natrajan Venkataraman (natv@juniper.net)

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

Csaba Mates (ietf@nop.hu)
[missing]

Deepak J. Gowda (dgowda@extremenetworks.com)
[missing]

Balaji Rajagoplan (balajir@juniper.net)
[missing]

Reshma Das (dreshma@juniper.net)
[missing]

Rajesh M (mrajesh@juniper.net)
[missing]

Chaitanya Yadlapalli (cy098d@att.com)
[missing]

Gyan Mishra (gyan.s.mishra@verizon.com)
[missing]

Mazen Khaddam (mazen.khaddam@cox.com)
[missing]

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

Xiaohu Xu (Captialonline)
[missing].


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

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

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

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

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

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

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

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

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

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

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

Need information:
a) implementation report for ct-srv6
b) link to Dhruv's review of CT draft.
c)

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

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


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

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

## Document Shepherd Checks

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

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

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

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

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

Natrajan Venkataraman (natv@juniper.net)

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

Csaba Mates (ietf@nop.hu)
[missing]

Deepak J. Gowda (dgowda@extremenetworks.com)
[missing]

Balaji Rajagoplan (balajir@juniper.net)
[missing]

Reshma Das (dreshma@juniper.net)
[missing]

Rajesh M (mrajesh@juniper.net)
[missing]

Chaitanya Yadlapalli (cy098d@att.com)
[missing]

Gyan Mishra (gyan.s.mishra@verizon.com)
[missing]

Mazen Khaddam (mazen.khaddam@cox.com)
[missing]

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

Xiaohu Xu (Captialonline)
[missing].


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

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

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

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

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

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

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

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

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

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

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

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

## Document History

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

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

Split discussions in 2nd WG LC:
https://mailarchive.ietf.org/arch/msg/idr/29CYvVl0RnW0hJSU3il3p_cqt80/

A Concern was raised by Robert Raszuk regarding the splitting of the
CT draft into 3 parts (draft-ietf-idr-bgp-ct, draft-ietf-idr-bgp-ct-srv6,
and draft-ietf-idr-bgp-fwd-rr).  He 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.  Due to Robert's concerns about being surprised as
WG draft were 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.

https://mailarchive.ietf.org/arch/msg/idr/29CYvVl0RnW0hJSU3il3p_cqt80/


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 has a normative dependencies on
draft-ietf-idr-salih-spring-srv6-inter-domain-sids.
-----
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.

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

Discomfort has been mention if the CAR and CT do not both progress to Experimental
at the same time.

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: [need info]

## Additional Reviews


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

  Reviews requested from PCE, Spring, and BESS prior to WG LC.
  Received reviews from PCE: [need link]

  Reviews not rec


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

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

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

## Document Shepherd Checks

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

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

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

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

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

Natrajan Venkataraman (natv@juniper.net)

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

Csaba Mates (ietf@nop.hu)
[missing]

Deepak J. Gowda (dgowda@extremenetworks.com)
[missing]

Balaji Rajagoplan (balajir@juniper.net)
[missing]

Reshma Das (dreshma@juniper.net)
[missing]

Rajesh M (mrajesh@juniper.net)
[missing]

Chaitanya Yadlapalli (cy098d@att.com)
[missing]

Gyan Mishra (gyan.s.mishra@verizon.com)
[missing]

Mazen Khaddam (mazen.khaddam@cox.com)
[missing]

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

Xiaohu Xu (Captialonline)
[missing].


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

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

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

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

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

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

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

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

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

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