Subject: [Idr] Lars Eggert's Discuss on draft-ietf-idr-bgp-ls-registry-04: (with DISCUSS and COMMENT)

From: Lars Eggert via Datatracker <[email-masked]>
Date: Wed, 24 Mar 2021 12:09:18 -0700

Lars Eggert has entered the following ballot position for
draft-ietf-idr-bgp-ls-registry-04: Discuss

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I'm putting in a "discuss" DISCUSS that I expect to clear during the
call. Several other ADs raised issues that deserve discussion. While they may
not fall under the "discuss criteria", they also don't fall under the "discuss
non-criteria" and I want to make sure we spent some time on discussing them.

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

Section 2.1, paragraph 4, comment:
>    In all cases of review by the Designated Expert (DE) described here,
>    the DE is expected to check the clarity of purpose and use of the
>    requested code points.  The following points apply to the registries
>    discussed in this document:
>

The process outlined in the rest of this section seems to define rules that are
basically equivalent to doing an RFC7120 "early allocation" for these
registries. Why is that existing process not sufficient?

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 24 Mar 2021 19:39:00 -0000

Hi Lars,

> non-criteria" and I want to make sure we spent some time on discussing them.

That's perfectly reasonable. 

I wish there was a way for the IESG to table something for discussion without using the "Discuss a document" hook which makes the authors (and the watchers) feel that *they* should be part of the discussion. But, anyway, it seems that there is something here that the IESG needs to discuss, so "whatever works."

> registries. Why is that existing process not sufficient?

It achieves a similar end with some slight variations. I can't speak for the WG as to why they preferred this approach, but:
- 7120 requires a stable WG I-D. Thus:
   - an early WG I-D doesn't qualify
   - a non-WG I-D doesn't qualify
   - a non-IETF document doesn't qualify
- 7120 allocations have to be renewed
   - this is extra effort 
   - only one renewal is allowed unless the IESG is invoked "under rare circumstances"
   - the code point "expires" if someone forgets to renew

Cheers,
Adrian

---

From: Lars Eggert <[email-masked]>
Date: Wed, 24 Mar 2021 22:56:20 +0200

Hi,

> I wish there was a way for the IESG to table something for discussion without using the "Discuss a document" hook which makes the authors (and the watchers) feel that *they* should be part of the d…

I wish so, too, but we're limited by the current toolchain here, as you know. I guess I could have put an explicit "non-ADs ignore this" into the text above...

>   - an early WG I-D doesn't qualify

RFC7120 requires:

   c.  The specifications of these code points must be stable; i.e., if
       there is a change, implementations based on the earlier and later
       specifications must be seamlessly interoperable.

It seems one would want this sort of stability here, too?

>   - a non-WG I-D doesn't qualify

It's not clear to me that RFC7120 requires this. Also, this document says "SHOULD only consider requests that arise from I-Ds that have already been accepted as Working Group documents..." which is a similar limitation.

>   - a non-IETF document doesn't qualify

RFC7120 also applies to "Specification Required" registries for which no IETF document is needed.

>   - the code point "expires" if someone forgets to renew

Fair point. But this document defines a mechanism whereby chairs and the ADs are tasked to remember to make IANA deprecate the codepoints when a document isn't published (or I guess published with incompatible changes to the revision for which the allocation was made). That seems to suffer from similar drawbacks.

Thanks,
Lars

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 25 Mar 2021 11:54:29 +0000

Hello,

I believe Adrian has made all these points already in his responses on these threads, and so perhaps this is just an effort at summarizing them for the IESG Discussion. 

(Request the WG Chairs to correct if they see this different from the WG consensus view).

1) The "Specification Required" policy is currently in place for this registry per RFC7752. The WG was informed that Internet-Drafts (even WG drafts) do not meet the criteria of "permanent and readily available" thanks to the boiler-plate text (below) that exists in Internet-Drafts. i.e. WG could not get IANA allocations based on WG drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

