Hi Donald, Nice spotting - that is quite strange. Using author tools I uploaded the 08 xml again, same result.
I uploaded the original 07 xml file (unchanged, from my local git) to author tools and now it also now generates with the RFC publisher remarks. A diff of this new 07 generation against the published 07 shows the same "RFC publisher" remarks against a handful of the references. Attached is the diff of the newly generated 07 against the live url 07. So indeed, perhaps either an intended change to the tooling or a xml2rfc bug? Thanks Andrew On 2022-11-17, 9:49 PM, "Donald Eastlake" <[email protected]> wrote: Hi Andrew, On Thu, Nov 17, 2022 at 3:39 PM Stone, Andrew (Nokia - CA/Ottawa) <[email protected]> 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 [email protected] > Thanks again > > Andrew > > > On 2022-11-16, 3:10 PM, "Donald Eastlake" <[email protected]> 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 > [email protected], >
<<< text/html; name="Diff_ original-07-new-generated.txt - draft-ietf-pce-local-protection-enforcement-07.txt.html": Unrecognized >>>
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
