[Idr] Re: draft-ietf-idr-nhc-00 early Secdir review

[Jeffrey Haas <[e-mail]>]

Wes,

> On Feb 6, 2026, at 09:29, Wes Hardaker <[e-mail]> wrote:
>> The security considerations in section 5.1 do mention that it's up to
>> the operator whether this attribute is carried between ASes.
> 
> Yes, but the default is to carry onward anything unknown.
> 
> Whether or not it is harmful in any way (including information
> revealing) depends on what is being carried, which also means predicting
> the future of the potential attributes.

Completely agreed.  And it's very much in the purview of security and operational considerations review to say if the recommended defaults are clear enough, or not, and what such defaults should be.  Please feel free to check that section to see if it passes your review scrutiny there.

Our biggest headache is that such enforcement can only happen at systems that are aware of the feature.  Otherwise, standard BGP procedures will mean it leaks anyway.  Thus, the most critical thing (IMO) is that the feature is safe when escape happens.  After that, sane defaults for when enforcement works.  Similarly, if there are confidentiality considerations... well, that's messy for new BGP features right now.

> 
>> We will, of course, take IANA's advice about the assignments outside
>> of this document during the editing process. Since the values are all
>> FCFS, moving them out of the document and immediately into the newly
>> created registry could happen.
> 
> Certainly IANA can help with guidance.  My (just personal) view is that
> they should be added in the document they're created in, because there
> isn't assurance that the other document will actually get to the point
> of publishing or implementation.  Thus, the parent document could end up
> reserving a value that never becomes used.

When IANA is the registry, we don't have any headaches.  They're the source of truth, and the gatekeeper of authorization.

Prior to the registry being in IANA, we need a single point of truth.  The owning document for the registry is what we've been suggesting for such things in IDR for both truth and "authorization".  

The best answer is we get the early registration procedures in ianabis moved forward:
https://datatracker.ietf.org/doc/draft-ietf-ianabis-rfc8126bis/

-- Jeff