Hi Matthew, Thank you for your review. Please see inline [Bruno] "Fixed" refers to my local copy of the document.
> From: Matthew Miller [mailto:linuxwolf+i...@outer-planes.net] > Sent: Tuesday, October 10, 2017 3:35 AM > > Reviewer: Matthew Miller > Review result: Ready with Issues > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-grow-bgp-gshut-11 > Reviewer: Matthew A. Miller > Review Date: 2017-10-09 > IETF LC End Date: 2017-10-11 > IESG Telechat date: N/A > > Summary: > > This document is ready to be published as an Informational document, but > there is one issue that I think clarification would help. > > Major issues: > > NONE > > Minor issues: > > In Section 4. "EBGP graceful shutdown procedure", it states that 0 can > used in all cases except where the AS already has a special meaning for > 0. It seems to me more ought to be said, but I admit I'm not well-versed > on (I) BGP and might be seeing dragons where only windmills are present. [Bruno] I'm not seeing much more to say. It's intended as a warning that an AS may already use LOCAL_PREF zero to mean something specific. In which case, the AS knows the specifics, authors/IETF/draft/RFC do not. I'm changing to the following reformulation. Please feel free to suggest text if you prefer. OLD: The LOCAL_PREF value must be lower than the one of the alternate path. 0 being the lowest value, it can be used in all cases, except if it already has a special meaning within the AS. NEW: The LOCAL_PREF value SHOULD be lower than the one of the alternate path. Zero being the lowest value, it MAY be used whichever LOCAL_PREF values are used by the AS. If LOCAL_PREF zero already has a special meaning within the AS, and there is a need to distinguish both usages, another low value MAY be used. > > Nits/editorial comments: > > * I suggest using RFC 8174 and its terminology boiler plate to help > disambiguate "may" versus "MAY". [Bruno] Changing reference from RFC 2119 to RFC 8174. The document already used some SHOULD. Changing: - cf above text on LOCAL_PREF 0 - A BGP speaker implementation MAY avoid such losses by ensuring that "third party" NEXT_HOPs are resolved before installing paths using these in the RIB - Alternatively, the operator (script) MAY ping third party NEXT_HOPs that are expected to be used (although both sentences are in appendix, so I'm not sure how much this apply) > * A number of acronyms are used throughout without being spelled out (e.g., > RR, IBGP, FIB, EBGP, AS), but some (e.g., ASBR) are spelled out. I would > find it helpful to be consistent here, preferably by spelling them out on > first use. [Bruno] Spelling out RR, AS I'm proposing to not spell out IBGP, EBGP and FIB which are listed as "well-known" by the RFC editor. (not to mention to readers familiar with BGP, which should be the target for this document); or leave this to the RFC editor. https://www.rfc-editor.org/materials/abbrev.expansion.txt (note that RR & AS are also part of this list, but with multiple expansions) > * In Section 1. "Introduction", second paragraph, the word "operation" > seems to be missing from the first sentence: > """ > This document discusses operational procedures to be applied in order > to reduce or eliminate loss of packets during a maintenance. > """ [Bruno] ok, fixed. > * Throughout the Appendices, there are some inconsistent uses of some terms, > especially when compared to the rest of the document: > > - "Local-Pref" versus "LOCAL_PREF" > - "nexhop" versus "NEXT_HOP" [Bruno] Thanks, fixed. :s/Local-Pref/LOCAL_PREF (*2) :s/nexthop/BGP NEXT_HOP (*2) > * In Appendix A. "Alternative techniques with limited applicability", the > phrase "describe them" ought to be "describes them". [Bruno] Thanks, fixed. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
