Guidance to Avoid Carrying RPKI Validation States in BGP Path Attributes
draft-ietf-sidrops-avoid-rpki-state-in-bgp-10

[Ballot discuss]
Thanks to the authors and the WG for this document that provides important and useful guidance to the Internet Routing community.

I have a few points that I would like to discuss:

The document puts forth the view that all EBGP sessions are between providers on the Internet and ignores the part that several provider networks comprise of more than one AS (sometimes also private AS) where EBGP session is within a single administrative domain. IMHO this oversimplification of the current deployments makes it harder for a wider community out there to correctly interpret and follow the guidance in this document. I would like to discuss if some text can be added to this document to cover such deployments.

RFC9087 does realize it and covers it as follows in section 2:
"An example of a case where the community would reasonably be received from, or sent to, an EBGP peer is when two adjacent ASes are under control of the same administration."

Section 2 (Scope) of this document does touch upon some recommendations for "internal signaling changes" but again assumes that this is only happening between IBGP speakers. This, perhaps, would be a good section to clarify the carveout on similar lines as the text from RFC9087? Then the rest of the document does not need to be changed.

This point is similar to one raised by Mahesh and hence I support his point as well.

Applicability to only transitive or all BGP Path Attributes.

The title explicitly says transitive. The abstract drops transitive entirely. The introduction also does not use it consistently except when it comes to discussion of communities. Similar is the case with the rest of the document. There is a need to tighten the use of the correct terminology.

Note that attribute transitivity is orthogonal to IBGP/EBGP - this is for extended community transitivity which is a separate thing. Refer https://www.ietf.org/archive/id/draft-haas-idr-bgp-attribute-escape-04.html#section-2

That said, I understand that the issue being identified could also happen with non-transitive attributes and then this becomes about all BGP attributes?

All of this is perhaps best explained in the Scope section.  There may be other ways to achieve use of consistent terminologies. It would be good to discuss this.

I have a related suggestion to use only communities as an example for all the content in section 3 and its sub-sections. From a quick check, I get that is what has been observed out in the wild. This would leave a smaller portion of the document to check for consistent use of the terms we are discussing.

One related, subtle but important, aspect that perhaps also needs coverage is that while the Extended Communities Attribute is transitive, the extended communities themselves may be either transitive or non-transitive. I am asking because it helps determine whether this BCP is overruling RFC8097 or not.

[Ballot comment]
I also have two other comment to offer:

1) Include IPv6-address specific community attribute

123   Attributes carried across external BGP sessions.  Specifically,
124   operators should not associate BGP Prefix Origin Validation results
125   [RFC6811] with BGP routes using transitive community or community-
126   like attributes, including:

128   *  BGP Communities [RFC1997],

130   *  transitive BGP Extended Communities [RFC4360],

Please also add RFC5701 above

2) The references to ASPA and SPL seems to be normative based on how they are referenced in some place in this document. I would suggest removing those references from the document except in section 2 where the reference is phrased as an example.

[Ballot discuss]
Section 2, paragraph 0
>    This document discusses signaling locally significant RPKI validation
>    states through BGP Path Attributes propagated to EBGP neighbors.
>    This includes operator-specific BGP Communities to signal validation
>    states, as well as any current or future standardized well-known BGP
>    Communities denoting validation states.  As BGP message churn is
>    associated with internal signaling changes, it is RECOMMENDED that
>    operators also consider the guidance (Section 5) within their
>    network, i.e., between their IBGP speakers.

RFC 8097 defines the BGP non-transitive opaque extended community
(type 0x43) for signaling RPKI validation state. Its normative
text states:

- Implementations SHOULD attach the community to IBGP UPDATE messages
- By default, SHOULD NOT send to EBGP peers
- By default, MUST drop if received from EBGP
- EBGP use is explicitly permitted when adjacent ASes share administrative
  control or in route-server scenarios

This document creates two unacknowledged conflicts:

IBGP: Section 2's RECOMMENDED guidance (apply Section 5 guidance to
IBGP as well) directly contradicts RFC 8097's SHOULD for IBGP use.
Operators have contradictory SHOULD-level guidance from two documents,
with no basis to resolve it.

