Hi All, (To keep everyone in the loop since you weren’t all on the cc of the IANA review email.)
Amanda Baber at IANA pointed out that the added paragraph is a problem for IANA since it’s too imprecise for IANA to carry out. The options come down to: 1. Revisit the WG decision, and add a field to the registry for the “Y/N” annotations that relate to this spec. 2. Change the policy to something like "IETF Review (Additional Expert Review Required) or IESG Approval" and include advice to the experts in the document. (Thanks to Amanda for this suggestion.) 3. Move the “it requires” text out of the IANA considerations and into a more appropriate section, and don’t try to put a gatekeeper into the registry (yet). I think either option 1 or option 2 would be fine insofar as resolving Lars (et al)’s concern. Option 3 would amount to returning to the previous plan of record, which was to ship the spec without a registry gatekeeper but ask the WG to produce a registry reorg that does so in a more comprehensive way. Of these plans, I’m least enthusiastic about option 2 since it would require us to appoint and instruct an expert reviewer, for what I hope will be a short-lived function. That implies — to me — that option 1 is the least bad way of breaking the deadlock. Until we resolve this the draft will be stuck in “IANA NOT OK”. —John > Hi Lars, > > Thanks for your confirmation. > > Acee/John, I haven't received any response (objection or support) from the WG > on this change. I believe this may be a good interim step until the WG > considers any IANA registry reorganization. Can you please share your views > as shepherd and AD respectively? > > Thanks, > Ketan > > > On Mon, Oct 3, 2022 at 6:31 PM Lars Eggert <[email protected]> wrote: > Hi, > > On 2022-9-30, at 16:37, Ketan Talaulikar <[email protected]> wrote: > > In brief, the proposal was to introduce the following text in the IANA > > considerations: > > > > <NEW> > > This document updates the guidance to IANA for further allocations > > from the "OSPFv2 Extended Link TLV Sub-TLVs" [1] and the > > "OSPFv3 Extended LSA Sub-TLVs" [2] registries and requests the addition > > of this document as a reference to those registries. It requires > > that any document requesting allocation of code point from these > > two registries need to indicate the applicability of the introduced > > sub-TLV to the L2 Bundle Member TLV in that document. > > something along those lines would work for me. > > Thanks, > Lars > > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
