BGP Next Hop Dependent Characteristics Attribute
draft-ietf-idr-nhc-07

[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-idr-nhc-06

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

# Many thanks Shepherd writeup from Sue Hares and the RTGDIR reviews from Mach Chen and Andrew Alston

# The document is well written, many thanks for your efforts on making this such a pleasure to read.

# COMMENTS
# ========

309   Due to the nature of BGP optional transitive path attributes, any BGP
310   speaker that does not implement this specification will propagate the
311   NHC, the requirements of this section notwithstanding.  Such a
312   speaker will not update the NHC, however.

GV> If NHC is implemented, does this imply that the functionality is automatically enabled by default?
Operators often prefer to explicitly enable new control-plane processing behavior rather than have it activated automatically. It may therefore be useful to clarify that an NHC speaker that does not support NHC, or has NHC support administratively disabled, will still propagate the NHC unchanged.

397   When a BGP speaker receives a BGP route that includes the NHC, it
398   MUST compare the address given in the header portion of the NHC and
399   illustrated in Figure 1 to the next hop of the BGP route.  If the two

GV> In section 2.2.1 is mentioned that in some cases the NH is not globally unique. In such situation the BGPID TLV should be used i suspect? Should this type of processing added? and what if there is a non-matching NH but a matching BGPID TLV? (similar line of thought as with my next review comment)

492 3.  BGP Identifier Characteristic

GV> The text seems to keep the door slightly open to attach a BGPID characteristic even with a globally unique NH. It does not forbid doing this. However doing so, the NHC has two potential datapoints to verify if NHC is valid or not for the route entry. In such situation, must the receiving router only look at the matching NH, or only at matching BGPID, or both? or is that considered as incorrect NHC?

Many thanks for this document,

Kind Regards,
Gunter Van de Velde
Routing AD

[Ballot comment]
I believe this document is well designed and appropriate for PS (I would have been concerned if this has tried to be Informational).

I support and will not spam the feedback from others. I will expand on Éric's point on SHOULDs in one particular paragraph. Some SHOULDs not having explanations are less of a big deal than others, but these truly need it to avoid edge case interoperability issues:

>  An implementation receiving routes with an NHC SHOULD NOT discard the
>  attribute or its contained characteristics by default.  An
>  implementation SHOULD provide configuration control of whether any
>  given characteristic is processed.  An implementation MAY provide
>  finer-grained control on propagation based on attributes of the
>  peering session, as discussed in Section 6.

[Ballot comment]
Section 2.2, paragraph 5
>    An implementation SHOULD propagate the NHC and its contained
>    characteristics by default.  An implementation SHOULD provide
>    configuration control of whether any given characteristic is
>    propagated.  An implementation MAY provide finer-grained control on
>    propagation based on attributes of the peering session, as discussed
>    in Section 6.

Éric Vyncke identified this on his ballot against -05; it does not appear
to have been addressed in -06. Several SHOULD statements do not identify
the conditions under which deviation is acceptable, as required by BCP 14.

Section 2.4, paragraph 1
>    A BGP UPDATE message with a malformed NHC SHALL be handled using the
>    approach of "attribute discard" defined in [RFC7606].

RFC 7606 Section 2 states that attribute discard "MUST NOT be used except
in the case of an attribute that has no effect on route selection or
installation," and Section 8 further states that where an attribute has
or may have a route selection effect, "the presumption is that discarding
it is unsafe unless careful analysis proves otherwise." Section 2.3 of
this document explicitly allows NHC characteristics to influence the route
selection (in the tunneling, EBGP, and configuration-enabled cases).
The document therefore, needs to carry out and record the "careful analysis."
that RFC 7606 requires as a precondition for using attribute discard.
The analysis is straightforward — discarding a malformed NHC is equivalent
to receiving the route without an NHC, which is a normal condition for
any router, so no forwarding or selection inconsistency results — but it
needs to be stated. Without it, the document's choice of attribute
discard is technically non-compliant with RFC 7606.

Section 2.4, paragraph 1
>    An NHC that contains no characteristic TLVs MAY be considered
>    malformed, although it is observed that the prescribed behavior of
>    "attribute discard" is semantically no different from that of having
>    no TLVs to process.  There is no reason to propagate an NHC that
>    contains no characteristic TLVs, and so such NHCs MUST NOT be further
>    propagated.

A receiver that does not exercise the MAY (i.e., treats the empty NHC
as not malformed) is still bound by the MUST NOT propagate. This is a
separate, independent prohibition that does not flow from the malformed/discard
handling of RFC 7606. The text would be clearer if it distinguished these
two paths explicitly: (a) if treated as malformed, apply attribute discard;
(b) if not treated as malformed, the NHC MUST still be silently dropped
and not propagated. Currently a reader could incorrectly infer that the MUST
NOT propagate is a consequence of the MAY malformed treatment.

Section 5, paragraph 3
>    Implementations are reported at the IDR implementation status Wiki
>    (https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-
>    entropy-label).

The URL in Section 5 — https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-entropy-label —
links to the implementation wiki for the entropy label draft, not for NHC.
This needs to be corrected to the NHC implementation page.

No reference entries found for these items, which were mentioned in the text:
[draft-ietf-idr-next-next], [draft-ietf-idr-entropy-label],
[draft-ietf-idr-bgp-generic], [draft-ietf-idr-elc-00], and
[draft-ietf-idr-bgp-ifit].

[Ballot comment]
Hi Bruno, Kireeti, Serge, Satya, John, Kevin, and Bin,

Thank you for the effort put in this specification. It was an interesting read to go through all the one decade I-Ds branches that lead to this effort.

The document is well-written and well-articulated, although there is a mix of protocol specifications and operational considerations (incremental deployment, configuration knobs, when special care is needed from those who deploy, log abnormal behavior, etc.) but that’s fine as far as these are there.

Please find some comments, fwiw:

# Initial values

I suggest we clarify the following:

## Add a mention that entries can be modified (deleted or content altered). This is to have a provision for some of these I-Ds to change the description if they want so or update the reference if any of these I-Ds make it to an RFC.

## The table does not track the document/event that led to a registration. For example, there is no visible information in the registry that indicates 1-2-4-5 are registered by this doc. Maybe add a note column to disclose that?

### Do we envisage in future having attributes that can be deprecated? If so, should that indication be supported by the registry (that is, add a status column)? 

# Mismatch

CURRENT:
      0                  1                  2                  3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Address Family Identifier  |    SAFI      | Next Hop Len  |
      +-------------------------------+---------------+---------------+
      |                                                              |
      ~            Network Address of Next Hop (variable)            ~
      |                                                              |
      +---------------------------------------------------------------+
      |                                                              |
      ~                Characteristic TLVs (variable)                ~
      |                                                              |
      +---------------------------------------------------------------+

                            Figure 1: NHC Format

  The meanings of the header fields (Address Family Identifier, SAFI or
  Subsequent Address Family Identifier, Length of Next Hop, and Network
  Address of Next Hop) are as given in Section 3 of [RFC4760].

## Mismatch between the figure and description for “Next Hop Len”.

## Please note that RFC4760 uses “Length of Next Hop Network Address”, not “Length of Next Hop” or “Next Hop Len”.

# Applicable only for NHC-aware routers

CURRENT:
  When a BGP speaker receives a BGP route that includes the NHC, it
  MUST compare the address given in the header portion of the NHC and
  illustrated in Figure 1 to the next hop of the BGP route. 

This seems to be assumed, but it is better to make it explicit this (and all Section 2.3) is discussing the behavior of NHC-aware routers.

# NHC Information

CURRENT:
  Since the NHC is intended chiefly for conveying information about
  forwarding plane features, it needs to be regenerated whenever the
  BGP route's next hop is changed. 

## There is nothing in the document that actually constrains the nature of information that can be conveyed in an NHC. The allocation FCFS policy won’t help rationalize that space.

## Having a more constrained range would be my favorite here (minimum Expert Review range).


# “potentially useful”

CURRENT:
  The NHC signals
  potentially useful information related to the forwarding plane
  features, so it is desirable to make it transitive to ensure

## I’m sure there is a reasoning behind that subtle mention, but this raises the questions as why one would announce something that isn’t useful?

## Shouldn’t we simply say:

NEW:
  The NHC signals
  information related to the forwarding plane
  features, so it is desirable to make it transitive to ensure

# Characteristic Code

CURRENT:
  Characteristic Code: a two-octet unsigned integer that indicates the
  type of characteristic advertised and unambiguously identifies an
  individual characteristic.

## Shouldn’t the description include a mention about “forwarding” as that is the intended use?

## I suggest to add a pointer to the registry

NEW:
  Values are taken from the registry (Section 4).

## As I’m there, the document is silent about sending reserved values

Consider adding text such as the following here or in Section 2.2:

NEW:
  By default, characteristics with Code set to a reserved value (Section 4)
  MUST NOT be used when sending an NHC.

“by default” is on purpose as this allows to relax the rule for experimentation or testing.

Alternatively, we may only cover 0 and 65535 cases:

NEW:
  Characteristics with Code set to 0 and 65535 MUST NOT be used when sending an NHC.

# Characteristic Value

CURRENT:
  Characteristic Length: a two-octet unsigned integer that indicates
  the length, in octets, of the Characteristic Value field.  A length
  of 0 indicates that the Characteristic Value field is zero-length,
  i.e., it has a null value.

  Characteristic Value: a variable-length field.  It is interpreted
  according to the value of the Characteristic Code.

Should Characteristic Value description say that it includes a non-null value to avoid having two ways to encode null values?

# Redundant behavior

2.2.1

  To mitigate this problem, if a BGP speaker constructs a route whose
  next hop has no global part, it MUST include a BGPID TLV (Section 3).

Vs.

3.2
  when a route
  includes only a link-local address and no global address, the BGPID
  MUST be included. 

I would keep the normative language in one single place.

# Picky

## Peer vs Peers

A BGP speaker may have several peers.

OLD:
  RFC 5492 allows a BGP speaker to advertise its capabilities to its
  peer.  When a route is propagated beyond the immediate peer, it is

NEW:
  RFC 5492 allows a BGP speaker to advertise its capabilities to its
  peers.  When a route is propagated beyond an immediate peer, it is

or

NEW2:
  RFC 5492 allows a BGP speaker to advertise its capabilities to a
  peer. When a route is propagated beyond an immediate peer, it is

A similar construct is also present in the introduction.

## Multiple ASNs

A speaker may have multiple ASNs.

OLD:
  AS Number: The Autonomous System Number [RFC6793]

NEW:
  AS Number: An Autonomous System Number [RFC6793]

## It is the ASN that is carried in the attribute

OLD: Autonomous System carried in the BGPID.

NEW: Autonomous System Number carried in the BGPID.

Cheers,
Med

[Ballot comment]
Thanks for the work done in this document.

Alas, the shepherd's write-up provides neither justification for the intended status not a good sensible explanation for the 6 authors.

I have also noticed several `SHOULD` (e.g., sections 2.2 & 2.3) without the required guidance per: https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/ (and this could be very important for interoperation !). I was about to ballot a DISCUSS on this point.

In section 4, add an informative reference to https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-2

I am afraid that draft-ietf-idr-elc is a *NORMATIVE* reference, so, let's remove all entries in section 4 that refer to draft documents.

IESG/Authors/WG Chairs:

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

IANA understands that, upon approval of this document, there are two actions that we must complete. We also have a question about the second action requested in this document.

First, in the BGP Path Attributes registry in the Border Gateway Protocol (BGP) Parameters registry group located at:

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

the early allocation for:

Value: 39
Code: BGP Next Hop Dependent Characteristic (NHC)

will be made permanent and its reference changed to [ RFC-to-be ].

Second, a new registry is to be created called the Next Hop Dependent Characteristic Codes registry. The new registry will be located in the Border Gateway Protocol (BGP) Parameters registry group located at:

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

The registry will be maintained in the following way (per RFC8126):

Value: 0 - Reserved
Values: 1 - 65399 - First Come, First Served
Values: 65400-65499 - Private Use
Values: 65500-65534 - Experimental Use
Value: 65535 - Reserved

There are initial registrations in the new registry as follows:

Value Description Change Controller Reference
-----+-----------+------------------+----------
0 Reserved IETF
1 ELCv3 IETF [draft-ietf-idr-elc]
2 NNHN kfwang@juniper.net [draft-wang-idr-next-next-hop-nodes]
3 BGPID IETF [ RFC-to-be ]
4 IFIT IETF [draft-ietf-idr-bgp-ifit-capabilities]
5 AMetric IETF [draft-ietf-idr-bgp-generic-metric]
6-65534 Unassigned
65535 Reserved

IANA Question -> Should the reference for value 2 be updated to draft-ietf-idr-next-next-hop-nodes and the change controller changed to the IETF? Additionally, IANA requests that the IANA Considerations of the above-referenced documents be updated to list the registration made in this new registry in a similar manner as draft-ietf-idr-bgp-ifit-capabilities-09.

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

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

For definitions of IANA review states, please see:

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

Thank you,

David Dong
IANA Services Sr. Specialist

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

From: The IESG
To: IETF-Announce
CC: draft-ietf-idr-nhc@ietf.org, idr-chairs@ietf.org, idr@ietf.org, ketant.ietf@gmail.com, shares@ndzh.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (BGP Next Hop Dependent Characteristics Attribute) to Proposed Standard


The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document: - 'BGP Next Hop Dependent Characteristics
Attribute'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2026-05-18. 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


  RFC 5492 allows a BGP speaker to advertise its capabilities to its
  peer.  When a route is propagated beyond the immediate peer, it is
  useful to allow certain characteristics to be conveyed further.  In
  particular, it is useful to advertise forwarding plane features.

  This specification defines a BGP transitive attribute to carry such
  information, the "Next Hop Dependent Characteristics Attribute," or
  NHC.  Unlike the capabilities defined by RFC 5492, the
  characteristics conveyed in the NHC apply solely to the routes
  advertised by the BGP UPDATE that contains the particular NHC.




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



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

Hares next steps:

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

## Document History

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

Strong concurrence. We had solid early reviews from RTG-DIR, SEC-DIR, OPS-DIR,
and individuals on the list. Any issues raised have been resolved by authors in -01.

RTG-DIR reviewer: Andrew Alston - issues, that were resolved
https://datatracker.ietf.org/doc/review-ietf-idr-nhc-00-rtgdir-early-alston-2026-02-03/
email: https://mailarchive.ietf.org/arch/msg/rtg-dir/Bc8IXgy8zhCMdkAPoK7t9n7Fclc/


In this review, Andrew states that:
"In section 2.5 of the draft, reference is made to anycast next-hops.  My
concern is that this text probably needs to be expanded to cover cases where
the next-hop is something indirectly resolved."

John responded with:
"Thanks for raising this point and for your patience while I got around to thinking and replying.
The issue you’ve raised is that the draft assumes the forwarding path has something to do with the next hop: "Since the NHC is intended chiefly for conveying information about forwarding plane features, it needs to be regenerated whenever the BGP route's next hop is changed.” But, sadly, there are various ways in BGP to have the forwarding path NOT follow the next hop, including the example you gave, the Tunnel Encapsulation Attribute, and almost certainly others as well."
Therefore, John wrote a paragraph about the issues with Tunnel Encapsulation Attribute.
John resolved this to Andrews Alston's satisfaction.

The shepherd thinks John's resolution is a reasonable one.

SEC-Dir reviewer: Wes Hardaker
https://datatracker.ietf.org/doc/review-ietf-idr-nhc-00-secdir-early-hardaker-2026-01-30/
Email: https://mailarchive.ietf.org/arch/msg/secdir/nLqb8oaRLpcIpUgVomebppfBGEs/

Wes raised the point:
"could colluding entities on either side of a NHC supporting device collude to
get it to reveal information about it's policies and habits (more than it could
without NHC)?"

