Hello Peter, Thanks for your quick reply and for addressing all my non-blocking COMMENT issues (including adding the consequences of not following the SHOULD).
Regards -éric From: Peter Psenak <[email protected]> Date: Thursday, 18 September 2025 at 11:57 To: Eric Vyncke (evyncke) <[email protected]>, The IESG <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Re: Éric Vyncke's No Objection on draft-ietf-lsr-igp-ureach-prefix-announce-09: (with COMMENT) Hi Eric, thanks for your comments, please see my responses inline (##PP): On 17/09/2025 17:35, Éric Vyncke via Datatracker wrote: Éric Vyncke has entered the following ballot position for draft-ietf-lsr-igp-ureach-prefix-announce-09: 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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lsr-igp-ureach-prefix-announce/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-lsr-igp-ureach-prefix-announce-09 CC @evyncke Thank you for the work put into this document. Please find below some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education). Special thanks to Yingzhen Qu for the shepherd's detailed write-up including the WG consensus (important to note for this I-D) _but it lacks_ the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric ## COMMENTS (non-blocking) ### Title s/IGP Unreachable Prefix Announcement/Unreachable Prefix *IGP* Announcement/ sounds clearer to me but English is not my primary language. ##PP I let the RFC Editors to decide, I feel what we have is better. ### Abstract s/This document describes/This document *specifies*/ as this is proposed standard. ##PP done ### Section 1 Who is the "we" in `we want to signal unreachability` ? The authors ? The LSR WG ? The IETF ? Please avoid using ambiguous "we" by rephrasing the sentence. ##PP done s/ISIS/IS-IS/ ? and in other places. ##PP done ### Section 2 s/for a prefix that is summarized by the summary *address*/for a prefix that is summarized by the summary *prefix*/ ? ##PP done There are two "SHOULD" in this section but nothing is written the cases when these "SHOULD" can be bypassed and/or what are the consequences. ##PP I added: "Not withdrawing the UPA would result in stale information being kept in the link state database of all routers in the area." Add "and OSPFv3" at the end of `so the above optimisation does not apply to OSPF` ? It seems that the I-D sometimes uses OSPF for OSPFv2 alone and sometimes for OSPFv2 and OSPFv3. ##PP I added and OSPFv3 at the end of the sentence, ### Section 3.1 Add "to support this specification" after `without the need to upgrade all nodes in a network.` ? ##PP done `Those ABRs or ASBRs, which are responsible for propagating UPA advertisements into other areas or domains MUST also recognize UPA advertisements.` what are the consequences if this is not the case (e.g., not all ABR/ASBR have been upgraded). Should this be mentioned in an operational considerations section ? ##PP added: "Failure to do so would prevent UPA to reach the routers in the remote areas or domains." ### Section 5.1 Was the use of a 2-bit field considered rather than using 2 flags ? It would have allowed 4 values as opposed as the current 3 values. Out of curiosity because it is probably too late to change it... ##PP RFC7444 defines the "IPv4/IPv6 Extended Reachability Attribute Flags" TLV, which is a variable length bitfield. We are simply adding two new bits in that bitfield. ### Section 8 It is often preferable to add an informational reference to the URI of the registries. #PP never done it, can you please provide an example RFC/draft, I'll follow that. thanks, Peter
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
