Skip to main content

Last Call Review of draft-ietf-sidr-bgpsec-ops-12

Request Review of draft-ietf-sidr-bgpsec-ops
Requested revision No specific revision (document currently at 16)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2016-12-21
Requested 2016-12-07
Authors Randy Bush
I-D last updated 2017-01-05
Completed reviews Secdir Last Call review of -12 by Rich Salz (diff)
Genart Last Call review of -12 by Roni Even (diff)
Opsdir Last Call review of -12 by Sheng Jiang (diff)
Assignment Reviewer Rich Salz
State Completed
Request Last Call review on draft-ietf-sidr-bgpsec-ops by Security Area Directorate Assigned
Reviewed revision 12 (document currently at 16)
Result Has nits
Completed 2017-01-05
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

This document is Ready.  I have a few purely editorial suggestions below. I
also have a question which is perhaps out of scope for the review of this
document, which is why I say ready as opposed to with nits or almost ready. The
document explains that BGPsec is a new protocol that will be deployed over
years.  Is there a plan or intent to update this document as the community
gains experience?

The Introduction section is great with pointers to relevant documents. We need
to do more of that kind of thing.  My nits follow, and all are optional, in the
hopes of increasing clarify.

Section 1:
  BGPsec need be spoken only by an AS's eBGP speaking, AKA border, routers,
I suggest the following (if I got the meaning right); hyphenate and use or not
   BGPsec need be spoken only by an AS's eBGP-speaking, or border,  routers,

Should section 2 be merged into section 1?  ROA should be spelled out when
first used.

Section 4, "A large operator ... may accept"  Perhaps deploy, not accept?  I
think the "On the other extreme" is redundant and could be removed.

Section 5 change the comma to a colon in the first sentence?  In "The operator
should be aware..." change to "An" ?  Similarly in section 6, "Operators might
need to ..."  Change to "An operator"?  This is part of having overall
consistency about one/the/an operator reference.  A level of nit we don't
ordinarily think about :)

Section 7, spell out iBGP at first use?

Section 9, perhaps add a sentence like: "This document outlines some of the
operational issues defined there" or some such.

Section 11, are you thinking three parties or two?  If three, put the design
group last; if two, put the two names in parens.

Thanks for writing this.