É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. ### Abstract s/This document describes/This document *specifies*/ as this is proposed standard. ### 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. s/ISIS/IS-IS/ ? and in other places. ### Section 2 s/for a prefix that is summarized by the summary *address*/for a prefix that is summarized by the summary *prefix*/ ? 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. 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. ### Section 3.1 Add "to support this specification" after `without the need to upgrade all nodes in a network.` ? `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 ? ### 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... ### Section 8 It is often preferable to add an informational reference to the URI of the registries. _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
