From nobody Thu Feb 1 07:51:04 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A08512D847 for ; Thu, 1 Feb 2018 07:51:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no 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 OxJd1rKWp7Gg for ; Thu, 1 Feb 2018 07:51:00 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92A7612EAD9 for ; Thu, 1 Feb 2018 07:50:59 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 19B5849387; Thu, 1 Feb 2018 16:50:51 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 8248310A; Thu, 1 Feb 2018 16:50:48 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::b44]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id F101639; Thu, 1 Feb 2018 16:50:47 +0100 (CET) Received: (nullmailer pid 3668 invoked by uid 1000); Thu, 01 Feb 2018 15:50:44 -0000 Date: Thu, 1 Feb 2018 16:50:44 +0100 From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= To: Carsten Bormann Cc: peter van der Stok , core@ietf.org Message-ID: <20180201155042.GA24116@hephaistos.amsuess.com> References: <20180103092213.GH14264@hephaistos> <20180117155221.GA24165@hephaistos.amsuess.com> <7b6888e664517db68320d5f046503414@xs4all.nl> <20180125135208.GH22953@hephaistos.amsuess.com> <32F511B1-8DB1-4D8D-8446-3D82CFC0E5BC@tzi.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="/04w6evG8XlLl3ft" Content-Disposition: inline In-Reply-To: <32F511B1-8DB1-4D8D-8446-3D82CFC0E5BC@tzi.org> User-Agent: Mutt/1.9.3 (2018-01-21) Archived-At: Subject: [core] Cool URIs for the Web of Things (was: Re: Next steps in RD-DNS-SD) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 15:51:03 -0000 --/04w6evG8XlLl3ft Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Carsten, Peter, and CoRE in general, On Thu, Jan 25, 2018 at 04:20:12PM +0100, Carsten Bormann wrote: > >> -IP address > >=20 > > An IP address may change, but the RD deals with URIs, and cool URIs > > don't change[TimBL98]. > > There is no requirement in RD that only cool URIs can be registered. >=20 > More seriously, this is one of the cases where wisdom from the Browser > Web enters the discussion here that may not be applicable. We already > ran into that issue with coap+tcp://, and it seems we will run into it > again and again. Leaving aside details of whether it's IP addresses or also host names that have become volatile, I think that this piece of browser wisdom is very applicable here. Link targets, form targets, or dynamic links are all expressed as URIs. We'll need to pack all that is required for any client to dereference it into the URI. Otherwise, all those link targets would need sideband information a la "The binding is to coap://[2001:db8::1]/foo, but actually I mean whichever device is currently registered at the example.com RD with the endpoint name node1", negating the purpose of single-string identifiers. The topic is as important now for the Web of Things as it was in 1999 for the browser web, maybe even more so, for back then, a user could act even on a bad ("Sorry, the page is gone, we've moved the content") redirect. > Well, we have never defined Uri-Host to carry a DNS name, but here it > indeed seems logical to use that. If we find a spot in the literal space allowed by URIs but not by DNS (and AFAICT the only such areas are IPvFuture and fake TLDs like .onion or .arpa), then lets pick it in this URI scheme -- or do it the next scheme. As I see it, we're mixing two different kinds of discovery we're trying to have the RD do: 1. Finding resources out of a pool This may involve user interaction and is similar to the DNS-SD process of listing the instances of a particular service in a domain. The queries used for this look like /rd-lookup/res?if=3Dcore.s&unit=3DdegC and are expected to return more than one result. 2. Getting the ephemeral address of a previous result. Right now, if an endpoint registers without a stable host name (which it, as you pointed out, might not even have), the lookup 1 returns an ephemeral "uncool" URI. It will be suitable for immediate consumption, but adding it to a batch, to a dynlink or just storing it for further use (browsers would call this bookmarking) is bound to fail sooner or later. If RD is to play a role in the latter, I'm all in for that -- but there should still be a stable URI result somewhere inbetween. Should a plain RD assist with that? Can it, at all? Should it do so unconditionally or only when the endpoint asks for cooler URIs? (RD-DNS-SD might provide some answers by serving a (any) stable name derived from the d=3D/ep=3D parameters pointing to the ephemeral address; that's not really the DNS-SD part that helps here but just plain DNS, if that is a suitable tool for this at all.) To compare this to the DNS-SD processes: There, PTR lookups give the client an instance name in something like 1, which it can then store internally. It can not usualy use that information in a link, though. (I've seen printer-internal URI schemes backslash-escape instance names for use inside the authority component, but nothing official). Step 2 is then following SRV, possibly TXT and A/AAAA records. > Instead, IoT devices use the RD to rendezvous. They don=E2=80=99t have > anything but their IP addresses yet, so renumbering events *will* > change those. But that is not a problem, as RD data can be updated > easily. How does this solve the problem of DNS names being unstable or brand-dependant, when we expect devices to interoperate on an Internet scale (ie. without necessarily sharing an RD)? It just shifts it from the individual device to which RD is used (and thus trusted with identifying endpoints). Say we extend the CoAP URI schemes so that coap://example.com(d=3Dmy-domain,ep=3Dnode1)/sensor/temp would be resolved as "Find an RD at example.com, query for an endpoint with those d and ep parameters, and use its address". This still needs DNS as initial rendevouz point and just adds a step. Granted, we could just expect every network to provide an RD that hooks into a global RD network, but that'd go further than even the wild speculation in core-rd-replication. We could also expect devices that communicate to share an RD, but while that migh work in an enterprise environment, it brings the danger of vendor silo-ification to consumers. > Actually, the main reason to pursue the RD-to-DNS-SD mapping is to > have an ordered way to export RD information over to the DNS, [...] I think that RD-DNS-SD can already do that no matter how we decide in the open questions. The topic we're talking about here is much more a general RD, possibly also CoRE or T2TRG issue. (Changing the recipients list to reflect that). > > If a device expects to have a longer life cycle than its assigned > > address, IMO it should not register with an IP literal. (This is a > > general RD topic, actually). >=20 > No, it should keep simply keep its RD info updated. How about "it should keep the RD updated, and ask the RD to hand out something more persistent instead"? (Or can the RD infer that request =66rom the regiatration?) Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --/04w6evG8XlLl3ft Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlpzNzQACgkQOY0REtOk veGadxAAzwhjULziKXNQAa3mntY9FRNfS95JODS6HjgyjhmsI2+nQQQKf5ePjYok jghhWwT7iSAUIQArmnLKQrFWmrmQL7MccJNW4oMSiQPGLRcsqoR+MhT17H5Cqhl1 U1/zwZ7NyTc4/9BT5OtZyp3GbgGIPoF8N8p0Qla8RPyVKaGXwtZE0iaHgAm9APXx PjfiQYuRJLXisJISFx6OidOa5RAZOH98YjSzjYS0Xf4OjGxCypJfPZe4IIMBQKHO vuUwvcHQHXVkWQCwndi/RBlwTfxTq7miFqF2xnNuXTGrtQHtgDk++6rgS6BNi1a3 HUgKNIT4F47swNoEL9em++FfHTGWBr5W07qmofurk0KSSxF/4mAHULEPOQGRROhZ ZMSdYHavLlwpHU3YQk8CjTjTo3Yu2yXBUPOPEYCHkuTzdVjpUijDznAjmmYv+0OE Nyi/pzp0ElALEkbEa1tVvg2jRWp5akZtco5u4YH5rzNyVIWTef88u7piBdn63krM o3yi0fwmoeWoAIUHqKJFclliIaS0yljBstMzMHfyIOg4NlSzjqVjauAY7UJW1H13 jGGsAumLAxSxrEsn/ioTw08JZ0ACAQcVbse+Lj/B6bTFMAU03aKv2AVcqGhtZT6d RDhh+KkNNuZcJuMZQpEOP4bKxqUUdvh+GbrGObnTPug9E/uLAmU= =b3Mv -----END PGP SIGNATURE----- --/04w6evG8XlLl3ft-- From nobody Fri Feb 2 02:07:29 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34DE112FAA5 for ; Fri, 2 Feb 2018 02:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no 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 2Mk-YqISuh41 for ; Fri, 2 Feb 2018 02:07:26 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3701412FAA3 for ; Fri, 2 Feb 2018 02:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w12A7FJB022465; Fri, 2 Feb 2018 11:07:15 +0100 (CET) Received: from [134.102.117.161] (unknown [134.102.117.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3zXt2C1CHTzDXPq; Fri, 2 Feb 2018 11:07:15 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: <20180201155042.GA24116@hephaistos.amsuess.com> Date: Fri, 2 Feb 2018 11:07:14 +0100 Cc: peter van der Stok , core@ietf.org X-Mao-Original-Outgoing-Id: 539258833.766305-35b02e2a04183f3e2e3c34f5cf4b36f9 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180103092213.GH14264@hephaistos> <20180117155221.GA24165@hephaistos.amsuess.com> <7b6888e664517db68320d5f046503414@xs4all.nl> <20180125135208.GH22953@hephaistos.amsuess.com> <32F511B1-8DB1-4D8D-8446-3D82CFC0E5BC@tzi.org> <20180201155042.GA24116@hephaistos.amsuess.com> To: =?utf-8?Q?=22Christian_M=2E_Ams=C3=BCss=22?= X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [core] Cool URIs for the Web of Things (was: Re: Next steps in RD-DNS-SD) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 10:07:28 -0000 Hi Christian, this is a long discussion. We had some of this in Ludwigsburg, but we didn't continue it very much since, and maybe it is time to do so. This discussion cannot he had without thinking about *identity*. (In the sense of RFC4949, and not in the English sense.) In the IoT, many people are thinking about *Device Identity* (DI). Device Identity stays with a specific device and is generally immutable. It may spawn derived identities such as AIKs, but this is not of major interest for the present discussion. However, DI is not what is needed in most practical applications. In reality, devices break, get lost, or have to eb taken out of service for other reasons. While some devices allow the transfer of their device identity to a new device (a procedure known by some as fal-tor-pan), there are some difficulties with that [security; the new device may not be completely identical to the old one], so I'll ignore the possibility for now. So what do we do when we have to replace the temp sensor in room 451? We install a new device, with a new DI, but assign it the same "Role Identity" (RI). So everyone can work with "the temp sensor in room 451", before or after the change, under the continuing RI. But how do we communicate with a device or a holder of a role? We also need an identity for communication, which I'll call the "Plumbing Identity" (PI). In the Browser Web, PI and RI are conflated. This has worked reasonably well, so well that sometimes people think this is a founding principle of the Web. Really, it was a historical accident -- we initially used a PI as an RI, simply assuming that the plumbing was stable and secure enough, with DNS as the indirection allowing for more stable PIs. When it became apparent that neither DNS nor the plumbing itself were secure enough, the RI aspect of the PI was reinforced by authenticating it via TLS and the PKI. What we really will need to make the IoT work are Semantic Identities (SI). Room 451 may have a refrigerator, and that may also have a temperature sensor for the ambient temperature. That does not make the refrigerator *the* new "temp sensor in Room 451", it still keeps its role as refrigerator. It may also have some semantic properties (latency of the sensor, accuracy etc.) that make it differ from "the temp sensor in Room 451" and are part of its SI. If I need the temperature in Room 451, I may want to make do with the fridge's sensor if the other sensor is down, or I may want to fuse the sensors. If you go to an RD and look for a resource that is intrinsically a temp sensor for ambient temperatures and contextually in Room 451, you are essentially implementing SI. But that is a digression for the current discussion. Back to DIs, PIs, and RIs. PIs come in different forms. If your stable PI is a DNS name, you need to convert this into an IP address (possibly via a service record) before it becomes useful as a PI. You don't want to do this for each interaction, so you keep the directly usable PI (IP address) around, and the question becomes interesting how often you run the protocol to convert a stable PI into a usable one. There is little difference between RD and DNS here, except that RD has space for useful semantic attributes and can talk about resources, not just endpoints. SRV records could be used for transport selection in DNS; in RD that would be built in. So what do we write into those cool URIs? In the Browser Web, DNS names (and only occasionally IP addresses); transport negotiation happens in TLS (ALPN). For CoRE: if we want to use RD as the indirection mechanism toward directly usable PIs, the resource descriptions to be found there will need to provide IP addresses in them (just as they usually have a transport binding in them, which a cool URI would not). The URI is a natural place for an IP address, but it is not the only way. In any case, for a cool URI we would still need to find what could be the stable identifier to be put into the authority -- OCF has an idea for that... Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Feb 2 02:14:45 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5657512FAB2 for ; Fri, 2 Feb 2018 02:14:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no 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 tIxV-I8mMu-N for ; Fri, 2 Feb 2018 02:14:21 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D83D12FAAF for ; Fri, 2 Feb 2018 02:14:11 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w12AE5cC029022; Fri, 2 Feb 2018 11:14:05 +0100 (CET) Received: from [134.102.117.161] (unknown [134.102.117.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3zXtB566rXzDXQ1; Fri, 2 Feb 2018 11:14:05 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: Date: Fri, 2 Feb 2018 11:14:05 +0100 Cc: core@ietf.org X-Mao-Original-Outgoing-Id: 539259244.474666-262b2124dcf94c6a4b25e8c21fc3f0ff Content-Transfer-Encoding: quoted-printable Message-Id: <5B2343D0-AD45-45C3-BB41-752B902B0F00@tzi.org> References: <20180103092213.GH14264@hephaistos> <20180117155221.GA24165@hephaistos.amsuess.com> <7b6888e664517db68320d5f046503414@xs4all.nl> <20180125135208.GH22953@hephaistos.amsuess.com> <32F511B1-8DB1-4D8D-8446-3D82CFC0E5BC@tzi.org> <20180201155042.GA24116@hephaistos.amsuess.com> To: =?utf-8?Q?=22Christian_M=2E_Ams=C3=BCss=22?= X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [core] Cool URIs for the Web of Things (was: Re: Next steps in RD-DNS-SD) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 10:14:27 -0000 On Feb 2, 2018, at 11:07, Carsten Bormann wrote: >=20 > Ludwigsburg Forgot to add a reference: = https://github.com/t2trg/2016-10-implementers/blob/master/slides/T2TRG-201= 6-10-implementers-chair-material.pdf =46rom slide 35=E2=80=A6 Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Feb 2 06:05:34 2018 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E4C4112D810; Fri, 2 Feb 2018 06:05:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: cabo@tzi.org, core-chairs@ietf.org, core@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.71.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151758033190.31856.14053511400747792450.idtracker@ietfa.amsl.com> Date: Fri, 02 Feb 2018 06:05:31 -0800 Archived-At: Subject: [core] core - New Meeting Session Request for IETF 101 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 14:05:32 -0000 A new meeting session request has just been submitted by Carsten Bormann, a Chair of the core working group. --------------------------------------------------------- Working Group Name: Constrained RESTful Environments Area Name: Applications and Real-Time Area Session Requester: Carsten Bormann Number of Sessions: 2 Length of Session(s): 2 Hours, 2 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: cbor httpbis artarea t2trg suit ace lpwan 6lo roll teep Second Priority: dnssd saag irtfopen 6tisch netconf netmod sacm emu Third Priority: lwig detnet quic v6ops opsarea cfrg icnrg People who must be present: Carsten Bormann Alexey Melnikov Jaime Jimenez Resources Requested: Special Requests: Please also avoid any IoT related BOFs. Many WG contribtrs this time are moving onward on Thu eve/Fri to the Prague OCF/W3C meetings. It would be preferable to have no meetings after Thu lunch. --------------------------------------------------------- From nobody Fri Feb 2 10:26:33 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA11412DA3E for ; Fri, 2 Feb 2018 10:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no 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 sWTLvMxPbgJx for ; Fri, 2 Feb 2018 10:26:20 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2D5B12D87C for ; Fri, 2 Feb 2018 10:26:13 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 868DE48B0E; Fri, 2 Feb 2018 19:26:09 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 4EA6E56; Fri, 2 Feb 2018 19:26:08 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::b44]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 0E6A939; Fri, 2 Feb 2018 19:26:08 +0100 (CET) Received: (nullmailer pid 25357 invoked by uid 1000); Fri, 02 Feb 2018 18:26:06 -0000 Date: Fri, 2 Feb 2018 19:26:05 +0100 From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= To: Carsten Bormann Cc: core@ietf.org Message-ID: <20180202182604.GA7977@hephaistos.amsuess.com> References: <20180103092213.GH14264@hephaistos> <20180117155221.GA24165@hephaistos.amsuess.com> <7b6888e664517db68320d5f046503414@xs4all.nl> <20180125135208.GH22953@hephaistos.amsuess.com> <32F511B1-8DB1-4D8D-8446-3D82CFC0E5BC@tzi.org> <20180201155042.GA24116@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.3 (2018-01-21) Archived-At: Subject: Re: [core] Cool URIs for the Web of Things X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 18:26:23 -0000 --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Carsten, On Fri, Feb 02, 2018 at 11:07:14AM +0100, Carsten Bormann wrote: > Back to DIs, PIs, and RIs. These are convenient terminology > PIs come in different forms. If your stable PI is a DNS name, you > need to convert this into an IP address (possibly via a service > record) before it becomes useful as a PI. You don't want to do this > for each interaction, so you keep the directly usable PI (IP address) > around, and the question becomes interesting how often you run the > protocol to convert a stable PI into a usable one. Let me try to link this to URI concepts and schemes we have so far, and link it to the identity's authenticity[1]: * Transport specific URIs with address literals (coap+tcp://[2001:db8::1]/ & co): These clearly encode PIs.=20 The client can not establish whether the server it talks to uses that identity authentically (short of trusting the network). * Transport specific URIs with DNS names: Those can be RIs or DIs depending on how the name owner uses DNS, with some plumbing information included (the protocol) and the rest easily derivable (doing plain DNS lookups). The lookup result can not be treated as a derived URI, for that loses "virtual host" information the server might rely on. For the TLS based schemes, the server proves the authenticity of its identity during the handshake. * ocf://{uuid}/ style URIs: Clearly encoding DIs ([2] actually calls the URI's authority component Device ID). Those addresses are used in parallel with IP-literal URIs and resolved in what appears to be a mixture of RD operation and side-banding the literal URIs in target attributes of links to the ocf:// URIs. AFAICT no information is encoded in the URI that allows a client to establish the server identity's authenticity; certificates can sign a device UUID, but that obviously only works if both already share a trust anchor. =20 There is a concept of UAIDs based on cryptographic hashes (urn:usid: URIs, which are also used in CN of certificates), but I don't understand how those are interlinked. I think that on the way to A Big Solution, some questions we should ask ourselves are: * Of all the form of identities, do we need to have URI representations of all of them? (Esp. Is it an issue that our PIs can not always be expressed in URIs?) * Can we use the more abstract identities on embedded devices? (RIs should be doable, SIs are still a bit fuzzy). Can we provide resolution mechanisms such that we can always operate on RIs? (Are there situations where we *want* a DI or PI URI? When talking *about* a device, DI and RI intermix.) Best regards Christian [1] RFC4949 p148 par.1 talks about the identity's authenticity and eligibility. I think that in a client-server context, the former matters and should be derivable from a URI, while the latter does not because it'd need to be established when the client receives the URI, not when it dereferences it. [2] https://openconnectivity.org/specs/OCF_Core_Specification_v1.3.0.pdf --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --d6Gm4EdcadzBjdND Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlp0rS8ACgkQOY0REtOk veHZxhAA0Nqrdr0XyEooo9OX86MGsmcAuWPfdTFJilMZNWYK6gdGZO+m3VMgC9t7 3M1cEeV+xJedmgoYTA/nvZ8I9QUEBwZeiscIj/Jn/14RFcy+uMbyc9Fe5708bnwf nKYHjbUwcumCMhIF//laHnnMALGy9+I78vvZw0Qr+gSlPKE7a/D4MPxLReUH1woW ZxwdjJL6gXKNhoLxAke5v/QvQ4ZkJ7UKi+rd7HgWvv9NhhAw0VqvdBeQd1FYjbvL 3xg/KIW4YhOLleExcD52gD39wzOvt8BsSnlc7QafkHG8Oqa+4yDSKFEEXSfEshy/ 3CVAxznrOHmFGR25fs0osz5V1Iph12DdsRKUg68Nl7jSjdiGtL5H5/pTvy9RKvP/ OhppTbyQvWG+JbeknHWFVXBceHmUcpMZ9la4qasoH5MSbq5dP6S1JD/qZKk8SChL hyWP7lo2jvz0HnEwlY8nP6zzP56rV2JebTvsXOxk6Bvoxk/5tU4PPMrdVhqgbjli vZ8TeOuW15d48Ceh5r2fhV7Jdm7KEF329ah49T/VbQ7aQr2OFb5UbGreNr4YVWyo 7IcA9sJ/2pDD+dOCtnPaHyAZTPm40KVUw4aENBm1AMMJIMDjq62HCApB6gwnrB/2 6shgEyboGIF4mzWzuDWiN2GMXyfmRELnpyJ8qD0joIWjTn+kWVE= =7OLh -----END PGP SIGNATURE----- --d6Gm4EdcadzBjdND-- From nobody Sat Feb 3 13:11:31 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 125A512D77B for ; Sat, 3 Feb 2018 13:11:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 8v0xEKHV3xWD for ; Sat, 3 Feb 2018 13:11:28 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F3BE129C6C for ; Sat, 3 Feb 2018 13:11:28 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 424ADB80BFB; Sat, 3 Feb 2018 13:11:25 -0800 (PST) To: zach@sensinode.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, cabo@tzi.org, jaime@iki.fi X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: davidm@egauge.net, core@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20180203211125.424ADB80BFB@rfc-editor.org> Date: Sat, 3 Feb 2018 13:11:25 -0800 (PST) Archived-At: Subject: [core] [Technical Errata Reported] RFC6690 (5254) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Feb 2018 21:11:30 -0000 The following errata report has been submitted for RFC6690, "Constrained RESTful Environments (CoRE) Link Format". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5254 -------------------------------------- Type: Technical Reported by: David Mosberger Section: 2 Original Text ------------- relation-types = relation-type / DQUOTE relation-type *( 1*SP relation-type ) DQUOTE Corrected Text -------------- relation-types = reg-rel-type / DQUOTE relation-type *( 1*SP relation-type ) DQUOTE Notes ----- As defined originally "relation-types" may consist of a "URI". RFC 3986 defines URI to allow semi-colons in various places. For example, "http://;" seems to be a valid URI. Unfortunately, that makes parsing a link-param list ambiguous since its elements are separated by semicolons. The proposed fix to to allow "ext-rel-type" (i.e., "URI") to appear only inside a quoted relation-type list. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6690 (draft-ietf-core-link-format-14) -------------------------------------- Title : Constrained RESTful Environments (CoRE) Link Format Publication Date : August 2012 Author(s) : Z. Shelby Category : PROPOSED STANDARD Source : Constrained RESTful Environments APP Area : Applications Stream : IETF Verifying Party : IESG From nobody Sun Feb 4 00:09:33 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A2C126CC4 for ; Sun, 4 Feb 2018 00:09:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no 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 nCtR7wr6CRWA for ; Sun, 4 Feb 2018 00:09:29 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80F18126BF7 for ; Sun, 4 Feb 2018 00:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w1489Lpd025398; Sun, 4 Feb 2018 09:09:21 +0100 (CET) Received: from [192.168.217.102] (p5DC7EAF5.dip0.t-ipconnect.de [93.199.234.245]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3zZ3KF0VHFzDXl7; Sun, 4 Feb 2018 09:09:21 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: <20180203211125.424ADB80BFB@rfc-editor.org> Date: Sun, 4 Feb 2018 09:09:20 +0100 Cc: zach@sensinode.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, jaime@iki.fi, davidm@egauge.net, core@ietf.org X-Mao-Original-Outgoing-Id: 539424558.904771-e1c46a1f7883dce34df09ae3e3bcb32a Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180203211125.424ADB80BFB@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [core] [Technical Errata Reported] RFC6690 (5254) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Feb 2018 08:09:32 -0000 Hi David, while the observation is correct that there are URIs (Instances of = ext-rel-type) that disturb parsing of link-value-lists, the cure cited = here is worse than the ailment: It would suddenly rule out constructs = such as: rel=3Durn:foo:bar (1) Yes, this could be quoted, as in rel=3D=E2=80=9Curn:foo:bar=E2=80=9D (2) but example 1 is legal 6690 syntax now. Better to add an English language restriction to the production that = URIs that disturb link-value-list parsing are not to be used outside of = double quotes. Background: The whole idea of using ABNF to describe both the unquoted and quoted = values is deeply broken. See RFC 8288 for how to do this right. =20 We=E2=80=99ll need to update RFC 6690 at some point, and we=E2=80=99ll = certainly move up to RFC 8288 from RFC 5988 then. Up to then, we should avoid introducing more artifacts that stem from = this failed attempt, such as suddenly outlawing the perfectly parsable = example 1 above. Gr=C3=BC=C3=9Fe, Carsten > On Feb 3, 2018, at 22:11, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC6690, > "Constrained RESTful Environments (CoRE) Link Format". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5254 >=20 > -------------------------------------- > Type: Technical > Reported by: David Mosberger >=20 > Section: 2 >=20 > Original Text > ------------- > relation-types =3D relation-type > / DQUOTE relation-type *( 1*SP relation-type ) = DQUOTE >=20 > Corrected Text > -------------- > relation-types =3D reg-rel-type > / DQUOTE relation-type *( 1*SP relation-type ) DQUOTE >=20 >=20 > Notes > ----- > As defined originally "relation-types" may consist of a "URI". RFC = 3986 defines URI to allow semi-colons in various places. For example, = "http://;" seems to be a valid URI. Unfortunately, that makes parsing a = link-param list ambiguous since its elements are separated by = semicolons. >=20 > The proposed fix to to allow "ext-rel-type" (i.e., "URI") to appear = only inside a quoted relation-type list. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC6690 (draft-ietf-core-link-format-14) > -------------------------------------- > Title : Constrained RESTful Environments (CoRE) Link = Format > Publication Date : August 2012 > Author(s) : Z. Shelby > Category : PROPOSED STANDARD > Source : Constrained RESTful Environments APP > Area : Applications > Stream : IETF > Verifying Party : IESG >=20 From nobody Tue Feb 6 03:04:43 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8E7129BBF for ; Tue, 6 Feb 2018 03:04:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 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 M7JVrLsoBFf3 for ; Tue, 6 Feb 2018 03:04:39 -0800 (PST) Received: from lb3-smtp-cloud7.xs4all.net (lb3-smtp-cloud7.xs4all.net [194.109.24.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10CE1124205 for ; Tue, 6 Feb 2018 03:04:38 -0800 (PST) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:214]) by smtp-cloud7.xs4all.net with ESMTPA id j13EezluY3A62j13EeeoMj; Tue, 06 Feb 2018 12:04:37 +0100 Received: from AMontpellier-654-1-119-113.w90-0.abo.wanadoo.fr ([90.0.134.113]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 06 Feb 2018 12:04:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 06 Feb 2018 12:04:36 +0100 From: peter van der Stok To: Core Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfOI09POD+WzrkOo04EAaatJqJJr2VzfgPnDIycT9T440WGA97+G+6EyFRwiXSQ/vH8CHHvUdZdazypGcBt1Pi6TQC5EQLhbSz4DLiWVyfeP4/FdtBq1W 4ZXTebU6BVBiFCFP/4vlFCwN/mlUZ0D/YygFKap4g7vBdDFhP90iWSsx6ac4JC4GeAh6wLhLke4p5LmXA4xoLZAQMO5XTqqnV6s= Archived-At: Subject: [core] tiloca-core-muticast-oscoap-4 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 11:04:42 -0000 Hi authors, Many thanks for this very useful document. Below some comments. These are mainly restricted to document structure, relation to other documents, and new concepts and terminology. I hope they are sufficiently clear and help improving the text. Peter Abstract: I did not see text that validates the phrase: “All security requirements fulfilled by OSCORE are maintained for multicast OSCORE request messages and related OSCORE response messages.” I did see: this document specifies the parameter values for OSCORE messages applied to group communication. Why is source authentication more important (mentioned separately) than all other security aspects of OCORE? Introduction: Benefit from a group communication model: A possible group communication model is the use of unicast for all individual destinations; I don’t see how this increases efficiency. May-be you mean: leveraging the broadcast model of the underlying communication medium? Across intermediary nodes -> possibly involving intermediary nodes. The phrase: “To this end, …. protected message” is funny. I did not know that you could protect messages by including payload (something went wrong in this phrase). Remove: “while fulfilling the same security requirements”. My suggestion: end-to-end security is assured by using the same security technology as for OSCORE. The OSCORE draft mentions: “providing end-to-end encryption, integrity, replay protection, and secure the binding of response to request”. It does not mention source authentication explicitly. So, why is multicast-oscoap different? Section 1.1 Multicaster: Is M <= N? sub-question is: are the destinations always all group members and is the source also a destination? May be you should refer to section 2.2 which provides a better explanation. Endpoint ID: why this exclusion of pure listeners? It complicates the protocol. Remove: “That is, …. same time”. Does not clarify uniqueness. Section 2. I do understand the purpose of section 2.2, but not of section 2.1. As far as I understand the Group Manager is essential for secure group communication as specified here; No GM means no group communication (is that correct?) In that case I would suggest two other subsections. Section 2.1a Requirements on group manager, section 2.1b, Protocol characteristics. Multicast communication topology: remove the lighting use case, and refer to appendix. Multicast group size: is this the number of members? The fact that a member may be listener as well as multicaster is another aspect and not relevant to size. The numbers are interesting to guide implementers. Establishment and Management of Security context: I recommend to mention relation to OSCORE security contexts. Actually, the text seems to discuss requirements on the GM. GM specification is out of scope but not any GM design can be used with oscoap-multicast. Multicast data security Cipher suite: GM requirement?? Backward security: GM requirement? Actually, this poses the question of ordering of messages from different sources; Is there a total ordering of messages or only a partial source order? (I see this is explained in section 2.2) May be a forward reference? Forward security: GM requirement?. Section 2.2 security Objectives Bullet 2; remove “In fact, …plaintext” ; does not add much Bullet 3: shall be authenticated with respect to two sources (sender and group) (simultaneously?) Section 3; Suggestion: Each endpoint stores extensions of the Oscore context. I seem to read that the Contexts used for group communication are extensions to the one specified for OSCORE. If that is true, use different names or use extension of . Common context -> group context? In OSCORE the common context is defined as common between send and receiver, not common to the group. Point 1, bullet 2: “ … once the security context is established”: do you mean the common context? Point 2, The phrase “In practice, … OSCORE messages” is difficult to understand (at least I see multiple explanations) Do you mean that SenderID is equal to its endpointID received at joining? It would be nice to give tables with additions to OSCORE security context for Sender Context, Recipient Context and Common (group) context; Now one has to search for them in the text. Point 3 Is Recipient Id also equal to endpointID. The text about Recipient context creation is unclear. Is the creation done by the Recipient endpoint? How are the contexts shared? Who does the sharing? Or do you mean that they are copied over at reception? Sender pubic key is extracted from Sender context (stored in GM, or sent over with message?) or from a trusted key repository? This paragraph is not very clear to me. Parts of the text are good candidates for a GM requirements section. See my comments about appendix C. Section 3.1 Remove: “such a risk… office buildings. Nevertheless”. The fun with drones provided by Dutch universities, proves these assumptions to be futile. Distribution of master key is another GM requirement. Section 4 bullit 1: The phrase “set to the SenderId of the endpoint” creates the impression that an endpoint has multiple IDs. Probably, you mean: the SenderId of the Context is set to the ID of the endpoint (or similar much better text) Bullit 2 star 1: Is the group’s Security Context equal to the Common context? Figure 1 differs from figure 7 in OSCORE draft Section 5; Suggestion: In case of malformed messages a “listening only” receiver endpoint silently rejects the message and sends no error message; all other receivers return an error message x.xx. Section 5.1 The document uses two terms: multicaster endpoint and sender endpoint; I assume they are equal concepts; If yes, choose one, if no, explain difference. Point 1; stores where? Find where? Section 5.2 point 2; It is not clear how a new Recipient context is created; That is probably due to the vague duties of the GM. Section 6; I think that synchronizing sequence numbers is part of the standard and should be specified as requirement on the GM. Section 7.1 Remove “for instance .. those roles” Refer to appendix A. Section 7; Don’t you need some discussion on size of group to discuss security breach probabilities? Appendix A lighting control; here you refer to multicast group, which is sometimes correct. In the introduction you talk about group communication. Switches but also sensors can control the state of the lights. Why is the backbone multicast enabled? Is that a MUST? Events within a 200 ms interval are perceived as simultaneous by humans. Necessary in many configurations. In Building control, intervals of seconds are sufficient. Commissioning of LLN system; Interesting idea that multicast should be enabled on a subnetwork for discovery. However, that would be after enrollment of the devices? I think the use case needs a bit more thought. Emergency multicast; Also interesting, but that needs a fault tolerant multicast algorithm, like MPL. for example. Appendix C. I like this appendix, it provides the necessary understanding how things will work in practice. Please keep this appendix but also create a section with GM requirements, with the purpose of the requirements explained in the appendix. (this is a suggestion, don’t know if it will work actually) C.1 bullit management keying material: depend -> depends C.3 I think the utilization of ACE framework SHOULD be part of the standard. Too many options reduce the interoperability. Especially standards about the GM seem rather crucial to me. Appendix D. Are the proposed options interoperable within a group? Also here I would advocate interoperable solutions only. -- Peter van der Stok vanderstok consultancy mailto: consultancy@vanderstok.org www: www.vanderstok.org tel NL: +31(0)492474673 F: +33(0)966015248 From nobody Tue Feb 6 09:33:30 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D398512708C for ; Tue, 6 Feb 2018 09:33:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 (1024-bit key) header.d=ericsson.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 GCxj5kt0oglY for ; Tue, 6 Feb 2018 09:33:22 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1AD412D84F for ; Tue, 6 Feb 2018 09:33:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1517938400; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=L+aGQv7nbMqll5dz31YC0eTw9PBG3OA4vmyMW+43DMQ=; b=b+cIs0AHlCCZ0gzso0Hyb1zWkJsBoJ8oQS+Qp5nJkc3gPK0GzQ/qfFfZJ3KxYk1G UEEPyGYrkV3co8hQmtqhHP4T54WAnhV1/gx3FlF5EpAbwJEqaJK8rkJnE3LS9LgI 4dhIrjab1Spo5UUleav+mTX3by9I9FDIBEcVtWvLzmM=; X-AuditID: c1b4fb25-473ff7000000341b-df-5a79e6dfd335 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 2C.41.13339.FD6E97A5; Tue, 6 Feb 2018 18:33:20 +0100 (CET) Received: from ESESSMB107.ericsson.se ([169.254.7.108]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0352.000; Tue, 6 Feb 2018 18:33:19 +0100 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= To: "core@ietf.org WG (core@ietf.org)" Thread-Topic: =?utf-8?B?W2NvcmVdICAg8J+UlCBXRyBDYWxsIGZvciBBZG9wdGlvbiBvbiBkcmFmdC10?= =?utf-8?Q?iloca-core-multicast-oscoap?= Thread-Index: AQHTbQbfFw3YhwXmnUCgGt38EK5jy6OX9lUA Date: Tue, 6 Feb 2018 17:33:19 +0000 Message-ID: References: <1893AB2B-E540-4D34-8393-DF90F86A4142@gmail.com> In-Reply-To: <1893AB2B-E540-4D34-8393-DF90F86A4142@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/signed; boundary="Apple-Mail=_49E8A2D5-E28B-4170-B4E5-F83DA56FBC11"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNIsWRmVeSWpSXmKPExsUyM2K7ru6DZ5VRBrNb2Sz2vV3P7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujEVnWlkKDoRVPJv1hrWBsTGgi5GTQ0LAROJs11N2EFtI4DCj xJL3+V2MXED2YkaJvnvfmEASbALOEp+eNYIViQiYSWzZ9ZUVxBYWqJfY/P8dG0iDiEADo8Tv M4+ZIIqMJPrOPAFrYBFQkbjy4jFQAwcHr4C9xLMLiSCmkECRxLerEiAVnAK2EvsvHWEDsRkF xCS+n1oDNoVZQFzi1pP5TBB3ikg8vHiaDcIWlXj5+B8rhK0k0bjkCSvICcwCUxgldh/qZQRJ 8AoISpyc+YRlAqPwLCSzZiGrm4WkDqIoSWL9ro9MELa2xLKFr5khbE2J/d3LWTDFNSQ6v01k hbBNJV4f/cgIYVtLzPh1kA3CVpSY0v2QfQEj9ypG0eLU4qTcdCNjvdSizOTi4vw8vbzUkk2M wGg8uOW36g7Gy28cDzEKcDAq8fDuv1sZJcSaWFZcmXuIUQVozqMNqy8wSrHk5eelKonwBm0C SvOmJFZWpRblxxeV5qQWH2KU5mBREuc96ckbJSSQnliSmp2aWpBaBJNl4uCUamC0OtqdUnPs 2oLw+pYpPG/8k2PvimovVvjgu+PZ3XSp9XYvc1OTYtXUG/J2z7Sun/5MRSCB4fqK9lvLGANV IsOdu2I3JH3+cb76cZ/qObHaCRfPXgx5MFVkM6vmgbul/2Zk/tedzeH64JW5TIg/29YTSwOK zp10VrNq2DTnepf5puT1Rz6c2bJdiaU4I9FQi7moOBEAJmrhus4CAAA= Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Call_for_Adoption_on_draft-tilo?= =?utf-8?q?ca-core-multicast-oscoap?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 17:33:26 -0000 --Apple-Mail=_49E8A2D5-E28B-4170-B4E5-F83DA56FBC11 Content-Type: multipart/alternative; boundary="Apple-Mail=_F410B110-CC05-4FE6-A1DF-95DB6C66A887" --Apple-Mail=_F410B110-CC05-4FE6-A1DF-95DB6C66A887 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear CoRE-WG, =46rom both the email discussions and the in room consensus at last = IETF, it seems that this draft is ready for adoption.=20 As with the other documents, this draft is not being tracked at the = moment on https://github.com/core-wg/ but = if the authors consider it appropriate they can add it there. Thanks, - - Jaime Jim=C3=A9nez >=20 >> On Nov 23, 2017, at 8:59 AM, Jaime Jim=C3=A9nez = > wrote: >>=20 >> Dear all, >>=20 >> The draft on "Secure group communication for CoAP" ( = draft-tiloca-core-multicast-oscoap = ) had = in room consensus for adoption during IETF99 already, now we are clear = to confirm it on the mailing list.=20 >>=20 >> Please reply to the list with your comments, including although not = limited to whether or not you support adoption. Non-authors are = especially encouraged to comment. >>=20 >> Target to end the WGA is 14th of December. >>=20 >> Ciao, >> - - Jaime Jim=C3=A9nez >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 --Apple-Mail=_F410B110-CC05-4FE6-A1DF-95DB6C66A887 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear = CoRE-WG,

=46rom both the email discussions = and the in room consensus at last IETF, it seems that this draft is = ready for adoption. 

As with the other documents, this draft is = not being tracked at the moment on https://github.com/core-wg/  but if the authors = consider it appropriate they can add it there.

Thanks,
- - Jaime = Jim=C3=A9nez


On Nov = 23, 2017, at 8:59 AM, Jaime Jim=C3=A9nez <jaime.jimenez@ericsson.com> wrote:

Dear all,

The draft on "Secure group communication for CoAP" = ( draft-tiloca-core-multicast-oscoap ) had in room = consensus for adoption during IETF99 already, now we are clear to confirm it on the mailing list. 

Please reply to the list with your comments, including = although not limited to whether or not you support adoption. = Non-authors are especially encouraged to comment.

Target to end the WGA is 14th of December.

Ciao,
- - Jaime Jim=C3=A9nez

_______________________________________________
core = mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core


= --Apple-Mail=_F410B110-CC05-4FE6-A1DF-95DB6C66A887-- --Apple-Mail=_49E8A2D5-E28B-4170-B4E5-F83DA56FBC11 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMxjCCBfww ggPkoAMCAQICEAIbLM20K0Yu/5jc3dejkfUwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCU0Ux ETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYz MB4XDTE4MDExNjEyMjkzMVoXDTIxMDExNjEyMjkzMFowaTERMA8GA1UECgwIRXJpY3Nzb24xFzAV BgNVBAMMDkphaW1lIEppbcOpbmV6MSkwJwYJKoZIhvcNAQkBFhpqYWltZS5qaW1lbmV6QGVyaWNz c29uLmNvbTEQMA4GA1UEBRMHZWphamltbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AI+DThV/KcZen+MJmBGqpcdYmsas7GdU5GbP2v6kJi3InKvo92Ypf2Ca2GV6WpHrwMwwvWdl+6mP BPsjmjGsJ4UXg2Uu4QRKK6Jqq6azB3+1mBHXOuPu5MwSqRXRsU72fxqEjAT8JZM5xKzqeZ+e7onX vUY2IQnDDo3Y6+hOvPe64N+qwgbQVXLL639YPQjxiKElpZccSmCvShq1N9Ct/i/ecm81uJV4czZN 3Cdt6UYZwelaV+dHeZi07sLPP6MAvFoGOa2sgsyA99V77XwAVu8jY2Z8PEnwrMqAHfhqNEsXnOXs IH3HH/khzjkNVxv/ohlj6jwR1EoJ6kYRlLDEUPsCAwEAAaOCAcAwggG8MEgGA1UdHwRBMD8wPaA7 oDmGN2h0dHA6Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5j cmwwgYIGCCsGAQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlh LmNvbTBIBggrBgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY2VyMCUGA1UdEQQeMByBGmphaW1lLmppbWVuZXpAZXJpY3Nzb24u Y29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjAdBgNVHQ4EFgQUd399BTtL2oFkOMio32TINfqzZe4wHwYDVR0jBBgwFoAUHHsZnpec dqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBCwUAA4ICAQBU8yzcwgcR S4MZI/xYSuEHqlzNiZMmlK4JbR1kDjd/eY+mYqgM9NPaLqgzt+pdUfbEh7bl+y19UDMXmsbzWS+1 e0Rh76h/TYuo0YLuvW7V+rQKa335v0L/WHNO5F/x4rIHaxUeGboOtuMLuE8jOxe6iUbpuPRWHO9Y glcqSBkHLTs7sDu//kGAzgMb0a8bs07UdG33BP950NfrTzEnHnS4scqnERGIQDElzHpBEe32SuIF 0Xbvl6NSzIvvqu5egdhn/zyQ89n28aWKgxfgsm1Q7ln452mncP55ZYJeb4cFDmIa2yUjbHf9CxeK xtlao5ZGkHLx4iKEwFkVE3KTR9ckCD8C1Cy2kNMRuzC6b6tixbTM8ff0tIDkG8nvb4h/Qi5rfUAW fkPZndQo0Ot9NWiY9aGUr/6DejVE+x1RFhWdeGaWyMpk/8/N7z3uSJIBZY+01mzs3PAGJBFQL6uS naoouYsvlAJ0oBCPn3eAUu4J5IuZfKxPpfpK2Tn+Su0ctU6N6TFAHaFqFyVw7WXky5XwGcIHV8Y4 JKWsknwImPJbolfOnydAPDLD3/ktTd39wdOljSeq0WZeAoZi4GW4ILre4XIy+LrGhgm0xPe7Igtf P3DXIbNVGfvPE/58zm/+bg1Q91Nf2VEYDgGbR1cPDDs9l771qWKsGFvRpq1j87nAADCCBsIwggSq oAMCAQICEFO4foPhnJkok7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFT b25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcN MjUxMDI3MTIxNjQ2WjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQDs8t8AALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs0zfSTm+7meis bhkqUXkL7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9ZVbXILlLhRummTdD dxhVW4Leo0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvSxlfpVdiCulPTlmsmV2RS BSAwqBshZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eNo4v2PUmE0rhu+Zs0nujnwhlj PA2/8b8v9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWqg5t2H/E0XY1LwJez89W07nscEocy BmpC+zJAmKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4TlG4rAUikc5U5TmUIGBRQGxulYhfAzqS Yf8oLUMLky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1MOkX1vS+fLgOvBo5LRU1fLPUZQ7FKrDXC6nl 2ldvEtljHWstGBmqv25aEvAA+yrrplCh/kYvSBjvZibz9Obbwx4yqS77/NHN1iyZyVP2s52B2BLd vo4yhzk6nRk8S/8zHaUUkBUrrvijPDaGK5FNVSaioGvkC7IKioITKffYLtT9XuirKrHlh3VzkazG 46pAVwIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29j c3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50 cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgw BgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpo dHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3Js MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYE FBx7GZ6XnHasID3Y3OORauPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G CSqGSIb3DQEBCwUAA4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gVLtDUJQEP Rs5QtaZiObNHCZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyoEBHGvw5RY6vR lZrj0uKvdASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50ZkBqYnnl2t3D3oBX2N ZCQysshUcqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEOrPwfixWms+C8sF0r9qN1 uJGx6ELPOiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1UrRIQ85AKjqzBnLSsjRGgbMgJ+ xKtngmvEA155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKXe4HdDc1P+UMYm16m2L6LkIIoRlx0 A5mi+K7jewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNOxdOEEHf4kkdWOaSIuj3TQYhNv+LsgF0u ijiBmaz2zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaHKWhd3dZua/tlSiqokUFX2DxmHmZ1n5HM9Oia AIXP/Zo2x10j/Yb1mM3i0bqGahxlHYzl/QyEG/dujp3lewuVjCI0mPDkZGphvxyqp4Jo8qS94EnO qBvxOgftYug7OY9EKY+WkDGCAr0wggK5AgEBMFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhACGyzNtCtGLv+Y 3N3Xo5H1MAkGBSsOAwIaBQCgggE3MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE4MDIwNjE3MzMxOVowIwYJKoZIhvcNAQkEMRYEFObS6T2Zd5USO2X/8bdFDhuVAZiO MGoGCSsGAQQBgjcQBDFdMFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYD VQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhACGyzNtCtGLv+Y3N3Xo5H1MGwGCyqG SIb3DQEJEAILMV2gWzBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEAIbLM20K0Yu/5jc3dejkfUwDQYJKoZIhvcN AQEBBQAEggEAPC1cO081+FtRB+RFfcHbzy+IpCNDvJ6GFNA6KYrinVhvO4SBE4j9cGvVDpUv3B/b BYX+VA+jwHCdnmsSt0gI4K0RA6McAM2abxdGjhIgqFWL8gcZDxYRMiWibCqF6jnVHijGKthEV/pF fumjOCw8L53LSDyJgXp0HN+sdublVDkTVq0DENKXHqGvc+eRWa7KiIjEvsQ/+b/pgcMCbW1KFwcl bSgc+u1Czs6SUg10DX1qOJUXSGuv9ikjj3RkZYgpCPt8HRiOmR9k7z0YHYoJLoHKgEJxYWqcL7Vv svyK9OIsaEQQ+dpTqmwO6V/c0/QnfSRO44qGKKmGC3poJNRUWQAAAAAAAA== --Apple-Mail=_49E8A2D5-E28B-4170-B4E5-F83DA56FBC11-- From nobody Wed Feb 7 20:36:12 2018 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 270E7127599; Wed, 7 Feb 2018 20:36:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151806457010.17056.1096834933081382322@ietfa.amsl.com> Date: Wed, 07 Feb 2018 20:36:10 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-yang-cbor-06.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 04:36:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : CBOR Encoding of Data Modeled with YANG Authors : Michel Veillette Alexander Pelov Abhinav Somaraju Randy Turner Ana Minaburo Filename : draft-ietf-core-yang-cbor-06.txt Pages : 35 Date : 2018-02-07 Abstract: This document defines encoding rules for serializing configuration data, state data, RPC input and RPC output, Action input, Action output and notifications defined within YANG modules using the Concise Binary Object Representation (CBOR) [RFC7049]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-yang-cbor-06 https://datatracker.ietf.org/doc/html/draft-ietf-core-yang-cbor-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-yang-cbor-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 9 05:58:47 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE838124235 for ; Fri, 9 Feb 2018 05:58:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net 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 kA53j5r1PL5K for ; Fri, 9 Feb 2018 05:58:43 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9715F126579 for ; Fri, 9 Feb 2018 05:58:42 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=K/qAC3LMqli2elzbD79qKR5XZwUxCkJiHUwpkNIrtH+G/TODui3lk8EX4DtqvjlXLfMIuxB92kBw9ct4rgiJPPyman4JYp+P67b+msf5bMJAKnUJuqgpAflHSKsSwtD9P3Kd7hliDyWuQLDz1kAvcLVt3BwHvRueKbc/QuUVEa0=; h=Received:Received:From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Message-Id:Date:Cc:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 29228 invoked from network); 9 Feb 2018 14:58:39 +0100 Received: from mue-88-130-61-231.dsl.tropolys.de (HELO ?192.168.178.33?) (88.130.61.231) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 9 Feb 2018 14:58:39 +0100 From: "Mirja Kuehlewind (IETF)" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Message-Id: Date: Fri, 9 Feb 2018 14:58:37 +0100 Cc: core@ietf.org To: draft-ietf-core-cocoa.all@ietf.org X-Mailer: Apple Mail (2.3445.5.20) X-PPP-Message-ID: <20180209135839.29223.78956@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: [core] AD review of draft-ietf-core-cocoa-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 13:58:45 -0000 Hi authors! I reviewed the document and think it is ready for IETF last call. Find = below a couple of mostly editorial notes that came to my mind while = reviewing the document. Please let me know if you=E2=80=99ll like to = address (if at all) any of these comments with an update before I start = IETF last call, or if I should start the last call immediately with this = version! @Jaime: could you please update the shepherd-write to reflect that I=E2=80= =99m the responsible area director and maybe provide one additional = sentence to explain why informational is the right indented status! Thanks! Mirja -------------------------- Mostly editorial comments: 1) First sentence in sec 1, maybe:=20 s/The CoAP protocol/The Constrained Application Protocol (CoAP) = [RFC7252]/ 2) The following note is not necessary: "(Note that the present document is itself informational, but it is discussing normative statements about behavior that makes the congestion control scheme work in a safe manner.)=E2=80=9C 3) The formatting with (1) and (2) is a bit confusing in the equations = in section 4.2.; maybe you can add some more space there. Further I = really find it confusing that you directly use RTO instead of RTT here = and then just later explain that you use an K of 1. I would rather = explain that first an maybe even use RTT_weak and RTT_strong instead of = E_ 4) I find the heading of section 4.2.1 a bit confusing and the whole = section a bit hard to read as you didn=E2=80=99t really introduce the = =E2=80=9Enew=E2=80=9C backoff calculation yet. Maybe you can actually = move some of the discussion (about initial values and K) in the previous = subsection and call this ubsection something like =E2=80=9EBackoff = calculation=E2=80=9C and then maybe add one sentence that explains what = RFC6298 does, e.g. =E2=80=9EIn [RFC6298] the RTO is increased = exponentially with a factor of 2 if the RTO timer expires.=E2=80=9C 4) sec 4.3 "It MUST be kept for at least 255 s.=E2=80=9C Why is that a MUST and why 255s? 5) I would consider to have section 5 before section 4, to give the = reader a better idea that the calculated RTO is used to define the = sending rate (which is the actually congestion control part of the = spec). I think it would also be good to give a high-level (1-2 = sentences) overview of the congestion control principle in the intro, = e.g. CoCoA calculates the retransmission time-out (RTO) based on the = estimated RTT with and without loss and limits the sending rate (for = non-confinable packets) to 1/RTO. By taking retransmissions (in a = potentially lossy network) into account when estimating the RTT, this = algorithm reacts to congestion will a lower sending rate.=E2=80=9C Also this sentence in section 5.1 could be helpful information in the = intro already: "Assuming that the RTO estimation in CoCoA works as expected, RTO[k] should be slightly greater than the RTT[k], thus CoCoA would be more conservative.=E2=80=9C= 6) Maybe consider to integrate Appendix B into the body of the document. = I think that would actually help the reader. From nobody Mon Feb 12 05:33:28 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF4EB127978 for ; Mon, 12 Feb 2018 05:33:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 (1024-bit key) header.d=ericsson.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 m6ldYStYJjId for ; Mon, 12 Feb 2018 05:33:25 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B823C126C19 for ; Mon, 12 Feb 2018 05:33:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1518442402; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=+N7iEeRXVcKIvvb6bHYeBQ49jJFWld6B1AcD2zjBjuA=; b=LP2p50NzIApWymu+3jZ+ORYdFJWMNZTzI/L8eYb0wt5xWkHRB7uhAkzoMfImET0K zkhz9hfytNn6yqq45dZMM/AjU6TWFmqj+wQo8Vn0m1/pX/mICIFMlQUFAXw1e2w6 rx6b/sKMSF8XPzV+pDt/kMXsGv6S4BYS6WGiWVlN2co=; X-AuditID: c1b4fb25-473ff7000000341b-ec-5a8197a27545 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 0E.45.13339.2A7918A5; Mon, 12 Feb 2018 14:33:22 +0100 (CET) Received: from ESESSMB107.ericsson.se ([169.254.7.108]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0352.000; Mon, 12 Feb 2018 14:33:22 +0100 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= To: "Mirja Kuehlewind (IETF)" CC: "draft-ietf-core-cocoa.all@ietf.org" , "core@ietf.org" Thread-Topic: AD review of draft-ietf-core-cocoa-02 Thread-Index: AQHToa4aLDrSx6eaQECmLTHGBPgD4KOgt/mA Date: Mon, 12 Feb 2018 13:33:22 +0000 Message-ID: <4B20067C-5F2E-4F30-8AEB-27B2B07D107C@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/signed; boundary="Apple-Mail=_B6C35E6C-23DB-4F7F-BF3E-C115DF8D823C"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKIsWRmVeSWpSXmKPExsUyM2J7iO6i6Y1RBof+G1nse7ue2WLmq7es Fi+uf2R2YPZYsuQnk0fLx4WsAUxRXDYpqTmZZalF+nYJXBnn99xkLvhUXnFz5yL2BsZtWV2M nBwSAiYSZ7efZOpi5OIQEjjMKLHx/QkoZwmjRPePW0wgVWwCzhKfnjWyg9giAsYShyd/ZwWx mQUKJBZcesEGYgsLGEm86LrFBlOz5WgTK4RtJNHe18vYxcjBwSKgKvH5ozFImFfAXqK59Qgj iC0k4CixadpssHJOASeJU0uugdmMAmIS30+tYYJYJS5x68l8JoijRSQeXjzNBmGLSrx8/I8V wlaSWLH9EiNE/RRGidVroiB2CUqcnPmEZQKjyCwko2YhKZuFpAwiniSxZE8/M4StLbFs4Wso W1Nif/dyFkxxDYnObxNZIWxTiddHPzJC2NYSM34dZIOwFSWmdD9kX8DIvYpRtDi1OCk33chY L7UoM7m4OD9PLy+1ZBMjMIIPbvmtuoPx8hvHQ4wCHIxKPLzb2xujhFgTy4orcw8xqgDNebRh 9QVGKZa8/LxUJRHeP81Aad6UxMqq1KL8+KLSnNTiQ4zSHCxK4rwnPXmjhATSE0tSs1NTC1KL YLJMHJxSDYw8HtlmdquDW56flHwnKsybHm4R/fM2n8nZNx9uCsyeb+W2u7HeaNJEv7qtXrNX 7VAXfl1x3bCDYdnW49dD6+puMTw77xY4u+RUU1b5U8ZpjYuu8MvP3hjmrnb4xhLhtWHTFs0w yc0OsHz65q/3HdEbiWpm8RfnLjHbGDZ/bXHgrqf2F2bqrMxUYinOSDTUYi4qTgQAFnWmHugC AAA= Archived-At: Subject: Re: [core] AD review of draft-ietf-core-cocoa-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2018 13:33:27 -0000 --Apple-Mail=_B6C35E6C-23DB-4F7F-BF3E-C115DF8D823C Content-Type: multipart/alternative; boundary="Apple-Mail=_76F1DB5E-C9B2-4B6B-95E0-DB16F043E75D" --Apple-Mail=_76F1DB5E-C9B2-4B6B-95E0-DB16F043E75D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > @Jaime: could you please update the shepherd-write to reflect that = I=E2=80=99m the responsible area director and maybe provide one = additional sentence to explain why informational is the right indented = status! Done! - - Jaime Jim=C3=A9nez > On 9 Feb 2018, at 15.58, Mirja Kuehlewind (IETF) = wrote: >=20 > Hi authors! >=20 > I reviewed the document and think it is ready for IETF last call. Find = below a couple of mostly editorial notes that came to my mind while = reviewing the document. Please let me know if you=E2=80=99ll like to = address (if at all) any of these comments with an update before I start = IETF last call, or if I should start the last call immediately with this = version! >=20 > @Jaime: could you please update the shepherd-write to reflect that = I=E2=80=99m the responsible area director and maybe provide one = additional sentence to explain why informational is the right indented = status! >=20 > Thanks! > Mirja >=20 > -------------------------- >=20 > Mostly editorial comments: >=20 > 1) First sentence in sec 1, maybe:=20 > s/The CoAP protocol/The Constrained Application Protocol (CoAP) = [RFC7252]/ >=20 > 2) The following note is not necessary: > "(Note that the present document is itself informational, but it is > discussing normative statements about behavior that makes the > congestion control scheme work in a safe manner.)=E2=80=9C >=20 > 3) The formatting with (1) and (2) is a bit confusing in the equations = in section 4.2.; maybe you can add some more space there. Further I = really find it confusing that you directly use RTO instead of RTT here = and then just later explain that you use an K of 1. I would rather = explain that first an maybe even use RTT_weak and RTT_strong instead of = E_ >=20 > 4) I find the heading of section 4.2.1 a bit confusing and the whole = section a bit hard to read as you didn=E2=80=99t really introduce the = =E2=80=9Enew=E2=80=9C backoff calculation yet. Maybe you can actually = move some of the discussion (about initial values and K) in the previous = subsection and call this ubsection something like =E2=80=9EBackoff = calculation=E2=80=9C and then maybe add one sentence that explains what = RFC6298 does, e.g. =E2=80=9EIn [RFC6298] the RTO is increased = exponentially with a factor of 2 if the RTO timer expires.=E2=80=9C >=20 > 4) sec 4.3 "It MUST be kept for at least 255 s.=E2=80=9C > Why is that a MUST and why 255s? >=20 > 5) I would consider to have section 5 before section 4, to give the = reader a better idea that the calculated RTO is used to define the = sending rate (which is the actually congestion control part of the = spec). I think it would also be good to give a high-level (1-2 = sentences) overview of the congestion control principle in the intro, = e.g. CoCoA calculates the retransmission time-out (RTO) based on the = estimated RTT with and without loss and limits the sending rate (for = non-confinable packets) to 1/RTO. By taking retransmissions (in a = potentially lossy network) into account when estimating the RTT, this = algorithm reacts to congestion will a lower sending rate.=E2=80=9C >=20 > Also this sentence in section 5.1 could be helpful information in the = intro already: "Assuming that the RTO > estimation in CoCoA works as expected, RTO[k] should be slightly > greater than the RTT[k], thus CoCoA would be more conservative.=E2=80=9C= >=20 > 6) Maybe consider to integrate Appendix B into the body of the = document. I think that would actually help the reader. >=20 >=20 --Apple-Mail=_76F1DB5E-C9B2-4B6B-95E0-DB16F043E75D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
@Jaime: could you please = update the shepherd-write to reflect that I=E2=80=99m the responsible = area director and maybe provide one additional sentence to explain why = informational is the right indented status!

Done!

- - Jaime Jim=C3=A9nez

On 9 Feb 2018, at 15.58, Mirja Kuehlewind (IETF) <ietf@kuehlewind.net>= wrote:

Hi authors!

I reviewed the = document and think it is ready for IETF last call. Find below a couple = of mostly editorial notes that came to my mind while reviewing the = document. Please let me know if you=E2=80=99ll like to address (if at = all) any of these comments with an update before I start IETF last call, = or if I should start the last call immediately with this version!

@Jaime: could you please update the = shepherd-write to reflect that I=E2=80=99m the responsible area director = and maybe provide one additional sentence to explain why informational = is the right indented status!

Thanks!
Mirja

--------------------------

Mostly = editorial comments:

1) First sentence in = sec 1, maybe:
s/The CoAP protocol/The Constrained = Application Protocol (CoAP) [RFC7252]/

2) = The following note is not necessary:
"(Note that the = present document is itself informational, but it is
=   discussing normative statements about behavior that makes = the
  congestion control scheme work in a safe = manner.)=E2=80=9C

3) The formatting with = (1) and (2) is a bit confusing in the equations in section 4.2.; maybe = you can add some more space there. Further I really find it confusing = that you directly use RTO instead of RTT here and then just later = explain that you use an K of 1. I would rather explain that first an = maybe even use RTT_weak and RTT_strong instead of E_

4) I find the heading of section 4.2.1 a bit confusing and = the whole section a bit hard to read as you didn=E2=80=99t really = introduce the =E2=80=9Enew=E2=80=9C backoff calculation yet. Maybe you = can actually move some of the discussion (about initial values and K) in = the previous subsection and call this ubsection something like = =E2=80=9EBackoff calculation=E2=80=9C and then maybe add one sentence = that explains what RFC6298 does, e.g. =E2=80=9EIn [RFC6298] the RTO is = increased exponentially with a factor of 2 if the RTO timer = expires.=E2=80=9C

4) sec 4.3 "It MUST be = kept for at least 255 s.=E2=80=9C
Why is that a MUST and = why 255s?

5) I would consider to have = section 5 before section 4, to give the reader a better idea that the = calculated RTO is used to define the sending rate (which is the actually = congestion control part of the spec). I think it would also be good to = give a high-level (1-2 sentences) overview of the congestion control = principle in the intro, e.g. CoCoA calculates the retransmission = time-out (RTO) based on the estimated RTT with and without loss and = limits the sending rate (for non-confinable packets) to 1/RTO. By taking = retransmissions (in a potentially lossy network) into account when = estimating the RTT, this algorithm reacts to congestion will a lower = sending rate.=E2=80=9C

Also this sentence = in section 5.1 could be helpful information in the intro already: = "Assuming that the RTO
  estimation in CoCoA = works as expected, RTO[k] should be slightly
=   greater than the RTT[k], thus CoCoA would be more = conservative.=E2=80=9C

6) Maybe consider to = integrate Appendix B into the body of the document. I think that would = actually help the reader.



= --Apple-Mail=_76F1DB5E-C9B2-4B6B-95E0-DB16F043E75D-- --Apple-Mail=_B6C35E6C-23DB-4F7F-BF3E-C115DF8D823C Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMxjCCBfww ggPkoAMCAQICEAIbLM20K0Yu/5jc3dejkfUwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCU0Ux ETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYz MB4XDTE4MDExNjEyMjkzMVoXDTIxMDExNjEyMjkzMFowaTERMA8GA1UECgwIRXJpY3Nzb24xFzAV BgNVBAMMDkphaW1lIEppbcOpbmV6MSkwJwYJKoZIhvcNAQkBFhpqYWltZS5qaW1lbmV6QGVyaWNz c29uLmNvbTEQMA4GA1UEBRMHZWphamltbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AI+DThV/KcZen+MJmBGqpcdYmsas7GdU5GbP2v6kJi3InKvo92Ypf2Ca2GV6WpHrwMwwvWdl+6mP BPsjmjGsJ4UXg2Uu4QRKK6Jqq6azB3+1mBHXOuPu5MwSqRXRsU72fxqEjAT8JZM5xKzqeZ+e7onX vUY2IQnDDo3Y6+hOvPe64N+qwgbQVXLL639YPQjxiKElpZccSmCvShq1N9Ct/i/ecm81uJV4czZN 3Cdt6UYZwelaV+dHeZi07sLPP6MAvFoGOa2sgsyA99V77XwAVu8jY2Z8PEnwrMqAHfhqNEsXnOXs IH3HH/khzjkNVxv/ohlj6jwR1EoJ6kYRlLDEUPsCAwEAAaOCAcAwggG8MEgGA1UdHwRBMD8wPaA7 oDmGN2h0dHA6Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5j cmwwgYIGCCsGAQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlh LmNvbTBIBggrBgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY2VyMCUGA1UdEQQeMByBGmphaW1lLmppbWVuZXpAZXJpY3Nzb24u Y29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjAdBgNVHQ4EFgQUd399BTtL2oFkOMio32TINfqzZe4wHwYDVR0jBBgwFoAUHHsZnpec dqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBCwUAA4ICAQBU8yzcwgcR S4MZI/xYSuEHqlzNiZMmlK4JbR1kDjd/eY+mYqgM9NPaLqgzt+pdUfbEh7bl+y19UDMXmsbzWS+1 e0Rh76h/TYuo0YLuvW7V+rQKa335v0L/WHNO5F/x4rIHaxUeGboOtuMLuE8jOxe6iUbpuPRWHO9Y glcqSBkHLTs7sDu//kGAzgMb0a8bs07UdG33BP950NfrTzEnHnS4scqnERGIQDElzHpBEe32SuIF 0Xbvl6NSzIvvqu5egdhn/zyQ89n28aWKgxfgsm1Q7ln452mncP55ZYJeb4cFDmIa2yUjbHf9CxeK xtlao5ZGkHLx4iKEwFkVE3KTR9ckCD8C1Cy2kNMRuzC6b6tixbTM8ff0tIDkG8nvb4h/Qi5rfUAW fkPZndQo0Ot9NWiY9aGUr/6DejVE+x1RFhWdeGaWyMpk/8/N7z3uSJIBZY+01mzs3PAGJBFQL6uS naoouYsvlAJ0oBCPn3eAUu4J5IuZfKxPpfpK2Tn+Su0ctU6N6TFAHaFqFyVw7WXky5XwGcIHV8Y4 JKWsknwImPJbolfOnydAPDLD3/ktTd39wdOljSeq0WZeAoZi4GW4ILre4XIy+LrGhgm0xPe7Igtf P3DXIbNVGfvPE/58zm/+bg1Q91Nf2VEYDgGbR1cPDDs9l771qWKsGFvRpq1j87nAADCCBsIwggSq oAMCAQICEFO4foPhnJkok7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFT b25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcN MjUxMDI3MTIxNjQ2WjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQDs8t8AALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs0zfSTm+7meis bhkqUXkL7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9ZVbXILlLhRummTdD dxhVW4Leo0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvSxlfpVdiCulPTlmsmV2RS BSAwqBshZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eNo4v2PUmE0rhu+Zs0nujnwhlj PA2/8b8v9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWqg5t2H/E0XY1LwJez89W07nscEocy BmpC+zJAmKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4TlG4rAUikc5U5TmUIGBRQGxulYhfAzqS Yf8oLUMLky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1MOkX1vS+fLgOvBo5LRU1fLPUZQ7FKrDXC6nl 2ldvEtljHWstGBmqv25aEvAA+yrrplCh/kYvSBjvZibz9Obbwx4yqS77/NHN1iyZyVP2s52B2BLd vo4yhzk6nRk8S/8zHaUUkBUrrvijPDaGK5FNVSaioGvkC7IKioITKffYLtT9XuirKrHlh3VzkazG 46pAVwIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29j c3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50 cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgw BgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpo dHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3Js MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYE FBx7GZ6XnHasID3Y3OORauPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G CSqGSIb3DQEBCwUAA4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gVLtDUJQEP Rs5QtaZiObNHCZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyoEBHGvw5RY6vR lZrj0uKvdASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50ZkBqYnnl2t3D3oBX2N ZCQysshUcqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEOrPwfixWms+C8sF0r9qN1 uJGx6ELPOiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1UrRIQ85AKjqzBnLSsjRGgbMgJ+ xKtngmvEA155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKXe4HdDc1P+UMYm16m2L6LkIIoRlx0 A5mi+K7jewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNOxdOEEHf4kkdWOaSIuj3TQYhNv+LsgF0u ijiBmaz2zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaHKWhd3dZua/tlSiqokUFX2DxmHmZ1n5HM9Oia AIXP/Zo2x10j/Yb1mM3i0bqGahxlHYzl/QyEG/dujp3lewuVjCI0mPDkZGphvxyqp4Jo8qS94EnO qBvxOgftYug7OY9EKY+WkDGCAr0wggK5AgEBMFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhACGyzNtCtGLv+Y 3N3Xo5H1MAkGBSsOAwIaBQCgggE3MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE4MDIxMjEzMzMyMVowIwYJKoZIhvcNAQkEMRYEFIv7XRwTSBdKz82kQyTUCtF5OYwk MGoGCSsGAQQBgjcQBDFdMFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYD VQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhACGyzNtCtGLv+Y3N3Xo5H1MGwGCyqG SIb3DQEJEAILMV2gWzBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEAIbLM20K0Yu/5jc3dejkfUwDQYJKoZIhvcN AQEBBQAEggEAACVTl8ZUxaVs+8nFO5XNxrJraeZNkEm+Jf32afB0hkaocLyBGLrmsQwtnf//7R5t t2TNJc8pf/KC/SuRu/SY/yG5WQeTaF1pn2vx/15+o8iTfM78CrP9qGUpMyINol/knn62iyzC1BkE noN84bFU82/XfzmVS0Hwe6LxAvbGqrP6/BBRcmK8VIYA0+pMuTzq+ANB+qyM5i0EpQY5L4XAo6C1 Q+B5y1d9sNEUOrpTYz8zojoiaDb9FMeN1QV9XBm0K9t8jK5JPoTRFXcfjkYaCCuSj2jWiD3CSlWI aGUGJCNyi25K0tSnF+xUbdM5ZtNUJ5xa7jv9lWdgqcbkde2ETAAAAAAAAA== --Apple-Mail=_B6C35E6C-23DB-4F7F-BF3E-C115DF8D823C-- From nobody Mon Feb 12 13:12:10 2018 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5BA126FDC; Mon, 12 Feb 2018 13:12:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151846992832.5990.1015894494551358794@ietfa.amsl.com> Date: Mon, 12 Feb 2018 13:12:08 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-coap-pubsub-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2018 21:12:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : Publish-Subscribe Broker for the Constrained Application Protocol (CoAP) Authors : Michael Koster Ari Keranen Jaime Jiménez Filename : draft-ietf-core-coap-pubsub-03.txt Pages : 23 Date : 2018-02-12 Abstract: The Constrained Application Protocol (CoAP), and related extensions are intended to support machine-to-machine communication in systems where one or more nodes are resource constrained, in particular for low power wireless sensor networks. This document defines a publish- subscribe broker for CoAP that extends the capabilities of CoAP for supporting nodes with long breaks in connectivity and/or up-time. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-coap-pubsub/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-coap-pubsub-03 https://datatracker.ietf.org/doc/html/draft-ietf-core-coap-pubsub-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-coap-pubsub-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 12 13:19:06 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFF912704A for ; Mon, 12 Feb 2018 13:19:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net 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 5rER0l44ufqC for ; Mon, 12 Feb 2018 13:19:03 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ACC112D962 for ; Mon, 12 Feb 2018 13:19:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=YCtPP6bXJrxXlkSFrQOGC2URPH7990pMNDgkIxnkHUDNhHbreVvbWwZ8sxZK58vOAPO8cGNwbT1BOBSRHswSYSw/DjJfrTOYs0VHY1Sq0rW3v0UplBO1UnnVQVLfGrhPtsw01JB3CEWlIH9id57dCrMz6aLZCyNkKV1ffsXcqzY=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 19340 invoked from network); 12 Feb 2018 22:12:19 +0100 Received: from mue-88-130-61-078.dsl.tropolys.de (HELO ?192.168.178.33?) (88.130.61.78) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 12 Feb 2018 22:12:18 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <4B20067C-5F2E-4F30-8AEB-27B2B07D107C@ericsson.com> Date: Mon, 12 Feb 2018 22:12:17 +0100 Cc: "draft-ietf-core-cocoa.all@ietf.org" , "core@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <477E70B1-A8B3-4A27-B2E1-CE26DF46DE68@kuehlewind.net> References: <4B20067C-5F2E-4F30-8AEB-27B2B07D107C@ericsson.com> To: =?utf-8?Q?Jaime_Jim=C3=A9nez?= X-Mailer: Apple Mail (2.3445.5.20) X-PPP-Message-ID: <20180212211218.19334.57961@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [core] AD review of draft-ietf-core-cocoa-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2018 21:19:04 -0000 Thanks! > Am 12.02.2018 um 14:33 schrieb Jaime Jim=C3=A9nez = : >=20 >> @Jaime: could you please update the shepherd-write to reflect that = I=E2=80=99m the responsible area director and maybe provide one = additional sentence to explain why informational is the right indented = status! >=20 > Done! >=20 > - - Jaime Jim=C3=A9nez >=20 >> On 9 Feb 2018, at 15.58, Mirja Kuehlewind (IETF) = wrote: >>=20 >> Hi authors! >>=20 >> I reviewed the document and think it is ready for IETF last call. = Find below a couple of mostly editorial notes that came to my mind while = reviewing the document. Please let me know if you=E2=80=99ll like to = address (if at all) any of these comments with an update before I start = IETF last call, or if I should start the last call immediately with this = version! >>=20 >> @Jaime: could you please update the shepherd-write to reflect that = I=E2=80=99m the responsible area director and maybe provide one = additional sentence to explain why informational is the right indented = status! >>=20 >> Thanks! >> Mirja >>=20 >> -------------------------- >>=20 >> Mostly editorial comments: >>=20 >> 1) First sentence in sec 1, maybe:=20 >> s/The CoAP protocol/The Constrained Application Protocol (CoAP) = [RFC7252]/ >>=20 >> 2) The following note is not necessary: >> "(Note that the present document is itself informational, but it is >> discussing normative statements about behavior that makes the >> congestion control scheme work in a safe manner.)=E2=80=9C >>=20 >> 3) The formatting with (1) and (2) is a bit confusing in the = equations in section 4.2.; maybe you can add some more space there. = Further I really find it confusing that you directly use RTO instead of = RTT here and then just later explain that you use an K of 1. I would = rather explain that first an maybe even use RTT_weak and RTT_strong = instead of E_ >>=20 >> 4) I find the heading of section 4.2.1 a bit confusing and the whole = section a bit hard to read as you didn=E2=80=99t really introduce the = =E2=80=9Enew=E2=80=9C backoff calculation yet. Maybe you can actually = move some of the discussion (about initial values and K) in the previous = subsection and call this ubsection something like =E2=80=9EBackoff = calculation=E2=80=9C and then maybe add one sentence that explains what = RFC6298 does, e.g. =E2=80=9EIn [RFC6298] the RTO is increased = exponentially with a factor of 2 if the RTO timer expires.=E2=80=9C >>=20 >> 4) sec 4.3 "It MUST be kept for at least 255 s.=E2=80=9C >> Why is that a MUST and why 255s? >>=20 >> 5) I would consider to have section 5 before section 4, to give the = reader a better idea that the calculated RTO is used to define the = sending rate (which is the actually congestion control part of the = spec). I think it would also be good to give a high-level (1-2 = sentences) overview of the congestion control principle in the intro, = e.g. CoCoA calculates the retransmission time-out (RTO) based on the = estimated RTT with and without loss and limits the sending rate (for = non-confinable packets) to 1/RTO. By taking retransmissions (in a = potentially lossy network) into account when estimating the RTT, this = algorithm reacts to congestion will a lower sending rate.=E2=80=9C >>=20 >> Also this sentence in section 5.1 could be helpful information in the = intro already: "Assuming that the RTO >> estimation in CoCoA works as expected, RTO[k] should be slightly >> greater than the RTT[k], thus CoCoA would be more conservative.=E2=80= =9C >>=20 >> 6) Maybe consider to integrate Appendix B into the body of the = document. I think that would actually help the reader. >>=20 >>=20 >=20 From nobody Mon Feb 12 22:15:40 2018 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F8312E888; Mon, 12 Feb 2018 22:15:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151850253530.22168.5893787237631626068@ietfa.amsl.com> Date: Mon, 12 Feb 2018 22:15:35 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-oscore-groupcomm-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Feb 2018 06:15:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : Secure group communication for CoAP Authors : Marco Tiloca Goeran Selander Francesca Palombini Jiye Park Filename : draft-ietf-core-oscore-groupcomm-00.txt Pages : 29 Date : 2018-02-12 Abstract: This document describes a method for protecting group communication over the Constrained Application Protocol (CoAP). The proposed approach relies on Object Security for Constrained RESTful Environments (OSCORE) and the CBOR Object Signing and Encryption (COSE) format. All security requirements fulfilled by OSCORE are maintained for multicast OSCORE request messages and related OSCORE response messages. Source authentication of all messages exchanged within the group is ensured, by means of digital signatures produced through private keys of sender devices and embedded in the protected CoAP messages. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-oscore-groupcomm/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-oscore-groupcomm-00 https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 14 17:36:57 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEED412D955; Wed, 14 Feb 2018 17:36:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 QF8pa43CzMnE; Wed, 14 Feb 2018 17:36:36 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1866B12D87A; Wed, 14 Feb 2018 17:35:36 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 3E44EB8129C; Wed, 14 Feb 2018 17:35:18 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, core@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20180215013518.3E44EB8129C@rfc-editor.org> Date: Wed, 14 Feb 2018 17:35:18 -0800 (PST) Archived-At: Subject: [core] =?utf-8?q?RFC_8323_on_CoAP_=28Constrained_Application_Prot?= =?utf-8?q?ocol=29_over_TCP=2C_TLS=2C_and_WebSockets?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 01:36:44 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8323 Title: CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets Author: C. Bormann, S. Lemay, H. Tschofenig, K. Hartke, B. Silverajan, B. Raymor, Ed. Status: Standards Track Stream: IETF Date: February 2018 Mailbox: cabo@tzi.org, slemay@zebra.com, Hannes.Tschofenig@gmx.net, hartke@tzi.org, Bilhanan.Silverajan@tut.fi, brianraymor@hotmail.com Pages: 54 Characters: 110771 Updates: RFC 7641, RFC 7959 I-D Tag: draft-ietf-core-coap-tcp-tls-11.txt URL: https://www.rfc-editor.org/info/rfc8323 DOI: 10.17487/RFC8323 The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of CoAP over UDP includes support for reliable delivery, simple congestion control, and flow control. Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or Transport Layer Security (TLS). This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. It also formally updates RFC 7641 for use with these transports and RFC 7959 to enable the use of larger messages over a reliable transport. This document is a product of the Constrained RESTful Environments Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Feb 14 22:41:23 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC5E1205F0 for ; Wed, 14 Feb 2018 22:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 9hEohPpFBOgU for ; Wed, 14 Feb 2018 22:41:19 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 466841200E5 for ; Wed, 14 Feb 2018 22:41:19 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w1F6fF6x012655 for ; Thu, 15 Feb 2018 07:41:15 +0100 (CET) Received: from client-0081.vpn.uni-bremen.de (client-0081.vpn.uni-bremen.de [134.102.107.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3zhmrW4DgyzDX9B; Thu, 15 Feb 2018 07:41:15 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: <20180215013518.3E44EB8129C@rfc-editor.org> Date: Thu, 15 Feb 2018 07:41:14 +0100 X-Mao-Original-Outgoing-Id: 540369673.184021-15436abd77457abe42d43c286820fb18 Content-Transfer-Encoding: quoted-printable Message-Id: <08D3C97B-82E1-4D7F-B5AC-6A36C07D0597@tzi.org> References: <20180215013518.3E44EB8129C@rfc-editor.org> To: "core@ietf.org WG (core@ietf.org)" X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [core] RFC 8323 on CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 06:41:22 -0000 This took a lot longer to complete than we thought it would. Thanks to Alexey Melnikov for making it happen. Special thanks to Brian Raymor for taking on the various fragments we = had, as the editor and diligently turning them into a good document. Of course, thanks also to the RFC editor, the other esteemed co-authors, = the contributors (there were too many authors to list them all as = authors), the Working Group, and all other people who provided input and = comments! (See https://tools.ietf.org/html/rfc8323#page-52 for what surely is an = incomplete list.) More interops are next. =20 In the first interop, it was amazing to experience how low-complexity = CoAP over TCP/TLS has become. TCP is often not a good match for constrained node networks, but if you = do need to use it for some reason (such as IPv4 NAT traversal), adding = CoAP on top of it is extremely easy. CoAP over WebSockets now provides a good way to do CoAP out of a = JavaScript program running in a browser before browsers learn to do this = natively. Gr=C3=BC=C3=9Fe, Carsten > On Feb 15, 2018, at 02:35, rfc-editor@rfc-editor.org wrote: >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 8323 >=20 > Title: CoAP (Constrained Application Protocol) over=20 > TCP, TLS, and WebSockets=20 > Author: C. Bormann,=20 > S. Lemay, > H. Tschofenig, > K. Hartke, > B. Silverajan, > B. Raymor, Ed. > Status: Standards Track > Stream: IETF > Date: February 2018 > Mailbox: cabo@tzi.org,=20 > slemay@zebra.com,=20 > Hannes.Tschofenig@gmx.net, > hartke@tzi.org,=20 > Bilhanan.Silverajan@tut.fi, > brianraymor@hotmail.com > Pages: 54 > Characters: 110771 > Updates: RFC 7641, RFC 7959 >=20 > I-D Tag: draft-ietf-core-coap-tcp-tls-11.txt >=20 > URL: https://www.rfc-editor.org/info/rfc8323 >=20 > DOI: 10.17487/RFC8323 >=20 > The Constrained Application Protocol (CoAP), although inspired by > HTTP, was designed to use UDP instead of TCP. The message layer of > CoAP over UDP includes support for reliable delivery, simple > congestion control, and flow control. >=20 > Some environments benefit from the availability of CoAP carried over > reliable transports such as TCP or Transport Layer Security (TLS). > This document outlines the changes required to use CoAP over TCP, > TLS, and WebSockets transports. It also formally updates RFC 7641 > for use with these transports and RFC 7959 to enable the use of > larger messages over a reliable transport. >=20 > This document is a product of the Constrained RESTful Environments = Working Group of the IETF. >=20 > This is now a Proposed Standard. >=20 > STANDARDS TRACK: This document specifies an Internet Standards Track > protocol for the Internet community, and requests discussion and = suggestions > for improvements. Please refer to the current edition of the Official > Internet Protocol Standards (https://www.rfc-editor.org/standards) for = the=20 > standardization state and status of this protocol. Distribution of = this=20 > memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > https://www.ietf.org/mailman/listinfo/ietf-announce > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see https://www.rfc-editor.org/search > For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk >=20 > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. = Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 >=20 From nobody Thu Feb 15 04:40:25 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B05B12D969 for ; Thu, 15 Feb 2018 04:40:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net 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 vfclQlCVW9O0 for ; Thu, 15 Feb 2018 04:40:21 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF7DF12D961 for ; Thu, 15 Feb 2018 04:40:16 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=oIPuxQ8pUnp0KtqxpF1vOR6OtvzXY3vQUym23ueguHcXdH/SYRs4Q0gxIdwZGKCpD6sjcye+1oK9QV7woC1n9xmaFH6tGngQDqDh6J0XqAC1KGuLdHpq/gqJD+hzRDtwDY7DsbFETAuV0GgKbLuKF9dPYS7KJes52ZpafF0YyJI=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 1693 invoked from network); 15 Feb 2018 13:39:13 +0100 Received: from mue-88-130-61-168.dsl.tropolys.de (HELO ?192.168.178.33?) (88.130.61.168) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 15 Feb 2018 13:39:13 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <477E70B1-A8B3-4A27-B2E1-CE26DF46DE68@kuehlewind.net> Date: Thu, 15 Feb 2018 13:39:12 +0100 Cc: "core@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <78806C40-FE57-4785-B59A-E69E06784888@kuehlewind.net> References: <4B20067C-5F2E-4F30-8AEB-27B2B07D107C@ericsson.com> <477E70B1-A8B3-4A27-B2E1-CE26DF46DE68@kuehlewind.net> To: "draft-ietf-core-cocoa.all@ietf.org" X-Mailer: Apple Mail (2.3445.5.20) X-PPP-Message-ID: <20180215123913.1688.36784@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [core] AD review of draft-ietf-core-cocoa-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 12:40:24 -0000 Hi authors, do want to make another update before I start IETF last call, or should = I start it right away? Mirja > Am 12.02.2018 um 22:12 schrieb Mirja Kuehlewind (IETF) = : >=20 > Thanks! >=20 >> Am 12.02.2018 um 14:33 schrieb Jaime Jim=C3=A9nez = : >>=20 >>> @Jaime: could you please update the shepherd-write to reflect that = I=E2=80=99m the responsible area director and maybe provide one = additional sentence to explain why informational is the right indented = status! >>=20 >> Done! >>=20 >> - - Jaime Jim=C3=A9nez >>=20 >>> On 9 Feb 2018, at 15.58, Mirja Kuehlewind (IETF) = wrote: >>>=20 >>> Hi authors! >>>=20 >>> I reviewed the document and think it is ready for IETF last call. = Find below a couple of mostly editorial notes that came to my mind while = reviewing the document. Please let me know if you=E2=80=99ll like to = address (if at all) any of these comments with an update before I start = IETF last call, or if I should start the last call immediately with this = version! >>>=20 >>> @Jaime: could you please update the shepherd-write to reflect that = I=E2=80=99m the responsible area director and maybe provide one = additional sentence to explain why informational is the right indented = status! >>>=20 >>> Thanks! >>> Mirja >>>=20 >>> -------------------------- >>>=20 >>> Mostly editorial comments: >>>=20 >>> 1) First sentence in sec 1, maybe:=20 >>> s/The CoAP protocol/The Constrained Application Protocol (CoAP) = [RFC7252]/ >>>=20 >>> 2) The following note is not necessary: >>> "(Note that the present document is itself informational, but it is >>> discussing normative statements about behavior that makes the >>> congestion control scheme work in a safe manner.)=E2=80=9C >>>=20 >>> 3) The formatting with (1) and (2) is a bit confusing in the = equations in section 4.2.; maybe you can add some more space there. = Further I really find it confusing that you directly use RTO instead of = RTT here and then just later explain that you use an K of 1. I would = rather explain that first an maybe even use RTT_weak and RTT_strong = instead of E_ >>>=20 >>> 4) I find the heading of section 4.2.1 a bit confusing and the whole = section a bit hard to read as you didn=E2=80=99t really introduce the = =E2=80=9Enew=E2=80=9C backoff calculation yet. Maybe you can actually = move some of the discussion (about initial values and K) in the previous = subsection and call this ubsection something like =E2=80=9EBackoff = calculation=E2=80=9C and then maybe add one sentence that explains what = RFC6298 does, e.g. =E2=80=9EIn [RFC6298] the RTO is increased = exponentially with a factor of 2 if the RTO timer expires.=E2=80=9C >>>=20 >>> 4) sec 4.3 "It MUST be kept for at least 255 s.=E2=80=9C >>> Why is that a MUST and why 255s? >>>=20 >>> 5) I would consider to have section 5 before section 4, to give the = reader a better idea that the calculated RTO is used to define the = sending rate (which is the actually congestion control part of the = spec). I think it would also be good to give a high-level (1-2 = sentences) overview of the congestion control principle in the intro, = e.g. CoCoA calculates the retransmission time-out (RTO) based on the = estimated RTT with and without loss and limits the sending rate (for = non-confinable packets) to 1/RTO. By taking retransmissions (in a = potentially lossy network) into account when estimating the RTT, this = algorithm reacts to congestion will a lower sending rate.=E2=80=9C >>>=20 >>> Also this sentence in section 5.1 could be helpful information in = the intro already: "Assuming that the RTO >>> estimation in CoCoA works as expected, RTO[k] should be slightly >>> greater than the RTT[k], thus CoCoA would be more conservative.=E2=80= =9C >>>=20 >>> 6) Maybe consider to integrate Appendix B into the body of the = document. I think that would actually help the reader. >>>=20 >>>=20 >>=20 >=20 From nobody Fri Feb 16 06:23:52 2018 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B066712D87C; Fri, 16 Feb 2018 06:23:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.72.1 Auto-Submitted: auto-generated Precedence: bulk CC: alexey.melnikov@isode.com, draft-ietf-core-object-security@ietf.org, core-chairs@ietf.org, core@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151879103067.4953.9893299656933286646.idtracker@ietfa.amsl.com> Date: Fri, 16 Feb 2018 06:23:50 -0800 Archived-At: Subject: [core] Last Call: (Object Security for Constrained RESTful Environments (OSCORE)) to Proposed Standard X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 14:23:51 -0000 The IESG has received a request from the Constrained RESTful Environments WG (core) to consider the following document: - 'Object Security for Constrained RESTful Environments (OSCORE)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-03-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-core-object-security/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-core-object-security/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Sat Feb 17 07:27:54 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C28A1241F5; Sat, 17 Feb 2018 07:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.111 X-Spam-Level: X-Spam-Status: No, score=-0.111 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 PZn0h4rq2gRL; Sat, 17 Feb 2018 07:27:51 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 30190120047; Sat, 17 Feb 2018 07:27:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1518881269; d=isode.com; s=june2016; i=@isode.com; bh=PJlfWhDbjFfKxLCNv1gNaOQ77GmRMat3kbSQzMkssgk=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=RLN3mRNSxEBPbc+J1cDc4lDOjF/ia7P60Vq4IcgQPo8owITDu46Xnv+1Lloaf6nrYYQonY JSPVzp//C3LcbzAXPHocsbVAUO0wgAKWpvj1ZLeUjpadVDJUpT5F+1qRLJ55WkvFzRaKzj X3ewIPahMr8bu7DOOVVGQDRC7jo4UxI=; Received: from [192.168.0.3] (cpc121086-nmal24-2-0-cust54.19-2.cable.virginm.net [77.97.145.55]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Sat, 17 Feb 2018 15:27:49 +0000 To: draft-ietf-core-object-security.authors@ietf.org From: Alexey Melnikov Cc: "core@ietf.org WG" Message-ID: <5A8849F5.6070703@isode.com> Date: Sat, 17 Feb 2018 15:27:49 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Archived-At: Subject: [core] AD review of draft-ietf-core-object-security-08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Feb 2018 15:27:52 -0000 Hi, In order to speed up publication process I initiated IETF LC before fully completing my AD review. The completed review is below: In general I found the document to be well written and quite detailed (which I like). Some smaller issues and a few questions below: Minor: 1) I found Section 6 to be confusing. There is nothing about payload compression there. There is also description of the Object-Security option format. Maybe rename the section, as it is not purely about compression? In particular, In Section 6.1: I suggest you explain that Object-Security option is a more compact encoding of the Headers in the COSE_Encrypt0 structure. If that is not the case, then I think this section needs even more work. 2) In Section 8.3, point 3: If Observe is not used, either the nonce from the request is used or a new Partial IV is used. How can the responder decide which of the choices to use? (If this is covered elsewhere in the document, I would appreciate a reference). 3) In Section 9: Does "osc" target attribute need to be registered with IANA? 4) In Section 10.1: the reference to [I-D.ietf-core-echo-request-tag] looks Normative to me, not Informative. 5) In Section 10.2: which media type is used for the OSCORE-encrypted payload transported in HTTP? Nits: In Section 3.3: To enable retrieval of the right Recipient Context, the Recipient ID SHOULD be unique in the sets of all Recipient Contexts used by an Does this SHOULD need a bit more explaining (i.e. why it is not a MUST)? endpoint. The Client MAY provide a 'kid context' parameter (Section 5.1) to help the Server find the right context. [I-D.ietf-core-coap-tcp-tls] - this is RFC 8323 now. First mention of AEAD needs a reference to RFC 5116. The document references it later on in the document, so maybe just move the reference earlier. Best Regards, Alexey From nobody Sat Feb 17 08:34:59 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2DDA1204DA; Sat, 17 Feb 2018 08:34:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 JApWs0NPk0ix; Sat, 17 Feb 2018 08:34:44 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16CB4120725; Sat, 17 Feb 2018 08:34:43 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w1HGYepK013857; Sat, 17 Feb 2018 17:34:40 +0100 (CET) Received: from client-0231.vpn.uni-bremen.de (client-0231.vpn.uni-bremen.de [134.102.107.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3zkFwF6pZ9zDXjD; Sat, 17 Feb 2018 17:34:37 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 540578068.245754-97e5f0bc463b69dabaa858a33a4d2e19 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Sat, 17 Feb 2018 08:34:29 -0800 Message-Id: To: ace@ietf.org, "core@ietf.org WG (core@ietf.org)" , cose , cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [core] Constrained Node/Network Cluster @ IETF101: DRAFT AGENDA X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Feb 2018 16:34:46 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF101. Remember that there is still quite some potential for changes. The painful ones (not necessarily fixable) this time include: DINRG vs. ACE, CBOR vs. TEEP, ROLL vs. SUIT vs. OCF/WoT; also CORE vs. ANIMA, CORE vs. QUIC. All times are BST (UTC+0100). (You can get pure UTC times on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten SATURDAY/SUNDAY -- Hackathon (including various interops) MONDAY, March 19, 2018 0930-1200 Morning Session I Bleinheim ART dispatch Dispatch WG - 0930-1100 Joint = with ARTAREA Sandringham INT ipwave IP Wireless Access in Vehicular = Environments WG Palace C IRTF*** dinrg Decentralized Internet Infrastructure = Proposed RG Viscount OPS v6ops IPv6 Operations WG Balmoral SEC *** ace Authentication and Authorization for = Constrained Environments WG 1330-1530 Afternoon Session I Buckingham ART *** core Constrained RESTful Environments WG Viscount INT 6man IPv6 Maintenance WG Sandringham TSV quic QUIC WG 1550-1720 Afternoon Session II Sandringham INT intarea Internet Area Working Group WG Balmoral IRTF cfrg Crypto Forum Buckingham SEC oauth Web Authorization Protocol WG 1740-1840 Afternoon Session III Balmoral SEC tls Transport Layer Security WG Sandringham TSV tsvarea Transport Area Open Meeting TUESDAY, March 20, 2018 0930-1200 Morning Session I Viscount ART *** core Constrained RESTful Environments WG Sandringham IRTF maprg Measurement and Analysis for Protocols Buckingham OPS anima Autonomic Networking Integrated Model = and Approach WG Bleinheim SEC secdispatch Security Dispatch WG 1330-1530 Afternoon Session I Park Suite ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Buckingham IRTF panrg Path Aware Networking Proposed RG Richm_Chl_Tow RTG rift Routing In Fat Trees WG Balmoral SEC *** teep Trusted Execution Environment = Provisioning BOF 1550-1820 Afternoon Session II Balmoral ART httpbis Hypertext Transfer Protocol WG Park Suite IRTF icnrg Information-Centric Networking WEDNESDAY, March 21, 2018 0930-1200 Morning Session I Viscount INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Sandringham IRTF irtfopen IRTF Open Meeting Bleinheim SEC tls Transport Layer Security WG Park Suite TSV taps Transport Services WG 1330-1500 Afternoon Session I Viscount INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Richm_Chl_Tow RTG bier Bit Indexed Explicit Replication WG Park Suite SEC oauth Web Authorization Protocol WG Palace C TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1520-1650 Afternoon Session II Park Suite INT *** lwig Light-Weight Implementation Guidance WG Buckingham SEC acme Automated Certificate Management = Environment WG Viscount SEC tokbind Token Binding WG 1710-1940 IETF Plenary - Sandringham THURSDAY, March 22, 2018 0930-1200 Morning Session I Buckingham INT dnssd Extensions for Scalable DNS Service = Discovery WG Park Suite RTG *** roll Routing Over Low power and Lossy = networks WG Sandringham TSV quic QUIC WG 1330-1530 Afternoon Session I Buckingham INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Sandringham SEC saag Security Area Open Meeting 1550-1750 Afternoon Session II Bleinheim IRTF*** t2trg Thing-to-Thing Sandringham RTG rtgarea Routing Area Open Meeting Buckingham SEC mls Messaging Layer Security BOF Balmoral TSV tsvwg Transport Area Working Group WG 1810-1910 Afternoon Session III Bleinheim ART uta Using TLS in Applications WG Park Suite RTG babel Babel routing protocol WG Balmoral TSV tsvwg Transport Area Working Group WG FRIDAY, March 23, 2018 0930-1130 Morning Session I Richm_Chl_Tow ART ice Interactive Connectivity Establishment = WG - 0930 - 1030 Sandringham INT homenet Home Networking WG Bleinheim RTG detnet Deterministic Networking WG Viscount RTG *** roll Routing Over Low power and Lossy = networks WG Balmoral SEC *** suit Software Updates for Internet of Things = WG 1150-1320 Afternoon Session I Bleinheim RTG detnet Deterministic Networking WG 1330-1730 @ OCF meeting venue (Prague, colocated with W3C WoT) -- Joint meeting of OCF, W3C WoT, and T2TRG From nobody Mon Feb 19 05:31:23 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B15D21274D2 for ; Mon, 19 Feb 2018 05:31:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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_MED=-2.3, 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 (1024-bit key) header.d=ericsson.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 d_5h1JXS1nnT for ; Mon, 19 Feb 2018 05:31:20 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BF8A127873 for ; Mon, 19 Feb 2018 05:31:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519047073; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=gi3/r6JbMZ+wp3lzEMGx9OEN46LA3c+McX4oZQwNTuk=; b=MTV2A/hCDX5V0ipZtZlFpp+CwG4drZXrQCJqzlXunEfgQY7RnHDLDiKsxxy+HQAz gEHe7u+39UHogILDchZQUr2f28ldwB+FMQCOZ4CL0a4xZ8LsVZ6slGYIQnbML2q4 4Xm472PILjXmRcldTI7XxRAhCDWaBmI6f7QmwdDoPwE=; X-AuditID: c1b4fb25-823ff700000038f0-24-5a8ad1a1fd79 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 95.93.14576.1A1DA8A5; Mon, 19 Feb 2018 14:31:13 +0100 (CET) Received: from ESESSMB107.ericsson.se ([169.254.7.129]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0352.000; Mon, 19 Feb 2018 14:31:13 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Alexey Melnikov , "draft-ietf-core-object-security.authors@ietf.org" CC: "core@ietf.org WG" Thread-Topic: AD review of draft-ietf-core-object-security-08 Thread-Index: AQHTqAPh+m6SWmYgJ0qGWkdVgXnjGqOru9wA Date: Mon, 19 Feb 2018 13:31:12 +0000 Message-ID: References: <5A8849F5.6070703@isode.com> In-Reply-To: <5A8849F5.6070703@isode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIIsWRmVeSWpSXmKPExsUyM2K7tO7Ci11RBjsfGVjMWF1kse/temaL zc++sjoweyxZ8pPJ41SzYQBTFJdNSmpOZllqkb5dAlfG6d3OBXscKqa8fsPcwPjCrouRk0NC wETiz9U3jF2MXBxCAocZJeZt38kK4SxhlPi7+wo7SBWbgIvEg4ZHTCAJEYFZjBLT5i5hBUkw C6hJPFp6jgXEFhawkbhz4SVYXETAVmLai1tsELaRRP/t3YwgNouAqkTf6uVg9bwCFhLHvjwE GsoBtE1DYv/SepAwp4CmxPK/c5hBbEYBMYnvp9YwQawSl7j1ZD4TxNUCEkv2nGeGsEUlXj7+ B7ZWVEBPYm9POxtEXFFi59l2ZpDxzEAz1+/ShxhjLbFqfwMLhK0oMaX7ITvENYISJ2c+YZnA KD4LybZZCN2zkHTPQtI9C0n3AkbWVYyixanFSbnpRsZ6qUWZycXF+Xl6eaklmxiBEXdwy2/V HYyX3zgeYhTgYFTi4fU81RUlxJpYVlyZe4hRgoNZSYTXIgQoxJuSWFmVWpQfX1Sak1p8iFGa g0VJnHeOcHuUkEB6YklqdmpqQWoRTJaJg1OqgVF6t2ZbY4JlxJkdL3ZfPv/IVDW8deN3+Qrp lzFnTLLrL93TeC1ho84gX2291OpI059ZzUbHZ31fuLpeI3qi+NKlrlb/9n0qjWv5tOKGbOPd BWLzXL+KTroakPR/0a1GS8d5L6bbei3yjvzDvPOC4pYAnc3OznLtHDN/Xc33MHj3Y8XmnUsn CnkpsRRnJBpqMRcVJwIA7RJZVbQCAAA= Archived-At: Subject: Re: [core] AD review of draft-ietf-core-object-security-08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 13:31:23 -0000 SGkgQWxleGV5LA0KDQpUaGFua3MgZm9yIHRoZSByZXZpZXcsIGNvbW1lbnRzL3F1ZXN0aW9ucyBp bmxpbmUgYmVsb3cuDQoNCkkgdXBkYXRlZCB0aGUgZHJhZnQgb24gdGhlIENvUkUgV0cgR2l0aHVi IGJhc2VkIG9uIHRoZSByZXZpZXcsIHRoZSBjb21taXQNCmlzIGhlcmU6DQpodHRwczovL2dpdGh1 Yi5jb20vY29yZS13Zy9vc2NvYXAvY29tbWl0Lzc2NTY2NjINCg0KVGhlIHJlc3VsdGluZyBkb2N1 bWVudCBpcyBoZXJlIChpbmNsdWRpbmcgYWxzbyBzb21lIGVkaXRvcmlhbCBmaXhlcyBhbmQNCnRo ZSBuZXcgQXBwZW5kaXggRCBwcm9wb3NlZCBieSB0aGUgU2hlcGhlcmQpOg0KaHR0cHM6Ly9jb3Jl LXdnLmdpdGh1Yi5pby9vc2NvYXAvZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eS5odG1s DQoNCg0KT24gMjAxOC0wMi0xNyAxNjoyNywgIkFsZXhleSBNZWxuaWtvdiIgPGFsZXhleS5tZWxu aWtvdkBpc29kZS5jb20+IHdyb3RlOg0KDQo+SGksDQo+SW4gb3JkZXIgdG8gc3BlZWQgdXAgcHVi bGljYXRpb24gcHJvY2VzcyBJIGluaXRpYXRlZCBJRVRGIExDIGJlZm9yZQ0KPmZ1bGx5IGNvbXBs ZXRpbmcgbXkgQUQgcmV2aWV3LiBUaGUgY29tcGxldGVkIHJldmlldyBpcyBiZWxvdzoNCj4NCj5J biBnZW5lcmFsIEkgZm91bmQgdGhlIGRvY3VtZW50IHRvIGJlIHdlbGwgd3JpdHRlbiBhbmQgcXVp dGUgZGV0YWlsZWQNCj4od2hpY2ggSSBsaWtlKS4gU29tZSBzbWFsbGVyIGlzc3VlcyBhbmQgYSBm ZXcgcXVlc3Rpb25zIGJlbG93Og0KPg0KPk1pbm9yOg0KPg0KPjEpIEkgZm91bmQgU2VjdGlvbiA2 IHRvIGJlIGNvbmZ1c2luZy4gVGhlcmUgaXMgbm90aGluZyBhYm91dCBwYXlsb2FkDQo+Y29tcHJl c3Npb24gdGhlcmUuIFRoZXJlIGlzIGFsc28gZGVzY3JpcHRpb24gb2YgdGhlIE9iamVjdC1TZWN1 cml0eQ0KPm9wdGlvbiBmb3JtYXQuIE1heWJlIHJlbmFtZSB0aGUgc2VjdGlvbiwgYXMgaXQgaXMg bm90IHB1cmVseSBhYm91dA0KPmNvbXByZXNzaW9uPw0KDQpbR1NdIFBldGVyIHZhbiBkZXIgU3Rv ayBhbHNvIGNvbW1lbnRlZCBvbiB0aGlzIGluIGhpcyByZXZpZXcgYW5kIHdlIG1hZGUNCmFuIHVw ZGF0ZSwgYnV0IG1heWJlIHRoaXMgbmVlZHMgdG8gYmUgY2xhcmlmaWVkIGZ1cnRoZXIuIEkgaGF2 ZSBjaGFuZ2VkDQp0aGUgdGl0bGUgb2YgdGhlIHNlY3Rpb24g4oCcT1NDT1JFIEhlYWRlciBDb21w cmVzc2lvbuKAnSBlbXBoYXNpemluZyB0aGF0IGl0DQppcyBhYm91dCBlbmNvZGluZyBoZWFkZXJz LCB3aGljaCBpcyBhbHNvIGFsaWduZWQgd2l0aCB5b3VyIG90aGVyIGNvbW1lbnQ6DQoNCg0KPg0K PkluIHBhcnRpY3VsYXIsIEluIFNlY3Rpb24gNi4xOiBJIHN1Z2dlc3QgeW91IGV4cGxhaW4gdGhh dA0KPk9iamVjdC1TZWN1cml0eSBvcHRpb24gaXMgYSBtb3JlIGNvbXBhY3QgZW5jb2Rpbmcgb2Yg dGhlIEhlYWRlcnMgaW4gdGhlDQo+Q09TRV9FbmNyeXB0MCBzdHJ1Y3R1cmUuDQoNCltHU10gSSBh ZGRlZCB0aGUgZXhwbGFuYXRpb24gaW1tZWRpYXRlbHkgYmVmb3JlIFNlY3Rpb24gNi4xLg0KDQoN Cj4NCj4yKSBJbiBTZWN0aW9uIDguMywgcG9pbnQgMzoNCj4NCj5JZiBPYnNlcnZlIGlzIG5vdCB1 c2VkLCBlaXRoZXIgdGhlIG5vbmNlIGZyb20gdGhlDQo+cmVxdWVzdCBpcyB1c2VkIG9yIGEgbmV3 IFBhcnRpYWwgSVYgaXMgdXNlZC4NCj4NCj5Ib3cgY2FuIHRoZSByZXNwb25kZXIgZGVjaWRlIHdo aWNoIG9mIHRoZSBjaG9pY2VzIHRvIHVzZT8gKElmIHRoaXMgaXMNCj5jb3ZlcmVkIGVsc2V3aGVy ZSBpbiB0aGUgZG9jdW1lbnQsIEkgd291bGQgYXBwcmVjaWF0ZSBhIHJlZmVyZW5jZSkuDQoNCg0K W0dTXSBUaGlzIGlzIGRpc2N1c3NlZCBpbiB0aGUgYmVnaW5uaW5nIG9mIHNlY3Rpb24gNSwgSSBh ZGRlZCB0aGUgYQ0KcmVmZXJlbmNlLiAoVGhlIGFuc3dlciBpcyB0aGF0IHRoZSBmb3JtZXIgaXMg cmVjb21tZW5kZWQsIHRvIHNhdmUgbWVzc2FnZQ0Kb3ZlcmhlYWQsIGJ1dCB0aGVyZSBhcmUgbm9u LU9ic2VydmUgZXhhbXBsZXMgd2hlcmUgdGhlIFBhcnRpYWwgSVYgaXMNCmluY2x1ZGVkIGluIGEg cmVzcG9uc2UsIHNlZSBzZWN0aW9uIDcuNS4yLikNCg0KDQoNCj4NCj4zKSBJbiBTZWN0aW9uIDk6 IERvZXMgIm9zYyIgdGFyZ2V0IGF0dHJpYnV0ZSBuZWVkIHRvIGJlIHJlZ2lzdGVyZWQgd2l0aA0K PklBTkE/DQoNCltHU10gSSBkb27igJl0IHRoaW5rIHNvLiBXZSBtaW1pY2tlZCB0aGUgc3BlY2lm aWNhdGlvbiBvZiB0aGUg4oCcb2Jz4oCdIHRhcmdldA0KYXR0cmlidXRlIGZyb20gUkZDIDc2NDE6 DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzY0MSNzZWN0aW9uLTYNCg0KDQo+DQo+ NCkgSW4gU2VjdGlvbiAxMC4xOiB0aGUgcmVmZXJlbmNlIHRvIFtJLUQuaWV0Zi1jb3JlLWVjaG8t cmVxdWVzdC10YWddDQo+bG9va3MgTm9ybWF0aXZlIHRvIG1lLCBub3QgSW5mb3JtYXRpdmUuDQoN CltHU10gQ29ycmVjdCwgZ29vZCBjYXRjaC4gSG93ZXZlciwgW0ktRC5pZXRmLWNvcmUtZWNoby1y ZXF1ZXN0LXRhZ10gKGlmDQphcHByb3ZlZCkgdXBkYXRlcyBSRkMgNzk1OSAoaS5lLiBCbG9ja3dp c2UpIHdoaWNoIGlzIGFscmVhZHkgbm9ybWF0aXZlbHkNCnJlZmVyZW5jZWQsIHNvIHdlIGRvbuKA mXQgaGF2ZSB0byBtZW50aW9uIFtJLUQuaWV0Zi1jb3JlLWVjaG8tcmVxdWVzdC10YWddDQphdCBh bGwgaW4gdGhpcyBjb250ZXh0LiBJIHJlbW92ZWQgdGhlIHJlZmVyZW5jZS4NCg0KPg0KPjUpIElu IFNlY3Rpb24gMTAuMjogd2hpY2ggbWVkaWEgdHlwZSBpcyB1c2VkIGZvciB0aGUgT1NDT1JFLWVu Y3J5cHRlZA0KPnBheWxvYWQgdHJhbnNwb3J0ZWQgaW4gSFRUUD8NCj4NCg0KW0dTXSBHb29kIHF1 ZXN0aW9uLCB0aGVyZSBhcmUgYSBmZXcgdGhpbmdzIHRvIG5vdGUgaGVyZS4gRmlyc3QsIHRoZSBD b0FQDQpvcHRpb24gQ29udGVudC1Gb3JtYXQgaXMgSW5uZXIgc28gdGhlIENvQVAgcGF5bG9hZCBt ZWRpYSB0eXBlIGlzDQplbmNyeXB0ZWQuIFNlY29uZCwgdGhlIE91dGVyIENvbnRlbnQtRm9ybWF0 IG9wdGlvbiBpcyBub3QgcHJlc2VudCBpbg0KT1NDT1JFIHByb3RlY3RlZCBDb0FQIG1lc3NhZ2Vz IChpbiB0aGUgaW50ZXJlc3Qgb2Ygc2F2aW5nIG1lc3NhZ2UNCm92ZXJoZWFkKS4gVGhpcmQsIHdo ZW4gQ29BUC1tYXBwYWJsZSBIVFRQIGlzIHByb3RlY3RlZCB3aXRoIE9TQ09SRSwgdGhlDQptZXNz YWdlIGlzIGZpcnN0IG1hcHBlZCB0byBDb0FQIGFuZCB0aGVuIHByb2Nlc3NlZCB3aXRoIE9TQ09S RSwgc28gdGhlDQptZWRpYSB0eXBlIG9mIHRoZSBPU0NPUkUgZW5jcnlwdGVkIHBheWxvYWQgaXMg Y2FycmllZCBpbiB0aGUgZW5jcnlwdGVkDQpDb250ZW50LUZvcm1hdCBvcHRpb24gYWxzbyBpbiB0 aGUgY2FzZSBvZiBIVFRQLiBIb3dldmVyLCB3ZSBtYXkgc3RpbGwgd2FudA0KdG8gaGF2ZSBhIENv bnRlbnQtVHlwZSBoZWFkZXIgZmllbGQgaW4gdGhlIEhUVFAgbWVzc2FnZSB0cmFuc3BvcnRpbmcg dGhlDQpPU0NPUkUgbWVzc2FnZS4gV2FzIHRoaXMgd2hhdCB5b3Ugd2VyZSByZWZlcnJpbmcgdG8/ DQoNCkFjY29yZGluZyB0byBSRkMgNzIzMQ0KKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM3MjMxI3NlY3Rpb24tMy4xLjEuNSk6DQoNCidBIHNlbmRlciB0aGF0IGdlbmVyYXRlcyBhIG1l c3NhZ2UgY29udGFpbmluZyBhIHBheWxvYWQgYm9keSBTSE9VTEQNCiAgIGdlbmVyYXRlIGEgQ29u dGVudC1UeXBlIGhlYWRlciBmaWVsZCBpbiB0aGF0IG1lc3NhZ2UgdW5sZXNzIHRoZQ0KICAgaW50 ZW5kZWQgbWVkaWEgdHlwZSBvZiB0aGUgZW5jbG9zZWQgcmVwcmVzZW50YXRpb24gaXMgdW5rbm93 biB0byB0aGUNCiAgIHNlbmRlci4gIElmIGEgQ29udGVudC1UeXBlIGhlYWRlciBmaWVsZCBpcyBu b3QgcHJlc2VudCwgdGhlIHJlY2lwaWVudA0KICAgTUFZIGVpdGhlciBhc3N1bWUgYSBtZWRpYSB0 eXBlIG9mICJhcHBsaWNhdGlvbi9vY3RldC1zdHJlYW3igJ0NCihbUkZDMjA0Nl0pIG9yIGV4YW1p bmUgdGhlIGRhdGEgdG8gZGV0ZXJtaW5lIGl0cyB0eXBlLicNCg0KDQpXaGlsZSBDb250ZW50LVR5 cGUgaXMgcmVjb21tZW5kLCBub3RpbmcgdGhhdCBpbiB0aGUgY2FzZSBvZiBPU0NPUkUgd2Ugd2Fu dA0KdG8gZW5jcnlwdCB0aGUgQ29udGVudC1UeXBlIGZvciB0aGUgb3RoZXIgQ29BUCBlbmRwb2lu dCwgc28gd2hhdGV2ZXIgbWVkaWENCnR5cGUgd2Ugd291bGQgcG90ZW50aWFsbHkgaW5jbHVkZSBp biB0aGUg4oCcT3V0ZXLigJ0gbWVzc2FnZSB3b3VsZCBvbmx5IGJlIGENCmR1bW15LiBGdXJ0aGVy bW9yZSwgdGhlIGRlc3RpbmF0aW9uIGVuZHBvaW50IHdvdWxkIGFueXdheSBmaXJzdCBoYXZlIHRv DQpwcm9jZXNzIHRoZSBPU0NPUkUgbWVzc2FnZSB0byByZWNyZWF0ZSB0aGUgSFRUUCBtZXNzYWdl IGJlZm9yZSBoYW5kaW5nDQpvdmVyIGZvciBIVFRQIHByb2Nlc3NpbmcuDQoNCkFzIEkgcmVhZCB0 aGUgdGV4dCBhYm92ZSBpdCBpcyBwb3NzaWJsZSB0byBsZWF2ZSBDb250ZW50LVR5cGUgb3V0LCBi dXQNCndvdWxkIHRoYXQgYmUgYW4gaXNzdWUgaW4gZXhpc3RpbmcgbmV0d29ya3M/IFdobyB3b3Vs ZCBiZSBhYmxlIHRvIGdpdmUNCnNvbWUgYWR2aWNlIGhlcj8NCg0KSWYgd2UgZGVjaWRlIHRvIGlu Y2x1ZGUgYSBDb250ZW50LVR5cGUgaGVhZGVyIGZpZWxkLCB0aGUgbWFpbiBvcHRpb25zIGFyZToN Cg0KLSByZXVzZSBvZiAiYXBwbGljYXRpb24vY29zZeKAnSBkZWZpbmVkIGluIFJGQyA4MTUyIChp ZiBhcHByb3ByaWF0ZSkNCi0gbmV3IG1lZGlhIHR5cGUgZS5nLiDigJxhcHBsaWNhdGlvbi9vc2Nv cmXigJ0gdG8gYmUgZGVmaW5lZCBpbiB0aGlzIGRyYWZ0Lg0KDQoNCkkgYWRkZWQgYSBwbGFjZWhv bGRlciAoVEJEKSBpbiB0aGUgZHJhZnQuDQoNCg0KPg0KPk5pdHM6DQo+DQo+SW4gU2VjdGlvbiAz LjM6DQo+ICBUbyBlbmFibGUgcmV0cmlldmFsIG9mIHRoZSByaWdodCBSZWNpcGllbnQgQ29udGV4 dCwgdGhlIFJlY2lwaWVudCBJRA0KPiAgU0hPVUxEIGJlIHVuaXF1ZSBpbiB0aGUgc2V0cyBvZiBh bGwgUmVjaXBpZW50IENvbnRleHRzIHVzZWQgYnkgYW4NCj4NCj5Eb2VzIHRoaXMgU0hPVUxEIG5l ZWQgYSBiaXQgbW9yZSBleHBsYWluaW5nIChpLmUuIHdoeSBpdCBpcyBub3QgYSBNVVNUKT8NCg0K SWYgdGhlIFJlY2lwaWVudCBJRCBpcyB0aGUgc2FtZSBmb3IgZGlmZmVyZW50IHNlY3VyaXR5IGNv bnRleHRzIChpLmUuIHdoZW4NCmRpZmZlcmVudCBNYXN0ZXIgU2VjcmV0cykgdGhpcyBpcyBub3Qg YSBzZWN1cml0eSBpc3N1ZSwgYnV0IHRoZSByZWNpcGllbnQNCm1heSBoYXZlIHRvIHRyeSBtdWx0 aXBsZSBzZWN1cml0eSBjb250ZXh0cyBiZWZvcmUgZmluZGluZyB0aGUgcmlnaHQgKGlmDQphbnkp LiBUaGVyZWZvcmUgaXQgaXMgbm90IG1hbmRhdG9yeSBidXQgcmVjb21tZW5kZWQuIEkgYWRkZWQg bW9yZQ0KZXhwbGFuYXRpb24gb24gdGhpcy4NCg0KDQo+DQo+ICBlbmRwb2ludC4gVGhlIENsaWVu dCBNQVkgcHJvdmlkZSBhICdraWQgY29udGV4dCcgcGFyYW1ldGVyIChTZWN0aW9uDQo+ICA1LjEp IHRvIGhlbHAgdGhlIFNlcnZlciBmaW5kIHRoZSByaWdodCBjb250ZXh0Lg0KDQpXZXJlIHRoZXJl IGFueSBjb21tZW50IG9uIHRoaXMgcGFydGljdWxhciB0ZXh0LCBvciBpcyB0aGlzIHNuaXBwZXQg aXQganVzdA0KYSByZW1uYW50IGZyb20gdGhlIHF1b3RlIGluIHRoZSBwcmV2aW91cyBjb21tZW50 Pw0KDQoNCj4NCj4NCj5bSS1ELmlldGYtY29yZS1jb2FwLXRjcC10bHNdIC0gdGhpcyBpcyBSRkMg ODMyMyBub3cuDQoNCk9LLCBkb25lLg0KDQo+DQo+Rmlyc3QgbWVudGlvbiBvZiBBRUFEIG5lZWRz IGEgcmVmZXJlbmNlIHRvIFJGQyA1MTE2LiBUaGUgZG9jdW1lbnQNCj5yZWZlcmVuY2VzIGl0IGxh dGVyIG9uIGluIHRoZSBkb2N1bWVudCwgc28gbWF5YmUganVzdCBtb3ZlIHRoZSByZWZlcmVuY2UN Cj5lYXJsaWVyLg0KPg0KDQpPSywgSSBhZGRlZCB0aGUgcmVmZXJlbmNlIHRvIHRoZSBmaXJzdCBt ZW50aW9uaW5nIG9mIEFFQUQuDQoNCg0KVGhhbmtzDQpHw7ZyYW4NCg0KDQo= From nobody Mon Feb 19 06:00:26 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EBF91274D2; Mon, 19 Feb 2018 06:00:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 Anaep1UZgaeV; Mon, 19 Feb 2018 06:00:22 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 83C2D1242F7; Mon, 19 Feb 2018 06:00:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1519048821; d=isode.com; s=june2016; i=@isode.com; bh=QW1lsC9ztgfkhLdzj7RboGFkZ1W61ViPIndLv8DW8Rw=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=NvIYFTn3eLGziI2c6ef4OKBx7R974mNgxFsEuuFalKvlN9xVItm0bPYTkS2l/ZGZpfO/c9 HcgG5fanRhtJQICfwa799QI8iHp9LJhM6xgz/eU4yIVQWWabVLDoP+Xz2L+vg4z1Dx22YL v6+wbvGT4T+CKU4EYAeaoBLECwe9KDg=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 19 Feb 2018 14:00:21 +0000 To: =?UTF-8?Q?G=c3=b6ran_Selander?= , "draft-ietf-core-object-security.authors@ietf.org" Cc: "core@ietf.org WG" References: <5A8849F5.6070703@isode.com> From: Alexey Melnikov Message-ID: <0f0f5e9e-245f-b0bd-cd1c-48b028b9cdfd@isode.com> Date: Mon, 19 Feb 2018 14:00:20 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [core] AD review of draft-ietf-core-object-security-08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 14:00:24 -0000 Hi G=C3=B6ran, Thank you for the updates. I deleted the ones where I am in agreement=20 and have nothing else to say. On 19/02/2018 13:31, G=C3=B6ran Selander wrote: > Hi Alexey, > > Thanks for the review, comments/questions inline below. > > I updated the draft on the CoRE WG Github based on the review, the commit > is here: > https://github.com/core-wg/oscoap/commit/7656662 > > The resulting document is here (including also some editorial fixes and > the new Appendix D proposed by the Shepherd): > https://core-wg.github.io/oscoap/draft-ietf-core-object-security.html > > > On 2018-02-17 16:27, "Alexey Melnikov" wrote: > >> Hi, >> In order to speed up publication process I initiated IETF LC before >> fully completing my AD review. The completed review is below: >> >> In general I found the document to be well written and quite detailed >> (which I like). Some smaller issues and a few questions below: >> >> Minor: >> >> 1) I found Section 6 to be confusing. There is nothing about payload >> compression there. There is also description of the Object-Security >> option format. Maybe rename the section, as it is not purely about >> compression? > [GS] Peter van der Stok also commented on this in his review and we made > an update, but maybe this needs to be clarified further. I have changed > the title of the section =E2=80=9COSCORE Header Compression=E2=80=9D empha= sizing that it > is about encoding headers, which is also aligned with your other comment: > >> In particular, In Section 6.1: I suggest you explain that >> Object-Security option is a more compact encoding of the Headers in the >> COSE_Encrypt0 structure. > [GS] I added the explanation immediately before Section 6.1. Your new text is better, thank you. =C2=A0(snip) >> 3) In Section 9: Does "osc" target attribute need to be registered with >> IANA? > [GS] I don=E2=80=99t think so. We mimicked the specification of the =E2=80= =9Cobs=E2=80=9D target > attribute from RFC 7641: > https://tools.ietf.org/html/rfc7641#section-6 Ok. I think it would be good to have an IANA registry for these, but no=20 need to make your document do that. >> 4) In Section 10.1: the reference to [I-D.ietf-core-echo-request-tag] >> looks Normative to me, not Informative. > [GS] Correct, good catch. However, [I-D.ietf-core-echo-request-tag] (if > approved) updates RFC 7959 (i.e. Blockwise) which is already normatively > referenced, so we don=E2=80=99t have to mention [I-D.ietf-core-echo-reques= t-tag] > at all in this context. I removed the reference. I don't think this works with references. Does implementing RFC 7959=20 without any knowledge of [I-D.ietf-core-echo-request-tag] be=20 satisfactory with OSCORE? >> 5) In Section 10.2: which media type is used for the OSCORE-encrypted >> payload transported in HTTP? >> > [GS] Good question, there are a few things to note here. First, the CoAP > option Content-Format is Inner so the CoAP payload media type is > encrypted. Second, the Outer Content-Format option is not present in > OSCORE protected CoAP messages (in the interest of saving message > overhead). Third, when CoAP-mappable HTTP is protected with OSCORE, the > message is first mapped to CoAP and then processed with OSCORE, so the > media type of the OSCORE encrypted payload is carried in the encrypted > Content-Format option also in the case of HTTP. However, we may still want > to have a Content-Type header field in the HTTP message transporting the > OSCORE message. Was this what you were referring to? Yes. Applications or plugin frequently get invoked based on media types.=20 So if you want to allow for decoding of OSCORE payloads in a plugin, you=20 should define a media type. > According to RFC 7231 > (https://tools.ietf.org/html/rfc7231#section-3.1.1.5): > > 'A sender that generates a message containing a payload body SHOULD > generate a Content-Type header field in that message unless the > intended media type of the enclosed representation is unknown to the > sender. If a Content-Type header field is not present, the recipient > MAY either assume a media type of "application/octet-stream=E2=80=9D > ([RFC2046]) or examine the data to determine its type.' > > > While Content-Type is recommend, noting that in the case of OSCORE we want > to encrypt the Content-Type for the other CoAP endpoint, so whatever media > type we would potentially include in the =E2=80=9COuter=E2=80=9D message w= ould only be a > dummy. Yes, but it signals to applications that "this payload is OSCORE-encrypted". > Furthermore, the destination endpoint would anyway first have to > process the OSCORE message to recreate the HTTP message before handing > over for HTTP processing. > As I read the text above it is possible to leave Content-Type out, but > would that be an issue in existing networks? I think unlabelled content is a bad form :-). > Who would be able to give > some advice her? > > If we decide to include a Content-Type header field, the main options are: > > - reuse of "application/cose=E2=80=9D defined in RFC 8152 (if appropriate) > - new media type e.g. =E2=80=9Capplication/oscore=E2=80=9D to be defined i= n this draft. Either of these work for me. > I added a placeholder (TBD) in the draft. > >> Nits: >> >> In Section 3.3: >> To enable retrieval of the right Recipient Context, the Recipient ID >> SHOULD be unique in the sets of all Recipient Contexts used by an >> >> Does this SHOULD need a bit more explaining (i.e. why it is not a MUST)? > If the Recipient ID is the same for different security contexts (i.e. when > different Master Secrets) this is not a security issue, but the recipient > may have to try multiple security contexts before finding the right (if > any). Therefore it is not mandatory but recommended. I added more > explanation on this. > > >> endpoint. The Client MAY provide a 'kid context' parameter (Section >> 5.1) to help the Server find the right context. > Were there any comment on this particular text, or is this snippet it just > a remnant from the quote in the previous comment? Just continuation of the previously quoted text. From nobody Mon Feb 19 09:15:58 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4EB126CD8 for ; Mon, 19 Feb 2018 09:15:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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_MED=-2.3, 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 (1024-bit key) header.d=ericsson.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 boy98ueu86T4 for ; Mon, 19 Feb 2018 09:15:56 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6EEC1243F6 for ; Mon, 19 Feb 2018 09:15:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519060554; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=gQbDwovCehimB823jY68hvbBMEG9fJAQRMe2J+LIt7A=; b=gPt++IvPQ4lTF41RQhMc7fuO205duVbjzgf6Vh3ZeVNxuxKjw9Yy/C8Bqt/0kM1p vvGlue+pDb4IAIFJGUBoUXHJBZPjG57JOBks8FGnSMGU0BMtP4sd0mqN5vIznJjE qfUNe09v9CFEg0yb+gPvL8Urb6MMgvRRgFDPSSy24mk=; X-AuditID: c1b4fb25-c03dc9c0000038f0-20-5a8b0649b6ff Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 51.5D.14576.9460B8A5; Mon, 19 Feb 2018 18:15:54 +0100 (CET) Received: from ESESSMB107.ericsson.se ([169.254.7.129]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0352.000; Mon, 19 Feb 2018 18:15:39 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Alexey Melnikov , "draft-ietf-core-object-security.authors@ietf.org" CC: "core@ietf.org WG" Thread-Topic: AD review of draft-ietf-core-object-security-08 Thread-Index: AQHTqAPh+m6SWmYgJ0qGWkdVgXnjGqOru9wA///3TQCAAEdpgA== Date: Mon, 19 Feb 2018 17:15:38 +0000 Message-ID: References: <5A8849F5.6070703@isode.com> <0f0f5e9e-245f-b0bd-cd1c-48b028b9cdfd@isode.com> In-Reply-To: <0f0f5e9e-245f-b0bd-cd1c-48b028b9cdfd@isode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="utf-8" Content-ID: <0DCA1905399A4A4B8046CC0EE353142A@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIIsWRmVeSWpSXmKPExsUyM2K7hK4XW3eUwb9aixmriyz2vV3PbLH5 2VdWB2aPJUt+MnmcajYMYIrisklJzcksSy3St0vgylh34g9jwRudiq1Nh5gaGG9odzFyckgI mEj87d3I3sXIxSEkcJhR4kLDBhYIZwmjxObp+5hBqtgEXCQeNDxiAkmICMxilJg2dwkrSIJZ QE3i0dJzLCC2sICNxJ0LL8HiIgK2EtNe3GKDsJ0kfjUuB4uzCKhKvLu9BSzOK2AhMW/2WzaI bV2MEnM+z2EHSXACNd9dshlsKKOAmMT3U2uYIJaJS9x6Mp8J4m4BiSV7zjND2KISLx//A1sg KqAnsbennQ0iriTxY8MloDkcQL2aEut36UOY1hIzLxpBTFSUmNL9kB3iHEGJkzOfsExgFJ+F ZNkshOZZCM2zkDTPQtK8gJF1FaNocWpxUm66kbFealFmcnFxfp5eXmrJJkZgxB3c8lt1B+Pl N46HGAU4GJV4eKf97ooSYk0sK67MPcQowcGsJMLrcwMoxJuSWFmVWpQfX1Sak1p8iFGag0VJ nHeOcHuUkEB6YklqdmpqQWoRTJaJg1OqgVGhP+m8p9XtZbnG57nTSwOrXxYJ/rDrkNriMWdD rXWg0hyu4LkLfe7wpdmdFHQtnRRil+rO+WRKVeDaC59Uvxp8fmUl3KLs9EPP9uNfydrVTw69 YljO3Pt+UxSjp//OjtXdU3n08mdVVGQ5m8rt3CC2u8nk45nQ3DXtIclmDzQkfd2sZu/ZrMRS nJFoqMVcVJwIAPwqeSO0AgAA Archived-At: Subject: Re: [core] AD review of draft-ietf-core-object-security-08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 17:15:57 -0000 SGkgQWxleGV5LA0KDQpUaGFua3MgZm9yIHF1aWNrIHJlc3BvbnNlLCBtb3JlIHJlcGxpZXMgYmVs b3cuDQoNCk9uIDIwMTgtMDItMTkgMTU6MDAsICJBbGV4ZXkgTWVsbmlrb3YiIDxhbGV4ZXkubWVs bmlrb3ZAaXNvZGUuY29tPiB3cm90ZToNCg0KPg0KPj4+IDQpIEluIFNlY3Rpb24gMTAuMTogdGhl IHJlZmVyZW5jZSB0byBbSS1ELmlldGYtY29yZS1lY2hvLXJlcXVlc3QtdGFnXQ0KPj4+IGxvb2tz IE5vcm1hdGl2ZSB0byBtZSwgbm90IEluZm9ybWF0aXZlLg0KPj4gW0dTXSBDb3JyZWN0LCBnb29k IGNhdGNoLiBIb3dldmVyLCBbSS1ELmlldGYtY29yZS1lY2hvLXJlcXVlc3QtdGFnXSAoaWYNCj4+ IGFwcHJvdmVkKSB1cGRhdGVzIFJGQyA3OTU5IChpLmUuIEJsb2Nrd2lzZSkgd2hpY2ggaXMgYWxy ZWFkeSBub3JtYXRpdmVseQ0KPj4gcmVmZXJlbmNlZCwgc28gd2UgZG9u4oCZdCBoYXZlIHRvIG1l bnRpb24gW0ktRC5pZXRmLWNvcmUtZWNoby1yZXF1ZXN0LXRhZ10NCj4+IGF0IGFsbCBpbiB0aGlz IGNvbnRleHQuIEkgcmVtb3ZlZCB0aGUgcmVmZXJlbmNlLg0KPg0KPkkgZG9uJ3QgdGhpbmsgdGhp cyB3b3JrcyB3aXRoIHJlZmVyZW5jZXMuIERvZXMgaW1wbGVtZW50aW5nIFJGQyA3OTU5DQo+d2l0 aG91dCBhbnkga25vd2xlZGdlIG9mIFtJLUQuaWV0Zi1jb3JlLWVjaG8tcmVxdWVzdC10YWddIGJl DQo+c2F0aXNmYWN0b3J5IHdpdGggT1NDT1JFPw0KDQpbR1NdIFRoZSByZWZlcmVuY2UgdG8gW0kt RC5pZXRmLWNvcmUtZWNoby1yZXF1ZXN0LXRhZ10gaW4gdGhpcyB0ZXh0DQphZGRyZXNzZWQgdGhl IHVzZSBvZiB0aGUgUmVxdWVzdC1UYWcgb3B0aW9uIHRvZ2V0aGVyIHdpdGggQmxvY2t3aXNlLg0K UmVxdWVzdC1UYWcgaXMgcHJpbWFyaWx5IGFkZHJlc3NpbmcgdGhlICJSZXF1ZXN0IEZyYWdtZW50 IFJlYXJyYW5nZW1lbnQNCkF0dGFja+KAnSBkZXNjcmliZWQgaW4NCmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1tYXR0c3Nvbi1jb3JlLWNvYXAtYWN0dWF0b3JzLTAzI3NlY3Rpb24t Mg0KLjUgDQpPU0NPUkUsIGFzIHdlbGwgYXMgRFRMUywgYXJlIHZ1bG5lcmFibGUgdG8gdGhpcyBh dHRhY2ssIHNvIGluIGdlbmVyYWwNCm5laXRoZXIgYXJlIOKAnHNhdGlzZmFjdG9yeeKAnSB3aXRo b3V0IGl0IGZvciB0aGVzZSB1c2UgY2FzZXMuDQoNCkhlbmNlIHRoZSByZWZlcmVuY2UgdG8gW0kt RC5pZXRmLWNvcmUtZWNoby1yZXF1ZXN0LXRhZ10gaW4gdGhpcyBzZWN0aW9uDQp3YXMgYXMgYSBz ZWN1cml0eSB1cGRhdGUgdG8gUkZDIDc5NTkgKGNvbXBhcmUgc2VjdGlvbiA0LjIuMy4yIHdoZXJl IHRoaXMNCmlzIGRlc2NyaWJlZCBpbiB0aGUgY29udGV4dCBvZiBJbm5lciBhcyB3ZWxsIGFzIE91 dGVyIG9wdGlvbnMpIGJ1dA0Kc3BlY2lmaWNhdGlvbi13aXNlIHRoZSBkZXBlbmRlbmNlIGlzIGJl dHdlZW4gdGhpcyBkcmFmdCBhbmQgUkZDNzk1OSwNCmluY2x1ZGluZyBhbnkgcG90ZW50aWFsIHVw ZGF0ZXMgb2YgdGhhdCBkcmFmdC4NCg0KDQpEb2VzIHRoYXQgbWFrZSBtb3JlIHNlbnNlPw0KDQoN Cg0KPg0KPj4+IDUpIEluIFNlY3Rpb24gMTAuMjogd2hpY2ggbWVkaWEgdHlwZSBpcyB1c2VkIGZv ciB0aGUgT1NDT1JFLWVuY3J5cHRlZA0KPj4+IHBheWxvYWQgdHJhbnNwb3J0ZWQgaW4gSFRUUD8N Cj4+Pg0KPj4gW0dTXSBHb29kIHF1ZXN0aW9uLCB0aGVyZSBhcmUgYSBmZXcgdGhpbmdzIHRvIG5v dGUgaGVyZS4gRmlyc3QsIHRoZSBDb0FQDQo+PiBvcHRpb24gQ29udGVudC1Gb3JtYXQgaXMgSW5u ZXIgc28gdGhlIENvQVAgcGF5bG9hZCBtZWRpYSB0eXBlIGlzDQo+PiBlbmNyeXB0ZWQuIFNlY29u ZCwgdGhlIE91dGVyIENvbnRlbnQtRm9ybWF0IG9wdGlvbiBpcyBub3QgcHJlc2VudCBpbg0KPj4g T1NDT1JFIHByb3RlY3RlZCBDb0FQIG1lc3NhZ2VzIChpbiB0aGUgaW50ZXJlc3Qgb2Ygc2F2aW5n IG1lc3NhZ2UNCj4+IG92ZXJoZWFkKS4gVGhpcmQsIHdoZW4gQ29BUC1tYXBwYWJsZSBIVFRQIGlz IHByb3RlY3RlZCB3aXRoIE9TQ09SRSwgdGhlDQo+PiBtZXNzYWdlIGlzIGZpcnN0IG1hcHBlZCB0 byBDb0FQIGFuZCB0aGVuIHByb2Nlc3NlZCB3aXRoIE9TQ09SRSwgc28gdGhlDQo+PiBtZWRpYSB0 eXBlIG9mIHRoZSBPU0NPUkUgZW5jcnlwdGVkIHBheWxvYWQgaXMgY2FycmllZCBpbiB0aGUgZW5j cnlwdGVkDQo+PiBDb250ZW50LUZvcm1hdCBvcHRpb24gYWxzbyBpbiB0aGUgY2FzZSBvZiBIVFRQ LiBIb3dldmVyLCB3ZSBtYXkgc3RpbGwNCj4+d2FudA0KPj4gdG8gaGF2ZSBhIENvbnRlbnQtVHlw ZSBoZWFkZXIgZmllbGQgaW4gdGhlIEhUVFAgbWVzc2FnZSB0cmFuc3BvcnRpbmcgdGhlDQo+PiBP U0NPUkUgbWVzc2FnZS4gV2FzIHRoaXMgd2hhdCB5b3Ugd2VyZSByZWZlcnJpbmcgdG8/DQo+WWVz LiBBcHBsaWNhdGlvbnMgb3IgcGx1Z2luIGZyZXF1ZW50bHkgZ2V0IGludm9rZWQgYmFzZWQgb24g bWVkaWEgdHlwZXMuDQo+U28gaWYgeW91IHdhbnQgdG8gYWxsb3cgZm9yIGRlY29kaW5nIG9mIE9T Q09SRSBwYXlsb2FkcyBpbiBhIHBsdWdpbiwgeW91DQo+c2hvdWxkIGRlZmluZSBhIG1lZGlhIHR5 cGUuDQo+DQo+PiBBY2NvcmRpbmcgdG8gUkZDIDcyMzENCj4+IChodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjNzIzMSNzZWN0aW9uLTMuMS4xLjUpOg0KPj4NCj4+ICdBIHNlbmRlciB0aGF0 IGdlbmVyYXRlcyBhIG1lc3NhZ2UgY29udGFpbmluZyBhIHBheWxvYWQgYm9keSBTSE9VTEQNCj4+ ICAgICBnZW5lcmF0ZSBhIENvbnRlbnQtVHlwZSBoZWFkZXIgZmllbGQgaW4gdGhhdCBtZXNzYWdl IHVubGVzcyB0aGUNCj4+ICAgICBpbnRlbmRlZCBtZWRpYSB0eXBlIG9mIHRoZSBlbmNsb3NlZCBy ZXByZXNlbnRhdGlvbiBpcyB1bmtub3duIHRvIHRoZQ0KPj4gICAgIHNlbmRlci4gIElmIGEgQ29u dGVudC1UeXBlIGhlYWRlciBmaWVsZCBpcyBub3QgcHJlc2VudCwgdGhlDQo+PnJlY2lwaWVudA0K Pj4gICAgIE1BWSBlaXRoZXIgYXNzdW1lIGEgbWVkaWEgdHlwZSBvZiAiYXBwbGljYXRpb24vb2N0 ZXQtc3RyZWFt4oCdDQo+PiAoW1JGQzIwNDZdKSBvciBleGFtaW5lIHRoZSBkYXRhIHRvIGRldGVy bWluZSBpdHMgdHlwZS4nDQo+Pg0KPj4NCj4+IFdoaWxlIENvbnRlbnQtVHlwZSBpcyByZWNvbW1l bmQsIG5vdGluZyB0aGF0IGluIHRoZSBjYXNlIG9mIE9TQ09SRSB3ZQ0KPj53YW50DQo+PiB0byBl bmNyeXB0IHRoZSBDb250ZW50LVR5cGUgZm9yIHRoZSBvdGhlciBDb0FQIGVuZHBvaW50LCBzbyB3 aGF0ZXZlcg0KPj5tZWRpYQ0KPj4gdHlwZSB3ZSB3b3VsZCBwb3RlbnRpYWxseSBpbmNsdWRlIGlu IHRoZSDigJxPdXRlcuKAnSBtZXNzYWdlIHdvdWxkIG9ubHkgYmUgYQ0KPj4gZHVtbXkuDQo+DQo+ WWVzLCBidXQgaXQgc2lnbmFscyB0byBhcHBsaWNhdGlvbnMgdGhhdCAidGhpcyBwYXlsb2FkIGlz DQo+T1NDT1JFLWVuY3J5cHRlZCIuDQo+DQo+PiAgIEZ1cnRoZXJtb3JlLCB0aGUgZGVzdGluYXRp b24gZW5kcG9pbnQgd291bGQgYW55d2F5IGZpcnN0IGhhdmUgdG8NCj4+IHByb2Nlc3MgdGhlIE9T Q09SRSBtZXNzYWdlIHRvIHJlY3JlYXRlIHRoZSBIVFRQIG1lc3NhZ2UgYmVmb3JlIGhhbmRpbmcN Cj4+IG92ZXIgZm9yIEhUVFAgcHJvY2Vzc2luZy4NCj4+IEFzIEkgcmVhZCB0aGUgdGV4dCBhYm92 ZSBpdCBpcyBwb3NzaWJsZSB0byBsZWF2ZSBDb250ZW50LVR5cGUgb3V0LCBidXQNCj4+IHdvdWxk IHRoYXQgYmUgYW4gaXNzdWUgaW4gZXhpc3RpbmcgbmV0d29ya3M/DQo+SSB0aGluayB1bmxhYmVs bGVkIGNvbnRlbnQgaXMgYSBiYWQgZm9ybSA6LSkuDQo+PiAgIFdobyB3b3VsZCBiZSBhYmxlIHRv IGdpdmUNCj4+IHNvbWUgYWR2aWNlIGhlcj8NCj4+DQo+PiBJZiB3ZSBkZWNpZGUgdG8gaW5jbHVk ZSBhIENvbnRlbnQtVHlwZSBoZWFkZXIgZmllbGQsIHRoZSBtYWluIG9wdGlvbnMNCj4+YXJlOg0K Pj4NCj4+IC0gcmV1c2Ugb2YgImFwcGxpY2F0aW9uL2Nvc2XigJ0gZGVmaW5lZCBpbiBSRkMgODE1 MiAoaWYgYXBwcm9wcmlhdGUpDQo+PiAtIG5ldyBtZWRpYSB0eXBlIGUuZy4g4oCcYXBwbGljYXRp b24vb3Njb3Jl4oCdIHRvIGJlIGRlZmluZWQgaW4gdGhpcyBkcmFmdC4NCj5FaXRoZXIgb2YgdGhl c2Ugd29yayBmb3IgbWUuDQoNCltHU10gT0ssIEnigJlsbCBtYWtlIGEgc2VwYXJhdGUgdGhyZWFk IG9uIHRoYXQuDQoNClRoYW5rcw0KR8O2cmFuDQoNCg== From nobody Mon Feb 19 09:36:10 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FCC8128959 for ; Mon, 19 Feb 2018 09:36:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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_MED=-2.3, 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 (1024-bit key) header.d=ericsson.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 firAy6IH-aaI for ; Mon, 19 Feb 2018 09:35:54 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B29361243F6 for ; Mon, 19 Feb 2018 09:35:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519061752; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=vYYFyFYF6w0eCSAotQJK/kIwVI7cgJtRwW1p/ddsynU=; b=DDCmGBhndKvn3J7OMYow/VEvpjv5blFeuyYHlvkvWUYE76whujXsOP89jhM1x/XK kMrZjwD+W/Qe8h3FU3OCxd0XAmfbF//GNL5RJNPZzcMNzC20M2iCxzJNlaReFa42 xmCxrE8Exn615a6QuI712np9c6cxGA464wLI9/zrKI0=; X-AuditID: c1b4fb25-c03dc9c0000038f0-3d-5a8b0af7964a Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id BD.20.14576.7FA0B8A5; Mon, 19 Feb 2018 18:35:52 +0100 (CET) Received: from ESESSMB107.ericsson.se ([169.254.7.129]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0352.000; Mon, 19 Feb 2018 18:35:29 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "core@ietf.org WG" CC: Alexey Melnikov , "draft-ietf-core-object-security.authors@ietf.org" Thread-Topic: Media type for OSCORE in HTTP (Was: AD review of draft-ietf-core-object-security-08) Thread-Index: AQHTqagJt6vNLBmjjUqxOVAMxqqEAA== Date: Mon, 19 Feb 2018 17:35:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZGbHdQPcHV3eUwdzNzBYzVhdZ7Hu7ntli 87OvrA7MHkuW/GTyONVsGMAUxWWTkpqTWZZapG+XwJWx6vQV5oJjShUts0+xNjBeUexi5OSQ EDCR+Hp9AWsXIxeHkMBhRonP5/YyQThLGCUe/1jBBFLFJuAi8aDhEZgtIqAm0TrpFRtIEbPA LEaJL71NzCAJYYF4iVn39jBDFKVInOj7CNWgJzFt2mxWEJtFQFXi3re/bCA2r4CFxNwDMxlB bEYBMYnvp9aA1TMLiEvcejKfCeI8AYkle84zQ9iiEi8f/wObIwo0c29POxtEXFFi59l2oBoO oF5NifW79CHGWEvs2neCFcJWlJjS/ZAdYq2gxMmZT1gmMIrOQrJtFkL3LCTds5B0z0LSvYCR dRWjaHFqcVJuupGxXmpRZnJxcX6eXl5qySZGYBQd3PJbdQfj5TeOhxgFOBiVeHin/e6KEmJN LCuuzD3EKMHBrCTC63MDKMSbklhZlVqUH19UmpNafIhRmoNFSZx3jnB7lJBAemJJanZqakFq EUyWiYNTqoGRka3Z6Eh6+vHFWsIuXJG7V0t1fmI/wnbbuP5xgMsPPqNdi5hSGuX7eL8KHPtQ /L+wXubBnexvZx2eNIj9MlyYa7Qy9frDXXl9njw6Uw4XeJx+ftsgLf7j7tP3lvEx7i0WcxYP PCaWs/1aTMFFzcXtN3wKMs1tFxy44X/kotyP9yYrOrpif85TYinOSDTUYi4qTgQAS516FZ4C AAA= Archived-At: Subject: [core] Media type for OSCORE in HTTP (Was: AD review of draft-ietf-core-object-security-08) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 17:36:01 -0000 QWxsLA0KDQpUaGUgQUQgcmV2aWV3IHBvaW50ZWQgYXQgdGhlIG9taXNzaW9uIG9mIG1lZGlhIHR5 cGUgdG8gdXNlIGluIHRoZSBoZWFkZXINCmZpZWxkIENvbnRlbnQtVHlwZSBvZiBhbiBIVFRQIG1l c3NhZ2UgY2FycnlpbmcgYW4gT1NDT1JFIGVuY3J5cHRlZCBtZXNzYWdlLg0KDQo+PiBJZiB3ZSBk ZWNpZGUgdG8gaW5jbHVkZSBhIENvbnRlbnQtVHlwZSBoZWFkZXIgZmllbGQsIHRoZSBtYWluIG9w dGlvbnMNCj4+YXJlOg0KPj4NCj4+IC0gcmV1c2Ugb2YgImFwcGxpY2F0aW9uL2Nvc2XigJ0gZGVm aW5lZCBpbiBSRkMgODE1MiAoaWYgYXBwcm9wcmlhdGUpDQo+PiAtIG5ldyBtZWRpYSB0eXBlIGUu Zy4g4oCcYXBwbGljYXRpb24vb3Njb3Jl4oCdIHRvIGJlIGRlZmluZWQgaW4gdGhpcyBkcmFmdC4N Cj4gRWl0aGVyIG9mIHRoZXNlIHdvcmsgZm9yIG1lLg0KDQoNCkRvZXMgYW55b25lIGhhdmUgYW4g c3Ryb25nIG9waW5pb24gaGVyZSAob3IgZGV2aWF0aW5nIG9waW5pb24gYWJvdXQgdGhlDQpuZWNl c3NpdHkgb2YgaGF2aW5nIHRoaXMgaGVhZGVyIGZpZWxkKT8NCg0KQlINCkfDtnJhbiANCg0KDQoN Ck9uIDIwMTgtMDItMTkgMTU6MDAsICJBbGV4ZXkgTWVsbmlrb3YiIDxhbGV4ZXkubWVsbmlrb3ZA aXNvZGUuY29tPiB3cm90ZToNCg0KPg0KPj4+IDUpIEluIFNlY3Rpb24gMTAuMjogd2hpY2ggbWVk aWEgdHlwZSBpcyB1c2VkIGZvciB0aGUgT1NDT1JFLWVuY3J5cHRlZA0KPj4+IHBheWxvYWQgdHJh bnNwb3J0ZWQgaW4gSFRUUD8NCj4+Pg0KPj4gW0dTXSBHb29kIHF1ZXN0aW9uLCB0aGVyZSBhcmUg YSBmZXcgdGhpbmdzIHRvIG5vdGUgaGVyZS4gRmlyc3QsIHRoZSBDb0FQDQo+PiBvcHRpb24gQ29u dGVudC1Gb3JtYXQgaXMgSW5uZXIgc28gdGhlIENvQVAgcGF5bG9hZCBtZWRpYSB0eXBlIGlzDQo+ PiBlbmNyeXB0ZWQuIFNlY29uZCwgdGhlIE91dGVyIENvbnRlbnQtRm9ybWF0IG9wdGlvbiBpcyBu b3QgcHJlc2VudCBpbg0KPj4gT1NDT1JFIHByb3RlY3RlZCBDb0FQIG1lc3NhZ2VzIChpbiB0aGUg aW50ZXJlc3Qgb2Ygc2F2aW5nIG1lc3NhZ2UNCj4+IG92ZXJoZWFkKS4gVGhpcmQsIHdoZW4gQ29B UC1tYXBwYWJsZSBIVFRQIGlzIHByb3RlY3RlZCB3aXRoIE9TQ09SRSwgdGhlDQo+PiBtZXNzYWdl IGlzIGZpcnN0IG1hcHBlZCB0byBDb0FQIGFuZCB0aGVuIHByb2Nlc3NlZCB3aXRoIE9TQ09SRSwg c28gdGhlDQo+PiBtZWRpYSB0eXBlIG9mIHRoZSBPU0NPUkUgZW5jcnlwdGVkIHBheWxvYWQgaXMg Y2FycmllZCBpbiB0aGUgZW5jcnlwdGVkDQo+PiBDb250ZW50LUZvcm1hdCBvcHRpb24gYWxzbyBp biB0aGUgY2FzZSBvZiBIVFRQLiBIb3dldmVyLCB3ZSBtYXkgc3RpbGwNCj4+d2FudA0KPj4gdG8g aGF2ZSBhIENvbnRlbnQtVHlwZSBoZWFkZXIgZmllbGQgaW4gdGhlIEhUVFAgbWVzc2FnZSB0cmFu c3BvcnRpbmcgdGhlDQo+PiBPU0NPUkUgbWVzc2FnZS4gV2FzIHRoaXMgd2hhdCB5b3Ugd2VyZSBy ZWZlcnJpbmcgdG8/DQo+WWVzLiBBcHBsaWNhdGlvbnMgb3IgcGx1Z2luIGZyZXF1ZW50bHkgZ2V0 IGludm9rZWQgYmFzZWQgb24gbWVkaWEgdHlwZXMuDQo+U28gaWYgeW91IHdhbnQgdG8gYWxsb3cg Zm9yIGRlY29kaW5nIG9mIE9TQ09SRSBwYXlsb2FkcyBpbiBhIHBsdWdpbiwgeW91DQo+c2hvdWxk IGRlZmluZSBhIG1lZGlhIHR5cGUuDQo+DQo+PiBBY2NvcmRpbmcgdG8gUkZDIDcyMzENCj4+ICho dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzIzMSNzZWN0aW9uLTMuMS4xLjUpOg0KPj4N Cj4+ICdBIHNlbmRlciB0aGF0IGdlbmVyYXRlcyBhIG1lc3NhZ2UgY29udGFpbmluZyBhIHBheWxv YWQgYm9keSBTSE9VTEQNCj4+ICAgICBnZW5lcmF0ZSBhIENvbnRlbnQtVHlwZSBoZWFkZXIgZmll bGQgaW4gdGhhdCBtZXNzYWdlIHVubGVzcyB0aGUNCj4+ICAgICBpbnRlbmRlZCBtZWRpYSB0eXBl IG9mIHRoZSBlbmNsb3NlZCByZXByZXNlbnRhdGlvbiBpcyB1bmtub3duIHRvIHRoZQ0KPj4gICAg IHNlbmRlci4gIElmIGEgQ29udGVudC1UeXBlIGhlYWRlciBmaWVsZCBpcyBub3QgcHJlc2VudCwg dGhlDQo+PnJlY2lwaWVudA0KPj4gICAgIE1BWSBlaXRoZXIgYXNzdW1lIGEgbWVkaWEgdHlwZSBv ZiAiYXBwbGljYXRpb24vb2N0ZXQtc3RyZWFt4oCdDQo+PiAoW1JGQzIwNDZdKSBvciBleGFtaW5l IHRoZSBkYXRhIHRvIGRldGVybWluZSBpdHMgdHlwZS4nDQo+Pg0KPj4NCj4+IFdoaWxlIENvbnRl bnQtVHlwZSBpcyByZWNvbW1lbmQsIG5vdGluZyB0aGF0IGluIHRoZSBjYXNlIG9mIE9TQ09SRSB3 ZQ0KPj53YW50DQo+PiB0byBlbmNyeXB0IHRoZSBDb250ZW50LVR5cGUgZm9yIHRoZSBvdGhlciBD b0FQIGVuZHBvaW50LCBzbyB3aGF0ZXZlcg0KPj5tZWRpYQ0KPj4gdHlwZSB3ZSB3b3VsZCBwb3Rl bnRpYWxseSBpbmNsdWRlIGluIHRoZSDigJxPdXRlcuKAnSBtZXNzYWdlIHdvdWxkIG9ubHkgYmUg YQ0KPj4gZHVtbXkuDQo+DQo+WWVzLCBidXQgaXQgc2lnbmFscyB0byBhcHBsaWNhdGlvbnMgdGhh dCAidGhpcyBwYXlsb2FkIGlzDQo+T1NDT1JFLWVuY3J5cHRlZCIuDQo+DQo+PiAgIEZ1cnRoZXJt b3JlLCB0aGUgZGVzdGluYXRpb24gZW5kcG9pbnQgd291bGQgYW55d2F5IGZpcnN0IGhhdmUgdG8N Cj4+IHByb2Nlc3MgdGhlIE9TQ09SRSBtZXNzYWdlIHRvIHJlY3JlYXRlIHRoZSBIVFRQIG1lc3Nh Z2UgYmVmb3JlIGhhbmRpbmcNCj4+IG92ZXIgZm9yIEhUVFAgcHJvY2Vzc2luZy4NCj4+IEFzIEkg cmVhZCB0aGUgdGV4dCBhYm92ZSBpdCBpcyBwb3NzaWJsZSB0byBsZWF2ZSBDb250ZW50LVR5cGUg b3V0LCBidXQNCj4+IHdvdWxkIHRoYXQgYmUgYW4gaXNzdWUgaW4gZXhpc3RpbmcgbmV0d29ya3M/ DQo+SSB0aGluayB1bmxhYmVsbGVkIGNvbnRlbnQgaXMgYSBiYWQgZm9ybSA6LSkuDQo+PiAgIFdo byB3b3VsZCBiZSBhYmxlIHRvIGdpdmUNCj4+IHNvbWUgYWR2aWNlIGhlcj8NCj4+DQo+PiBJZiB3 ZSBkZWNpZGUgdG8gaW5jbHVkZSBhIENvbnRlbnQtVHlwZSBoZWFkZXIgZmllbGQsIHRoZSBtYWlu IG9wdGlvbnMNCj4+YXJlOg0KPj4NCj4+IC0gcmV1c2Ugb2YgImFwcGxpY2F0aW9uL2Nvc2XigJ0g ZGVmaW5lZCBpbiBSRkMgODE1MiAoaWYgYXBwcm9wcmlhdGUpDQo+PiAtIG5ldyBtZWRpYSB0eXBl IGUuZy4g4oCcYXBwbGljYXRpb24vb3Njb3Jl4oCdIHRvIGJlIGRlZmluZWQgaW4gdGhpcyBkcmFm dC4NCj5FaXRoZXIgb2YgdGhlc2Ugd29yayBmb3IgbWUuDQoNCg== From nobody Mon Feb 19 11:00:23 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB30E127873; Mon, 19 Feb 2018 11:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no 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 AFsnydsD8RLt; Mon, 19 Feb 2018 11:00:17 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C3DB126DFB; Mon, 19 Feb 2018 11:00:16 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w1JJ0CKp002556; Mon, 19 Feb 2018 20:00:12 +0100 (CET) Received: from client-0191.vpn.uni-bremen.de (client-0191.vpn.uni-bremen.de [134.102.107.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3zlY3F0jMjzDWcD; Mon, 19 Feb 2018 20:00:08 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: Date: Mon, 19 Feb 2018 11:00:02 -0800 Cc: "core@ietf.org WG" , "draft-ietf-core-object-security.authors@ietf.org" X-Mao-Original-Outgoing-Id: 540759600.3806829-4900e9bfa61db65257f6d6d5c772fca3 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: =?utf-8?Q?G=C3=B6ran_Selander?= X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [core] Media type for OSCORE in HTTP (Was: AD review of draft-ietf-core-object-security-08) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 19:00:22 -0000 On Feb 19, 2018, at 09:35, G=C3=B6ran Selander = wrote: >=20 >>> - reuse of "application/cose=E2=80=9D defined in RFC 8152 (if = appropriate) >>> - new media type e.g. =E2=80=9Capplication/oscore=E2=80=9D to be = defined in this draft. >> Either of these work for me. >=20 >=20 > Does anyone have an strong opinion here (or deviating opinion about = the > necessity of having this header field)? Generally, REST bodies (as transferred in payloads in CoAP) need to have = a media type. OSCORE skirts around this for CoAP by having the Object-Security option = essentially supplant Content-Format. That is not great design. (It also isn=E2=80=99t a disaster.) (This works, as long as these are not in error responses, since = Content-Format does not have a default, see RFC 7252 Section 5.5.1.) For HTTP and its valiant ecosystem, there may be stronger reasons to = indicate a media type so existing implementations don=E2=80=99t feel = like they should try to help (*). application/cose is not useful because the OSCORE payload isn=E2=80=99t. So something like application/oscore should be registered (is there only = one of these?). Next question: Does this media type get a Content-Format value, too? Gr=C3=BC=C3=9Fe, Carsten (*) technical term: =E2=80=9Ctry to help=E2=80=9D =3D destroy a protocol = based on all the nicest intentions. From nobody Mon Feb 19 23:37:04 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15831126D74 for ; Mon, 19 Feb 2018 23:37:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=ericsson.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 r2m91q2DKLuy for ; Mon, 19 Feb 2018 23:37:02 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF7BB1243F3 for ; Mon, 19 Feb 2018 23:37:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519112218; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=52l/mK9VtZur2ytFF0MWbeTyylC3BoQi5us+6RfnSVo=; b=KLDEGMOUkC1rOtboKwBsHKsxU3eNj99fNccVPNmKDVkJlgx0dUKn5SvzfFFj8UW+ TYvEXbdCcQK1ROycvhbo1wE0lccnD/TUMT077yBS6i2dDjW12i8VpNyAg8Okd11V FSteU4k2Bt1Dlnls3EUx+nz8MhOgMNGRJrmK5YYJXOY=; X-AuditID: c1b4fb2d-4b1ff70000005540-d7-5a8bd01a1a62 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 95.8F.21824.A10DB8A5; Tue, 20 Feb 2018 08:36:58 +0100 (CET) Received: from ESESSMB107.ericsson.se ([169.254.7.129]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0352.000; Tue, 20 Feb 2018 08:36:58 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Carsten Bormann CC: "core@ietf.org WG" , "draft-ietf-core-object-security.authors@ietf.org" Thread-Topic: [core] Media type for OSCORE in HTTP (Was: AD review of draft-ietf-core-object-security-08) Thread-Index: AQHTqagJt6vNLBmjjUqxOVAMxqqEAKOsA50AgADkPoA= Date: Tue, 20 Feb 2018 07:36:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [83.251.191.108] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAIsWRmVeSWpSXmKPExsUyM2K7ma7Uhe4og3nXrSyOTLnLarHv7Xpm i83PvrI6MHssWfKTyWPaoswApigum5TUnMyy1CJ9uwSujHUNc5kLlilUTP7znLWBcY98FyMn h4SAicS3bTPZuxi5OIQEDjNKbGl6wAzhLGGUaNmziB2kik3AReJBwyMmEFtEQEniwsU1bCA2 s8BERom9ryS6GDk4hAWyJBp3GEGUZEsseNnICmFbSez68QbMZhFQldjzYjUTSDmvgIXEtSMG IGEhgUyJH6vawUo4Bawl1k27BjadUUBM4vupNUwQm8Qlbj2ZzwRxs4DEkj3nmSFsUYmXj/+B 9YoK6Ens7WlnAxkvAXRlzwYpEJNZQFNi/S59iCnWEu0TW5ghbEWJKd0Pwf7jFRCUODnzCcsE RvFZSJbNQuiehaR7FpLuWUi6FzCyrmIULU4tLs5NNzLWSy3KTC4uzs/Ty0st2cQIjLeDW37r 7mBc/drxEKMAB6MSD6/Uwe4oIdbEsuLK3EOMEhzMSiK8TkuBQrwpiZVVqUX58UWlOanFhxil OViUxHlPevJGCQmkJ5akZqemFqQWwWSZODilGhjX7pq0ROKYycvvIcsrzTSjDT+ueLjnx08+ y51Bwe8eW3lKRpzerZX48biV14oXGufePHf9Z6n3Z3f3JeE7l9XX6F/WXDN3r0zDztYcs5Yn MmJKwrxZ4afKCtK/T1Cb2uO9cuFL687GOGe1jAbvvT0L5kkrLfRqKOsIkS/MfLR9nllmvUnS rXwlluKMREMt5qLiRABK7i7UswIAAA== Archived-At: Subject: Re: [core] Media type for OSCORE in HTTP (Was: AD review of draft-ietf-core-object-security-08) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 07:37:03 -0000 SGkgQ2Fyc3RlbiwgDQoNClRoZSBpbnRlbnQgaXMgdG8gYWxsb3cgYSBmZXcgZGVmaW5lZCBvcGVy YXRpb25zIGluZGVwZW5kZW50IG9mIG1lZGlhIHR5cGUNCm9mIHBheWxvYWQgYmV0d2VlbiBPU0NP UkUgd3JhcHBpbmcgaW4gdGhlIHNlbmRpbmcgZW5kcG9pbnQgYW5kIE9TQ09SRQ0KdW53cmFwcGlu ZyBpbiB0aGUgcmVjaXBpZW50IGVuZHBvaW50LCBpbmNsdWRpbmc6IENvQVAgcHJveHkgb3BlcmF0 aW9ucywNCmJsb2Nrd2lzZSBmcmFnbWVudGF0aW9uIGFuZCByZWFkaW5nIGNsYXNzIEkgb3B0aW9u cy4gQW5kIHdpdGggdGhlIGFkZGl0aW9uDQpvZiBIVFRQIHByb2Nlc3NpbmcsIGFsc28gdGhlIG9w ZXJhdGlvbiBvZiBtYXBwaW5nIGJldHdlZW4gSFRUUCBhbmQgQ29BUC4NCkJlZm9yZSBPU0NPUkUg d3JhcHBpbmcgYW5kIGFmdGVyIE9TQ09SRSB1bndyYXBwaW5nIHRoZSBwcm9jZXNzaW5nIHNob3Vs ZA0KYmUgaGFuZGxlZCBieSB0aGUgbm9ybWFsIHRyYW5zZmVyIGxheWVyLiBTbywgYSBzcGVjaWFs IG1lZGlhIHR5cGUgbGlrZQ0KJ2FwcGxpY2F0aW9uL29zY29yZScga2VlcGluZyDigJxoZWxwZnVs 4oCdIEhUVFAgcHJvY2Vzc2luZyBhd2F5IHNlZW1zIHRvIGJlDQpyaWdodC4gQXBhcnQgZnJvbSB0 aGF0IEkgZG9u4oCZdCBzZWUgYSByZWFzb24gdG8gbWFrZSBhbnkgc3BlY2lhbCB1c2Ugb2YNCkNv bnRlbnQtVHlwZS9Db250ZW50LUZvcm1hdC4gQnV0IG1heWJlIEnigJltIG1pc3Npbmcgc29tZXRo aW5nPw0KDQpBZGRpdGlvbmFsIGNvbW1lbnRzIGlubGluZS4NCg0KDQpPbiAyMDE4LTAyLTE5IDIw OjAwLCAiQ2Fyc3RlbiBCb3JtYW5uIiA8Y2Fib0B0emkub3JnPiB3cm90ZToNCg0KPk9uIEZlYiAx OSwgMjAxOCwgYXQgMDk6MzUsIEfDtnJhbiBTZWxhbmRlciA8Z29yYW4uc2VsYW5kZXJAZXJpY3Nz b24uY29tPg0KPndyb3RlOg0KPj4gDQo+Pj4+IC0gcmV1c2Ugb2YgImFwcGxpY2F0aW9uL2Nvc2Xi gJ0gZGVmaW5lZCBpbiBSRkMgODE1MiAoaWYgYXBwcm9wcmlhdGUpDQo+Pj4+IC0gbmV3IG1lZGlh IHR5cGUgZS5nLiDigJxhcHBsaWNhdGlvbi9vc2NvcmXigJ0gdG8gYmUgZGVmaW5lZCBpbiB0aGlz DQo+Pj4+ZHJhZnQuDQo+Pj4gRWl0aGVyIG9mIHRoZXNlIHdvcmsgZm9yIG1lLg0KPj4gDQo+PiAN Cj4+IERvZXMgYW55b25lIGhhdmUgYW4gc3Ryb25nIG9waW5pb24gaGVyZSAob3IgZGV2aWF0aW5n IG9waW5pb24gYWJvdXQgdGhlDQo+PiBuZWNlc3NpdHkgb2YgaGF2aW5nIHRoaXMgaGVhZGVyIGZp ZWxkKT8NCj4NCj5HZW5lcmFsbHksIFJFU1QgYm9kaWVzIChhcyB0cmFuc2ZlcnJlZCBpbiBwYXls b2FkcyBpbiBDb0FQKSBuZWVkIHRvIGhhdmUNCj5hIG1lZGlhIHR5cGUuDQo+DQo+T1NDT1JFIHNr aXJ0cyBhcm91bmQgdGhpcyBmb3IgQ29BUCBieSBoYXZpbmcgdGhlIE9iamVjdC1TZWN1cml0eSBv cHRpb24NCj5lc3NlbnRpYWxseSBzdXBwbGFudCBDb250ZW50LUZvcm1hdC4NCj5UaGF0IGlzIG5v dCBncmVhdCBkZXNpZ24uICAoSXQgYWxzbyBpc27igJl0IGEgZGlzYXN0ZXIuKQ0KDQpbR1NdIFRo ZSBvdGhlciBhbHRlcm5hdGl2ZXMgYWRkIG1vcmUgbWVzc2FnZSBvdmVyaGVhZC4NCg0KDQo+KFRo aXMgd29ya3MsIGFzIGxvbmcgYXMgdGhlc2UgYXJlIG5vdCBpbiBlcnJvciByZXNwb25zZXMsIHNp bmNlDQo+Q29udGVudC1Gb3JtYXQgZG9lcyBub3QgaGF2ZSBhIGRlZmF1bHQsIHNlZSBSRkMgNzI1 MiBTZWN0aW9uIDUuNS4xLikNCg0KW0dTXSBFcnJvciByZXNwb25zZXMgcHJvdGVjdGVkIGJ5IE9T Q09SRSBhcmUgbm90IHZpc2libGUgYXMgZXJyb3IgbWVzc2FnZXMuDQoNCj4NCj5Gb3IgSFRUUCBh bmQgaXRzIHZhbGlhbnQgZWNvc3lzdGVtLCB0aGVyZSBtYXkgYmUgc3Ryb25nZXIgcmVhc29ucyB0 bw0KPmluZGljYXRlIGEgbWVkaWEgdHlwZSBzbyBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgZG9u 4oCZdCBmZWVsIGxpa2UgdGhleQ0KPnNob3VsZCB0cnkgdG8gaGVscCAoKikuDQo+DQo+YXBwbGlj YXRpb24vY29zZSBpcyBub3QgdXNlZnVsIGJlY2F1c2UgdGhlIE9TQ09SRSBwYXlsb2FkIGlzbuKA mXQuDQoNCltHU10gVGhlcmUgd2FzIGEgcmVxdWVzdCB0byB1c2Ugb25lIG9mIHRoZSByZXNlcnZl ZCBmbGFnIGJpdHMgdG8gaW5kaWNhdGUNCmEgdmFyaWFudCB3aGVuIHRoZSBPU0NPUkUgcGF5bG9h ZCBpcyBhIENPU0Ugb2JqZWN0IGluc3RlYWQgb2YgYSBjb21wcmVzc2VkDQpDT1NFLCBidXQgaW4g Z2VuZXJhbCB0aGF0IHdvdWxkIG5vdCBiZSB0aGUgY2FzZSwgYW5kIHRoZSBkaXNjdXNzaW9uIG9m IHRoZQ0KcmVzZXJ2ZWQgZmxhZyBiaXRzIHdhcyBkZWZlcnJlZCB0byBHcm91cCBPU0NPUkUuDQoN Cj4NCj5TbyBzb21ldGhpbmcgbGlrZSBhcHBsaWNhdGlvbi9vc2NvcmUgc2hvdWxkIGJlIHJlZ2lz dGVyZWQNCg0KW0dTXSBPSy4gVW5sZXNzIHRoZXJlIGFyZSBvdGhlciBjb21tZW50cyBJIHdpbGwg YWRkIHRoaXMgaW4gYSBuZXcNCnN1YnNlY3Rpb24gaW4gdGhlIElBTkEgY29uc2lkZXJhdGlvbnMg YW5kIHRoZSBhZGRpdGlvbmFsIEhUVFAtQ29BUCBtYXBwaW5nDQpydWxlLg0KDQoNCj4oaXMgdGhl cmUgb25seSBvbmUgb2YgdGhlc2U/KS4NCiANCltHU10gQXMgc3RhdGVkIGFib3ZlLCBJIGRvbuKA mXQgc2VlIHRoZSBuZWVkIHRvIG1ha2UgYW55IG90aGVyIGRpc3RpbmN0aW9uDQpiYXNlZCBvbiBt ZWRpYSB0eXBlLg0KDQo+DQo+TmV4dCBxdWVzdGlvbjogRG9lcyB0aGlzIG1lZGlhIHR5cGUgZ2V0 IGEgQ29udGVudC1Gb3JtYXQgdmFsdWUsIHRvbz8NCg0KW0dTXSBTYW1lIGFuc3dlciBoZXJlLCBJ IGRvbuKAmXQgc2VlIHRoZSBuZWVkLiBCdXQgaWYgc29tZW9uZSBjYW4gZ2l2ZSBhDQpnb29kIHJl YXNvbiB3ZSBjYW4gZGVmaW5lIHRoYXQuDQoNCkfDtnJhbg0KDQoNCj4NCj5HcsO8w59lLCBDYXJz dGVuDQo+DQo+KCopIHRlY2huaWNhbCB0ZXJtOiDigJx0cnkgdG8gaGVscOKAnSA9IGRlc3Ryb3kg YSBwcm90b2NvbCBiYXNlZCBvbiBhbGwgdGhlDQo+bmljZXN0IGludGVudGlvbnMuDQo+DQoNCg== From nobody Tue Feb 20 23:47:50 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0103712E882 for ; Tue, 20 Feb 2018 23:47:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 8jIl8rlt_rkw for ; Tue, 20 Feb 2018 23:47:48 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2128212E880 for ; Tue, 20 Feb 2018 23:47:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519199264; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=IXQDstRkoy2x5qalG2R/qHduqvdbkLNaEpNSXb73gPY=; b=LkIvTOuP34p+IrXiJdlqHjJW+FXSuLjEbmzphfF///aCox3mwlMkl5L7B2xnYwLx XgtC/SYMdPD6nmOagUPIcVhNGKAkFH5ic7/Ve2jv5y6tUA9l9cldUziWrTb+RQy8 n2lRgovRbSmOqdEyOMZl0qG8RuAmsu16uLBcCPxB2uc=; X-AuditID: c1b4fb2d-87c029c000005540-21-5a8d242099b6 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 12.97.21824.0242D8A5; Wed, 21 Feb 2018 08:47:44 +0100 (CET) Received: from ESESSMB107.ericsson.se ([169.254.7.129]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0352.000; Wed, 21 Feb 2018 08:47:44 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Carsten Bormann CC: "core@ietf.org WG" , "draft-ietf-core-object-security.authors@ietf.org" Thread-Topic: [core] Media type for OSCORE in HTTP (Was: AD review of draft-ietf-core-object-security-08) Thread-Index: AQHTqagJt6vNLBmjjUqxOVAMxqqEAKOsA50AgADkPoCAAZVagA== Date: Wed, 21 Feb 2018 07:47:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [83.251.191.108] Content-Type: text/plain; charset="utf-8" Content-ID: <15355749ADDDB0459542D7B50445B9DE@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIIsWRmVeSWpSXmKPExsUyM2K7ma6CSm+UwbdNGhZHptxltdj3dj2z xeZnX1kdmD2WLPnJ5DFtUWYAUxSXTUpqTmZZapG+XQJXxu4jZxkL7ulXfGmay9TAeECvi5GT Q0LAROLN0susXYxcHEIChxklFs9dzg6SEBJYwijxbTIPiM0m4CLxoOERE4gtIqAkceHiGjYQ m1lgIqPE3lcSXYwcHMICWRKNO4wgSrIlFrxsZIWwnSSWXtsDNpJFQFVi8tpGsDG8AhYSXV+m M0PsncEocXb1E0aQBKeApcTb/gYwm1FATOL7qTVMELvEJW49mc8EcbSAxJI955khbFGJl4// gS0TFdCT2NvTzgZyjwTQnT0bpEBMZgFNifW79CGmWEscuHmXHcJWlJjS/ZAd4hxBiZMzn7BM YBSfhWTZLITuWUi6ZyHpnoWkewEj6ypG0eLU4uLcdCNjvdSizOTi4vw8vbzUkk2MwIg7uOW3 7g7G1a8dDzEKcDAq8fCeftETJcSaWFZcmXuIUYKDWUmEt1KoN0qINyWxsiq1KD++qDQntfgQ ozQHi5I470lP3ighgfTEktTs1NSC1CKYLBMHp1QDo8Pnb0zKixZItx9QXH7/n0aCjanCIv6D KyYXaLQp1vrkX3yoLbRZJef1RBXFsr6DKadlXwRIMydaLV04h3+t/Zd10Ts2bnx5+2nTwc0y 85L3XPk15YhQUF+ixKqLtrx5/KnF9yymv3+5/uvC7akH3OJsv5Yv2yFiy/Au2Nzm3wulhzM0 YpVbupRYijMSDbWYi4oTAQAmhn+0AgAA Archived-At: Subject: Re: [core] Media type for OSCORE in HTTP (Was: AD review of draft-ietf-core-object-security-08) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 07:47:49 -0000 UmVzcG9uZGluZyB0byBteSBvd24gbWFpbCAtLSBnb3QgYW4gb2ZmLWxpc3QgY29tbWVudCB0aGF0 IHRoZSByZWFzb25pbmcNCndhcyBoYXJkIHRvIGZvbGxvdyBzbyBoZXJlIGlzIGFub3RoZXIgdHJ5 Lg0KDQpXaGVuIGFuIE9TQ09SRSBtZXNzYWdlIGlzIHNlbnQgd2l0aCBDb0FQIHRoZSBDb250ZW50 LUZvcm1hdCBvcHRpb24gaXMNCnJlZHVuZGFudCAoaS5lLiB0aGUgQ29udGVudC1Gb3JtYXQgb2Yg dGhlIENvQVAgbWVzc2FnZSB2aXNpYmxlIG9uIHRoZQ0Kd2lyZSwgbm90IHRoZSBDb250ZW50LUZv cm1hdCBvZiB0aGUgb3JpZ2luYWwgdW5wcm90ZWN0ZWQgQ29BUCBtZXNzYWdlDQp3aGljaCBpcyBl bmNyeXB0ZWQgYW5kIHBhcnQgb2YgdGhlIGNpcGhlcnRleHQgb2YgdGhlIENPU0UgbWVzc2FnZSku IFRoZQ0KT2JqZWN0LVNlY3VyaXR5IG9wdGlvbiwgY29udGFpbmluZyB0aGUgY29tcHJlc3NlZCBD T1NFIGhlYWRlcnMsIGhhcyBhbGwNCmluZm9ybWF0aW9uIG5lY2Vzc2FyeSB0byBwcm9jZXNzIHRo ZSBDT1NFIG9iamVjdCBpbiBhZGRpdGlvbiB0byBzaWduYWxpbmcNCuKAnHRoaXMgaXMgYW4gT1ND T1JFIG1lc3NhZ2XigJ0uIFNpbmNlIHRoZXJlIGlzIG5vIGRlZmF1bHQgZm9yIENvbnRlbnQtRm9y bWF0DQp0aGlzIHNob3VsZCBiZSBzdWZmaWNpZW50IGZvciBDb0FQLiBJbnRlcm1lZGlhcnkgbm9k ZXMgdGhhdCBwZXJmb3JtDQpsZWdpdGltYXRlIHByb3h5IG9wZXJhdGlvbnMgb24gYW4gT1NDT1JF IG1lc3NhZ2UgZWl0aGVyIHVuZGVyc3RhbmRzDQpPU0NPUkUsIGluIHdoaWNoIGNhc2UgdGhleSBj YW4ga25vdyB3aGVyZSB0byBmaW5kIHRoZSBuZWNlc3NhcnkNCmluZm9ybWF0aW9uIGluIHRoZSBt ZXNzYWdlIChlLmcuIHJlYWRpbmcgY2xhc3MgSSBvcHRpb25zLCBtYXBwaW5nIGJldHdlZW4NCkhU VFAgYW5kIENvQVApLCBvciBpZiB0aGV5IGRvbuKAmXQgdW5kZXJzdGFuZCBPU0NPUkUgY2FuIHBy b2Nlc3MgdGhlIG1lc3NhZ2UNCmFzIGFuIG9yZGluYXJ5IENvQVAgbWVzc2FnZSAoZS5nLiBDb0FQ IHByb3h5IGZvcndhcmRpbmcsIGJsb2Nrd2lzZQ0KZnJhZ21lbnRhdGlvbikuDQoNCldoZW4gYW4g T1NDT1JFIG1lc3NhZ2UgaXMgc2VudCB3aXRoIEhUVFAgd2UgbmVlZCB0byBleHBsaWNpdGx5IHNp Z25hbCB0aGF0DQp0aGlzIGlzIE9TQ09SRSBmb3Igd2hpY2ggdGhlIG5ldyBtZWRpYSB0eXBlICdh cHBsaWNhdGlvbi9vc2NvcmUnIGlzDQpkZWZpbmVkLiANCg0KSG9wZSB0aGF0IG1ha2VzIG1vcmUg c2Vuc2UuDQoNCkfDtnJhbg0KDQoNCk9uIDIwMTgtMDItMjAgMDg6MzYsICJHw7ZyYW4gU2VsYW5k ZXIiIDxnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb20+IHdyb3RlOg0KDQo+SGkgQ2Fyc3Rlbiwg DQo+DQo+VGhlIGludGVudCBpcyB0byBhbGxvdyBhIGZldyBkZWZpbmVkIG9wZXJhdGlvbnMgaW5k ZXBlbmRlbnQgb2YgbWVkaWEgdHlwZQ0KPm9mIHBheWxvYWQgYmV0d2VlbiBPU0NPUkUgd3JhcHBp bmcgaW4gdGhlIHNlbmRpbmcgZW5kcG9pbnQgYW5kIE9TQ09SRQ0KPnVud3JhcHBpbmcgaW4gdGhl IHJlY2lwaWVudCBlbmRwb2ludCwgaW5jbHVkaW5nOiBDb0FQIHByb3h5IG9wZXJhdGlvbnMsDQo+ YmxvY2t3aXNlIGZyYWdtZW50YXRpb24gYW5kIHJlYWRpbmcgY2xhc3MgSSBvcHRpb25zLiBBbmQg d2l0aCB0aGUgYWRkaXRpb24NCj5vZiBIVFRQIHByb2Nlc3NpbmcsIGFsc28gdGhlIG9wZXJhdGlv biBvZiBtYXBwaW5nIGJldHdlZW4gSFRUUCBhbmQgQ29BUC4NCj5CZWZvcmUgT1NDT1JFIHdyYXBw aW5nIGFuZCBhZnRlciBPU0NPUkUgdW53cmFwcGluZyB0aGUgcHJvY2Vzc2luZyBzaG91bGQNCj5i ZSBoYW5kbGVkIGJ5IHRoZSBub3JtYWwgdHJhbnNmZXIgbGF5ZXIuIFNvLCBhIHNwZWNpYWwgbWVk aWEgdHlwZSBsaWtlDQo+J2FwcGxpY2F0aW9uL29zY29yZScga2VlcGluZyDigJxoZWxwZnVs4oCd IEhUVFAgcHJvY2Vzc2luZyBhd2F5IHNlZW1zIHRvIGJlDQo+cmlnaHQuIEFwYXJ0IGZyb20gdGhh dCBJIGRvbuKAmXQgc2VlIGEgcmVhc29uIHRvIG1ha2UgYW55IHNwZWNpYWwgdXNlIG9mDQo+Q29u dGVudC1UeXBlL0NvbnRlbnQtRm9ybWF0LiBCdXQgbWF5YmUgSeKAmW0gbWlzc2luZyBzb21ldGhp bmc/DQo+DQo+QWRkaXRpb25hbCBjb21tZW50cyBpbmxpbmUuDQo+DQo+DQo+T24gMjAxOC0wMi0x OSAyMDowMCwgIkNhcnN0ZW4gQm9ybWFubiIgPGNhYm9AdHppLm9yZz4gd3JvdGU6DQo+DQo+Pk9u IEZlYiAxOSwgMjAxOCwgYXQgMDk6MzUsIEfDtnJhbiBTZWxhbmRlciA8Z29yYW4uc2VsYW5kZXJA ZXJpY3Nzb24uY29tPg0KPj53cm90ZToNCj4+PiANCj4+Pj4+IC0gcmV1c2Ugb2YgImFwcGxpY2F0 aW9uL2Nvc2XigJ0gZGVmaW5lZCBpbiBSRkMgODE1MiAoaWYgYXBwcm9wcmlhdGUpDQo+Pj4+PiAt IG5ldyBtZWRpYSB0eXBlIGUuZy4g4oCcYXBwbGljYXRpb24vb3Njb3Jl4oCdIHRvIGJlIGRlZmlu ZWQgaW4gdGhpcw0KPj4+Pj5kcmFmdC4NCj4+Pj4gRWl0aGVyIG9mIHRoZXNlIHdvcmsgZm9yIG1l Lg0KPj4+IA0KPj4+IA0KPj4+IERvZXMgYW55b25lIGhhdmUgYW4gc3Ryb25nIG9waW5pb24gaGVy ZSAob3IgZGV2aWF0aW5nIG9waW5pb24gYWJvdXQgdGhlDQo+Pj4gbmVjZXNzaXR5IG9mIGhhdmlu ZyB0aGlzIGhlYWRlciBmaWVsZCk/DQo+Pg0KPj5HZW5lcmFsbHksIFJFU1QgYm9kaWVzIChhcyB0 cmFuc2ZlcnJlZCBpbiBwYXlsb2FkcyBpbiBDb0FQKSBuZWVkIHRvIGhhdmUNCj4+YSBtZWRpYSB0 eXBlLg0KPj4NCj4+T1NDT1JFIHNraXJ0cyBhcm91bmQgdGhpcyBmb3IgQ29BUCBieSBoYXZpbmcg dGhlIE9iamVjdC1TZWN1cml0eSBvcHRpb24NCj4+ZXNzZW50aWFsbHkgc3VwcGxhbnQgQ29udGVu dC1Gb3JtYXQuDQo+PlRoYXQgaXMgbm90IGdyZWF0IGRlc2lnbi4gIChJdCBhbHNvIGlzbuKAmXQg YSBkaXNhc3Rlci4pDQo+DQo+W0dTXSBUaGUgb3RoZXIgYWx0ZXJuYXRpdmVzIGFkZCBtb3JlIG1l c3NhZ2Ugb3ZlcmhlYWQuDQo+DQo+DQo+PihUaGlzIHdvcmtzLCBhcyBsb25nIGFzIHRoZXNlIGFy ZSBub3QgaW4gZXJyb3IgcmVzcG9uc2VzLCBzaW5jZQ0KPj5Db250ZW50LUZvcm1hdCBkb2VzIG5v dCBoYXZlIGEgZGVmYXVsdCwgc2VlIFJGQyA3MjUyIFNlY3Rpb24gNS41LjEuKQ0KPg0KPltHU10g RXJyb3IgcmVzcG9uc2VzIHByb3RlY3RlZCBieSBPU0NPUkUgYXJlIG5vdCB2aXNpYmxlIGFzIGVy cm9yDQo+bWVzc2FnZXMuDQo+DQo+Pg0KPj5Gb3IgSFRUUCBhbmQgaXRzIHZhbGlhbnQgZWNvc3lz dGVtLCB0aGVyZSBtYXkgYmUgc3Ryb25nZXIgcmVhc29ucyB0bw0KPj5pbmRpY2F0ZSBhIG1lZGlh IHR5cGUgc28gZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIGRvbuKAmXQgZmVlbCBsaWtlIHRoZXkN Cj4+c2hvdWxkIHRyeSB0byBoZWxwICgqKS4NCj4+DQo+PmFwcGxpY2F0aW9uL2Nvc2UgaXMgbm90 IHVzZWZ1bCBiZWNhdXNlIHRoZSBPU0NPUkUgcGF5bG9hZCBpc27igJl0Lg0KPg0KPltHU10gVGhl cmUgd2FzIGEgcmVxdWVzdCB0byB1c2Ugb25lIG9mIHRoZSByZXNlcnZlZCBmbGFnIGJpdHMgdG8g aW5kaWNhdGUNCj5hIHZhcmlhbnQgd2hlbiB0aGUgT1NDT1JFIHBheWxvYWQgaXMgYSBDT1NFIG9i amVjdCBpbnN0ZWFkIG9mIGEgY29tcHJlc3NlZA0KPkNPU0UsIGJ1dCBpbiBnZW5lcmFsIHRoYXQg d291bGQgbm90IGJlIHRoZSBjYXNlLCBhbmQgdGhlIGRpc2N1c3Npb24gb2YgdGhlDQo+cmVzZXJ2 ZWQgZmxhZyBiaXRzIHdhcyBkZWZlcnJlZCB0byBHcm91cCBPU0NPUkUuDQo+DQo+Pg0KPj5TbyBz b21ldGhpbmcgbGlrZSBhcHBsaWNhdGlvbi9vc2NvcmUgc2hvdWxkIGJlIHJlZ2lzdGVyZWQNCj4N Cj5bR1NdIE9LLiBVbmxlc3MgdGhlcmUgYXJlIG90aGVyIGNvbW1lbnRzIEkgd2lsbCBhZGQgdGhp cyBpbiBhIG5ldw0KPnN1YnNlY3Rpb24gaW4gdGhlIElBTkEgY29uc2lkZXJhdGlvbnMgYW5kIHRo ZSBhZGRpdGlvbmFsIEhUVFAtQ29BUCBtYXBwaW5nDQo+cnVsZS4NCj4NCj4NCj4+KGlzIHRoZXJl IG9ubHkgb25lIG9mIHRoZXNlPykuDQo+IA0KPltHU10gQXMgc3RhdGVkIGFib3ZlLCBJIGRvbuKA mXQgc2VlIHRoZSBuZWVkIHRvIG1ha2UgYW55IG90aGVyIGRpc3RpbmN0aW9uDQo+YmFzZWQgb24g bWVkaWEgdHlwZS4NCj4NCj4+DQo+Pk5leHQgcXVlc3Rpb246IERvZXMgdGhpcyBtZWRpYSB0eXBl IGdldCBhIENvbnRlbnQtRm9ybWF0IHZhbHVlLCB0b28/DQo+DQo+W0dTXSBTYW1lIGFuc3dlciBo ZXJlLCBJIGRvbuKAmXQgc2VlIHRoZSBuZWVkLiBCdXQgaWYgc29tZW9uZSBjYW4gZ2l2ZSBhDQo+ Z29vZCByZWFzb24gd2UgY2FuIGRlZmluZSB0aGF0Lg0KPg0KPkfDtnJhbg0KPg0KPg0KPj4NCj4+ R3LDvMOfZSwgQ2Fyc3Rlbg0KPj4NCj4+KCopIHRlY2huaWNhbCB0ZXJtOiDigJx0cnkgdG8gaGVs cOKAnSA9IGRlc3Ryb3kgYSBwcm90b2NvbCBiYXNlZCBvbiBhbGwgdGhlDQo+Pm5pY2VzdCBpbnRl bnRpb25zLg0KPj4NCj4NCg0K From nobody Wed Feb 21 11:17:29 2018 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 91DC112D965; Wed, 21 Feb 2018 11:17:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151924064755.21154.2052748339211725337@ietfa.amsl.com> Date: Wed, 21 Feb 2018 11:17:27 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-cocoa-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 19:17:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : CoAP Simple Congestion Control/Advanced Authors : Carsten Bormann August Betzler Carles Gomez Ilker Demirkol Filename : draft-ietf-core-cocoa-03.txt Pages : 18 Date : 2018-02-21 Abstract: CoAP, the Constrained Application Protocol, needs to be implemented in such a way that it does not cause persistent congestion on the network it uses. The CoRE CoAP specification defines basic behavior that exhibits low risk of congestion with minimal implementation requirements. It also leaves room for combining the base specification with advanced congestion control mechanisms with higher performance. This specification defines more advanced, but still simple CoRE Congestion Control mechanisms, called CoCoA. The core of these mechanisms is a Retransmission TimeOut (RTO) algorithm that makes use of Round-Trip Time (RTT) estimates, in contrast with how the RTO is determined as per the base CoAP specification (RFC 7252). The mechanisms defined in this document have relatively low complexity, yet they improve the default CoAP RTO algorithm. The design of the mechanisms in this specification has made use of input from simulations and experiments in real networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-cocoa/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-cocoa-03 https://datatracker.ietf.org/doc/html/draft-ietf-core-cocoa-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-cocoa-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 21 11:21:39 2018 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 34B7F12DA01; Wed, 21 Feb 2018 11:21:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Scott Bradner To: Cc: ietf@ietf.org, core@ietf.org, draft-ietf-core-cocoa.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151924088919.28302.2725971304170450273@ietfa.amsl.com> Date: Wed, 21 Feb 2018 11:21:29 -0800 Archived-At: Subject: [core] Opsdir telechat review of draft-ietf-core-cocoa-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 19:21:29 -0000 Reviewer: Scott Bradner Review result: Serious Issues I have not reviewed this document in any detail but since it makes no reference to RFC 5033 (Specifying New Congestion Control Algorithms) I consider it to be fatally incomplete RFC 5033 is a BCP which in my opinion must (MUST?) be followed in any document that purports to define a new congestion protocol, even at the informational level. From nobody Wed Feb 21 14:23:22 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2118312DA69; Wed, 21 Feb 2018 14:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no 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 wYyQKM9uklVu; Wed, 21 Feb 2018 14:23:19 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C9F112DA68; Wed, 21 Feb 2018 14:23:18 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w1LMNEjp020788; Wed, 21 Feb 2018 23:23:14 +0100 (CET) Received: from client-0108.vpn.uni-bremen.de (client-0108.vpn.uni-bremen.de [134.102.107.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3zmsSc4SRRzDX9G; Wed, 21 Feb 2018 23:23:12 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: <151544955659.9620.8608063613527533195@ietfa.amsl.com> Date: Wed, 21 Feb 2018 14:23:10 -0800 Cc: tsv-art@ietf.org, IETF discussion list , core@ietf.org, draft-ietf-core-cocoa.all@ietf.org X-Mao-Original-Outgoing-Id: 540944589.003582-ab952b28ca5cc3c8e4a3820bedc320be Content-Transfer-Encoding: quoted-printable Message-Id: <3D867C10-CBD6-4A8B-8149-5F91A75C57A5@tzi.org> References: <151544955659.9620.8608063613527533195@ietfa.amsl.com> To: Wesley Eddy X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [core] Tsvart early review of draft-ietf-core-cocoa-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 22:23:21 -0000 Hi Wesley, Thank you for this thorough review, and apologies for the high RTT of = this email. We have prepared https://tools.ietf.org/html/draft-ietf-core-cocoa-03 with some reactions to your (and Mirja=E2=80=99s) comments; diff is in https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-cocoa-03.txt= > The terminology "RTO estimate" used throughout the document is = confusing to me. > The RTO is a solid value, not estimated, and is computed from = estimates of the > RTT and RTT variation. You could talk about estimating the "optimal" = RTO value > (for some definition of optimal), but I don't think that's the case = here.=20 > Similarly section 4.2 is titled "Measured RTO Estimate", but RTO is = not a > measured quantity (it is always computed). I think this terminology = needs to > be corrected throughout the document. We fixed the title of 4.2 (which was indeed misleading) to = =E2=80=9CMeasurement-based RTO Estimate=E2=80=9D. We are using =E2=80=9CRTO estimate=E2=80=9D because we have three = estimator processes (the weak, the strong, and the combined one). The = result of the last estimator is used as the actual RTO value. But in 15 = places we were trying to highlight the estimator process and not the use = the result is being put to, that=E2=80=99s where it says RTO estimate. If you have an idea how to get this result as well as avoid some of the = confusion this seems to generate, we=E2=80=99d like to hear it. > Section 3 seems important to me, but doesn't say very clearly what it = means by > "generally applicable". Does that mean that it could run across the = Internet?=20 > Does it work if there are very short or very long delays, or only ones = around > the values mentioned in Apppendix C? Does it work if the links are = very thin > bandwidth? Is it efficient when there is very high bandwidth (e.g. = Gbps > range)? Since there are many classes of IoT device and many possible = use > cases, it seems important to me to be a little bit more clear about = the > envisioned use cases, or at least the specific ones that have been = explored > to-date, versus what hasn't been explicitly considered but might (or = might not) > also work. The appendix just sort of uses the word "diverse" and = mentions a > couple link technologies, but otherwise doesn=E2=80=99t provide any = enlightenment. We expanded this a bit, please see https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-cocoa-03.txt#part-4 We did not explicitly restate the area of application of CoAP; of course = CoCoA is intended to be used with CoAP, so this is less about data = center use with Gbit/s channels, but more about the environments = described in RFC 7228. (Note that there are also different =E2=80=9Cefficiency=E2=80=9D = considerations here: it is not the objective of CoCoA to fill a link.) > The first sentence in section 4 doesn't make much sense to me, since = the > default timeout doesn't imply any knowledge of the RTT. Do you mean = to say > that a more appropriate RTO can be computed once some RTT samples are > available? The wording could be clarified here. Should be fixed now. > The description in the beginning of section 4.2 says that ambiguous = samples > resulting from retransmissions are used in the "weak" estimator, and = seems to > be saying that Karn's algorithm is not used for filtering samples? = The > rationale seems to be in 4.2.2, but the text there is vague. In = general, it > would seem to result only in a potentially slower than necessary = timeout, but > still faster than the default. That seems inherently safe, and I'd = think there > could be a stronger argument made than the current text. We didn=E2=80=99t feel like attempting to strengthen the language here, = but did add a little bit of information in=20 https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-cocoa-03.txt#part-5 > That said, the statement in this section that the rate of retries is = reduced > does not make sense, since any time the RTO decreases, the rate of = retries > should be increasing, with all other things considered equal? Reduced as compared to strong-only (as the text now states). > Is there sensitivity to the weights for the EWMA? This has been = studied a bit > for TCP, but I guess may be different for CoAP scenarios since there = are less > samples typically, or something? Several weights were tried in the research. Unfortunately, this is less = than adequately documented at this time. It would be more satisfying to = have some documentation about choosing these weights, maybe we can spawn = some more formal research about this, but the important thing of course = is that the results do look good with the suggested weights. >=20 > Why is this being targeted for just Informational rather than = Experimental or > better? It's mentioned as being informational in both the header and = Section > 1.1, but I didn't notice an explanation of why the WG thinks it = wouldn't be a > candidate for widespread use, etc. Is there a concern that needs to = be > described? CoCoA is certainly intended to be the go-to implementation strategy for = all but class-1 [RFC7228] devices. Experimental would be fine if we had an experiment that we want to run. But the experiments we came up with already were done (see Appendix A). The question is, of course, whether unilateral implementation methods, = to which congestion control methods without participation of the peer = such as CoCoA belong, should be informational or standards track. Given = that the Security area does most of its standardization work in = informational documents, the line is blurry. Outside security, = generally, what needs to be implemented for interoperability goes into = standards track, and the rest is much less well-defined. We went for = informational because it=E2=80=99s possible. Standards-Track also would = work; I think we can leave this decision to the wisdom of the IESG. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Feb 21 15:59:11 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF8EA1201F2; Wed, 21 Feb 2018 15:59:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no 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 J7LtGO8Am6xB; Wed, 21 Feb 2018 15:59:07 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BDB11200E5; Wed, 21 Feb 2018 15:59:07 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w1LNx3LB000350; Thu, 22 Feb 2018 00:59:03 +0100 (CET) Received: from client-0108.vpn.uni-bremen.de (client-0108.vpn.uni-bremen.de [134.102.107.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3zmvb72FtLzDX9l; Thu, 22 Feb 2018 00:58:57 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: <78806C40-FE57-4785-B59A-E69E06784888@kuehlewind.net> Date: Wed, 21 Feb 2018 15:58:55 -0800 Cc: "draft-ietf-core-cocoa.all@ietf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 540950330.73599-5bc77f8354144376ee3df942d588ea41 Content-Transfer-Encoding: quoted-printable Message-Id: <288D63DB-33C7-441A-8FBB-D63D47F6F872@tzi.org> References: <4B20067C-5F2E-4F30-8AEB-27B2B07D107C@ericsson.com> <477E70B1-A8B3-4A27-B2E1-CE26DF46DE68@kuehlewind.net> <78806C40-FE57-4785-B59A-E69E06784888@kuehlewind.net> To: "Mirja Kuehlewind (IETF)" X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [core] AD review of draft-ietf-core-cocoa-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 23:59:10 -0000 On Feb 15, 2018, at 04:39, Mirja Kuehlewind (IETF) = wrote: >=20 > Hi authors, >=20 > do want to make another update before I start IETF last call, or = should I start it right away? >=20 > Mirja Hi Mirja, as you can see, we opted for making a small update (we could have = communicated this earlier). We have prepared https://tools.ietf.org/html/draft-ietf-core-cocoa-03 with some reactions to your (and Wesley's) comments; diff is in https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-cocoa-03.txt= Details below. The authors believe that -03 is now ready for IETF last call. Gr=C3=BC=C3=9Fe, Carsten >>>>=20 >>>> -------------------------- >>>>=20 >>>> Mostly editorial comments: >>>>=20 >>>> 1) First sentence in sec 1, maybe:=20 >>>> s/The CoAP protocol/The Constrained Application Protocol (CoAP) = [RFC7252]/ Fixed (in abstract, too). Really, I=E2=80=99d like to get CoAP on the =E2=80=9Cdoes not need to be = expanded=E2=80=9D list, though. (Oops, the reference got lost in -03; added in the editors=E2=80=99 = draft on https://github.com/core-wg/cocoa .) >>>> 2) The following note is not necessary: >>>> "(Note that the present document is itself informational, but it is >>>> discussing normative statements about behavior that makes the >>>> congestion control scheme work in a safe manner.)=E2=80=9C Gone. https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-cocoa-03.txt#part-3 >>>> 3) The formatting with (1) and (2) is a bit confusing in the = equations in section 4.2.; maybe you can add some more space there. = Further I really find it confusing that you directly use RTO instead of = RTT here and then just later explain that you use an K of 1. I would = rather explain that first an maybe even use RTT_weak and RTT_strong = instead of E_ We made it more explicit that we are using the same variables and = calculations as RFC 6298 (which the reader indeed needs to be familiar = with). (And fixed the formulas to be less confusingly spaced.) https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-cocoa-03.txt#part-5 >>>> 4) I find the heading of section 4.2.1 a bit confusing and the = whole section a bit hard to read as you didn=E2=80=99t really introduce = the =E2=80=9Enew=E2=80=9C backoff calculation yet. Maybe you can = actually move some of the discussion (about initial values and K) in the = previous subsection and call this ubsection something like =E2=80=9EBackof= f calculation=E2=80=9C and then maybe add one sentence that explains = what RFC6298 does, e.g. =E2=80=9EIn [RFC6298] the RTO is increased = exponentially with a factor of 2 if the RTO timer expires.=E2=80=9C Done (in a similar way). Lower down in=E2=80=A6 https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-cocoa-03.txt#part-5 >>>> 4) sec 4.3 "It MUST be kept for at least 255 s.=E2=80=9C >>>> Why is that a MUST and why 255s? 255 s is a convenient 8-bit value that fits well with the time scales of = CoAP. I think the point here is that if you discard data about = worse-than-default RTO too quickly, then you don=E2=80=99t get all of = the congestion control benefits of CoCoA in worse-than-default = environments. The MUST just was a very conservative precaution against = lazy implementers. Clearly, this number needs to scale with the RFC = 7252 Section 4.8 transmission parameters (see also Laurent Toutain=E2=80=99= s new timescale draft), so we do indeed have a bit of a bug here. In https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-cocoa-03.txt#part-6 we tried to be a bit more explicit about the goals and a bit less = draconian about the specifics (SHOULD instead of MUST). The = recommendation of 255 s (for the default Section 4.8 CoAP parameter set) = stays in, but there is additional information that should help an = implementer do the right thing when there are different timescales. Alternative timescales haven=E2=80=99t really been tried a lot, so = trying to nail this down to specific numbers here would be premature. (CoRE WG: The reduction from MUST to SHOULD is the only technical change = in -03 relative to -02. Please check whether you are comfortable with this.) =20 >>>> 5) I would consider to have section 5 before section 4, That didn=E2=80=99t work well for us. After all Section 5 is only about Non-Confirmables, these are one = specific case that requires additional considerations (we are not = getting measurements back), but is based on the estimator of Section 4. >>>> to give the reader a better idea that the calculated RTO is used to = define the sending rate (which is the actually congestion control part = of the spec). I think it would also be good to give a high-level (1-2 = sentences) overview of the congestion control principle in the intro, = e.g. CoCoA calculates the retransmission time-out (RTO) based on the = estimated RTT with and without loss and limits the sending rate (for = non-confinable packets) to 1/RTO. By taking retransmissions (in a = potentially lossy network) into account when estimating the RTT, this = algorithm reacts to congestion will a lower sending rate.=E2=80=9C >>>>=20 >>>> Also this sentence in section 5.1 could be helpful information in = the intro already: "Assuming that the RTO >>>> estimation in CoCoA works as expected, RTO[k] should be slightly >>>> greater than the RTT[k], thus CoCoA would be more conservative.=E2=80= =9C We put some of this in the introduction, see https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-cocoa-03.txt#part-2 (The big blue block lower down). >>>> 6) Maybe consider to integrate Appendix B into the body of the = document. I think that would actually help the reader. We actually like it clearly separated. We have a few forward = references; we hope that people can skip forward along those easily if = they prefer code over text (I certainly do). From nobody Wed Feb 21 19:51:50 2018 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B7685126D73; Wed, 21 Feb 2018 19:51:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Halpern To: Cc: draft-ietf-core-object-security.all@ietf.org, ietf@ietf.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151927150372.21177.1992679615718735268@ietfa.amsl.com> Date: Wed, 21 Feb 2018 19:51:43 -0800 Archived-At: Subject: [core] Genart last call review of draft-ietf-core-object-security-08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 03:51:44 -0000 Reviewer: Joel Halpern Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-core-object-security-08 Reviewer: Joel Halpern Review Date: 2018-02-21 IETF LC End Date: 2018-03-02 IESG Telechat date: 2018-03-08 Summary: This document is ready for publication as a Proposed Standard RFC Major issues: N/A Minor issues: In section 8.2 on verifying the request, step 5 says to "compose" the Additional Authentication Data. I would have expected it to be "verify" the Additional Authentication Data. I could imagine that the verification consists of composing what it should be, and then comparing with what is received. But I do not see the comparison step. is it implicit in some other step? This occurs again in 8.4, so I presume I am simply missing something. This may suggest some clarification could be useful. Nits/editorial comments: N/A From nobody Thu Feb 22 06:32:15 2018 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C350212EADA; Thu, 22 Feb 2018 06:32:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke?= To: Cc: draft-ietf-core-object-security.all@ietf.org, ietf@ietf.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151930992776.8232.15713995276934864913@ietfa.amsl.com> Date: Thu, 22 Feb 2018 06:32:07 -0800 Archived-At: Subject: [core] Opsdir telechat review of draft-ietf-core-object-security-08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 14:32:08 -0000 Reviewer: Éric Vyncke Review result: Has Issues Hello, I am the assigned OPS-DIR reviewer for this draft. The OPS DIrectorate reviews a great part of the IETF documents being processed by the IESG for the OPS ADs. Please treat with these comments as with all other IETF LC comments. Please wait for direction from your document shepherd or AD before posting a new version of the draft. This document defines a method for application-layer protection of CoAP called OSCORE, re-using CORE (RFC8152) for protection and designed for constrained nodes. It is specifically designed to avoid clear-text access by TLS proxies. _Please note that I am not following the CORE WG so some candid comments may be uneducated._ As a side note, I wonder why the AEAD algorithm is in the common security context as it prevents using different crypto algorithm for the two directions of the traffic. Section 3.2 states that the master secret shall be pre-established but *does not give any hint on how to provision this master secret*. Section 4.2 defines the behavior when new CoAP fields/options will be specified. Which is good of course for the future operations. The draft specifies a mandatory AEAD algorithm to be implemented => I am afraid when this algorithm will become less secure, a revised version of this I-D will be published but let's hope that the devices will be able to be upgraded... (this issue is obviously out of scope for this document) The OSCORE message contains a version which is good for future versions. Section 8 does not discuss the situations when the receiving endpoints does not support the proposed method... This section should mention how to provision/discover whether the receiving side (and possibly all the on-path proxies) support OSCORE. Section 9 very briefly mention a 'osc' attribut in a web link. The establishement of security context is very succinctly described in section 11.2 which refers to section 3.2 which does not specify how to provision this master secret. It would be useful to refer to I-D.ietf-ace-oauth-authz and I-D.ietf-ace-oscore-profile in section 3.2 In short my concerns are: - no description of the master secret provisioning (or is a reference to draft-ietf-ace-oauth-authz enough?) - no YANG model for provisioning (or is there an I-D for this in writing?) - no description how crypto algorithms can be negociated Hope this helps -éric From nobody Fri Feb 23 02:26:22 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1333124235 for ; Fri, 23 Feb 2018 02:26:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 bOUYwjhOXlJe for ; Fri, 23 Feb 2018 02:26:13 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D683C1242EA for ; Fri, 23 Feb 2018 02:26:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519381571; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=LV6GjmMfZ7z/964nwq8eBTXYU+TUcOaJ85lJA9yxFxE=; b=UrV6WOY6kix88kQzWaQmJCWqc41cq5ttQzpLbun2v1p3gdE9H3WfEgNTXT2dNkQm ijpl2eI1kp5ypqxjzbarWbIupoWFN6HpPgFZKu7pgVClgw7XIUhtl8Cct3Fc2UDB QSDYFjMjKzqviCVcd2ANJYHNGk+uKggDv7gylxq8WaA=; X-AuditID: c1b4fb3a-347ff700000067b4-cd-5a8fec426682 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A1.72.26548.24CEF8A5; Fri, 23 Feb 2018 11:26:11 +0100 (CET) Received: from ESESSMB107.ericsson.se ([169.254.7.129]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0352.000; Fri, 23 Feb 2018 11:26:10 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Joel Halpern , "gen-art@ietf.org" CC: "draft-ietf-core-object-security.all@ietf.org" , "ietf@ietf.org" , "core@ietf.org" Thread-Topic: Genart last call review of draft-ietf-core-object-security-08 Thread-Index: AQHTq5B10khO9+K1o0aQQatbu7YyQ6Oxyk4A Date: Fri, 23 Feb 2018 10:26:09 +0000 Message-ID: References: <151927150372.21177.1992679615718735268@ietfa.amsl.com> In-Reply-To: <151927150372.21177.1992679615718735268@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [83.251.191.108] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDIsWRmVeSWpSXmKPExsUyM2K7k67zm/4og+9TOC32vV3PbPGtZx6r xdVXn1ksnm2cz2Lx8dQbJgdWjyVLfjJ5nJvynTGAKYrLJiU1J7MstUjfLoEro2vuLfaCTWIV E84sZ2pgfCHaxcjBISFgIrHsiloXIxeHkMBhRolzq/qYIJwljBIHNzazdzFycrAJuEg8aHjE BGKLCPhKHP+7CayIWWA5o8SJxu9gCWEBL4kze26xQhR5S2xde50RZIOIgJHE1Nl1IGEWAVWJ OQcOsIDYvAIWEv9PfwSbLyTgLDH7whFmEJsTaNei/yfBxjAKiEl8P7UGbDyzgLjErSfzwWwJ AQGJJXvOM0PYohIvH/8DqxcV0JPY29POBvGYkkTPBikQk1lAU2L9Ln2IKdYSFz4sYISwFSWm dD9kh7hGUOLkzCcsExjFZyFZNguhexaS7llIumch6V7AyLqKUbQ4tbg4N93ISC+1KDO5uDg/ Ty8vtWQTIzAOD275bbWD8eBzx0OMAhyMSjy82570RwmxJpYVV+YeYpTgYFYS4S17DhTiTUms rEotyo8vKs1JLT7EKM3BoiTO65RmESUkkJ5YkpqdmlqQWgSTZeLglGpgZPJkf5UY+kfgQ3du svrHAI6EYt7fgRcS1vqFPl50+f6n5pN3SsvUNANWrgz8tO9bZHyybNf6Kb4fWXdm/puk8ltS U/JKo2nf7KiJAi/PPNDumJHOFxXiPs/m55/Plgu+Pv5lUcJVoPBWfrJdE2smj3dw5u2tLzKk VnJVse9N/aH0SZxRMcBMiaU4I9FQi7moOBEA0geO178CAAA= Archived-At: Subject: Re: [core] Genart last call review of draft-ietf-core-object-security-08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 10:26:16 -0000 SGkgSm9lbCwNCg0KVGhhbmtzIGZvciB5b3VyIHJldmlldy4gQ29tbWVudHMgaW5saW5lLg0KDQoN Ck9uIDIwMTgtMDItMjIgMDQ6NTEsICJKb2VsIEhhbHBlcm4iIDxqbWhAam9lbGhhbHBlcm4uY29t PiB3cm90ZToNCg0KPlJldmlld2VyOiBKb2VsIEhhbHBlcm4NCj5SZXZpZXcgcmVzdWx0OiBSZWFk eSB3aXRoIE5pdHMNCj4NCj5JIGFtIHRoZSBhc3NpZ25lZCBHZW4tQVJUIHJldmlld2VyIGZvciB0 aGlzIGRyYWZ0LiBUaGUgR2VuZXJhbCBBcmVhDQo+UmV2aWV3IFRlYW0gKEdlbi1BUlQpIHJldmll d3MgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZA0KPmJ5IHRoZSBJRVNHIGZvciB0 aGUgSUVURiBDaGFpci4gIFBsZWFzZSB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0DQo+bGlrZSBh bnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KPg0KPkZvciBtb3JlIGluZm9ybWF0aW9uLCBw bGVhc2Ugc2VlIHRoZSBGQVEgYXQNCj4NCj48aHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvZ2Vu L3dpa2kvR2VuQXJ0ZmFxPi4NCj4NCj5Eb2N1bWVudDogZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1z ZWN1cml0eS0wOA0KPlJldmlld2VyOiBKb2VsIEhhbHBlcm4NCj5SZXZpZXcgRGF0ZTogMjAxOC0w Mi0yMQ0KPklFVEYgTEMgRW5kIERhdGU6IDIwMTgtMDMtMDINCj5JRVNHIFRlbGVjaGF0IGRhdGU6 IDIwMTgtMDMtMDgNCj4NCj5TdW1tYXJ5OiBUaGlzIGRvY3VtZW50IGlzIHJlYWR5IGZvciBwdWJs aWNhdGlvbiBhcyBhIFByb3Bvc2VkIFN0YW5kYXJkIFJGQw0KPg0KPk1ham9yIGlzc3VlczogTi9B DQo+DQo+TWlub3IgaXNzdWVzOg0KPiAgICBJbiBzZWN0aW9uIDguMiBvbiB2ZXJpZnlpbmcgdGhl IHJlcXVlc3QsIHN0ZXAgNSBzYXlzIHRvICJjb21wb3NlIiB0aGUNCj4gICAgQWRkaXRpb25hbCBB dXRoZW50aWNhdGlvbiBEYXRhLiAgSSB3b3VsZCBoYXZlIGV4cGVjdGVkIGl0IHRvIGJlDQo+InZl cmlmeSINCj4gICAgdGhlIEFkZGl0aW9uYWwgQXV0aGVudGljYXRpb24gRGF0YS4gIEkgY291bGQg aW1hZ2luZSB0aGF0IHRoZQ0KPnZlcmlmaWNhdGlvbg0KPiAgICBjb25zaXN0cyBvZiBjb21wb3Np bmcgd2hhdCBpdCBzaG91bGQgYmUsIGFuZCB0aGVuIGNvbXBhcmluZyB3aXRoIHdoYXQNCj5pcw0K PiAgICByZWNlaXZlZC4gIEJ1dCBJIGRvIG5vdCBzZWUgdGhlIGNvbXBhcmlzb24gc3RlcC4gIGlz IGl0IGltcGxpY2l0IGluDQo+c29tZQ0KPiAgICBvdGhlciBzdGVwPyAgVGhpcyBvY2N1cnMgYWdh aW4gaW4gOC40LCBzbyBJIHByZXN1bWUgSSBhbSBzaW1wbHkNCj5taXNzaW5nDQo+ICAgIHNvbWV0 aGluZy4gIFRoaXMgbWF5IHN1Z2dlc3Qgc29tZSBjbGFyaWZpY2F0aW9uIGNvdWxkIGJlIHVzZWZ1 bC4NCg0KVGhlIEFBRCBpcyBpbmRlZWQg4oCcY29tcG9zZWQiIGJvdGggb24gZW5jcnlwdGluZyBh bmQgZGVjcnlwdGluZyBzaWRlIGZyb20NCmRhdGEgd2hpY2ggbmVlZHMgdG8gYmUga25vd24gdG8g dGhlIGVuZHBvaW50IGF0IHRoZSB0aW1lIHdoZW4gdGhlIEFFQUQNCm9wZXJhdGlvbiBpcyBwZXJm b3JtZWQuIFRoZSBhdXRoZW50aWNhdGVkIGRlY3J5cHRpb24gcHJvY2VzcyBpcyBkZXNjcmliZWQN CmluOg0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTExNiNzZWN0aW9uLTIuMg0K DQpTbyB0aGUgdmVyaWZpY2F0aW9uIGNvbnNpc3RzIG9mIGZlZWRpbmcgdGhlIGlucHV0LCBpbmNs dWRpbmcgdGhlIEFBRCwgdG8NCnRoZSBhdXRoZW50aWNhdGVkIGRlY3J5cHRpb24gd2hpY2ggY2Fs Y3VsYXRlcyB0aGUgcGxhaW4gdGV4dCBvciBGQUlMLCBhbmQNCmEgZmFpbHVyZSBtYXkgYmUgLSBi dXQgaXMgbm90IG5lY2Vzc2FyaWx5IC0gY2F1c2VkIGJ5IHdyb25nIEFBRC4NCg0KVGhlIEFEIHJl dmlldyBhbHNvIGluZGljYXRlZCB0aGF0IHdlIHNob3VsZCBtb3ZlIHRoZSByZWZlcmVuY2UgdG8g UkZDIDUxMTYNCnRvIGFuIGVhcmx5IHNlY3Rpb24gaW4gdGhlIGRyYWZ0IGFuZCB0aGF0IGNoYW5n ZSBpcyBhbHJlYWR5IGluY2x1ZGVkIGluDQp0aGUgbGF0ZXN0IHZlcnNpb24gb24gdGhlIENvUkUg V0cgR2l0aHViLg0KDQoNCkJlc3QgcmVnYXJkcw0KR8O2cmFuDQoNCg== From nobody Fri Feb 23 02:58:26 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E0A129C59 for ; Fri, 23 Feb 2018 02:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 e4tOpX-ahp0O for ; Fri, 23 Feb 2018 02:58:22 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D5F5127871 for ; Fri, 23 Feb 2018 02:58:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519383500; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=OXfq3DzlCiKTuNpXaMgV4bQ8gyqOlcGnLM3yev6k0q0=; b=XEBoHpgFBvJ/4O3ByjnL9GaJs2ir0J4++KZCaFAXND+2KVmOe5isYN6WCwuQndiB 1DC+Fk3BOcHsQxeRB8DcnX2Pt+w70kx5uC59nMEuAwdDvmQMboZ3fayG5ie0weNV Pm68pwVrWrmnVN1N26Z4yc9hp0gOV2i5Fn329Z0Hn8E=; X-AuditID: c1b4fb25-44ba69c000002d5f-2c-5a8ff3cc92cd Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 54.F1.11615.CC3FF8A5; Fri, 23 Feb 2018 11:58:20 +0100 (CET) Received: from ESESSMB107.ericsson.se ([169.254.7.129]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0352.000; Fri, 23 Feb 2018 11:58:19 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: =?utf-8?B?w4lyaWMgVnluY2tl?= , "ops-dir@ietf.org" CC: "draft-ietf-core-object-security.all@ietf.org" , "ietf@ietf.org" , "core@ietf.org" Thread-Topic: Opsdir telechat review of draft-ietf-core-object-security-08 Thread-Index: AQHTq+nsZxF6pWnh9E6gxOB3W3sh+KOx0paA Date: Fri, 23 Feb 2018 10:58:18 +0000 Message-ID: References: <151930992776.8232.15713995276934864913@ietfa.amsl.com> In-Reply-To: <151930992776.8232.15713995276934864913@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [83.251.191.108] Content-Type: text/plain; charset="utf-8" Content-ID: <7CB61CE1E45D194B90CEDF296CFD6563@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLIsWRmVeSWpSXmKPExsUyM2K7qO6Zz/1RBgfuylvse7ue2eJbzzxW iy/7FzBaPNs4n8Wit2kJswOrx5TfG1k9liz5yRTAFMVlk5Kak1mWWqRvl8CVsfvYXsaCHzYV zTNPMzYwbrDuYuTkkBAwkTj2/zgTiC0kcJhR4tVd/y5GLiB7CaPEtgnn2EASbAIuEg8aHoEV iQjESqx/f5sdpIhZYDmjxInG72AJYQFPiR1v3zNCFHlJTDn1mx3CNpLY/Ho/WA2LgKrE2lPb wWxeAQuJiZ+3skJsdpa4u2AT2DJOoGXXGs4xg9iMAmIS30+tAatnFhCXuPVkPhPE1QISS/ac Z4awRSVePv4HNkdUQE9ib0870BwOoLiSRM8GKRCTWUBTYv0ufYgp1hJPpy1khbAVJaZ0P2SH uEZQ4uTMJywTGMVnIVk2C6F7FpLuWUi6ZyHpXsDIuopRtDi1OCk33chYL7UoM7m4OD9PLy+1 ZBMjMBIPbvmtuoPx8hvHQ4wCHIxKPLxLnvZHCbEmlhVX5h5ilOBgVhLhLXsOFOJNSaysSi3K jy8qzUktPsQozcGiJM47R7g9SkggPbEkNTs1tSC1CCbLxMEp1cBY7iTN53O6bXKod4qN9qJf ZkmpMUv1LYwPWc7813FSLbpnY7f4L94/va4y7w49+snkxLgpO9DgephZ6huG0u2x1/O2lz3P DXHa1zB1dcS3pbFFNluZWX2+TJau19NYvdfxZd5cVpFotYm83WmPk9z/sWcEKc4123LoKUvO ofn6+VY6ltcO+iixFGckGmoxFxUnAgDqsza4wAIAAA== Archived-At: Subject: Re: [core] Opsdir telechat review of draft-ietf-core-object-security-08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 10:58:25 -0000 DQpIaSBFcmljLA0KDQpUaGFua3MgZm9yIHlvdXIgcmV2aWV3LiBDb21tZW50cyBpbmxpbmUuDQoN Cg0KT24gMjAxOC0wMi0yMiAxNTozMiwgIsOJcmljIFZ5bmNrZSIgPGV2eW5ja2VAY2lzY28uY29t PiB3cm90ZToNCg0KPlJldmlld2VyOiDDiXJpYyBWeW5ja2UNCj5SZXZpZXcgcmVzdWx0OiBIYXMg SXNzdWVzDQo+DQo+SGVsbG8sDQo+DQo+SSBhbSB0aGUgYXNzaWduZWQgT1BTLURJUiByZXZpZXdl ciBmb3IgdGhpcyBkcmFmdC4gVGhlIE9QUyBESXJlY3RvcmF0ZQ0KPnJldmlld3MNCj5hIGdyZWF0 IHBhcnQgb2YgdGhlIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRyBm b3IgdGhlDQo+T1BTIEFEcy4NCj5QbGVhc2UgdHJlYXQgd2l0aCB0aGVzZSBjb21tZW50cyBhcyB3 aXRoIGFsbCBvdGhlciBJRVRGIExDIGNvbW1lbnRzLg0KPlBsZWFzZQ0KPndhaXQgZm9yIGRpcmVj dGlvbiBmcm9tIHlvdXIgZG9jdW1lbnQgc2hlcGhlcmQgb3IgQUQgYmVmb3JlIHBvc3RpbmcgYSBu ZXcNCj52ZXJzaW9uIG9mIHRoZSBkcmFmdC4NCj4NCj5UaGlzIGRvY3VtZW50IGRlZmluZXMgYSBt ZXRob2QgZm9yIGFwcGxpY2F0aW9uLWxheWVyIHByb3RlY3Rpb24gb2YgQ29BUA0KPmNhbGxlZA0K Pk9TQ09SRSwgcmUtdXNpbmcgQ09SRSAoUkZDODE1MikgZm9yIHByb3RlY3Rpb24gYW5kIGRlc2ln bmVkIGZvcg0KPmNvbnN0cmFpbmVkDQo+bm9kZXMuIEl0IGlzIHNwZWNpZmljYWxseSBkZXNpZ25l ZCB0byBhdm9pZCBjbGVhci10ZXh0IGFjY2VzcyBieSBUTFMNCj5wcm94aWVzLg0KPg0KPl9QbGVh c2Ugbm90ZSB0aGF0IEkgYW0gbm90IGZvbGxvd2luZyB0aGUgQ09SRSBXRyBzbyBzb21lIGNhbmRp ZCBjb21tZW50cw0KPm1heSBiZQ0KPnVuZWR1Y2F0ZWQuXw0KPg0KPkFzIGEgc2lkZSBub3RlLCBJ IHdvbmRlciB3aHkgdGhlIEFFQUQgYWxnb3JpdGhtIGlzIGluIHRoZSBjb21tb24gc2VjdXJpdHkN Cj5jb250ZXh0IGFzIGl0IHByZXZlbnRzIHVzaW5nIGRpZmZlcmVudCBjcnlwdG8gYWxnb3JpdGht IGZvciB0aGUgdHdvDQo+ZGlyZWN0aW9ucw0KPm9mIHRoZSB0cmFmZmljLg0KDQpUaGlzIGhhcyBi ZWVuIGRpc2N1c3NlZCBidXQgbm8gY29tcGVsbGluZyB1c2UgY2FzZSB3ZXJlIHByZXNlbnRlZCBz byBmb3INCnNpbXBsaWNpdHkgdGhpcyB3YXMgbGVmdCBvdXQuDQoNCj4NCj5TZWN0aW9uIDMuMiBz dGF0ZXMgdGhhdCB0aGUgbWFzdGVyIHNlY3JldCBzaGFsbCBiZSBwcmUtZXN0YWJsaXNoZWQgYnV0 DQo+KmRvZXMNCj5ub3QgZ2l2ZSBhbnkgaGludCBvbiBob3cgdG8gcHJvdmlzaW9uIHRoaXMgbWFz dGVyIHNlY3JldCouDQoNCg0KSS1ELmlldGYtYWNlLW9hdXRoLWF1dGh6IGlzIHJlZmVyZW5jZWQg aW4gU2VjdGlvbiAzLjIsIGJ1dCAtIGFzIHlvdSByZW1hcmsNCmJlbG93IC0gd2Ugc2hvdWxkIGFs c28gYWRkIHRoZSBzcGVjaWZpYyByZWZlcmVuY2UgdG8NCkktRC5pZXRmLWFjZS1vc2NvcmUtcHJv ZmlsZS4gVGhlcmUgYXJlIGFsc28gb3RoZXIgb3B0aW9ucy4gU29tZQ0KY29uc3RyYWluZWQgZGV2 aWNlIGRlcGxveW1lbnRzIHByb3Zpc2lvbiBwcmUtc2hhcmVkIGtleXMgd2hpY2ggbWF5IGJlIHVz ZWQNCmFzIG1hc3RlciBzZWNyZXQuIFRoZXJlIGFyZSBhbHNvIHR3byBjYW5kaWRhdGUga2V5IGV4 Y2hhbmdlIHByb3RvY29scw0KKGRyYWZ0LXNlbGFuZGVyLWFjZS1jb3NlLWVjZGhlIGFuZCBkcmFm dC1tYXR0c3Nvbi1hY2UtdGxzLW9zY29yZSkgYnV0DQpwcm9ncmVzcyBoYXMgYmVlbiBzdGFsbGVk IGJ5IGEgZGlzY3Vzc2lvbiBpbiBBQ0Ugd2hpY2ggcHJvdG9jb2wgaXMgcmlnaHQuDQoNCg0KPlNl Y3Rpb24gNC4yIGRlZmluZXMgdGhlIGJlaGF2aW9yIHdoZW4gbmV3IENvQVAgZmllbGRzL29wdGlv bnMgd2lsbCBiZQ0KPnNwZWNpZmllZC4gV2hpY2ggaXMgZ29vZCBvZiBjb3Vyc2UgZm9yIHRoZSBm dXR1cmUgb3BlcmF0aW9ucy4NCj4NCj5UaGUgZHJhZnQgc3BlY2lmaWVzIGEgbWFuZGF0b3J5IEFF QUQgYWxnb3JpdGhtIHRvIGJlIGltcGxlbWVudGVkDQoNClRoZSBJRVRGIG1hbmRhdGVzIHNwZWNp ZmljYXRpb24gb2YgTVRJIGFsZ29yaXRobXMuDQoNCg0KPj0+IEkgYW0gYWZyYWlkDQo+d2hlbiB0 aGlzIGFsZ29yaXRobSB3aWxsIGJlY29tZSBsZXNzIHNlY3VyZSwgYSByZXZpc2VkIHZlcnNpb24g b2YgdGhpcw0KPkktRCB3aWxsDQo+YmUgcHVibGlzaGVkIGJ1dCBsZXQncyBob3BlIHRoYXQgdGhl IGRldmljZXMgd2lsbCBiZSBhYmxlIHRvIGJlDQo+dXBncmFkZWQuLi4NCj4odGhpcyBpc3N1ZSBp cyBvYnZpb3VzbHkgb3V0IG9mIHNjb3BlIGZvciB0aGlzIGRvY3VtZW50KQ0KDQpUaGUgdXNlIG9m IEktRC5pZXRmLWFjZS1vc2NvcmUtcHJvZmlsZSwgZm9yIGV4YW1wbGUsIGFsbG93cyBpbiBhZGRp dGlvbiB0bw0KbWFzdGVyIHNlY3JldCBhbHNvIHRoZSBzcGVjaWZpY2F0aW9uIG9mIEFFQUQgYWxn b3JpdGhtIGFuZCBLREYgYWxnb3JpdGhtDQphbmQgb3RoZXIgZGVmYXVsdCBwYXJhbWV0ZXJzIHVz ZWQgdG8gZGVyaXZlIHRoZSBzZWN1cml0eSBjb250ZXh0LiBJZiB0aGUNCmRldmljZSBzdXBwb3J0 cyBtb3JlIHRoYW4gb25lIEFFQUQgYWxnb3JpdGhtLCBhIHN3aXRjaCBjYW4gYmUgbWFkZSB3aXRo DQp0aGlzIHByb3RvY29sLiBBcyB5b3UgcmVtYXJrLCB0aGUgcmVhbCBpc3N1ZSBpcyB0aGF0IHRo ZSBkZXZpY2UgbWF5IG5vdA0Kc3VwcG9ydCBtdWx0aXBsZSBhbGdvcml0aG1zLg0KDQoNCj4NCj5U aGUgT1NDT1JFIG1lc3NhZ2UgY29udGFpbnMgYSB2ZXJzaW9uIHdoaWNoIGlzIGdvb2QgZm9yIGZ1 dHVyZSB2ZXJzaW9ucy4NCj4NCj5TZWN0aW9uIDggZG9lcyBub3QgZGlzY3VzcyB0aGUgc2l0dWF0 aW9ucyB3aGVuIHRoZSByZWNlaXZpbmcgZW5kcG9pbnRzDQo+ZG9lcyBub3QNCj5zdXBwb3J0IHRo ZSBwcm9wb3NlZCBtZXRob2QuLi4NCg0KSXQgd2FzbuKAmXQgY2xlYXIgdG8gbWUgd2hhdCB0aGUg InByb3Bvc2VkIG1ldGhvZOKAnSByZWZlcnJlZCB0by4gQXJlIHlvdQ0KdGhpbmtpbmcgb2YgcmVj ZWl2aW5nIGVuZHBvaW50cyBub3Qgc3VwcG9ydGluZyBPU0NPUkU/IENvQVAgKFJGQzcyNTINCnNl Y3Rpb24gNS40LjEpIHNwZWNpZmllcyB0aGUgYmVoYXZpb3VyIG9mIGEgcmVjZWl2aW5nIGVuZHBv aW50IHdoaWNoIGRvZXMNCm5vdCBzdXBwb3J0IHRoZSBPYmplY3QtU2VjdXJpdHkgb3B0aW9uOg0K DQoiVW5yZWNvZ25pemVkIG9wdGlvbnMgb2YgY2xhc3MgImNyaXRpY2FsIiB0aGF0IG9jY3VyIGlu IGEgQ29uZmlybWFibGUNCnJlcXVlc3QgTVVTVCBjYXVzZSB0aGUgcmV0dXJuIG9mIGEgNC4wMiAo QmFkIE9wdGlvbikgcmVzcG9uc2UuIFRoaXMNCnJlc3BvbnNlIFNIT1VMRCBpbmNsdWRlIGEgZGlh Z25vc3RpYyBwYXlsb2FkIGRlc2NyaWJpbmcgdGhlIHVucmVjb2duaXplZA0Kb3B0aW9uKHMpIChz ZWUgU2VjdGlvbiA1LjUuMiku4oCdDQoNCg0KVGhlIGFwcGxpY2F0aW9uIGRlY2lkZXMgdGhlIGNv bmRpdGlvbnMgZm9yIHdoaWNoIE9TQ09SRSBpcyByZXF1aXJlZCwgYW5kDQppZiBpdCBpbnZva2Vz IE9TQ09SRSBhbHNvIG5lZWRzIHRvIGhhbmRsZSB0aGUgY2FzZSB0aGF0IE9TQ09SRSBpcyBub3QN CnN1cHBvcnRlZCBieSB0aGUgc2VydmVyICh3aGljaCBTSE9VTEQgYmVjb21lIGtub3duIHRvIHRo ZSBjbGllbnQgYnkgdGhlDQptZWNoYW5pc20gZGVzY3JpYmVkIGFib3ZlKS4NCg0KRG8gd2UgbmVl ZCB0byBzcGVjaWZ5IHNvbWV0aGluZyBpbiB0aGlzIHJlc3BlY3Q/DQoNCg0KPlRoaXMgc2VjdGlv biBzaG91bGQgbWVudGlvbiBob3cgdG8gcHJvdmlzaW9uL2Rpc2NvdmVyIHdoZXRoZXIgdGhlDQo+ cmVjZWl2aW5nIHNpZGUgKGFuZCBwb3NzaWJseSBhbGwgdGhlIG9uLXBhdGggcHJveGllcykgc3Vw cG9ydCBPU0NPUkUuDQoNCg0KQXMgbWVudGlvbmVkIGFib3ZlLCB0aGUgcHJvdmlzaW9uaW5nIG9m IHRoZSByZWNlaXZpbmcgc2lkZSBpcyBkZXNjcmliZWQNCmUuZy4gaW4gSS1ELmlldGYtYWNlLW9z Y29yZS1wcm9maWxlLg0KDQpPU0NPUkUgaXMgZGVzaWduZWQgdG8gd29yayB3aXRoIHByb3hpZXMg d2hpY2ggdW5kZXJzdGFuZCBvciBkb27igJl0DQp1bmRlcnN0YW5kIE9TQ09SRSwgcHJvdmlkaW5n IGRpZmZlcmVudCBmdW5jdGlvbmFsaXR5LiBCdXQgdGhlIHByb3RlY3Rpb24NCm9mIG1lc3NhZ2Vz IGJldHdlZW4gZW5kcG9pbnRzIGFuZCBwcm94aWVzIGlzIG5vdCBpbiBzY29wZS4gSXQgY2FuIGJl IGFkZGVkDQpieSBkZWZpbmluZyBhIGNsYXNzIEkgb3B0aW9uLiBPciwgaWYgZW5kcG9pbnRzIGFu ZCBwcm94aWVzIGNhbiBiZSBjb25zaWRlcg0KdG8gcGFydCBvZiBhIHNlY3VyaXR5IGdyb3VwLCB0 aGUgZXh0ZW5zaW9uIHRvIGdyb3VwIGNvbW11bmljYXRpb25zIGNhbiBiZQ0KYXBwbGllZCAoZHJh ZnQtaWV0Zi1jb3JlLW9zY29yZS1ncm91cGNvbW0pLCB3aGVyZSB0aGUga2V5IHByb3Zpc2lvbmlu ZyBpcw0Kc3BlY2lmaWVkIGluIGFub3RoZXIgQUNFIGRyYWZ0IChkcmFmdC10aWxvY2EtYWNlLW9z Y29hcC1qb2luaW5nKS4NCg0KUGxlYXNlIHByb3ZpZGUgc29tZSBtb3JlIGRldGFpbHMgYXMgdG8g d2hhdCBraW5kIG9mIHByb3Zpc2lvbmluZy9kaXNjb3ZlcnkNCm1lY2hhbmlzbXMgeW91IGFyZSBz dGlsbCBtaXNzaW5nIGFuZCBmb3Igd2hhdCBwdXJwb3NlLg0KDQoNCj5TZWN0aW9uIDkgdmVyeSBi cmllZmx5IG1lbnRpb24gYSAnb3NjJyBhdHRyaWJ1dCBpbiBhDQo+d2ViIGxpbmsuDQoNClllcywg dGhhdCBpcyBvbmUgd2F5IHRvIGluZGljYXRlIHN1cHBvcnQgZm9yIE9TQ09SRS4gRGlkIHlvdSBt aXNzIGFueXRoaW5nDQppbiB0aGlzIHNlY3Rpb24/DQoNCj4NCj5UaGUgZXN0YWJsaXNoZW1lbnQg b2Ygc2VjdXJpdHkgY29udGV4dCBpcyB2ZXJ5IHN1Y2NpbmN0bHkgZGVzY3JpYmVkIGluDQo+c2Vj dGlvbg0KPjExLjIgd2hpY2ggcmVmZXJzIHRvIHNlY3Rpb24gMy4yIHdoaWNoIGRvZXMgbm90IHNw ZWNpZnkgaG93IHRvIHByb3Zpc2lvbg0KPnRoaXMNCj5tYXN0ZXIgc2VjcmV0LiBJdCB3b3VsZCBi ZSB1c2VmdWwgdG8gcmVmZXIgdG8gSS1ELmlldGYtYWNlLW9hdXRoLWF1dGh6IGFuZA0KPkktRC5p ZXRmLWFjZS1vc2NvcmUtcHJvZmlsZSBpbiBzZWN0aW9uIDMuMg0KDQpBZ3JlZWQsIGFzIG1lbnRp b25lZCBhYm92ZS4NCg0KPg0KPkluIHNob3J0IG15IGNvbmNlcm5zIGFyZToNCj4tIG5vIGRlc2Ny aXB0aW9uIG9mIHRoZSBtYXN0ZXIgc2VjcmV0IHByb3Zpc2lvbmluZyAob3IgaXMgYSByZWZlcmVu Y2UgdG8NCj5kcmFmdC1pZXRmLWFjZS1vYXV0aC1hdXRoeiBlbm91Z2g/KSAtIG5vIFlBTkcgbW9k ZWwgZm9yIHByb3Zpc2lvbmluZyAob3INCj5pcw0KPnRoZXJlIGFuIEktRCBmb3IgdGhpcyBpbiB3 cml0aW5nPykgLSBubyBkZXNjcmlwdGlvbiBob3cgY3J5cHRvIGFsZ29yaXRobXMNCj5jYW4NCj5i ZSBuZWdvY2lhdGVkDQoNCkkgaG9wZSBJIGhhdmUgYW5zd2VyZWQgdGhlc2UgaXRlbXMgYWJvdmUs IGV4Y2VwdCBZQU5HIG1vZGVsOiBUaGUgcGxhbm5lZA0KZGVwbG95bWVudHMgSSBrbm93IG9mIGFy ZSBub3QgdXNpbmcgWUFORywgYnV0IGlmIHRoYXQgaXMgcmVxdWlyZWQgb3INCnBlb3BsZSBhcmUg aW50ZXJlc3RlZCB3ZSBjYW4gc3BlY2lmeSB0aGF0IGluIGEgc2VwYXJhdGUgZHJhZnQuIExldCB1 cyBrbm93Lg0KDQo+DQo+SG9wZSB0aGlzIGhlbHBzDQoNCg0KVGhhbmtzLA0KR8O2cmFuDQoNCg== From nobody Fri Feb 23 06:00:00 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF3071201FA; Fri, 23 Feb 2018 05:59:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 fGduQ5F_mXe9; Fri, 23 Feb 2018 05:59:41 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE50312E05C; Fri, 23 Feb 2018 05:59:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 966211C0691; Fri, 23 Feb 2018 05:59:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1519394379; bh=4Lx8mYtWy4A0/tnkHBBAlCA56VyyoMsjzEA4RyT9K/0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=LQu5kV1fTZgZ0dQAerfzp7HTO7wrvwpn12xGT6DzKpmZ4fZ2g3aWEoyT9TMmqk94v UNk2lUdEpoB8z9e4rgpD3dfz4cTtmmXo8BenRcuFVQEHhOMBjuKKiRiZE1b6cLiL1V 8GGrL0wJ1gnHs3N9ptsMPDhdryhLNplyEcEbhEJc= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id D85451C059F; Fri, 23 Feb 2018 05:59:38 -0800 (PST) To: =?UTF-8?Q?G=c3=b6ran_Selander?= , "gen-art@ietf.org" Cc: "draft-ietf-core-object-security.all@ietf.org" , "ietf@ietf.org" , "core@ietf.org" References: <151927150372.21177.1992679615718735268@ietfa.amsl.com> From: "Joel M. Halpern" Message-ID: Date: Fri, 23 Feb 2018 08:59:38 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [core] Genart last call review of draft-ietf-core-object-security-08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 13:59:43 -0000 In terms of my concerns, if Step 7 said "Verify and Decrypt the COSE object using the Recipient Key as per RFC 5116 Section 2.2" that would fill in the confusion for this reader. Yours, Joel On 2/23/18 5:26 AM, Göran Selander wrote: > Hi Joel, > > Thanks for your review. Comments inline. > > > On 2018-02-22 04:51, "Joel Halpern" wrote: > >> Reviewer: Joel Halpern >> Review result: Ready with Nits >> >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF documents being processed >> by the IESG for the IETF Chair. Please treat these comments just >> like any other last call comments. >> >> For more information, please see the FAQ at >> >> . >> >> Document: draft-ietf-core-object-security-08 >> Reviewer: Joel Halpern >> Review Date: 2018-02-21 >> IETF LC End Date: 2018-03-02 >> IESG Telechat date: 2018-03-08 >> >> Summary: This document is ready for publication as a Proposed Standard RFC >> >> Major issues: N/A >> >> Minor issues: >> In section 8.2 on verifying the request, step 5 says to "compose" the >> Additional Authentication Data. I would have expected it to be >> "verify" >> the Additional Authentication Data. I could imagine that the >> verification >> consists of composing what it should be, and then comparing with what >> is >> received. But I do not see the comparison step. is it implicit in >> some >> other step? This occurs again in 8.4, so I presume I am simply >> missing >> something. This may suggest some clarification could be useful. > > The AAD is indeed “composed" both on encrypting and decrypting side from > data which needs to be known to the endpoint at the time when the AEAD > operation is performed. The authenticated decryption process is described > in: > > https://tools.ietf.org/html/rfc5116#section-2.2 > > So the verification consists of feeding the input, including the AAD, to > the authenticated decryption which calculates the plain text or FAIL, and > a failure may be - but is not necessarily - caused by wrong AAD. > > The AD review also indicated that we should move the reference to RFC 5116 > to an early section in the draft and that change is already included in > the latest version on the CoRE WG Github. > > > Best regards > Göran > From nobody Fri Feb 23 06:30:47 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF054127201 for ; Fri, 23 Feb 2018 06:30:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H4=-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 (1024-bit key) header.d=ericsson.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 ycxq8NB7MSIO for ; Fri, 23 Feb 2018 06:30:45 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9C5E127337 for ; Fri, 23 Feb 2018 06:30:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519396243; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=E6dIPhmY0ylVkLern1bOL20GiPtePVPOPTq5FkhD9mE=; b=RT1qYxv/yrb/30PVmnBXUud3oZJhQ8FBlH1ZUGeSVzaxn0A9xk/dVz0s+YZRCIhV cIdgnhzSYlh6uTMecfroXqm90nJiNMz2/qJruOL6g6ZslXXB7Et+lDdu85vAVIey TsIZdvL3GeDVNUYQouPG3+8iXaE2cAOYBs5u5QbbQP0=; X-AuditID: c1b4fb3a-728f89c0000067b4-bf-5a90259274cd Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 2A.C3.26548.295209A5; Fri, 23 Feb 2018 15:30:43 +0100 (CET) Received: from ESESSMB107.ericsson.se ([169.254.7.129]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0352.000; Fri, 23 Feb 2018 15:30:41 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "Joel M. Halpern" , "gen-art@ietf.org" CC: "draft-ietf-core-object-security.all@ietf.org" , "ietf@ietf.org" , "core@ietf.org" Thread-Topic: Genart last call review of draft-ietf-core-object-security-08 Thread-Index: AQHTq5B10khO9+K1o0aQQatbu7YyQ6Oxyk4AgAAq4wCAABlwgA== Date: Fri, 23 Feb 2018 14:30:40 +0000 Message-ID: References: <151927150372.21177.1992679615718735268@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLIsWRmVeSWpSXmKPExsUyM2K7iu5k1QlRBneWcFvse7ue2eJbzzxW i6uvPrNYPNs4n8Xi46k3TA6sHkuW/GTyODflO2MAUxSXTUpqTmZZapG+XQJXxvYPSQWP5Cvu /7/G3MD4Q66LkZNDQsBE4urqtaxdjFwcQgKHGSX2z1nKBuEsYZQ4tHsXM0gVm4CLxIOGR0wg tohAiMSBh6vAipgFljNKnGj8DpYQFvCSOLPnFitEkbfE1rXXGSFsJ4meOU1ANgcHi4CqxMlf HCBhXgELifUtGxghlq1mlDhwbgM7SIJTwFmi/e8WNhCbUUBM4vupNWDzmQXEJW49mc8EcbaA xJI955khbFGJl4//ge0VFdCT2NvTzgayS0JAUWJ5vxyIySygKbF+lz7EFGuJpcfbGCFsRYkp 3Q/ZIc4RlDg58wnLBEbxWUiWzULonoWkexaS7llIuhcwsq5iFC1OLS7OTTcy0kstykwuLs7P 08tLLdnECIzEg1t+W+1gPPjc8RCjAAejEg/vKuEJUUKsiWXFlbmHGCU4mJVEeMue90cJ8aYk VlalFuXHF5XmpBYfYpTmYFES53VKs4gSEkhPLEnNTk0tSC2CyTJxcEo1MCbtFNt8RUpC5W5B c6n6Sov4u2E+RU8neyacy717+FuH5K7QqER/Tlmmcwe5Lv3ekXv87OppIenhG4/kOtTFVQg4 T3L40Jna9JYj/9iv4/+/3W/+26bw/vbWkE1Hnpfc3DB5lt5xvSPpV+8oxZVcWbn+sZdw4HX+ Cxysctu6I9dxPo17bjGpa7ESS3FGoqEWc1FxIgBLUTDfwAIAAA== Archived-At: Subject: Re: [core] Genart last call review of draft-ietf-core-object-security-08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 14:30:47 -0000 SGkgSm9lbCwNCg0KVGhhbmtzIGZvciBxdWljayBmZWVkYmFjaywgaW5saW5lLg0KDQpPbiAyMDE4 LTAyLTIzIDE0OjU5LCAiSm9lbCBNLiBIYWxwZXJuIiA8am1oQGpvZWxoYWxwZXJuLmNvbT4gd3Jv dGU6DQoNCj5JbiB0ZXJtcyBvZiBteSBjb25jZXJucywgaWYgU3RlcCA3IHNhaWQgIlZlcmlmeSBh bmQgRGVjcnlwdCB0aGUgQ09TRQ0KPm9iamVjdCB1c2luZyB0aGUgUmVjaXBpZW50IEtleSBhcyBw ZXIgUkZDIDUxMTYgU2VjdGlvbiAyLjIiIHRoYXQgd291bGQNCj5maWxsIGluIHRoZSBjb25mdXNp b24gZm9yIHRoaXMgcmVhZGVyLg0KDQpTaW5jZSB0aGUgQUVBRCBpcyB1c2VkIHRocm91Z2hvdXQg dGhlIGRyYWZ0LCBpbiBwYXJ0aWN1bGFyIGluIG90aGVyIHBhcnRzDQpvZiB0aGlzIHNlY3Rpb24g SeKAmW0gdGhpbmtpbmcgdGhhdCBtYXliZSB3ZSBzaG91bGQgYWRkIFJGQyA1MTE2IHRvIHRoZSBs aXN0DQpvZiBzcGVjaWZpY2F0aW9ucyBmb2xsb3dpbmcgIlJlYWRlcnMgYXJlIGV4cGVjdGVkIHRv IGJlIGZhbWlsaWFyIHdpdGjigJ0gaW4NClNlY3Rpb24gMS4xLiBXb3VsZCB0aGF0IGFkZHJlc3Mg eW91ciBjb21tZW50Pw0KDQpUaGFua3MNCkfDtnJhbg0KDQoNCg0KPg0KPllvdXJzLA0KPkpvZWwN Cj4NCj5PbiAyLzIzLzE4IDU6MjYgQU0sIEfDtnJhbiBTZWxhbmRlciB3cm90ZToNCj4+IEhpIEpv ZWwsDQo+PiANCj4+IFRoYW5rcyBmb3IgeW91ciByZXZpZXcuIENvbW1lbnRzIGlubGluZS4NCj4+ IA0KPj4gDQo+PiBPbiAyMDE4LTAyLTIyIDA0OjUxLCAiSm9lbCBIYWxwZXJuIiA8am1oQGpvZWxo YWxwZXJuLmNvbT4gd3JvdGU6DQo+PiANCj4+PiBSZXZpZXdlcjogSm9lbCBIYWxwZXJuDQo+Pj4g UmV2aWV3IHJlc3VsdDogUmVhZHkgd2l0aCBOaXRzDQo+Pj4NCj4+PiBJIGFtIHRoZSBhc3NpZ25l ZCBHZW4tQVJUIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgR2VuZXJhbCBBcmVhDQo+Pj4g UmV2aWV3IFRlYW0gKEdlbi1BUlQpIHJldmlld3MgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHBy b2Nlc3NlZA0KPj4+IGJ5IHRoZSBJRVNHIGZvciB0aGUgSUVURiBDaGFpci4gIFBsZWFzZSB0cmVh dCB0aGVzZSBjb21tZW50cyBqdXN0DQo+Pj4gbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1l bnRzLg0KPj4+DQo+Pj4gRm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIEZBUSBh dA0KPj4+DQo+Pj4gPGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL2dlbi93aWtpL0dlbkFydGZh cT4uDQo+Pj4NCj4+PiBEb2N1bWVudDogZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eS0w OA0KPj4+IFJldmlld2VyOiBKb2VsIEhhbHBlcm4NCj4+PiBSZXZpZXcgRGF0ZTogMjAxOC0wMi0y MQ0KPj4+IElFVEYgTEMgRW5kIERhdGU6IDIwMTgtMDMtMDINCj4+PiBJRVNHIFRlbGVjaGF0IGRh dGU6IDIwMTgtMDMtMDgNCj4+Pg0KPj4+IFN1bW1hcnk6IFRoaXMgZG9jdW1lbnQgaXMgcmVhZHkg Zm9yIHB1YmxpY2F0aW9uIGFzIGEgUHJvcG9zZWQgU3RhbmRhcmQNCj4+PlJGQw0KPj4+DQo+Pj4g TWFqb3IgaXNzdWVzOiBOL0ENCj4+Pg0KPj4+IE1pbm9yIGlzc3VlczoNCj4+PiAgICAgSW4gc2Vj dGlvbiA4LjIgb24gdmVyaWZ5aW5nIHRoZSByZXF1ZXN0LCBzdGVwIDUgc2F5cyB0byAiY29tcG9z ZSINCj4+PnRoZQ0KPj4+ICAgICBBZGRpdGlvbmFsIEF1dGhlbnRpY2F0aW9uIERhdGEuICBJIHdv dWxkIGhhdmUgZXhwZWN0ZWQgaXQgdG8gYmUNCj4+PiAidmVyaWZ5Ig0KPj4+ICAgICB0aGUgQWRk aXRpb25hbCBBdXRoZW50aWNhdGlvbiBEYXRhLiAgSSBjb3VsZCBpbWFnaW5lIHRoYXQgdGhlDQo+ Pj4gdmVyaWZpY2F0aW9uDQo+Pj4gICAgIGNvbnNpc3RzIG9mIGNvbXBvc2luZyB3aGF0IGl0IHNo b3VsZCBiZSwgYW5kIHRoZW4gY29tcGFyaW5nIHdpdGgNCj4+PndoYXQNCj4+PiBpcw0KPj4+ICAg ICByZWNlaXZlZC4gIEJ1dCBJIGRvIG5vdCBzZWUgdGhlIGNvbXBhcmlzb24gc3RlcC4gIGlzIGl0 IGltcGxpY2l0IGluDQo+Pj4gc29tZQ0KPj4+ICAgICBvdGhlciBzdGVwPyAgVGhpcyBvY2N1cnMg YWdhaW4gaW4gOC40LCBzbyBJIHByZXN1bWUgSSBhbSBzaW1wbHkNCj4+PiBtaXNzaW5nDQo+Pj4g ICAgIHNvbWV0aGluZy4gIFRoaXMgbWF5IHN1Z2dlc3Qgc29tZSBjbGFyaWZpY2F0aW9uIGNvdWxk IGJlIHVzZWZ1bC4NCj4+IA0KPj4gVGhlIEFBRCBpcyBpbmRlZWQg4oCcY29tcG9zZWQiIGJvdGgg b24gZW5jcnlwdGluZyBhbmQgZGVjcnlwdGluZyBzaWRlIGZyb20NCj4+IGRhdGEgd2hpY2ggbmVl ZHMgdG8gYmUga25vd24gdG8gdGhlIGVuZHBvaW50IGF0IHRoZSB0aW1lIHdoZW4gdGhlIEFFQUQN Cj4+IG9wZXJhdGlvbiBpcyBwZXJmb3JtZWQuIFRoZSBhdXRoZW50aWNhdGVkIGRlY3J5cHRpb24g cHJvY2VzcyBpcw0KPj5kZXNjcmliZWQNCj4+IGluOg0KPj4gDQo+PiBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjNTExNiNzZWN0aW9uLTIuMg0KPj4gDQo+PiBTbyB0aGUgdmVyaWZpY2F0 aW9uIGNvbnNpc3RzIG9mIGZlZWRpbmcgdGhlIGlucHV0LCBpbmNsdWRpbmcgdGhlIEFBRCwgdG8N Cj4+IHRoZSBhdXRoZW50aWNhdGVkIGRlY3J5cHRpb24gd2hpY2ggY2FsY3VsYXRlcyB0aGUgcGxh aW4gdGV4dCBvciBGQUlMLA0KPj5hbmQNCj4+IGEgZmFpbHVyZSBtYXkgYmUgLSBidXQgaXMgbm90 IG5lY2Vzc2FyaWx5IC0gY2F1c2VkIGJ5IHdyb25nIEFBRC4NCj4+IA0KPj4gVGhlIEFEIHJldmll dyBhbHNvIGluZGljYXRlZCB0aGF0IHdlIHNob3VsZCBtb3ZlIHRoZSByZWZlcmVuY2UgdG8gUkZD DQo+PjUxMTYNCj4+IHRvIGFuIGVhcmx5IHNlY3Rpb24gaW4gdGhlIGRyYWZ0IGFuZCB0aGF0IGNo YW5nZSBpcyBhbHJlYWR5IGluY2x1ZGVkIGluDQo+PiB0aGUgbGF0ZXN0IHZlcnNpb24gb24gdGhl IENvUkUgV0cgR2l0aHViLg0KPj4gDQo+PiANCj4+IEJlc3QgcmVnYXJkcw0KPj4gR8O2cmFuDQo+ PiANCg0K From nobody Fri Feb 23 06:32:54 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA88124D6C; Fri, 23 Feb 2018 06:32:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 FvDJzlMAL4FK; Fri, 23 Feb 2018 06:32:36 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D9971200FC; Fri, 23 Feb 2018 06:32:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 58EDD1C0691; Fri, 23 Feb 2018 06:32:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1519396356; bh=6Kdv+MN7ZOHs72CAWCtUntOiCu6nbdHzMLAfvMr4c5g=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=FCQZMAzTPFGMBM87qez1aD5Bk2JFLqiQRM26Ar74v3C+3OlSaJX1lo3ftlewtYJSM RCexsRIzBGXKY4Hjypb9cirxwfsfsRuq91/P2fXjNtS0E4BovStKq5LX3VbMS2L9AV KWvlsfRaIxUVYGc5EmvGmx6sslyc+OC4phTiPgcQ= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 8645C1C059F; Fri, 23 Feb 2018 06:32:35 -0800 (PST) To: =?UTF-8?Q?G=c3=b6ran_Selander?= , "Joel M. Halpern" , "gen-art@ietf.org" Cc: "draft-ietf-core-object-security.all@ietf.org" , "ietf@ietf.org" , "core@ietf.org" References: <151927150372.21177.1992679615718735268@ietfa.amsl.com> From: Joel Halpern Direct Message-ID: Date: Fri, 23 Feb 2018 09:32:34 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [core] Genart last call review of draft-ietf-core-object-security-08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 14:32:38 -0000 I guess it is up to you. Personally, I like the idea of the verify description including some reference to how one actually does verify. I will leave it to the authors and WG to decide what degree of clarity is called for here. Yours, Joel On 2/23/18 9:30 AM, Göran Selander wrote: > Hi Joel, > > Thanks for quick feedback, inline. > > On 2018-02-23 14:59, "Joel M. Halpern" wrote: > >> In terms of my concerns, if Step 7 said "Verify and Decrypt the COSE >> object using the Recipient Key as per RFC 5116 Section 2.2" that would >> fill in the confusion for this reader. > > Since the AEAD is used throughout the draft, in particular in other parts > of this section I’m thinking that maybe we should add RFC 5116 to the list > of specifications following "Readers are expected to be familiar with” in > Section 1.1. Would that address your comment? > > Thanks > Göran > > > >> >> Yours, >> Joel >> >> On 2/23/18 5:26 AM, Göran Selander wrote: >>> Hi Joel, >>> >>> Thanks for your review. Comments inline. >>> >>> >>> On 2018-02-22 04:51, "Joel Halpern" wrote: >>> >>>> Reviewer: Joel Halpern >>>> Review result: Ready with Nits >>>> >>>> I am the assigned Gen-ART reviewer for this draft. The General Area >>>> Review Team (Gen-ART) reviews all IETF documents being processed >>>> by the IESG for the IETF Chair. Please treat these comments just >>>> like any other last call comments. >>>> >>>> For more information, please see the FAQ at >>>> >>>> . >>>> >>>> Document: draft-ietf-core-object-security-08 >>>> Reviewer: Joel Halpern >>>> Review Date: 2018-02-21 >>>> IETF LC End Date: 2018-03-02 >>>> IESG Telechat date: 2018-03-08 >>>> >>>> Summary: This document is ready for publication as a Proposed Standard >>>> RFC >>>> >>>> Major issues: N/A >>>> >>>> Minor issues: >>>> In section 8.2 on verifying the request, step 5 says to "compose" >>>> the >>>> Additional Authentication Data. I would have expected it to be >>>> "verify" >>>> the Additional Authentication Data. I could imagine that the >>>> verification >>>> consists of composing what it should be, and then comparing with >>>> what >>>> is >>>> received. But I do not see the comparison step. is it implicit in >>>> some >>>> other step? This occurs again in 8.4, so I presume I am simply >>>> missing >>>> something. This may suggest some clarification could be useful. >>> >>> The AAD is indeed “composed" both on encrypting and decrypting side from >>> data which needs to be known to the endpoint at the time when the AEAD >>> operation is performed. The authenticated decryption process is >>> described >>> in: >>> >>> https://tools.ietf.org/html/rfc5116#section-2.2 >>> >>> So the verification consists of feeding the input, including the AAD, to >>> the authenticated decryption which calculates the plain text or FAIL, >>> and >>> a failure may be - but is not necessarily - caused by wrong AAD. >>> >>> The AD review also indicated that we should move the reference to RFC >>> 5116 >>> to an early section in the draft and that change is already included in >>> the latest version on the CoRE WG Github. >>> >>> >>> Best regards >>> Göran >>> > From nobody Fri Feb 23 06:38:50 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE05012025C for ; Fri, 23 Feb 2018 06:38:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 scdyKjOHMUlV for ; Fri, 23 Feb 2018 06:38:35 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D025124D6C for ; Fri, 23 Feb 2018 06:38:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519396711; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=pyFzcSVY52fc2tmP3PCnB563297bFAKkWIRSK6E1Qdc=; b=FATykzKjHerlQfn8+vhGkZplQq9bMg4zDZSO8VJoyPiJYvDyNme6mvRFJAu4Qh6O wsbDEbbeJ5lGlqTSRoc2PwSB1RrRFY8BXf+CxZASsfPzyoq54yP4poc4Sbx0RyFP WvlsWDYEb0/ofpaJ0D1W6D/pPc98mu591Fv6iNYgvjE=; X-AuditID: c1b4fb25-083ff70000002d5f-9f-5a902766ded0 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id E3.7D.11615.667209A5; Fri, 23 Feb 2018 15:38:31 +0100 (CET) Received: from ESESSMB107.ericsson.se ([169.254.7.129]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0352.000; Fri, 23 Feb 2018 15:38:30 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Joel Halpern Direct , "Joel M. Halpern" , "gen-art@ietf.org" CC: "draft-ietf-core-object-security.all@ietf.org" , "ietf@ietf.org" , "core@ietf.org" Thread-Topic: Genart last call review of draft-ietf-core-object-security-08 Thread-Index: AQHTq5B10khO9+K1o0aQQatbu7YyQ6Oxyk4AgAAq4wCAABlwgP//78QAgAASbAA= Date: Fri, 23 Feb 2018 14:38:29 +0000 Message-ID: References: <151927150372.21177.1992679615718735268@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="utf-8" Content-ID: <8FF162214F945A43B030157BD3F8975D@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGIsWRmVeSWpSXmKPExsUyM2K7um66+oQog41f2Cz2vV3PbPGtZx6r xdVXn1ksnm2cz2KxbRFQ7OOpN0wObB5Llvxk8jg35TtjAFMUl01Kak5mWWqRvl0CV8azxsls BZc0Km4vfc/awHhGvYuRk0NCwETiysLD7F2MXBxCAocZJdp//WWGcJYwSvzdepYJpIpNwEXi QcMjJpCEiEAbo8SXZRvYQBxmgeWMEicav4NVCQt4SZzZc4sVxBYR8JbYuvY6I4TtJ/H6wlEw m0VAVeL+xbVgNq+AhcSL5v8sEOsmM0m07bgMluAUcJaY+2MhM4jNKCAm8f3UGrAFzALiEree zGeCOFxAYsme88wQtqjEy8f/wBaLCuhJ7O1pZ4OIK0rsPNsOVMMB1KspsX6XPsQYa4nD66Yx QtiKElO6H7JD3CMocXLmE5YJjOKzkGybhdA9C0n3LCTds5B0L2BkXcUoWpxanJSbbmSsl1qU mVxcnJ+nl5dasokRGJsHt/xW3cF4+Y3jIUYBDkYlHl5HoQlRQqyJZcWVuYcYJTiYlUR4y573 RwnxpiRWVqUW5ccXleakFh9ilOZgURLnnSPcHiUkkJ5YkpqdmlqQWgSTZeLglGpgbKld0SIt zvh+paj61btVhnu5eBn+rOn50hJQMFPu2Z8i9ZPszZyrTmlbyYUl2gVNfzpj40rzV7kRpYdX NTSwHxWxPOgS9G/Cb11lFt21hQmqs3fI3dr+rWDShe2W89R2/lrlHfe3+OU+af6TzfHH9u+r SrlUyLNSi+cj166QnuJT7wu1p/6yVGIpzkg01GIuKk4EAOb43jTJAgAA Archived-At: Subject: Re: [core] Genart last call review of draft-ietf-core-object-security-08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 14:38:36 -0000 DQpIb3cgYWJvdXQgdGhpcyAoc2VlIHRoZSBsYXN0IGFuZCB0aGlyZCB0byBsYXN0IGVkaXQpOg0K aHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvb3Njb2FwL2NvbW1pdC84ZjI3N2Q4Mw0KDQp3aGVy ZSB0aGUgcmVmZXJlbmNlIGlzIG1hZGUgdG8gQ09TRSBpbnN0ZWFkIG9mIEFFQUQ/DQoNCkJlc3QN CkfDtnJhbg0KDQoNCk9uIDIwMTgtMDItMjMgMTU6MzIsICJKb2VsIEhhbHBlcm4gRGlyZWN0IiA8 am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb20+DQp3cm90ZToNCg0KPkkgZ3Vlc3MgaXQgaXMgdXAg dG8geW91LiAgUGVyc29uYWxseSwgSSBsaWtlIHRoZSBpZGVhIG9mIHRoZSB2ZXJpZnkNCj5kZXNj cmlwdGlvbiBpbmNsdWRpbmcgc29tZSByZWZlcmVuY2UgdG8gaG93IG9uZSBhY3R1YWxseSBkb2Vz IHZlcmlmeS4NCj5JIHdpbGwgbGVhdmUgaXQgdG8gdGhlIGF1dGhvcnMgYW5kIFdHIHRvIGRlY2lk ZSB3aGF0IGRlZ3JlZSBvZiBjbGFyaXR5DQo+aXMgY2FsbGVkIGZvciBoZXJlLg0KPg0KPllvdXJz LA0KPkpvZWwNCj4NCj5PbiAyLzIzLzE4IDk6MzAgQU0sIEfDtnJhbiBTZWxhbmRlciB3cm90ZToN Cj4+IEhpIEpvZWwsDQo+PiANCj4+IFRoYW5rcyBmb3IgcXVpY2sgZmVlZGJhY2ssIGlubGluZS4N Cj4+IA0KPj4gT24gMjAxOC0wMi0yMyAxNDo1OSwgIkpvZWwgTS4gSGFscGVybiIgPGptaEBqb2Vs aGFscGVybi5jb20+IHdyb3RlOg0KPj4gDQo+Pj4gSW4gdGVybXMgb2YgbXkgY29uY2VybnMsIGlm IFN0ZXAgNyBzYWlkICJWZXJpZnkgYW5kIERlY3J5cHQgdGhlIENPU0UNCj4+PiBvYmplY3QgdXNp bmcgdGhlIFJlY2lwaWVudCBLZXkgYXMgcGVyIFJGQyA1MTE2IFNlY3Rpb24gMi4yIiB0aGF0IHdv dWxkDQo+Pj4gZmlsbCBpbiB0aGUgY29uZnVzaW9uIGZvciB0aGlzIHJlYWRlci4NCj4+IA0KPj4g U2luY2UgdGhlIEFFQUQgaXMgdXNlZCB0aHJvdWdob3V0IHRoZSBkcmFmdCwgaW4gcGFydGljdWxh ciBpbiBvdGhlcg0KPj5wYXJ0cw0KPj4gb2YgdGhpcyBzZWN0aW9uIEnigJltIHRoaW5raW5nIHRo YXQgbWF5YmUgd2Ugc2hvdWxkIGFkZCBSRkMgNTExNiB0byB0aGUNCj4+bGlzdA0KPj4gb2Ygc3Bl Y2lmaWNhdGlvbnMgZm9sbG93aW5nICJSZWFkZXJzIGFyZSBleHBlY3RlZCB0byBiZSBmYW1pbGlh ciB3aXRo4oCdDQo+PmluDQo+PiBTZWN0aW9uIDEuMS4gV291bGQgdGhhdCBhZGRyZXNzIHlvdXIg Y29tbWVudD8NCj4+IA0KPj4gVGhhbmtzDQo+PiBHw7ZyYW4NCj4+IA0KPj4gDQo+PiANCj4+Pg0K Pj4+IFlvdXJzLA0KPj4+IEpvZWwNCj4+Pg0KPj4+IE9uIDIvMjMvMTggNToyNiBBTSwgR8O2cmFu IFNlbGFuZGVyIHdyb3RlOg0KPj4+PiBIaSBKb2VsLA0KPj4+Pg0KPj4+PiBUaGFua3MgZm9yIHlv dXIgcmV2aWV3LiBDb21tZW50cyBpbmxpbmUuDQo+Pj4+DQo+Pj4+DQo+Pj4+IE9uIDIwMTgtMDIt MjIgMDQ6NTEsICJKb2VsIEhhbHBlcm4iIDxqbWhAam9lbGhhbHBlcm4uY29tPiB3cm90ZToNCj4+ Pj4NCj4+Pj4+IFJldmlld2VyOiBKb2VsIEhhbHBlcm4NCj4+Pj4+IFJldmlldyByZXN1bHQ6IFJl YWR5IHdpdGggTml0cw0KPj4+Pj4NCj4+Pj4+IEkgYW0gdGhlIGFzc2lnbmVkIEdlbi1BUlQgcmV2 aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZSBHZW5lcmFsIEFyZWENCj4+Pj4+IFJldmlldyBUZWFt IChHZW4tQVJUKSByZXZpZXdzIGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQNCj4+ Pj4+IGJ5IHRoZSBJRVNHIGZvciB0aGUgSUVURiBDaGFpci4gIFBsZWFzZSB0cmVhdCB0aGVzZSBj b21tZW50cyBqdXN0DQo+Pj4+PiBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQo+ Pj4+Pg0KPj4+Pj4gRm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIEZBUSBhdA0K Pj4+Pj4NCj4+Pj4+IDxodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9nZW4vd2lraS9HZW5BcnRm YXE+Lg0KPj4+Pj4NCj4+Pj4+IERvY3VtZW50OiBkcmFmdC1pZXRmLWNvcmUtb2JqZWN0LXNlY3Vy aXR5LTA4DQo+Pj4+PiBSZXZpZXdlcjogSm9lbCBIYWxwZXJuDQo+Pj4+PiBSZXZpZXcgRGF0ZTog MjAxOC0wMi0yMQ0KPj4+Pj4gSUVURiBMQyBFbmQgRGF0ZTogMjAxOC0wMy0wMg0KPj4+Pj4gSUVT RyBUZWxlY2hhdCBkYXRlOiAyMDE4LTAzLTA4DQo+Pj4+Pg0KPj4+Pj4gU3VtbWFyeTogVGhpcyBk b2N1bWVudCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24gYXMgYSBQcm9wb3NlZA0KPj4+Pj5TdGFu ZGFyZA0KPj4+Pj4gUkZDDQo+Pj4+Pg0KPj4+Pj4gTWFqb3IgaXNzdWVzOiBOL0ENCj4+Pj4+DQo+ Pj4+PiBNaW5vciBpc3N1ZXM6DQo+Pj4+PiAgICAgIEluIHNlY3Rpb24gOC4yIG9uIHZlcmlmeWlu ZyB0aGUgcmVxdWVzdCwgc3RlcCA1IHNheXMgdG8NCj4+Pj4+ImNvbXBvc2UiDQo+Pj4+PiB0aGUN Cj4+Pj4+ICAgICAgQWRkaXRpb25hbCBBdXRoZW50aWNhdGlvbiBEYXRhLiAgSSB3b3VsZCBoYXZl IGV4cGVjdGVkIGl0IHRvIGJlDQo+Pj4+PiAidmVyaWZ5Ig0KPj4+Pj4gICAgICB0aGUgQWRkaXRp b25hbCBBdXRoZW50aWNhdGlvbiBEYXRhLiAgSSBjb3VsZCBpbWFnaW5lIHRoYXQgdGhlDQo+Pj4+ PiB2ZXJpZmljYXRpb24NCj4+Pj4+ICAgICAgY29uc2lzdHMgb2YgY29tcG9zaW5nIHdoYXQgaXQg c2hvdWxkIGJlLCBhbmQgdGhlbiBjb21wYXJpbmcgd2l0aA0KPj4+Pj4gd2hhdA0KPj4+Pj4gaXMN Cj4+Pj4+ICAgICAgcmVjZWl2ZWQuICBCdXQgSSBkbyBub3Qgc2VlIHRoZSBjb21wYXJpc29uIHN0 ZXAuICBpcyBpdA0KPj4+Pj5pbXBsaWNpdCBpbg0KPj4+Pj4gc29tZQ0KPj4+Pj4gICAgICBvdGhl ciBzdGVwPyAgVGhpcyBvY2N1cnMgYWdhaW4gaW4gOC40LCBzbyBJIHByZXN1bWUgSSBhbSBzaW1w bHkNCj4+Pj4+IG1pc3NpbmcNCj4+Pj4+ICAgICAgc29tZXRoaW5nLiAgVGhpcyBtYXkgc3VnZ2Vz dCBzb21lIGNsYXJpZmljYXRpb24gY291bGQgYmUgdXNlZnVsLg0KPj4+Pg0KPj4+PiBUaGUgQUFE IGlzIGluZGVlZCDigJxjb21wb3NlZCIgYm90aCBvbiBlbmNyeXB0aW5nIGFuZCBkZWNyeXB0aW5n IHNpZGUNCj4+Pj5mcm9tDQo+Pj4+IGRhdGEgd2hpY2ggbmVlZHMgdG8gYmUga25vd24gdG8gdGhl IGVuZHBvaW50IGF0IHRoZSB0aW1lIHdoZW4gdGhlIEFFQUQNCj4+Pj4gb3BlcmF0aW9uIGlzIHBl cmZvcm1lZC4gVGhlIGF1dGhlbnRpY2F0ZWQgZGVjcnlwdGlvbiBwcm9jZXNzIGlzDQo+Pj4+IGRl c2NyaWJlZA0KPj4+PiBpbjoNCj4+Pj4NCj4+Pj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzUxMTYjc2VjdGlvbi0yLjINCj4+Pj4NCj4+Pj4gU28gdGhlIHZlcmlmaWNhdGlvbiBjb25z aXN0cyBvZiBmZWVkaW5nIHRoZSBpbnB1dCwgaW5jbHVkaW5nIHRoZSBBQUQsDQo+Pj4+dG8NCj4+ Pj4gdGhlIGF1dGhlbnRpY2F0ZWQgZGVjcnlwdGlvbiB3aGljaCBjYWxjdWxhdGVzIHRoZSBwbGFp biB0ZXh0IG9yIEZBSUwsDQo+Pj4+IGFuZA0KPj4+PiBhIGZhaWx1cmUgbWF5IGJlIC0gYnV0IGlz IG5vdCBuZWNlc3NhcmlseSAtIGNhdXNlZCBieSB3cm9uZyBBQUQuDQo+Pj4+DQo+Pj4+IFRoZSBB RCByZXZpZXcgYWxzbyBpbmRpY2F0ZWQgdGhhdCB3ZSBzaG91bGQgbW92ZSB0aGUgcmVmZXJlbmNl IHRvIFJGQw0KPj4+PiA1MTE2DQo+Pj4+IHRvIGFuIGVhcmx5IHNlY3Rpb24gaW4gdGhlIGRyYWZ0 IGFuZCB0aGF0IGNoYW5nZSBpcyBhbHJlYWR5IGluY2x1ZGVkDQo+Pj4+aW4NCj4+Pj4gdGhlIGxh dGVzdCB2ZXJzaW9uIG9uIHRoZSBDb1JFIFdHIEdpdGh1Yi4NCj4+Pj4NCj4+Pj4NCj4+Pj4gQmVz dCByZWdhcmRzDQo+Pj4+IEfDtnJhbg0KPj4+Pg0KPj4gDQoNCg== From nobody Fri Feb 23 06:41:11 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1363E12025C; Fri, 23 Feb 2018 06:41:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 pRyZTQdyGIYN; Fri, 23 Feb 2018 06:40:59 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F43E124D6C; Fri, 23 Feb 2018 06:40:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4A6EA1D2646; Fri, 23 Feb 2018 06:40:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1519396859; bh=iWy4X9EYqu6DIX1CCpGKV8qQIMUNj2s3JdgB85VMS08=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=ZskomaH6EziQQ1KfVLEgdg9B+gdJZp9dgNWURKk7BvWfAjP4Eh88CuPHGojnzYk+a 0E9CowcZX4IoWbXyMY2QMc6NiB3BwX3dGxojgxrTGnNFSHHUXgbh06W1hnM6LfBFOB hhi6xyBikDJbQuHLoNuFeNir2/B+jUoynIq0qjsU= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 8A1351C0D68; Fri, 23 Feb 2018 06:40:58 -0800 (PST) To: =?UTF-8?Q?G=c3=b6ran_Selander?= , "gen-art@ietf.org" Cc: "draft-ietf-core-object-security.all@ietf.org" , "ietf@ietf.org" , "core@ietf.org" References: <151927150372.21177.1992679615718735268@ietfa.amsl.com> From: "Joel M. Halpern" Message-ID: Date: Fri, 23 Feb 2018 09:40:57 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [core] Genart last call review of draft-ietf-core-object-security-08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 14:41:01 -0000 Yes, that is what I was looking for. Thank you, Joel On 2/23/18 9:38 AM, Göran Selander wrote: > > How about this (see the last and third to last edit): > https://github.com/core-wg/oscoap/commit/8f277d83 > > where the reference is made to COSE instead of AEAD? > > Best > Göran > > > On 2018-02-23 15:32, "Joel Halpern Direct" > wrote: > >> I guess it is up to you. Personally, I like the idea of the verify >> description including some reference to how one actually does verify. >> I will leave it to the authors and WG to decide what degree of clarity >> is called for here. >> >> Yours, >> Joel >> >> On 2/23/18 9:30 AM, Göran Selander wrote: >>> Hi Joel, >>> >>> Thanks for quick feedback, inline. >>> >>> On 2018-02-23 14:59, "Joel M. Halpern" wrote: >>> >>>> In terms of my concerns, if Step 7 said "Verify and Decrypt the COSE >>>> object using the Recipient Key as per RFC 5116 Section 2.2" that would >>>> fill in the confusion for this reader. >>> >>> Since the AEAD is used throughout the draft, in particular in other >>> parts >>> of this section I’m thinking that maybe we should add RFC 5116 to the >>> list >>> of specifications following "Readers are expected to be familiar with” >>> in >>> Section 1.1. Would that address your comment? >>> >>> Thanks >>> Göran >>> >>> >>> >>>> >>>> Yours, >>>> Joel >>>> >>>> On 2/23/18 5:26 AM, Göran Selander wrote: >>>>> Hi Joel, >>>>> >>>>> Thanks for your review. Comments inline. >>>>> >>>>> >>>>> On 2018-02-22 04:51, "Joel Halpern" wrote: >>>>> >>>>>> Reviewer: Joel Halpern >>>>>> Review result: Ready with Nits >>>>>> >>>>>> I am the assigned Gen-ART reviewer for this draft. The General Area >>>>>> Review Team (Gen-ART) reviews all IETF documents being processed >>>>>> by the IESG for the IETF Chair. Please treat these comments just >>>>>> like any other last call comments. >>>>>> >>>>>> For more information, please see the FAQ at >>>>>> >>>>>> . >>>>>> >>>>>> Document: draft-ietf-core-object-security-08 >>>>>> Reviewer: Joel Halpern >>>>>> Review Date: 2018-02-21 >>>>>> IETF LC End Date: 2018-03-02 >>>>>> IESG Telechat date: 2018-03-08 >>>>>> >>>>>> Summary: This document is ready for publication as a Proposed >>>>>> Standard >>>>>> RFC >>>>>> >>>>>> Major issues: N/A >>>>>> >>>>>> Minor issues: >>>>>> In section 8.2 on verifying the request, step 5 says to >>>>>> "compose" >>>>>> the >>>>>> Additional Authentication Data. I would have expected it to be >>>>>> "verify" >>>>>> the Additional Authentication Data. I could imagine that the >>>>>> verification >>>>>> consists of composing what it should be, and then comparing with >>>>>> what >>>>>> is >>>>>> received. But I do not see the comparison step. is it >>>>>> implicit in >>>>>> some >>>>>> other step? This occurs again in 8.4, so I presume I am simply >>>>>> missing >>>>>> something. This may suggest some clarification could be useful. >>>>> >>>>> The AAD is indeed “composed" both on encrypting and decrypting side >>>>> from >>>>> data which needs to be known to the endpoint at the time when the AEAD >>>>> operation is performed. The authenticated decryption process is >>>>> described >>>>> in: >>>>> >>>>> https://tools.ietf.org/html/rfc5116#section-2.2 >>>>> >>>>> So the verification consists of feeding the input, including the AAD, >>>>> to >>>>> the authenticated decryption which calculates the plain text or FAIL, >>>>> and >>>>> a failure may be - but is not necessarily - caused by wrong AAD. >>>>> >>>>> The AD review also indicated that we should move the reference to RFC >>>>> 5116 >>>>> to an early section in the draft and that change is already included >>>>> in >>>>> the latest version on the CoRE WG Github. >>>>> >>>>> >>>>> Best regards >>>>> Göran >>>>> >>> > From nobody Fri Feb 23 07:08:50 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF6612E87D; Fri, 23 Feb 2018 07:08:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no 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 BeFk7ohYQuDN; Fri, 23 Feb 2018 07:08:46 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9625129515; Fri, 23 Feb 2018 07:08:41 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 2222B494B2; Fri, 23 Feb 2018 16:08:38 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 22023A7; Fri, 23 Feb 2018 16:08:36 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::db8]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id C2E34285; Fri, 23 Feb 2018 16:08:35 +0100 (CET) Received: (nullmailer pid 4255 invoked by uid 1000); Fri, 23 Feb 2018 15:08:34 -0000 Date: Fri, 23 Feb 2018 16:08:34 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: draft-silverajan-core-coap-protocol-negotiation@ietf.org, Core WG mailing list Message-ID: <20180223150833.GA26617@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5mCyUwZo2JvN/JJP" Content-Disposition: inline User-Agent: Mutt/1.9.3 (2018-01-21) Archived-At: Subject: [core] Review of draft-ietf-core-protocol-negotiation-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 15:08:48 -0000 --5mCyUwZo2JvN/JJP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello protocol-negotiation authors, hello CoRE group, I'd like to offer a review and some suggestions to the document draft-ietf-core-protocol-negotiation-07. My interest in the document is both as a potential implementor, and as co-author of resource-directory, which will in part be judged by whether it easily allows extensions as suggested in protocol-negotiation. * Introduction: It would be helpful to have RFC8323 and draft-becker-core-coap-sms-gprs-06 referenced to understand how different transports use CoAP URIs. =20 * Another document that describes a CoAP scheme is draft-bormann-t2trg-slipmux-02 ("Hey coap+uart://ttyUSB0/, do you happen to be available over the network too, just in case you get unplugged?"). * coap+ws:// does not work like the example with coap+ws://example.org/ws-endpoint/sensors/temperature suggests any more. A more suitable example might be an HTTP proxy URI ('http://proxy.example.org/coap+tcp://eample.org/sensors/temperature'). * The example exchange in "Overcoming Middlebox Issues" confuses me: Why would a client that has already established communication with a server utilize an external service to discover more addresses? With the current draft, this calls for the Alternative-Transport option. * New Resource Directory Parameters: * Why is `at` comma separated rather than a repeated parameter? The former indicates limitations on the available characters (at least the comma; is there any other syntax planned a la `;q=3D0.5`?), and the latter would IMHO be more straight forward to implement. * With changes to the RD in the latest versions, the endpoint lookup looks a bit different. I've taken the examples of this section and created some current ones in the upcoming RD draft ([1]). Note that at least for the endpoint lookups, the `at` parameter does not need to be implemented in a PN-aware RD, as it is the default behavior for unknown RD Parameters to accept them on registration and show them in an endpoint lookup. I think that with the new behavior of the RD, the `tt` parameter makes more sense in resource lookup than in endpoint lookup; would you consider specifying it for there too? Do the examples align with your ideas of how P-N can would work with the latest RD? [1]: https://core-wg.github.io/resource-directory/draft-ietf-core-resou= rce-directory.html#rfc.appendix.B * Does `at` mean that *all* URIs on this server can have their prefixes arbitrarily exchanged, or only the advertised links? * Alternative-Transport option: * Does this option state that the requested URI is equivalent to the indicated ones, or all URIs on the host? * Why is an option used here? The availability of an alternative transport is a metadatum I think would be very suitable for inclusion in . Expression as link metadata would make the unmediated exchange more compatible with the RD-mediated exchange, which right now look very different. * The 'ol' CoRE Link Attribute: Did you consider using a link relation for this? (Ie. there would be a dedicated link from the described resource to its alternative URIs, rather than the URIs being encoded in target attributes). The "alternate" or "duplicate" registered relations seem to already do the required. =20 (Admittedly, I don't quite see the use case for individual link alternative URIs; if the use case you have in mind answers the question, it might be a good idea to outline that use case.) * "Using CoRE Resource Directory": The example in 6.2 would, on a lookup in a ol-unaware RD, return as shown here: Req: GET coap://rd.example.com/rd-lookup/res?ep=3Dnode1 Res: 2.05 Content [...] ;if=3D"sensor"; ol=3D"http://[FDFD::123]:61616,coap://server2.example.com" If the intention is that the href of the link can be re-interpreted as a relative reference based on any of the ol values (btw: again, why comma-separated?), this depends heavily on the serialization and breaks when the serialization needs to be changed (as in the RD that needs to return the absolute reference). All things considered, I think that this is a document that should be adopted by the WG; it covers a relevant topic and provides good starting points for solving it. Thank you, Bill and Mert, for writing this document Christian --=20 You don't become great by trying to be great. You become great by wanting to do something, and then doing it so hard that you become great in the process. -- Marie Curie (as quoted by Randall Munroe) --5mCyUwZo2JvN/JJP Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlqQLmsACgkQOY0REtOk veHkvw//XSB0BNo2Ttw9v6fbn4pgiPiuCVULZ78VbptoD5Js55/0/QIXjH8vD3q+ rb/7/KZfWRWi2+MZbhMQPJgnhvEP1n8LC3lF3nrdJFcHn1lYJJ9nMKnypRIPQqeC FdH4WIfr4BnzNTQW+yCvZREtXshCOtd+YrjRtOnWde7Vo/R5SIJAMV+NmajNXDR5 dxoBHcyRrWQ7pIgyTqcYOUEjSnOeESxHfy43AAA1cI27vt6m9fqLokDMTWrubfZO rfSf1+vpzHuNoVgzJwL70tXLw/vk2sP7EazUPRyEuajUpXFNhSVK5WpwG4C/eyTq 0uRco23/SzJwjjca9BYTgCZeNMfK+d0Xh1gAcajKSE0WDqZOWZYzPzo4OX7XSMk7 aByCKsjqonoHu6Ok81ywacN5mEAM2wSsuZ5FEac35/W+pDdxYQHjgPeUXCJCN1zi qhAUUZdIRVcyOniuJdDo0eiO8lQrFPDrvBm2FuFDErdkCbb3/IIsC+ynjc2uF0GI YLa+pSBeMd9NJRQX2uLC5bNrGMxjIM+u4K8LH8wLF80I5aOFi30M2V2R48il1tdG mcZ1JDdoPVTWZ6G7oBWvsDZqQaQhCLEjNIWSPs+wA3MNcT5QLtrYjHcb9Z3/elV0 3lOyU2XjnUji/geQ1Q51qkhWovpHjZUujGm7NNODDvc5DnMrSu4= =P3GI -----END PGP SIGNATURE----- --5mCyUwZo2JvN/JJP-- From nobody Sat Feb 24 00:03:39 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD21126D45; Sat, 24 Feb 2018 00:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 BpTacQAHyYk4; Sat, 24 Feb 2018 00:03:35 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14003120227; Sat, 24 Feb 2018 00:03:34 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w1O83Vm7021286; Sat, 24 Feb 2018 09:03:31 +0100 (CET) Received: from client-0185.vpn.uni-bremen.de (client-0185.vpn.uni-bremen.de [134.102.107.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3zpLFG64Z9zDXfw; Sat, 24 Feb 2018 09:03:30 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 541152208.06002-906f3783a4e6b88ee7e0de21eeb0bf70 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Sat, 24 Feb 2018 00:03:29 -0800 Message-Id: <42D54C90-DA66-42FB-B734-27986B87BC2E@tzi.org> To: ace , "core@ietf.org WG" , cose , cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [core] Constrained Node/Network Cluster @ IETF101: "FINAL" AGENDA X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Feb 2018 08:03:38 -0000 Here is my usual eclectic condensed agenda based on the "FINAL" AGENDA for IETF101. Remember that "FINAL" means this will be the basis for printed agenda sheets, there is still some potential for changes after that. SUIT is now on top of CORE (!??). (Also, ICE has moved.) The painful ones this time include: DINRG vs. ACE, CBOR vs. TEEP, ROLL vs. traveling to OCF/WoT; also CORE vs. ANIMA, CORE vs. QUIC, CORE vs. SECDISPATCH. All times are actually in GMT (UTC+0000, DST only starts in London on March 25). (You can always get pure UTC times on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten SATURDAY/SUNDAY -- Hackathon (including various interops) MONDAY, March 19, 2018 0930-1200 Morning Session I Blenheim ART dispatch Dispatch WG - 0930-1100 Joint = with ARTAREA Sandringham INT ipwave IP Wireless Access in Vehicular = Environments WG Palace C IRTF*** dinrg Decentralized Internet Infrastructure = Proposed RG Viscount OPS v6ops IPv6 Operations WG Balmoral SEC *** ace Authentication and Authorization for = Constrained Environments WG 1330-1530 Afternoon Session I Richm_Chl_Tow ART *** core Constrained RESTful Environments WG Viscount INT 6man IPv6 Maintenance WG Buckingham SEC *** suit Software Updates for Internet of Things = WG Sandringham TSV quic QUIC WG 1550-1720 Afternoon Session II Sandringham INT intarea Internet Area Working Group WG Balmoral IRTF cfrg Crypto Forum Viscount SEC oauth Web Authorization Protocol WG 1740-1840 Afternoon Session III Balmoral SEC tls Transport Layer Security WG Sandringham TSV tsvarea Transport Area Open Meeting TUESDAY, March 20, 2018 0930-1200 Morning Session I Viscount ART *** core Constrained RESTful Environments WG Sandringham IRTF maprg Measurement and Analysis for Protocols Buckingham OPS anima Autonomic Networking Integrated Model = and Approach WG Blenheim SEC secdispatch Security Dispatch WG 1330-1530 Afternoon Session I Park Suite ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Palace C ART ice Interactive Connectivity Establishment = WG Buckingham IRTF panrg Path Aware Networking Proposed RG Richm_Chl_Tow RTG rift Routing In Fat Trees WG Balmoral SEC *** teep Trusted Execution Environment = Provisioning BOF 1550-1820 Afternoon Session II Balmoral ART httpbis Hypertext Transfer Protocol WG Park Suite IRTF icnrg Information-Centric Networking WEDNESDAY, March 21, 2018 0930-1200 Morning Session I Viscount INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Sandringham IRTF irtfopen IRTF Open Meeting Blenheim SEC tls Transport Layer Security WG Park Suite TSV taps Transport Services WG 1330-1500 Afternoon Session I Viscount INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Richm_Chl_Tow RTG bier Bit Indexed Explicit Replication WG Park Suite SEC oauth Web Authorization Protocol WG Palace C TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1520-1650 Afternoon Session II Park Suite INT *** lwig Light-Weight Implementation Guidance WG Buckingham SEC acme Automated Certificate Management = Environment WG Viscount SEC tokbind Token Binding WG 1710-1940 IETF Plenary - Sandringham THURSDAY, March 22, 2018 0930-1200 Morning Session I Buckingham INT dnssd Extensions for Scalable DNS Service = Discovery WG Park Suite RTG *** roll Routing Over Low power and Lossy = networks WG Sandringham TSV quic QUIC WG 1330-1530 Afternoon Session I Buckingham INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Sandringham SEC saag Security Area Open Meeting 1550-1750 Afternoon Session II Blenheim IRTF*** t2trg Thing-to-Thing Sandringham RTG rtgarea Routing Area Open Meeting Buckingham SEC mls Messaging Layer Security BOF Balmoral TSV tsvwg Transport Area Working Group WG 1810-1910 Afternoon Session III Blenheim ART uta Using TLS in Applications WG Park Suite RTG babel Babel routing protocol WG Balmoral TSV tsvwg Transport Area Working Group WG FRIDAY, March 23, 2018 0930-1130 Morning Session I Sandringham INT homenet Home Networking WG Blenheim RTG detnet Deterministic Networking WG Viscount RTG *** roll Routing Over Low power and Lossy = networks WG 1150-1320 Afternoon Session I Blenheim RTG detnet Deterministic Networking WG - 1150 - = 1430 1330-1730 @ OCF meeting venue (Prague, colocated with W3C WoT) -- Joint meeting of OCF, W3C WoT, and T2TRG (UTC+01:00 times) From nobody Sat Feb 24 03:40:36 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D38412D7F4; Sat, 24 Feb 2018 03:40:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no 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 66eyOxDlR00E; Sat, 24 Feb 2018 03:40:33 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14BBF12D7ED; Sat, 24 Feb 2018 03:40:32 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 4A3F2494BC; Sat, 24 Feb 2018 12:40:29 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 5B91856; Sat, 24 Feb 2018 12:40:28 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::db8]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 13B4BC3; Sat, 24 Feb 2018 12:40:28 +0100 (CET) Received: (nullmailer pid 21772 invoked by uid 1000); Sat, 24 Feb 2018 11:40:27 -0000 Date: Sat, 24 Feb 2018 12:40:27 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: draft-silverajan-core-coap-protocol-negotiation@ietf.org Cc: Core WG mailing list Message-ID: <20180224114026.GA4265@hephaistos.amsuess.com> References: <20180223150833.GA26617@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PNTmBPCT7hxwcZjr" Content-Disposition: inline In-Reply-To: <20180223150833.GA26617@hephaistos.amsuess.com> User-Agent: Mutt/1.9.3 (2018-01-21) Archived-At: Subject: [core] protocol-negotiation and web linking X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Feb 2018 11:40:35 -0000 --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Bill and Mert, during the review of protocol-negotiation, I came up with an idea that is too far off from the document to go directly into a review. It might be an overdose of web-linking talking here, so feel free to dismiss it if need be, but maybe there are ideas in it that can help bring on p-n. Let me start with examples and then explain what they should mean: | Req: GET coap://node1/.well-known/core | Res: 2.05 Content, Payload: | <>;alt-base=3D"coap+tcp://node1", | ;if=3D"core.s" or when registering at the RD: | Req: POST /rd?ep=3Dnode1&con=3Dcoap://node1 | <>;alt-base=3D"coap+tcp://node1", | ;if=3D"core.s" | Res: 2.01 Created, Location: /reg/1234 The endpoint registering at the RD could update the alt-base value(s) of the link like it would update any other link it manages. (Admittedly, that part of RD got postponed; might look like PATCH /reg/1234, Payload {"1": {"href": "", "alt-base": ["coap+tcp://node1:1234"]}} in some upcoming JSON link patch format). Resource lookups would stay the same. Asking a server directly for alternative transports could be done with GET /.well-known/core?alt-base=3D* or /.well-known/core?alt-base=3Dcoap+ws://*. This would be a dedicated request rather than piggy-backing onto any existing one with a new option, but we're doing the same with any of the other resource metadata as well, and a .well-known/core discovery is often the first step in interaction anyway. One way to give the protocol negotiation meaning to this would be only two normative sentences: | An "alt-base" attribute on a link means that representations of the link | target are equally valid if the attribute's value were assigned as Base | URI of the encapsulating entity (RFC3986 Section 5.1.2) for the purpose | of resolving relative references in the document. URIs obtained from the | representation using any alt-base value are all related to the URI | obtained from the same reference without considering the alt-base | attribute by the "alternative" relation (and therefore to each other, as | that relation is transitive). (I've picked the "alternative" relation here; see my review comments on the `ol` attribute. If no link relation is deemed suitable and you stay with `ol`, the second sentence would need to say that they are "equivalent for all REST operations supported by their protocols".) The approach of transmitting the URI data in link attributes is motivated by the RD's desire to not be anything more than a cache of what can be discovered using .well-known/core discovery. The explanation of being an "alternative Base URI" rather than a generic alternative transport could be a middle ground between saying that only a single URI is available somewhere else and saying that everything on this address is available there: It only makes statements about the links in the presented document. This would allow groups of resources to state their equivalences. The approach suggested here has some drawbacks: It is a bit more verbose in terms of transmitted bytes, and requires constrained nodes to synthesize variable data into payload that we usually take pride in being able to assemble at build time. If there is interest in the approach at all, I think we can overcome those. Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --PNTmBPCT7hxwcZjr Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlqRTycACgkQOY0REtOk veE50BAAmeqw+p0EQH5KZTBZfh4ZjaMRkMz+VWxdIvrRBxs1ApUOlKWqqFg4JnSh 1szAuetEEjeqg8gF2Cf+ybaA0vT6077x8bBPyP4lAYMuwKGobS1pEw6vAtBDSH3N qbBEBaApofUw2rGBMxVEm/R4rAVc1t/XG7AD3Qz5PSti9P+A1q3jkkCwxOrM7z2g YxAL8NYQknQ8oNm/WFGWypi19i4CcP+jeTdgb8TeNgCwlwCJMMXISrgqeQIr1Ez4 9Q2Pd+uAwBWJcEl9QuLUWy3qP26YXHCloP61+Q75endDcYASNWnSFEMV/0padD9X JRshhJalLyczutLiB6MYTlggEAINbKab13/l8VostSNfOoqZHrG8G/6XMyAgR0nw aw00bqTYfGDR353qgWTD/JjfSPR0OO9VzC2h0pnhq5tV8tBjtEJ4CaOv10uvHb/1 cH1Se6+oULci7bOYP7y+yVA41wuWnWNkIpD1426NSph2eJ+A3ZcAw2wkyEVFJ3q2 /3mM6g910XOIQrtCY8tTvVL4rGSJogzKEZTGVrEWQzT/AJk0SReA6jm4fendIwu3 iA3AktMGn/tfIu2JnsUGbINPDfCcn3kISmyPBNVZEc36sy6kUa3BAQqFfqNbSmYx jkZ3Cc7A6Vy3QornKJBQg6/1tJr59S6GqTVDIBgzal9eCeZcLt0= =kiZa -----END PGP SIGNATURE----- --PNTmBPCT7hxwcZjr-- From nobody Sun Feb 25 09:47:04 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46623126D05; Sun, 25 Feb 2018 09:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no 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 3RsaQx3-bgm9; Sun, 25 Feb 2018 09:47:01 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49942126C83; Sun, 25 Feb 2018 09:47:01 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w1PHkvnY003589; Sun, 25 Feb 2018 18:46:57 +0100 (CET) Received: from [192.168.217.114] (p5DC7EAF5.dip0.t-ipconnect.de [93.199.234.245]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3zqC814LVZzDXrm; Sun, 25 Feb 2018 18:46:57 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: <5A8849F5.6070703@isode.com> Date: Sun, 25 Feb 2018 18:46:56 +0100 Cc: draft-ietf-core-object-security.authors@ietf.org, "core@ietf.org WG" X-Mao-Original-Outgoing-Id: 541273615.212896-f1ad5ee8898984905f11a4ed05331acc Content-Transfer-Encoding: quoted-printable Message-Id: <043B8327-B717-44A0-9266-A6531FD3A8C7@tzi.org> References: <5A8849F5.6070703@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [core] AD review of draft-ietf-core-object-security-08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Feb 2018 17:47:03 -0000 On Feb 17, 2018, at 16:27, Alexey Melnikov = wrote: >=20 > 3) In Section 9: Does "osc" target attribute need to be registered = with > IANA? Some more details about this one: RFC 5988 decided not to create a registry for link target attributes, = and its replacement, RFC 8288, sustained this decision. RFC 6690 went ahead and defined two sub-registries for *values* of the = link target attributes =E2=80=9Crt=E2=80=9D and =E2=80=9Cif=E2=80=9D. = Still, the target attribute names themselves are registered nowhere. A 6690bis effort may very well want to create a registry here, now that = RFC 8288 says about Target Attributes (Section 2.2): They can be defined both by individual link relation types and by link serialisations. This specification does not attempt to coordinate the name of target attributes, their cardinality, or use. Those creating and maintaining serialisations SHOULD coordinate their target attributes to avoid conflicts in semantics or syntax and MAY define their own registries of target attributes. So, in addition to individual link relation types, RFC6690 or a = successor specification, as a serialization of Web Links, is the place = where such a registry could be defined. Until that happens, OSCORE is exactly right in proceeding in the same = way RFC 7641 (Observe) did for =E2=80=9Cobs=E2=80=9D. Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Feb 25 13:29:53 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC70120454; Sun, 25 Feb 2018 13:29:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no 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 VCpUMVPM5yQi; Sun, 25 Feb 2018 13:29:48 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F47E120724; Sun, 25 Feb 2018 13:29:48 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w1PLTfsn028083; Sun, 25 Feb 2018 22:29:41 +0100 (CET) Received: from [192.168.217.114] (p5DC7EAF5.dip0.t-ipconnect.de [93.199.234.245]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3zqJ51005NzDXsy; Sun, 25 Feb 2018 22:29:40 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: Date: Sun, 25 Feb 2018 22:29:40 +0100 Cc: draft-ietf-core-links-json@ietf.org, core@ietf.org X-Mao-Original-Outgoing-Id: 541286978.545785-fc18ad8e872123d78d13a3335fbf7089 Content-Transfer-Encoding: quoted-printable Message-Id: <53E184FA-7370-4B64-BE86-D88ABA10B313@tzi.org> References: <20171214114204.GA31455@hephaistos> To: =?utf-8?Q?Christian_Ams=C3=BCss?= X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [core] Links-json: proposal for revision addressing IETF last-call comments X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Feb 2018 21:29:51 -0000 On Dec 14, 2017, at 16:31, Carsten Bormann wrote: >=20 > Hi Christian, >=20 > (Speaking as a core-links-json co-author:) >=20 > We indeed have experienced a shift of focus here. >=20 > When the work on links-json started, seamless roundtripping with RFC = 6690 link-format was the foremost objective. >=20 > But, in the meantime, seamless integration into the larger Web world = (both Big Web and Thing Web) was become of foremost importance. >=20 > Three aspects of RFC 6690 are in the way here: > =E2=80=94 it is based on RFC 5988, which has been superseded by RFC = 8288, with many problems solved =E2=80=94 in particular the handling of = starred attributes (such as title*) can be much simplified now. > =E2=80=94 it uses a rather simplified form of resolving percent = encoding, which works great for limited use cases, but prevents its = seamless use with Web applications that may employ more complex percent = encoding. > =E2=80=94 it has unusual rules for resolving relative links, which is = the point that you are referring to. >=20 > We can work around the third problem by only using absolute links, = which will be the fix for RD for now. >=20 > The deviation of RFC 6690 from the relative link handling that would = be usual for RFC 8288 (and, actually, also for RFC 5988 already) was a = feeble attempt to get some URI compression into the format (relative = URIs can be shorter than absolute ones). This kind of works, for = certain use cases, but is brittle. A better way is to go back to = absolute links and address the URI compression objective separately, = maybe even in a different RFC. This does need some thinking. (I may be = worth to remember that RDF has been using a form URI compression from = the outset, and we may want to learn from there =E2=80=94 see also = link-employing formats such as CORAL!) >=20 > So the next step is to integrate these learnings into links-json and = come up with a new version. > This will obviously need another WGLC before we hand it back to the = IESG. =20 > By addressing this heads-on, the process should also fix the blocking = issues that got it stuck in the IESG, so we should be able to finish = this soon. Based on these considerations, I have generated a draft = draft-ietf-core-link-json-10 that I plan to submit tomorrow for wider = review. This is rebased on RFC 8288 (which supersedes RFC 5988), uses IRIs to = navigate around at least some of the percent-encoding issues we = identified, and adds language-tagged values. Comments are welcome! The draft draft is still in the WG SVN (yes, it is *that* old): = https://svn.tools.ietf.org/svn/wg/core/draft-ietf-core-links-json-xx.txt Diff from previously submitted I-D: = https://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-core-links-json-09.txt&ur= l2=3Dhttps://svn.tools.ietf.org/svn/wg/core/draft-ietf-core-links-json-xx.= txt or https://goo.gl/VPfUDX for short. Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Feb 25 18:25:32 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ECEC1243F3; Sun, 25 Feb 2018 18:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 NqgyYDBao7Rc; Sun, 25 Feb 2018 18:25:28 -0800 (PST) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 2B2CD120713; Sun, 25 Feb 2018 18:25:28 -0800 (PST) Received: by mail-oi0-x233.google.com with SMTP id c83so9606079oib.1; Sun, 25 Feb 2018 18:25:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=tELK1iZ+irKROTHc6Ddc/b3zLMbpg3W/4Si85y7LpMw=; b=i8EKXFcAlydpOLRqerFWBg3tml/IPioj54bRVhidnemCuc+qp+k34oCHosjxGXnhTr eVlJVc1U1DiTPIVrJvANKhjRErBTEj+e4byLWDNkbp0+hERkQ9qb3WBVPylqC/mB54eK DQpE5xGofvYOqC7EzINKbAyzYAnT7BboC25HGRfvToercnKTvfyo9mAbUHIv++1L5arb qjMwLFX+LEdRTtiQre9kkVOQVnbZazfxZoTLmABPXmiaH/f2UdhIIqEI16LT7YFdYSOx ZVRDr7DcYVdAckBJDfS2jcPHdlGyUpUMcdoua2wlpQgiKV8ZRLSdFOLgNAnLkqmIQjmh VDwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=tELK1iZ+irKROTHc6Ddc/b3zLMbpg3W/4Si85y7LpMw=; b=jfwgXNuqfNOLr/e4YrCPod2jTgXIhsBWAneGaxRphJO+XOC9sbEgtS51dtLHTP6EYn OoBjyXe9W/KDaB/A1XUYmt+GCCn5tVyOvwChSQzVWrtl3rrbN0aSXIqkUBEGZ3/Z/AqH O/XRNiA8q53J/Eo5xd2uIy8qxggDHNhDLKbl2E4xU1tfEOn5/p9YlySgs6Wspq2y78mI vEz9wschhAluz+Ghblms6YlCQ2UcbNeq+DmNTSHwnWnsxirPguQofsiuItSDFso/wRq8 ywiZieqYKSp8TH+X9L0HnRu0Y+lNSqK4J7moC40z69V1uwsJCFN9EanODKYd5mV/9/DG qDdw== X-Gm-Message-State: APf1xPDRqf2Xbmo1HSuB87O0DKGCJyqZAFl6nwVG+S7J4V37ofSxE+ba hXTbWT+ZQR/hcVXXkEwiT24efMxgiEKZajq9jpIV5Q== X-Google-Smtp-Source: AG47ELtFX9yXDAeEpszegBev95W9RYosbDVkCtgNLQdO+qi/nIHOqe24npIJSAqVfcoibqXekCpm/WgkKemJbpOZlu8= X-Received: by 10.202.94.196 with SMTP id s187mr5466438oib.144.1519611927332; Sun, 25 Feb 2018 18:25:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.16.85 with HTTP; Sun, 25 Feb 2018 18:25:27 -0800 (PST) In-Reply-To: <20180224114026.GA4265@hephaistos.amsuess.com> References: <20180223150833.GA26617@hephaistos.amsuess.com> <20180224114026.GA4265@hephaistos.amsuess.com> From: Martin Thomson Date: Mon, 26 Feb 2018 13:25:27 +1100 Message-ID: To: =?UTF-8?Q?Christian_Ams=C3=BCss?= Cc: draft-silverajan-core-coap-protocol-negotiation@ietf.org, Core WG mailing list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] protocol-negotiation and web linking X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 02:25:30 -0000 Just a tourist, but can someone explain why this design needs to be so fundamentally different to RFC 7838? Making the means by which a resource is identified differ based on the means of interaction is something we have tried hard to avoid in HTTP. Or maybe this is the key point of divergence between HTTP and COAP and any attempt to address this is a lost cause. On Sat, Feb 24, 2018 at 10:40 PM, Christian Ams=C3=BCss wrote: > Hello Bill and Mert, > > during the review of protocol-negotiation, I came up with an idea that > is too far off from the document to go directly into a review. It might > be an overdose of web-linking talking here, so feel free to dismiss it > if need be, but maybe there are ideas in it that can help bring on p-n. > > Let me start with examples and then explain what they should mean: > > | Req: GET coap://node1/.well-known/core > | Res: 2.05 Content, Payload: > | <>;alt-base=3D"coap+tcp://node1", > | ;if=3D"core.s" > > or when registering at the RD: > > | Req: POST /rd?ep=3Dnode1&con=3Dcoap://node1 > | <>;alt-base=3D"coap+tcp://node1", > | ;if=3D"core.s" > | Res: 2.01 Created, Location: /reg/1234 > > The endpoint registering at the RD could update the alt-base value(s) of > the link like it would update any other link it manages. (Admittedly, > that part of RD got postponed; might look like PATCH /reg/1234, Payload > {"1": {"href": "", "alt-base": ["coap+tcp://node1:1234"]}} in some > upcoming JSON link patch format). > > Resource lookups would stay the same. Asking a server directly for > alternative transports could be done with GET > /.well-known/core?alt-base=3D* or /.well-known/core?alt-base=3Dcoap+ws://= *. > This would be a dedicated request rather than piggy-backing onto any > existing one with a new option, but we're doing the same with any of the > other resource metadata as well, and a .well-known/core discovery is > often the first step in interaction anyway. > > One way to give the protocol negotiation meaning to this would be only > two normative sentences: > > | An "alt-base" attribute on a link means that representations of the lin= k > | target are equally valid if the attribute's value were assigned as Base > | URI of the encapsulating entity (RFC3986 Section 5.1.2) for the purpose > | of resolving relative references in the document. URIs obtained from th= e > | representation using any alt-base value are all related to the URI > | obtained from the same reference without considering the alt-base > | attribute by the "alternative" relation (and therefore to each other, a= s > | that relation is transitive). > > (I've picked the "alternative" relation here; see my review comments on > the `ol` attribute. If no link relation is deemed suitable and you stay > with `ol`, the second sentence would need to say that they are > "equivalent for all REST operations supported by their protocols".) > > > The approach of transmitting the URI data in link attributes is > motivated by the RD's desire to not be anything more than a cache of > what can be discovered using .well-known/core discovery. > > > The explanation of being an "alternative Base URI" rather than a generic > alternative transport could be a middle ground between saying that only > a single URI is available somewhere else and saying that everything on > this address is available there: It only makes statements about the > links in the presented document. This would allow groups of resources to > state their equivalences. > > > The approach suggested here has some drawbacks: It is a bit more verbose > in terms of transmitted bytes, and requires constrained nodes to > synthesize variable data into payload that we usually take pride in > being able to assemble at build time. If there is interest in the > approach at all, I think we can overcome those. > > > Best regards > Christian > > -- > To use raw power is to make yourself infinitely vulnerable to greater pow= ers. > -- Bene Gesserit axiom > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From nobody Mon Feb 26 02:54:26 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9BD9126DCA for ; Mon, 26 Feb 2018 02:54:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 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 R7Boumi3F99z for ; Mon, 26 Feb 2018 02:54:22 -0800 (PST) Received: from lb1-smtp-cloud9.xs4all.net (lb1-smtp-cloud9.xs4all.net [194.109.24.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8EC1126CB6 for ; Mon, 26 Feb 2018 02:54:22 -0800 (PST) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:215]) by smtp-cloud9.xs4all.net with ESMTPA id qGQFeBFNSwC4EqGQFeAUir; Mon, 26 Feb 2018 11:54:19 +0100 Received: from AMontpellier-654-1-186-134.w92-145.abo.wanadoo.fr ([92.145.165.134]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 26 Feb 2018 11:54:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 26 Feb 2018 11:54:19 +0100 From: peter van der Stok To: Core Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <151963922478.31478.9450242369979488900.idtracker@ietfa.amsl.com> References: <151963922478.31478.9450242369979488900.idtracker@ietfa.amsl.com> Message-ID: <7dbaebcd27310388dd4fd0e2e3968609@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfJThgGM06znsCmajYa/SfGa6zBR7LFo2QFzBbs/1LKaxd3bjGwFrKmU2nXTZodhdJj21ECbHFpQ22BRrRm9VU3rrwBYV6FWhtrQ5bbgzW/Kd5suIIZ37 w82BFeNxjtzQbVgWemk6OleYg5UpqKPK+T9hVRY/x+7YacHw4XBjszeQWjGswFUWI2wVFzV6/4gglRc6CiTPNS/Vxslr5sEmEiM= Archived-At: Subject: [core] Fwd: New Version Notification for draft-hartke-core-pending-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 10:54:25 -0000 Hi Core, a new version of the pending draft is submitted. The current version does not try to extend one already dedicated response code or create a new one. Klaus and Peter A new version of I-D, draft-hartke-core-pending-02.txt has been successfully submitted by Klaus Hartke and posted to the IETF repository. Name: draft-hartke-core-pending Revision: 02 Title: "Pending" Responses for the Constrained Application Protocol (CoAP) Document date: 2018-02-26 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-hartke-core-pending-02.txt Status: https://datatracker.ietf.org/doc/draft-hartke-core-pending/ Htmlized: https://tools.ietf.org/html/draft-hartke-core-pending-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-hartke-core-pending-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-hartke-core-pending-02 Abstract: This document proposes a new type of response for the Constrained Application Protocol (CoAP) called a "Pending" response. A CoAP server can use a Pending response to indicate that it has accepted a request but has not yet started processing it or that processing the request will take longer than a client is typically willing to wait for a response. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Mon Feb 26 03:01:28 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9690D126DCA for ; Mon, 26 Feb 2018 03:01:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no 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 ZOYfpGoIVzJW for ; Mon, 26 Feb 2018 03:01:25 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67B54126CB6 for ; Mon, 26 Feb 2018 03:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w1QB1Mfm025621; Mon, 26 Feb 2018 12:01:22 +0100 (CET) Received: from client-0005.vpn.uni-bremen.de (client-0005.vpn.uni-bremen.de [134.102.107.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3zqf5Z1LyGzDWTv; Mon, 26 Feb 2018 12:01:22 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: <7dbaebcd27310388dd4fd0e2e3968609@xs4all.nl> Date: Mon, 26 Feb 2018 12:01:21 +0100 Cc: Core X-Mao-Original-Outgoing-Id: 541335679.896718-116afafe9f9d5a84c00c223d6a73e0a7 Content-Transfer-Encoding: quoted-printable Message-Id: <92499CF0-46E3-4FF9-82F7-797D29369558@tzi.org> References: <151963922478.31478.9450242369979488900.idtracker@ietfa.amsl.com> <7dbaebcd27310388dd4fd0e2e3968609@xs4all.nl> To: peter van der Stok X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [core] Fwd: New Version Notification for draft-hartke-core-pending-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 11:01:26 -0000 On Feb 26, 2018, at 11:54, peter van der Stok = wrote: >=20 > The current version does not try to extend one already dedicated = response code or create a new one. No, but the draft seems to bend the semantics of existing response = codes? I think that is mainly a problem with 2.02, which means the resource is = gone, but in this case it isn=E2=80=99t really gone just yet? I=E2=80=99d rather provide that information in the body (the actual = media type behind the content-format needs to be defined, anyway). Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Feb 26 03:16:48 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3F7126CB6 for ; Mon, 26 Feb 2018 03:16:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NO_DNS_FOR_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_TEMPERROR=0.01] autolearn=no autolearn_force=no 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 zHrzUMPWk9qw for ; Mon, 26 Feb 2018 03:16:46 -0800 (PST) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEF5D126D74 for ; Mon, 26 Feb 2018 03:16:44 -0800 (PST) Received: from mail-qk0-f181.google.com ([209.85.220.181]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1eqGlu-0006n0-B1; Mon, 26 Feb 2018 12:16:42 +0100 Received: by mail-qk0-f181.google.com with SMTP id z197so18543570qkb.6 for ; Mon, 26 Feb 2018 03:16:42 -0800 (PST) X-Gm-Message-State: APf1xPDS7htTersqpkMRwX1Rd4yV/EoGAMbZAndEAJz1sMpmXbJG3ukj OqKCG3s88uBtFe8FSm4sXkloi+UEDdG0UTf95dI= X-Google-Smtp-Source: AG47ELv74t3tc5fPF2qgpEmnt99YSKhJYGm5XFWgRthmwXHfrxJYcNXROtcXerr4V2INIX5mKVoEaA4OM0IfcDnwQvM= X-Received: by 10.55.15.7 with SMTP id z7mr16307033qkg.312.1519643801351; Mon, 26 Feb 2018 03:16:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.134.195 with HTTP; Mon, 26 Feb 2018 03:16:01 -0800 (PST) In-Reply-To: <92499CF0-46E3-4FF9-82F7-797D29369558@tzi.org> References: <151963922478.31478.9450242369979488900.idtracker@ietfa.amsl.com> <7dbaebcd27310388dd4fd0e2e3968609@xs4all.nl> <92499CF0-46E3-4FF9-82F7-797D29369558@tzi.org> From: Klaus Hartke Date: Mon, 26 Feb 2018 12:16:01 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Core Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1519643805; a3067daa; X-HE-SMSGID: 1eqGlu-0006n0-B1 Archived-At: Subject: Re: [core] Fwd: New Version Notification for draft-hartke-core-pending-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 11:16:47 -0000 Carsten Bormann wrote: >> The current version does not try to extend one already dedicated respons= e code or create a new one. > > No, but the draft seems to bend the semantics of existing response codes? Not really. Or, at least, it shouldn't, although it appears a bit like it due to the renamed response codes. The idea is just that the content-format encourages the client to poll/observe until it gets another content-format. This should work with unaware intermediaries; only the two ends need to understand it. > I think that is mainly a problem with 2.02, which means the resource is g= one, but in this case it isn=E2=80=99t really gone just yet? Good point. Maybe we should restrict it to GET, PUT, and POST? > I=E2=80=99d rather provide that information in the body (the actual media= type behind the content-format needs to be defined, anyway). The content-format is defined to be absent or a human-readable diagnostic message (second to last paragraph in Section 2). It might be worth being able to include application-specific status information, but I don't have a good idea yet how to indicate the content-format of that. Klaus From nobody Mon Feb 26 09:45:58 2018 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F4A126D73; Mon, 26 Feb 2018 09:45:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151966715682.31492.16725065682951816740@ietfa.amsl.com> Date: Mon, 26 Feb 2018 09:45:56 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-links-json-10.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 17:45:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : Representing Constrained RESTful Environments (CoRE) Link Format in JSON and CBOR Authors : Kepeng LI Akbar Rahman Carsten Bormann Filename : draft-ietf-core-links-json-10.txt Pages : 20 Date : 2018-02-26 Abstract: JavaScript Object Notation, JSON (RFC 8259) is a text-based data format which is popular for Web based data exchange. Concise Binary Object Representation, CBOR (RFC7049) is a binary data format which has been optimized for data exchange for the Internet of Things (IoT). For many IoT scenarios, CBOR formats will be preferred since it can help decrease transmission payload sizes as well as implementation code sizes compared to other data formats. Web Linking (RFC 8288) provides a way to represent links between Web resources as well as the relations expressed by them and attributes of such a link. In constrained networks, a collection of Web links can be exchanged in the CoRE link format (RFC 6690). Outside of constrained environments, it may be useful to represent these collections of Web links in JSON, and similarly, inside constrained environments, in CBOR. This specification defines a common format for this. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-links-json/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-links-json-10 https://datatracker.ietf.org/doc/html/draft-ietf-core-links-json-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-links-json-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 27 15:17:45 2018 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F55E12EAF4; Tue, 27 Feb 2018 15:11:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: core@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151977307825.5200.15557873754993173620.idtracker@ietfa.amsl.com> Date: Tue, 27 Feb 2018 15:11:18 -0800 Archived-At: Subject: [core] core - Requested sessions have been scheduled for IETF 101 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 23:11:21 -0000 Dear Carsten Bormann, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. core Session 1 (2:00:00) Tuesday, Morning Session I 0930-1200 Room Name: Viscount size: 175 --------------------------------------------- core Session 2 (2:00:00) Monday, Afternoon Session I 1330-1530 Room Name: Richmond/Chelsea/Tower size: 75 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Constrained RESTful Environments Area Name: Applications and Real-Time Area Session Requester: Carsten Bormann Number of Sessions: 2 Length of Session(s): 2 Hours, 2 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: cbor httpbis artarea t2trg suit ace lpwan 6lo roll teep Second Priority: dnssd saag irtfopen 6tisch netconf netmod sacm emu Third Priority: lwig detnet quic v6ops opsarea cfrg icnrg People who must be present: Carsten Bormann Alexey Melnikov Jaime Jimenez Resources Requested: Special Requests: Please also avoid any IoT related BOFs. Many WG contribtrs this time are moving onward on Thu eve/Fri to the Prague OCF/W3C meetings. It would be preferable to have no meetings after Thu lunch. --------------------------------------------------------- From nobody Wed Feb 28 22:41:45 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8319612422F for ; Wed, 28 Feb 2018 22:41:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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_MED=-2.3, RCVD_IN_MSPIKE_H4=-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 (1024-bit key) header.d=ericsson.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 36UMcdLYenEB for ; Wed, 28 Feb 2018 22:41:42 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E37261241F8 for ; Wed, 28 Feb 2018 22:41:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519886500; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=9CsE5qdg8uXz7bLoJzmcmUw1lMMyhuUv0A2dWm82f5s=; b=H9ABRIrKtpvCIpfIMb0u2CtJ2O4wt7AuO/eSx8u1F7l+Fd1DOtSG47GXz3X640Qh MamZEeXDnripnzzHBbEDKExv+raqsGTu9HeoKzpM6RcZE5UgHvlbJHuuR9JDYUSp +iFuJKKtZTivXrs7mNLjbcqqSNajDRzU77Qi8S83G4w=; X-AuditID: c1b4fb3a-728f89c0000067b4-38-5a97a0a426ef Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 72.94.26548.4A0A79A5; Thu, 1 Mar 2018 07:41:40 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0352.000; Thu, 1 Mar 2018 07:41:03 +0100 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: Alexey Melnikov CC: Cullen Jennings , Carsten Bormann , "core@ietf.org WG" Thread-Topic: [core] AD review of draft-ietf-core-senml-12 Thread-Index: AQHTiyDu0BM6qxYgikiCexhp7NumuKO7KZuA Date: Thu, 1 Mar 2018 06:41:02 +0000 Message-ID: <1FCFDFB2-EA6E-4994-9A4C-86B30F531B47@ericsson.com> References: <5A57D346.8070301@isode.com> In-Reply-To: <5A57D346.8070301@isode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [87.95.226.8] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsUyM2K7ge6SBdOjDP5uF7CYsbrI4siUu6wW +96uZ7bomMzmwOIx5fdGVo8lS34yeZxqNvSYtigzgCWKyyYlNSezLLVI3y6BK2P3hR+sBZfd K/52XGBsYLxs2cXIySEhYCKxqX8XcxcjF4eQwGFGic2PrrFBOIsYJZovf2cDqWITsJeYvOYj I4gtIqAvsfrVLBYQm1kgR+LTqm9gNcIClhJvLjWwQ9RYSbxsb4OyjSTeTWoCsjk4WARUJO6s UwIJ84KMPLyKCcQWEtCQ2PH7HdgYTgFNiSsvpoK1MgqISXw/tYYJYpW4xK0n85kgjhaQWLLn PDOELSrx8vE/VghbXmLG2VtQ9XoSN6ZOYYOwrSXaVy1ih7C1JZYtfM0McYOgxMmZT1gmMIrN QrJiFpL2WUjaZyFpn4WkfQEj6ypG0eLU4uLcdCMjvdSizOTi4vw8vbzUkk2MwLg7uOW31Q7G g88dDzEKcDAq8fCu7J8eJcSaWFZcmXuIUYKDWUmE9/T2aVFCvCmJlVWpRfnxRaU5qcWHGKU5 WJTEeZ3SLKKEBNITS1KzU1MLUotgskwcnFINjH29N9nL7+88wXLIhN9JP+8114+oixONv5sf OnFYzrTnbuelRXnzGuZ8vms7o0je+vPvGyya6+W3+He9/rvNsP2qvXcvrzTLoVUXNC+2ScQu uHj2MXP8Kou/G/8d7O9hefxQVyizftaVvN9RT69LWVbO3v5R/mCQ8CKLJM8ven/NHjSZJik0 HFRiKc5INNRiLipOBACwlQhFtwIAAA== Archived-At: Subject: Re: [core] AD review of draft-ietf-core-senml-12 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 06:41:44 -0000 Hi Alexey, Thank you for the review! And sorry for the late reply. We have now address= ed all your comments in the PR 98: https://github.com/core-wg/senml-spec/pull/98 Also see answers to your comments inline. Cheers, Ari > On 11 Jan 2018, at 23.12, Alexey Melnikov wro= te: >=20 > Hi, > I nearly finished my review (I still need to double check a few things > on fragment identifiers and media type registration compatibility with > base media types like application/xml). I think the document is > generally in a good shape, but there are a few things that we need to be > fixed or discussed first. >=20 > I will also ask for a couple of extra reviews of this document. >=20 > Major: >=20 > 1) In order to be able to register application/senml+exi and > application/sensml+exi, +exi suffix needs to be registered (+json, +xml > and +cbor are already registered. See > ). > There is separate registration procedure for this. Note that there was > already a discussion about registering +exi and a Designated Expert > opinion was that EXI is not a generic encoding format (JSON, CBOR and > XML are) that can be decoded without knowing schemaID. The WG can argue > against this point, but I am not convinced that the WG will convince the > Designated Expert otherwise. >=20 > If you don't want to register the +exi suffix, the easiest fix to the > document is to change "+" in application/senml+exi and > application/sensml+exi to "-", as "-" doesn't have special semantics > associated with suffixes. Fixed by changing to "-exi" as you suggested and was discussed in this thre= ad already. >=20 > 2) The following omissions are pretty easy to fix, but I think they are > important enough for readers of documents: >=20 > First references to UTF-8, XML, Relax NG, XML Schema need Normative > References. (Some of these are missing Normative References, some of > these are just missing them on first use.) Added references for each. > I also suspect that some IESG members will have an opinion that the CDDL > reference is Normative. So you might need to choose between making CDDL > reference Normative (which will result in this document not being > published until CDDL draft is also approved for publication) and > removing CDDL definition from the document. Clarified that this is informative (similar text was OK with earlier RFC): As a convenient reference, the JSON and CBOR representations can be described with the common CDDL [I-D.ietf-cbor-cddl] specification in Figure 1 (informative). > Minor: >=20 >=20 > Section 2: >=20 > Some devices have accurate time while others do not so SenML supports > absolute and relative times. Time is represented in floating point > as seconds and values greater than zero represent an absolute time > relative to the Unix epoch while values of 0 or less represent a >=20 > Does Unix epoch need a reference? Added reference to the POSIX spec and added new clarifying text: Time is represented in floating point as seconds. Values greater than zero represent an absolute time relative to the Unix epoch (1970-01-01T00:00Z in UTC time) and the time is counted same way as the Portable Operating System Interface (POSIX) "seconds since the epoch" [TIME_T]. Values of 0 or less represent a relative time in the past from the current time. > relative time in the past from the current time. >=20 > 3. Terminology >=20 > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in > [RFC2119]. >=20 > I suggest you switch to the updated phrasing that allows for lowercase > "must", etc: >=20 > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in > BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all > capitals, as shown here. Fixed as suggested. > In 4.4 >=20 > Although it is RECOMMENDED that concatenated names are represented as > URIs [RFC3986] or URNs [RFC8141], the restricted character set > specified above puts strict limits on the URI schemes and URN > namespaces that can be used. >=20 > I understand that this phrasing is a result of discussions in the WG. Is > it possible/useful to point out some typical URI schemes that can't be > used here, such as HTTP/HTTPS/COAP? Added two examples: However, the restricted character set does not allow the use of many URI schemes, such as the 'tag' scheme [RFC4151] and the 'ni' scheme [RFC6920], in names as such. > In Section 5: >=20 > The mantissa SHOULD > be less than 19 characters long and the exponent SHOULD be less than > 5 characters long. >=20 > The above two SHOULDs: is the above sufficient for interoperability? > What would happen if the SHOULD is not followed? The SHOULDs are there to facilitate efficient parsing of the data. We added= this: In the interest of avoiding unnecessary verbosity and speeding up processing, the mantissa SHOULD be less than 19 characters long and the exponent SHOULD be less than 5 characters long. > In 5.1.2: >=20 > SenML defines a > separate media type to indicate Sensor Streaming Measurement Lists > (SensML) for this usage (see Section 12.3.2). >=20 > It would be good to mention something about this in the IANA > registrations for media types, as on a cursory look one can think that > there are lots of duplicated registrations. Added to 12.3 (Media Type Registrations):=20 This document registers media types for each serialization format of SenML (JSON, CBOR, and EXI) and also media types for the same formats of the streaming use (SensML). > I just want to double check regarding binary data in XML. I assume there > is a need to use XML escaping for bytes not otherwise allowed in XML? It > might be worth pointing this out to avoid naive (and buggy) implementatio= ns. Base64 encoding is used with binary data: https://tools.ietf.org/html/draft= -ietf-core-senml-12#section-7 > The following comment applies to all media type registrations: >=20 > 12.3.1. senml+json Media Type Registration >=20 > Interoperability considerations: Applications should ignore any JSON > key value pairs that they do not understand. This allows backwards > compatibility extensions to this specification. The "bver" field can > be used to ensure the receiver supports a minimal level of > functionality needed by the creator of the JSON object. >=20 > Is it worth mentioning here special treatment of keys that end with "_": >=20 > Implementations MUST ignore fields they don't recognize unless that > field has a label name that ends with the '_' character in which > case an error MUST be generated. >=20 > (The above text is from page 7. Might need to reword it in the media > type registration template)? Changed this to: Interoperability considerations: Applications MUST ignore any JSON key value pairs that they do not understand unless the key ends with the '_' character in which case an error MUST be generated. This allows backwards compatible extensions to this specification. And similar changes to all other registrations. > In Section 13: >=20 > You should also mention that defined formats don't include executable > content. (Media Type reviewers typically ask this question) Added to Section 13: The SenML formats defined by this specification do not contain any executable content. However, future extensions could potentially embed application specific executable content in the data. > Nits: >=20 > Abstract >=20 > This specification defines media types for representing simple sensor > measurements and device parameters in the Sensor Measurement Lists > (SenML). Representations are defined in JavaScript Object Notation > (JSON), Concise Binary Object Representation (CBOR), eXtensible > Markup Language (XML), and Efficient XML Interchange (EXI), which > share the common SenML data model. A simple sensor, such as a > temperature sensor, could use this media type in protocols such as >=20 > this media type --> one of these media types Fixed. > HTTP or CoAP to transport the measurements of the sensor or to be > configured. >=20 >=20 > First references to HTTP, COAP, S/MIME and TLS need Informative Reference= s. Fixed. > 12.1. Units Registry >=20 > IANA will create a registry of SenML unit symbols. The primary > purpose of this registry is to make sure that symbols uniquely map to > give type of measurement. >=20 > give --> given Fixed. > Best Regards, > Alexey >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core