[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. -
- [sidr] Ben Campbell's No Objection on draft-ietf-… Ben Campbell
- Re: [sidr] Ben Campbell's No Objection on draft-i… Randy Bush
- Re: [sidr] Ben Campbell's No Objection on draft-i… Randy Bush
- Re: [sidr] Ben Campbell's No Objection on draft-i… Alvaro Retana (aretana)
- Re: [sidr] Ben Campbell's No Objection on draft-i… Ben Campbell
- Re: [sidr] Ben Campbell's No Objection on draft-i… Randy Bush
- Re: [sidr] Ben Campbell's No Objection on draft-i… Ben Campbell
- Re: [sidr] Ben Campbell's No Objection on draft-i… Randy Bush
- Re: [sidr] Ben Campbell's No Objection on draft-i… Ben Campbell
- Re: [sidr] Ben Campbell's No Objection on draft-i… Randy Bush
- Re: [sidr] Ben Campbell's No Objection on draft-i… Ben Campbell
- Re: [sidr] Ben Campbell's No Objection on draft-i… Randy Bush
- Re: [sidr] Ben Campbell's No Objection on draft-i… Ben Campbell