[sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT)

"Ben Campbell" <ben@nostrum.com> Tue, 03 January 2017 23:59 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: sidr@ietf.org
Delivered-To: sidr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1478B129453; Tue, 3 Jan 2017 15:59:16 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Ben Campbell" <ben@nostrum.com>
To: "The IESG" <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.40.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148348795694.28027.8646303758093237302.idtracker@ietfa.amsl.com>
Date: Tue, 03 Jan 2017 15:59:16 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/0ASO93EQoj2NK_mfd1zBYYPuRvg>
Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-bgpsec-ops@ietf.org, sidr@ietf.org
Subject: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Jan 2017 23:59:17 -0000

Ben Campbell has entered the following ballot position for
draft-ietf-sidr-bgpsec-ops-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-ops/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Update:  I noted when reviewing other sidr drafts on this telechat agenda
that this draft treats 2119 keywords differently than the other drafts.
That is, this draft explicitly excludes lower case versions of the 2119
keywords, while the other related drafts do not. Assuming that these
drafts have the same target audience, I think that will be confusing to
readers.

I am okay with either approach; in fact I somewhat prefer excluding lower
case versions. But I think consistency among a related group of drafts is
more important.

Just a few minor and editorial comments:

-1, first paragraph: "It is thought...": Can you mention "who" thinks it?
Otherwise that reads as "weasel words".

-1, third paragraph: Please consider writing out "also known as"

-4, first paragraph: I found "either" followed by "and/or" a bit
confusing. I suggest simply dropping the word "either".

-4, 2nd paragraph: The MAY seems like a statement of fact. Is it intended
to offer permission, or describe reality? (The latter should not use a
2119 keyword.)

-4, last paragraph: "a prudent operator will..." sounds like it might be
worthy of a SHOULD.

-6, first paragraph: "SHOULD/MUST only" constructions tend to be
ambiguous. In this case, are we saying SHOULD only originated signed
announcements, as opposed to unsigned announcements? Or as opposed to
validating received assignments? If the latter, then the "need not
validate" seems to weaken the SHOULD.

-6, last paragraph: Can something be cited for the 84% assertion?

-7, paragraph 6: This seems to say that signed paths MUST be signed. Does
the "MUST be signed if sent to external BGP speakers" mean that the
existing signature must not be stripped (as stated more weakly in the
previous sentence), or does it mean the sender must re-sign the path?

-7, paragraph 7: "a signed path learned via iBGP MAY be Not Valid." seems
like a statement of fact.

-12.2: [I-D.ietf.sider.bgpsec.overview] is mentioned in section 2 as
needed to understand this document. That suggests it should be a
normative reference. 



-