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

"Alexey Melnikov" <aamelnikov@fastmail.fm> Mon, 06 January 2020 17:30 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 1E73C120872; Mon, 6 Jan 2020 09:30:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.718
X-Spam-Level:
X-Spam-Status: No, score=-2.718 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.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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=oSyWz6jv; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=xDheIDs1
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 fTYh26isBjUb; Mon, 6 Jan 2020 09:30:25 -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 0A75C12086C; Mon, 6 Jan 2020 09:30:25 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 35E5E21D2B; Mon, 6 Jan 2020 12:30:24 -0500 (EST)
Received: from imap1 ([10.202.2.51]) by compute7.internal (MEProxy); Mon, 06 Jan 2020 12:30:24 -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=9UFv/0OMCP+yvFxa8C8tbYEufGYVV3G EhJBzbc9ZO1I=; b=oSyWz6jv6T6TuSvyJsTXSlk7hZTuOdCvbG9DXOhkk3yt487 J7PYeBLj6bcrzTcXyH5WzBoUDCNDZlG7qnpzN/PnXb8inA0NKqA+VBdOZbQi58cb miC17PheRe0iV4xAoOtG2QuiGwEkVWO7MngvFHRLmCUE8lgPl7rnK8BiAlkbThQZ 7LGM01wRdvMmS8YBg2lxEH4CIfRbdniHpTQ75mgWjtp3LAWtKpYUPfUYpFEIBDC3 7cbk1wg2he3yekBwSCoY53lncaoZBKK4J0IrU5XDs1YNdLKe0FTKULL8ahrhStAx 5Wr36Wjr1QRxMCLL4RXrhBEqjvBZlPifYa6sD2g==
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=9UFv/0 OMCP+yvFxa8C8tbYEufGYVV3GEhJBzbc9ZO1I=; b=xDheIDs1UoyQu3pHcum1Sk r2+NxENw+SLaSFXdj2F+7p3KNsyuCjC1cvkvHFU/ZyliJh+BBdjtK4lqiF92YqDF YCcE4C8R/senilbrXm6Jha5MGOEwJ7159CUVQI6B/HKEoQb0WzKedGnjHzLfx7/f X8dz7IxiIoW9kDQLwgcJywgI1gK7MSEqTAXYyBZRbtmCQafxCDGsr6ARryZc3kIC uLeHiwbF+RKi/OMAldpCbrcaKr/cP2/BPWuH2vV2zB+I/7wVQD9V0yq7V4vALJTp RRC2rMcJZiOuv4G6cjVRoDXFdo6yENNV8/H07DvoEFkUdo6wvcu/eu957Lmy72Fg ==
X-ME-Sender: <xms:r24TXizJFNtONkiBd4AXzD9O68ZPIlzyFYV7VJK33N_hvDjPCrbIhg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvdehtddguddtvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedftehl vgigvgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilh drfhhmqeenucffohhmrghinhepghhithhhuhgsrdgtohhmnecurfgrrhgrmhepmhgrihhl fhhrohhmpegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmhenucevlhhushhtvg hrufhiiigvpedt
X-ME-Proxy: <xmx:r24TXjYkhqveWe47wLreYxDHHtn5fUrkpnQ5ZKG-y6DkaSyVBU03JA> <xmx:r24TXnTGPz8PxX5AAiQ6i_52wSjOBVFTccDNieKAooeQ1ISUZP8eEA> <xmx:r24TXuj_r_gxf0gf3RgC4FxTq-THo1YqEo0EJKJyLCwJMT2iemIxGg> <xmx:sG4TXkKFsdK_KW9Zk2keGBlQSA2WwX6Z4lC2v7hbZ2sy5JyMEK9oHA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id B608BC200A4; Mon, 6 Jan 2020 12:30:23 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-731-g1812a7f-fmstable-20200106v2
Mime-Version: 1.0
Message-Id: <49f1a8ec-3b10-4af0-88c5-ddc097b8353a@www.fastmail.com>
In-Reply-To: <BN7PR11MB2547408F79E742E622F75E6EC92A0@BN7PR11MB2547.namprd11.prod.outlook.com>
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> <f1704915-d073-4bca-a933-9fc26a1d70b4@www.fastmail.com> <BN7PR11MB2547408F79E742E622F75E6EC92A0@BN7PR11MB2547.namprd11.prod.outlook.com>
Date: Mon, 06 Jan 2020 17:30:02 +0000
From: Alexey Melnikov <aamelnikov@fastmail.fm>
To: Panos Kampanakis <pkampana@cisco.com>
Cc: "ace-chairs@ietf.org" <ace-chairs@ietf.org>, Jim Schaad <ietf@augustcellars.com>, Ace Wg <ace@ietf.org>, The IESG <iesg@ietf.org>, "draft-ietf-ace-coap-est@ietf.org" <draft-ietf-ace-coap-est@ietf.org>
Content-Type: multipart/alternative; boundary="b8a941071a554ab593a83a1ea2aff90f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/VcZPpxcw8X56aYGmkYRHG9Fjiu4>
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, 06 Jan 2020 17:30:27 -0000

Hi Panos,

On Fri, Dec 27, 2019, at 5:20 AM, Panos Kampanakis (pkampana) wrote:
> Hi Alexey,

> 

> This commit https://github.com/SanKumar2015/EST-coaps/commit/77d65f0eb7a28282f363e5e48cd0d28970f9366e should address your feedback. The full discussion is in https://github.com/SanKumar2015/EST-coaps/issues/155

> 

> Let us know if it does not make sense.

Yes, the changes look fine to me. I just cleared my DISCUSS.

Best Regards,
Alexey

> Rgs,

> Panos

> 


> *From:* Ace <ace-bounces@ietf.org> *On Behalf Of *Alexey Melnikov
> *Sent:* Monday, December 23, 2019 9:42 AM
> *To:* consultancy@vanderstok.org; Carsten Bormann <cabo@tzi.org>
> *Cc:* ace-chairs@ietf.org; Jim Schaad <ietf@augustcellars.com>; Benjamin Kaduk <kaduk@mit.edu>; Ace Wg <ace@ietf.org>; The IESG <iesg@ietf.org>; draft-ietf-ace-coap-est@ietf.org; Klaus Hartke <hartke@projectcool.de>
> *Subject:* Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT)

> 

> 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).

> 

> 
> *Attachments:*
>  * smime.p7s