Hi Andrew, On Thu, Nov 17, 2022 at 3:39 PM Stone, Andrew (Nokia - CA/Ottawa) <andrew.st...@nokia.com> wrote: > > Hi Donald, > > Thank you very much for the review. Version -08 is submitted with the > suggestions and additional changes: > > Section 5: "this i-d" -> "this document" (to mirror section 8 suggestion) > Section 8: definitive language, added editor note (to mirror section 5 > suggestion)
Thanks. The incorporation of my suggestions looks great. However, I noticed something unrelated which seems quite odd. In the References sections "RFC Publisher" appears to have been added as an author for many but not all of the RFCs referenced. I've never seen this before and it is so bizarre it might be a temporary glitch so I have attached the Diff2 I see between -07 and -08... Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e...@gmail.com > Thanks again > > Andrew > > > On 2022-11-16, 3:10 PM, "Donald Eastlake" <d3e...@gmail.com> wrote: > > Hello, > > I have been selected to do a routing directorate "early" review of > this draft. For more information about the Routing Directorate, please > see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Document: draft-ietf-pce-local-protection-enforcement-07 > Reviewer: Donald Eastlake 3rd > Review Date: 16 November 2022 > Intended Status: Standards Track > > Summary: > Has Nits. > > Comments: > This is a straightforward document specifying an "Enforcement" bit in > the PCEP LSP Attributes Object. This bit operates in conjunction with > the previously specified L (Local Protection Desired) bit to clarify > the extent to which local protection is required / desired / undesired > / prohibited in the path being determined. Appropriate backwards > compatibility considerations are included. > > Major Issues: > No Major issues. > > Minor Issues: > No Minor technical issues but has nits. > > > Nits: > > Section 2: Need to be updated as per RFC 8174. > > Section 5, Page 6: Drafts should be written as definite > specifications, not as proposals. It will not be useful to say this > has an "early allocation" when this is published as an RFC. > OLD > A new flag is > proposed in this document in the LSP Attributes Object which extends > the L flag to identify the protection enforcement. > > Bit 6 has been early allocated by IANA as the Protection Enforcement > flag. > NEW > A Protection Enforcement flag "E" is specified below, extending the L > flag. > RFC Editor Note: The text below assumes the E bit remains the > early allocation value 6. Please adjust if this changes and remove > this note before publication. > > > Trivia / Editorial Suggestions: > > Section 1, Page 3: re "so therefore" I suggest you pick one of these > two words and drop the other. > Add comma: "router processing the SID such as" -> "router processing > the SID, such as" > > Section 3: Suggest adding entries for the following: LSPA > > Section 4.1, Page 4, 2nd line: "PCEP is with the" -> "PCEP is the" > > Section 4.2, Page 5, 1st paragraph: > "The boolean bit flag" -> "The boolean bit L flag" > "The selection for" -> "Selecting" > > Section 4.2, Page 5, 2nd paragraph: > "if there is anywhere along the path that traffic will be fast > re-routed at the point of failure" -> "if there is a failure anywhere > along the path that traffic will be fast re-routed at that point" > > Section 4.2, Page 5, 3rd paragraph: > "rather local failures to cause" -> "rather local failures cause" > "(ex: insufficient bandwidth)" -> "(e.g., insufficient bandwidth)" > "resulting for the LSP to be torn down" -> "resulting in the LSP being > torn down" > > Section 4.2, Page 6: "to instruct the PCE a preference" -> "to give > the PCE a preference" > > Section 5, Page 7: "criteria however the" -> "criteria; however, the" > "should interpret and behave when" -> "should behave when" > > Section 5, Page 8: (twice) "It is RECOMMENDED for a PCE to assume" -> > "It is RECOMMENDED that a PCE assume" > "ignore the E flag thus it" -> "ignore the E flag. Thus, it" > > Section 8: Since there is only one subsection of Section 8, the > "Section 8.1" subheading should be deleted. > When published, this will no longer be an "I-D" so the Reference > should be changed from "I-D" to "[this document]". > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > d3e...@gmail.com, >
<<< text/html; charset="US-ASCII"; name="Diff_ draft-ietf-pce-local-protection-enforcement-07.txt - draft-ietf-pce-local-protection-enforcement-08.txt.html": Unrecognized >>>
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
