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

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

Return-Path: <randy@psg.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E34D129493; Sun, 1 Jan 2017 16:26:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.001
X-Spam-Level:
X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pX59toofUlR; Sun, 1 Jan 2017 16:26:47 -0800 (PST)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A9C5129475; Sun, 1 Jan 2017 16:26:47 -0800 (PST)
Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from <randy@psg.com>) id 1cNqSa-0004KX-Gj; Mon, 02 Jan 2017 00:26:44 +0000
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
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Jan 2017 00:26:48 -0000

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