[sidr] Alissa Cooper's No Objection on draft-ietf-sidr-bgpsec-ops-13: (with COMMENT)
"Alissa Cooper" <alissa@cooperw.in> Wed, 04 January 2017 16:22 UTC
Return-Path: <alissa@cooperw.in>
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 BFB20129640; Wed, 4 Jan 2017 08:22:23 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alissa Cooper <alissa@cooperw.in>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.40.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148354694377.12928.12337719277813930522.idtracker@ietfa.amsl.com>
Date: Wed, 04 Jan 2017 08:22:23 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/E5gRilxVlBTdBRBUQK5xrz7VtNM>
Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-bgpsec-ops@ietf.org, sidr@ietf.org
Subject: [sidr] Alissa Cooper's No Objection on draft-ietf-sidr-bgpsec-ops-13: (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: Wed, 04 Jan 2017 16:22:24 -0000
Alissa Cooper has entered the following ballot position for draft-ietf-sidr-bgpsec-ops-13: 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: ---------------------------------------------------------------------- = Section 5 = "Route Reflectors MUST have BGPsec enabled if and only if there are eBGP speakers in their client cone, i.e. an RR client or the transitive closure of a client's customers' customers' customers' etc." "MUST ... if and only if" is a strange construction. I'm assuming what is meant here is that Route Reflectors MUST NOT enable BGPsec unless there are eBGP speakers in their client cone -- that might be a more sensible way to phrase this since clearly enabling BGPsec isn't required for anyone. Also, for a normative requirement I think it would be better to be specific rather than saying "etc." (e.g., "a client's customers or customers thereof" or something like that). "Additionally, outsourcing verification is not prudent security practice." Isn't that part of the point of draft-ietf-sidr-rpki-rtr-rfc6810-bis though? I know this paragraph is not talking about that but since use of a trusted cache was mentioned in the protocol draft, this struck me as a slight discrepancy.
- [sidr] Alissa Cooper's No Objection on draft-ietf… Alissa Cooper
- Re: [sidr] Alissa Cooper's No Objection on draft-… Randy Bush
- Re: [sidr] Alissa Cooper's No Objection on draft-… Alissa Cooper