EBGP exceptions: RFC 8097 explicitly permits—and provides configuration
guidance for—EBGP use in shared-administration and route-server scenarios.
This document's Section 5 "SHOULD NOT signal... across EBGP sessions"
covers these scenarios without acknowledgment.

The Shepherd write-up confirms the WG discussed RFC 8097 in WGLC and
decided not to reference it. That decision is not tenable: the document
creates normative guidance that conflicts with a Proposed Standard,
and the conflict must be explicitly addressed.

The options are: reference RFC 8097 and explain the relationship;
carry "Updates: RFC 8097" if superseding its IBGP recommendation
and EBGP exceptions; or narrow the Section 2 IBGP recommendation to
avoid the contradiction.

[Ballot comment]
Section 3.1.1, paragraph 2
>    *  When an operator issues new ROAs for their netblocks, possibly by
>      issuing one ROA with a non-minimal maxLength (Section 4.3.2.2 of
>      [RFC9582]) covering a large number of prefixes.  This may also
>      occur when incorrectly migrating to minimally covering ROAs
>      ([RFC9319]).  One example of such a circumstance is when the
>      previous ROA is first revoked (see Section 3.1.2) and the new ROAs
>      are only issued after this revocation has been propagated (due to
>      an operational error or a bug in the issuance pipeline).

Netblock is used in this section and in 3.1.2 and 4 without definition.
Replace with "prefix" or "address block." (Also flagged by Routing AD Gunter
Van de Velde.)

Section 4, paragraph 3
>    *  Avoids having to resend, e.g., more than 500,000 BGP routes
>      towards BGP neighbors (for the own customer cone towards peers and
>      providers, for the full table towards customers) if the RPKI cache
>      crashes and RTR sessions are terminated, or if flaps in validation
>      are caused by other events.

The 500,000-route figure is below the current global table size (>1M prefixes).
The February 2024 percentage data in Section 3.4 is a point-in-time
measurement. Adding a note that these represent data at time of writing
would help to get a better picture.

Section 5, paragraph 1
>    The document acknowledges that specific operational requirements,
>    such as a BGP implementation used by an operator still being
>    dependent on annotating RPKI-derived validation states using BGP Path
>    Attributes, may necessitate the use of BGP path attributes to signal
>    validation states between BGP speakers.  If this is the case, the
>    dependent operator MUST ensure that these attributes are removed
>    before announcing Network Layer Reachability Information (NLRI) to
>    EBGP neighbors.  Depending on the supported functionality of the BGP
>    implementations in use in a given AS, removal of the aforementioned
>    attributes may not be consistently possible across the AS, leading to
>    the conditions this document is intended to discuss.

"between BGP speakers" should read "between IBGP speakers within the
same AS" — as written it could be read to include EBGP, conflicting with
the preceding SHOULD NOT. (Also flagged by BGPDIR reviewer by John
Scudder, thanks John.)

[Ballot comment]
Thank you for this work. It is an interesting read and well written text.

Could you add a few words in the doc what the reader should understand when the term 'netblock' is used?

Thank you,
Gunter Van de Velde,
Routing AD

[Ballot comment]
Thank you to Paul Kyzivat for the GENART review.

** Section 1
  In the past, some operators and vendors suggested to use BGP
  Communities ([RFC1997] and [RFC8092]) to annotate received routes
  with validation states local to a router.  Some claim that the
  practice of signaling validation states could be useful,

-- Where are/have these claims being made?

-- Who are these parties referenced by “some claim …”?

** Section 3.1.3
  While, in general, implementations should not have bugs, operators
  should not make mistakes, and the network should be reliable, this is
  usually not the case in practice. 

Isn’t it a false premise that hypothetical software stack or operators don’t make mistakes/have bugs?

# Document History

Document: https://datatracker.ietf.org/doc/draft-ietf-sidrops-avoid-rpki-state-in-bgp/

Title: Guidance to Avoid Carrying RPKI Validation States in Transitive BGP Path Attributes

Revision: draft-ietf-sidrops-avoid-rpki-state-in-bgp-07

