Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT)

"Alexey Melnikov" <aamelnikov@fastmail.fm> Mon, 23 December 2019 14:42 UTC

Return-Path: <aamelnikov@fastmail.fm>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E454B1200C1; Mon, 23 Dec 2019 06:42:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.697
X-Spam-Level:
X-Spam-Status: No, score=-2.697 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=Q6PKphD7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=DqBKcDvA
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 NlH3Au61h8RC; Mon, 23 Dec 2019 06:42:50 -0800 (PST)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AB371200B7; Mon, 23 Dec 2019 06:42:50 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id A003821C1B; Mon, 23 Dec 2019 09:42:46 -0500 (EST)
Received: from imap1 ([10.202.2.51]) by compute7.internal (MEProxy); Mon, 23 Dec 2019 09:42:46 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm2; bh=8il5EFdC4+iOrbcEtz84kGUq64waNoB JePLhk6EIEM0=; b=Q6PKphD7IGXYrwMWKXPmhyl4hCOx823ZEXDvqO/f3Z4wYVw w8ar/LcMb5bpGJSLSMB/2oc5yqa/0pbIAlUCEVlB8jvWT1ZTpRoQ6+zw0fnY3a7N 1kegL1ZK0ue0j43LXZMeVYuokgMJpKYyxtNjP2Xaehv1sFuLZHZC7WNay7w/UpyC N6Twtn5a/oRJu8m7wfONVMAA2Z5IB1FZgV+XSLsIoNHqLtBJHdKSvBMIzmHIo//f EZ7KYEnehl5GE0UG3DFN/Sr+wLS/CZTNsPDBfrr4LanCrgccuy/WgYNJBrm2E7P8 lQakN4gO7zpmXQ4Dw+purbK5cwmZUUO5dp1C8KA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=8il5EF dC4+iOrbcEtz84kGUq64waNoBJePLhk6EIEM0=; b=DqBKcDvAxFSXsPN2vuSs86 sXbMYAyC4hr0q3TWKP+pdHpGOkKHkTR3JDnyFNCIxe7oZmwpKyG3fcErcUso00S6 /dh8rS9veaxPHVVZAH4sYRBlMUP0ShBsVsXBeFKlLY3efZVh1yfrhzFs3U0HoBng Y1ke85Z0YTBjpfWXxWHb+2b9DS50eO9u2D18oFS40zDx06IufEdWSfjPIxVKflVW RrWUAN/LeaY9LgUNMqPSj+y805UCq+ARRuBgqkW8qsizuqQCc4qbFHhGazGP67CW lD5un9qyhNbJRhGJomOabsib3ggrhj8f331bDlRNdSZjJOJ6bXVf0Q/uffYXf0Mg ==
X-ME-Sender: <xms:ZNIAXriOi_u27VO8Hhx7dn-hVZiKuQoDJBBGOdWDW_HY07qFdhgZTg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvddvtddgieejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrd hfmheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshht mhgrihhlrdhfmhenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:ZdIAXhrH2XkQDzSuSo7rLCkliPIb-vuNTdYMiKmbvY4OZMdGML3ZCA> <xmx:ZdIAXrEZZVRUBaiLkgY8xQlt2zsP6GvRFFYLM-6aJBCg2jHK34avTw> <xmx:ZdIAXrn-yiUvaQ2kvl9Omo37nygB7um-rQIOShDa6XFFADeI5guiYg> <xmx:ZtIAXhPwkbEp7LeE3PPOkbkty5wcc3RYGLd9EvtHIkbPMwa5Jo9kLg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id D1EA5C200A4; Mon, 23 Dec 2019 09:42:44 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-694-gd5bab98-fmstable-20191218v1
Mime-Version: 1.0
Message-Id: <f1704915-d073-4bca-a933-9fc26a1d70b4@www.fastmail.com>
In-Reply-To: <32540abd39940ad245e3c814e64a40e7@bbhmail.nl>
References: <157667562611.29907.6804425237641037015.idtracker@ietfa.amsl.com> <20191220004728.GF35479@kduck.mit.edu> <d798b1a3-8462-4605-a8d1-71fd9c3b6421@www.fastmail.com> <CAAzbHvZdLMQyX_wpeVCErzqS=0q9n5b-XbXfGDN_2iQAGRX6Yw@mail.gmail.com> <12E7D8E7-8354-4700-B92E-A07A9BC4B881@tzi.org> <32540abd39940ad245e3c814e64a40e7@bbhmail.nl>
Date: Mon, 23 Dec 2019 14:42:24 +0000
From: Alexey Melnikov <aamelnikov@fastmail.fm>
To: consultancy@vanderstok.org, Carsten Bormann <cabo@tzi.org>
Cc: Klaus Hartke <hartke@projectcool.de>, ace-chairs@ietf.org, Jim Schaad <ietf@augustcellars.com>, Benjamin Kaduk <kaduk@mit.edu>, Ace Wg <ace@ietf.org>, draft-ietf-ace-coap-est@ietf.org, The IESG <iesg@ietf.org>
Content-Type: multipart/alternative; boundary="3a22224eb1f640a394c73d1fbde4c809"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/XcBIihF_lgcQhMdn1_L89V0ZpG8>
Subject: Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT)
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Dec 2019 14:42:53 -0000

Hi Peter,

On Mon, Dec 23, 2019, at 9:12 AM, Peter van der Stok wrote:
> HI all,
> 
> We had this discussion about this specific text several times.
> I like to keep at least some text for the following reason:
> Implementers, new to coap without a photographic memory of RFC7252 text, are surprised by the absence of uri host in the examples, and tend to assume an error.
> 
> The curent text does not look like a "normative rephrasing" to me. 
> Nevertheless, is the suggestion below acceptable to everyone?
> 
> OLD
> 

> The Uri-Host and Uri-Port Options can be omitted if they coincide
>  with the transport protocol destination address and port
>  respectively. Explicit Uri-Host and Uri-Port Options are typically
>  used when an endpoint hosts multiple virtual servers and uses the
>  Options to route the requests accordingly.
> 
> NEW


> Section 5.10.1 of RFC7252 specifies that the Uri-Host and Uri-Port Options can be omitted if they coincide
>  with the transport protocol destination address and port
>  respectively. 
> 
> Other suggestions are welcome.

Your suggested text is much better.

Thank you,
Alexey

> Peter

> Carsten Bormann schreef op 2019-12-20 18:16:

>> On Dec 20, 2019, at 17:34, Klaus Hartke <hartke@projectcool.de> wrote: 
>>> 
>>> I would prefer if draft-ietf-ace-coap-est didn't say anything here,
>>> since the Uri-Host and Uri-Port options and whether they should be
>>> omitted or not is entirely specified by CoAP [RFC7252].*
>> 
>> Klaus has an important point here.
>> 
>> We need to be **much more** vigilant about specifications messing with their normative references.
>> Saying how they are used, yes, but re-stating (or, worse, re-interpreting) normative material from those references is prone to creating dialects that no longer interoperate with their unadulterated originals. Unless these are hopelessly broken(*) and this is the only way to fix them, this is a MUST NOT.
>> 
>> Grüße, Carsten
>> 
>> (*) the normative reference EST has an example for that case: The use of content-transfer-encoding with HTTP, which is explicitly ruled out in Section 19.4.5 of RFC 2616 (and now appendix A.5 of RFC 7231). That was a count of RFC 7030 messing with a normative reference, and in turn **needed** to be messed with in CoAP-EST (and eventually needs to be fixed in the parent specification, too).