2) As a result of (1), the WG has had to follow the early allocation procedures of RFC7120 for a large set of allocations and documents (BGP-LS is a bit busy!). IDR requires 2 implementations to publish drafts as RFCs. Things take time. The WG, chairs, AD and in some cases the IESG have to do a lot of process work to retain the allocations when there are delays in getting to publication.

3) The WG was looking for IANA allocation based on WG documents. With the guidance of WG chairs, our AD and participants with more experience in IANA allocations, we (the WG) took a step back to "Expert Review" so as to avoid the early allocation process overheads. Please note that we have sufficient code-point space.

4) The guidance to DE was only improved/enhanced but that, IMHO, is more secondary in nature and something that happened over the course of review of the document to improve it.

Finally, thanks again to Adrian for coming up with the solution (i.e. the draft) and taking it through the process for the WG!

Thanks,
Ketan 

-----Original Message-----
From: Idr <[email-masked]> On Behalf Of Lars Eggert
Sent: 25 March 2021 02:26
To: [email-masked]
Cc: [email-masked]; [email-masked]; The IESG <[email-masked]>; [email-masked]; Susan Hares <[email-masked]>
Subject: Re: [Idr] Lars Eggert's Discuss on draft-ietf-idr-bgp-ls-registry-04: (with DISCUSS and COMMENT)

Hi,

On 2021-3-24, at 21:39, Adrian Farrel <[email-masked]> wrote:
>> call. Several other ADs raised issues that deserve discussion. While 
>> they may not fall under the "discuss criteria", they also don't fall 
>> under the "discuss non-criteria" and I want to make sure we spent some time on discussing them.
> 

>> The process outlined in the rest of this section seems to define 
>> rules that are basically equivalent to doing an RFC7120 "early 
>> allocation" for these registries. Why is that existing process not sufficient?
> 

RFC7120 requires:

Thanks,
Lars

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 25 Mar 2021 12:51:45 +0000

To summarize my thoughts on this:

This document works around an issue rather than fixing it at source.  I.e., is every WG going to have these registry change documents to change their registries to Expert Review to make early allocation easier?  This seems like it will create a lot of unnecessary process work & RFCs, and I think that it will muddy the waters for what the registry classifications actually mean.

So, I think that the IETF needs to figure out how to make the process of getting IANA assignments easier for the WGs.

Given that IDR is finding this process to be unnecessarily burdensome now, and we don't know how long, or even if, IETF will find a general solution, then I'm supportive of the general efforts to streamline their process for producing technical standards now.

Hence, my preference is to publish now, but we should work out how to fix this properly before we get a flood of similar documents.

Regards,
Rob

> From: iesg <[email-masked]> On Behalf Of Ketan Talaulikar (ketant)
> Sent: 25 March 2021 11:54
> To: Lars Eggert <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]; Susan Hares <[email-masked]>; [email-masked]
> Subject: RE: [Idr] Lars Eggert's Discuss on draft-ietf-idr-bgp-ls-
> registry-04: (with DISCUSS and COMMENT)
> 
> Hello,
> 
> I believe Adrian has made all these points already in his responses on
> these threads, and so perhaps this is just an effort at summarizing them
> for the IESG Discussion.
> 
> 1) The "Specification Required" policy is currently in place for this
> registry per RFC7752. The WG was informed that Internet-Drafts (even WG
> drafts) do not meet the criteria of "permanent and readily available"
> thanks to the boiler-plate text (below) that exists in Internet-Drafts.
> i.e. WG could not get IANA allocations based on WG drafts.
> 
> 2) As a result of (1), the WG has had to follow the early allocation
> procedures of RFC7120 for a large set of allocations and documents (BGP-LS
> is a bit busy!). IDR requires 2 implementations to publish drafts as RFCs.
> Things take time. The WG, chairs, AD and in some cases the IESG have to do
> a lot of process work to retain the allocations when there are delays in
> getting to publication.
> 
> 3) The WG was looking for IANA allocation based on WG documents. With the
> guidance of WG chairs, our AD and participants with more experience in
> IANA allocations, we (the WG) took a step back to "Expert Review" so as to
> avoid the early allocation process overheads. Please note that we have
> sufficient code-point space.
> 
> 4) The guidance to DE was only improved/enhanced but that, IMHO, is more
> secondary in nature and something that happened over the course of review
> of the document to improve it.
> 
> Finally, thanks again to Adrian for coming up with the solution (i.e. the
> draft) and taking it through the process for the WG!
> 
> Thanks,
> Ketan
> 
> Cc: [email-masked]; [email-masked]; The IESG <[email-masked]>; draft-
> [email-masked]; Susan Hares <[email-masked]>
> > I wish there was a way for the IESG to table something for discussion
> without using the "Discuss a document" hook which makes the authors (and
> the watchers) feel that *they* should be part of the discussion. But,
> anyway, it seems that there is something here that the IESG needs to
> discuss, so "whatever works."
> 
> I wish so, too, but we're limited by the current toolchain here, as you
> know. I guess I could have put an explicit "non-ADs ignore this" into the
> text above...
> 
> 
> > COMMENT:
> >>
> > It achieves a similar end with some slight variations. I can't speak for
> the WG as to why they preferred this approach, but:
> It's not clear to me that RFC7120 requires this. Also, this document says
> "SHOULD only consider requests that arise from I-Ds that have already been
> accepted as Working Group documents..." which is a similar limitation.
> 
> Fair point. But this document defines a mechanism whereby chairs and the
> ADs are tasked to remember to make IANA deprecate the codepoints when a
> document isn't published (or I guess published with incompatible changes
> to the revision for which the allocation was made). That seems to suffer
> from similar drawbacks.
> 
> Thanks,
> Lars

