Paul, thank you for your review and thank you all for the following discussion. I have entered a Discuss ballot for this document based on your review, specifically, point 2 below.
Thanks, Lars > On 2022-9-16, at 20:57, Paul Kyzivat <[email protected]> wrote: > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-lsr-ospf-l2bundles-06 > Reviewer: Paul Kyzivat > Review Date: 2022-09-16 > IETF LC End Date: 2022-09-29 > IESG Telechat date: ? > > Summary: > > This draft is on the right track but has open issues, described in the review. > > Issues: > > Major: 0 > Minor: 1 > Nits: 1 > > 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. > > 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. > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