OPS-DIR Reviewer: Giuseppe Fioccola - status ready with NITs and fix from John
https://mailarchive.ietf.org/arch/msg/idr/-t4E61Dj23EymsXdsnHp7fxdzsY/


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

The conversation on the draft had good review and good consensus.
The summary of the discussion includes:
1) Early Reviews note above (OPS-DIR, RTG-DIR, SEC-DIR)
1. Tom Petch mentioning a broken reference to draft-wang-idr-next-next-hop-nodes-01 and textual changes
2. OPS-DIR (review mentioned compliance to RFC5706bis (draft-ietf-opsawg-rfc5706bis-02)
John Scudder notes the temporal order of the creation of these drafts meant this draft was in final form
waiting for WG LC and implementations prior to this draft.

Call referenced:
WG LC initial call:
https://mailarchive.ietf.org/arch/msg/idr/DnsWUvtDxGGAMPFs0pwtcbsQV9M/

WG LC Extended:
https://mailarchive.ietf.org/arch/msg/idr/kLc8fb1-fow78-pvK3lSSLTeX-M/

Post WG LC Shepherd report:
https://mailarchive.ietf.org/arch/msg/idr/QLIaLuPwKaoRGXxU-54S8_i0fIM/


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

No.

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

Existing implementations: see https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-nhc
The amount of detail on this implementation page is impressive.

## 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.
RTG-DIR, OPS-DIR, SEC-DIR.  See comments above.

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

No formal reviews.

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

No formal reviews.

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

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?

The early review took into account issues related to routing, security, and operations.

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

Proposed standard. The BGP Next Hop Dependent Characteristics attribute
(NHC attribute, or just NHC) is an optional, transitive BGP path attribute with type code 39.
It augments [RFC4271], but does not modify it.

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.

IPR Statements from 7 authors:

Bruno Decraene
https://mailarchive.ietf.org/arch/msg/idr/DtOZjeUsgFef8Zbwco--o-Xqp9M/
Kireeti Kompella

Serge Krier
https://mailarchive.ietf.org/arch/msg/idr/AvdQg_0ZhC1pFVzAjsdj_q5o4UI/

Satya Mohanty
https://mailarchive.ietf.org/arch/msg/idr/7Dpg77ttyno4_DCX929R-fpYXCQ/

John Scudder
https://mailarchive.ietf.org/arch/msg/idr/4foGpV00mnqO3F_GhEdIbKWFChU/

Kevin Wang
https://mailarchive.ietf.org/arch/msg/idr/WQGFDysVq4zgrMM636BQIOwb6g4/

Bin Wen
https://mailarchive.ietf.org/arch/msg/idr/sANtu7cipsNDVxbLzoQNfRWKaGI/

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

yes.  The agreement to allow 7 authors was because the draft-ietf-idr-entropy-label
was the merge of two drafts (draft-scudder-idr-entropy-label, draft-ietf-idr-next-hop-capability).
We want to encourage these type of merges - so this shepherd has forwarded this to the IESG.

The merged draft of draft-ietf-idr-entropy-label was split to into
draft-ietf-idr-nhc-01 and draft-ietf-idr-nlc.  Only draft-ietf-idr-nhc-00
had two implementations and a decision was made to progress draft-ietf-idr-nhc-01.
See https://datatracker.ietf.org/doc/draft-ietf-idr-entropy-label/

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

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

All reference are IETF RFCs or drafts.

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

No.

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

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

No.

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

I reviewed the section, and I asked IANA to do an early review.

  IANA is requested to create a new registry called "BGP Next Hop
  Dependent Characteristic Codes" within the Border Gateway Protocol
  (BGP) Parameters group.  The registry's allocation policy is First
  Come, First Served, except where designated otherwise in Table 2
  in the document.

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.

  Only a FCFS registry.



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

Hares next steps:

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

## Document History

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

Strong concurrence. We had solid early reviews from RTG-DIR, SEC-DIR, OPS-DIR,
and individuals on the list. Any issues raised have been resolved by authors in -01.

RTG-DIR reviewer: Andrew Alston - issues, that were resolved
https://datatracker.ietf.org/doc/review-ietf-idr-nhc-00-rtgdir-early-alston-2026-02-03/
email: https://mailarchive.ietf.org/arch/msg/rtg-dir/Bc8IXgy8zhCMdkAPoK7t9n7Fclc/


In this review, Andrew states that:
"In section 2.5 of the draft, reference is made to anycast next-hops.  My
concern is that this text probably needs to be expanded to cover cases where
the next-hop is something indirectly resolved."

John responded with:
"Thanks for raising this point and for your patience while I got around to thinking and replying.
The issue you’ve raised is that the draft assumes the forwarding path has something to do with the next hop: "Since the NHC is intended chiefly for conveying information about forwarding plane features, it needs to be regenerated whenever the BGP route's next hop is changed.” But, sadly, there are various ways in BGP to have the forwarding path NOT follow the next hop, including the example you gave, the Tunnel Encapsulation Attribute, and almost certainly others as well."
Therefore, John wrote a paragraph about the issues with Tunnel Encapsulation Attribute.
John resolved this to Andrews Alston's satisfaction.

The shepherd thinks John's resolution is a reasonable one.

SEC-Dir reviewer: Wes Hardaker
https://datatracker.ietf.org/doc/review-ietf-idr-nhc-00-secdir-early-hardaker-2026-01-30/
Email: https://mailarchive.ietf.org/arch/msg/secdir/nLqb8oaRLpcIpUgVomebppfBGEs/

Wes raised the point:
"could colluding entities on either side of a NHC supporting device collude to
get it to reveal information about it's policies and habits (more than it could
without NHC)?"

