Early Review of draft-ietf-idr-nhc-00
review-ietf-idr-nhc-00-secdir-early-hardaker-2026-01-30-00

In general the document is well written and nicely done (and I recognize it's
not really a -00).  Only a couple of thoughts to consider:

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

- If you have A -> B -> C -> D and A sets an NHC with route R1, and B and C
don't understand NHC and thus just pass it on, the D could receive NHC
information that is incorrect and undetectable if B changes the route to R2 and
C changes it back to R1.  Whether or not this is a risk depends on the NHC of
course, but the text implies that this generally shouldn't be allowed.  But D's
validity checks for the NHC and BGPID will pass.

- "Characteristic TLVs MUST be placed in the NHC in increasing order", which is
followed by implementations must accept NHC in any order.  That probably means
it is a SHOULD not a MUST?  Because what's the downside of putting them in the
wrong order?  There is no penalty?

- you might put the BGPID reference at first use (top of 3)

- The IANA considerations should really only create the table and define the
values used in this document.  The other 4 drafts (values 1, 2, 4, 5) need to
have IANA sections that request the value the need.

- in security considerations I'd just remove "weak sense" -- it doesn't really
help too much and its up to others to determine the importance level

Cheers!