---

From: Lars Eggert <[email-masked]>
Date: Thu, 25 Mar 2021 15:14:31 +0200

Hi,

> Hence, my preference is to publish now, but we should work out how to fix this properly before we get a flood of similar documents.

that is a reasonable way forward.

To scope this potential revision of RFC7120, let's briefly make sure we capture the issues that at least IDR has identified, so someone has a starting point to work off of:

- would like early allocation for specs before they are "stable"
  - open question on what to do about non-interoperable changes?

- would like to do early allocation for non-IETF specs

- would like early allocations to not time out
  - or at least time out much later than after one year?
  - for large registries, may not need to deprecate outdated early allocations at all
  - for others, task chairs/ADs; is this workable?
    - how would we do this last point for non-IETF specs?

Thanks,
Lars

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 25 Mar 2021 08:38:35 -0500

On March 25, 2021 at 8:52:00 AM, Rob Wilton wrote:

Hi!

We can talk more at the Telechat, but here are more thoughts.

In the end, the WG wants better oversight and more flexibility.

> This document works around an issue rather than fixing it at source. I.e., is
> every WG going to have these registry change documents to change their
> registries to Expert Review to make early allocation easier?

I know that the process of early allocation keeps coming up.  But it
is more than that.  rfc7120 says this in §2 (Conditions for Early
Allocation):

   ...requests for early assignment of code points from a "Specification
   Required" registry are allowed if the specification will be published as
   an RFC.

This point tightens the consideration around when, and to what, should
an early allocation be made, as well as the source of the request.

As mentioned, idr has a strict 2-implementation policy: work won't
progress unless there are two implementations, implementations need
codepoints, codepoints can be allocated "if the specification will be
published as an RFC", but we need implementations to make sure the
document will advance, which require codepoints, etc..

Also, given the use of BGP-LS, which carries information towards a
"consumer" (rfc7752) (aka controller), the potential sources of
information desired increases to include potential work from outside
the IETF -- work that may never be published as an RFC, but which
might require an early allocation.  For example, a significant amount
of BGP-LS extensions come from the in-house development of ISIS/OSPF,
but ISIS is already actively being used by IEEE in SPB (802.1aq) --
the IETF version of L2 routing is trill (we already closed the WG) --
with deployed implementations of both, it is possible that requests
will be made...but rfc7120 doesn't allow for early allocation (unless
"the specification will be published as an RFC"), regardless of
whether the process can be made easier or not (unless that requirement
is removed, of course).