OPS-DIR Reviewer: Giuseppe Fioccola - status ready with NITs and fix from John
https://mailarchive.ietf.org/arch/msg/idr/-t4E61Dj23EymsXdsnHp7fxdzsY/


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

The conversation on the draft had good review and good consensus.
The summary of the discussion includes:
1) Early Reviews note above (OPS-DIR, RTG-DIR, SEC-DIR)
1. Tom Petch mentioning a broken reference to draft-wang-idr-next-next-hop-nodes-01 and textual changes
2. OPS-DIR (review mentioned compliance to RFC5706bis (draft-ietf-opsawg-rfc5706bis-02)
John Scudder notes the temporal order of the creation of these drafts meant this draft was in final form
waiting for WG LC and implementations prior to this draft.

Call referenced:
WG LC initial call:
https://mailarchive.ietf.org/arch/msg/idr/DnsWUvtDxGGAMPFs0pwtcbsQV9M/

WG LC Extended:
https://mailarchive.ietf.org/arch/msg/idr/kLc8fb1-fow78-pvK3lSSLTeX-M/

Post WG LC Shepherd report:
https://mailarchive.ietf.org/arch/msg/idr/QLIaLuPwKaoRGXxU-54S8_i0fIM/


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

No.

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

Existing implementations: see https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-nhc
The amount of detail on this implementation page is impressive.

## 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.
RTG-DIR, OPS-DIR, SEC-DIR.  See comments above.

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

No formal reviews.

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

No formal reviews.

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

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?

The early review took into account issues related to routing, security, and operations.

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

Proposed standard. The BGP Next Hop Dependent Characteristics attribute
(NHC attribute, or just NHC) is an optional, transitive BGP path attribute with type code 39.
It augments [RFC4271], but does not modify it.

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.

IPR Statements from 7 authors:

Bruno Decraene
https://mailarchive.ietf.org/arch/msg/idr/DtOZjeUsgFef8Zbwco--o-Xqp9M/
Kireeti Kompella

Serge Krier
https://mailarchive.ietf.org/arch/msg/idr/AvdQg_0ZhC1pFVzAjsdj_q5o4UI/

Satya Mohanty
https://mailarchive.ietf.org/arch/msg/idr/7Dpg77ttyno4_DCX929R-fpYXCQ/

John Scudder
https://mailarchive.ietf.org/arch/msg/idr/4foGpV00mnqO3F_GhEdIbKWFChU/

Kevin Wang
https://mailarchive.ietf.org/arch/msg/idr/WQGFDysVq4zgrMM636BQIOwb6g4/

Bin Wen
https://mailarchive.ietf.org/arch/msg/idr/sANtu7cipsNDVxbLzoQNfRWKaGI/

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

yes.  The agreement to allow 7 authors was because the draft-ietf-idr-entropy-label
was the merge of two drafts (draft-scudder-idr-entropy-label, draft-ietf-idr-next-hop-capability).
We want to encourage these type of merges - so this shepherd has forwarded this to the IESG.

The merged draft of draft-ietf-idr-entropy-label was split to into
draft-ietf-idr-nhc-01 and draft-ietf-idr-nlc.  Only draft-ietf-idr-nhc-00
had two implementations and a decision was made to progress draft-ietf-idr-nhc-01.
See https://datatracker.ietf.org/doc/draft-ietf-idr-entropy-label/

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

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

All reference are IETF RFCs or drafts.

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

No.

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

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

No.

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

I reviewed the section, and I asked IANA to do an early review.

  IANA is requested to create a new registry called "BGP Next Hop
  Dependent Characteristic Codes" within the Border Gateway Protocol
  (BGP) Parameters group.  The registry's allocation policy is First
  Come, First Served, except where designated otherwise in Table 2
  in the document.

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.

  Only a FCFS registry.



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

Hares next steps:

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

## Document History

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

Strong concurrence. We had solid early reviews from RTG-DIR, SEC-DIR, OPS-DIR,
and individuals on the list. Any issues raised have been resolved by authors in -01.

RTG-DIR reviewer: Andrew Alston - issues, that were resolved
https://datatracker.ietf.org/doc/review-ietf-idr-nhc-00-rtgdir-early-alston-2026-02-03/
email: https://mailarchive.ietf.org/arch/msg/rtg-dir/Bc8IXgy8zhCMdkAPoK7t9n7Fclc/


In this review, Andrew states that:
"In section 2.5 of the draft, reference is made to anycast next-hops.  My
concern is that this text probably needs to be expanded to cover cases where
the next-hop is something indirectly resolved."

John responded with:
"Thanks for raising this point and for your patience while I got around to thinking and replying.
The issue you’ve raised is that the draft assumes the forwarding path has something to do with the next hop: "Since the NHC is intended chiefly for conveying information about forwarding plane features, it needs to be regenerated whenever the BGP route's next hop is changed.” But, sadly, there are various ways in BGP to have the forwarding path NOT follow the next hop, including the example you gave, the Tunnel Encapsulation Attribute, and almost certainly others as well."
Therefore, John wrote a paragraph about the issues with Tunnel Encapsulation Attribute.
John resolved this to Andrews Alston's satisfaction.

The shepherd thinks John's resolution is a reasonable one.

SEC-Dir reviewer: Wes Hardaker
https://datatracker.ietf.org/doc/review-ietf-idr-nhc-00-secdir-early-hardaker-2026-01-30/
Email: https://mailarchive.ietf.org/arch/msg/secdir/nLqb8oaRLpcIpUgVomebppfBGEs/

Wes raised the point:
"could colluding entities on either side of a NHC supporting device collude to
get it to reveal information about it's policies and habits (more than it could
without NHC)?"