Shepherd: Luigi Iannone (ggx@gigix.net)

Writeup Template: https://datatracker.ietf.org/doc/shepherdwriteup-template/workinggroup



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?

    Working Group Last Call on the mailing list shows a broad support for this document.

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

    Consensus has been reached via considerate discussion throughout the whole WGLC. One point has been raised about the need to reference RFC 8097, but decision was that no direct reference to such document is necessary (see: https://mailarchive.ietf.org/arch/msg/last-call/I5g6_7LJccw9Qqnz2x2d4PBB1CA/).

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

    No one showed any form of discontent.

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

    This is not a protocol document. It is a Best Current Practice document on how to operate existing implementations.


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

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

    No formal review is required.

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

    This document does not contain a YANG Module.

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.

    The document does not contain anything written in a formal language, hence, no validation and/or check has been performed.


# Document Shepherd Checks

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

    The document is clearly written, needed, and ready to be handed off to the responsible AD.

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

    The document does not touch any ops issue.

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

    This document requests to be published as Best Current Practice. BCP is the right intended status as the document includes operational guidance and current thoughts of the community to avoid leaking RPKI validation state in BGP transitive attributes, and thus preserve the stability of the global Internet routing system.

    Both the Datatracker and front page show the intended status. 

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

    All the co-authors, did state explicitly that they are not aware of any IPR related to this document. No one else did any IPR disclosure. 

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.

    Each co-author is clearly willing to be listed as such.

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

    The idnits shows a warning about non-ascii characters. This can be fixed later on.

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

    No reference should change type.

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

    There is no reference with restricted access. 

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

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

    No normative references are in unclear state or not ready.

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.

    This document does not change the status of any existing RFC. 

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

    The IANA considerations section does not contain any action.

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.

    The is no new registries requiring Expert Review created in this document.

The following Last Call announcement was sent out (ends 2026-05-27):

From: The IESG
To: IETF-Announce
CC: draft-ietf-sidrops-avoid-rpki-state-in-bgp@ietf.org, ggx@gigix.net, mohamed.boucadair@orange.com, sidrops-chairs@ietf.org, sidrops@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Guidance to Avoid Carrying RPKI Validation States in Transitive BGP Path Attributes) to Best Current Practice


The IESG has received a request from the SIDR Operations WG (sidrops) to
consider the following document: - 'Guidance to Avoid Carrying RPKI
Validation States in Transitive BGP
  Path Attributes'
  as Best Current Practice

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

Abstract


  This document provides guidance to avoid carrying Resource Public Key
  Infrastructure (RPKI) derived validation states in transitive Border
  Gateway Protocol (BGP) Path Attributes.  Annotating routes with
  transitive attributes signaling validation states may cause needless
  flooding of BGP UPDATE messages through the global Internet routing
  system, for example when Route Origin Authorizations (ROAs) are
  issued, or are revoked, or when RPKI-To-Router sessions are
  terminated.

  Operators should ensure RPKI-derived validation states are not
  signaled in transitive BGP Path Attributes.  Specifically, Operators
  should not associate Prefix Origin Validation state with BGP routes
  using transitive BGP Communities.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sidrops-avoid-rpki-state-in-bgp/



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

# Document History

Document: https://datatracker.ietf.org/doc/draft-ietf-sidrops-avoid-rpki-state-in-bgp/

Title: Guidance to Avoid Carrying RPKI Validation States in Transitive BGP Path Attributes

Revision: draft-ietf-sidrops-avoid-rpki-state-in-bgp-05

Shepherd: Luigi Iannone (ggx@gigix.net)

Writeup Template: https://datatracker.ietf.org/doc/shepherdwriteup-template/workinggroup



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?

    Working Group Last Call on the mailing list shows a broad support for this document.

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

    No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

    No one showed any form of discontent.

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

    The document itself has a section reporting at least five implementations.


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

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

    No formal review is required.

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

    This document does not contain a YANG Module.

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.

    The document does not contain anything written in a formal language, hence, no validation and/or check has been performed.


