Re: [Gen-art] Gen-ART Last Call review of draft-ietf-lsr-ospf-l2bundles-06

[Ketan Talaulikar <[e-mail]>]

Hello All,

I see that the IETF LC for this document is over and it is scheduled for
the upcoming IESG telechat. I wanted to poll to see if there was any
support or feedback for point (2) below and the IANA changes on the lines
suggested by Paul.

Thanks,
Ketan

On Wed, Sep 21, 2022 at 9:12 PM Ketan Talaulikar <[e-mail]>
wrote:

> < adding the WG alias and our AD >
>
> Hi Paul,
>
> Thanks for the discussion. I will summarize the two points as follows:
>
> 1) Should the reference to [IEEE802.1AX] be informative? It is currently
> normative. The context is covered in draft-kucherawy-bcp97bis-02. We will
> wait for guidance from our AD/IESG on this.
>
> 2) There is a proposal to take a "half-step" to build guard rails at the
> point of IANA allocations so future documents that introduce new sub-TLVs,
> that they cover the applicability of those new sub-TLVs to the L2 Bundle
> Member sub-TLV. Following is a draft proposed text (feel free to suggest
> alternative) to be added to the IANA considerations of this document. I am
> not aware of any such precedent and so would like to seek feedback from the
> WG and our chairs/AD if this is something that we should do.
>
> <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.
>
>
> [1] https://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xhtml#extended-link-tlv-sub-tlvs
>
> [2] https://www.iana.org/assignments/ospfv3-parameters/ospfv3-parameters.xhtml#extended-lsa-sub-tlvs
>
> </NEW>
>
>
> Thanks,
> Ketan
>
> On Wed, Sep 21, 2022 at 8:16 PM Paul Kyzivat <[e-mail]>
> wrote:
>
>> Ketan,
>>
>> I've trimmed the conversation down to just the relevant points.
>>
>> On 9/21/22 10:07 AM, Ketan Talaulikar wrote:
>>
>> > KT> This ID-nits warning is perhaps simply because the normative
>> > reference is not from an IETF publication and so perhaps the tool is
>> not
>> > able to determine if that publication is "standards" or informational.
>> > As far as the guidance from draft-kucherawy, I'll wait for our AD and
>> > IESG to share their views - we'll do as indicated by the IESG.
>>
>> OK
>>
>> > KT> If I understand your point, and I am paraphrasing, the idea is that
>> > we add this document as reference on the OSPFv2/v3 code point registry
>> > and in this document's IANA section we add guidelines for IANA to look
>> > for whether the allocation request has specified the applicability to
>> > the L2 Bundle Member Sub-TLV. So that acts as a checkpoint before
>> future
>> > allocations out of this registry. Is that correct?
>>
>> Yes
>>
>> > So this is half-step
>> > between the current state of the document and the suggested new
>> document
>> > that changes the registry organization.
>>
>> I guess. If this hypothetical new document straightens things out
>> better, then this would simply cover anything that happens until that
>> new document is adopted, or in case that never happens.
>>
>> Alternately, you could hold this document until that other one is ready.
>>
>> >     One last thought: have you considered whether potential future
>> updates
>> >     to the definitions to currently defined sub-TLVs could ever change
>> >     their
>> >     applicability?
>> >
>> >
>> > KT> That would be very remote/unlikely IMO.
>> >
>> >     I suspect any time a change is made to the registry that
>> >     adds/replaces a reference to a document defining a sub-TLV, the
>> newly
>> >     referenced document will need to "indicate applicability".
>> >
>> > KT> Sure and this should be taken care of by the IANA checks when the
>> > new document reference is updated in registry.
>>
>> Yes.
>>
>>         Thanks,
>>         Paul
>>
>