I believe that the implementation requirement + allocation flexibility
is not common to all WGs.  Solving "the problem" for idr (BGP-LS
specifically) may not end up working for everyone else.  One size
doesn't always have to fit all.

We can achieve both better oversight (through the experts + WG review)
*and* more flexibility with the "Expert Review" policy.  I don't
believe we can get there without this document unless we change the
allocation policies for everyone.

Thanks!

Alvaro.

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 25 Mar 2021 13:39:36 +0000

Hi Lars/Rob,

The point was about "final" allocation under "Specification Required" scheme and the ability of the WG to do that using WG documents before they become RFCs. The "Specification Required" does not seem to consider Internet-Drafts as "permanent and readily available".

The issue was not really with early allocation and RFC7120. Very likely that process is suitable for other areas/WGs. The WG felt that the early allocation process was onerous when it came to BGP-LS specs.

Thanks,
Ketan

-----Original Message-----
From: Lars Eggert <[email-masked]> 
Sent: 25 March 2021 18:45
To: Rob Wilton (rwilton) <[email-masked]>
Cc: Ketan Talaulikar (ketant) <[email-masked]>; The IESG <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; Susan Hares <[email-masked]>; [email-masked]
Subject: Re: [Idr] Lars Eggert's Discuss on draft-ietf-idr-bgp-ls-registry-04: (with DISCUSS and COMMENT)

Hi,

Thanks,
Lars

---

From: John Scudder <[email-masked]>
Date: Thu, 25 Mar 2021 13:23:19 +0000

On Mar 24, 2021, at 4:56 PM, Lars Eggert <[email-masked]<mailto:[email-masked]>> wrote:

RFC7120 requires:

I think the answer is the same as for 7120: if the specification is changed in a non-interoperable way, the old code point must be deprecated and a new one allocated. Fortunately the affected registries are for large spaces so it’s not necessary to be extremely conservative with allocating code points — unlike with a small space, it’s perfectly fine to anticipate that some allocations will be deprecated in the course of developing the spec. (I mean, let’s not do it just for fun!)

On Mar 25, 2021, at 8:51 AM, Rob Wilton (rwilton) <rwilton=[email-masked]<mailto:rwilton=[email-masked]>> wrote:

I agree with this.

—John

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 25 Mar 2021 10:15:37 -0400

Ketan and IESG:

<WG chair hat on> 
Ketan has correctly summarized the WG discussion.  The WG goal is to enable
the 2 implementations to occur prior to standardization, and to allow the
implementations to keep those values. 

If other WGs have not seen this problem, perhaps it is because they do not
require 2 implementation before standardization.  We are adding this
additional registry work to make this process easier for the implementers. 
<WG chair hat off>

[personal opinion] 
If the process occasion creates a conflict, I believe it is worth the risk.
It is critical to get early implementations of protocols with stable values.
Running code and rough consensus is a slogan I truly believe in.  

Sue 

-----Original Message-----
From: Ketan Talaulikar (ketant) [mailto:[email-masked]] 
Sent: Thursday, March 25, 2021 7:54 AM
To: Lars Eggert; The IESG
Cc: [email-masked]; [email-masked];
[email-masked]; Susan Hares; [email-masked]
Subject: RE: [Idr] Lars Eggert's Discuss on
draft-ietf-idr-bgp-ls-registry-04: (with DISCUSS and COMMENT)

Hello,

I believe Adrian has made all these points already in his responses on these
threads, and so perhaps this is just an effort at summarizing them for the
IESG Discussion. 

(Request the WG Chairs to correct if they see this different from the WG
consensus view).

1) The "Specification Required" policy is currently in place for this
registry per RFC7752. The WG was informed that Internet-Drafts (even WG
drafts) do not meet the criteria of "permanent and readily available" thanks
to the boiler-plate text (below) that exists in Internet-Drafts. i.e. WG
could not get IANA allocations based on WG drafts.

2) As a result of (1), the WG has had to follow the early allocation
procedures of RFC7120 for a large set of allocations and documents (BGP-LS
is a bit busy!). IDR requires 2 implementations to publish drafts as RFCs.
Things take time. The WG, chairs, AD and in some cases the IESG have to do a
lot of process work to retain the allocations when there are delays in
getting to publication.

