[Sidrops] Opsdir last call review of draft-ietf-sidrops-rtr-keying-02

Scott Bradner <sob@sobco.com> Wed, 26 December 2018 13:09 UTC

Return-Path: <sob@sobco.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 CEB3E130FDC; Wed, 26 Dec 2018 05:09:18 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Scott Bradner <sob@sobco.com>
To: <ops-dir@ietf.org>
Cc: draft-ietf-sidrops-rtr-keying.all@ietf.org, sidrops@ietf.org, ietf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.89.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154582975877.9431.8940530526143232465@ietfa.amsl.com>
Date: Wed, 26 Dec 2018 05:09:18 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/scOUEvjfyUN7sPjwsVqkwsFGzNM>
X-Mailman-Approved-At: Wed, 26 Dec 2018 08:27:21 -0800
Subject: [Sidrops] Opsdir last call review of draft-ietf-sidrops-rtr-keying-02
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, 26 Dec 2018 13:09:19 -0000

Reviewer: Scott Bradner
Review result: Serious Issues

This is an OPSDIR review of Router Keying for BGPsec
(draft-ietf-sidrops-rtr-keying).

This seems like a useful document but it is hard to see why it should be
standards track or why it should be using RFC 2119 type terminology.

Standards track should be reserved for technology specifications where
interoperability is an issue.  I do not see interoperability issues being
addressed in this document since it focuses on how to create keys rather than
the features of keys that might be important for interoperability.  (as an
aside, if this document were adopted on the standards track how would it ever
demonstrate interoperability to progress?) This seems much more of an
informational document to me and not even a BCP since the practices it
describes do not meet what I consider to be BCP material (see RFC 2026 section
5)

The same issue arises with the use of RFC 2119 type terminology – RFC 2119
terminology is only to be used where interoperability is an issue – see RF 2119
section 6:

6. Guidance in the use of these Imperatives
   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.

I did not discover any issues worth mentioning with the document if it is
viewed as operational guidance.

Scott