Last Call Review of draft-ietf-grow-bgp-reject-04
review-ietf-grow-bgp-reject-04-genart-lc-worley-2017-04-10-00

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
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

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.