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

Russ Housley <> Tue, 27 February 2018 16:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CD7A712D969 for <>; Tue, 27 Feb 2018 08:22:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IiEG6kEQ8qQm for <>; Tue, 27 Feb 2018 08:22:00 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4F32512DA2C for <>; Tue, 27 Feb 2018 08:22:00 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 427343004CE for <>; Tue, 27 Feb 2018 11:21:58 -0500 (EST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id lIiFa4oGBpIB for <>; Tue, 27 Feb 2018 11:21:56 -0500 (EST)
Received: from a860b60074bd.home ( []) by (Postfix) with ESMTPSA id 595E83004D7; Tue, 27 Feb 2018 11:21:56 -0500 (EST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Russ Housley <>
In-Reply-To: <>
Date: Tue, 27 Feb 2018 11:21:57 -0500
Cc: IETF TLS <>, IETF Gen-ART <>, IETF <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Sean Turner <>, Stewart Bryant <>
X-Mailer: Apple Mail (2.3273)
Archived-At: <>
Subject: Re: [TLS] Genart last call review of draft-ietf-tls-iana-registry-updates-04
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 27 Feb 2018 16:22:02 -0000

>> Minor issues:
>> I think convention is to list the documents being updated in the Abstract, but
>> cannot find any formal guidance.
> You’re right that is the convention, but it’s not required.  draft-flanagan-7322bis is attempting to make including updates in the abstract a must, but it’s not been through any kind of LC yet.  There is a sentence there saying that a lot of RFCs are updated and to see the updates header so I think under the 7322 to balance concise and to not include references I’m thinking this is okay.

If another update top the document is needed, then it does not seem hard to comply with the coming convention.

>> If an item is marked as not recommended it does not necessarily mean
>> SB> Do you mean "marked as not recommended" or "not marked as recommended”.
> There are two states for the Recommended column: YES and NO.  I can go either way on whether
> marked as not recommended = NO
> not marked as recommended = NO
> WG - thoughts?

I think the second wording is more clear.

>> =======
>> SB>  I am worried about the semantics of Recommended = no.
>> SB> Presumably there are three states: recommended, not recommended,
>> SB> and silent/don't know/don't care/not yet. Which of these
>> SB> states does Recommended = no represent?
> There are two states and a draft that specifies a value in a registry that has a Recommended column needs to state which it is.  I’m not too concerned because we can change the column value later if it turns out a NO should have been a YES.

It would be more clear is Section 6 said that each parameter will have either "yes" or "no" in the new recommended column.