[posting to keep the WG in the loop] Hi Ketan,
As discussed in the parallel thread with Amanda @ IANA, this looks good, except that it would be a good idea to supply specific text for IANA to use as an annotation on the registry. Amanda pointed to the Note on https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-advertising-neighbor-information as an example of how to write it. Thanks, —John > On Oct 6, 2022, at 10:46 AM, Ketan Talaulikar <ketant.i...@gmail.com> wrote: > > > [External Email. Be cautious of content] > > > Hi John, > > We've posted an update of the draft with the changes as per option 1 below: > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-l2bundles-09 > > Please let us know if there are any other concerns. Will also let the IANA > team know of this update on the parallel thread so they can also check/review > the same. > > Thanks, > Ketan > > > On Thu, Oct 6, 2022 at 6:37 PM John Scudder <j...@juniper.net> wrote: > Hi Ketan, > > Thanks for the analysis. A few comments below. > > > On Oct 6, 2022, at 8:30 AM, Ketan Talaulikar <ketant.i...@gmail.com> wrote: > > > > Hi John/Lars, > > > > I hope this topic can be discussed in the upcoming telechat to conclude on > > the option to be adopted. > > > > To make it easier, let me provide a pointer to the text for each inline > > below. I am not sure that I understand option 3 very well. > > > > > > On Wed, Oct 5, 2022 at 9:42 PM John Scudder <j...@juniper.net> wrote: > > 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. > > > > KT> This was > > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-l2bundles-05#section-3 > > > > IANA is requested to introduce a column "Applicability to L2 Bundle > > Member TLV" in the registry tables for the "OSPFv2 Extended Link TLV > > Sub-TLVs" registry with the initial updates (Y/N) against allocations > > as indicated in Figure 2. Similarly, IANA is requested to introduce > > a column "Applicability to L2 Bundle Member TLV" in the registry > > tables for the "OSPFv3 Extended LSA Sub-TLVs" registry with the > > initial updates (Y/N/X) against allocations as indicated in Figure 3. > > Further allocations from these two registries are expected to > > indicate the applicability of the introduced sub-TLV to the L2 Bundle > > Member TLV that would get updated in these registries. > > Thanks. As mentioned earlier, this is my preferred option — the more so after > looking through your analysis. I think all the gyrations after version 05 > have demonstrated amply that “perfect is the enemy of good”. > > > 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.) > > > > KT> This is a "quick" tweak on > > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-l2bundles-08#section-4 > > as follows: > > > > This document updates the guidance to IANA for further allocations > > from the "OSPFv2 Extended Link TLV Sub-TLVs" and the "OSPFv3 Extended > > LSA Sub-TLVs" registries to "IETF Review (Additional Expert Review > > > > Required)" [RFC8126] and requests the addition of this document > > as a reference to those registries. It requires that the designated > > > > expert appointed by IESG verify that any document > > requesting allocation of code point from these two registries needs > > to specify the applicability of the introduced sub-TLV to the L2 > > Bundle Member TLV in a manner similar to Figure 2 and Figure 3 that > > cover existing allocations up to the point of publication of this > > document. > > That looks right. As previously mentioned I don’t see benefit to choosing > this option instead of (1) — all cost, no additional benefit. > > > 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). > > > > KT> I am not sure what this option involves. Putting this document as a > > reference but no IANA actions or gatekeeper seems odd to me. Isn't this > > option - "do nothing" - which is the state in which this draft came out of > > the WG and AD review? > > Yes indeed, I guess I only mentioned it for completeness. It would resolve > IANA’s concerns but wouldn’t satisfy Lars’s DISCUSS, so I think we can take > this off the table. > > —John > > > What came out of the WG: > > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-l2bundles-04#section-3 > > also same as at the end of John's AD review: > > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-l2bundles-06#section-3 > > > > Thanks, > > Ketan > > > > > > 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 <l...@eggert.org> wrote: > > > Hi, > > > > > > On 2022-9-30, at 16:37, Ketan Talaulikar <ketant.i...@gmail.com> 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
