Re: Genart last call review of draft-ietf-grow-bgp-reject-04

[Job Snijders <[e-mail]>]

Dear Dale, 

I'd be happy to incorporate these changes. I appreciate that you
clarified the text.

Attached is an easy-to-read html rfcdiff which contains Dale Worley's
proposed changes verbatim. Unless someone speaks up against this
proposal, I'll upload this as a new -05 revision somewhere in the next
few days.

Kind regards,

Job

On Mon, Apr 10, 2017 at 06:26:16PM -0700, Dale Worley wrote:
> Reviewer: Dale Worley
> Review result: Ready with Nits
> 
> 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.