Hi All, The update has been posted: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-l2bundles-10
Thanks, Ketan On Fri, Oct 7, 2022 at 2:21 PM Ketan Talaulikar <[email protected]> wrote: > Hi All, > > Following is the updated text proposal for the part of the IANA section > under discussion: > > IANA is requested to introduce a column "Applicability to L2 Bundle > Member sub-TLV" (abbreviated as L2BM) 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. An explanatory > note is also to be added to this registry as follows: > > The column for the Applicability to L2 Bundle Member sub-TLV (L2BM) > may be marked as follows: > > Y - sub-TLV may appear in L2 Bundle Member sub-TLV > N - sub-TLV MUST NOT appear in L2 Bundle Member sub-TLV > > Similarly, IANA is requested to introduce a column "Applicability to > L2 Bundle Member sub-TLV" (abbreviated as L2BM) 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. > > The column for the Applicability to L2 Bundle Member sub-TLV (L2BM) > may be marked as follows: > > Y - sub-TLV may appear in L2 Bundle Member sub-TLV > N - sub-TLV MUST NOT appear in L2 Bundle Member sub-TLV > X - sub-TLV is not a Router Link sub-TLV; it MUST NOT appear > in L2 Bundle Member sub-TLV > > Further allocations from these two registries are required to > indicate the applicability of the introduced sub-TLV to the L2 Bundle > Member sub-TLV that would get updated in these registries. > > Planning to post this update unless there are any concerns/suggestions and > also once I get confirmation from IANA that this is OK with them. > > Thanks, > Ketan > > > On Fri, Oct 7, 2022 at 1:44 AM John Scudder <[email protected]> wrote: > >> [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 <[email protected]> >> 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 <[email protected]> wrote: >> > Hi Ketan, >> > >> > Thanks for the analysis. A few comments below. >> > >> > > On Oct 6, 2022, at 8:30 AM, Ketan Talaulikar <[email protected]> >> 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 <[email protected]> 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 <[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
