[Sidrops] Alvaro Retana's No Objection on draft-ietf-sidrops-rtr-keying-03: (with COMMENT)

Alvaro Retana <aretana.ietf@gmail.com> Wed, 23 January 2019 17:46 UTC

Return-Path: <aretana.ietf@gmail.com>
X-Original-To: sidrops@ietf.org
Delivered-To: sidrops@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9DA130FB5; Wed, 23 Jan 2019 09:46:42 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Alvaro Retana <aretana.ietf@gmail.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-sidrops-rtr-keying@ietf.org, Chris Morrow <morrowc@ops-netman.net>, sidrops-chairs@ietf.org, sidrops@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.90.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154826560230.7563.12584828485918011085.idtracker@ietfa.amsl.com>
Date: Wed, 23 Jan 2019 09:46:42 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/VbDTawJAs1TfCvER3-4MJHS5qmc>
Subject: [Sidrops] Alvaro Retana's No Objection on draft-ietf-sidrops-rtr-keying-03: (with COMMENT)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Jan 2019 17:46:43 -0000

Alvaro Retana has entered the following ballot position for
draft-ietf-sidrops-rtr-keying-03: 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-sidrops-rtr-keying/



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

(1) I don't really have a strong objection for this document being a BCP. 
However, while documenting two different methods, there is no clear indication
of "what is believed to be the best" [rfc2026], or even better, which method
should be used in what situations.  I understand that operators have different
preferences/needs and that prescribing one method as the default in not the
right thing to do.

I would really like to see some text (maybe a "Deployment Considerations"
section) that talks about when one or the other might be preferred/considered.

(2) §4: s/BGP Identifier [RFC4271]/BGP Identifier [RFC6286]

(3) §4: "In the case where the operator has chosen not to use unique per-router
certificates, a BGP Identifier of 0 MAY be used." rfc6286 defines the BGP
Identifier as always being non-zero.  rfc8209 says that "if the same
certificate is issued to more than one router (and hence the private key is
shared among these routers), the choice of the router ID used in this name is
at the discretion of the Issuer."  It seems to me that it doesn't matter which
ID is used...it just can't be 0.  The simple fix is to just remove the sentence.

(4) §8: "Enabling the router-to-CA connectivity MAY require connections to
external networks (i.e., through firewalls, NATs, etc.)."  That "MAY" is out of
place because this sentence is just stating a fact.

(5) §8: "Note that the checks performed by the router in Section 7...SHOULD be
performed."  Besides confirming the checks from §7, I'm not sure what this
sentence really contributes...but I do think that the "SHOULD" is out of place
because the Normative language is already in §7.

(6) Nits
s/used by the the/used by the
s/corresponds to the private used/corresponds to the private key used