Hi Lars, Thanks for your review and feedback/comments. Please check inline below for responses.
The updates for your comments as discussed below will be included in the next version. On Fri, Sep 30, 2022 at 6:47 PM Lars Eggert via Datatracker < nore...@ietf.org> wrote: > Lars Eggert has entered the following ballot position for > draft-ietf-lsr-ospf-l2bundles-06: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-l2bundles/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > # GEN AD review of draft-ietf-lsr-ospf-l2bundles-06 > > CC @larseggert > > Thanks to Paul Kyzivat for the General Area Review Team (Gen-ART) review > (https://mailarchive.ietf.org/arch/msg/gen-art/IqLhVi63YKAt6GINPOKUQ0sGt3g > ). > > I'm raising Paul's review comment as a DISCUSS: > ``` > 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. 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. > > 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> Paul and I discussed the ways to address this point given that the WG didn't want to include a larger scale registry reorganization as part of this document. Please check this thread below, in case it was missed: https://mailarchive.ietf.org/arch/msg/lsr/yA87ypJB_82k0w13R9fp4_lFQok/ I have polled the WG and am still waiting for feedback. 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. [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> Please let me know if this text would address your concern. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > ## Nits > > All comments below are about very minor potential issues that you may > choose to > address in some way - or ignore - as you see fit. Some were flagged by > automated tools (via https://github.com/larseggert/ietf-reviewtool), so > there > will likely be some false positives. There is no need to let me know what > you > did with these suggestions. > > ### Typos > > #### Section 2, paragraph 3 > ``` > - assymetric for an OSPF link depending on the underlying layer 2 > - - > + asymmetric for an OSPF link depending on the underlying layer 2 > + + > ``` > KT> Ack > > ### Grammar/style > > #### Section 2, paragraph 2 > ``` > member link is operationally up. Therefore advertisements of member links > MU > ^^^^^^^^^ > ``` > A comma may be missing after the conjunctive/linking adverb "Therefore". > KT> Ack > > #### Section 2, paragraph 19 > ``` > which the OSPF protocol operates. Therefore the security considerations of > th > ^^^^^^^^^ > ``` > A comma may be missing after the conjunctive/linking adverb "Therefore". > KT> Ack Thanks, Ketan > > ## Notes > > This review is in the ["IETF Comments" Markdown format][ICMF], You can use > the > [`ietf-comments` tool][ICT] to automatically convert this review into > individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. > > [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md > [ICT]: https://github.com/mnot/ietf-comments > [IRT]: https://github.com/larseggert/ietf-reviewtool > > > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
