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

[John Scudder <[e-mail]>]

Hi All,

Regarding the reference to IEEE802.1AX, there are two issues that were discussed –

First, should it be normative or informative, on the merits? Ketan makes it clear that the choice to make it normative was a considered one; I don’t see a reason to press for a change.

Second, is it a downref? I think Ketan is correct that this is just an idnits artifact (the “possible” in “possible downref” admits of the possibility that it’s being flagged incorrectly, which I think is what’s the case here). See RFC 7241, “The IEEE 802/IETF Relationship”, Section 3.4, “Cross-Referencing”,

   IETF and IEEE 802 each recognize the standards defined by the other
   organization.  Standards produced by each organization can be used as
   references in standards produced by the other organization.

I think we are good on this point.

Thanks,

--John


From: Ketan Talaulikar <[e-mail]>
Date: Wednesday, September 21, 2022 at 10:07 AM
To: Paul Kyzivat <[e-mail]>
Cc: [e-mail] <[e-mail]>, General Area Review Team <[e-mail]>
Subject: Re: Gen-ART Last Call review of draft-ietf-lsr-ospf-l2bundles-06

Hi Paul,

Thanks for your quick reply and please check inline below for response.


On Tue, Sep 20, 2022 at 11:11 PM Paul Kyzivat <[e-mail]<mailto:[e-mail]>> wrote:
Ketan,

On 9/20/22 10:30 AM, Ketan Talaulikar wrote:

>     1) NIT: 1 Introduction
>
>     IDNITS reports:
>
>          -- Possible downref: Non-RFC (?) normative reference: ref.
>          'IEEE802.1AX'
>
>     As best I can tell there is no need for this reference to be normative.
>     (Its only an example in the introduction.) I suggest making this a
>     non-normative reference.
>
>
> KT> We kept it as normative since this document is all about "bundle
> members" and that refers to the 802.1AX. However, I am ok to change that
> to informative if the IESG suggests so.

I just saw a draft concerned with this issue:

   Last Call: <draft-kucherawy-bcp97bis-02.txt> (Procedures for Standards
   Track Documents to Refer Normatively to Documents at a Lower Level) to
   Best Current Practice

It isn't approved yet so it isn't definitive, but its close enough that
it might be wise to follow it.

Its easier to just avoid the issue by calling the reference
non-normative. But its your call, together with your AD.

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.


>     2) MINOR: Section 2: Normative requirements on future documents
>
>     While I don't fully understand all the document dependencies, the
>     following normative requirement:
>
>          ... Specifications that introduce new sub-TLVs of the Extended Link
>          TLV MUST indicate their applicability for the L2 Bundle Member
>          Attributes Sub-TLV.  An implementation MUST ignore any sub-TLVs
>          received that are not applicable in the context of the L2 Bundle
>          Member Attribute Sub-TLV.
>
>     looks to me like it may be imposing requirements on future work that
>     may
>     not itself be aware of or normatively linked to this document.
>
> KT> This is correct.
>
>     The
>     registry in question is defined only by RFC7684. Figure 2 further
>     supports this point by effectively revising the format for the
>     registry,
>     adding an additional column.
>
> KT> The intention was not to change the registry format. Please see
> further below.
>
>     I suggest it would be appropriate to formally update the registry to
>     reference this document to impose requirements on future registrations,
>     and add a column indicating applicability in the context of the L2
>     Bundle Member Attribute Sub-TLV.
>
>     The same logic applies to Figure 3 and the IANA OSPFv3 Extended-LSA
>     Sub-TLVs registry. I suggest the same sort of fix for it.
>
> KT> Your point is valid and this has been discussed with the AD and the
> WG. Please check the following threads for those details and how we got
> to the current state of the document:
>
> https://mailarchive.ietf.org/arch/msg/lsr/1MzfiHUq7LlY9VQFhtLR7j9eo2g/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/lsr/1MzfiHUq7LlY9VQFhtLR7j9eo2g/__;!!NEt6yMaO-gk!BIYNq61kseq8zcf90VnVjWTMJ7fD7PuprZC6b1sSt9txGDyErjOnl0nv-tIVCZRZfbreAmQrpBa2TRwl9A$>
> <https://mailarchive.ietf.org/arch/msg/lsr/1MzfiHUq7LlY9VQFhtLR7j9eo2g/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/lsr/1MzfiHUq7LlY9VQFhtLR7j9eo2g/__;!!NEt6yMaO-gk!BIYNq61kseq8zcf90VnVjWTMJ7fD7PuprZC6b1sSt9txGDyErjOnl0nv-tIVCZRZfbreAmQrpBa2TRwl9A$>>
>
> https://mailarchive.ietf.org/arch/msg/lsr/UJgcBwSLcbVYPjrp0SicsDcHpj0/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/lsr/UJgcBwSLcbVYPjrp0SicsDcHpj0/__;!!NEt6yMaO-gk!BIYNq61kseq8zcf90VnVjWTMJ7fD7PuprZC6b1sSt9txGDyErjOnl0nv-tIVCZRZfbreAmQrpBb05VzbPQ$>
> <https://mailarchive.ietf.org/arch/msg/lsr/UJgcBwSLcbVYPjrp0SicsDcHpj0/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/lsr/UJgcBwSLcbVYPjrp0SicsDcHpj0/__;!!NEt6yMaO-gk!BIYNq61kseq8zcf90VnVjWTMJ7fD7PuprZC6b1sSt9txGDyErjOnl0nv-tIVCZRZfbreAmQrpBb05VzbPQ$>>

I can't decipher the logic of the discussion. (Feels like I need more
context than what is in the thread, but I didn't spend a lot of time
trying.)

KT> No issue. It was simply to point to discussions on similar lines.


I acknowledge that it isn't strictly necessary to change the table
format in the registry.

But it is essential to do *something* that forces anyone trying to add a
new entry to either of those tables to "indicate their applicability for
the L2 Bundle Member Attributes Sub-TLV". That needs to be a new
requirement for adding an entry to either table.

KT> Agree.


How to achieve that? Currently someone wanting to add to those tables
will look for the applicable rules in the Reference at the top of the
table, to [RFC7684]. That doesn't impose your new rule. So at the least,
you can add an additional reference to the top of each table, to your
document.

And then, to make it clear, I recommend adding another item to your IANA
Considerations that clearly states it applies to anyone adding or
changing anything in these tables, and restate or clearly reference the
requirements I highlighted to in Section 2.

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? So this is half-step between the current state of the document and the suggested new document that changes the registry organization.


While adding an applicability column isn't technically necessary, it
would make it harder for future updates to forget this step, since they
would be forced to figure out what to put in that column.

KT> We started down this track but then backed off and pushed this to a new document that focuses on the registry reorganization.


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.

Thanks,
Ketan


        Thanks,
        Paul


Juniper Business Use Only