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 . Document: draft-ietf-grow-bgp-reject-04 Reviewer: Dale R. Worley Review Date: 2017-04-10 IETF LC End Date: 2017-04-18 IESG Telechat date: not scheduled Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. This is the shortest draft I've ever reviewed. There are only 41 lines of text that contain technical content. My knowledge of BGP is quite limited, so I cannot review the desirability of this solution. I assume that the routing and operations community has fully considered that question. I find the wording of section 2 to be poor: 2. Solution Requirements The following requirements apply to the solution described in this document: o Software MUST consider any routes ineligible for route selection (section 9.1.1 [RFC4271]), if no import policy was configured for the EBGP peer. o Software MUST NOT advertise any routes to an EBGP peer, if no export policy was configured. o Software SHOULD fall back to an "import nothing" and "export nothing" mode following failure of internal components, such as a policy engine. o Software MUST operate in this mode by default. o Software MAY provide a configuration option to disable this security capability. First, section 2 isn't the requirements for the solution, but the requirements *on BGP speakers* constitute the solution itself. Second, "software" seems to be a misnomer for "BGP speaker". (Compare with RFC 4271.) Third, the interaction of the final item with the 2119 words in the preceding items is awkward. Fourth, it seems that "routes" in the first item should be qualified by "advertised by an EBGP peer". In all cases, what is intended is clear, but the words don't seem to say it well. Revising the phrasing, I get: 2. Solution The following requirements apply to all BGP speakers: o A BGP speaker MUST consider any routes advertised by an EBGP peer ineligible for route selection (section 9.1.1 [RFC4271]), if no import policy was configured for the peer. o A BGP speaker MUST NOT advertise any routes to an EBGP peer, if no export policy was configured. o A BGP speaker SHOULD fall back to an "import nothing" and "export nothing" mode following failure of internal components, such as a policy engine. o A BGP speaker MAY provide a configuration option to disable the preceding behaviors, but it MUST implement them by default.