OPS-DIR Reviewer: Giuseppe Fioccola - status ready with NITs and fix from John
https://mailarchive.ietf.org/arch/msg/idr/-t4E61Dj23EymsXdsnHp7fxdzsY/


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

The conversation on the draft had good review and good consensus.
The summary of the discussion includes:
1) Early Reviews note above (OPS-DIR, RTG-DIR, SEC-DIR)
1. Tom Petch mentioning a broken reference to draft-wang-idr-next-next-hop-nodes-01 and textual changes
2. OPS-DIR (review mentioned compliance to RFC5706bis (draft-ietf-opsawg-rfc5706bis-02)
John Scudder notes the temporal order of the creation of these drafts meant this draft was in final form
waiting for WG LC and implementations prior to this draft.

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

No.

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

existing implementations: see https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-nhc
You fine a lot of detail on this implementation page is impressive.

## 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.
RTG-DIR, OPS-DIR, SEC-DIR.  See comments above.

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

No formal reviews.

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

No formal reviews.

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

Yes. 

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?

See early review took into account the issues from routing, security, and operations.
Well done!!

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

Proposed standard. The BGP Next Hop Dependent Characteristics attribute
(NHC attribute, or just NHC) is an optional, transitive BGP path attribute with type code 39.
It augments [RFC4271], but does not modify it.

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.

IPR Statements from 7 authors:

Bruno Decraene
https://mailarchive.ietf.org/arch/msg/idr/DtOZjeUsgFef8Zbwco--o-Xqp9M/
Kireeti Kompella

Serge Krier
https://mailarchive.ietf.org/arch/msg/idr/AvdQg_0ZhC1pFVzAjsdj_q5o4UI/

Satya Mohanty
https://mailarchive.ietf.org/arch/msg/idr/7Dpg77ttyno4_DCX929R-fpYXCQ/

John Scudder
https://mailarchive.ietf.org/arch/msg/idr/4foGpV00mnqO3F_GhEdIbKWFChU/

Kevin Wang
https://mailarchive.ietf.org/arch/msg/idr/WQGFDysVq4zgrMM636BQIOwb6g4/

Bin Wen
https://mailarchive.ietf.org/arch/msg/idr/sANtu7cipsNDVxbLzoQNfRWKaGI/

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

yes.  The agreement to allow 7 authors was because the draft-ietf-idr-entropy-label
was the merge of two drafts (draft-scudder-idr-entropy-label, draft-ietf-idr-next-hop-capability).
We want to encourage these type of merges.

The merged draft of draft-ietf-idr-entropy-label was split to into
draft-ietf-idr-nhc-01 and draft-ietf-idr-nlc.  Only draft-ietf-idr-nhc-00
had two implementations and a decision was made to progress draft-ietf-idr-nhc-01.
See https://datatracker.ietf.org/doc/draft-ietf-idr-entropy-label/

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

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
All reference are IETF RFCs or drafts.

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

No.

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

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

No.

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

Asking for an Early review of IANA of this text. 

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

Hares next steps:

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

## Document History

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

Strong concurrence. We had solid early reviews from RTG-DIR, SEC-DIR, OPS-DIR,
and individuals on the list. Any issues raised have been resolved by authors in -01.

RTG-DIR reviewer: Andrew Alston - issues, that were resolved
https://datatracker.ietf.org/doc/review-ietf-idr-nhc-00-rtgdir-early-alston-2026-02-03/
email: https://mailarchive.ietf.org/arch/msg/rtg-dir/Bc8IXgy8zhCMdkAPoK7t9n7Fclc/


In this review, Andrew states that:
"In section 2.5 of the draft, reference is made to anycast next-hops.  My
concern is that this text probably needs to be expanded to cover cases where
the next-hop is something indirectly resolved."

John responded with:
"Thanks for raising this point and for your patience while I got around to thinking and replying.
The issue you’ve raised is that the draft assumes the forwarding path has something to do with the next hop: "Since the NHC is intended chiefly for conveying information about forwarding plane features, it needs to be regenerated whenever the BGP route's next hop is changed.” But, sadly, there are various ways in BGP to have the forwarding path NOT follow the next hop, including the example you gave, the Tunnel Encapsulation Attribute, and almost certainly others as well."
Therefore, John wrote a paragraph about the issues with Tunnel Encapsulation Attribute.
John resolved this to Andrews Alston's satisfaction.

The shepherd thinks John's resolution is a reasonable one.

SEC-Dir reviewer: Wes Hardaker
https://datatracker.ietf.org/doc/review-ietf-idr-nhc-00-secdir-early-hardaker-2026-01-30/
Email: https://mailarchive.ietf.org/arch/msg/secdir/nLqb8oaRLpcIpUgVomebppfBGEs/

Wes raised the point:
"could colluding entities on either side of a NHC supporting device collude to
get it to reveal information about it's policies and habits (more than it could
without NHC)?"

