[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:28 UTC

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>
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148348613046.28010.9982061046362154033.idtracker@ietfa.amsl.com>
Date: Tue, 03 Jan 2017 15:28:50 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/XtM-vS79T7M8mncSHwuqeO0E1hE>
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)

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

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. 



-

[sidr] Ben Campbell's No Objection on draft-ietf-… Ben Campbell