Subject: [Idr] Robert Wilton's No Objection on draft-ietf-idr-bgp-ls-registry-04: (with COMMENT)

From: Robert Wilton via Datatracker <[email-masked]>
Date: Mon, 22 Mar 2021 03:19:29 -0700

Robert Wilton has entered the following ballot position for
draft-ietf-idr-bgp-ls-registry-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-registry/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi,

Thank you for this document.

My first observation on this document is that it does not really explain why
this change is being made.  I think that it would be helpful  for readers if
the introduction briefly explained why the allocation policy is being changed.

However, I have the same concern that Martin raised, i.e., this uses an IANA
"Expert Review" classification where the instructions to follow are broadly
"IETF Review" or "Standards Action", and I don't understand why one of those
classifications isn't being used instead.

Section 4.11 of RFC8216 explains that the use of well-known policies aids
community experience and wide understanding, and that the policies are in
increasing order of strictness.  But the use of "Expert Review" does not match
what I would naturally expect that IANA policy to mean.

Regards,
Rob

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 22 Mar 2021 11:16:43 -0000

Hi Rob,

Thanks for chatting.

> the introduction briefly explained why the allocation policy is being changed.

Answer is similar to that I gave Martin: we don't normally explain how we chose IANA policies in our documents, although there is often heated and confused debate about which policies to apply and how large ranges should be.

In this specific case, as pen-holder, I'm not sure I can put my finger on exactly why the WG felt it important to change, only that this is the result they wanted to end up with.

But...

> classifications isn't being used instead.

Both "IETF Review" and "Standards Action" generally require completion of the RFC process before allocation can be made. This is annoying for implementers in registries where new codepoints are being assigned thick and fast. It encourages squatting and conflicts.
The "Early Allocation" procedures allow this to be salvaged, but those procedures come at a cost that the WG thought was too much:
- the document making the assignment must be a WG document
- the WG document must be "stable"
- early allocations must be renewed yearly with the intent of a 2-year maximum
OTOH, "Expert Review" allows assignment to be made once only, and also for "less mature" documents.

But...

> what I would naturally expect that IANA policy to mean.

I think it is not commonly understood that for "Expert Review", "The required documentation and review criteria, giving clear guidance to the designated expert, should be provided when defining the registry" [RFC8126]. Very many legacy registries don't have proper guidance for the DEs, but it is a fundamental part of the concept of "Expert Review" and this can be gauged by the size of Section 5 of RFC 8216 (10% of the whole document).

In terms of increasing order of strictness, do you think that this document has elevated "Expert Review" above the next category which is "Specification Required"? There is a debate to be had here about whether "Specification Required" includes the use of an Internet-Draft when it says "permanent and readily available public specification". This seems to me to be a Big Debate (TM) that the IESG might want to lead the IETF community through, but perhaps one that we don't want to use to gate the progression of this document. FWIW the arguments seem to centre around:
- can an expired I-D be found in a permanent and definitive repository?
- does the registry include the revision number for an I-D?
- the I-D contains boilerplate explicitly stating that it is inappropriate to reference it
- 8126 suggests that an RFC is an ideal means of meeting the requirement

But apart from that, 8126 says that "Specification Required" is the same as "Expert Review" with the addition of the requirement for a publicly available and stable spec.

I don't think that this document brings "Expert Review" close to the next in line which is "RFC Required".

So, all these words written and in brief, is there any action we should take for this document?

Cheers,
Adrian

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 22 Mar 2021 13:08:19 +0000

Hi Adrian,

Please see inline ...

