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


= 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.