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!