OPS-DIR Reviewer: Giuseppe Fioccola - status ready with NITs and fix from John
https://mailarchive.ietf.org/arch/msg/idr/-t4E61Dj23EymsXdsnHp7fxdzsY/


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

The conversation on the draft had good review and good consensus.
The summary of the discussion includes:
1) Early Reviews note above (OPS-DIR, RTG-DIR, SEC-DIR)
1. Tom Petch mentioning a broken reference to draft-wang-idr-next-next-hop-nodes-01 and textual changes
2. OPS-DIR (review mentioned compliance to RFC5706bis (draft-ietf-opsawg-rfc5706bis-02)
John Scudder notes the temporal order of the creation of these drafts meant this draft was in final form
waiting for WG LC and implementations prior to this draft.

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

No.

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

existing implementations: see https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-nhc
You fine a lot of detail on this implementation page is impressive.

## 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.
RTG-DIR, OPS-DIR, SEC-DIR.  See comments above.

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

No formal reviews.

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

No formal reviews.

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

Yes. 

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?

See early review took into account the issues from routing, security, and operations.
Well done!!

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

Proposed standard. The BGP Next Hop Dependent Characteristics attribute
(NHC attribute, or just NHC) is an optional, transitive BGP path attribute with type code 39.
It augments [RFC4271], but does not modify it.

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.

IPR Statements from 7 authors:

Bruno Decraene
https://mailarchive.ietf.org/arch/msg/idr/DtOZjeUsgFef8Zbwco--o-Xqp9M/
Kireeti Kompella

Serge Krier
https://mailarchive.ietf.org/arch/msg/idr/AvdQg_0ZhC1pFVzAjsdj_q5o4UI/

Satya Mohanty
https://mailarchive.ietf.org/arch/msg/idr/7Dpg77ttyno4_DCX929R-fpYXCQ/

John Scudder
https://mailarchive.ietf.org/arch/msg/idr/4foGpV00mnqO3F_GhEdIbKWFChU/

Kevin Wang
https://mailarchive.ietf.org/arch/msg/idr/WQGFDysVq4zgrMM636BQIOwb6g4/

Bin Wen
https://mailarchive.ietf.org/arch/msg/idr/sANtu7cipsNDVxbLzoQNfRWKaGI/

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

yes.  The agreement to allow 7 authors was because the draft-ietf-idr-entropy-label
was the merge of two drafts (draft-scudder-idr-entropy-label, draft-ietf-idr-next-hop-capability).
We want to encourage these type of merges.

The merged draft of draft-ietf-idr-entropy-label was split to into
draft-ietf-idr-nhc-01 and draft-ietf-idr-nlc.  Only draft-ietf-idr-nhc-00
had two implementations and a decision was made to progress draft-ietf-idr-nhc-01.
See https://datatracker.ietf.org/doc/draft-ietf-idr-entropy-label/

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

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
All reference are IETF RFCs or drafts.

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

No.

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

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

No.

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

Asking for an Early review of IANA of this text. 

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

Hares next steps:

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

## Document History

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

Strong concurrence. We had solid early reviews from RTG-DIR, SEC-DIR, OPS-DIR,
and individuals on the list. Any issues raised have been resolved by authors in -01.

RTG-DIR reviewer: Andrew Alston - issues, that were resolved
https://datatracker.ietf.org/doc/review-ietf-idr-nhc-00-rtgdir-early-alston-2026-02-03/
email: https://mailarchive.ietf.org/arch/msg/rtg-dir/Bc8IXgy8zhCMdkAPoK7t9n7Fclc/


In this review, Andrew states that:
"In section 2.5 of the draft, reference is made to anycast next-hops.  My
concern is that this text probably needs to be expanded to cover cases where
the next-hop is something indirectly resolved."

John responded with:
"Thanks for raising this point and for your patience while I got around to thinking and replying.
The issue you’ve raised is that the draft assumes the forwarding path has something to do with the next hop: "Since the NHC is intended chiefly for conveying information about forwarding plane features, it needs to be regenerated whenever the BGP route's next hop is changed.” But, sadly, there are various ways in BGP to have the forwarding path NOT follow the next hop, including the example you gave, the Tunnel Encapsulation Attribute, and almost certainly others as well."
Therefore, John wrote a paragraph about the issues with Tunnel Encapsulation Attribute.

John resolved this to Andrews Alston's satisfaction.


SEC-Dir reviewer: Wes Hardaker
https://datatracker.ietf.org/doc/review-ietf-idr-nhc-00-secdir-early-hardaker-2026-01-30/
Email: https://mailarchive.ietf.org/arch/msg/secdir/nLqb8oaRLpcIpUgVomebppfBGEs/

Wes raised the point:
"could colluding entities on either side of a NHC supporting device collude to
get it to reveal information about it's policies and habits (more than it could
without NHC)?"