> -----Original Message-----
> From: Adrian Farrel <[email-masked]>
> Sent: 22 March 2021 11:17
> To: Rob Wilton (rwilton) <[email-masked]>; 'The IESG' <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]; 'Susan Hares' <[email-masked]>; 'Jie Dong'
> <[email-masked]>; [email-masked]
> Subject: RE: Robert Wilton's No Objection on draft-ietf-idr-bgp-ls-
> registry-04: (with COMMENT)
> 
> Hi Rob,
> 
> Thanks for chatting.
> 
> Answer is similar to that I gave Martin: we don't normally explain how we
> chose IANA policies in our documents, although there is often heated and
> confused debate about which policies to apply and how large ranges should
> be.
> 
> In this specific case, as pen-holder, I'm not sure I can put my finger on
> exactly why the WG felt it important to change, only that this is the
> result they wanted to end up with.
[RW] 

Okay.

> Both "IETF Review" and "Standards Action" generally require completion of
> the RFC process before allocation can be made. This is annoying for
> implementers in registries where new codepoints are being assigned thick
> and fast. It encourages squatting and conflicts.
> The "Early Allocation" procedures allow this to be salvaged, but those
> procedures come at a cost that the WG thought was too much:
[RW] 

   8.  In the event that the document is a Working Group document or is
       AD Sponsored, and that document fails to progress to publication
       as an RFC, the Working Group chairs or AD SHOULD contact IANA to
       coordinate about marking the code points as deprecated.  A
       deprecated code point is not marked as allocated for use and is
       not available for allocation in a future document.  The WG chairs
       may inform IANA that a deprecated code point can be completely
       de-allocated (i.e., made available for new allocations) at any
       time after it has been deprecated if there is a shortage of
       unallocated code points in the registry.

But in section 2.1, step 8 (text above), my interpretation is that the expert review assignment is effectively only temporary until the document gets published as an RFC, and otherwise the assignment gets undone.  I.e., I still regard this approach as being a broadly equivalent approach to IETF Review + Early allocation.

> I think it is not commonly understood that for "Expert Review", "The
> required documentation and review criteria, giving clear guidance to the
> designated expert, should be provided when defining the registry"
> [RFC8126]. Very many legacy registries don't have proper guidance for the
> DEs, but it is a fundamental part of the concept of "Expert Review" and
> this can be gauged by the size of Section 5 of RFC 8216 (10% of the whole
> document).
> 
> In terms of increasing order of strictness, do you think that this
> document has elevated "Expert Review" above the next category which is
> "Specification Required"?
[RW] 
My interpretation from reading this document was that it is logically equivalent to IETF Review + IANA early allocation, but aiming to have less IANA early allocation process overhead.

But it may depend on how this paragraph is interpreted:

   2.  The Designated Experts SHOULD only consider requests that arise
       from I-Ds that have already been accepted as Working Group
       documents or that are planned for progression as AD Sponsored
       documents in the absence of a suitably chartered Working Group.

I.e., what are the scenarios when the above SHOULD it not a MUST?  Is the intent here to allow a non WG draft to have a code point assigned?  Or is the intent that a non IETF organization is allowed to request an allocation (if the IDR WG agrees, as per step 4)?

 There is a debate to be had here about whether
> "Specification Required" includes the use of an Internet-Draft when it
> says "permanent and readily available public specification". This seems to
> me to be a Big Debate (TM) that the IESG might want to lead the IETF
> community through, but perhaps one that we don't want to use to gate the
> progression of this document. FWIW the arguments seem to centre around:
> But apart from that, 8126 says that "Specification Required" is the same
> as "Expert Review" with the addition of the requirement for a publicly
> available and stable spec.
> 
[RW] 

Hum, it is interesting that I seem to have quite a different interpretation!

But perhaps the difference is when the allocations are made vs under what circumstances allocations are allowed to be made.

> So, all these words written and in brief, is there any action we should
[RW] 

Obviously, I think that getting clarity on what the actual rules mean is probably important.

But otherwise, I intend to wait and see what the rest of the IESG thinks of the approach being taken here.  BTW, if you know it, please can you share the reference to the ISIS RFC that you cited as a precedent for this approach.

Thanks,
Rob

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 22 Mar 2021 13:43:55 -0000

> BTW, if you know it, please can you share the reference to the ISIS RFC that you cited as a precedent for this approach.

7370

A