Subject: [Idr] Martin Duke's Discuss on draft-ietf-idr-bgp-ext-com-registry-03: (with DISCUSS)

From: Martin Duke via Datatracker <[email-masked]>
Date: Fri, 19 Nov 2021 14:48:38 -0800

Martin Duke has entered the following ballot position for
draft-ietf-idr-bgp-ext-com-registry-03: 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/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

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

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

I'm having trouble seeing how we got here; this registry architecture is hard
to understand, and past actions appear to violate RFC 3692.

1. RFC7153 designated 0x80-0x8f as experimental and then immediately defines
0x80 as the gateway to a further subregistry of FCFS/IETF review codepoints.
This does not appear to be "Reserved for Experimental Use" in the RFC 3692
sense, in that it is not meant to be used only by explicit experiments. (It's a
standards track document).

2. RFC8955 compounds it by taking another 2 (of 15 remaining!) experimental
codepoints in a standards-track document, for a similar purpose.

I agree with this draft's reclassification of the 3 codepoints, as it
recognizes reality that they are apparently no longer safe for RFC 3692
experiments. But I would also like to verify that this behavior will not
continue: future standards-track allocations, including those pointing to more
subtypes ("Part 4", etc), will draw from the FCFS range, not Experimental.

Furthermore, experiments (with a draft or not) that use one of these
experimental codepoints should be reassigned a FCFS codepoint if they move to
Standards track.

---

From: Christoph Loibl <[email-masked]>
Date: Mon, 22 Nov 2021 11:53:26 +0100

Hi Martin,

Thank you for reviewing the document and pointing out, that these historic assignments seem to violate BCP RFC 3692.

I cannot speak for the WG, but personally I do not understand how RFC 5575 (which allocated these experimental codepoints in the first place and has been obsoleted by RFC 8955 recently) could keep these codepoints without anyone questioning during the whole process (without having a hard time reading mailing-list archives and meeting notes). To me this seems to be a (rare?) organisational issue. 

Cheers Christoph

-- 
Christoph Loibl
[email-masked] | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at

> On 19.11.2021, at 23:48, Martin Duke via Datatracker <[email-masked]> wrote:
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Alvaro Retana <[email-masked]>
Date: Mon, 22 Nov 2021 07:17:22 -0800

On November 19, 2021 at 5:48:38 PM, Martin Duke wrote:

Martin:

Hi!

> I'm having trouble seeing how we got here; this registry architecture is
> hard to understand, and past actions appear to violate RFC 3692.
>
> continue: future standards-track allocations, including those pointing to
> more subtypes ("Part 4", etc), will draw from the FCFS range, not
> Experimental.
>
> experimental codepoints should be reassigned a FCFS codepoint if they move
> to Standards track.

That is the intent.  The allocation process has been followed for
other BGP-related registries, and I'm sure the WG will continue to do
so.

We can't unfortunately go back and correct how the assignments were
made to rfc5575 (which seems to have been the origin of this whole
issue) -- so we are (finally!) cleaning it up.

Alvaro.

---

From: Martin Duke <[email-masked]>
Date: Mon, 22 Nov 2021 08:58:38 -0800

Thanks Alvaro.

I removed the DISCUSS.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 23 Nov 2021 09:21:08 -0500

Christoph, IESG, and Working Group at large,

On Mon, Nov 22, 2021 at 11:53:26AM +0100, Christoph Loibl wrote:
> Thank you for reviewing the document and pointing out, that these historic
> assignments seem to violate BCP RFC 3692.
> 
> I cannot speak for the WG, but personally I do not understand how RFC 5575
> (which allocated these experimental codepoints in the first place and has
> been obsoleted by RFC 8955 recently) could keep these codepoints without
> anyone questioning during the whole process (without having a hard time
> reading mailing-list archives and meeting notes). To me this seems to be a
> (rare?) organisational issue. 

I do not speak for the chairs at the time this was done.  I likely did speak
to the chairs about this given my involvement in Flowspec at my employer.
But most certainly, this happened because Experimental code points seldom
get used correctly.

https://datatracker.ietf.org/meeting/97/materials/slides-97-idr-code-point-management-02

I gave the above presentation a few times in IETF and regularly break out
the internal presentation this is based upon for training purposes.
Experimental code points often simply fail to get used correctly.

Similar conversations on the other types of allocation strategies largely
point out that trying to make things too hard also backfire.

It's for this reason that the practice within IDR over recent years has
trended toward larger first-come, first-served allocation strategies with a
large enough code point space that it's not a problem.

I'd recommend the IESG consider taking up some flavor of my presentation as
part of the core educational materials for the IETF.

-- Jeff