3) The WG was looking for IANA allocation based on WG documents. With the
guidance of WG chairs, our AD and participants with more experience in IANA
allocations, we (the WG) took a step back to "Expert Review" so as to avoid
the early allocation process overheads. Please note that we have sufficient
code-point space.

4) The guidance to DE was only improved/enhanced but that, IMHO, is more
secondary in nature and something that happened over the course of review of
the document to improve it.

Thanks,
Ketan 

-----Original Message-----
From: Idr <[email-masked]> On Behalf Of Lars Eggert
Sent: 25 March 2021 02:26
To: [email-masked]
Cc: [email-masked]; [email-masked]; The IESG <[email-masked]>;
[email-masked]; Susan Hares <[email-masked]>
Subject: Re: [Idr] Lars Eggert's Discuss on
draft-ietf-idr-bgp-ls-registry-04: (with DISCUSS and COMMENT)

Hi,

> I wish there was a way for the IESG to table something for discussion
without using the "Discuss a document" hook which makes the authors (and the
watchers) feel that *they* should be part of the discussion. But, anyway, it
seems that there is something here that the IESG needs to discuss, so
"whatever works."

RFC7120 requires:

>   - a non-IETF document doesn't qualify

RFC7120 also applies to "Specification Required" registries for which no
IETF document is needed.

>   - the code point "expires" if someone forgets to renew

Fair point. But this document defines a mechanism whereby chairs and the ADs
are tasked to remember to make IANA deprecate the codepoints when a document
isn't published (or I guess published with incompatible changes to the
revision for which the allocation was made). That seems to suffer from
similar drawbacks.

Thanks,
Lars

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 25 Mar 2021 10:18:29 -0400

Lars: 

On your comment: 
  - for others, task chairs/ADs; is this workable?
    - how would we do this last point for non-IETF specs
======
On the last point, in the past the IDR chairs have work IANA on
deprecations. 

Cheers, Sue 

-----Original Message-----
From: Lars Eggert [mailto:[email-masked]] 
Sent: Thursday, March 25, 2021 9:15 AM
To: Rob Wilton (rwilton)
Cc: Ketan Talaulikar (ketant); The IESG; [email-masked];
[email-masked]; [email-masked]; Susan Hares;
[email-masked]
Subject: Re: [Idr] Lars Eggert's Discuss on
draft-ietf-idr-bgp-ls-registry-04: (with DISCUSS and COMMENT)

Hi,

On 2021-3-25, at 14:51, Rob Wilton (rwilton) <[email-masked]> wrote:
> Hence, my preference is to publish now, but we should work out how to fix
this properly before we get a flood of similar documents.

To scope this potential revision of RFC7120, let's briefly make sure we
capture the issues that at least IDR has identified, so someone has a
starting point to work off of:

  - for large registries, may not need to deprecate outdated early
allocations at all

Thanks,
Lars

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 25 Mar 2021 15:04:30 -0000

Lars,

Thanks.

I think you have captured a good starting point for discussion.

Can I just note that FCFS suffers the same moving target problem of a code
point that is assigned to a draft where the draft may change the meaning on
a later revision.

Some of this is simply "buyer beware." If you use a code point referenced by
an I-D then expect things to go wrong.

But it might also be helpful for IANA to track against an I-D version, not
just the I-D name.

Cheers,
Adrian

-----Original Message-----
From: Lars Eggert <[email-masked]> 
Sent: 25 March 2021 13:15
To: Rob Wilton (rwilton) <[email-masked]>
Cc: Ketan Talaulikar (ketant) <ketant=[email-masked]>; The IESG
<[email-masked]>; [email-masked]; [email-masked];
[email-masked]; Susan Hares <[email-masked]>; [email-masked]
Subject: Re: [Idr] Lars Eggert's Discuss on
draft-ietf-idr-bgp-ls-registry-04: (with DISCUSS and COMMENT)

Hi,

Thanks,
Lars