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

Sean Turner <> Tue, 27 February 2018 19:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2F5EA126D05 for <>; Tue, 27 Feb 2018 11:22:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Lvmtxz4M4ifY for <>; Tue, 27 Feb 2018 11:22:06 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3179C127058 for <>; Tue, 27 Feb 2018 11:22:06 -0800 (PST)
Received: by with SMTP id c7so24619614qtn.3 for <>; Tue, 27 Feb 2018 11:22:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sLEu4CyWB4rajuR2qoF3Hkkmf4dEKT2UyRcukSfDYxY=; b=mt/Urco8J+cyXBVHrJ3IXHnyIXIM3aih5GWg2zVG/tQf+e91w/a3S7uN9Oht7jeKtF 0Mf63SFBidtgR4o43eLcQhxVM4W2CnCpLuJu9JNstEfzKG6osaIcTMpaefiAmPUihMnd 9fblf2nkOL5oYLr7hXc/py5348ZfH2MW6+hN0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sLEu4CyWB4rajuR2qoF3Hkkmf4dEKT2UyRcukSfDYxY=; b=LxWpJ4zAypMB+iMCKEnN0tWM22LzQM3t6NECkaUXW7Hk/t2DRorrGRcccLLqR+SMPo AN+U7dl5tVZXGLG/gmJNXYGAyrpdpnfOTB2WZgWtC7OaP7JZ1RWr/Shvf2TpzecsknbD OaFE6hStvJHXAGtQjg6FLAa46x8WvqNnXoVxX2SynJ3qDrxpZLhpBQT3kN7h0UiMB6iV s8HNVhHFCrDzziwKKNJs6OuxF8IY3QffEtBe9B54sZ6bfWe8BQpDs1yZ9Pxy0lH3QUGO i7MO/gAn+4PJibAZETXMtG4zHwUlD2KnMwePdlqOX9WsjUO7JFmDvKfi1v3VR5bPpQfI jdMw==
X-Gm-Message-State: APf1xPC0E9LrzK/IHpEDlY4n0Ay91w8EZ1eu7wTSUZjefcqJzQo/udyl vVcFhvA97XIzkXQR5HUXf8w26Q==
X-Google-Smtp-Source: AG47ELv72Ui/PCBgHxJxhrTu7XCo2efuiE0on4CFlJ6cGY7TUdiRQ+Adu5gznJXbAk5j7qmoWnHeDA==
X-Received: by with SMTP id p17mr26341998qtb.282.1519759325231; Tue, 27 Feb 2018 11:22:05 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id m24sm846011qtc.81.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Feb 2018 11:22:04 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Sean Turner <>
In-Reply-To: <>
Date: Tue, 27 Feb 2018 14:22:03 -0500
Cc: Stewart Bryant <>, IETF TLS <>, IETF Gen-ART <>, IETF <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Russ Housley <>
X-Mailer: Apple Mail (2.3445.5.20)
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 19:22:08 -0000

> On Feb 27, 2018, at 11:21, Russ Housley <> wrote:
>>> 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.

Just an FYI I plan to object to 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.

Can do:


  The instructions in this document add a Recommended column to many of the
  TLS registries


  The instructions in this document add a Recommended column with a value
  of YES or NO to many of the (D)TLS registries