Hi Paul, 

On 9/20/22, 1:42 PM, "Paul Kyzivat" <[email protected]> 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.

    >     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://mailarchive.ietf.org/arch/msg/lsr/1MzfiHUq7LlY9VQFhtLR7j9eo2g/>
    > 
    > https://mailarchive.ietf.org/arch/msg/lsr/UJgcBwSLcbVYPjrp0SicsDcHpj0/ 
    > <https://mailarchive.ietf.org/arch/msg/lsr/UJgcBwSLcbVYPjrp0SicsDcHpj0/>

    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.)

    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.

    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.

    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.

    One last thought: have you considered whether potential future updates 
    to the definitions to currently defined sub-TLVs could ever change their 
    applicability? 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".

I believe the consensus in the WG is that this registry reorg document might 
take some time and review. We don't want to hold this OSPF L2 bundles document 
hostage. 

Thanks,
Acee

        Thanks,
        Paul

_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art

Reply via email to