Subject: [secdir] Secdir review of draft-ietf-sidr-bgpsec-ops-12

From: "Salz, Rich" <[email-masked]>
Date: Sun, 1 Jan 2017 19:29:23 +0000

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 AKA
   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.

---

From: Randy Bush <[email-masked]>
Date: Mon, 02 Jan 2017 09:26:41 +0900

thanks for the review.  always a pleasure to get competent reviews.

>   BGPsec need be spoken only by an AS's eBGP-speaking, or border, routers,

no problem with hyphen.  but "or" implies an alternative, which could
confuse.  what bothers you about "AKA?"  want it unpacked?  "often
termed?"

> Should section 2 be merged into section 1?

certainly could.  dunno about should. :)

> ROA should be spelled out when first used.

ack

> Section 4, "A large operator ... may accept" Perhaps deploy, not
> accept?

eenie meenie.  by "accept" i meant to imply a tradeoff.  but fine.

> I think the "On the other extreme" is redundant and could be removed.

ok, how about "At the other end of the spectrum?"  i am trying to paint
a tradeoff space.

> Section 5 change the comma to a colon in the first sentence?

you drove me back to strunk & white.  imiho, the second clause is
insufficiently independent (no verb, does not begin with "and," "but,"
etc), to use a semicolon.  and it certainly is not a 'follow' list,
which would use a colon.

> 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 :)

you're worse than my grandmother, an english teacher, who used to send
my letters back red-marked.

> Section 7, spell out iBGP at first use?

hmmm.  we did not unpack eBGP, BGP, or BGPsec.  we could go nuts, or is
it nits, here.  let's save finding the detent on this knob to rfced.
they are pretty careful in this space.

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

i tried that, changing "defined" to "described."  but actually that
document does not describe, let alone define, most of the operational
considerations this document tries to address.  as adding such a
sentence does not really add a lot to the semantics, i hope you do not
mind if i pass on this one.

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

one where the oxford comma did not bail me out.  good catch.

i have the edits in my xml copy.  shout if you think any are
sufficiently serious to warrant pussing the button.  otherwise i will
hold for other reviews.

again, thanks.

randy

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 2 Jan 2017 00:37:41 +0000

> confuse.  what bothers you about "AKA?"  want it unpacked?  "often

Often termed clears it up for me.

As for the rest, they really are fleas on a flea, and whatever you do is fine with me.