# Document Shepherd Checks

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

    The document is clearly written, needed, and ready to be handed off to the responsible AD.

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

    The document does not touch any ops issue.

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

    This document requests to be published as Best Current Practice. BCP is the right intended status as the document includes operational guidance and current thoughts of the community to avoid leaking RPKI validation state in BGP transitive attributes, and thus preserve the stability of the global Internet routing system.

  Both the Datatracker and front page show the intended status. 

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

    All the co-authors, did state explicitly that they are not aware of any IPR related to this document. No one else did any IPR disclosure. 

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.

    Each co-author is clearly willing to be listed as such.

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

    The idnits shows a warning about non-ascii characters. This can be fixed later on.

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

    No reference should change type.

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

    There is no reference with restricted access. 

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

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

    No normative references are in unclear state or not ready.

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.

    This document does not change the status of any existing RFC. 

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

    The IANA considerations section does not contain any action.

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.

    The is no new registries requiring Expert Review created in this document.

# Document History

Document: https://datatracker.ietf.org/doc/draft-ietf-sidrops-avoid-rpki-state-in-bgp/

Title: Guidance to Avoid Carrying RPKI Validation States in Transitive BGP Path Attributes

Revision: draft-ietf-sidrops-avoid-rpki-state-in-bgp-05

Shepherd: Luigi Iannone (ggx@gigix.net)

Writeup Template: https://datatracker.ietf.org/doc/shepherdwriteup-template/workinggroup



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?

    Working Group Last Call on the mailing list shows a broad support for this document.

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

    No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

    No one showed any form of discontent.

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

    The document itself has a section reporting at least five implementations.


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

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

    No formal review is required.

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

    This document does not contain a YANG Module.

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.

    The document does not contain anything written in a formal language, hence, no validation and/or check has been performed.


# Document Shepherd Checks

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

    The document is clearly written, needed, and ready to be handed off to the responsible AD.

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

    The document does not touch any ops issue.

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

    This document request to be published as Best Current Practice and it is the right intended status. Datatracker shows the intended status. 

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

    All the co-authors, did state explicitly that they are not aware of any IPR related to this document. No one else did any IPR disclosure. 

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.

    Each co-author is clearly willing to be listed as such.

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

    The idnits shows a warning about non-ascii characters. This can be fixed later on.

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

    No reference should change type.

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

    There is no reference with restricted access. 

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

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

    No normative references are in unclear state or not ready.

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.

    This document does not change the status of any existing RFC. 

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

    The IANA considerations section does not contain any action.

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.

    The is no new registries requiring Expert Review created in this document.

# Document History

Document: https://datatracker.ietf.org/doc/draft-ietf-sidrops-avoid-rpki-state-in-bgp/

Title: Guidance to Avoid Carrying RPKI Validation States in Transitive BGP Path Attributes

Revision: draft-ietf-sidrops-avoid-rpki-state-in-bgp-05

Shepherd: Luigi Iannone (ggx@gigix.net)

Writeup Template: https://datatracker.ietf.org/doc/shepherdwriteup-template/workinggroup



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?

    Working Group Last Call on the mailing list shows a broad support for this document.

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

    No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

    No one showed any form of discontent.

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

    The document itself has a section reporting at least five implementations.


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

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

    No formal review is required.

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

    This document does not contain a YANG Module.

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.

    The document does not contain anything written in a formal language, hence, no validation and/or check has been performed.


# Document Shepherd Checks

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

    The document is clearly written, needed, and ready to be handed off to the responsible AD.

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

    The document does not touch any ops issue.

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

    This document request to be published as Best Current Practice and it is the right intended status. Datatracker shows the intended status. 

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

    All the co-authors, did state explicitly that they are not aware of any IPR related to this document. No one else did any IPR disclosure. 

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.

    Each co-author is clearly willing to be listed as such.

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

    The idnits shows a warning about non-ascii characters. This can be fixed later on.

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

    No reference should change type.

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

    There is no reference with restricted access. 

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

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

    No normative references are in unclear state or not ready.

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.

    This document does not change the status of any existing RFC. 

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

    The IANA considerations section does not contain any action.

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.

    The is no new registries requiring Expert Review created in this document.