Roman -
Thanx for the review. Responses inline. > -----Original Message----- > From: Roman Danyliw via Datatracker <[email protected]> > Sent: Wednesday, June 10, 2020 3:05 PM > To: The IESG <[email protected]> > Cc: [email protected]; [email protected]; [email protected]; Acee > Lindem (acee) <[email protected]>; [email protected]; Acee Lindem > (acee) <[email protected]> > Subject: Roman Danyliw's No Objection on draft-ietf-isis-te-app-14: (with > COMMENT) > > Roman Danyliw has entered the following ballot position for > draft-ietf-isis-te-app-14: No Objection > > 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/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-isis-te-app/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > (revised) > ** Section 4.1. As I understand it, the SABM can be of 0 – 8 octets in > length. > The SABM Length field represents that length and has 7 bits to do that. > However, the maximum number of bits needed to represent 8 is only 4 bits. > What’s the thinking on those three extra bits? Should they be marked as > reserved? I would have the same question for the UDABM mask. > [Les:] The limitation for the xABM length to be no more than 8 bytes was introduced only recently based on a review comment. The concern was that without a limit, it would be theoretically possible for the ABM itself to consume the full sub-TLV space, leaving no room for the actual link attribute advertisements. There are existing implementations of this draft which have been deployed. Changing the interpretation of (some of) the bits would not be backwards compatible. I do not think the small space savings would be worth the trouble. You are the third reviewer to ask about this. (Tongue-in-cheek) I am impressed with the (oxymoron alert…) “abundance of frugality”. 😊 > ** Section 6.2. I didn’t follow what it means to send the sub-TLV in Section > 4.2 with a zero length SABM Length and UDABM Length – that is two empty > bitmasks? Is that permitted? What would it convey? > [Les:] Clearly 0 length masks are permitted since we specify a length of 0 as valid. And usage is described in Sections 4.2 and 6.2 – any application can use such advertisements. What specifically is your question? > ** Section 8. Per “Tampering with the information defined in this document > may > have an effect on applications using it, including impacting Traffic > Engineering.”, I have no disagreement with this statement. However, I > would > recommend adding a brief statement what is the security impact of > “impacting > Traffic Engineering”. > > ** Section 8. Per “This is similar in nature to the impacts associated with > (for example) [RFC5305]”, what specific text in RFC5305 was envisioned? The > SecCon section (Section 6) of RFC5305 contains only one sentence that points > to > RFC5304? > [Les:] I have added a reference to RFC8570 – whose Security section has a good discussion of impacts to TE. I have removed the reference to RFC5305. It seemed unnecessary after referencing RFC8570 and – as you point out – it does not discuss security issues in any detail. > ** Section 8. Consider using the editorial framing of the first paragraph of > Section 13 in draft-ietf-ospf-te-link-attr-reuse to introduce how the RFC5304 > applies here. > [Les:] Done > ** Editorial > -- Section 3. Editorial. Consider providing a reference for the registries > instead of an inline URL. > [Les:] Yes – this has been done. Another reviewer also requested this. > -- Section 4.1. The rendering of the sub-TLV diagram was split between Page > 6 > and 7 when this draft is read in TXT format. IMO, it would be more readable > if > it was on one page. > [Les:] I prefer to leave this to the RFC Editor. > -- Per Section 4.1. Editorial. Per “See the following section for a > description …”, please explicitly name the section. > [Les:] Done > -- Section 4.2. Typo. s/Identifer/Identifier/ [Les:] Done Les > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
