Last Call Review of draft-ietf-grow-bgp-reject-04
review-ietf-grow-bgp-reject-04-opsdir-lc-martinez-2017-04-19-00

Request Review of draft-ietf-grow-bgp-reject
Requested rev. no specific revision (document currently at 08)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2017-04-18
Requested 2017-04-04
Authors Jared Mauch, Job Snijders, Greg Hankins
Draft last updated 2017-04-19
Completed reviews Opsdir Last Call review of -04 by Carlos Martínez (diff)
Secdir Last Call review of -05 by Takeshi Takahashi (diff)
Genart Last Call review of -04 by Dale Worley (diff)
Rtgdir Last Call review of -04 by Russ White (diff)
Secdir Telechat review of -08 by Takeshi Takahashi
Genart Telechat review of -07 by Dale Worley (diff)
Genart Telechat review of -08 by Dale Worley
Assignment Reviewer Carlos Martínez 
State Completed
Review review-ietf-grow-bgp-reject-04-opsdir-lc-martinez-2017-04-19
Reviewed rev. 04 (document currently at 08)
Review result Ready
Review completed: 2017-04-19

Review
review-ietf-grow-bgp-reject-04-opsdir-lc-martinez-2017-04-19

I have reviewed this draft as part of the last-call reviews of the
Operations Directorate. These comments should be taken by authors and WG
chairs just as any other last-call comment.

In its abstract this document mentions:

"This document defines the default behavior of a BGP speaker when
there is no import or export policy associated with an External BGP
session."

Introduction
The document's introduction describes a well known operational caveat that
has caused countless headaches over the years to those involved in BGP
operations. A BGP speaker may, and in may cases, will, accept and publish
anythin to its neighbors when there is no more specific routing policy
applied.

Proposed solution
The document proposes a set of default behaviours for BGP speakers in the
absence of configured routing policies.

The document references RFC4271 in the second paragraph. I believe it would
benefit from referencing 4271 in the third paragraph for the definition
of "EBGP peer".

The fourth paragraph proposes a default operating mode of "import nothing"
and "export nothing". This terminology should be familiar for anyone working
on BGP operations. I however believe the reader would benefit from a provided
definition of these terms.

The above comments are all minor points and Overall I believe the document
is clear and well written and ready to move forward.