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
