Murray Kucherawy has entered the following ballot position for draft-ietf-ospf-te-link-attr-reuse-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-ospf-te-link-attr-reuse/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Three main things from me: (1) I found I'm in agreement below with some of the points raised in the posted OPSDIR review. Please give that another once-over. (2) A grammatical point: I think nearly every instance in this document of "which" should be replaced by "that". (3) In Section 12.3.3, I don't think it's appropriate to use MUST-type language to constrain future document authors. And now, my nit-storm: Section 1: * "... attribute advertisements - examples of which ..." -- hyphen should be a comma * "... for a link that is not enabled for RSV-TE." -- s/RSV/RSVP/ * "... path via that link it will result ..." -- comma after "link" Section 3: * Please define, or provide a reference for, "GMPLS". Section 4.1: * "... not inspected by OSPF, that acts as ..." -- s/that/which instead/ Section 5: * Several changes to this paragraph suggested: OLD: On top of advertising the link attributes for standardized applications, link attributes can be advertised for the purpose of application that is not defined as standardized one. We call such application a user defined application. What such application might be is not subject to the standardization and is outside of the scope of this specification. NEW: On top of advertising the link attributes for standardized applications, link attributes can be advertised for the purpose of applications that are not standardized. We call such an application a "User Defined Application" or "UDA". These applications are not subject to standardization and are outside of the scope of this specification. * Is the snapshot of the current content of the Link Attribute Application Identifier Registry needed? The rest of the document doesn't seem to reference it. * "... to advertise all UDAs." -- although it's fairly clear at this point what a UDA is, I suggest defining it somewhere above, maybe by hanging it off one of the other places where the full name is used such as in the paragraph above Section 6.1: * Please expand "IPFRR" on first use. Section 6.2: * "All these can be used ..." -- s/All/All of/ Section 11: * "- e.g. RSVP-TE -" -- comma after "e.g." * "... one need to make sure ..." -- s/need/needs/ * "... applications, where the enablement ..." -- remove comma * "... such application - e.g. LFA." -- change to "such application. An example of this is LFA." Section 12.3.4: * "Link attributes that are NOT allowed ..." -- s/NOT/not/ _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
