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

Sean Turner <sean@sn3rd.com> Tue, 27 February 2018 19:22 UTC

Return-Path: <sean@sn3rd.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 2F5EA126D05 for <tls@ietfa.amsl.com>; Tue, 27 Feb 2018 11:22:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com
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 Lvmtxz4M4ifY for <tls@ietfa.amsl.com>; Tue, 27 Feb 2018 11:22:06 -0800 (PST)
Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3179C127058 for <tls@ietf.org>; Tue, 27 Feb 2018 11:22:06 -0800 (PST)
Received: by mail-qt0-x230.google.com with SMTP id c7so24619614qtn.3 for <tls@ietf.org>; Tue, 27 Feb 2018 11:22:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; 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; d=1e100.net; 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 10.200.55.81 with SMTP id p17mr26341998qtb.282.1519759325231; Tue, 27 Feb 2018 11:22:05 -0800 (PST)
Received: from [172.16.0.18] ([96.231.218.194]) by smtp.gmail.com with ESMTPSA id m24sm846011qtc.81.2018.02.27.11.22.04 (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 <sean@sn3rd.com>
In-Reply-To: <AD0D8AD0-DC69-4254-B525-7D0C3545B05F@vigilsec.com>
Date: Tue, 27 Feb 2018 14:22:03 -0500
Cc: Stewart Bryant <stewart.bryant@gmail.com>, IETF TLS <tls@ietf.org>, IETF Gen-ART <gen-art@ietf.org>, IETF <ietf@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <0EF565D9-C1F4-480A-9D01-8BAEB616736E@sn3rd.com>
References: <151915624732.3939.12189669437030269709@ietfa.amsl.com> <C398E12E-1121-4182-B297-2CDC710C9731@sn3rd.com> <AD0D8AD0-DC69-4254-B525-7D0C3545B05F@vigilsec.com>
To: Russ Housley <housley@vigilsec.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/pOomxnK47HR5GfeKmLgc-mmwPY8>
Subject: Re: [TLS] Genart 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 19:22:08 -0000


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

fixed

>>> =======
>>> 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:

OLD:

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

NEW:

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

PR: https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/63