Re: [Idr] Narrowing the questions: Debate about IANA assignment policies for BGP-LS registries

["Les Ginsberg (ginsberg)" <[e-mail]>]

Adrian –

Please see inline.

From: Idr <[e-mail]> On Behalf Of Adrian Farrel
Sent: Friday, November 20, 2020 2:02 AM
To: [e-mail]
Cc: [e-mail]
Subject: [Idr] Narrowing the questions: Debate about IANA assignment policies for BGP-LS registries

Many thanks for the continued rapid progress and to Alvaro for pointing up another issue at the mic.

Although 7370 offers a template (which I’ll use) I would like to get answers to some very specific questions to narrow this down…


  1.  What do you want to require as the base reference?


1.       Do you want to limit allocations to come from *stable* WG drafts?
This is similar (as Alvaro notes) to RFC 7120 “Early Allocation” except it doesn’t invoke the AD.

[Les:] Stability is important, but its definition can be a bit elusive. I think it is important to remember what the goal of early allocation is. Since progressing to RFC is often a lengthy process in the IETF (for both good and bad reasons – but let’s not debate that here) and yet we like to have implementation/interoperability experience BEFORE WG last call, there is a practical need to allow early implementations to be deployed and yet avoid backwards compatibility issues with implementations which are compliant to the eventual RFC. So “stability” here really means that the objects for which early allocation is requested  are unlikely to change as the document progresses. This is to some extent a judgment call – which is why we need an “expert”. Allocating codepoints early and then having the form of those advertisements change such that the allocated codepoint is no longer relevant accomplishes nothing of value. The process here does not have to be infallible – but it should have a high rate of “success” (meaning the codepoint survives to the RFC). Otherwise you might as well do FCFS.



2.       Do you want to limit allocations to come from (any) WG drafts?
This is more relaxed than “Early Allocation” but we might have to handle when a draft is updated and changes the meaning of the code point. We might want IANA to the draft version for allocations. Or we could say that it is all work in progress so the meaning is always the most recent version of the draft.



[Les:] This would be my choice.



3.       Do you want to allow any I-D (includes WG and individual I-Ds)?
This moves closer to “First Come First Served” but requires some reference and the DE can check that it is “somewhat clear”.



[Les:] Not individual IDs. I think the RFC 7370 language is good here.



4.       Do you want to allow requests without I-Ds?
This is closest to “First Come First Served”, but I think I am hearing “no” to this question.

[Les:] No.


  1.  How much review do you want IDR to be allowed?


  1.  DE must see WG consensus for the allocation.
  2.  DE must see all issues from the WG addressed by author before allocation.
  3.  DE must have answers to all issues from the WG before allocation.
  4.  DE must “seriously listen” to comments.
[Les:] I think all of the points above can be relevant, but it is important to remember that early allocation is NOT equivalent to “the draft is done”.
There MUST, however, be a “shared belief”  that the codepoints are likely to survive as the draft progresses. Additional codepoints may be required, but we would like to avoid having to discard allocated codepoints as that means the goals of early allocation (see stability discussion above) won’t have been met.

How long should IDR be given to comment?

I think this resolves to two weeks in all cases.

[Les:] Seems adequate to me.

   Les

Thanks,
Adrian