OPS-DIR Reviewer: Giuseppe Fioccola - status ready with NITs and fix from John
https://mailarchive.ietf.org/arch/msg/idr/-t4E61Dj23EymsXdsnHp7fxdzsY/


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

The conversation on the draft had good review and good consensus.
The summary of the discussion includes:
1. Tom Petch mentioning a broken reference to draft-wang-idr-next-next-hop-nodes-01 and textual changes
2. OPS-DIR (review mentioned compliance to RFC5706bis (draft-ietf-opsawg-rfc5706bis-02)
John Scudder notes the temporal order of the creation of these drafts meant this draft was in final form
waiting for WG LC and implementations prior to this draft.
3. RTG-DIR review - A
In section 2.5 of the draft, reference is made to anycast next-hops.  My
concern is that this text probably needs to be expanded to cover cases where
the next-hop is something indirectly resolved.

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

No.

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

existing implementations: see https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-nhc
You fine a lot of detail on this implementation page is impressive.

## 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.
RTG-DIR, OPS-DIR, SEC-DIR. 

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.

IPR Statements from 7 authors:

Bruno Decraene
https://mailarchive.ietf.org/arch/msg/idr/DtOZjeUsgFef8Zbwco--o-Xqp9M/
Kireeti Kompella

Serge Krier
https://mailarchive.ietf.org/arch/msg/idr/AvdQg_0ZhC1pFVzAjsdj_q5o4UI/

Satya Mohanty
https://mailarchive.ietf.org/arch/msg/idr/7Dpg77ttyno4_DCX929R-fpYXCQ/

John Scudder
https://mailarchive.ietf.org/arch/msg/idr/4foGpV00mnqO3F_GhEdIbKWFChU/

Kevin Wang
https://mailarchive.ietf.org/arch/msg/idr/WQGFDysVq4zgrMM636BQIOwb6g4/

Bin Wen
https://mailarchive.ietf.org/arch/msg/idr/sANtu7cipsNDVxbLzoQNfRWKaGI/

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

yes.  The agreement to allow 7 authors was because the draft-ietf-idr-entropy-label
was the merge of two drafts (draft-scudder-idr-entropy-label, draft-ietf-idr-next-hop-capability).
We want to encourage these type of merges.

The merged draft of draft-ietf-idr-entropy-label was split to into
draft-ietf-idr-nhc-01 and draft-ietf-idr-nlc.  Only draft-ietf-idr-nhc-00
had two implementations and a decision was made to progress draft-ietf-idr-nhc-01.
See https://datatracker.ietf.org/doc/draft-ietf-idr-entropy-label/

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

Hares next steps:

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

## Document History

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

Strong concurrence. 

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

The conversation on the draft had good review and good consensus.
The summary of the discussion includes:
1. Tom Petch mentioning a broken reference to draft-wang-idr-next-next-hop-nodes-01 and textual changes
2. 

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

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

## Additional Reviews

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

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

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

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

## Document Shepherd Checks

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

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

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

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

IPR Statements from 7 authors:

Bruno Decraene
https://mailarchive.ietf.org/arch/msg/idr/DtOZjeUsgFef8Zbwco--o-Xqp9M/
Kireeti Kompella

Serge Krier
https://mailarchive.ietf.org/arch/msg/idr/AvdQg_0ZhC1pFVzAjsdj_q5o4UI/

Satya Mohanty
https://mailarchive.ietf.org/arch/msg/idr/7Dpg77ttyno4_DCX929R-fpYXCQ/

John Scudder
https://mailarchive.ietf.org/arch/msg/idr/4foGpV00mnqO3F_GhEdIbKWFChU/

Kevin Wang
https://mailarchive.ietf.org/arch/msg/idr/WQGFDysVq4zgrMM636BQIOwb6g4/

Bin Wen
https://mailarchive.ietf.org/arch/msg/idr/sANtu7cipsNDVxbLzoQNfRWKaGI/

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

yes.  The agreement to allow 7 authors was because the draft-ietf-idr-entropy-label
was the merge of two drafts (draft-scudder-idr-entropy-label, draft-ietf-idr-next-hop-capability).
We want to encourage these type of merges.

The merged draft of draft-ietf-idr-entropy-label was split to into
draft-ietf-idr-nhc-01 and draft-ietf-idr-nlc.  Only draft-ietf-idr-nhc-00
had two implementations and a decision was made to progress draft-ietf-idr-nhc-01.
See https://datatracker.ietf.org/doc/draft-ietf-idr-entropy-label/

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

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

## Document History

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

Strong concurrence. 

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

The conversation on the draft had good review and good consensus.
The summary of the discussion includes:
1. Tom Petch mentioning a broken reference to draft-wang-idr-next-next-hop-nodes-01 and textual changes
2. 

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

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

## Additional Reviews

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

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

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

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

## Document Shepherd Checks

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

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

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

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

IPR Statements from 7 authors:

Bruno Decraene
https://mailarchive.ietf.org/arch/msg/idr/DtOZjeUsgFef8Zbwco--o-Xqp9M/
Kireeti Kompella

Serge Krier
https://mailarchive.ietf.org/arch/msg/idr/AvdQg_0ZhC1pFVzAjsdj_q5o4UI/

Atya Mohanty

John Scudder

Kevin Wang
https://mailarchive.ietf.org/arch/msg/idr/WQGFDysVq4zgrMM636BQIOwb6g4/

Bin Wen

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

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

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

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

## Document History

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

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

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

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

## Additional Reviews

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

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

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

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

## Document Shepherd Checks

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

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

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

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

IPR Statements from 7 authors:

Bruno Decraene
https://mailarchive.ietf.org/arch/msg/idr/DtOZjeUsgFef8Zbwco--o-Xqp9M/
Kireeti Kompella

Serge Krier
https://mailarchive.ietf.org/arch/msg/idr/AvdQg_0ZhC1pFVzAjsdj_q5o4UI/

Atya Mohanty

John Scudder

Kevin Wang
https://mailarchive.ietf.org/arch/msg/idr/WQGFDysVq4zgrMM636BQIOwb6g4/

Bin Wen

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

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

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

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

## Document History

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

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

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

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

## Additional Reviews

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

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

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

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

## Document Shepherd Checks

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

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

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

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

IPR Statements from 7 authors:

Bruno Decraene
https://mailarchive.ietf.org/arch/msg/idr/DtOZjeUsgFef8Zbwco--o-Xqp9M/
Kireeti Kompella
Serge Krier
https://mailarchive.ietf.org/arch/msg/idr/AvdQg_0ZhC1pFVzAjsdj_q5o4UI/

Atya Mohanty

John Scudder

Kevin Wang
https://mailarchive.ietf.org/arch/msg/idr/WQGFDysVq4zgrMM636BQIOwb6g4/

Bin Wen

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

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

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

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

## Document History

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

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

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

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

## Additional Reviews

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

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

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

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

## Document Shepherd Checks

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

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

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

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

IPR Statements from 7 authors:

Bruno Decraene
https://mailarchive.ietf.org/arch/msg/idr/DtOZjeUsgFef8Zbwco--o-Xqp9M/

Kireeti Kompella
Serge Krier
ATYA R MOHANTY
John Scudder
Kevin Wang
Bin Wen

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

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

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

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

## Document History

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

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

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

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

## Additional Reviews

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

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

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

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

## Document Shepherd Checks

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

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

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

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

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

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

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

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

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

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

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

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

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

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