IETF Logo Mail Archive

Re: [dns-privacy] Alexey Melnikov's Discuss on draft-ietf-dprive-dtls-and-tls-profiles-09: (with DISCUSS and COMMENT)

Alexey Melnikov <aamelnikov@fastmail.fm> Thu, 11 May 2017 12:25 UTC

Return-Path: <aamelnikov@fastmail.fm>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 448BD129422; Thu, 11 May 2017 05:25:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level:
X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=TMUnbdeF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QgTtMDy+
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 HFn3262-mEcb; Thu, 11 May 2017 05:25:45 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80FE1128C84; Thu, 11 May 2017 05:23:09 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id E5CDE20506; Thu, 11 May 2017 08:23:08 -0400 (EDT)
Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Thu, 11 May 2017 08:23:08 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=jExv9wpB59cxPaPW3rI4E4G+DY6xw CtJqnhuGtpTcTY=; b=TMUnbdeFHJSu+9SOu+k16IL6rBKNTuP7I1EjAzb9BsTVW Sc6069A6ZnZwonTD73ooTlcfj/6pG3QKWNx9ol/lKWH/bNMII5cREVVH2niNFnc1 zEemH3U9r5SX7IELVLVTdQtuMzy1DAC5M/DIwmh6lHS6wWfyDfPs64jaO5eu1vam CkZU/HL0CJPrn/5Hux91dh6XfuV7g13KpKrgIbwCT9eZeMIqVobjyozN6Q108kNU UltW581GYitx5hCcy2snjWlKeCsNBriUa1dkC+GeDQ6FZ7qn8Ix84WwRjpzioug9 O++y6YG/cQwgOU/H/uy/X7Gc+q9LgZ+0TjUQ2JIkA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=jExv9w pB59cxPaPW3rI4E4G+DY6xwCtJqnhuGtpTcTY=; b=QgTtMDy+c5jg+UriFYCUWV NMD9iZzna2XjwUcvLe9TkECWYZAwpAQPjf9pQj+8fdI6EXeqCOPzGSrCOwWfnGch R1P13jI11AnJkdQkaqXZkIdCqah6YCqMZehnw77rpviThTgqGxdLi/s976JAliSa KmkrVhjeIv3xHkkTNsEhXnYRCPcP0jOxG9cOIS6mbp8PwE71DMy9IsivyS/d2Bf4 Wbyn1skdYhTPBXiURyhmwSh3HaOEn9qt/rB2tGLEcK4mUu/XNuCUGNDNU+0dHSIO SibWBB67iY7TOqeiFAmzLbLqEXRB72EqRe49t0Uc96Y8ED+NoHKOICvHvwqrStGA ==
X-ME-Sender: <xms:rFcUWaMp94NRgRRScUN5N3m4gY4KJvHU8bGPbm9pGll5whp6x0XHnA>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id C36339E25D; Thu, 11 May 2017 08:23:08 -0400 (EDT)
Message-Id: <1494505388.20117.973209360.3E6B4BB1@webmail.messagingengine.com>
From: Alexey Melnikov <aamelnikov@fastmail.fm>
To: Sara Dickinson <sara@sinodun.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-dprive-dtls-and-tls-profiles@ietf.org, Tim Wicinski <tjw.ietf@gmail.com>, dprive-chairs@ietf.org, dns-privacy@ietf.org
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-6cc55fe1
Date: Thu, 11 May 2017 13:23:08 +0100
References: <149436978593.19294.10256470803161992800.idtracker@ietfa.amsl.com> <181B9399-EB5C-43CC-B21C-4A6CE77391DF@sinodun.com>
In-Reply-To: <181B9399-EB5C-43CC-B21C-4A6CE77391DF@sinodun.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/ypTerZ9QyDpKA-or-y1NKrr_iLk>
Subject: Re: [dns-privacy] Alexey Melnikov's Discuss on draft-ietf-dprive-dtls-and-tls-profiles-09: (with DISCUSS and COMMENT)
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 May 2017 12:25:47 -0000

Hi Sara,

On Thu, May 11, 2017, at 01:04 PM, Sara Dickinson wrote:
> 
> > On 9 May 2017, at 23:43, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:
> 
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> > 
> > (I just updated both my DISCUSS and my comment section.)
> > 
> > I would like to ballot YES on this document, but I would like to discuss
> > the following:
> > 
> > Sorry for being DownRef police, but RFC 7918 is clearly Normative
> > (because there is a SHOULD level requirement), but it is listed as
> > Informative reference.
> 
> I think that is a hangover from when it was referenced as a I-D
> 
> > It would be a DownRef once it is made Normative,
> > unless the procedure from RFC 8067 is used. Is RFC 7918 a suitable
> > DownRef? Is it widely implemented?
> 
> I just checked the early versions of the document and they actually
> included a note at the end of section 12 which has since been removed:
> 
> “ [NOTE: The references to (works in progress) should be upgraded to
>    MUST's if those references become RFC's prior to publication of this
>    document.]
> 
> At the time both RFC7918 and RFC7924 were still I-Ds. With that in mind:

Ok. This makes some sense.

> - Since RFC7918 is only Informational would it make more sense to use MAY
> and leave it as an informative reference. 

No. Firstly, a MAY level requirement is still Normative, as it is
required to implement. Secondly, whether a reference is normative or not
has nothing to do with whether the document being referenced is
Informational or any other kind.

> - But change the recommendation regarding RFC7924 to be a MUST and make
> that Normative (it is currently only informative).

I missed that. Please also make it Normative. (I have no opinion on
whether it should stay as SHOULD or become a MUST.)

Thank you,
Alexey

v2.23.0 | Report a Bug | By Email