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

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
c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at

> On 19.11.2021, at 23:48, Martin Duke via Datatracker <noreply@ietf.org> wrote:
> 
> 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.
> 
> 
> 
> 
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr