Re: [TLS] Opsdir last call review of draft-ietf-tls-iana-registry-updates-04

Russ Housley <housley@vigilsec.com> Tue, 27 February 2018 16:25 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE568124217 for <tls@ietfa.amsl.com>; Tue, 27 Feb 2018 08:25:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PqsPJdh31z1 for <tls@ietfa.amsl.com>; Tue, 27 Feb 2018 08:25:34 -0800 (PST)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1EFA12DA4B for <tls@ietf.org>; Tue, 27 Feb 2018 08:25:32 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C05AA3005D9 for <tls@ietf.org>; Tue, 27 Feb 2018 11:25:30 -0500 (EST)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Yz_B7ZZyu7cH for <tls@ietf.org>; Tue, 27 Feb 2018 11:25:28 -0500 (EST)
Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id B49E6300436; Tue, 27 Feb 2018 11:25:28 -0500 (EST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <D27C238D-C8F1-4FBC-A546-4555898CAE99@sn3rd.com>
Date: Tue, 27 Feb 2018 11:25:29 -0500
Cc: IETF TLS <tls@ietf.org>, ops-dir@ietf.org, IETF <ietf@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <57ECF9E5-80AC-4353-9E46-73A19BD085E3@vigilsec.com>
References: <151912347695.29703.11473433478669184845@ietfa.amsl.com> <D27C238D-C8F1-4FBC-A546-4555898CAE99@sn3rd.com>
To: Sean Turner <sean@sn3rd.com>, Dan Romascanu <dromasca@gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/1HwDdxRNGqfWAoNYz0qT-yROh6A>
Subject: Re: [TLS] Opsdir last call review of draft-ietf-tls-iana-registry-updates-04
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Feb 2018 16:25:36 -0000

> On Feb 20, 2018, at 05:44, Dan Romascanu <dromasca@gmail.com> wrote:
> 
> Reviewer: Dan Romascanu
> Review result: Has Issues
> 
> I am the assigned OPS-DIR reviewer for this draft. The OPS DIrectorate reviews
> a great part of the IETF documents being processed by the IESG for the OPS ADs.
> Please treat with these comments as with all other IETF LC comments. Please
> wait for direction from your document shepherd or AD before posting a new
> version of the draft.
> 
> This document which updates several TLS and DTLS RFCs describes a number of
> changes to TLS IANA registries that range from adding notes to the registry all
> the way to changing the registration policy. This is not a protocol or a
> protocol update document, thus a full OPS-DIR review conforming to RFC 5706 is
> not needed. From an operational point of view this document is important, as
> operators may need to refer to IANA registries in their daily work of ensuring
> functionality and maintaining networks where TLS and DTLS are used.
> 
> The document is Ready from an OPS-DIR perspective, with a few minor issues. The
> issues listed below are useful for all categories of users of this document:
> implementers, operators, end users. None is them is major, but it would be good
> to be addressed before the document approval.
> 
> 1. The document adds a Recommended column to many of the TLS registries. The
> rationale and meaning of a parameter being or not being Recommended are
> detailed in Section 6. It would be useful from an operator perspective to add
> to the registries where the Recommended column is added a text similar to the
> one in Section 6, that explains the rationale and the meaning. Something on the
> lines of:
> 
> * 'If a parameter is marked as Recommended, implementations
>  should support it. Adding a recommended parameter
>  to a registry or updating a parameter to recommended status
>  requires standards action. Not all parameters defined in standards
>  track documents need to be marked as recommended.
> 
>  If an item is not marked as Recommended it does not necessarily mean
>  that it is flawed, rather, it indicates that either the item has not
>  been through the IETF consensus process, has limited applicability,
>  or is intended only for specific use cases.’


Wouldn't it be sufficient to add a note a the bottom of the registry that says:

   If an item is marked as not recommended it does not necessarily mean
   that it is flawed, rather, it indicates that either the item has not
   been through the IETF consensus process, has limited applicability,
   or is intended only for specific use cases.

Russ