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

Randy Bush <randy@psg.com> Mon, 02 January 2017 00:26 UTC

Date: Mon, 02 Jan 2017 09:26:41 +0900
Message-ID: <m28tqunw72.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Rich Salz <rsalz@akamai.com>
In-Reply-To: <76b79dc5ec924487aaa3d098126d6ab6@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <76b79dc5ec924487aaa3d098126d6ab6@usma1ex-dag1mb1.msg.corp.akamai.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/Zo2yKOQpQl5vdowp5ttQTI8Uc6g>
Cc: IESG <iesg@ietf.org>, secdir <secdir@ietf.org>
Subject: Re: [secdir] Secdir review of draft-ietf-sidr-bgpsec-ops-12
Precedence: list

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

> 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,

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

[secdir] Secdir review of draft-ietf-sidr-bgpsec-… Salz, Rich
Re: [secdir] Secdir review of draft-ietf-sidr-bgp… Randy Bush
Re: [secdir] Secdir review of draft-ietf-sidr-bgp… Salz, Rich