From nobody Fri Oct 1 01:23:13 2021 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 6D64A3A0113; Fri, 1 Oct 2021 01:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 MBsbr4fPkz5K; Fri, 1 Oct 2021 01:23:05 -0700 (PDT) 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 5F8133A0A25; Fri, 1 Oct 2021 01:23:02 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id D25734174C; Fri, 1 Oct 2021 10:22:58 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id E254CD7; Fri, 1 Oct 2021 10:22:55 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:57cf:9775:915b:5002]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 9281313C; Fri, 1 Oct 2021 10:22:55 +0200 (CEST) Received: (nullmailer pid 3462502 invoked by uid 1000); Fri, 01 Oct 2021 08:22:55 -0000 Date: Fri, 1 Oct 2021 10:22:55 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Dan Garcia Carrillo Cc: EMU WG , "ace@ietf.org" , Rafa Marin-Lopez , core@ietf.org Message-ID: References: <0cfd2df3-9264-b6fd-e58b-a93a7d8fda5f@uniovi.es> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="L5Xh2gZWNTasjqlQ" Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [core] [Ace] CoAP-EAP draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 01 Oct 2021 08:23:12 -0000 --L5Xh2gZWNTasjqlQ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, (picking some easy targets to advance, not touching parallel or earlier discussion), On Fri, Sep 10, 2021 at 10:42:56AM +0200, Dan Garcia Carrillo wrote: > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 IoT device=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 Controller > > =A0=A0=A0=A0=A0=A0=A0=A0=A0 +------------+=A0=A0=A0=A0=A0=A0=A0 +------= ------+ > > =A0=A0=A0=A0=A0=A0=A0=A0=A0 | EAP peer/=A0 |=A0=A0=A0=A0=A0=A0=A0 | EAP= auth./ |+-----+[ AAA infra. ] > > =A0=A0=A0=A0=A0=A0=A0=A0=A0 | CoAP server|+------+| CoAP client|+-----+= [ EAP server?] > > =A0=A0=A0=A0=A0=A0=A0=A0=A0 +------------+=A0 CoAP=A0 +------------+=A0= EAP? > > =A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0 \_____ Scope of th= is document _____/ > >=20 > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Figu= re 1: CoAP-EAP Architecture > >=20 > [Authors] This is a good point. We did not include it at first, as having= a > AAA infrastructure is not mandatory. But the optionality can also be > expressed in the figure. We will consider using this for the next version. > Please also be aware that this architecture including AAA is assuming > something called EAP authenticator in pass-through mode. Nevertheless, an > EAP authenticator in standalone mode is also possible, where no AAA exist= s. Maybe it helps to emphasize the components then (which I probably got wrong in the image) -- there's the (existing / unmodifed) EAP server in the controller, which now gains the CoAP transport, and optionally passes on the data to some AAA infrastructure: | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 IoT device=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 Controller AAA infrastructure | =A0=A0=A0=A0=A0=A0=A0=A0=A0 +------------+=A0=A0=A0=A0=A0=A0=A0 +--------= ----+--------+ (optional) | =A0=A0=A0=A0=A0=A0=A0=A0=A0 | EAP peer/=A0 |=A0=A0=A0=A0=A0=A0=A0 | EAP a= uth./ | EAP | | =A0=A0=A0=A0=A0=A0=A0=A0=A0 | CoAP server|+------+| CoAP client| server |= +-----+[ ...] | =A0=A0=A0=A0=A0=A0=A0=A0=A0 +------------+=A0 CoAP=A0 +------------+-----= ---+ |=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0 \___ Scope of this document ___/ |=20 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Figure= 1: CoAP-EAP Architecture > > * (Bycatch of suggesting URIs): It may be worth mentioning that the > > =A0=A0 NON's source address can easily be spoofed. Thus, any device on = the > > =A0=A0 network can trigger what the authenticator may think of as a > > =A0=A0 device-triggered reauthentication, and the device may think of a= s an > > =A0=A0 authenticator-triggered reauthentication (provided it works that= way, > > =A0=A0 see below when reauthentication is mentioned again). > > [Authors] But this case would not be possible since we mention that (re) > authentication is initiated by the device. Thus, when the device sees an > authenticator triggered re-authentication will discard that. If authenticators don't reauthenticate, then fine. (But I wonder: What happens to an established context if, for example, the authenticator finds that a used credential just wound up on a CRL?). > > * Proxying: As it is right now, this protocol just barely works across > > =A0=A0 proxies, and only if they support CoAP-EAP explicitly. (And whil= e it > > =A0=A0 may sound odd to even consider that, bear in mind that they are = used > > =A0=A0 in a very similar way in RFC9031). > >=20 > > =A0=A0 While it's a bit open whether all CoAP-based protocols should > > =A0=A0 reasonably be expected to work across proxies or not, a remark (= maybe > > =A0=A0 before 3.1?) that "If CoAP proxies are used between EAP peer and= EAP > > =A0=A0 authenticator, they must be configured with knowledge of this > > =A0=A0 specification, or the operations will fail after step 0." >=20 > [Authors] Based on your comment, it seems there is no guarantee that any > CoAP-based protocol would work across proxies. Our question is whether th= ere > is any adaptation or change that would favour working through proxies. At > the research level, we worked with proxy and you are right, our assumption > is that proxies support CoAP-EAP explicitly > (https://ieeexplore.ieee.org/document/8467302).=A0 Since we are trying > to avoid right now anything tailored to CoAP-EAP and only using CoAP > as a means of transport for the exchange, why do you think this would > not work with proxies? A CoAP-based protocol in general works across proxies if it doesn't use any of the following: * Options that are not safe-to-forward * The role-reversal address (without a means to indicate an address more explicitly) This document does not use new options, but the initiation step uses the role-reversal address. The part where the controller is the CoAP client and the device is the CoAP server should work through any proxy -- but the initial step means that the initial CoAP server (the controller) looks at its role-reversal address (the source of the request). As it is now, a proxy that facilitates EAP-CoAP would need to recognize that first message and send it from a port dedicated to forwarding to that client. Allowing the client to set its address would not do away with all the issues, but at least paint a way out. > > > * 3.3.1: "after the maximum retransmission attempts, the CoAP client > > > =A0=A0 will remove the state from its side". > > >=20 > > > =A0=A0 So the device that's being kicked from the network can delay i= ts own > > > =A0=A0 eviction for about a minute as long as it doesn't answer? > > >=20 > [Authors] This is an interesting use case. To avoid this, we may have to > change the behaviour, to a NON-message and just remove the state. The application can grant a grace time if the reason for eviction warrants it -- but it should be the application / its reason guiding that time, not the OK. > > * OSCORE derivation: Is it cryptographically necessary to derive *both* > > =A0=A0 a master secret and a master salt through KDF? (Sounds like a > > =A0=A0 needless step to me, as both only go into KDF once more when the > > =A0=A0 actual OSCORE parameters are derived). I *guess* there's a good = reason > > =A0=A0 why the MSK is not used as the OSCORE IKM right away and the CSO= as > > =A0=A0 OSCORE master salt, but it'd help to have at list a comment here= on > > =A0=A0 why that's needed. > >=20 > > =A0=A0 (It may be useful to compare this step to the HKDF steps in OSCO= RE; > > =A0=A0 their info element is always a 5-element array with a 4th "type" > > =A0=A0 element of "Key" or "IV"; other extractions might just hook in t= here > > =A0=A0 with different type values, maybe, and save everyone an extra ha= ndling > > =A0=A0 step). > > [Authors] You are right, there should be a clarification on why this is d= one > the way it is. The main purpose is to use MSK=A0 as the root key for key > derivation. It is common practice with the usage of the MSK. If say key w= ere > compromised, another one could be derived from the MSK, without having to > resort to a new bootstrapping to refresh the MSK. But is ther an actual way to get different keys out of the same MSK? (Because if there's not, I don't see how it helps with that goal). > > > =A0=A0 * If the parties happen to be assigned the same sender ID, bad= things > > > =A0=A0=A0=A0 happen (identical key derivation, nonce reuse, nuclear m= eltdown). > > >=20 > > > =A0=A0=A0=A0 If the current pattern of KDF'ing IDs stands, this needs= to be > > > =A0=A0=A0=A0 prevented explicitly. >=20 > [Authors] Since the Sender and recipient IDs, are derived from the MSK, > which is assumed to be fresh key material, I think this should not be a > problem. It's not an issue of freshness but of chances of collisions. The length is limited (like 5 bytes depending on suite IIRC), and the birthday paradox can hit. BR c --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --L5Xh2gZWNTasjqlQ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmFWxVwACgkQOY0REtOk veHTAg/+IU3QlXygzIVL4R2qZsq6PmvnZ6TwRLklJuRNnlEGIbVe1n6UvwCZ/eeU QihNe/OubpU7gqLnm4vtWVQCkns0L9mtQHA1tPLUxXfFfJ3ZpPSLne5c/8bfd3eZ pBNjVt0E0u3lz+5wKoLD0bhJKBflGMhOVfvKCsBim05IPDQpZC3sbHicuIJaPy3U hVJ4driv/ecb6QObe//U5yTxhgwF+1nBvgShT1fTa7lVtNy+UVggYtuUU74TK/S3 t/WvWi0h+kaDniiD7WL2kuhdFgEp9qGiQzsmGkTk5J1HYMM+iOVtl0uooYXn5Mfc KW6j6fSxp+5LKlClQnO9AEmGlyTQgOu/21yhJbN8TRvwL0FTVwYmhkxAQkFIi8ag oKJ8lCDFq5Ej/lms/BL1LXHWk8IMk3bVpdUXrgrggpi59vZnCP1xBBeSgDoERi9L JwUlokr+NXEyuBGtGUygK/7lF7qnsqKqc1JMNmaoO6fHb2GW0v18IvGnbso2R+Gw KTgkCppoCmspEUtdO2EmfEXIlS05CyEm/ADIWx8ecoL5LtURToKIIbk/pSt+wTJ0 CAqmDairf6aBnpSF4zLto95M5+OnTJiEQDKOAfghvlsWQUOEmEK+G2PAIJp5E6CG dvRrvElvSlb4ameTxYJAQ20zjlkNHJEw4Kw8COW0qyx1VH/lXXY= =Keyk -----END PGP SIGNATURE----- --L5Xh2gZWNTasjqlQ-- From nobody Mon Oct 4 05:40:44 2021 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 2C0253A005F; Mon, 4 Oct 2021 05:40:24 -0700 (PDT) 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: 7.38.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <163335122409.28723.1569095506416646305@ietfa.amsl.com> Date: Mon, 04 Oct 2021 05:40:24 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-echo-request-tag-14.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2021 12:40:25 -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: Echo, Request-Tag, and Token Processing Authors : Christian Amsüss John Preuß Mattsson Göran Selander Filename : draft-ietf-core-echo-request-tag-14.txt Pages : 41 Date : 2021-10-04 Abstract: This document specifies enhancements to the Constrained Application Protocol (CoAP) that mitigate security issues in particular use cases. The Echo option enables a CoAP server to verify the freshness of a request or to force a client to demonstrate reachability at its claimed network address. The Request-Tag option allows the CoAP server to match block-wise message fragments belonging to the same request. This document updates RFC 7252 with respect to the client Token processing requirements, forbidding non-secure reuse of Tokens to ensure binding of response to request when CoAP is used with a security protocol, and with respect to amplification mitigation, where the use of Echo is now recommended. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-echo-request-tag/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-core-echo-request-tag-14.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-echo-request-tag-14 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 4 05:43:46 2021 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 3A7023A0061; Mon, 4 Oct 2021 05:43:45 -0700 (PDT) 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, SPF_HELO_NONE=0.001, 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 rbZ71590KqAZ; Mon, 4 Oct 2021 05:43:40 -0700 (PDT) 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 F1E253A0060; Mon, 4 Oct 2021 05:43:38 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 3D590401F6; Mon, 4 Oct 2021 14:43:35 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id A8C6AD7; Mon, 4 Oct 2021 14:43:33 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:e391:3670:36c5:b026]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id E9A3113C; Mon, 4 Oct 2021 14:43:27 +0200 (CEST) Received: (nullmailer pid 108222 invoked by uid 1000); Mon, 04 Oct 2021 12:43:27 -0000 Date: Mon, 4 Oct 2021 14:43:27 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Benjamin Kaduk , Francesca Palombini Cc: The IESG , draft-ietf-core-echo-request-tag@ietf.org, core-chairs@ietf.org, core@ietf.org Message-ID: References: <163034634166.17431.14820107713355769156@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cyrMV12GMDC6bd6U" Content-Disposition: inline In-Reply-To: <163034634166.17431.14820107713355769156@ietfa.amsl.com> Archived-At: Subject: Re: [core] Benjamin Kaduk's No Objection on draft-ietf-core-echo-request-tag-13: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 04 Oct 2021 12:43:45 -0000 --cyrMV12GMDC6bd6U Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Ben, Francesca, On Mon, Aug 30, 2021 at 10:59:01AM -0700, Benjamin Kaduk via Datatracker wr= ote: > I only have editorial/nit-level comments remaining. thanks, they're now in the uploaded -14. I think we're done here :-) BR Christian --=20 A beginning is the time for taking the most delicate care that the balances are correct. -- Princess Irulan, Manual of Muad'Dib --cyrMV12GMDC6bd6U Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmFa9usACgkQOY0REtOk veEbvhAAqgBUCojCnuCfR6CzPkIJmVoVb6TI7G1Gs4J29Q0F3zT7k4eQiy1Hs+D5 Ogz1ixnEGdv9XvAlpSb3Q/fih9W64w7qLq8p4Lcak1JcrkTVYasqwbc/iEG3C1sY NCZMBgCOlridJE++L7w093yf4fhx7u/6KmA4PATtZGhLoSxySyMbW2ZHIFJIA9kv w0N2uSOhixxm5QfeT1va5UL0f2Eu2aRkxlqqgYbSeX3XAelCc7E3+Y1hHzzOfaoD 5QxyGZgt7JVdkN6F6BFTwDnVNQjDYs0SZKQ8CfpENp2e61YfBKJ/gd6StZoWaaDA vLq/hND2fAb4abNq2eK1erEfTkvXkjdjZvlTJz7Nmho8Fq51qeBDIRq86UHcw7zK 9BQCxvDL9ytGm4RMVsWxP0aGk2KLEHC+TeafR2iDhsQvS0Sgcfjl1fEhaOZ0UzUY CyTwiAoflt3XGsijMe5lTeVraUqCwjrLmf+BBigwrsj5fIUfOY94SXza7zKeid7R P6fhlfP0yRD06ED4q3QpbX2wJhsALIR0Z9BbmxaOPzcF80Jaj/eMZ/q7ceD64Urs YLDtM0RXTYCvCzD4l2vvK5B468Pm+sImN4xLCw0Gua84zK4uTOqR5CAWEJAVbQnw Z6rDUWakJWGZz6SDSeQ59M336RW1utdQ+/8Gmey+iidrcmcDR04= =C5UP -----END PGP SIGNATURE----- --cyrMV12GMDC6bd6U-- From nobody Fri Oct 8 09:17:49 2021 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 ECC813A05DE; Fri, 8 Oct 2021 09:17:35 -0700 (PDT) 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: 7.38.0 Auto-Submitted: auto-generated Precedence: bulk Cc: Marco Tiloca , The IESG , core-chairs@ietf.org, core@ietf.org, draft-ietf-core-echo-request-tag@ietf.org, francesca.palombini@ericsson.com, marco.tiloca@ri.se, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <163370985594.28895.16278536032772383866@ietfa.amsl.com> Date: Fri, 08 Oct 2021 09:17:35 -0700 Archived-At: Subject: [core] Protocol Action: 'CoAP: Echo, Request-Tag, and Token Processing' to Proposed Standard (draft-ietf-core-echo-request-tag-14.txt) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2021 16:17:36 -0000 The IESG has approved the following document: - 'CoAP: Echo, Request-Tag, and Token Processing' (draft-ietf-core-echo-request-tag-14.txt) as Proposed Standard This document is the product of the Constrained RESTful Environments Working Group. The IESG contact persons are Murray Kucherawy and Francesca Palombini. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-core-echo-request-tag/ Technical Summary This document specifies enhancements to the Constrained Application Protocol (CoAP) that mitigate security issues in particular use cases. The Echo option enables a CoAP server to verify the freshness of a request or to force a client to demonstrate reachability at its claimed network address. The Request-Tag option allows the CoAP server to match block-wise message fragments belonging to the same request. This document updates RFC7252 with respect to the client Token processing requirements, forbidding non-secure reuse of Tokens to ensure binding of response to request when CoAP is used with security, and with respect to amplification mitigation, where the use of Echo is now recommended. Working Group Summary / Document Quality The document has been discussed in multiple IETF meetings, and has gone through multiple expert reviews. Consensus has been reached on the content of this document and its need. Personnel Document Shepherd: Marco Tiloca Area Director: Francesca Palombini From nobody Fri Oct 8 16:31:42 2021 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 BDB273A0DDA; Fri, 8 Oct 2021 16:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 oTLJnpSwu6Tl; Fri, 8 Oct 2021 16:31:02 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87C733A0DD8; Fri, 8 Oct 2021 16:31:02 -0700 (PDT) Received: from [192.168.217.118] (p5089a8ac.dip0.t-ipconnect.de [80.137.168.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4HR4FH13G9z2xkP; Sat, 9 Oct 2021 01:30:59 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 655428658.42018-0b94f61088342db8154d8c955dad3dae Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Sat, 9 Oct 2021 01:30:58 +0200 Message-Id: To: ace@ietf.org, Core , cose@ietf.org, cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: [core] Constrained Node/Network Cluster @ IETF112: DRAFT AGENDA X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 08 Oct 2021 23:31:08 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF112. Remember that there is still quite some potential for changes. The IoT-relevant conflicts that most meet the eye this time are ASDF/LAKE/RATS and IOTOPS/COSE. All times are in UTC. Note that the first week in November (W44) is the Week of Confusion, where DST has ended in Europe but not yet in North America. https://datatracker.ietf.org/meeting/agenda-utc might be handy. Gr=C3=BC=C3=9Fe, Carsten (### DST ENDS IN EUROPE ###) MONDAY, November 1, 2021 1500-1600 Hackathon Kickoff Rm 1 GEN hackathon Hackathon WEDNESDAY, November 3, 2021 1330-1500 IETF Plenary - Plenary FRIDAY, November 5, 2021 1500-1700 Hackathon Closing Rm 1 GEN hackathon Hackathon (### DST ENDS IN NORTH AMERICA ###) MONDAY, November 8, 2021 1200-1400 Session I Rm 1 ART dispatch Dispatch WG - Joint with ARTAREA Rm 6 SEC *** rats Remote ATtestation ProcedureS WG Rm 7 TSV masque Multiplexed Application Substrate over = QUIC Encryption WG 1430-1530 Session II Rm 2 INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Rm 5 RTG rift Routing In Fat Trees WG Rm 7 SEC *** suit Software Updates for Internet of Things = WG Rm 8 TSV tsvwg Transport Area Working Group WG 1600-1800 Session III Rm 1 ART *** core Constrained RESTful Environments WG Rm 3 INT madinas MAC Address Device Identification for = Network and Application Services WG TUESDAY, November 9, 2021 1200-1400 Session I Rm 1 ART webtrans WebTransport WG Rm 2 INT add Adaptive DNS Discovery WG Rm 6 RTG raw Reliable and Available Wireless WG Rm 7 SEC secdispatch Security Dispatch WG 1430-1530 Session II Rm 1 ART sedate Serialising Extended Data About Times = and Events WG Rm 2 INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Rm 3 IRTF maprg Measurement and Analysis for Protocols Rm 6 SEC *** ace Authentication and Authorization for = Constrained Environments WG 1600-1800 Session III Rm 3 INT 6man IPv6 Maintenance WG Rm 4 IRTF irtfopen IRTF Open Meeting Rm 8 SEC tls Transport Layer Security WG WEDNESDAY, November 10, 2021 1200-1400 Session I Rm 2 ART jsonpath JSON Path WG Rm 3 INT intarea Internet Area Working Group WG Rm 6 RTG detnet Deterministic Networking WG Rm 8 TSV quic QUIC WG 1430-1530 Session II Rm 2 ART uta Using TLS in Applications WG Rm 4 RTG babel Babel routing protocol WG Rm 6 RTG *** roll Routing Over Low power and Lossy = networks WG Rm 7 SEC openpgp Open Specification for Pretty Good = Privacy WG Rm 8 TSV tsvarea Transport Area Open Meeting 1600-1800 Session III Rm 1 ART wpack Web Packaging WG Rm 3 OPS anima Autonomic Networking Integrated Model = and Approach WG THURSDAY, November 11, 2021 1200-1400 Session I Rm 3 IRTF cfrg Crypto Forum Rm 4 IRTF coinrg Computing in the Network Research Group Rm 7 SEC gnap Grant Negotiation and Authorization = Protocol WG 1430-1530 Session II Rm 1 ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Rm 3 INT *** drip Drone Remote ID Protocol WG Rm 4 IRTF pearg Privacy Enhancements and Assessments = Research Group Rm 6 OPS v6ops IPv6 Operations WG Rm 7 RTG bier Bit Indexed Explicit Replication WG Rm 8 SEC acme Automated Certificate Management = Environment WG 1600-1800 Session III Rm 2 IRTF panrg Path Aware Networking RG Rm 6 SEC saag Security Area Open Meeting FRIDAY, November 12, 2021 1200-1400 Session I Rm 2 ART httpapi Building Blocks for HTTP APIs WG Rm 4 OPS v6ops IPv6 Operations WG - Joint with 6MAN Rm 6 SEC dance DANE Authentication for Network Clients = Everywhere WG Rm 7 SEC *** teep Trusted Execution Environment = Provisioning WG 1430-1530 Session II Rm 1 ART *** asdf A Semantic Definition Format for Data = and Interactions of Things WG Rm 5 RTG rtgarea Routing Area Open Meeting Rm 6 SEC *** lake Lightweight Authenticated Key Exchange = WG Rm 7 SEC *** rats Remote ATtestation ProcedureS WG Rm 8 TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1600-1700 Session III Rm 3 INT dnssd Extensions for Scalable DNS Service = Discovery WG Rm 4 OPS *** iotops IOT Operations WG Rm 7 SEC *** cose CBOR Object Signing and Encryption WG Rm 8 TSV tsvwg Transport Area Working Group WG From nobody Mon Oct 11 02:10:52 2021 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 350B73A0D94; Mon, 11 Oct 2021 02:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 zocj7taLiThV; Mon, 11 Oct 2021 02:10:45 -0700 (PDT) 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 9A4EA3A0D91; Mon, 11 Oct 2021 02:10:44 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id B4DAF400D8; Mon, 11 Oct 2021 11:10:40 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id CB3CF106; Mon, 11 Oct 2021 11:10:35 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:58a:38c7:d462:d25e]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 80DFF10A; Mon, 11 Oct 2021 11:10:35 +0200 (CEST) Received: (nullmailer pid 1445517 invoked by uid 1000); Mon, 11 Oct 2021 09:10:35 -0000 Date: Mon, 11 Oct 2021 11:10:35 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Dan Garcia Carrillo Cc: core@ietf.org, EMU WG , Rafa Marin-Lopez , "ace@ietf.org" Message-ID: References: <0cfd2df3-9264-b6fd-e58b-a93a7d8fda5f@uniovi.es> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="CGi3ylTd1ybX+vat" Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [core] [Ace] CoAP-EAP draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 11 Oct 2021 09:10:50 -0000 --CGi3ylTd1ybX+vat Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Dan & Rafa, On Fri, Sep 10, 2021 at 10:42:56AM +0200, Dan Garcia Carrillo wrote: > > * OSCORE ID derivation: > >=20 > > =A0=A0 * Randomly assigned full-length ideas look like an odd choice. > > [...] > >=20 > > =A0=A0=A0=A0 Any chance something like that can still make it in? > > [Authors] Did not see that as random but parametrised according to the > crypto suite. We will try to make this as straightforward as possible > following your comments. the construction we recently discussed (where both peers decide actively on the OSCORE Recipient IDs (or client ID for DTLS) they'd later want to use as inputs to EAP) would resolve this issue conveniently. (See coming follow-up in "About securing last exchange CoAP-EAP"[1] on how this makes things easier over there). BR c [1]: https://mailarchive.ietf.org/arch/msg/emu/bnMFV4_1uTW7sSwVOp7WzVZZCAI/ --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --CGi3ylTd1ybX+vat Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmFj/4YACgkQOY0REtOk veGByRAAgYKYNn+JtuqiGFlm0QRiRr4n6mfYZ810kDOhuFq2tCX7FCAHSBqFX4bc h666tC4D/Jld6/2d3bENdfiUMm2y60db12eRPLUQFSJtFVq8dDXUiuMxQVHBay/A ksQoEe0C8okUNT6ihrTD08FO4g/+XqQyrkd8U/VUbwrJrQNQT/0GKUhHiD091lgR DxRW/gG9pTeDUSO86WMDqXdy2ltr1dZ9to4DEWba+TWSucA47oXQNKYZ0mlMUpwc hC6DqvKSyki1FTBog2Ceapd27GnFHacDhZKSpTfuknHzk9X2KDCpBzdN8t4E9aga Vv5mF0MZJHFxBwSrG7rVzXD4wK7dmVgX4yK55hiZyuWML3HKg8uHPIM19z+6t/pm OjAS4jWm1cs0GWbW9HP7L1MWdyrLisI5hNsi+MPsh+dK73n5qX+ddEB+9m3rTrfz LJzh4PjPcfTQTb2rZgcyaaSRal/blVB70s9LBZS2r1m3osCsKvyTUd84XJdrXcHZ pnuFIghbjN/VwIbs7lSElq2+aimIen7Qa+3IX1N6ejNeL9lc6GXdSqiUysRAYh+D Dy5mwTyUlagLHfYC+4ODGtyF/+fDnC3eYNUnQLLX0yYwGowwS6kGpcffIcsG2FMB tIwGpCrDhqrgOIKCApeuSrNfTvw6rHdDM6iesTUYSgW2iHLUICw= =9Y3F -----END PGP SIGNATURE----- --CGi3ylTd1ybX+vat-- From nobody Mon Oct 11 08:38:20 2021 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 8BC983A08AC for ; Mon, 11 Oct 2021 08:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=ri.se 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 DntnBUkZSEj1 for ; Mon, 11 Oct 2021 08:38:12 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2054.outbound.protection.outlook.com [40.107.20.54]) (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 2AFCE3A088C for ; Mon, 11 Oct 2021 08:38:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LxsCZdH7mOxr35jz+5AUr+8n/llqOBxUvgEoMCVeRZo57Vq+OZ1t7OW/WYZ05DvrlMbBMdkNPaNXhT+S+RbwVnOLXYH4jcMJWf7xPPaeCR3wHTcPNvqgpSUEh99gGIU2aZhY53vAVfIfhPY/2U/unBe8umd6nCWra97goxia92Haoj/acB9wo1nzOexIwh8AX3Np1SkxNwRv9PiPbyM/SZlgcthG4D+47Vs8+RbZBN6qLjMAvuQIn3CGkT4HHir+BCncAF6modHyOWmLk0u41kJ9R5FhDkEzdaCpp6j+7U/cx9A+YvT0nXSjUUaqKuB6IzrhqAFJBTs6F3gNANnLHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=dF9DgX7T7IOJUfwVfiJXJCRy9abQJC/7tVh97H5ql8s=; b=UDZ6KPMu/YVw375jIUXYsoKtIYBaaeTwnoWIGh+TGrUXcOUonHAjZC/IK0A5myV5r4O8zI59j0yyGhQM4KRC6qM4xefVCMesr7qAHhRuVLy29Bj8wzNAOeX/KYvSaChOhtqdntFnwDuUhTiinBnCwRfXYmNulpM+zkXH3RZL3yvedKzayQ7VgRxb0rSsmL78qKsTSNOEtOvcaMoO9eYNysKPUiZpnCGEbnAaZ5r37uKfdMZkf0xRxdsssXom6b9a6D9fIPUVIf3TxPHnuxWaV8YcdpFywbOjeUUfLZKrI5LstuPgpDAJTewYxaNUy1iVL+Yefftm3rEKNqoQuk9SKA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dF9DgX7T7IOJUfwVfiJXJCRy9abQJC/7tVh97H5ql8s=; b=Hc5+21B0YQcGhYALEF+m92cp84oKCLCd3CbAe6UGi0BOa+Wp/qHoeU8ssLdxZd3P4yx0bf6sKQ+jN7alok2c+FrUGj5wfpT/enBWdXzMech9Al1IHdg7HGLvwxq0To4Li/4jKDXbnNAzl+Q50m4OjMMzLPtvsZ4Kn5m7NpDW9dM= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DBBP189MB1465.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:1ea::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.22; Mon, 11 Oct 2021 15:38:06 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::4dd0:ed4b:e776:d560]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::4dd0:ed4b:e776:d560%3]) with mapi id 15.20.4587.026; Mon, 11 Oct 2021 15:38:06 +0000 To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca Message-ID: Date: Mon, 11 Oct 2021 17:38:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="CORU9bnp5uZ7Q1rVflpgRpGkf4DfVvcgo" X-ClientProxiedBy: GV3P280CA0001.SWEP280.PROD.OUTLOOK.COM (2603:10a6:150:b::31) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 Received: from [10.8.0.2] (185.219.140.94) by GV3P280CA0001.SWEP280.PROD.OUTLOOK.COM (2603:10a6:150:b::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.18 via Frontend Transport; Mon, 11 Oct 2021 15:38:05 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: bb50958c-e26a-4b41-cb30-08d98ccd1e84 X-MS-TrafficTypeDiagnostic: DBBP189MB1465: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:6108; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: A33qbVFOMbIvLVQvxo/iuqmayiwjANzMJphuAqXnTJKMnaW9rW00LDfvzGUQLxU3+LKZTDdqVOKP30WHqiTbzApGZ0fn2qINCdUQgks6PcMsvbopy98kPamFsK8jkZdhz9YTqeVLsv5172X2wrJ/9KrK7sxxvWaBI8bU0em+gavSIiJPHS4nZqDaOZvJsHU/rBoZKxLffxasVKUNKMO6jL7sHUaPDWA6kNvnAOWr2eGT/XmfHR6zb4nt00QviwxedMbKXzrcXkBqnmKU2U9+vJDdg8bkhI4rneIax4bly4Tgu0y3cLnDZSxw6BjYaykN+0kZwuIGXh8zWNC8gRs6o4c66yysAuFLPRa4ZlZYI1fNpAw2pw+OQh71JyuaORkcEheJSg16yJc6S7jgxQonMafmh0Ia9P9pMNkib9WjmHWOBVnwBa+CFYsfq62dr3CWLrzd3F5MyO2w4yAVXfLBBwm+roqHpWl+LfaVL5NHzZZMcTfejJfmcRF6/2elk9x297tMdw+cb623n7yuxqm3QIUVwMQmXjlgyDzZUu9qUdNVeNmJqh/jb9uR1cwY9AipnLkp/Sa4RpXykeKCXjC3xyDwh0lbJ5C1VEewlWSjFsg14SK54LddS+ChDUK09p6ZZdfI07AAbr4uCemt6ZDqdTgOpB2IqL+7G+LvcKZNeBJAvkpVICRc8YvRbXWzTbVxWfe7aDmRQzZmeSMlRMpZWOFpYbPQRyWDKSqYYNcyR2yQLy0BXxD7pHejZPtqmKV4kbazsbqYni9Mw/EABKrU2AaXqTw1nkt1l+nJ8CKxiQ6MzQIdq3PU787y9pYkaX9h X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(2906002)(2616005)(31696002)(5660300002)(508600001)(6486002)(956004)(235185007)(44832011)(33964004)(86362001)(966005)(66946007)(4001150100001)(186003)(66556008)(66574015)(26005)(316002)(21480400003)(8676002)(16576012)(8936002)(31686004)(38100700002)(6916009)(83380400001)(36756003)(66476007)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?alMzYzFyU0xMdEJZNnMwOXl1d3MrbUVLRnF1R2pyand3YitnaXVRYWNDZmRi?= =?utf-8?B?TU8vejAxQmdtL0l5YVR2S2Rxbm80cmZ3aDdoZ2dSaEp5bmhSYkFqV3UvVE9Y?= =?utf-8?B?NW44VlN0K2JnQ29mSUgvaEJiUlhyTDN1ZXExS0ZhN3Q0aXpUL0ZxQ2VNRFlQ?= =?utf-8?B?SUExbnl0NWRTakFJTjI1WTRuRW5ZYjZyOFlBQkFsMmNLODJQYi9tYzN1QXFR?= =?utf-8?B?eks4Y1ZiV0ZCRytMRmFyY0NsVkRTZkM2UEdjd0FKZ3EwT0l1azhtRlkzSnhr?= =?utf-8?B?OE9FUHlmRG4yd2Qrdk1vajMybW5oWkl1TGZDbHZBZ1ZyS0tzWUZzNDlsYndr?= =?utf-8?B?aUVqcXhJempaSnc1enNua2xmUVpGSWtSV1djaSthbkttOFFjcS93N2Nabmw4?= =?utf-8?B?SkxJNEdZZWM1SW9EWVN2WWl5blgyNXQzM1VOUU1Wb002YnY4dTVXYTVwTFp4?= =?utf-8?B?dHpxblRNRGdKajc1Z0kvYXZ1NDQyRGxJRmhUd3RHa2pqaytqM0t1UUFXVzZ4?= =?utf-8?B?bnZScFZNY2JLd3gwb2ZFY2ZSMDdsWlZ6cGVORzFvdFV1VkNhZWZPV3JUQ2FG?= =?utf-8?B?MW5EOGJZK2psVzZNaHhBRldwZVMreTV0VE1Tei9wZEptdWx3aDJZQXpjZEQ2?= =?utf-8?B?Znp3ZlptSjY1MVhla2R3VkRKUzlNdU5kMk5WSWFabFFCS3laV2FsTlROc0Zy?= =?utf-8?B?YVRkc2Q4R1ZSVFN0WjBRb1NOOGJJdXR4NTZBQ0prZ0hKNEl1dW1tZG9vKzVZ?= =?utf-8?B?ZENWNWJWMUljblpTZkRpY0hSSW1PYUM3bFhRVUx5djFDSXJjZC85NUw2MlBx?= =?utf-8?B?OThBVmFJL0xtSlJPZkdoL2ZZeGp5S3NNV00vanYwU3llaCtHMkRMQWhFOEl0?= =?utf-8?B?aVV4SUZ1UkVzbUFCUm81am9mQkt6TmJia2t0VVBOV2ZNajdXT3dWcnlXVDlF?= =?utf-8?B?d1hXeXRpS0E1eW5zeDJKN0h2Sm9VRkxvTmF0VU5adTZJWHhYUGhXMTdNdDRo?= =?utf-8?B?dFFnOSt5WEQ3clRzaWxRTEpDcFAzRXplWDc5clcrbGJqR0lWOFR4QlMxL2hs?= =?utf-8?B?N0MwNE8xK0Z3T3dBQ05DT2wraG5LSDkxaE10TDFJTmRSQ0wrb1Y3V3RzOU5w?= =?utf-8?B?bUZmeFpyUTVjbHVGcklWL1IzRldSRmJSWDBTY0d5cU44TU5ZcHlOZVVNZU5n?= =?utf-8?B?NHNVWERDdTIwcHdPRnpWaERLL0lRL2pOS3lYQ3o5SmJlRTFRWldOb2pRL2ZH?= =?utf-8?B?T0E1YmNBQjNsQU1YR1NsSU1Ed2lManBzOGVWWFRPNS9SV1I4VksyVWRYeG5G?= =?utf-8?B?Vk1tVnJHa0FkYnE0azZxU2NwWk1HMGF1ZHI4aXNZL0EwMkZ3UUdPR2x5bmZE?= =?utf-8?B?ZnJmNDZJWTdkak5iOVowSUpUV2JETU9UKzJVcVdmRFdmbmdHbWcrV3hDbVlU?= =?utf-8?B?VC9LbGtmK05rT0R6ZE9Md1kyZk9NUDVTUHJzU2pnMGVGYUxqY0crNXJLNW12?= =?utf-8?B?bk5oMW9mN2hZc2l6c29IVFhFR3ZBQStrKzYrVFJVZzh0aUlRRHNCdUgwN2RE?= =?utf-8?B?WkR2YUM5eTZjaHRod1J0dS9BODF0UXlwMEtKcDN6OGFwUnpPY2VYNEcxZldq?= =?utf-8?B?UnVCT3hPQzVOUHZZVXRNM3ZhanlJNzY0RWFoWFoyL3RLTWZFcncxTURHVDRu?= =?utf-8?B?TlBEQUZRd0FZekxIK2tyYzgwcHFZejBidFJ4S1hKdjZ3dGV4SExhakF4ZWpU?= =?utf-8?Q?shKs4qtVBiok6J0Vohbio/EqwNRDP88nWPl9dnf?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: bb50958c-e26a-4b41-cb30-08d98ccd1e84 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Oct 2021 15:38:05.9780 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: +jpoa6Yq+cKjFEq91qPphLrn+QcRdxVk9GVu+sRByVeOjNQYNnG8XP14E+U9qH2D08cDPD1ifNFVCkkj+QvtSQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBP189MB1465 Archived-At: Subject: [core] CoRE WG Virtual Interim 2021-10-13 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 11 Oct 2021 15:38:18 -0000 --CORU9bnp5uZ7Q1rVflpgRpGkf4DfVvcgo Content-Type: multipart/mixed; boundary="Tz9wFl79ZXlV9dSP5YJJlIcbWNnfM6yr0"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: Subject: [core] CoRE WG Virtual Interim 2021-10-13 --Tz9wFl79ZXlV9dSP5YJJlIcbWNnfM6yr0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, Just a reminder that we'll have a virtual interim meeting on Wednesday,=20 October 13th at 14:00 UTC. The agenda is available at [1]. As per the Datatracker, the meeting will be on Meetecho [2], while=20 minutes will be taken at [3]. Best, Marco and Jaime [1] https://datatracker.ietf.org/meeting/interim-2021-core-12/session/cor= e [2]=20 https://meetings.conf.meetecho.com/interim/?short=3D3cedb9b5-b3ec-4685-ab= 43-5bff97c4b642 [3] https://codimd.ietf.org/notes-ietf-interim-2021-core-12-core --=20 Marco Tiloca Ph.D., Senior Researcher Division: Digital System Department: Computer Science Unit: Cybersecurity RISE Research Institutes of Sweden https://www.ri.se Phone: +46 (0)70 60 46 501 Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) --Tz9wFl79ZXlV9dSP5YJJlIcbWNnfM6yr0-- --CORU9bnp5uZ7Q1rVflpgRpGkf4DfVvcgo Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmFkWlsFAwAAAAAACgkQ7iZktA5Y2kNU uAgAkQzkHWWkSxYQ2Zi5yleBbEPOE2IfrKHJQJso3IY07ACLgE6vZEtfahgyTWQKFuaVZzlGsrVI IXggNw32PfQsiG4GFQ+kYijvI5O83XxE1cGAEzzs2E839hcASIVHf+53dr0krIF0fv4alrLhuBdM P4uzKcsWs0riqgZ1OnWxG+Bt5jDfIueDCbQfcbghf+09h3wsEt5E23CBEn/YnwQtGW844WHVotn1 aBVCmUqcudpG5iuuOFoj2dHHbslPA7IlycU+ORrPbuVrXFzE2RQgFS8QuJbcdrfFS0xlX5v1T9eH L6EZg0KMVxEXjkb80IKodhP2HDVOa5cK3vSfDeYsWA== =1zEx -----END PGP SIGNATURE----- --CORU9bnp5uZ7Q1rVflpgRpGkf4DfVvcgo-- From nobody Tue Oct 12 00:59:29 2021 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 5C4C53A03FE; Tue, 12 Oct 2021 00:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=Xuoza8La; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=Xuoza8La 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 y6_310qC4jCP; Tue, 12 Oct 2021 00:59:24 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0611.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1f::611]) (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 C42393A074E; Tue, 12 Oct 2021 00:59:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JrceFjTgB4PZJvin5wNQWWSN5bdQlWK7p9rnVTWditM=; b=Xuoza8LaHwyHGvvv8DeQuI0lUzrG8EZjzqM5wMyKDcQPWRh/gBQqj4oW5KtIo0qoxbj7TizjILGNKz6Egur2Nv7apJKWdXyM//lhDLQDp7u3xlyrZ4Jsz3Dy1x9/9q94Aoj0RSNbyiYsl7yPL0snJLvQW0Nw8nXF5CgfxZa3Cpg= Received: from AS9PR06CA0329.eurprd06.prod.outlook.com (2603:10a6:20b:45b::35) by AM6PR08MB4835.eurprd08.prod.outlook.com (2603:10a6:20b:c3::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.22; Tue, 12 Oct 2021 07:59:11 +0000 Received: from VE1EUR03FT034.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:45b:cafe::c8) by AS9PR06CA0329.outlook.office365.com (2603:10a6:20b:45b::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.14 via Frontend Transport; Tue, 12 Oct 2021 07:59:11 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT034.mail.protection.outlook.com (10.152.18.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.18 via Frontend Transport; Tue, 12 Oct 2021 07:59:09 +0000 Received: ("Tessian outbound b9598e0ead92:v103"); Tue, 12 Oct 2021 07:59:09 +0000 X-CR-MTA-TID: 64aa7808 Received: from f8bb4336a454.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id D822059F-A6A1-478B-B0E8-90E5302288C2.1; Tue, 12 Oct 2021 07:59:03 +0000 Received: from EUR04-DB3-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id f8bb4336a454.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 12 Oct 2021 07:59:03 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jOReh/CY+CMi++7Rflx6wKMOmGePVuixEN6jryTuC7VpCEhl2cpvbHFDGAW1lKs/tjlx8gFfW3vl8pym2JCLqb3fvQcFYvUmPTxi9Ov5FjvVUFZA8waJ+CVIFmjnWHqqY22omH9nvGaESn6Ia+nhwav0m6qFHCirsHiIZKCUEPaK3edX22l1ysr/ebWp0LSenZ3uHX/BA7XyUkvw3BwyOvaOpdSLUgCRQ9RH+zxTHnESPc01GuunBT2rl9Bi9KmV42DAM7MDlFcnG10VpG6rEqEB6bFlUXT1mv6Bx+fe/sROfuDN2qUDf8nDJOXMN/23NWUAMm3lEfVXRc2l/68ycg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=JrceFjTgB4PZJvin5wNQWWSN5bdQlWK7p9rnVTWditM=; b=PQQkGkOG74pUAtrrvK1MIm82B09WdQ8pb3XaAdNr7Z2YzLj5ldmy1KJpDksrrHrIQnAnzKSP94+clK7upvNVKAfqPRUjmBd4yqfRkn1cCJfKcX2GuV19njkC5v+W5p4qiecOER26Awszt8x+gS5e5wEJqLWyRpckH1TrLksm4WDQf5RzqOg2D9nRB/dFxM/nErMGUg4E/bw4NWuEwsP2Ll5o9z+wnEcdcsdnyeqDRDiCpgEHflgxRel0pOrgCWorKLOOP/TS6sFe/K7rkFoClmGJJO5/p6Jt7qtW+5XCwE+iEhscVxGgOetGT4ANUHnHou6rCK7mFTmb2H3A+6bkwg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JrceFjTgB4PZJvin5wNQWWSN5bdQlWK7p9rnVTWditM=; b=Xuoza8LaHwyHGvvv8DeQuI0lUzrG8EZjzqM5wMyKDcQPWRh/gBQqj4oW5KtIo0qoxbj7TizjILGNKz6Egur2Nv7apJKWdXyM//lhDLQDp7u3xlyrZ4Jsz3Dy1x9/9q94Aoj0RSNbyiYsl7yPL0snJLvQW0Nw8nXF5CgfxZa3Cpg= Received: from DBBPR08MB5915.eurprd08.prod.outlook.com (2603:10a6:10:20d::17) by DB6PR0801MB1831.eurprd08.prod.outlook.com (2603:10a6:4:38::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.21; Tue, 12 Oct 2021 07:59:01 +0000 Received: from DBBPR08MB5915.eurprd08.prod.outlook.com ([fe80::4514:95de:c5e0:ddbe]) by DBBPR08MB5915.eurprd08.prod.outlook.com ([fe80::4514:95de:c5e0:ddbe%9]) with mapi id 15.20.4587.025; Tue, 12 Oct 2021 07:59:01 +0000 From: Hannes Tschofenig To: "core@ietf.org WG" , "ace@ietf.org" , "suit@ietf.org" Thread-Topic: Hackathon#112 Participation Thread-Index: Ade/Pv5ZqRziEqy8SaeaDOihwyXYcw== Date: Tue, 12 Oct 2021 07:59:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 26D1C333460F0244AD63D058E30762A5.0 x-checkrecipientchecked: true Authentication-Results-Original: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com; x-ms-publictraffictype: Email X-MS-Office365-Filtering-Correlation-Id: 9e26b1de-922c-413d-a951-08d98d562c3c x-ms-traffictypediagnostic: DB6PR0801MB1831:|AM6PR08MB4835: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: KPTL4k9V5vTK00C0N1dlQkdJ9RpjfiaZ7r7jG0op/UYGpc/ePhEhYpN1wj/SwzVmq+zeta/OJS5B5KHFtBoTeNppURGWpB8oY44kZVL8iV6aYf6M0v3Rb5gJ0bn/QA10y9HhG/+Ub0371sWDFrggWzSN7wMBxFBo1TED8NVAwi6VSes3GOF/YMwb+AdGH+lxYClwnmMzjFFCMI70EPmRG/19aeY6fxvuU69IA/Nj+0KFnG50L3uC95SMIbKRr1nebnn1xybAQKCVi4MbSGS89Q/V0nxkbyeCK3B/Ra9CUD/hPDI/QKY+3NjmUeOF8kNUvWw/0sMbv+1VuEAPlydYg1SUcf3QTIOQqWyaAA6L7Z0/kdt+1bmeezkYcGxoRDLa2T0kaYTGuYdNAqVKZ1fMtVLKz/Qft1KfXxoHKLWQizlXNWP8r+xew/OsaNGUgZlsCeFo5teSLrBOYRqx4pZwUhlCuX7O3lYrQr5cNlF0O2UXSoDyUKGvF6VfyBjfSYTfiS1Mc7u6RInaZqG71tpPexDZqlf+fo77ZqCAxOJ+SLsI1EsQPwmQl1UOt78IZQtiGL44i6aWgmnr+m6FlID4PG6Kj8ygwwlO0sUmTZz/CAszOdwQ/j1EDm+vcXxx6PsmqxeFI3jfbX42fN5/9PY0EmvzhEa9VdOV+OG4xPS+Yu4XptHtiKnm/9uE6+mbQvouBpKMALNZfshi/RZkKkCVdcq8bp8nPT7v+hmVmWYB9ZzdwW620hWWhIMIr7Q9bfYUdnUeza9CCBiaZsEdJt7TAAfK95jdSQfxcDAlSTqwxPE= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBBPR08MB5915.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(86362001)(66446008)(966005)(508600001)(64756008)(52536014)(38100700002)(66476007)(76116006)(166002)(122000001)(4744005)(66946007)(186003)(5660300002)(66556008)(71200400001)(7696005)(9686003)(33656002)(6506007)(316002)(2906002)(38070700005)(110136005)(8676002)(26005)(55016002)(8936002)(450100002)(83380400001); DIR:OUT; SFP:1101; x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DBBPR08MB59155BF41AB856C2ABA82920FAB69DBBPR08MB5915eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0801MB1831 Original-Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT034.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: d1832942-f75b-45f9-a038-08d98d562761 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: L5bx3Qltla475zI8aB/riNkYfEGEVtKUHt+aLPdaiXSyx1t2UyxHdoVSOixHut8AGMwAeCZQm9RZIiW164syCngsKquxebms3nw2/mOh+N6oot6fdmo3dntCZQ9s0s+RY8NH8Mr2POG9G0Khzs4qWGVz7e8i9XSAlVsjBr4nbBDkA+oBRDpH+11yrDyyM/w/40Ou1Ad6jYjCuDRThMto3r5vQKTWdXTsddfLW2+DEw/eKD3KQ/mnGlGH3VTrJ3048RNBfJ3SSeiH95U9y3KTmYd/auJYZvXGfYSbngGHQq8V+iSPJ/Z8R4p2690ERDv2IjZSu691Ui5KneawHnwG34dvr4mfI3nmz2LFQ3WLmL7hKyi2WSgMGpDaRT9Ruf4L2nf1T013NeQT6JnLZxHjE/w+bjLvcnNYThqc0Z8WI/gaTDpHklYdRZ3q1lLSDb/wk0/M9n9CUnVJWQ56ghkYt2cDz5HmyXldnMTKkhuntYLE7KhSZiDOt6Y4NZ9C92ONBR7bA53gPfrNRUSWKOn5TwG2p+uPSmuwyNW8OYRgn8oRKCn8E5VkMFeI7ilRUsV+/ctzikRRzZnKmrzSLHnvKoD6SLwPx5rqeGrK2NOgyitnBG5mBsahOB3GBPJb5PIklYqtBAg+GpFnxdWLurPJHTeGTocfjlMZR/8QBiI6M4jCfdXc2Ty5GF/ndkRz5uWqA4PpyQE6oT+cpD8A38exD88aJ75s/hvp6envZZWTj9+FzS2ZZagLsEXhln0HJPZDHIViQxhnsiSwUQu3dd8q3Emh/JGtreRTxBUeqdOk6IQ= X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(46966006)(36840700001)(186003)(81166007)(8676002)(55016002)(36860700001)(26005)(450100002)(70206006)(2906002)(82310400003)(70586007)(966005)(508600001)(356005)(110136005)(47076005)(336012)(166002)(9686003)(86362001)(83380400001)(52536014)(7696005)(5660300002)(33656002)(6506007)(8936002)(316002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Oct 2021 07:59:09.6743 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9e26b1de-922c-413d-a951-08d98d562c3c X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: VE1EUR03FT034.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4835 Archived-At: Subject: [core] Hackathon#112 Participation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 12 Oct 2021 07:59:28 -0000 --_000_DBBPR08MB59155BF41AB856C2ABA82920FAB69DBBPR08MB5915eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I just checked the IETF hackathon wiki and noticed a low participation from= IoT groups. At the IETF#11 hackathon several folks worked together (see summary present= ation at https://github.com/IETF-Hackathon/ietf111-project-presentations/bl= ob/main/hackathon-lwm2m.pdf) and we made some progress. Let's continue this coding experience at the IETF#112 hackathon. If you are= interested to work together at next hackathon, please drop me an email. Arm is happy to support IoT hackathon participants with hardware*. Ciao Hannes (*) Cortex M developer boards, to be more precise. IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_DBBPR08MB59155BF41AB856C2ABA82920FAB69DBBPR08MB5915eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I just checked the IETF hackathon wiki and noticed a= low participation from IoT groups.

 

At the IETF#11 hackathon several folks worked togeth= er (see summary presentation at https://github.com/IETF-Hackathon/ietf111-project-presentations/blob/main/h= ackathon-lwm2m.pdf) and we made some progress.

 

Let’s continue this coding experience at the I= ETF#112 hackathon. If you are interested to work together at next hackathon= , please drop me an email.

 

Arm is happy to support IoT hackathon participants w= ith hardware*.

 

Ciao

Hannes

 

(*) Cortex M developer boards, to be more precise. <= o:p>

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_DBBPR08MB59155BF41AB856C2ABA82920FAB69DBBPR08MB5915eurp_-- From nobody Tue Oct 12 06:37:29 2021 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 53F883A124C; Tue, 12 Oct 2021 06:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 eLFcZfIOUHh8; Tue, 12 Oct 2021 06:37:21 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81D103A0875; Tue, 12 Oct 2021 06:37:19 -0700 (PDT) Received: from [192.168.217.118] (p5089a8ac.dip0.t-ipconnect.de [80.137.168.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4HTGtP1mpjz2xjZ; Tue, 12 Oct 2021 15:37:17 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <163233240502.20840.5498014177264082102@ietfa.amsl.com> Date: Tue, 12 Oct 2021 15:37:16 +0200 Cc: The IESG , draft-ietf-core-senml-data-ct@ietf.org, core-chairs@ietf.org, core@ietf.org X-Mao-Original-Outgoing-Id: 655738636.620616-4e0b446813128d263c8a5052452d9867 Content-Transfer-Encoding: quoted-printable Message-Id: References: <163233240502.20840.5498014177264082102@ietfa.amsl.com> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-senml-data-ct-05: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 12 Oct 2021 13:37:25 -0000 Hi Ben, thank you for bringing up a number of important issues. > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I have a couple points for discussion, essentially relating to how = much > we're diverging from HTTP and to what extent the specifics of the > divergence should be specifically mentioned in the document. >=20 > (1) I'd like to dig a little more into the analogy with HTTP and > whether we are artificially limiting ourselves: currently we only = allow > 0 or 1 content-codings to be specified, but per > = https://www.ietf.org/archive/id/draft-ietf-httpbis-semantics-19.html#name-= content-encoding > the HTTP ecosystem permits multiple codings to be applied in turn to = the > same representation. While the sensor data values are likely to be > relatively small and applying multiple content-codings is not likely = to > be useful in such a scenario, this seems like something where we = should > only consciously diverge from HTTP, rather than inadvertently doing = so. I agree that this should be handled (if only for = application/json@deflate@aes128gcm and similar cases). We discussed this in the previous interim and it seems we like the = syntax I proposed in the previous sentence. Combining the numerous changes needed with addressing Christer=E2=80=99s = comments on the Abstract: https://github.com/core-wg/senml-data-ct/pull/8 > (2) Let's also discuss whether we want to reuse ABNF rule names from > HTTP while having the rule content diverge, without specific = enumeration > of the divergence. So far I found instances where this document does > not allow HTAB or obs-text in places that draft-ietf-httpbis-semantics > does, which may well be the right way to spell the rule, but seems to > merit a little discussion. Very good point. I=E2=80=99m not sure the ABNF behind =E2=80=9CABNF = rule names from HTTP=E2=80=9D is stable enough that we need to stick = with it in all cases. I was certainly surprised by the recent change to parameters =3D *( OWS ";" OWS [ parameter ] ) (which makes sequences of ";" legal; see also section B.2 in = -semantics.) and wonder whether we should follow this change (and = why!?). Httpbis-semantics uses modified ABNF anyway; so there is no way to have = exactly the same ABNF. But it is worthwhile pointing out that legacy = 8-bit text and HTAB have no place in the strings used in this protocol = and therefore are not allowed. I added a comment: =20 -; Cleaned up from RFC 7231: +; Cleaned up from RFC 7231, only leaving SP as blank space, and +; removing legacy 8-bit characters: The other difference from RFC 2616 and its descendants is the absence of = =E2=80=9Cquoted-pair=E2=80=9D from the =E2=80=9Cquoted-string=E2=80=9D = production, which indeed can be discussed. (May need to discuss this in the interim tomorrow for final resolution.) > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Do we want to comment anywhere about the situation where an > implementation receives a message using an IANA-registered numeric > content-format that is "too new" for that implementation to know = about? (Should have a discussion about error handling in the interim tomorrow. But generally, the important thing is that the implementation *know* = that it needs to be updated to understand.) > It also feels a little weird that we have to end up using the > text-string encoding of a decimal number for the Content-Format, even > for the CBOR representation of SenML structures, but I guess that's = what > RFC 8428 intended and not worth trying to change. We started out with a numeric encoding, but then noticed that SenML is = usually very specific about only allowing a single data type per field. > Abstract >=20 > I'm somewhat sympathetic to the gen-art reviewer's contention that the > new field is not indicating the "Content-Format" of the binary data > values (since Content-Format is a defined term in CoAP and SenML is > claimed to not be limited to CoAP usage). Perhaps we could switch > around the order of description, i.e., "for indicating the Internet > media type (including parameters) of these binary data values (i.e., = the > CoAP Content-Format that would apply when CoAp is used), as well as = any > content-coding that is applied"? This is addressed in https://github.com/core-wg/senml-data-ct/pull/8, = but not exactly following your blueprint. The term =E2=80=9Ccontent format=E2=80=9D is still used both for a = =E2=80=9CContent-Format number=E2=80=9D and a = =E2=80=9CContent-Format-String=E2=80=9D. >=20 > Section 3 >=20 > * a CoAP Content-Format identifier in decimal form with no leading > zeros (except for the value "0" itself). This value represents = an > unsigned integer in the range of 0-65535, similar to the CoRE = Link > Format [RFC6690] "ct" attribute). >=20 > Should we also reference > https://datatracker.ietf.org/doc/html/rfc7252#section-7.2.1 which is > where the "ct" link attribute is actually defined? I spent a bit of > time looking for it in 6690 itself only to discover that it was = removed > in draft-ietf-core-link-format-07 with remark "Moved [...] to the base > CoAP specification". Good point. YYY >=20 > The CoAP Content-Format number provides a simple and efficient way = to > indicate the type of the data. [...] >=20 > If we're limited to string representation, is it really "efficient" in = a > CBOR context? That=E2=80=99s not what the sentence is about :-), but =E2=80=9C11050=E2=80= =9D is still more efficient than "application/json@deflate=E2=80=9D. > Section 6 >=20 > ; Cleaned up from RFC 7231: >=20 > (per the DISCUSS,) I'm a bit anti-enthused about saying "cleaned up" = without saying what > changed (i.e., whether it's just refactoring, or actual changes to the > rule like requiring specifically *SP instead of OWS that allows HTAB = as > well). See above. > Section 7 >=20 > These security considerations are well-thought-out and nicely written. > Thank you! >=20 > I think there are some (rare) situations where individual media-type > (specifications) have their own security considerations, but I'm not > really convinced that we need to mention that/incorporate them by > reference, here. >=20 > NITS >=20 > Section 1 >=20 > The receiver is expected to know how to interpret the data in the > "vd" field based on the context, e.g., name of the data source and > out-of-band knowledge of the application. However, this context may > not always be easily available to entities processing the SenML = pack. >=20 > I'd consider adding ", especially if the pack is propagated to = multiple > entities". That is a bit implied in the context of SenML, but it doesn=E2=80=99t = hurt to say it again. field based on the context, e.g., name of the data source and = out-of-band knowledge of the application. However, this context may not always be -easily available to entities processing the SenML pack. To facilitate +easily available to entities processing the SenML pack, especially if +the pack is propagated over time and via multiple entities. To = facilitate automatic interpretation it is useful to be able to indicate an = Internet > Section 2 >=20 > Content-Coding: A name registered in the HTTP Content Coding > registry [IANA.http-parameters] as specified by Section 8.5 of > [RFC7230], indicating an encoding transformation with semantics > further specified in Section 3.1.2.1 of [RFC7231]. [...] >=20 > (I expect that the RFC Editor will be able to replace the references = to > point to draft-ietf-httpb-semantics if it has been published before = this > document.) (With the actual changes in this document, I=E2=80=99m not sure that is = a mechanical operation. But let=E2=80=99s wait for httpbis-semantics to = emerge from EDIT.) > Section 4 >=20 > up to the end of the pack otherwise. Resolution (Section 4.6 of > [RFC8428]) of this base field is performed by adding its value with > the label "ct" to all Records in this range that carry a "vd" field > but do not already contain a Content-Format ("ct") field. >=20 > The conjugation "resolution" does not actually appear in RFC 8428 > itself, just discussion of "resolved records" and "to resolve the > records". It might be helpful to tweak things so that we don't rely = on > the reader knowing the irregular conjugation (but I don't have any = good > ideas off the top of my head)... -pack otherwise. Resolution ({{Section 4.6 of -senml}}) of this base +pack otherwise. The process of resolving ({{Section 4.6 of -senml}}) = this base The changes that are not already accepted in PR 8 are in https://github.com/core-wg/senml-data-ct/pull/9 Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Oct 12 10:03:37 2021 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 DD8793A0C15; Tue, 12 Oct 2021 10:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] 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 ruInSXNe9gPT; Tue, 12 Oct 2021 10:03:29 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 17D573A185B; Tue, 12 Oct 2021 10:02:29 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 19CH2K1k013227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 12 Oct 2021 13:02:26 -0400 Date: Tue, 12 Oct 2021 10:02:20 -0700 From: Benjamin Kaduk To: Carsten Bormann Cc: The IESG , draft-ietf-core-senml-data-ct@ietf.org, core-chairs@ietf.org, core@ietf.org Message-ID: <20211012170220.GA4103@kduck.mit.edu> References: <163233240502.20840.5498014177264082102@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-senml-data-ct-05: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 12 Oct 2021 17:03:34 -0000 Hi Carsten, On Tue, Oct 12, 2021 at 03:37:16PM +0200, Carsten Bormann wrote: > Hi Ben, > > thank you for bringing up a number of important issues. > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I have a couple points for discussion, essentially relating to how much > > we're diverging from HTTP and to what extent the specifics of the > > divergence should be specifically mentioned in the document. > > > > (1) I'd like to dig a little more into the analogy with HTTP and > > whether we are artificially limiting ourselves: currently we only allow > > 0 or 1 content-codings to be specified, but per > > https://www.ietf.org/archive/id/draft-ietf-httpbis-semantics-19.html#name-content-encoding > > the HTTP ecosystem permits multiple codings to be applied in turn to the > > same representation. While the sensor data values are likely to be > > relatively small and applying multiple content-codings is not likely to > > be useful in such a scenario, this seems like something where we should > > only consciously diverge from HTTP, rather than inadvertently doing so. > > I agree that this should be handled (if only for application/json@deflate@aes128gcm and similar cases). > We discussed this in the previous interim and it seems we like the syntax I proposed in the previous sentence. That seems reasonable. I didn't check just now, but I think I looked last time about whether "@" was allowed in the earlier parts of the media-type+parameters and there was no problem. > Combining the numerous changes needed with addressing Christer’s comments on the Abstract: > > https://github.com/core-wg/senml-data-ct/pull/8 Generally seems reasonable, though I've lost track of the surrounding context for whether "content coding" and "content format" (vs "Content-Coding" and "Content-Format") make sense in the context of the list and surrounding discussion. > > (2) Let's also discuss whether we want to reuse ABNF rule names from > > HTTP while having the rule content diverge, without specific enumeration > > of the divergence. So far I found instances where this document does > > not allow HTAB or obs-text in places that draft-ietf-httpbis-semantics > > does, which may well be the right way to spell the rule, but seems to > > merit a little discussion. > > Very good point. I’m not sure the ABNF behind “ABNF rule names from HTTP” is stable enough that we need to stick with it in all cases. > I was certainly surprised by the recent change to > > parameters = *( OWS ";" OWS [ parameter ] ) > > (which makes sequences of ";" legal; see also section B.2 in -semantics.) and wonder whether we should follow this change (and why!?). I confess I looked at both 7230+7231 and the new -semantics while reviewing this doc, and didn't make a careful distinction between the two sources. > Httpbis-semantics uses modified ABNF anyway; so there is no way to have exactly the same ABNF. But it is worthwhile pointing out that legacy 8-bit text and HTAB have no place in the strings used in this protocol and therefore are not allowed. > > I added a comment: > > -; Cleaned up from RFC 7231: > +; Cleaned up from RFC 7231, only leaving SP as blank space, and > +; removing legacy 8-bit characters: Thanks! > The other difference from RFC 2616 and its descendants is the absence of “quoted-pair” from the “quoted-string” production, which indeed can be discussed. > > (May need to discuss this in the interim tomorrow for final resolution.) Ok. > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Do we want to comment anywhere about the situation where an > > implementation receives a message using an IANA-registered numeric > > content-format that is "too new" for that implementation to know about? > > (Should have a discussion about error handling in the interim tomorrow. > But generally, the important thing is that the implementation *know* that it needs to be updated to understand.) True. > > It also feels a little weird that we have to end up using the > > text-string encoding of a decimal number for the Content-Format, even > > for the CBOR representation of SenML structures, but I guess that's what > > RFC 8428 intended and not worth trying to change. > > We started out with a numeric encoding, but then noticed that SenML is usually very specific about only allowing a single data type per field. > > > Abstract > > > > I'm somewhat sympathetic to the gen-art reviewer's contention that the > > new field is not indicating the "Content-Format" of the binary data > > values (since Content-Format is a defined term in CoAP and SenML is > > claimed to not be limited to CoAP usage). Perhaps we could switch > > around the order of description, i.e., "for indicating the Internet > > media type (including parameters) of these binary data values (i.e., the > > CoAP Content-Format that would apply when CoAp is used), as well as any > > content-coding that is applied"? > > This is addressed in https://github.com/core-wg/senml-data-ct/pull/8, but not exactly following your blueprint. > The term “content format” is still used both for a “Content-Format number” and a “Content-Format-String”. > > > > > Section 3 > > > > * a CoAP Content-Format identifier in decimal form with no leading > > zeros (except for the value "0" itself). This value represents an > > unsigned integer in the range of 0-65535, similar to the CoRE Link > > Format [RFC6690] "ct" attribute). > > > > Should we also reference > > https://datatracker.ietf.org/doc/html/rfc7252#section-7.2.1 which is > > where the "ct" link attribute is actually defined? I spent a bit of > > time looking for it in 6690 itself only to discover that it was removed > > in draft-ietf-core-link-format-07 with remark "Moved [...] to the base > > CoAP specification". > > Good point. YYY > > > > > The CoAP Content-Format number provides a simple and efficient way to > > indicate the type of the data. [...] > > > > If we're limited to string representation, is it really "efficient" in a > > CBOR context? > > That’s not what the sentence is about :-), but “11050” is still more efficient than "application/json@deflate”. > > > Section 6 > > > > ; Cleaned up from RFC 7231: > > > > (per the DISCUSS,) I'm a bit anti-enthused about saying "cleaned up" without saying what > > changed (i.e., whether it's just refactoring, or actual changes to the > > rule like requiring specifically *SP instead of OWS that allows HTAB as > > well). > > See above. > > > Section 7 > > > > These security considerations are well-thought-out and nicely written. > > Thank you! > > > > I think there are some (rare) situations where individual media-type > > (specifications) have their own security considerations, but I'm not > > really convinced that we need to mention that/incorporate them by > > reference, here. > > > > NITS > > > > Section 1 > > > > The receiver is expected to know how to interpret the data in the > > "vd" field based on the context, e.g., name of the data source and > > out-of-band knowledge of the application. However, this context may > > not always be easily available to entities processing the SenML pack. > > > > I'd consider adding ", especially if the pack is propagated to multiple > > entities". > > That is a bit implied in the context of SenML, but it doesn’t hurt to say it again. > > field based on the context, e.g., name of the data source and out-of-band > knowledge of the application. However, this context may not always be > -easily available to entities processing the SenML pack. To facilitate > +easily available to entities processing the SenML pack, especially if > +the pack is propagated over time and via multiple entities. To facilitate > automatic interpretation it is useful to be able to indicate an Internet Thanks! > > Section 2 > > > > Content-Coding: A name registered in the HTTP Content Coding > > registry [IANA.http-parameters] as specified by Section 8.5 of > > [RFC7230], indicating an encoding transformation with semantics > > further specified in Section 3.1.2.1 of [RFC7231]. [...] > > > > (I expect that the RFC Editor will be able to replace the references to > > point to draft-ietf-httpb-semantics if it has been published before this > > document.) > > (With the actual changes in this document, I’m not sure that is a mechanical operation. But let’s wait for httpbis-semantics to emerge from EDIT.) > > > Section 4 > > > > up to the end of the pack otherwise. Resolution (Section 4.6 of > > [RFC8428]) of this base field is performed by adding its value with > > the label "ct" to all Records in this range that carry a "vd" field > > but do not already contain a Content-Format ("ct") field. > > > > The conjugation "resolution" does not actually appear in RFC 8428 > > itself, just discussion of "resolved records" and "to resolve the > > records". It might be helpful to tweak things so that we don't rely on > > the reader knowing the irregular conjugation (but I don't have any good > > ideas off the top of my head)... > > -pack otherwise. Resolution ({{Section 4.6 of -senml}}) of this base > +pack otherwise. The process of resolving ({{Section 4.6 of -senml}}) this base > > The changes that are not already accepted in PR 8 are in > https://github.com/core-wg/senml-data-ct/pull/9 Thanks again for all this, Ben From nobody Wed Oct 13 01:20:52 2021 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 BC0683A113B; Wed, 13 Oct 2021 01:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=aist.go.jp 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 e_fACdtckbvZ; Wed, 13 Oct 2021 01:20:45 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-eopbgr1400077.outbound.protection.outlook.com [40.107.140.77]) (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 2A0323A1507; Wed, 13 Oct 2021 01:20:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=k9WKVR7M3h8B8k/34ddt7dUGU+JiFnWeI+EmU2uLWf88d2WIVFliyI9Ja1OBqIpu6pY7zmSmyWh0/aGrcezyZ8abN506PMLJdBQgjIllJvd6n9/SwN9LAqOt28hdy3LfEooFgJ1EbVsGfbEQXT3EFl35XpArokiCDkYyJHjpgzFjkZ+CzV+CEwPxJtCj24IDz8YWEKTN8hy7R72XzezCHtJl/XWHWg9T41S1oBPH59BIB7HDp8wgP4Z7mxV3nojc6KT5KRey53DQ7Z6FN6Acwq6gEJiL7HmBB1eLWhGaXF2J/lMfCcjvyM8Icbta+efZZ2fn7ae1p1eJ3dCFGD4prg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qWVf462wfSKJqO6Cygx9pjX9Xk0LjYAVVHZvAXXRCss=; b=JEzipywa+BdQ4KzXhxuIYgAoLHaBA2wzrCI+ZptoCfKLv+H13tVed9lyIczEwopG2Gb+iJtX0uuamntDYdjOQ0WdrgHP2bC3lKpEJeRhD1S06qpbhnAWQ//K6xhNdJXkkJB9hNzVJdWPHElxs/GEx+6NNxUl6Y/TEVTOik6pDTvbSE18dSZGoJ37oJEkBt/fX3LWWkc2dU9gK4loYJq7q+5pYC75Ew+OAYmA/L16QzVDGX4uQZDnkJ28X+A2vdXeJ3nAps1B2x68vH1kLpAkIJ5NGkD70lw6Klwem2kkGe4rqfhsxpUJ/+hXHz178oOwlo9Ypw1jSBrl0e46ZEnmRQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=aist.go.jp; dmarc=pass action=none header.from=aist.go.jp; dkim=pass header.d=aist.go.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qWVf462wfSKJqO6Cygx9pjX9Xk0LjYAVVHZvAXXRCss=; b=NWi0dsXuIPmzD9fRzrb5EqAK3QOcN4mAbV7k2ZnjBxzqT/rWWYFZ96WlHkWGccQ+PBfnA5/v6eu41JJltA5iOFSrR7/Jj77dkPK2+6XRe8uF2Tqz1aZQhnoU5uEaQ/6Ma9Lbob7U5K8713IKKfTNYhe9QbOzPaPDf+Jm94wRyW8= Received: from TYAPR01MB3086.jpnprd01.prod.outlook.com (2603:1096:404:80::20) by TYAPR01MB4814.jpnprd01.prod.outlook.com (2603:1096:404:129::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.19; Wed, 13 Oct 2021 08:20:41 +0000 Received: from TYAPR01MB3086.jpnprd01.prod.outlook.com ([fe80::dd23:143b:ed1a:7bd9]) by TYAPR01MB3086.jpnprd01.prod.outlook.com ([fe80::dd23:143b:ed1a:7bd9%5]) with mapi id 15.20.4608.015; Wed, 13 Oct 2021 08:20:40 +0000 Message-ID: <139d7b2a-d3ca-0bb1-f2ec-db3b61b7583f@aist.go.jp> Date: Wed, 13 Oct 2021 17:20:39 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Content-Language: en-US To: Hannes Tschofenig , "core@ietf.org WG" , "ace@ietf.org" , "suit@ietf.org" References: From: Akira Tsukamoto In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: TYAPR01CA0110.jpnprd01.prod.outlook.com (2603:1096:404:2a::26) To TYAPR01MB3086.jpnprd01.prod.outlook.com (2603:1096:404:80::20) MIME-Version: 1.0 Received: from [150.82.75.129] (150.82.75.129) by TYAPR01CA0110.jpnprd01.prod.outlook.com (2603:1096:404:2a::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.15 via Frontend Transport; Wed, 13 Oct 2021 08:20:40 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c35978da-4d61-455a-6822-08d98e22580f X-MS-TrafficTypeDiagnostic: TYAPR01MB4814: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: G8jOJjTIqbOrHISGAOqGK2A1H87Nb/SHzqh61/B0lzLl9NBK5WoUU5R6diPlDz4R4cQVzW4EQMioZoVYteVOzwAjhmc1J3nOnhY/nxUEWUFWg4+xkMtX8WP7l13fvdzH/E/YuzzWGQx4CdvdwkRJ/SJJTU6h7TpABiHG9qeslVysszlwGAbawNXMwqX+oYlnBHhj7FLLUVXDs0F7FeaWhzn5DU8gzQzFGnanDj0ljAzMdWTZzwmxEAWrTW/6iwGOzqlm9n7FC9vi7IHMGF73L2Pcmd6az6UCSwc5scnr0HkP6e0qtH51kT5xFCYVX2zwd+H1Atkf76wwlYilckjs6fVFbsaaxAMEuRkP48it/6t9aXVNWmfPZBSAU91GpgxrrEQva5vbty7lgzOrnUFgM31bz3zIY5fasdzeXDrFjQjWldpNYTkeG7T1kFTyZv5h7aFtyrkRpKGrd8mrC/bUZpc5DfeVdjbHMrq7Si7HgHwCgcJPsUVVH9/jZJtSRm+YLu/t4BsIZhKLusbRhX9WM3WyoZUxVIIllSDgidARiybQr7eNRG2tPxSGHNiq1/u3GPJBe51tqY9ABA2G1aCLtGJlziHHobbgS/qIbUNV5uAFvXNZPN54p5caQ5kHVdsHD/Q10Tq8U54XGmvxVw579l/A25sJhqkUWqbjhOnpsxdJxVjrhoo0YaKUABtZJFHhM0bhNkyn8of/LBWuD10RouUMpaxa/cs1MtiGFP2cznMG+CjQc6OLacZn7b4RtrcGzzIe1zQx9I0T1UfMpCDB5smIeA6k4+cydI4w9x7IPhX4zpwj9RMiXZ7yt+KmdgnELecrCdo2c8LoLJPsYc1pZoU8h3bKgsh4nbZInglveLRxH9AHXWSNAXvW9DpOXxuX X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB3086.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(31686004)(86362001)(26005)(110136005)(8676002)(66946007)(44832011)(316002)(508600001)(38100700002)(956004)(6486002)(2906002)(8936002)(16576012)(66476007)(966005)(53546011)(45080400002)(66556008)(2616005)(5660300002)(83380400001)(36756003)(6706004)(31696002)(186003)(3940600001)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dVVLbHA4SnVyalE5MVFaakpoeUZQK1J2M1VOSmwrUmZ4dEtRa3hxRzhyT3NY?= =?utf-8?B?WlpVSHZnSDI5WUJMVnBEdDE4WE5USG5zMklSdC93aVoxbWw5QUFzREpXVWEv?= =?utf-8?B?QkZwWkRHRDFjeFUzeGdKcmhLYjJuM050L242QXEzR1RtaHZkbDhmL1lLVGZo?= =?utf-8?B?Nm9XelBWYndVNk5BY094K0dHZ2VZd0NaODg3UWhUM3MrSUc4YzJmZVk3S1NM?= =?utf-8?B?Qzd4V3k5Q2tnOVkvaUlBMWdxTWhYeDY0Vk5Fd1JocVVBVmlxS2xvQXhka2N3?= =?utf-8?B?SGcyQzE5TnlWeG92WmNpRWhJWGdVQmF2NUVQbXh0R1JaRTBqcDcyUERrTjBY?= =?utf-8?B?VisvUWdWUURhczlwMUNkak8vRFNCeFdETjlyQmx5UzNtSzNJdUNtZDIyd3dV?= =?utf-8?B?SzFyTGVUREVqZWE4OG01TUhGdFA1bStCSXlFdmc4NXZTdGVRTkRKd20yV2xl?= =?utf-8?B?VTh0bmhwRjVKY2F6YTJkYW1lblZmL05VTTVVNGtuYXJNREUxNHNHa1ZrV0xz?= =?utf-8?B?WjdEMVdZQSs3SHJuc01EWlJlK0dKbktCWCtXS0txa3htS0JBZko1c3hNL01y?= =?utf-8?B?Ty9NbWJLRWFJUkp2c1JhM3kzY3FUbHF5WlBxRGxpZXdQMU55d2lLaVpkR0pw?= =?utf-8?B?NWRUV1RvaVI0TERHSFpvcVFuRDUwOUJmRTYvb2lGdnFNZkE3SnVzZkVQR0J0?= =?utf-8?B?RktLdUljSjlHMUYrNDJEbU5QUGl0ekdReVE4dDh4d2RadEFBZnZzcW9SWFpW?= =?utf-8?B?amdXV29RbE4xOEZUdEJMSzNLVUtxTi9oeTUwamRoV3RQNmpOTFZUeEFOSE1T?= =?utf-8?B?ck5mK3JnakpjOTF2RjJyZHNWdFNXaG1xMDdWMWJzMTNtaHVCUzJXUGZSOERL?= =?utf-8?B?RElocjZqUFFRc24xY1dPTjRXMmVHNGUydjFmbGxsSFZpR05QV0psZmtDVlJG?= =?utf-8?B?UjN4OXBRSndFOWRJS0lsUHlDWlFleFVSYlA2SFBONEVtMjVIVGNPaWsySFNh?= =?utf-8?B?OEtLRFhLdUg1K0lrNW9MMHNEYUtRMmd4bDZKdXNnZDVFdHE4NGtRUEFSSE5K?= =?utf-8?B?MWNvYVFMcndyUDB2d0VGM3RVUWRMZzZvUTBGV1prczNOT2ZoR1JCTUN6R2ox?= =?utf-8?B?MzVmdGcrVjFaNDUzeWpBbHlYMHRpdDVHWWVqMTM3KzFsMld3V3g3VWlDWEJ0?= =?utf-8?B?UEQrUDR3K1BITmI5VVc0MkFDejZhU0JrblBId0hjamtFM0tWeHNjT1ZUQ0lP?= =?utf-8?B?V3B1dXFscytqS1I5RjAxZmVrRFd2dTZxVjlrVk9GYTlCWEIxQTlrQ3o4MHFD?= =?utf-8?B?dE9tTXR5TXBtajRtc3lMcjBnNHdURjA4YmJmb0JDSUVNUlovVk9yT251WENr?= =?utf-8?B?S3pSSHRJejhxckV1T0hReHZlRU0veldwN0tPRVJ4aitna3NsZ29NMkJZS1dt?= =?utf-8?B?Q1l0TGJQN0Vud0lxYmFOSm5ZcSs2Yk4veHhjZHdUaWdPaTFuSHJGVXZrdHNh?= =?utf-8?B?NVptN0hBcHQ3YllUUU8rWU5mZlgyZHVMemloSnRNT1pUVmxsejVSaUh4Nk5a?= =?utf-8?B?c3IwMlpmbEZvOU40OURmTmlnbXZGRTRnbFFhdU5SNXEvb21BNlNpZHN5ZkpN?= =?utf-8?B?WDNLUnJSS1BLRXJZSGJna3FvZXdRQmxpT2VWMGlOTFdFNjQyR0lVdXhBQm9u?= =?utf-8?B?bTdrdWdqRjBMNkt3ZThwY2sxa0pBeFI1V1lnZXJRQkJkUlIrcndRZTRpeVpj?= =?utf-8?Q?Nzmptg8ghVoYHAL+2R1J9EQS6Mn5vh5ylrMSuTA?= X-OriginatorOrg: aist.go.jp X-MS-Exchange-CrossTenant-Network-Message-Id: c35978da-4d61-455a-6822-08d98e22580f X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB3086.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Oct 2021 08:20:40.8801 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 18a7fec8-652f-409b-8369-272d9ce80620 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: hYEctrjdD4xX7eWXgckKHkTFY21hFmnvbKifn3AReVN5oNqFqKuQWnlutRTiIR8yhITciig1Jx1uFGGePMzw+QV4p2swvMrqH/YtfaX5ACA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR01MB4814 Archived-At: Subject: Re: [core] [Suit] Hackathon#112 Participation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 13 Oct 2021 08:20:51 -0000 Hi Hannes, The hackathon is in three weeks. We would like to go through the suit manifest formats on teep protocol at the github links. https://github.com/ietf-teep/teep-protocol/issues/158 https://github.com/ietf-teep/teep-protocol/pull/161 We are trying to finish adding suit support on our implementation at least during the ietf 112. It would be great, reviewing and could finalize the formats. Best, Akira Tsukamoto On 10/12/2021 4:59 PM, Hannes Tschofenig wrote: > Hi all, > > I just checked the IETF hackathon wiki and noticed a low participation from IoT groups. > > At the IETF#11 hackathon several folks worked together (see summary presentation at https://github.com/IETF-Hackathon/ietf111-project-presentations/blob/main/hackathon-lwm2m.pdf ) and we made some progress. > > Let’s continue this coding experience at the IETF#112 hackathon. If you are interested to work together at next hackathon, please drop me an email. > > Arm is happy to support IoT hackathon participants with hardware*. > > Ciao > > Hannes > > (*) Cortex M developer boards, to be more precise. > > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. > > _______________________________________________ > Suit mailing list > Suit@ietf.org > https://www.ietf.org/mailman/listinfo/suit > From nobody Wed Oct 13 11:00:25 2021 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 F23FC3A0B3E; Wed, 13 Oct 2021 11:00:22 -0700 (PDT) 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, SPF_HELO_NONE=0.001, 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 IdUbfq1ZLVz5; Wed, 13 Oct 2021 11:00:16 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABB5C3A0A34; Wed, 13 Oct 2021 11:00:15 -0700 (PDT) Received: from [192.168.217.118] (p5089a8ac.dip0.t-ipconnect.de [80.137.168.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4HV0gF6MWBz2xjd; Wed, 13 Oct 2021 20:00:09 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <20211012170220.GA4103@kduck.mit.edu> Date: Wed, 13 Oct 2021 20:00:09 +0200 Cc: The IESG , draft-ietf-core-senml-data-ct@ietf.org, core-chairs@ietf.org, core@ietf.org X-Mao-Original-Outgoing-Id: 655840808.9414001-9d9f8de8008151fc292ff3b83232e95f Content-Transfer-Encoding: quoted-printable Message-Id: References: <163233240502.20840.5498014177264082102@ietfa.amsl.com> <20211012170220.GA4103@kduck.mit.edu> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-senml-data-ct-05: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 13 Oct 2021 18:00:23 -0000 Good morning Ben, here are some answers to the remaining points on data-ct before we = submit -06: >>> (2) Let's also discuss whether we want to reuse ABNF rule names from >>> HTTP while having the rule content diverge, without specific = enumeration >>> of the divergence. So far I found instances where this document = does >>> not allow HTAB or obs-text in places that = draft-ietf-httpbis-semantics >>> does, which may well be the right way to spell the rule, but seems = to >>> merit a little discussion. >>=20 >> Very good point. I=E2=80=99m not sure the ABNF behind =E2=80=9CABNF = rule names from HTTP=E2=80=9D is stable enough that we need to stick = with it in all cases. >> I was certainly surprised by the recent change to >>=20 >> parameters =3D *( OWS ";" OWS [ parameter ] ) >>=20 >> (which makes sequences of ";" legal; see also section B.2 in = -semantics.) and wonder whether we should follow this change (and = why!?). >=20 > I confess I looked at both 7230+7231 and the new -semantics while = reviewing > this doc, and didn't make a careful distinction between the two = sources. We actually decided to move entirely from 7230/7231 to = httpbis-semantics, hoping that doesn=E2=80=99t put us in missref limbo = forever. In the interim meeting today, we agreed that the parameter optionality = is among the legacy features (with HTAB and obs-text), so we left it out = (and extended the comment in the ABNF what was left out. All the changes mentioned in this mail are in: https://github.com/core-wg/senml-data-ct/pull/10 [=E2=80=A6] >> The other difference from RFC 2616 and its descendants is the absence = of =E2=80=9Cquoted-pair=E2=80=9D from the =E2=80=9Cquoted-string=E2=80=9D = production, which indeed can be discussed. >>=20 >> (May need to discuss this in the interim tomorrow for final = resolution.) We agreed to restore quoted-pair (the bug fix I alluded to, over in = httpbis), so we are (sans legacy) fully compatible with HTTP=E2=80=99s = use of media types/content types. [=E2=80=A6] >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> Do we want to comment anywhere about the situation where an >>> implementation receives a message using an IANA-registered numeric >>> content-format that is "too new" for that implementation to know = about? >>=20 >> (Should have a discussion about error handling in the interim = tomorrow. >> But generally, the important thing is that the implementation *know* = that it needs to be updated to understand.) >=20 > True. We wrote a new section =E2=80=9Cevolution=E2=80=9D, which also answers = the questions that Roman Danyliw did not ask :-) We can=E2=80=99t really address the issue of SenML interoperability in = this document providing a single definition of a pair of fields, so we = expect there will be another draft (maybe also with other usage = guidelines that improve that interoperability). [=E2=80=A6] >>> Section 2 >>>=20 >>> Content-Coding: A name registered in the HTTP Content Coding >>> registry [IANA.http-parameters] as specified by Section 8.5 of >>> [RFC7230], indicating an encoding transformation with semantics >>> further specified in Section 3.1.2.1 of [RFC7231]. [...] >>>=20 >>> (I expect that the RFC Editor will be able to replace the references = to >>> point to draft-ietf-httpb-semantics if it has been published before = this >>> document.) >>=20 >> (With the actual changes in this document, I=E2=80=99m not sure that = is a mechanical operation. But let=E2=80=99s wait for httpbis-semantics = to emerge from EDIT.) Definitely not mechanical, but easy enough (but subject to change due to = EDIT). We plan to merge PR 10 soon and submit a new I-D. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Oct 13 11:07:47 2021 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 8A0073A08B6; Wed, 13 Oct 2021 11:07:44 -0700 (PDT) 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: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <163414846448.4429.11192315902065813807@ietfa.amsl.com> Date: Wed, 13 Oct 2021 11:07:44 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-senml-data-ct-06.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2021 18:07:45 -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 : SenML Data Value Content-Format Indication Authors : Ari Keränen Carsten Bormann Filename : draft-ietf-core-senml-data-ct-06.txt Pages : 11 Date : 2021-10-13 Abstract: The Sensor Measurement Lists (SenML) media type supports multiple types of values, from numbers to text strings and arbitrary binary data values. In order to facilitate processing of binary data values, this document specifies a pair of new SenML fields for indicating the content format of those binary data values, i.e., their Internet media type including parameters as well as any content codings applied. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-senml-data-ct/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-core-senml-data-ct-06.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-senml-data-ct-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 13 11:09:41 2021 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 E69333A08CD for ; Wed, 13 Oct 2021 11:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 XJTMva9cnDJE for ; Wed, 13 Oct 2021 11:09:34 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C38503A0899 for ; Wed, 13 Oct 2021 11:09:34 -0700 (PDT) Received: from [192.168.217.118] (p5089a8ac.dip0.t-ipconnect.de [80.137.168.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4HV0t41Rh5z2xl9; Wed, 13 Oct 2021 20:09:32 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <163414846448.4429.11192315902065813807@ietfa.amsl.com> Date: Wed, 13 Oct 2021 20:09:31 +0200 X-Mao-Original-Outgoing-Id: 655841371.586993-1d4339e340160e8f2feee4b61a1c07be Content-Transfer-Encoding: quoted-printable Message-Id: References: <163414846448.4429.11192315902065813807@ietfa.amsl.com> To: core@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-senml-data-ct-06.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 13 Oct 2021 18:09:40 -0000 Revision -06 should address all IESG input (DISCUSS and COMMENT). Gr=C3=BC=C3=9Fe, Carsten > On 2021-10-13, at 20:07, internet-drafts@ietf.org wrote: >=20 >=20 > 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. >=20 > Title : SenML Data Value Content-Format Indication > Authors : Ari Ker=C3=A4nen > Carsten Bormann > Filename : draft-ietf-core-senml-data-ct-06.txt > Pages : 11 > Date : 2021-10-13 >=20 > Abstract: > The Sensor Measurement Lists (SenML) media type supports multiple > types of values, from numbers to text strings and arbitrary binary > data values. In order to facilitate processing of binary data > values, this document specifies a pair of new SenML fields for > indicating the content format of those binary data values, i.e., > their Internet media type including parameters as well as any = content > codings applied. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-core-senml-data-ct/ >=20 > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-core-senml-data-ct-06.html >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-senml-data-ct-06 From nobody Wed Oct 13 12:15:51 2021 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 A7AB03A09C6; Wed, 13 Oct 2021 12:15:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-core-senml-data-ct@ietf.org, core-chairs@ietf.org, core@ietf.org, Jaime Jimenez , jaime@iki.fi X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <163415254866.23417.15368605110793342174@ietfa.amsl.com> Date: Wed, 13 Oct 2021 12:15:48 -0700 Archived-At: Subject: [core] Benjamin Kaduk's No Objection on draft-ietf-core-senml-data-ct-06: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2021 19:15:49 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-core-senml-data-ct-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-senml-data-ct/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the updates in the -06 and the discussion to get there. I'm happy with where things ended up, and have just one comment after reading the diff: The ABNF comment for the "Cleaned up" entries currently says "leaving the parameter as mandatory", which is only true in a very specific sense; "leaving the parameter as mandatory within the grouping" or "leaving the parameter as mandatory when the separator is present" might be more clear to a reader not focusing on the specific context of the statement. From nobody Wed Oct 13 13:16:46 2021 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 76D383A0D70; Wed, 13 Oct 2021 13:16:37 -0700 (PDT) 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, SPF_HELO_NONE=0.001, 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 6dWN1Nn1y0PQ; Wed, 13 Oct 2021 13:16:34 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4225D3A0D7D; Wed, 13 Oct 2021 13:16:32 -0700 (PDT) Received: from [192.168.217.118] (p5089a8ac.dip0.t-ipconnect.de [80.137.168.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4HV3hW4Hmwz2xkb; Wed, 13 Oct 2021 22:16:27 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <163415254866.23417.15368605110793342174@ietfa.amsl.com> Date: Wed, 13 Oct 2021 22:16:27 +0200 Cc: The IESG , draft-ietf-core-senml-data-ct@ietf.org, core-chairs@ietf.org, core@ietf.org X-Mao-Original-Outgoing-Id: 655848986.834669-681ee9194fabf5a33ac41e6590e817b3 Content-Transfer-Encoding: quoted-printable Message-Id: <0543A59A-E316-4349-839C-EDC629F7E75D@tzi.org> References: <163415254866.23417.15368605110793342174@ietfa.amsl.com> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] Benjamin Kaduk's No Objection on draft-ietf-core-senml-data-ct-06: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 13 Oct 2021 20:16:38 -0000 Thank you for all the great input! On 2021-10-13, at 21:15, Benjamin Kaduk wrote: >=20 > The ABNF comment for the "Cleaned up" entries currently says > "leaving the parameter as mandatory", which is only true in a > very specific sense; "leaving the parameter as mandatory within > the grouping" or "leaving the parameter as mandatory when the > separator is present" might be more clear to a reader not focusing > on the specific context of the statement. Good point. The best I came up with is: ; Cleaned up from [RFC-httpbis-semantics], ; leaving only SP as blank space, ; removing legacy 8-bit characters, and -; leaving the parameter as mandatory: +; leaving the parameter as mandatory with each semicolon: =20 Now the seed content of https://github.com/core-wg/senml-data-ct/pull/11 Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Oct 14 06:58:50 2021 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 850943A16A0 for ; Thu, 14 Oct 2021 06:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se 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 N4y_MGDYL1kL for ; Thu, 14 Oct 2021 06:56:33 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2079.outbound.protection.outlook.com [40.107.21.79]) (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 1C87A3A0982 for ; Thu, 14 Oct 2021 06:56:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q76SZ7og1UVTWURmVZa7NoiyJEMwCKDoM5v0q8LvoK7EleWzk7syYwg3WpxsJ+039udjWow0yZ7p7SLpypgfTbPf6Z26ADEXPQ7vXA2ZiMhuolupWknUNoftfYFLtYObjbxPKf2J0Y1qGk1W5aswbRZQRaZFTptC2zO44fkvOSS7GMJwN7jw8gRXkAL1RK/geQU4MVRX/hmMVfMPw8jgeHb5NrwkYud3TsoAsYSxY/jMFcVV51v2Z3JB+cItN2mL3SIS1l3q+xE4EPhUYyVaHGPHxGTEJG0TH6QzkXfbYZEcdgVhGuVTYQi5LqflAGt2a9R++HpGZqezN7A6IMH+Rw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ZqAX62+dqkSUoKftnc88kqPkkhitp8K1VPrd75e9We8=; b=hYvA9bSZucHd5LilUpophz2hDQ32zV2eEdQVHL2fib/9LOlxESJcnfaWS3Nwy4rG3CgtkRVKbxUJ1k2VMXcEXuoQDjJR72Ae7T25SKRu20cmPbtkYiV1jfvethLgerzanSwHTlCxBcsBSWjkD42BnKFGKb0kzzdG7WPS/bRAOzDACpfXmRicO7nXMlTQRKvTJGhdduI+7idla0TmpXFJ+NmO3DqcdMOGW0ruMJqZcaIqGxLCBdmtOKN7yaMS/bd2RUr4JLE8+WF5Nb7RxReca+Y5yVsZjZ+JY5TMeOqCe7MWEzOHtQIdCcAFyvJG9tdBJ6GWT6KReNwam7nw0JRX+A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZqAX62+dqkSUoKftnc88kqPkkhitp8K1VPrd75e9We8=; b=Sv+bQ8n+syUcjj4eySwYQ+3bQfVsDDXTa2NLjILfnEA5JjBITYBMtO9icRIK9rNRTNzH4PU6F2/CBS9tE1I6/qOLAVfi5p3jbhgdb/x01ik3s56brMbMU6fFvQp+GBH2+1OkvWEnMNet/WDkOIPU8ThQh3WchW+5QDCkQlXWsR8= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB9P189MB1498.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:26d::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.20; Thu, 14 Oct 2021 13:56:23 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::4dd0:ed4b:e776:d560]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::4dd0:ed4b:e776:d560%3]) with mapi id 15.20.4587.026; Thu, 14 Oct 2021 13:56:22 +0000 To: "core@ietf.org WG (core@ietf.org)" References: From: Marco Tiloca Message-ID: <290101ab-0022-0ed7-424e-dc5d6c73b401@ri.se> Date: Thu, 14 Oct 2021 15:56:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="e2Ez66JLFivLKOcepd4uzEWIVJ1cwVcpA" X-ClientProxiedBy: HE1PR05CA0209.eurprd05.prod.outlook.com (2603:10a6:3:f9::33) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 Received: from [10.8.0.5] (185.236.42.79) by HE1PR05CA0209.eurprd05.prod.outlook.com (2603:10a6:3:f9::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.14 via Frontend Transport; Thu, 14 Oct 2021 13:56:22 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e64849e7-6004-4706-6e11-08d98f1a6801 X-MS-TrafficTypeDiagnostic: DB9P189MB1498: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: iYUOEzeDMIN5gs8h+iR+g8UUb6C2GJkcsj2mWn8nJB3jojr46La7cazEVQiT0u5+oHi5GzFXgySVvVIT4aaGE2/10QihetRwHrq1vuckrZmzmXhb6ZPVjq8Kvh9fVdrmtvoGL5HWPUdKyXTGKWP09KriTD1DwUVPsF4t4yWqfzaTvkbj25nW1Do6q59pXOZS/YVSa47CW+J1UQYmuc37xzmGKsQ6dxZ7SrKWFQvSHbwbtJTIGtMPDMhOX7okQdh95s+aQyatCnGMorhSwmhkkDAnX+uSbbnXI1EQ70HY/VjlzyIaYynFfO06WDkRIpWH6Y3FQgsjzuolMNca6MsO1vlU/gMq0//0mOOc7zXh468flE/mOO/rBomdXizJh2rUVro5w7elVcix0iznHCzBJJ35L44N2XhrK7aDLsIo/pw0/xArD5wc96TFsBUe127j+rZ8fvP5JvcGIvTczUyBHaLU2x9VHRv5jS9BK81NwZ3zEYqUPpZsoiwl1XRyO7xLglPE/F0JL8ko13lHgxEB847khMvmQ/8Ypdrj+ap/q29GuQ7EfOkMghVjT8/8pK2avtl+ZU+pG68RuUWLrRnFkNVeRtPWXs1SsvXXsLOGxB5IboLE7Kkct4sns0EfxXhm0Uw5H2d2fbzVdMEbCg32vRwtCnzoe56u3w+bkrKAaiR+A5nfIzdLfuKehVKhlvvjpNeSpH0Eg3nHLU6M5yvTAe2KFRXcZn56Ye6sPoxW9su/FP9In4D8OtJo/hVZM7BFj5szC/pntzpT/AwNIZL8Z7c0kvUeB5SQ3c4IwcjHm/mluCDBFHUuVuRlN8d9a80QqTAa+vsvsO/i26a9TVWH9/zdbVVd8rybTO0TNbNimJ4= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(16576012)(2906002)(6486002)(53546011)(966005)(66476007)(235185007)(45080400002)(33964004)(6916009)(44832011)(83380400001)(8676002)(4001150100001)(66946007)(66574015)(186003)(5660300002)(26005)(316002)(8936002)(66556008)(508600001)(31696002)(38100700002)(21480400003)(30864003)(2616005)(36756003)(956004)(31686004)(86362001)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VmprQk54TWZHS2xoQ3RtU09MMGxVN1prYVJaQnVUaERPaEQ5QlJDSlpnbXhH?= =?utf-8?B?dkFEeXFzcXNUYUNMZE1xM1ZPL0ZHaFJ1cGNFWEtQYlZOOXY0dDBNZzdFN3hZ?= =?utf-8?B?NitmRHM0QmU5WXN3Rk1RYWgxRENJbmpWQ1UyR2UzNHh0WXBqNElqWDFXT0Mx?= =?utf-8?B?TXBIVHlWNFIzL2RKTWg1NzZwZVRFMDdUUjh5UDVWS3FRWXdUcGQ4aEhRQ3hO?= =?utf-8?B?S29sb0IzV05RZGhBTHZXUkkrYm85dkVsdWtNelVwZDU0TWk2UGdEeDlWUzBI?= =?utf-8?B?d1J2aVNNQWhqbmpGak9nOTlKQ29pV1M1V1lNWmpkNkF0Mk81U2JTalF1WXh5?= =?utf-8?B?enc1NzlIVGMycHFNeGcxN2JhdUljN0U1azdLWW5vNVVXU2JOUExsMGkvWm1x?= =?utf-8?B?c09PTTY4ZXlFbGlyNDZvVy9tNDE4bUNUaFZSY2ZONjduc05jN1BkUTJyWFZI?= =?utf-8?B?Z20zcFJVWEpmWGV1bUFyblpDNUZ4czd0bU1hWWNMdm94dlRyTlllUGxCa2kr?= =?utf-8?B?VWxLU1NZU1MyeWd0ZGlUNHg5aGU1YWNHajUzK2FDZWFwdTR1Y0krbFdoREFy?= =?utf-8?B?bGd4ekpYRUdaMk96bUozVml2QTQ1aXdTSGFsUDlENnp6aWRSZnAyZFFQV2Rt?= =?utf-8?B?d0RacVZDV1BRa1pHVDdudUxyZ0RHTCsyQUhwMFU2UXhmN3BodnZIcXpZb3Vy?= =?utf-8?B?a3BBeWgrTkNKdEx3d1hML0JIWG1WZEtHSXNxODNxeEFUb3Q1Rk41aEN5MXc1?= =?utf-8?B?cEVBL0lCMFJydXY4REIwNVh5VTdRVGE1eU5mQlhwUWJjc1I3bTRkWWo1R0ZK?= =?utf-8?B?TCswcmRnSzMvUktDWDl0Vm1SL1MyTW5hRUxjSHg0TEdXUWtDcThacng4ZDdN?= =?utf-8?B?TkhYbnhLdWlOTVErQkNyK3R3SGlDUXZEb0o1dkZCOWszNWIrVjRCcWtTN21a?= =?utf-8?B?WGxKVy9SWS82Yld6YVhCT0VrK2x2bm1mQzZ5dTFNYXlZaW9sRWs0d2Q1Sjlu?= =?utf-8?B?cUZNaG8xVEloS2wxSVpIN1g1RUlSS2ZrZnNXN3hPUkkrT3VJL3VmUmtKelVv?= =?utf-8?B?aVFNaW8rN0pReUNtMW9OcHA4U2lGNnNYRGgrN1ZHZ3FKNDU2cFBFVjlvSDBp?= =?utf-8?B?cW9ucWFwTi9UQUozd01zMmJnZnMvMnFGemp2L0U3V0RQTVdFT1VVR1d1ZEZ0?= =?utf-8?B?VFZQRFFUMStUQVQzS3dqekFLeXNrdUNzNUlsbHUxMjZvcEtWRnhibzlKS2lp?= =?utf-8?B?dzFuUHljY3hnOURaOWlHSkFENkNkNFR2TFJLQ21YVzYzWDRUSHZPeitSeUVN?= =?utf-8?B?TjZaTG9jODl4QUZWMEQ4Rm9XeGFOVWs0YU1YUmtyOFdBOW9kVXc5MFVBcGFz?= =?utf-8?B?NVFTMW1JSUxsRm5pTzJNSHgweG44WWFFMmpnSi8xMGQ4Y2pkRzg2MVI2THhu?= =?utf-8?B?ek91N1YvekJIQ2tQTnExVk41blA5dmNjbTlhaGdnNWNWZEN3Mm0zZDROaTBT?= =?utf-8?B?YVhFcnVaSllJVmVNT1Q1bjIyZ016VlNMN0R1bDU1YStIR2gxaEhvZ2hXUTdE?= =?utf-8?B?cWM4NXIrSm1OYTVweUo3VlFUcDF2Wk1ESUdiWHBSZjE0NFI5b1FMYlRCU1dw?= =?utf-8?B?WGluR3BGandNdnMydE12aVdySFpjc01aWUcvd0pjVERFWUlGVWdkYWVUa3F0?= =?utf-8?B?NXJHanVxeVcrZU5Db3hidys0WmtQZWtuRWE0OXBNbVNqWm56Z0s1LzlCL0d2?= =?utf-8?Q?3pEWEEEGZZ+Iflr/sjY5YayjmGLJf3JhgEbwPGn?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: e64849e7-6004-4706-6e11-08d98f1a6801 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Oct 2021 13:56:22.8811 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: IQdqzwAelVJseKRO+/DfdHhaF9goYMyiifcsGPfRTWOALBSZztyfbNwnQZ2M/Vitxrc0CZ87KF6+aPYkGh723g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9P189MB1498 Archived-At: Subject: Re: [core] CoRE rechartering: proposed text X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 14 Oct 2021 13:56:42 -0000 --e2Ez66JLFivLKOcepd4uzEWIVJ1cwVcpA Content-Type: multipart/mixed; boundary="JzdETBVjboGfRy0nosunLouSmhPqySv5p"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: <290101ab-0022-0ed7-424e-dc5d6c73b401@ri.se> Subject: Re: [core] CoRE rechartering: proposed text References: In-Reply-To: --JzdETBVjboGfRy0nosunLouSmhPqySv5p Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi all, Following the discussion at the 2021-10-13 interim meeting [1], we have=20 now made available the compressed charter text proposed by G=C3=B6ran ---= Thanks! This is essentially a subset of the original proposal from 2021-09-08=20 with roughly the same content but fewer words. Hence, it is an improved=20 starting point to build a revised charter for more convenient considerati= on. You can find the compressed text as a Pull Request at [2] and at the top = of the usual CodiMD document at [3]. No word-smithing has been done on=20 this text yet. Please, provide any comment and contribution on [2] and [3] as you prefer= =2E Thanks, Marco and Jaime [1]=20 https://datatracker.ietf.org/doc/minutes-interim-2021-core-12-20211013160= 0/ [2] https://github.com/core-wg/core-wg.github.io/pull/1 [3] https://notes.ietf.org/BkpQ-gttSRuVKlEgxho5gw?both On 2021-09-20 14:17, Esko Dijk wrote: > Hello, > > Current text looks good to me. It is a quite detailed charter; good to = have it updated now to reflect recent progress. Also it is good as an int= roduction to CoRE, or as overview of the latest status & work. > Possible downside of a detailed charter is that it needs to be updated = more often! > > Regards > Esko > > -----Original Message----- > From: core On Behalf Of Marco Tiloca > Sent: Thursday, September 16, 2021 09:22 > To: core@ietf.org WG (core@ietf.org) > Subject: Re: [core] CoRE rechartering: proposed text > > Hi all, > > During the 2021-09-15 interim meeting [1], we had a good first > discussion on the proposed new text for the possible updated charter. > > As mentioned at the meeting, please take some time to review the new > text and possibly provide input/comments. Even in case you are just fin= e > with the text "as is", it is valuable feedback to say so. > > > Please, provide your comments and proposed changes: > > - In this mail thread, where the first message [2] also includes the ne= w > proposed charter text; > > and/or > > - In this CodiMD document [3], where editing requires to be logged in > with your Datatracker account. > > > The new charter text is also available on our Github at [4], together > with a diff from the present charter text at [5]. > > Thanks, > Marco and Jaime > > > [1] > https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdat= atracker.ietf.org%2Fdoc%2Fminutes-interim-2021-core-10-202109151600%2F&am= p;data=3D04%7C01%7Cmarco.tiloca%40ri.se%7Cdb0df2811ff940f7d5f308d97c30adb= d%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637677371541036914%7CUnkno= wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX= VCI6Mn0%3D%7C3000&sdata=3DQOc1k5wnajJE0H%2B7gSKx5RAmjWrI6eC3pIJz38f1K= sk%3D&reserved=3D0 > > [2] https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2= Fmailarchive.ietf.org%2Farch%2Fmsg%2Fcore%2FhaBtninO85UjsyqASeeO0FFr_Wo%2= F&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7Cdb0df2811ff940f7d5f308d97c3= 0adbd%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637677371541036914%7CU= nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi= LCJXVCI6Mn0%3D%7C3000&sdata=3D1opdeqGfrPVvgperbBLRrb%2Fn9oMMxQHHGp9li= 5UnlW4%3D&reserved=3D0 > > [3] https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2= Fnotes.ietf.org%2FBkpQ-gttSRuVKlEgxho5gw%3Fboth&data=3D04%7C01%7Cmarc= o.tiloca%40ri.se%7Cdb0df2811ff940f7d5f308d97c30adbd%7C5a9809cf0bcb413a838= a09ecc40cc9e8%7C0%7C0%7C637677371541036914%7CUnknown%7CTWFpbGZsb3d8eyJWIj= oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&s= data=3Dwy7ZjbOS%2Fq8AKEu5N4l67WVb322r0pYYvwEYjsLQomo%3D&reserved=3D0 > > [4] > https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgit= hub.com%2Fcore-wg%2Fcore-wg.github.io%2Fblob%2Fmaster%2Fcore-charter.txt&= amp;data=3D04%7C01%7Cmarco.tiloca%40ri.se%7Cdb0df2811ff940f7d5f308d97c30a= dbd%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637677371541036914%7CUnk= nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC= JXVCI6Mn0%3D%7C3000&sdata=3DGUk2LT8JmyhSRH1cXjWjKkc%2BPtDfiRKjrUNsQVo= fLok%3D&reserved=3D0 > > [5] > https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgit= hub.com%2Fcore-wg%2Fcore-wg.github.io%2Fcommit%2F133861a92ef62a2130427521= 455fb58bce23aa3e%3Fbranch%3D133861a92ef62a2130427521455fb58bce23aa3e%26di= ff%3Dsplit&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7Cdb0df2811ff940f7d5= f308d97c30adbd%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C6376773715410= 36914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI= 6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DPrCkKcNmh%2FxDWOyfRCSeuClrvu9o= PpjNJJai77AGiZE%3D&reserved=3D0 > > > On 2021-09-08 19:34, Marco Tiloca wrote: >> Hi all, >> >> During the CoRE session at IETF 111 [1][2], it was proposed to update >> our charter, for better reflecting the current status of our work. >> This is also helpful for the IESG review processing and for newcomers >> to more easily understand the WG scope and direction. >> >> As promised, the Chairs have prepared an initial proposed text for the= >> WG to consider. Please, find the proposed text at the end of this mail= >> as well as in the CodiMD at [3]. >> >> With that as starting point, this mail starts a discussion on the new >> charter text. Please, provide your comments and proposed changes here >> on the mailing list or in the CodiMD at [3] (editing requires to be >> logged in). >> >> Best, >> Marco and Jaime >> >> >> [1] https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%= 2Fdatatracker.ietf.org%2Fdoc%2Fminutes-111-core%2F&data=3D04%7C01%7Cm= arco.tiloca%40ri.se%7Cdb0df2811ff940f7d5f308d97c30adbd%7C5a9809cf0bcb413a= 838a09ecc40cc9e8%7C0%7C0%7C637677371541036914%7CUnknown%7CTWFpbGZsb3d8eyJ= WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&am= p;sdata=3Dhp16Z5Pul%2BWqb3%2B3tZLBcqG9zpdacPKES39lKlQwYxk%3D&reserved= =3D0 >> >> [2] >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fda= tatracker.ietf.org%2Fmeeting%2F111%2Fmaterials%2Fslides-111-core-chairs-s= lides-00.pdf&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7Cdb0df2811ff940f7= d5f308d97c30adbd%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C63767737154= 1036914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT= iI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3D5KYC8BayVPx1Av5wXVkYHRruS1WZ= elLIVdmsutk0q8o%3D&reserved=3D0 >> >> [3] https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%= 2Fnotes.ietf.org%2FBkpQ-gttSRuVKlEgxho5gw%3Fboth&data=3D04%7C01%7Cmar= co.tiloca%40ri.se%7Cdb0df2811ff940f7d5f308d97c30adbd%7C5a9809cf0bcb413a83= 8a09ecc40cc9e8%7C0%7C0%7C637677371541036914%7CUnknown%7CTWFpbGZsb3d8eyJWI= joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&= sdata=3Dwy7ZjbOS%2Fq8AKEu5N4l67WVb322r0pYYvwEYjsLQomo%3D&reserved=3D0= >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> The CoRE Working Group (WG) provides a framework for resource-oriented= >> applications intended to run on constrained IP networks. A constrained= >> IP network has limited packet sizes, may exhibit a high degree of >> packet loss, and may have a substantial number of devices that may be >> powered off at any point in time but periodically "wake up" for brief >> periods of time. These networks and the nodes within them are >> characterized by severe limits on throughput, available power, and >> particularly on the complexity that can be supported with limited code= >> size and limited RAM per node [RFC 7228]. More generally, we speak of >> constrained node networks whenever at least some of the nodes and >> networks involved exhibit these characteristics. Low-Power Wireless >> Personal Area Networks (LoWPANs) are an example of this type of >> network. Constrained networks can occur as part of home and building >> automation, energy management, and the Internet of Things. >> >> The CoRE WG will define a framework for a limited class of >> applications: those that deal with the manipulation of simple >> resources on constrained networks. This includes applications to >> monitor simple sensors (e.g., temperature sensors, light sensors, and >> power meters), to control actuators (e.g., light switches, heating >> controllers, and door locks), and to manage devices. >> >> The general architecture targeted by the CoRE WG framework consists of= >> nodes on the constrained network, called Devices, that are responsible= >> for one or more Resources that may represent sensors, actuators, >> combinations of values, and/or other information. Devices send >> messages to change and query resources on other Devices. A Device can >> send notifications about changed resource values to Devices that have >> expressed their interest to receive notification about changes. A >> Device can also publish or be queried about its resources. Typically, >> a single physical host on the network would have just one Device but a= >> host might represent multiple logical Devices. The specific >> terminology to be used here is to be decided by the working group. >> >> As part of the framework for building these applications, the CoRE WG >> has defined the Constrained Application Protocol (CoAP) for the >> manipulation of Resources on a Device. CoAP is designed for use >> between Devices on the same constrained network, between Devices and >> general nodes on the Internet, and between Devices on different >> constrained networks both joined by an internet. CoAP is also being >> used via other mechanisms, such as SMS on mobile communication >> networks. CoAP targets the type of operating environments defined in >> the ROLL and 6Lo WGs, which have additional constraints compared to >> normal IP networks. Nevertheless, the CoAP protocol also operates over= >> traditional IP networks. >> >> There also may be intermediary nodes acting as proxies that possibly >> also interconnect between other Internet protocols and the Devices >> using the CoAP protocol. It is worth noting that a proxy does not have= >> to occur at the boundary between the constrained network and the more >> general network, but can be deployed at various locations in the >> less-constrained network. The CoRE WG will continue to evolve the >> support of proxies for CoAP to increase their practical applicability.= >> >> CoAP supports various forms of "caching". Beyond the benefits of >> caching already well known from REST, caching can be used to increase >> energy savings of low-power nodes by allowing them to be normally-off >> [RFC 7228]. For example, a temperature sensor might wake up every five= >> minutes and send the current temperature to a proxy that has expressed= >> interest in notifications. When the proxy receives a request over CoAP= >> or HTTP for that temperature resource, it can respond with the last >> notified value, instead of trying to query the Device which may not be= >> reachable at this time. The CoRE WG will continue to evolve this model= >> to increase its practical applicability. >> >> The CoRE WG will perform maintenance as well as possible updating and >> complementing on its first four standards-track specifications as >> required: >> >> - RFC 6690 >> - RFC 7252 >> - RFC 7641 >> - RFC 7959 >> >> The CoRE WG will continue to evolve the support for CoAP group >> communication originally developed in the Experimental RFC 7390. The >> CoRE WG will not develop a solution for reliable multicast delivery of= >> CoAP messages, which will remain Non-Confirmable when sent over >> multicast. >> >> RFC 7252 defines a basic HTTP mapping for CoAP, which was further >> elaborated in RFC 8075. This mapping will be evolved and supported by >> further documents as required. >> >> CoAP was initially designed to work over UDP and DTLS. Later on, >> mapping were defined between CoAP and IP-based transports, especially >> TCP and WebSockets including a secure version over TLS (RFC 8323). The= >> CoRE WG will continue defining transport mappings for alternative >> transports as required, both IP-based and non IP-based (e.g., SMS and >> Bluetooth), working with the Security Area on potentially addressing >> the security gap. This includes defining appropriate URI schemes. >> Continued compatibility with CoAP over SMS as defined in OMA >> Lightweight Machine-to-Machine (LwM2M) will be considered. >> Furthermore, the CoRE WG will work on solutions to facilitate the >> signaling of transports available to a Device. >> >> The CoRE WG will continue and complete its work on the CoRE Resource >> Directory (draft-ietf-core-resource-directory), as already partially >> adopted by OMA LwM2M, and will perform maintenance as well as possible= >> updating, complementing and specification of relevant uses as >> required. A primary related consideration is the interoperability with= >> DNS-SD and the work of the dnssd WG. The use of CoAP to transport DNS >> queries and responses will also be investigated. Furthermore, the CoRE= >> WG will also continue and complete its work on enabling broker-based >> publish-subscribe-style communication over CoAP >> (draft-ietf-core-coap-pubsub). >> >> The CoRE WG will work on related data formats, such as alternative >> representations of RFC 6690 link format and RFC 7390 group >> communication information. Also, the CoRE WG will complete its work on= >> Constrained Resource Identifiers for serializing URI components in >> CBOR (draft-ietf-core-href). Furthermore, the CoRE WG will develop >> CoRAL (draft-ietf-core-coral), a constrained RESTful application >> language suitable also for constrained node networks, which comprises >> an information model and an interaction model, and is intended for >> driving automated software agents that navigate a Web application. The= >> CoRE WG will complete the Sensor Measurement Lists (SenML) set of >> specifications, again with consideration to its adoption in OMA LwM2M.= >> >> Besides continuing to examine operational and manageability aspects of= >> the CoAP protocol itself, the CoRE WG will also complete the work on >> RESTCONF-style management functions available via CoAP that are >> appropriate for constrained node networks (draft-ietf-core-yang-cbor, >> draft-ietf-core-sid, draft-ietf-core-comi, >> draft-ietf-core-yang-library). This requires very close coordination >> with NETCONF and other operations and management WGs. YANG data models= >> are used for manageability. Note that the YANG modeling language is >> not a target for change in this process, although additional >> mechanisms that support YANG modules may be employed in specific cases= >> where significant performance gains are both attainable and required. >> The CoRE WG will continue to consider the OMA LwM2M management >> functions as a well-accepted alternative form of management and >> provide support at the CoAP protocol level where required. >> >> The CoRE WG originally selected DTLS as the basis for the >> communication security in CoAP. The CoRE WG will work with the TLS WG >> on the efficiency of this solution. The preferred cipher suites will >> evolve in cooperation with the TLS WG and CFRG. >> >> The CoRE WG considered object security as originally defined in JOSE >> and later adapted to the constrained node network requirements in >> COSE. Building on that, the CoRE WG has defined the Object Security >> for Constrained RESTful Environments (OSCORE) protocol (RFC 8613) for >> protecting CoAP messages at the application layer using COSE. The CoRE= >> WG will complete the work on the Group OSCORE protocol >> (draft-ietf-core-oscore-groupcomm) that enables OSCORE-protection of >> CoAP messages in group communication environments. Also, the CoRE WG >> will complete an optimization-oriented profiling of the EDHOC protocol= >> developed in the LAKE WG, when this is used to establish security >> material for OSCORE (draft-ietf-core-oscore-edhoc). Furthermore, the >> CoRE WG will perform maintenance as well as possible updating and >> complementing of the (Group) OSCORE documents above as required. >> >> The ACE WG is expected to provide solutions on authentication and >> authorization that may need complementary elements on the CoRE side. >> >> The CoRE WG will coordinate on requirements from many organizations >> and SDOs. The CoRE WG will closely coordinate with other IETF WGs, >> particularly of the constrained node networks cluster (6Lo, 6TiSCH, >> LWIG, ROLL, ACE, CBOR, COSE, IOTOPS, LAKE, SUIT), and with further >> appropriate groups in the IETF OPS and Security Areas. Work on these >> subjects, as well as on data/interaction models and design patterns >> (including follow-up work around the CoRE Interfaces draft) will >> additionally benefit from close cooperation with the Thing-to-Thing >> Research Group. >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> --=20 Marco Tiloca Ph.D., Senior Researcher Division: Digital System Department: Computer Science Unit: Cybersecurity RISE Research Institutes of Sweden https://www.ri.se Phone: +46 (0)70 60 46 501 Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) --JzdETBVjboGfRy0nosunLouSmhPqySv5p-- --e2Ez66JLFivLKOcepd4uzEWIVJ1cwVcpA Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmFoNwQFAwAAAAAACgkQ7iZktA5Y2kN7 RQf9ECGOQla+VhLdomXdLp6Es+hMGL37DYFNxETWlZQCLtP0shZRpJP0r27FxUUlShFu+bRLBtHj I3CjKvuccUYWLw3BWgGeJP4OdhF3OC8zRyjIHTapXa0s+tw5hv83yrXgGc+Obnd96eacAsI7d25m gK4TK2tBNJ4hgBkFl9nd8/gEwPiDVZQCC3bd+rml4McCn7zj6/saJTMk7EYUHrSI85dTvjHulE01 +MgJA++xWqsMceoFJ9CnR7UmFZn9P2qDuEDtJ0PT8SECmBbMuiOAMQjRqjs6TwnN2PzUU4qeMxK9 K6TKB4nX7VFU2sGk6CzdNiJWDrQ17i7A6W+ZXSeM6w== =YbYg -----END PGP SIGNATURE----- --e2Ez66JLFivLKOcepd4uzEWIVJ1cwVcpA-- From nobody Thu Oct 14 08:46:33 2021 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 DE0133A0B85 for ; Thu, 14 Oct 2021 08:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, 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 R9VPXB_0seGx for ; Thu, 14 Oct 2021 08:46:28 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A46D3A0B04 for ; Thu, 14 Oct 2021 08:46:26 -0700 (PDT) Received: from [192.168.217.118] (p5089a8ac.dip0.t-ipconnect.de [80.137.168.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4HVYfR1lvpz2xw0; Thu, 14 Oct 2021 17:46:23 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <290101ab-0022-0ed7-424e-dc5d6c73b401@ri.se> Date: Thu, 14 Oct 2021 17:46:22 +0200 Cc: "core@ietf.org WG (core@ietf.org)" X-Mao-Original-Outgoing-Id: 655919182.73095-d97d37e4e61a2c3edfbc49f27f1254ed Content-Transfer-Encoding: quoted-printable Message-Id: <04BC197B-552E-448C-8DFD-46CD3C107B74@tzi.org> References: <290101ab-0022-0ed7-424e-dc5d6c73b401@ri.se> To: Marco Tiloca X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] CoRE rechartering: proposed text X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 14 Oct 2021 15:46:32 -0000 > You can find the compressed text as a Pull Request at [2] and at the = top of the usual CodiMD document at [3]. No word-smithing has been done = on this text yet. Pre-warning: I think the long shopping list in the middle needs = subheadings (which charters don=E2=80=99t have yet), so expect a PR from = me within a week (unless someone else beats me to it). Gr=C3=BC=C3=9Fe, Carsten >=20 > Please, provide any comment and contribution on [2] and [3] as you = prefer. >=20 > Thanks, > Marco and Jaime >=20 >=20 > [1] = https://datatracker.ietf.org/doc/minutes-interim-2021-core-12-202110131600= / >=20 > [2] https://github.com/core-wg/core-wg.github.io/pull/1 >=20 > [3] https://notes.ietf.org/BkpQ-gttSRuVKlEgxho5gw?both From nobody Fri Oct 15 05:57:14 2021 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 22B453A079D; Fri, 15 Oct 2021 05:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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=seicmu.onmicrosoft.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 5n7IJ0gCHLiA; Fri, 15 Oct 2021 05:57:06 -0700 (PDT) Received: from USG02-BN3-obe.outbound.protection.office365.us (mail-bn3usg02on0118.outbound.protection.office365.us [23.103.208.118]) (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 2CC8D3A0787; Fri, 15 Oct 2021 05:57:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=Dz+hBMDMmCZ4CnOHWdTLqEILYxySD+IvwUNhW7K5OuFj/uoX2ZhX+9cz6twDlknDWafQ3beFgQ0iJYloQD6LaCtJoolNXgEfq9U8zkZmzhC2VYCiengD7NTBZYck+TMszwqk9bEG8hGXk7jMrbFcAALzVW+AbES/YNtJ/BYjEnf8uZXSHA21/JfiVOZS+QryKPm2czUgHfuXFxcqIutFr8UGhwC/OpxnJIh2j+CFWsuR3ZxnS/9s6JmHqMnLrEuVmzCVA6BU2RWCZHiJGluJeP0irIC1oON/bsRrE5YST3yErTf0U4MmRrTG24Bu3wjpDhQyPYBsNWZzEgaCdVH6/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector5401; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WhMmXbWeKpWs7B/7XoFt758yYTD3i5PTcIqTsPto3I4=; b=vY6SlbixF7qBmbcFqOrxiftozhMNbqBZr4L/X9qGp1rb7Gr15Ow7LHqn7Fy7n9vBSvW1TWQGLnsqT+vRANAJLxwx6+oUijafW6GJ3RvCWySlzWlhU5VMcs45qnRS9K3lVUN9XKSrsnEYkQByh5lJANSekvx79HW2y69ew5eNIDR1FcTVNcnD1kVS5km6XCuegm0B1uTZfRoRHiVYM5fXn6ksXS1tG1Yg81WC1srgO9yB1oaejnDy2hZb6ns/eTp/Z35JqUXjvwxgoeoeElxAb2l6ucn/TUDyxclk3GZ5pYoflIybHsrtRNJa8rwF8ZhBE38XcW9Vw+7omtVh7UMFDA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cert.org; dmarc=pass action=none header.from=cert.org; dkim=pass header.d=cert.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seicmu.onmicrosoft.com; s=selector1-seicmu-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WhMmXbWeKpWs7B/7XoFt758yYTD3i5PTcIqTsPto3I4=; b=RQN75+/mSc5K0yc2qbdlXN13+arkOu3Jxkmgrzt5L8Z9E9gBt471Zrvy9J+PzkPimZcdiFJ+OcjslLVG8U+dHOxVbWep05t2OZ103nx7ZkKnBuPBJdRllQDh171wbTqjT9BoTNq2h8pkbqcvkxVqadx/Mxuq5wjxZCwtM+r5OXk= Received: from BN1P110MB0939.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:134::12) by BN1P110MB0628.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:133::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.22; Fri, 15 Oct 2021 12:56:50 +0000 Received: from BN1P110MB0939.NAMP110.PROD.OUTLOOK.COM ([fe80::4463:48d1:9769:567f]) by BN1P110MB0939.NAMP110.PROD.OUTLOOK.COM ([fe80::4463:48d1:9769:567f%6]) with mapi id 15.20.4587.031; Fri, 15 Oct 2021 12:56:49 +0000 From: Roman Danyliw To: =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= CC: "draft-ietf-core-echo-request-tag@ietf.org" , "core-chairs@ietf.org" , The IESG , "core@ietf.org" Thread-Topic: [core] Roman Danyliw's No Objection on draft-ietf-core-echo-request-tag-12: (with COMMENT) Thread-Index: AQHXBW8cvCaSDidzg0Coyufct8gU8atKGyyAgIthmfA= Date: Fri, 15 Oct 2021 12:56:49 +0000 Message-ID: References: <161359527152.11372.63177839446582675@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: amsuess.com; dkim=none (message not signed) header.d=none;amsuess.com; dmarc=none action=none header.from=cert.org; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c851710b-d088-4882-c9b3-08d98fdb40ec x-ms-traffictypediagnostic: BN1P110MB0628: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: zx75xNjyRG0DnhQKvJAsP1OhbTfhYUPt9OZsqiYxWWzPBVUwsiEAR/f416T8lnGdvI3VseTpyiV2RZxNtTjTnQfX1l0ZBGcCVK3gUrutjB1kf+qt9k19E6quITiqSw4L4gVt68gD7UlEfKmphe+AY+0AYHq2H9fZZfpWriR+zm/9P1y8WK8/kP56uSqfT12PKQyoUaJ7Ma6edyEu4hV9kfw3mNIHxYVN6oIE+h5/3s5m4h7MfXqhx9qv9gNpQ5xntj2IfmJvIFsBzgiNkuMRxJXvBMkIlSdI6MV36Iyxmf3Txcmj4kNgZf45yciJvahuRZr5O5pTymzVUO8cIMLphsQaLFgP7PLqtqFCKEt3vZhW2Xe1/H1HqcDBSgMqvQrjE14/CMHTZIPQeh3DP4MSU075wmqUpmOkECpdTX6sdSTiMWxdkX970NYOHNX8bYqYh5yN28LaOdThkJSVdQBKuOZo5j+J6RryL0HTevmQONcaZYeZk0rra1BQAH/cl/cRHUf/Mt9MGnLdukHQwfhqinMSXrgXGtX5SIHTEeSngrlQti0+8dVCLoiqg7ca4PFSImUePK9ocxgSXjBgBGtC3Fc+B4XWzvR/zBQNuXKRS+smOMIjvGhpqS9TlbonySrf4G6W2+/eqhsLNmTpsQf6pVxTANenXWhrTfSoEGVIXbBI+pb5Sl22v6PScSYtad8iUA/oLldp4QENMVgQDRHufg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN1P110MB0939.NAMP110.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(86362001)(186003)(83380400001)(66574015)(8676002)(5660300002)(6916009)(9686003)(54906003)(53546011)(2906002)(26005)(7696005)(6506007)(55016002)(8936002)(76116006)(33656002)(38100700002)(122000001)(52536014)(71200400001)(4326008)(82960400001)(38070700005)(966005)(498600001)(66476007)(64756008)(66556008)(66446008)(66946007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: 5Z+PDkJklvt0vPULXU3z7nRWlLmWdcnN0tkcJiObJpRwfdofu131Ojl34p4jyNL0CvLSb4lWR4DIEtYTrVfsjvRsueDkXQyFEta3yOVDqMzQJUyR9OFFstR4KSpolgygP8I/wRMpMBd2RdVEYA+p1D2IzygUDxYEk0SNppnScfZLB5hPTB7cyy7K1MRLMZEF3Jf3n1r2zieyvuk58dGbd9dSLH4gLXXdjW+VU+66La8cpD6OXeS1ng/yIZZC7HYSg6O9ofVE53SULcCPqPNfRigQFPBBnATZHq/GVDezWySOh0I9a3TPwKlzJK25uT2lBjbeACqgHHT/FLKV9Nxrdo+Pd1g2w6pqySD1FX7iKmCiYysBVYuDZCTFpWUHAxMpl+bJrE0e5xBQnQDpitZo0n3l/wWdU66KOR58PqXWLXdPML3+SiOXjsMCCDN67zNnrKzO3F3CxgbA0wBKAdr68Q1oH5mYZrjW+yBl9dALl8A+WGzFh5+uIX+pd/pTssJvsY4ou0cscXvoZLrp6BCsajMMzs7fXlPGwrIRcKJ8EH1zryXu0DxcIWc1cRue2ON741OG9Cs6f7ApaJa8jhW4E55gCvJTY8fa5FM8ckuHcyS40589VeN18p3T/YadjUGQeO1V+oZirU8kVALGrb0CuUOpl1E9IganjxVjurlidbLDpMc6x62OqE+f+BojFIMtzob2OhVil98Dx0QgrF83ayMdXZZKRWTMjS6hLk+tw6g= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: cert.org X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN1P110MB0939.NAMP110.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: c851710b-d088-4882-c9b3-08d98fdb40ec X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2021 12:56:49.8336 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 95a9dce2-04f2-4043-995d-1ec3861911c6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1P110MB0628 Archived-At: Subject: Re: [core] Roman Danyliw's No Objection on draft-ietf-core-echo-request-tag-12: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 15 Oct 2021 12:57:12 -0000 SGkgQ2hyaXN0aWFuIQ0KDQpTaW5jZXJlIGFwb2xvZ2llcyBmb3IgdGhpcyB0YXJkeSByZXNwb25z ZS4gIFRoYW5rIHlvdSBmb3IgdGhpcyBkZXRhaWxlZCBleHBsYW5hdGlvbiBhbmQgdGhlIHBvaW50 ZXIgdG8gdGhlIGdlbmVyaWMtc2hvcnQtZWNoby4gIFRoaXMgd29ya3MgZm9yIG1lLiAgUGxlYXNl IGNvbnNpZGVyIG15IGNvbW1lbnRzIHJlc29sdmVkLg0KDQpSb21hbg0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGllc2cgPGllc2ctYm91bmNlc0BpZXRmLm9yZz4gT24g QmVoYWxmIE9mIENocmlzdGlhbiBBbXPDvHNzDQo+IFNlbnQ6IFN1bmRheSwgSnVseSAxOCwgMjAy MSA0OjI1IFBNDQo+IFRvOiBSb21hbiBEYW55bGl3IDxyZGRAY2VydC5vcmc+DQo+IENjOiBkcmFm dC1pZXRmLWNvcmUtZWNoby1yZXF1ZXN0LXRhZ0BpZXRmLm9yZzsgY29yZS1jaGFpcnNAaWV0Zi5v cmc7IFRoZSBJRVNHDQo+IDxpZXNnQGlldGYub3JnPjsgY29yZUBpZXRmLm9yZw0KPiBTdWJqZWN0 OiBSZTogW2NvcmVdIFJvbWFuIERhbnlsaXcncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1j b3JlLWVjaG8tDQo+IHJlcXVlc3QtdGFnLTEyOiAod2l0aCBDT01NRU5UKQ0KPiANCj4gSGVsbG8g Um9tYW4sDQo+IA0KPiB0aGFua3MgZm9yIHlvdXIgaW5wdXQgb24gZWNoby1yZXF1ZXN0LXRhZywg YW5kIGFwb2xvZ2llcyBmb3IgdGhlIGRlbGF5IGluDQo+IHByb2Nlc3NpbmcgdGhlbSB0byBjb21w bGV0aW9uLg0KPiANCj4gUGxlYXNlIHNlZSBbMV0gZm9yIGEgZmV3IGdlbmVyYWwgY29tbWVudHM7 IGhlcmUgYXJlIGluZGl2aWR1YWwgcmVzcG9uc2VzIHRvDQo+IHlvdXIgY29tbWVudHM6DQo+IA0K PiA+ICoqIFNlY3Rpb24gNS4gIFBlciDigJxBcyBlYWNoIHBzZXVkb3JhbmRvbSBudW1iZXIgbW9z dCBvbmx5IGJlIHVzZWQgb25jZQ0KPiDigKbigJ0sIGhvdyB3aWxsIHRoYXQgYmUgcG9zc2libGUg d2hlbiBlY2hvIHZhbHVlcyBhcyBzbWFsbCBhcmUgMS1ieXRlIGFyZQ0KPiBwb3NzaWJsZT8NCj4g DQo+IE5vdCBhbGwgYXBwbGljYXRpb25zIG9mIEVjaG8gZGVwZW5kIG9uIHBzZXVkb3JhbmRvbSBu dW1iZXJzLiBXaGVyZSB0aGV5IGRvDQo+IG5vdCwgdGhlaXIgY29uc3RydWN0aW9uIGNhbiBlbnN1 cmUgdGhhdCBvbmx5IHVuaXF1ZSAxLWJ5dGUgdmFsdWVzIGFyZSB1c2VkLnVudGlsDQo+IHRoZXNl IGFyZSBleGhhdXN0ZWQuDQo+IA0KPiBTZWUgYWxzbyBHRU5FUklDLVNIT1JULUVDSE9bMV0uDQo+ IA0KPiA+ICoqIFNlY3Rpb24gNS4NCj4gPiBIb3dldmVyLCB0aGlzIG1heSBub3QgYmUgYW4gaXNz dWUgaWYgdGhlDQo+ID4gICAgY29tbXVuaWNhdGlvbiBpcyBpbnRlZ3JpdHkgcHJvdGVjdGVkIGFn YWluc3QgdGhpcmQgcGFydGllcyBhbmQgdGhlDQo+ID4gICAgY2xpZW50IGlzIHRydXN0ZWQgbm90 IG1pc3VzaW5nIHRoaXMgY2FwYWJpbGl0eS4NCj4gPg0KPiA+IC0tIFdoeSBpcyB0aGUgdXNlIG9m IGludGVncml0eSBwcmVzZW50ZWQgYXMgb25seSBhIHBvc3NpYmlsaXR5IGhlcmU/ICBEaWRu4oCZ dA0KPiBTZWN0aW9uIDIuMyByZXF1aXJlIGl0IHdoZW4gYXNzdXJpbmcgdGhlIGZyZXNobmVzcyBy ZXF1aXJlbWVudCDigJMg4oCcV2hlbiB1c2VkDQo+IHRvIHNlcnZlIGZyZXNobmVzcyByZXF1aXJl bWVudHMgaW5jbHVkaW5nIGNsaWVudCBhbGl2ZW5lc3MgYW5kIHN0YXRlDQo+IHN5bmNocm9uaXpp bmcpLCB0aGUgRWNobyBvcHRpb24gdmFsdWUgTVVTVCBiZSBpbnRlZ3JpdHkgcHJvdGVjdGVkIGJl dHdlZW4gdGhlDQo+IGludGVuZGVkIGVuZHBvaW50cyAuLi7igJ0NCj4gPiAtLSBXb3VsZCBpdCBi ZSBjbGVhcmVyIGhlcmUgdG8gc2F5IHRoYXQgdGhpcyBpcyBtaXRpZ2F0aW9uIGFnYWluc3QgYW4g b24tcGF0aA0KPiBhdHRhY2tlciwgbm90IGFnYWluc3Qgcm9ndWUvY29tcHJvbWlzZWQgY2xpZW50 cz8NCj4gDQo+IEluIHRoZSBjb3Vyc2Ugb2YgdGhlIEdFTkVSSUMtU0hPUlQtRUNITyBjaGFuZ2Vz LCB0aGlzIGhhcyBiZWVuIG1hZGUgbW9yZQ0KPiBwcmVjaXNlIHVzaW5nIHRoZSBjb25jZXB0IG9m ICJhdXRob3JpdHkgb3ZlciBzeW5jaHJvbml6ZWQgcHJvcGVydHkiDQo+IGludHJvZHVjZWQgdGhl cmUuDQo+IA0KPiA+ICoqIEFwcGVuZGl4IEEgaGVscGZ1bGx5IHRyaWVzIHRvIGxheSBvdXQgcmVj b21tZW5kYXRpb25zLiAgQSBmZXcgY29tbWVudHM6DQo+ID4NCj4gPiAtLSBhbGwgb2YgdGhlIHJl Y29tbWVuZGF0aW9ucyBoZXJlIGhhdmUgb3B0aW9uIHZhbHVlcyBtdWNoIGxhcmdlciB0aGFuDQo+ ID4gdGhlIHBlcm1pdHRlZCBtaW5pbXVtIG9mIDEtYnl0ZS4gIEluIGFkZGl0aW9uIHRvIHRoZSBy ZWNvbW1lbmRhdGlvbnMsDQo+ID4gY291bGQgdGhlIGNpcmN1bXN0YW5jZXMgb2YgdGhlIGxvd2Vy IGJvdW5kIGFsc28gYmUgZGlzY3Vzc2VkDQo+IA0KPiBJdGVtIDMgb2YgYXBwZW5kaXggQSBjYW4g YmUgYXMgc2hvcnQgYXMgMSBieXRlICh1bnRpbCBpdCBvdmVyZmxvd3MgdG8gMiksIHdpdGggYQ0K PiBjb25jcmV0ZSBleGFtcGxlIGxpbmtlZCwgYW5kIGluY2x1ZGVzIGEgcmVxdWlyZW1lbnQgZm9y IGl0cyBhcHBsaWNhYmlsaXR5Lg0KPiANCj4gPiAtLSBpdCB3b3VsZCBiZSBoZWxwZnVsIHRvIGV4 cGxpY2l0bHkgc3RhdGUgd2hpY2ggbWV0aG9kcyBhcHBseSB0byB0aGUNCj4gPiBzcGVjaWZpYyB1 c2UgY2FzZXMgKGNsaWVudCBhbGl2ZW5lc3MsIHJlcXVlc3QgZnJlc2huZXNzLCBzdGF0ZQ0KPiA+ IHN5bmNocm9uaXphdGlvbiwgbmV0d29yayAgYWRkcmVzcyByZWFjaGFiaWxpdHkpLiAgRm9yIGV4 YW1wbGUsIG1ldGhvZA0KPiA+IDMgKHBlcnNpc3RlbnQgY291bnRlcikgbm90ZXMgdGhhdCBpdCBj YW4gYmUgdXNlZCBmb3Igc3RhdGUNCj4gPiBzeW5jaHJvbml6YXRpb24gYnV0IG5vdCBjbGllbnQg YWxpdmVuZXNzDQo+IA0KPiBUaGVzZSBhcmUgbm93IHRpZWQgdG9nZXRoZXIgYnkgdGhlIENoYXJh Y3Rlcml6YXRpb24gY2hhcHRlciBpbnRyb2R1Y2VkIGluDQo+IEdFTkVSSUMtU0hPUlQtRUNITy4N Cj4gDQo+IA0KPiBCZXN0IHJlZ2FyZHMNCj4gQ2hyaXN0aWFuDQo+IA0KPiBbMV06DQo+IGh0dHBz Oi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvY29yZS9TSUhqaU01QWpGUlpKUlpHVWpm M2NXMXNVdTQNCj4gDQo+IC0tDQo+IFRoaXMgbWF5IHNlZW0gYSBiaXQgd2VpcmQsIGJ1dCB0aGF0 J3Mgb2theSwgYmVjYXVzZSBpdCBpcyB3ZWlyZC4NCj4gICAtLSBwZXJsZGF0YSgxKSBhYm91dCBw ZXJsIHZhcmlhYmxlcw0K From nobody Fri Oct 15 15:44:25 2021 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 A458D3A0EDB; Fri, 15 Oct 2021 15:34:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: core@ietf.org, francesca.palombini@ericsson.com X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163433724558.17026.9187915778108046159@ietfa.amsl.com> Date: Fri, 15 Oct 2021 15:34:05 -0700 Archived-At: Subject: [core] core - Requested session has been scheduled for IETF 112 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2021 22:34:24 -0000 Dear Marco Tiloca, 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 requested) Monday, 8 November 2021, Session III 1600-1800 Room Name: Room 1 size: 501 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/112/sessions/core.ics Request Information: --------------------------------------------------------- Working Group Name: Constrained RESTful Environments Area Name: Applications and Real-Time Area Session Requester: Marco Tiloca Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 60 Conflicts to Avoid: People who must be present: Francesca Palombini Jaime Jimenez Marco Tiloca Resources Requested: Special Requests: Please keep the 2 hours on a single session. Please also avoid any potentially IoT related BOFs and PRGs that might come up. --------------------------------------------------------- From nobody Fri Oct 15 18:08:08 2021 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 576863A13D9; Fri, 15 Oct 2021 18:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 83yChLCfm71F; Fri, 15 Oct 2021 18:07:40 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 777F33A13D5; Fri, 15 Oct 2021 18:07:39 -0700 (PDT) Received: from smtpclient.apple (p5089a8ac.dip0.t-ipconnect.de [80.137.168.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4HWQ3X1ZTPz2xLD; Sat, 16 Oct 2021 03:07:36 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Sat, 16 Oct 2021 03:07:35 +0200 Message-Id: <1D04949B-1677-4768-937A-39F21E6327B7@tzi.org> To: ace@ietf.org, "core@ietf.org WG (core@ietf.org)" , cose@ietf.org, cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: [core] Constrained Node/Network Cluster @ IETF112: FINAL AGENDA X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 16 Oct 2021 01:07:45 -0000 Here is my usual eclectic condensed agenda based on the "FINAL" AGENDA for IETF112. Remember that further agenda changes can still happen. COSE no longer is on IOTOPS; MADINAS, ADD, INTAREA, UTA, and OPENPGP have moved around a bit. The conspicuous conflict of ASDF/LAKE/RATS remains. All times are in UTC. Note that the first week in November (W44) is the Week of Confusion, where DST has ended in Europe but not yet in North America. https://datatracker.ietf.org/meeting/agenda-utc might be handy. Gr=C3=BC=C3=9Fe, Carsten (### DST ENDS IN EUROPE ###) MONDAY, November 1, 2021 1500-1600 Hackathon Kickoff Rm 1 GEN hackathon Hackathon WEDNESDAY, November 3, 2021 1330-1500 IETF Plenary - Plenary FRIDAY, November 5, 2021 1500-1700 Hackathon Closing Rm 1 GEN hackathon Hackathon (### DST ENDS IN NORTH AMERICA ###) MONDAY, November 8, 2021 1200-1400 Session I Rm 1 ART dispatch Dispatch WG - Joint with ARTAREA Rm 7 SEC *** rats Remote ATtestation ProcedureS WG Rm 8 TSV masque Multiplexed Application Substrate over = QUIC Encryption WG 1430-1530 Session II Rm 2 INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Rm 5 RTG rift Routing In Fat Trees WG Rm 7 SEC *** suit Software Updates for Internet of Things = WG Rm 8 TSV tsvwg Transport Area Working Group WG 1600-1800 Session III Rm 1 ART *** core Constrained RESTful Environments WG Rm 3 INT add Adaptive DNS Discovery WG TUESDAY, November 9, 2021 1200-1400 Session I Rm 2 ART webtrans WebTransport WG Rm 3 INT intarea Internet Area Working Group WG Rm 6 RTG raw Reliable and Available Wireless WG Rm 7 SEC secdispatch Security Dispatch WG 1430-1530 Session II Rm 1 ART sedate Serialising Extended Data About Times = and Events WG Rm 3 INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Rm 4 IRTF maprg Measurement and Analysis for Protocols Rm 7 SEC *** ace Authentication and Authorization for = Constrained Environments WG 1600-1800 Session III Rm 3 INT 6man IPv6 Maintenance WG Rm 4 IRTF irtfopen IRTF Open Meeting Rm 8 SEC tls Transport Layer Security WG WEDNESDAY, November 10, 2021 1200-1400 Session I Rm 2 ART jsonpath JSON Path WG Rm 3 INT madinas MAC Address Device Identification for = Network and Application Services WG Rm 5 RTG detnet Deterministic Networking WG Rm 7 SEC openpgp Open Specification for Pretty Good = Privacy WG Rm 8 TSV quic QUIC WG 1430-1530 Session II Rm 4 RTG babel Babel routing protocol WG Rm 6 RTG *** roll Routing Over Low power and Lossy = networks WG Rm 7 SEC *** cose CBOR Object Signing and Encryption WG Rm 8 TSV tsvarea Transport Area Open Meeting 1600-1800 Session III Rm 1 ART wpack Web Packaging WG Rm 3 OPS anima Autonomic Networking Integrated Model = and Approach WG THURSDAY, November 11, 2021 1200-1400 Session I Rm 3 IRTF cfrg Crypto Forum Rm 4 IRTF coinrg Computing in the Network Research Group Rm 6 SEC gnap Grant Negotiation and Authorization = Protocol WG 1430-1530 Session II Rm 1 ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Rm 3 INT *** drip Drone Remote ID Protocol WG Rm 4 IRTF pearg Privacy Enhancements and Assessments = Research Group Rm 6 OPS v6ops IPv6 Operations WG Rm 7 RTG bier Bit Indexed Explicit Replication WG Rm 8 SEC acme Automated Certificate Management = Environment WG 1600-1800 Session III Rm 1 IRTF panrg Path Aware Networking RG Rm 6 SEC saag Security Area Open Meeting FRIDAY, November 12, 2021 1200-1400 Session I Rm 2 ART httpapi Building Blocks for HTTP APIs WG Rm 4 OPS v6ops IPv6 Operations WG - Joint with 6MAN Rm 6 SEC dance DANE Authentication for Network Clients = Everywhere WG Rm 7 SEC *** teep Trusted Execution Environment = Provisioning WG 1430-1530 Session II Rm 1 ART *** asdf A Semantic Definition Format for Data = and Interactions of Things WG Rm 5 RTG rtgarea Routing Area Open Meeting Rm 6 SEC *** lake Lightweight Authenticated Key Exchange = WG Rm 7 SEC *** rats Remote ATtestation ProcedureS WG Rm 8 TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1600-1700 Session III Rm 2 ART uta Using TLS in Applications WG Rm 3 INT dnssd Extensions for Scalable DNS Service = Discovery WG Rm 4 OPS *** iotops IOT Operations WG Rm 7 TSV tsvwg Transport Area Working Group WG mediaman From nobody Sat Oct 16 15:57:38 2021 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 15C673A0BD9 for ; Sat, 16 Oct 2021 15:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 rzCRwniPV3o4 for ; Sat, 16 Oct 2021 15:57:31 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36EC13A0BD5 for ; Sat, 16 Oct 2021 15:57:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 3745D18294 for ; Sat, 16 Oct 2021 18:57:54 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QATvKEN9iKyu for ; Sat, 16 Oct 2021 18:57:53 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id ADF5318290 for ; Sat, 16 Oct 2021 18:57:53 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1CB47AC for ; Sat, 16 Oct 2021 18:57:27 -0400 (EDT) From: Michael Richardson To: "core\@ietf.org WG \(core\@ietf.org\)" In-Reply-To: <290101ab-0022-0ed7-424e-dc5d6c73b401@ri.se> References: <290101ab-0022-0ed7-424e-dc5d6c73b401@ri.se> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [core] CoRE rechartering: proposed text X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 16 Oct 2021 22:57:36 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I commented on the pull request > https://github.com/core-wg/core-wg.github.io/pull/1 In summary, I think that we have done a poor job at all of the DTLS things, and we should have done more work with the TLS WG on this. That might mean that the IESG needs, when removing this from our charter, inserting it into the TLS WG charter. for instance: > * efficiency of DTLS as the basis for the communication security in CoAP On the GroupCom security side, unless the work is about to be approved by t= he IESG, then I think it should get another WG. Alas, "short-lived WGs" can take years to spin up, so I guess it will stay here. I suggest that the WG may wish to allocate alternating virtual interims to this in order to establish a cadence and get the work finished. Given the virtual interim cadence, I would like to discourage the WG from holding meetings during the plenary week. I see that senML document is at the IESG. I think that if there is more work to do on SenML that it be done elsewhere. > * optimization-oriented profiling of the EDHOC protocol to establish secu= rity material for OSCORE Why can't LAKE do this? > * with other IETF WGs, particularly of the constrained node networks > cluster (6Lo, 6TiSCH, LWIG, ROLL, ACE, CBOR, COSE, IOTOPS, LAKE, SUIT, > ASDF), okay, but really are even doing anything explicit? Can we even depend upon people being in all these groups given the conflict= s? That's partly what IOTOPS is *for* > * continue and complete its work on the CoRE Resource Directory Since we say that we want to be DNS-SD interoperable, I wonder if, at this point, the work should be transferred to DNS-SD. I have seen no evidence th= at we've consulted with DNS-SD. Maybe I missed that part. I think that any WG that tries to focus on more than three items will find that really, it will focus is on zero items. yang-cbor situation is what h= appens. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmFrWNYACgkQgItw+93Q 3WUhbAgAkL7EpRnBGX3KX/0vwBwTPo/YhPC4mF+UKqHTYiYlw2lg/OL8WHY1yn1P GuO3fnlPmCYh7OC9G6Nj3h8F9bgTc3oou9H3sJlng2362wIZF74XtvnMrtxbh7Rm szVIL/ha2TfVSFX8Zh2pmGE1RRnwSm8T/i8mYukQS1FVvito8s6X0W0eNsoBPNQy I4zdeLiTNzcfU0NWGIiORAMrhormvJzuQlT0JIpYOMZ5l0HHdPvGsHQXKbuAM6J7 en8pwG5q5z+QGnCjeWE9OWNp/LArQ1LBILvprYPE1jonSh4eXaq9tEpF/qkIKCFJ BAUxN23ce570Cthou1r97w0p2SY3OA== =QsrG -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Oct 16 16:16:20 2021 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 14EF03A0C6F for ; Sat, 16 Oct 2021 16:16:18 -0700 (PDT) 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, SPF_HELO_NONE=0.001, 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 2K7n64FkPwsN for ; Sat, 16 Oct 2021 16:16:12 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABB903A0C7C for ; Sat, 16 Oct 2021 16:16:11 -0700 (PDT) Received: from smtpclient.apple (p5089a8ac.dip0.t-ipconnect.de [80.137.168.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4HWzXP4PvXz2xJB; Sun, 17 Oct 2021 01:16:05 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Carsten Bormann In-Reply-To: <24137.1634425047@localhost> Date: Sun, 17 Oct 2021 01:16:05 +0200 Cc: "core@ietf.org WG (core@ietf.org)" Content-Transfer-Encoding: quoted-printable Message-Id: <17AE33BD-E8EA-4114-9D87-EB5A25A50D47@tzi.org> References: <290101ab-0022-0ed7-424e-dc5d6c73b401@ri.se> <24137.1634425047@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [core] CoRE rechartering: proposed text X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 16 Oct 2021 23:16:18 -0000 Hi Michael, I commented on the individual proposals in the GitHub repo, but I=E2=80=99= m really surprised at how bad most of them would be for getting any = useful work done. Whether some work should be in a specific WG does not depend on some = abstract academic concept of how the world is structured, but on having = the people assembled who can do good work. E.g., I=E2=80=99m having a = hard time believing that any useful work on using CoAP with DTLS would = happen in the TLS WG; the people there have quite different priorities. = SenML may not be useful to you, but it is out there in actual use and we = have done and are doing occasional maintenance (RFC 8798, = draft-ietf-core-senml-data-ct); no other WG is going to do that properly = (even though, yes, it may be weird to have a WG that does both a = protocol and a couple of data formats that go with that protocol; er, = maybe not so unusual). Gr=C3=BC=C3=9Fe, Carsten From nobody Sat Oct 16 17:14:57 2021 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 0FAC83A0EEB for ; Sat, 16 Oct 2021 17:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 sEifz61TkwIl for ; Sat, 16 Oct 2021 17:14:49 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CF1D3A0EEC for ; Sat, 16 Oct 2021 17:14:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 551B41829B; Sat, 16 Oct 2021 20:15:14 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3w6FFXuSBnKk; Sat, 16 Oct 2021 20:15:12 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 6C3D418050; Sat, 16 Oct 2021 20:15:12 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9E7B11C6; Sat, 16 Oct 2021 20:14:45 -0400 (EDT) From: Michael Richardson To: Carsten Bormann , "core\@ietf.org WG \(core\@ietf.org\)" In-Reply-To: <17AE33BD-E8EA-4114-9D87-EB5A25A50D47@tzi.org> References: <290101ab-0022-0ed7-424e-dc5d6c73b401@ri.se> <24137.1634425047@localhost> <17AE33BD-E8EA-4114-9D87-EB5A25A50D47@tzi.org> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [core] CoRE rechartering: proposed text X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 17 Oct 2021 00:14:54 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > I commented on the individual proposals in the GitHub repo, but I=E2= =80=99m > really surprised at how bad most of them would be for getting any > useful work done. There is a lot of useful work in CORE's charter which is not getting done. > Whether some work should be in a specific WG does not depend on some > abstract academic concept of how the world is structured, but on havi= ng > the people assembled who can do good work. E.g., I=E2=80=99m having = a hard > time believing that any useful work on using CoAP with DTLS would > happen in the TLS WG; I probably have even more wounds on this than you. But, we won't get it done here. Let's not say we are going to try. > the people there have quite different priorities. > SenML may not be useful to you, but it is out there in actual use and > we have done and are doing occasional maintenance (RFC 8798, It's because I think it's useful that I think it deserves its own place. When a WG has so many focuses it has no focuses. I point to OPSAWG. I think that we all agree that the existing charter would never get approve= d today. That's why rechartering is scary. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmFravUACgkQgItw+93Q 3WWZzAf8CWCWQ+/BOxPj7unXBEY6Jp2PuxANgEVeMYv73poHdMLrF0IQbNgIZdaG naN9LFuAA5UVclPgf45vPR78mCOEPTmOepMFEESQ+i6I5CokCcl9N6NUjvShOBOw BXmIOEpwN1LTo5vGuE4IMhweggEaQkALZMh6N+Rdseg9/bhIk5rhbiHjQszb32X/ 8WZrbrrEWMYhURs3ITSgVaA7LluDqfMp5kCHPyxiJ3MF74kszmYXysSdWMrqx+RG mZbhcTZ/knKZRzIKNRQuzo020sfP9XQ0+DuZlhL92drQ0ZuPYYO0V+tk8nttXhB/ W+v94IRKsEr+vJcllizrYAcHxvwe6Q== =TkIN -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Oct 16 22:09:44 2021 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 236153A0860 for ; Sat, 16 Oct 2021 22:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 5ky3YNPGDDsN for ; Sat, 16 Oct 2021 22:09:36 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E08B3A085F for ; Sat, 16 Oct 2021 22:09:34 -0700 (PDT) Received: from smtpclient.apple (p5089a8ac.dip0.t-ipconnect.de [80.137.168.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4HX7NC0FqDz2xHt; Sun, 17 Oct 2021 07:09:31 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Carsten Bormann In-Reply-To: <13516.1634429685@localhost> Date: Sun, 17 Oct 2021 07:09:30 +0200 Cc: "core@ietf.org WG (core@ietf.org)" Content-Transfer-Encoding: quoted-printable Message-Id: <276C40A2-B053-43B4-A173-7F76EDA318B1@tzi.org> References: <290101ab-0022-0ed7-424e-dc5d6c73b401@ri.se> <24137.1634425047@localhost> <17AE33BD-E8EA-4114-9D87-EB5A25A50D47@tzi.org> <13516.1634429685@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [core] CoRE rechartering: proposed text X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 17 Oct 2021 05:09:42 -0000 On 17. Oct 2021, at 02:14, Michael Richardson = wrote: >=20 >=20 > Carsten Bormann wrote: >> I commented on the individual proposals in the GitHub repo, but I=E2=80= =99m >> really surprised at how bad most of them would be for getting any >> useful work done. >=20 > There is a lot of useful work in CORE's charter which is not getting = done. Making it harder to do that work is not going to help with this. I understand that the progress of CORECONF is frustrating. But that is no reason to shut down other work that is proceeding at a = reasonable pace. It=E2=80=99s not like the OSCORE people will suddenly put time into the = latest YANG problem if they can=E2=80=99t work on group communication = any more. >> Whether some work should be in a specific WG does not depend on some >> abstract academic concept of how the world is structured, but on = having >> the people assembled who can do good work. E.g., I=E2=80=99m having = a hard >> time believing that any useful work on using CoAP with DTLS would >> happen in the TLS WG; >=20 > I probably have even more wounds on this than you. > But, we won't get it done here. Let's not say we are going to try. A charter is meant to provide a frame for the WG to work in. If nobody wants to move this forward, it won=E2=80=99t happen if we move = it to a WG that isn=E2=80=99t interested. (I don=E2=80=99t have any particular wounds with the TLS WG because I = wouldn=E2=80=99t even try to do work there that is related to CoRE. We did manage to pull off a DICE WG in 2013 to get RFC 7925; but that = was a non-trivial effort; not sure we have anything at that level on our = plates right now.) >> the people there have quite different priorities. >> SenML may not be useful to you, but it is out there in actual use and >> we have done and are doing occasional maintenance (RFC 8798, >=20 > It's because I think it's useful that I think it deserves its own = place. That wouldn=E2=80=99t make a lot of sense, because the maintenance = needed for SenML is really limited. (The current wording about =E2=80=9Ccompleting=E2=80=9D SenML may give = the wrong impression.) > When a WG has so many focuses it has no focuses. I point to OPSAWG. I think we have a laser-sharp focus compared to OPSAWG=E2=80=A6 (I also think we have a relatively well-working WG going on, in = particular since I stopped being involved in its management :-) > I think that we all agree that the existing charter would never get = approved today. > That's why rechartering is scary. If that is the diagnostic, we probably shouldn=E2=80=99t spend time = trying to do it. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Oct 18 06:15:07 2021 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 440183A138B for ; Mon, 18 Oct 2021 06:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 zfTg9EBCpbZj for ; Mon, 18 Oct 2021 06:15:01 -0700 (PDT) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 CB91B3A1389 for ; Mon, 18 Oct 2021 06:15:00 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id t9so66821863lfd.1 for ; Mon, 18 Oct 2021 06:15:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=guDUA/e03InJ5zVz9Yz3o7bmR7RgADloZvIpfCrxL0U=; b=ZesB2b7sLG5rK7jKrx3oGVBdyd3e5mEDJyysQiLMW2+rjIaFPkW06d4fBKUhCvLsAq PQioQ7+5IFwKeO7gNg/yaRZiMV/SqgDUMGvgiC3K8j2G81WKSVfqjuq5KzVq2VuKEXbq vkNssZXwn71vAaK7z/SefD3yzFDjPb841JLNm553oy1Iz5HU0np/bZEDShnVALv+5RRc eMdMXAuGXwx12hNwZ6gRMgNWGPfL+anVpRrUo3/oRopJJxmO2Cx4FxfE83lzaRKfxlZJ 09UN/HOtxlu7j1cHBF4zkBq7wEsUd5zUcYcmFXRpNcw9bLc4KTICGRTd2LQsk4oXkZaQ woew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=guDUA/e03InJ5zVz9Yz3o7bmR7RgADloZvIpfCrxL0U=; b=NNfYI/8D5vVMoVCX7agQMVmaaeBTRLRugV+2xsE+wC5QlEWNE1fTcXcj5XODkwnWRX cKdiVrur1x2b7xpWKTAOHmGG1/vPuPS7hIOVygcVgf8na4TyV8r4Hs8RKD7EpGhXK2ss XYUOzBvNMwSwqBnqSzrVZ2Y0oyGkxAC+fN/HskD5H1jHuytf6BbL7cr14kPdr2uGVA+t QcnXKPtZiQRSR9jAjg8zWqoz7hATnZJ55RWNA04hi5RdMWzTPWJem2bXpxWu+G7XtE4p lmTC2fazltbbFr3PSeOLy2B2ACRBxY4BtOV4YBaZ4o7ZqmNAGn8nceNzJIl6x9Nkpnjs tPZg== X-Gm-Message-State: AOAM533fY2HnymPWOLLwV951h2+Kn78l4JHvVMKyHftwuepb9VyTLynY dRWYrn7uPVBll/PLAuxl5s9w5aRTdvN4QF2MYaj/PWEaRxg= X-Google-Smtp-Source: ABdhPJywGkDI6OeM63yXjwHc3fhCLoFbWopIta/Dy9n6Y8oV4R+eEO7Ba+ClMWUncUXsCh/T3q3GxUltNaAP+HBLx8k= X-Received: by 2002:a05:6512:2025:: with SMTP id s5mr27912245lfs.30.1634562895332; Mon, 18 Oct 2021 06:14:55 -0700 (PDT) MIME-Version: 1.0 From: Thomas Fossati Date: Mon, 18 Oct 2021 14:14:44 +0100 Message-ID: To: "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [core] time to start the deprecation of CCM_8? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 18 Oct 2021 13:15:06 -0000 hi, As part of the (D)TLS 1.3 profile for IoT [1], Hannes and I would like to start the deprecation of CCM_8 when used in DTLS. The reason is its integrity bounds (i.e., the limit on acceptable forgeries) are abysmally low (see the full story [2], and a handy simplification [3]). This, in turn, allows a trivial DoS against any DTLS session that uses CCM_8 ciphersuites. (See also RFC-to-be 9147 [4] for more context.) Now things get extra interesting for CoRE because TLS_{ECDHE_ECDSA,PSK}_WITH_AES_128_CCM_8 happen to be the only two mandatory-to-implement ciphersuites in CoAP -- an advice we echoed in RFC7925 as well. Hence, we have no stand-by primitive/mode we can fall back to, which also means we cannot just deprecate, we also need to promote a new cipher. Not a great story, but here we are. It looks like we can no longer postpone an action, but at the same time we need to understand as much as possible what the real world implications are before we possibly upend an industry. To be clear, the gist of our deprecation will look like: * DTLS SHOULD NOT use CCM_8 * DTLS SHOULD use XYZ instead And our questions to you CoRE people are: 1. Are you OK with the above? 2. Any preference for XYZ? Should we recommend CCM, or move to GCM? (It looks like the latter would be more inline with stock TLS and should therefore improve interoperability. OTOH, the former would be easier to upgrade to in very constrained implementations.) 3. Should we also define a stand-by primitive/mode, e.g. CHACHA-POLY? 4. Should [1] update Section 9.1 of RFC7252 in the process? Thanks in advance for your consideration, Thomas & Hannes [1] https://datatracker.ietf.org/doc/draft-ietf-uta-tls13-iot-profile/ [2] https://link.springer.com/chapter/10.1007%2F3-540-36492-7_7 [3] https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38c.pdf#page=22 [4] https://www.rfc-editor.org/authors/rfc9147.html#appendix-B.3 From nobody Mon Oct 18 08:29:38 2021 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 B8BDF3A1560 for ; Mon, 18 Oct 2021 08:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=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 sqHfE1pyGxe6 for ; Mon, 18 Oct 2021 08:29:19 -0700 (PDT) Received: from 10.mo552.mail-out.ovh.net (10.mo552.mail-out.ovh.net [87.98.187.244]) (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 05F983A085C for ; Mon, 18 Oct 2021 08:29:17 -0700 (PDT) Received: from mxplan6.mail.ovh.net (unknown [10.109.156.216]) by mo552.mail-out.ovh.net (Postfix) with ESMTPS id DEA35221E2 for ; Mon, 18 Oct 2021 15:29:14 +0000 (UTC) Received: from simonbernard.eu (37.59.142.103) by DAG3EX2.mxp6.local (172.16.2.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Mon, 18 Oct 2021 17:29:14 +0200 Authentication-Results: garm.ovh; auth=pass (GARM-103G00596efdf10-df14-4426-aa1e-b14ed6abc4dc, 42AE60EA6DCE9B8B61B83842AC93BC34C9663A3A) smtp.auth=contact@simonbernard.eu X-OVh-ClientIp: 91.174.163.99 To: References: From: Simon Bernard Message-ID: <449fea3e-2629-a4f6-29a6-eed51b9e7f09@simonbernard.eu> Date: Mon, 18 Oct 2021 17:29:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: [37.59.142.103] X-ClientProxiedBy: DAG9EX1.mxp6.local (172.16.2.81) To DAG3EX2.mxp6.local (172.16.2.22) X-Ovh-Tracer-GUID: d4c3fbfd-7257-4963-b01d-71e0b40409ce X-Ovh-Tracer-Id: 10577266677638182935 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -4 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvtddrvddvtddgkeeiucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucgfrhhlucfvnfffucdlqdegmdenucfjughrpefuvfhfhffkffgfgggjtgfgihesthekredttdefjeenucfhrhhomhepufhimhhonhcuuegvrhhnrghrugcuoegtohhnthgrtghtsehsihhmohhnsggvrhhnrghrugdrvghuqeenucggtffrrghtthgvrhhnpeeludduudeuffegfeeluddvtdetueehiefghfeuhfeiteduhedvfeduvdeufeekjeenucffohhmrghinhepihgvthhfrdhorhhgpdhsphhrihhnghgvrhdrtghomhdpnhhishhtrdhgohhvpdhrfhgtqdgvughithhorhdrohhrghenucfkpheptddrtddrtddrtddpfeejrdehledrudegvddruddtfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdqohhuthdphhgvlhhopehmgihplhgrnheirdhmrghilhdrohhvhhdrnhgvthdpihhnvghtpedtrddtrddtrddtpdhmrghilhhfrhhomheptghonhhtrggtthesshhimhhonhgsvghrnhgrrhgurdgvuhdprhgtphhtthhopegtohhrvgesihgvthhfrdhorhhg Archived-At: Subject: Re: [core] time to start the deprecation of CCM_8? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 18 Oct 2021 15:29:27 -0000 Hi,  I guess Hannes better knows that than me, but this will also affects LWM2M v1.0 / v1.1 / v1.2 because AFAIK TLS_{ECDHE_ECDSA,PSK}_WITH_AES_128_CCM_8 is the only one cipher recommended and mandatory at client and server side. > Hannes and I would like > to start the deprecation of CCM_8 when used in DTLS Just to be sure, does it concerns only DTLS or TLS too ? The profile is about (D)TLS 1.3 but I understand this is a "general" depreciation, so this affects (D)TLS 1.2 too, or ? Thx Simon Le 18/10/2021 à 15:14, Thomas Fossati a écrit : > hi, > > As part of the (D)TLS 1.3 profile for IoT [1], Hannes and I would like > to start the deprecation of CCM_8 when used in DTLS. The reason is its > integrity bounds (i.e., the limit on acceptable forgeries) are abysmally > low (see the full story [2], and a handy simplification [3]). This, in > turn, allows a trivial DoS against any DTLS session that uses CCM_8 > ciphersuites. (See also RFC-to-be 9147 [4] for more context.) > > Now things get extra interesting for CoRE because > TLS_{ECDHE_ECDSA,PSK}_WITH_AES_128_CCM_8 happen to be the only two > mandatory-to-implement ciphersuites in CoAP -- an advice we echoed in > RFC7925 as well. Hence, we have no stand-by primitive/mode we can fall > back to, which also means we cannot just deprecate, we also need to > promote a new cipher. Not a great story, but here we are. > > It looks like we can no longer postpone an action, but at the same time > we need to understand as much as possible what the real world > implications are before we possibly upend an industry. > > To be clear, the gist of our deprecation will look like: > > * DTLS SHOULD NOT use CCM_8 > * DTLS SHOULD use XYZ instead > > And our questions to you CoRE people are: > > 1. Are you OK with the above? > 2. Any preference for XYZ? Should we recommend CCM, or move to GCM? > (It looks like the latter would be more inline with stock TLS and > should therefore improve interoperability. OTOH, the former would > be easier to upgrade to in very constrained implementations.) > 3. Should we also define a stand-by primitive/mode, e.g. CHACHA-POLY? > 4. Should [1] update Section 9.1 of RFC7252 in the process? > > Thanks in advance for your consideration, > Thomas & Hannes > > [1] https://datatracker.ietf.org/doc/draft-ietf-uta-tls13-iot-profile/ > [2] https://link.springer.com/chapter/10.1007%2F3-540-36492-7_7 > [3] https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38c.pdf#page=22 > [4] https://www.rfc-editor.org/authors/rfc9147.html#appendix-B.3 > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Mon Oct 18 08:48:57 2021 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 8AE083A154F for ; Mon, 18 Oct 2021 08:44:16 -0700 (PDT) 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, SPF_HELO_NONE=0.001, 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 sAquTMvoG0D4 for ; Mon, 18 Oct 2021 08:44:12 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 976773A1569 for ; Mon, 18 Oct 2021 08:44:12 -0700 (PDT) Received: from [192.168.217.118] (p5089a8ac.dip0.t-ipconnect.de [80.137.168.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4HY1Q15tyKz2xKp; Mon, 18 Oct 2021 17:44:09 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: Date: Mon, 18 Oct 2021 17:44:09 +0200 Cc: "core@ietf.org WG" X-Mao-Original-Outgoing-Id: 656264649.3406709-4f4c7d0136a1cbfb6c54ac8734678e42 Content-Transfer-Encoding: quoted-printable Message-Id: <081C80A8-5317-4DB1-BBCB-21654AE6F444@tzi.org> References: To: Thomas Fossati X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] time to start the deprecation of CCM_8? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 18 Oct 2021 15:44:17 -0000 I believe we have an ongoing discussion on how bad the situation really = is. What is clear is that CCM_8 is not useful without a regular rekeying = regime. We now have numbers for that; the results hinge on what probability of = damage you can accept. Appendix B.3 of 9147-to-be qualifies itself with "If the goal is to = preserve the same margins as other cipher suites,=E2=80=9D - well, if = you chose CCM_8, clearly that was not the goal. So I think we need a more detailed discussion of this. (I do agree with 9147-to-be=E2=80=99s conclusion that "This analysis = supports the view that TLS_AES_128_CCM_8_SHA256 is not suitable for = general use.=E2=80=9D =E2=80=94 I wouldn=E2=80=99t run my SSH sessions = over CCM_8.) > * DTLS SHOULD NOT use CCM_8 > * DTLS SHOULD use XYZ instead I think XYZ should be based on Keccak, but of course people will want to = make use of their AES hardware=E2=80=A6 > GCM I still don=E2=80=99t believe GCM=E2=80=99s brittleness is appropriate = for most IoT applications. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Oct 18 11:55:21 2021 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 D39923A195A for ; Mon, 18 Oct 2021 11:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, 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=gmx.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 1jaIAeSzgT3G for ; Mon, 18 Oct 2021 11:55:13 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 0DF1D3A1959 for ; Mon, 18 Oct 2021 11:55:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1634583310; bh=t25v6bIWBg/KUNyCqE8ZRcimuXwaNdAyZfPGsrMpRKc=; h=X-UI-Sender-Class:Subject:To:References:From:Cc:Date:In-Reply-To; b=Ssx2LRO2UlWjmc1Z1L/83ZdPBCDThp+RL990BiloznqQDxo+3mGYutlA+sxQhIGcy 1b30Ct5TSg/saiFYNPdPEhOevha8C0/hYppCWmiVx8Jkjknk5NqXjDsOVJV6DhAdcu By2ZymmpeHuImXnIKs3VB1VG6/2eO7hAMtOQuGx4= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.10] ([5.146.193.130]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Mt79P-1mrTCp2hwX-00tPsJ; Mon, 18 Oct 2021 20:55:10 +0200 To: core@ietf.org References: From: Achim Kraus Message-ID: Date: Mon, 18 Oct 2021 20:55:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:PLGWjn7N6HMISi4bNyfF7yURL4RxOqZYrrJs2k475elDXumASHb YZJsUiNofYRjh4Mpa6y08e17jW+qIbD0JFh2xaFGRwvX3nK+tfl76aYBJQRLBQIB5ZlUjB8 qO0LTtqtptTe60yAAlzro8fbj4j08TTO5c42Gy1L8KEA4plNZSPDPH+JMQU9eOwzPP0Ba82 PhvCYHw9mbLr9+SRGv9BA== X-UI-Out-Filterresults: notjunk:1;V03:K0:XxSvs6TNdoQ=:cTZ2Qonb5Gg7Ato2CN0Odz qccWUWFQM2yS32BGljaE+zHBTXCzr8SPbXsGx0+0A98lTiBSWNyJtCdd2GFcKqdb7+EtH1V4z OX+0/9CzIeM8twgYlUODFzsVcRJhFK3XlY1SoE2gQ1LcBp3UM9qqvP/zBf7oIOnXEtGXR36XF uz7+mvXFI03jQAVSmGwZwshpqaZA2ZQtF7lsDdKtYXBpRvAMAsSck07/xksKr7L/wQg7tV0xz QERTyfc/NPu2C+sR4v6MEyuQUcO+w+/tlw4AU8tt9rLDHW4QRcfVX1VoLy0gH2plVew++KTzq DyDYt6ptl5CsYHoVRjZ+i3nDi2Ewyu1TpI4TCHwuymqnL6ux4BxfE+D6TV2A5IYXS0Iy4ZYcW Kq74QzEJ+sBVrdDPHuYbajRKJUyi6puGcGnEjfq9QeofD2jaFkUCdWE19WmZf8Zwf7PvaEzhD Z00+WftFUygYhgL6h5WOLoAZdJnASGz+fz9ecKG7GkAJ2LqXG1NIBtGLTMsfN06nIL4HH36eF Ttkjq8uwqOCKSt/SVvagpugE6OVXmWngZQwkj2tGmgbM0PudH2fTk65il3IU6pY9Y/fZydWfW LpmnJ6Hq0nmCvji6XjAIkUkSGSWdJ88FIby8m6Ru46iB3t9DgCGPPWCXIfHi43W2r4UbCjVzu w6GLaw0bgH9DjDQh86rE59qMd0Thjzsug9xBRb8PifCudYCbBvV1iAfbKOA55Zok7QrQbO/kx 0tgjTh0i1V2EfzHc4KHVJqADaDDyEqlPuZRc7+L4SuYqB2Md9unSoy54EZVcp1c4+wluA+NRx cqraVjttVbSBg0fjhrnovgsamJfqOEbeImxB/LypB2YvFeGOyHxHw9BZljwW31L/Zjpt5kj/+ Y6g8NetLTPxl1uzCmDTbAlzu5zz0q4q56NUTRQ6IuAR64HnIx94acyGjSjMPQZuWL0PbUdcmN vM8EU4FqZ9m3iJQV+fZlk2WJ0kKDSTdMFxUjN5D5AFvuP3G5KqsRz+CUb2U67ChvnakcjRxoy aj9m9Q/EwFxqnNpV5YC02l87qhyQJsGjUdVDqE2SADSRS/tXuZQ5U0ZQe3ymO9k0iNKtj+HTW Xy0bucdRb81Vjg= Archived-At: Subject: Re: [core] time to start the deprecation of CCM_8? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 18 Oct 2021 18:55:19 -0000 Hi Thomas, Hi list a general recommendation of a cipher suite with stronger MAC for future deployments may be considered as not too bad. I would appreciate to have then also rules/best practice advice for using CCM8, for the cases, where someone has reasons to do so. The literature seems for to be a mix of a lot of stuff and for me it raises more questions than it gives answers. E.g. does the findings for GCM really fit to CCM as well? What are the assumed attacks? "Brute-force" to bypass the MAC? Or? In combination with CoAP the answers are more unclear: - considering IND-CPA: does the usage of varying MIDs and Tokens make such attacks harder? - considering INT-CTXT: does parsing the cipher-text as coap-message not provide additional security and makes brute-force less probable? For me that leaves mainly "bit-flip" attacks (e.g. flip a CoAP Type bit to 1 results in RST instead of ACK, or a bit in the CoAP Code). But attacking these bits is also bound to a short time-window (about 4 minutes), which makes such attacks again less probable (leaving notifications unconsidered= ). So: > * DTLS SHOULD NOT use CCM_8 > 1. Are you OK with the above? If the rules for using CCM8 are clear. e.g. append "without reason. If used,
SHOULD be applied" > 2. Any preference for XYZ? For me CCM is the clear favorite. At least, if it's mainly about the MAC. That enables the most implementation to follow the mitigation and not continue to use CCM8 just because alternatives are not that easy to implement (e.g. hw support). > 3. Should we also define a stand-by primitive/mode, e.g. CHACHA-POLY? Not as mandatory, at least not mandatory for clients. > 4. Should [1] update Section 9.1 of RFC7252 in the process? Depends on the update. Recommend CCM generally instead of CCM8, OK. FMPOV it would help much more, and will get more acceptance, if the considerations about CCM8 weakness are clear, and applied to CoAP specific cases. (I'm not sure, if switching to CCM is just consider to be less critical, than try to find out, if CCM8 used with CoAP is really weak. If so, that should be made clear and leave the usage of CCM8 just as "unknown" and not as "weak".) best regards Achim Kraus Am 18.10.21 um 15:14 schrieb Thomas Fossati: > hi, > > As part of the (D)TLS 1.3 profile for IoT [1], Hannes and I would like > to start the deprecation of CCM_8 when used in DTLS. The reason is its > integrity bounds (i.e., the limit on acceptable forgeries) are abysmally > low (see the full story [2], and a handy simplification [3]). This, in > turn, allows a trivial DoS against any DTLS session that uses CCM_8 > ciphersuites. (See also RFC-to-be 9147 [4] for more context.) > > Now things get extra interesting for CoRE because > TLS_{ECDHE_ECDSA,PSK}_WITH_AES_128_CCM_8 happen to be the only two > mandatory-to-implement ciphersuites in CoAP -- an advice we echoed in > RFC7925 as well. Hence, we have no stand-by primitive/mode we can fall > back to, which also means we cannot just deprecate, we also need to > promote a new cipher. Not a great story, but here we are. > > It looks like we can no longer postpone an action, but at the same time > we need to understand as much as possible what the real world > implications are before we possibly upend an industry. > > To be clear, the gist of our deprecation will look like: > > * DTLS SHOULD NOT use CCM_8 > * DTLS SHOULD use XYZ instead > > And our questions to you CoRE people are: > > 1. Are you OK with the above? > 2. Any preference for XYZ? Should we recommend CCM, or move to GCM? > (It looks like the latter would be more inline with stock TLS and > should therefore improve interoperability. OTOH, the former would > be easier to upgrade to in very constrained implementations.) > 3. Should we also define a stand-by primitive/mode, e.g. CHACHA-POLY? > 4. Should [1] update Section 9.1 of RFC7252 in the process? > > Thanks in advance for your consideration, > Thomas & Hannes > > [1] https://datatracker.ietf.org/doc/draft-ietf-uta-tls13-iot-profile/ > [2] https://link.springer.com/chapter/10.1007%2F3-540-36492-7_7 > [3] https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication80= 0-38c.pdf#page=3D22 > [4] https://www.rfc-editor.org/authors/rfc9147.html#appendix-B.3 > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From nobody Tue Oct 19 00:34:47 2021 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 B82663A07F7 for ; Tue, 19 Oct 2021 00:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 0j-FrQo0gIWg for ; Tue, 19 Oct 2021 00:34:32 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 3AA8C3A081F for ; Tue, 19 Oct 2021 00:34:32 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id 204so4406097ljf.9 for ; Tue, 19 Oct 2021 00:34:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GtjvJbwUvhjgNnG8lds9AX6ChNONdKYZeasi7laULFs=; b=W435rNM99ehTRT2wRuLdWt0vSaDgmVrvg/Xt2Qx1Ja8SLfXh2u7gwk4apagcmTKHic SpGJP8i/iQvIzPICL1CKxnH9mIfRGIK11XjDv0MAYkDD35Db8mdyyEz9h52kVG0ww/1z 5ejMAMppypCs/N1L+TkRyRUAfKffRjZpRrCIgqdPhWJNHR5R5RavktbasPFf7c7sOSwT Jl8HNMa+Iwaf4AGp2rRAjUonfZRFwdB7ho99OopMQvlbVfZ3wfMhagSEQt89trFpdIdg vw6t74dV5bQwYI/ZQe4sEFLdGtxdYPznXqi4+auGn4NUT+TcqDkEseDInLdj6xDXBUTr AFVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GtjvJbwUvhjgNnG8lds9AX6ChNONdKYZeasi7laULFs=; b=Ny3pIstl+z8YJ2L8YCh8+YiqdTNJnsoIefGv0az/i3UGO2QGVgfo9QYQ8A8tkPyEsb wJmrBPlrY9ewblO6OYLARRaeD0wabSAMtS7hwSDACE0knQwx7i2/AyTMOfGrDDEbgs2y BoLtHO0nITyktm7RjNii5Cqgu+JmXF4lgujIWnIoJSuNUpS86lswbyLJF9JsKm8LxkOI hRo1WKYjzH2o7pboQFiN9C+efyQYga/lCZVw8i+FqOqqNH6+EY0X/vSd/M57GLOPKX1x lf7406XTmG8+LpvZS4OygJZV+sYYNxV3a2sTOGIhM3BppEi4g4tOl8EKVMzDQ6uUisyP laWQ== X-Gm-Message-State: AOAM532FMhTARz8tqryaZ6Fh9ZtgwPFibc15SVarLvBEz6MSriDfOoEK S5OaVHx2BJQx8H1CFLO91IzsPc+543DSNTI6VvA= X-Google-Smtp-Source: ABdhPJx+G4xyADtvRgvpOg9vEXoysRkrqxmHFCbbNNrO+OtQknRGhjsL3Q3YrvK+ck2AV5y/Ljj105qqdA16QmxTAvI= X-Received: by 2002:a05:651c:179a:: with SMTP id bn26mr5157918ljb.528.1634628870160; Tue, 19 Oct 2021 00:34:30 -0700 (PDT) MIME-Version: 1.0 References: <449fea3e-2629-a4f6-29a6-eed51b9e7f09@simonbernard.eu> In-Reply-To: <449fea3e-2629-a4f6-29a6-eed51b9e7f09@simonbernard.eu> From: Thomas Fossati Date: Tue, 19 Oct 2021 08:34:19 +0100 Message-ID: To: Simon Bernard Cc: "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [core] time to start the deprecation of CCM_8? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 19 Oct 2021 07:34:42 -0000 Hi Simon, On Mon, Oct 18, 2021 at 4:29 PM Simon Bernard wrote: > I guess Hannes better knows that than me, but this will also affects > LWM2M v1.0 / v1.1 / v1.2 because AFAIK > TLS_{ECDHE_ECDSA,PSK}_WITH_AES_128_CCM_8 is the only one cipher > recommended and mandatory at client and server side. I am not directly involved in LwM2M so I am leaving this to Hannes. > > Hannes and I would like > > to start the deprecation of CCM_8 when used in DTLS > Just to be sure, does it concerns only DTLS or TLS too ? > > The profile is about (D)TLS 1.3 but I understand this is a "general" > depreciation, so this affects (D)TLS 1.2 too, or ? Yes, it'd be version independent: it's the cipher itself that is problematic, not the way 1.2 or 1.3 use it. cheers, t From nobody Tue Oct 19 00:37:14 2021 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 33A5B3A0827 for ; Tue, 19 Oct 2021 00:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 dowZ61vCRVOA for ; Tue, 19 Oct 2021 00:35:58 -0700 (PDT) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 260993A0805 for ; Tue, 19 Oct 2021 00:35:58 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id z11so5442505lfj.4 for ; Tue, 19 Oct 2021 00:35:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=QOiLp5Z3dnhkzc+z/f4THUHP5K3PrN6pGQ+lyArnxHg=; b=aMTN4VDAcdnJTABdRsg113cZlh6ffGDgRfwDRh0dbOOg622MDR/oq1sWmDCvjWyGpf GwLQN29ypvlJy4pS5VRi+/EuhNiJzqmJVdBg5oj/DcurCDjAoidTw3RRGCOpk4/qrTAh j78y1FFHhKz3J/A6BTjxarbL+NeIkmiWSATRhmdeeNtMEjZSosmgRS8jMaHbbnDsHW3k KSPdh+9NryZymqUCewp7nfPtDXU2fTJE5sDqrts/AnLy9O9axTuPR7J2mbvK5ZcxKIJw i4fOVUAJH0ctea/TZpBPLuHyQFvpP8G7ZMLjS7iF7X1ZtZLDlOeKIN6hFNT3iENI+QU6 201w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=QOiLp5Z3dnhkzc+z/f4THUHP5K3PrN6pGQ+lyArnxHg=; b=kypWfgZlRggz9nflFusXTaAsrlE6u25JcMJZavkLna81K0RNg6cbGf1Eoy6RBY1evO 9A2bVxJNNMk9QVz78cmJEmkORjvGM+hiniYk/SMIsV+Jx5cjpxeSxobIEZI2iHz9lfR9 dFzapdcybhZkYXfZYoUN7Oq0A+ARfcY8fhiDU1e/95UVvA/+Y6x2FOHt/QcvMAT6sdEH tVPXK3/nU/jZDODSKFs2leYqs+QGaIT0i+/HZ53/Dy/U9cXL66L4uz1MdigN0RKd4Fb3 usW+yRfJTkG044Nf60ENgo/U0VMf/JlKhRubLtaYLY8S+/afP9vSzv52lZHtGxSTOP+X SupQ== X-Gm-Message-State: AOAM530Hshy6gYYTuK+C4qMc7FmlDnsmj9SGEtVQSLrPCZlfBGWw1hMR NEMIxF7Yxr6pqeTs2clIx44iIxKq6YmLjHccO8+geBOymwE= X-Google-Smtp-Source: ABdhPJxrH+jCNOcJAoYR/HZ/BevdFJr9X1HCLkquwayCLD/Mjrmv0LJq4PbuB85D+HhS8kgJAx7MEJJ7rxx2IhCnggM= X-Received: by 2002:a19:c7cb:: with SMTP id x194mr4416831lff.555.1634628956011; Tue, 19 Oct 2021 00:35:56 -0700 (PDT) MIME-Version: 1.0 References: <081C80A8-5317-4DB1-BBCB-21654AE6F444@tzi.org> In-Reply-To: <081C80A8-5317-4DB1-BBCB-21654AE6F444@tzi.org> From: Thomas Fossati Date: Tue, 19 Oct 2021 08:35:45 +0100 Message-ID: To: Carsten Bormann Cc: "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] time to start the deprecation of CCM_8? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 19 Oct 2021 07:36:06 -0000 hi Carsten, On Mon, Oct 18, 2021 at 4:44 PM Carsten Bormann wrote: > I believe we have an ongoing discussion on how bad the situation > really is. > What is clear is that CCM_8 is not useful without a regular rekeying > regime. > We now have numbers for that; the results hinge on what probability of > damage you can accept. Sure, but what we are ultimately doing is shifting the responsibility of a hard configuration choice onto the users. Complex UIs should be avoided. > Appendix B.3 of 9147-to-be qualifies itself with "If the goal is to > preserve the same margins as other cipher suites,=E2=80=9D - well, if you > chose CCM_8, clearly that was not the goal. You say "if you chose CCM_8", but the thing is that the current MTI situation doesn't give you a real choice -- the only alternative we provide is around forward secrecy. We lack a "general use MTI fallback and that, I think, hurts us. > So I think we need a more detailed discussion of this. yes! > > * DTLS SHOULD NOT use CCM_8 > > * DTLS SHOULD use XYZ instead > > I think XYZ should be based on Keccak, I think I see what you are thinking, but I'd wait for NIST's lightweight crypto outcome before making any concrete recommendation. It shouldn't take too long. > but of course people will want to make use of their AES hardware... That, but people also want to be able to interop with ${mainstream_tls_stack} without too much hassle. > > GCM > > I still don=E2=80=99t believe GCM=E2=80=99s brittleness is appropriate fo= r most IoT > applications. I reckon we are past that point. The deterministic construction in TLS 1.3 makes it very difficult to fall into the "nonce disrespecting" trap that gave us so many nice CVEs in the past. Also, similar to BCP195-bis, we can backport the construction to 1.2 via the IoT profile. cheers, t From nobody Tue Oct 19 01:39:52 2021 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 844C83A08FE for ; Tue, 19 Oct 2021 01:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 MtsBL3TA9_q7 for ; Tue, 19 Oct 2021 01:39:48 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2D493A0827 for ; Tue, 19 Oct 2021 01:39:47 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id r6so4720936ljg.6 for ; Tue, 19 Oct 2021 01:39:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YCjvV6jedZxgyUeo9Kfa4sfqt+SOLSESUN7YTCI+/ds=; b=gJVDSw17QLtv5CENFDQPg1WdKkdTgVoKHHko76Z92LbbNZ0Q8Ll27aPzQlFGz7Ku6B bNdutSMfi6pLSFVgdTgus8hiF/W+ADOrK3RcqM8mE9K9mljkdF1HUhfxa6Pn6e+eCrOF m4N161bc7ADlUSONFdQ4z7CzTH0Kf/j+A841rW0d0NeH9hqvxzOOQIhvfG4NYxyfznS5 9ALAWHTCJLYFC/OrSVWvf6f2dl8GsPAdDUa2MizNXcdCM9Feq957ttT53alQexLj5rl/ YsmqsyC9b2tBvPenm2DXoZ4pZiQ57+ho/TyiI/xgI79DwgZMSORUEEMseeHtwo3sJg+w b+UA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YCjvV6jedZxgyUeo9Kfa4sfqt+SOLSESUN7YTCI+/ds=; b=1lA0r1LwR7SgOX2eIbsXL1Mvrmt20Fg2ay+3PGqIRj19oC2DJ4wVgQmoLwObdAt3++ FAvIo9Nh3qLVYyfF3qyAjMVRSrW8YlMBgmtX1sybfteLhD8u/Rs42tDV6BvSPvyJP9Nl JG7g8zTxU8c+/0mkQ2z9R29rZjiHXuFtGpj7r953OlLVQaloUbPHlmTFVvzk3uW2c1Ut ebWyUuOgbGhLxsLZSzObqkjgvip1A8yPUQWmEJYV5UqxeBP5uk+fpjB19j9opQA3To3j N04hx0dO59uFhCGtsXp9MLw5Hb1xxK65FnuKEowwigdqT2gDfzY+wvP9SHb97kkwzPn3 tPGA== X-Gm-Message-State: AOAM531zYfXa9J3xUOzL80vfuQpCtCxplsPnrsV2NaDr904G1DbEkEnX V5QehcC7+MvXvk6wWOC1oVPK+4PneXLCipLBO0k= X-Google-Smtp-Source: ABdhPJy/3qETxOIn9E0EdqcOfsaOr/jH5dR7B+cFHBic1DpIalQQs39lEBRpno5lgi0m1fBuzYTlny7EwEGBcrf06mI= X-Received: by 2002:a2e:b88f:: with SMTP id r15mr3895394ljp.474.1634632785650; Tue, 19 Oct 2021 01:39:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Thomas Fossati Date: Tue, 19 Oct 2021 09:39:34 +0100 Message-ID: To: Achim Kraus Cc: "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [core] time to start the deprecation of CCM_8? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 19 Oct 2021 08:39:50 -0000 hi Achim, On Mon, Oct 18, 2021 at 7:55 PM Achim Kraus wrote: > a general recommendation of a cipher suite with stronger MAC for future > deployments may be considered as not too bad. I would appreciate to have > then also rules/best practice advice for using CCM8, for the cases, > where someone has reasons to do so. That's actually an interesting point. I think we need to be mindful about the risk that saying "SHOULD NOT, however if ${complicated_list_of_conditions} then MAYBE" creates confusion and ultimately insecurity. Personally, I'd rather stick to the "simple and nearly-impossible to misuse UIs" model -- i.e., the good old "boring crypto". > The literature seems for to be a mix of a lot of stuff and for me it > raises more questions than it gives answers. E.g. does the findings for > GCM really fit to CCM as well? What are the assumed attacks? > "Brute-force" to bypass the MAC? Or? > > In combination with CoAP the answers are more unclear: > > - considering IND-CPA: does the usage of varying MIDs and Tokens make > such attacks harder? > > - considering INT-CTXT: does parsing the cipher-text as coap-message not > provide additional security and makes brute-force less probable? For me > that leaves mainly "bit-flip" attacks (e.g. flip a CoAP Type bit to 1 > results in RST instead of ACK, or a bit in the CoAP Code). But attacking > these bits is also bound to a short time-window (about 4 minutes), which > makes such attacks again less probable (leaving notifications unconsidered). Yes, the literature is non trivial, especially around the amount of assumptions one has to make to come out with a number. And this, to me, is probably the best counter-argument to having a detailed list of conditions under which a cipher becomes un/usable, especially for borderline situations like CCM_8. > So: > > > * DTLS SHOULD NOT use CCM_8 > > > 1. Are you OK with the above? > > If the rules for using CCM8 are clear. e.g. append "without reason. If > used,
SHOULD be applied" > > > 2. Any preference for XYZ? > > For me CCM is the clear favorite. At least, if it's mainly about the > MAC. That enables the most implementation to follow the mitigation and > not continue to use CCM8 just because alternatives are not that easy to > implement (e.g. hw support). Noted, thanks. > > 3. Should we also define a stand-by primitive/mode, e.g. CHACHA-POLY? > > Not as mandatory, at least not mandatory for clients. I think if we want to have a stand-by we need to mark it MTI, otherwise there is no guarantee that in a "main cipher catastrophe" it can be switched on. > > 4. Should [1] update Section 9.1 of RFC7252 in the process? > > Depends on the update. Recommend CCM generally instead of CCM8, OK. Noted. > FMPOV it would help much more, and will get more acceptance, if the > considerations about CCM8 weakness are clear, and applied to CoAP > specific cases. That's super interesting stuff, but it's also a lot of non-trivial work. > (I'm not sure, if switching to CCM is just consider to be less critical, > than try to find out, if CCM8 used with CoAP is really weak. If so, that > should be made clear and leave the usage of CCM8 just as "unknown" and > not as "weak".) > > best regards > Achim Kraus cheers, thanks for the input! -- Thomas From nobody Tue Oct 19 02:08:00 2021 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 0EEA43A0922 for ; Tue, 19 Oct 2021 02:07:58 -0700 (PDT) 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, SPF_HELO_NONE=0.001, 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 EcxIWgrjC-mT for ; Tue, 19 Oct 2021 02:07:50 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB2F03A091E for ; Tue, 19 Oct 2021 02:07:49 -0700 (PDT) Received: from [192.168.217.118] (p5089a8ac.dip0.t-ipconnect.de [80.137.168.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4HYSZB6761z2xf6; Tue, 19 Oct 2021 11:07:46 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: Date: Tue, 19 Oct 2021 11:07:46 +0200 Cc: "core@ietf.org WG" X-Mao-Original-Outgoing-Id: 656327266.155176-abe57af48f00490d20529affd86bac7c Content-Transfer-Encoding: quoted-printable Message-Id: References: <081C80A8-5317-4DB1-BBCB-21654AE6F444@tzi.org> To: Thomas Fossati X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] time to start the deprecation of CCM_8? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 19 Oct 2021 09:07:58 -0000 On 2021-10-19, at 09:35, Thomas Fossati wrote: >=20 > hi Carsten, >=20 > On Mon, Oct 18, 2021 at 4:44 PM Carsten Bormann wrote: >> I believe we have an ongoing discussion on how bad the situation >> really is. >> What is clear is that CCM_8 is not useful without a regular rekeying >> regime. >> We now have numbers for that; the results hinge on what probability = of >> damage you can accept. >=20 > Sure, but what we are ultimately doing is shifting the responsibility = of > a hard configuration choice onto the users. Complex UIs should be > avoided. I agree that we need to do something. I would like to discuss what that something is. E.g., git uses SHA-1, which has been deprecated about a decade ago. There is a SHA-256 option now, but adoption is slow (and probably will = be until someone does serious mischief with SHA-1, which is not too = easy). I=E2=80=99d avoid stopping to use git until everybody has switched to = SHA=E2=80=94256. >> Appendix B.3 of 9147-to-be qualifies itself with "If the goal is to >> preserve the same margins as other cipher suites,=E2=80=9D - well, if = you >> chose CCM_8, clearly that was not the goal. >=20 > You say "if you chose CCM_8", but the thing is that the current MTI > situation doesn't give you a real choice -- the only alternative we > provide is around forward secrecy. We lack a "general use MTI = fallback > and that, I think, hurts us. As Achim said, CCM (without _8) is the obvious fallback (fall-forward, = if you prefer), and we should have a consensus document that points that = out. >=20 >> So I think we need a more detailed discussion of this. >=20 > yes! >=20 >>> * DTLS SHOULD NOT use CCM_8 =E2=80=A6 except if [___] (fill the blank here) >>> * DTLS SHOULD use XYZ instead >>=20 >> I think XYZ should be based on Keccak, >=20 > I think I see what you are thinking, but I'd wait for NIST's = lightweight > crypto outcome before making any concrete recommendation. It = shouldn't > take too long. Exactly, and that really should be the next major step before everybody = loses interest, with CCM as the stopgap. >> but of course people will want to make use of their AES hardware... >=20 > That, but people also want to be able to interop with > ${mainstream_tls_stack} without too much hassle. But you always could choose a mainstream cipher suite, if that was = important. >>> GCM >>=20 >> I still don=E2=80=99t believe GCM=E2=80=99s brittleness is = appropriate for most IoT >> applications. >=20 > I reckon we are past that point. The deterministic construction in = TLS > 1.3 makes it very difficult to fall into the "nonce disrespecting" = trap > that gave us so many nice CVEs in the past. Also, similar to > BCP195-bis, we can backport the construction to 1.2 via the IoT = profile. OK, but I=E2=80=99d like to see the numbers (how do you do a 64-bit = authentication tag, if that=E2=80=99s all you need and you do need the = compactness?). Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Oct 19 04:18:19 2021 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 D7C133A0B63 for ; Tue, 19 Oct 2021 04:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, 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 K2Se820ypza1 for ; Tue, 19 Oct 2021 04:18:11 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0AA53A0B62 for ; Tue, 19 Oct 2021 04:18:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id AB2AC18071; Tue, 19 Oct 2021 07:18:44 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xO0NPHTWCG1T; Tue, 19 Oct 2021 07:18:41 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id F04B51802D; Tue, 19 Oct 2021 07:18:40 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id ECD98614; Tue, 19 Oct 2021 07:18:04 -0400 (EDT) From: Michael Richardson To: Carsten Bormann , Thomas Fossati , "core\@ietf.org WG" In-Reply-To: <081C80A8-5317-4DB1-BBCB-21654AE6F444@tzi.org> References: <081C80A8-5317-4DB1-BBCB-21654AE6F444@tzi.org> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [core] time to start the deprecation of CCM_8? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 19 Oct 2021 11:18:17 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > I believe we have an ongoing discussion on how bad the situation real= ly is. > What is clear is that CCM_8 is not useful without a regular rekeying > regime. Understood, but are there actually algorithms where that isn't true? Even AES128-CBC runs out. > So I think we need a more detailed discussion of this. > (I do agree with 9147-to-be=E2=80=99s conclusion that "This analysis = supports > the view that TLS_AES_128_CCM_8_SHA256 is not suitable for general > use.=E2=80=9D =E2=80=94 I wouldn=E2=80=99t run my SSH sessions over C= CM_8.) This statement surprises me actually. a) SSH sessions do have a regular rekeying regime! b) many SSH sessions are relatively short, often minutes to hours. Yes, sometimes weeks to months. c) Yes, some SSH sessions move multiple dozen gigabytes of data (backup ses= sions). But they can rekey, and the sessions usually start/end every day. This is not to say you should use CCM_8 with your SSH-based backups, but I don't see this as a particularly downside. >> * DTLS SHOULD NOT use CCM_8 >> * DTLS SHOULD use XYZ instead > I think XYZ should be based on Keccak, but of course people will want > to make use of their AES hardware=E2=80=A6 CCM_8 has been a thorn in the side of IoT to cloud in my experience. I'm all for an XYZ that is strong enough to be part of the standard web set. I have no opinion about Keccak. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmFuqWwACgkQgItw+93Q 3WXVYggAmsUT//T/hRx0M+P0FYPq9OX4iE+M+lqg9QtfZTo2isftZ11ftKnMetdL iXbSrsKz0OUlOBWU7ce/lo6pVdd9D8s5vSpsLpu78gLa2tvo48TFHqBmSy3UqXJ7 aeMulWAFKUmE6+KMmrHLzMqvKmY3v7ohfB1Ouysc/hn7cnw5f7hxTZF8E1nyM3g2 JkHa0C8oPmJz1VZA0tbny+/E7Bv7IJlObZtceG0+7WE6QQNUHneaeeiCVemLGwgC zCcaYoMTXHFk0B3/xTTMsr4AiLq6ICt/qwxq+2chO7Nlu4tVTCmXrwZ9atjhXVM3 LHvJBxFLx+wBs4rLXY6yJ++A6/IX/g== =tMuH -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Oct 19 22:30:35 2021 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 1DC223A0A24 for ; Tue, 19 Oct 2021 22:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, 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=gmx.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 T1EfC_A6Blcf for ; Tue, 19 Oct 2021 22:30:25 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 2E2443A0A21 for ; Tue, 19 Oct 2021 22:30:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1634707809; bh=q6uudIX1Q78ii2T/29mvjzKkovqMewD+0FCbm9DK8MA=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=dAr8lSF0pNSsmyT8R18MxrwDvu+Zlay1/7iSI3ZCGTOkUxCxECqII7FTGR3w4gdTK Y7PJdztNz12tJmsz9+jzOet8UAEWN8qaJvx/ac6suJqpeee+8uDsZV7ZSmdN1EB7bq mW7uhnCJ/87s/OSxBS3R3xeAE8A8DnkelcYzWAsY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.10] ([5.146.193.130]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MhU9j-1nFiiY0Q4p-00eZR9; Wed, 20 Oct 2021 07:30:09 +0200 To: Michael Richardson , Carsten Bormann , Thomas Fossati , "core@ietf.org WG" References: <081C80A8-5317-4DB1-BBCB-21654AE6F444@tzi.org> <20585.1634642284@localhost> From: Achim Kraus Message-ID: <5580d99d-04b6-824d-51a6-2b36a17b2692@gmx.net> Date: Wed, 20 Oct 2021 07:30:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <20585.1634642284@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:4vs1rNq+3ivtpdJ6fY4bVVldIH2bwfrbzQ671+BQ0WZok2ySUYg qrUXVKjVmhhvAyEfMa8QxahZsPj5S1UNDAR19QUdM+Gf/z0ASBJxuPHRpmyL8OZ29fZDgpe jvM9y5SSbkp19GzfYSD7gLd0Rg+zxR4OopY3W4ntioIoUZbUxN2pjreWlwwybfc9UaPgLwk 7Jngi1+vcnhIFg/10w+bQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:/whyLkF2khg=:/s5lE1Hix1ESa5hp9HHahi L4rNkclT7RK4+WBB7c+d6/ojhfm98b3cyuInO1WQlIlz3PMe1Z3M5TuwAk4IlLv9RiH4BWQLj L7TRbzkcoqDrt7RbPu9WMCksVA8OEWemtEX3bO3igvSVZXcG0BQD0FiI3y6XKLxEr0K0gSumF jZjV9haSrZOuwc+DHm3U+HH//u/aVWURb86j0+K4A+qCuqmzvfYvGq7J6wHslTa95dx4aypUo EEQwGmG5XfNFiL+tnki3oR3yCn4pAIpbfY+g+opr+mY0F8v407lLo+ayqT72HQ0IZOPhvgfT/ Bo633pwCcJ8vrueCUDhEBzw6ewkFdTi1KFaSnxPUydbrYzrSV2qqu2gCRFcW+2dRBjBiXL6N2 KTX93Iu3e0zpJq0FJKAPT5W5rxTJJ0QLA4EUiJAGBLhfvd9QJmOoHgEcEWy80UFsWMVKBmyY5 YUGkJqUnCT5o3I5obiQwDK/h6cGsnSXyetgQahXqy0QnskIM8CZCbLxbYqRCTuqu9UClfh8r1 OjsieToqVGj3KKdLQXcs3qQUYckc9AlepXIGGTVl7u8DD1Z03vb1HNv8dl2fqMc3xRhk98DXN Z3J7Qvo7LAOJRzw2too2581ho39hn+4N7Jd5AxB3p0Wj88vDLXqlVPVPALjcr8SH9R7y9sf8f pwAy4l1n2sUz6pa559FpwthK+fz8KCs5scOo7CNYQTr9SYtdCd0ALDOsB80LMLXUkvn5b4mRG xdykRUaeFbGH5GG5MQaKsE324VmWjHvMzLsRKySdYMbqIGfTjmLeeqX3f+h+RpeHZ/fjebgaA JUAiMrhM6t1OEk732ZZmozz/3t4y4tB+F38FRrErQjQVuwtiJ29lnSxOt/pb/Ohc8s6JV4xfP yUTPnHbFjG1v9UGofytCI554sTs+5MUdtq/tWgq7xZFpq1OxAQ89GE3C2Og0VZuCDnBR7mAzA c2hhzYAedGXtL2gqoJ9BrhF4qWo1hnJp79O32xRwGUC+KR5tBXBzwQrMH5R/ES+zD7WetO9a5 y6j8W90DCEf/ENazzxW8y3JxJMquShxf0VomC82EW//snQr/oLt4zAQjhHsnjm7iosTOaeGkC D1TN+ZRjKhw0EE= Archived-At: Subject: Re: [core] time to start the deprecation of CCM_8? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 20 Oct 2021 05:30:31 -0000 Hi Micheal, > CCM_8 has been a thorn in the side of IoT to cloud in my experience. in my experience, TCP, RSA and X509 are much more holding up (small, embedded) devices to connect to the cloud. OK, though I'm one of the committer of Eclipse/Calfornium, my personal preference is obvious. (Some shameless advertisement: The upcoming release 3.0 of that open source project with the "DTLS Connection ID build in load balancer support", together with a general improved cloud UDP support (k8s), makes it much easier (and cheaper), to connect devices scalable and reliable to the cloud.) > I'm all for an XYZ that is strong enough to be part of the standard web set. 5 years ago, I recognized, that have a mandatory small set of cipher suites makes it much easier to use it. Your point, that the big cloud provider doesn't care about that, is in my opinion also the result of much less request from iot, as forecasted. I still think, to distinguish from DTLS "standalone" and "coap" usage, makes sense. In my opinion for "standalone", it's OK to change the recommendation. For CoAP I tried to point, that "unknown (weak)" is not "(proven) weak". My current ideas on that are: - check for each deployment, if the 8 bytes saving is relevant. For normal IP(v4) traffic we have 20 bytes IP, 8 bytes UDP, 13 bytes DTLS 1.2 record, 8 bytes nonce, and 8 or 16 bytes MAC. That's in sum 57 vs. 65 (or about 12%). Adding a CoAP message with 32 byte, the relative saving is less. In some cases it's more the MTU, which makes the 8 bytes saving relevant in order not to use 2 low-layer-messages. @Carsten: maybe you can add the numbers for more critical transport layers= . - test each deployments with both, CCM and CCM8. That should provide the experience to chose a good match. - a client, which chose CCM_8, SHOULD also offer CCM in the ClientHello. That enables the operators of deployments to switch to CCM in the future, if the "CCM_8/CoAP" turns out to be too weak. Best regards Achim Kraus Am 19.10.21 um 13:18 schrieb Michael Richardson: > > Carsten Bormann wrote: > > I believe we have an ongoing discussion on how bad the situation = really is. > > What is clear is that CCM_8 is not useful without a regular rekey= ing > > regime. > > Understood, but are there actually algorithms where that isn't true? > Even AES128-CBC runs out. > > > So I think we need a more detailed discussion of this. > > (I do agree with 9147-to-be=E2=80=99s conclusion that "This analy= sis supports > > the view that TLS_AES_128_CCM_8_SHA256 is not suitable for genera= l > > use.=E2=80=9D =E2=80=94 I wouldn=E2=80=99t run my SSH sessions ov= er CCM_8.) > > This statement surprises me actually. > a) SSH sessions do have a regular rekeying regime! > b) many SSH sessions are relatively short, often minutes to hours. Yes, > sometimes weeks to months. > c) Yes, some SSH sessions move multiple dozen gigabytes of data (backup = sessions). > But they can rekey, and the sessions usually start/end every day. > > This is not to say you should use CCM_8 with your SSH-based backups, but= I > don't see this as a particularly downside. > > >> * DTLS SHOULD NOT use CCM_8 > >> * DTLS SHOULD use XYZ instead > > > I think XYZ should be based on Keccak, but of course people will = want > > to make use of their AES hardware=E2=80=A6 > > CCM_8 has been a thorn in the side of IoT to cloud in my experience. > I'm all for an XYZ that is strong enough to be part of the standard web = set. > I have no opinion about Keccak. > > -- > Michael Richardson . o O ( IPv6 I=C3=B8T consu= lting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From nobody Tue Oct 19 22:43:14 2021 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 52AD43A0A3B for ; Tue, 19 Oct 2021 22:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.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 tUFIuEJ8emXY for ; Tue, 19 Oct 2021 22:41:37 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 A45103A0A3C for ; Tue, 19 Oct 2021 22:41:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1634708489; bh=LI2fMhiZTAPhrorbOeGKISKSzenhwFR96I3v8Zb+t0M=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=XRgw2bZ9hrty8Sec6dgYZy0wJc8RzF1kX3apAauO0AnnT5CG4nkDgypUbb54Vt+Kr lQe2wuLtBTK/oIgVv1P2RaQ5n8eVGr75i6H2Ldb9jJvI4bV9Ry8hVLIJHOOZBb6STp MCz3POqCPkS1Hw/sYZp+8hTdRKe+Y7sfozJpa2AA= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.10] ([5.146.193.130]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MhD6g-1nG00h2rJq-00eJXJ; Wed, 20 Oct 2021 07:41:29 +0200 To: Thomas Fossati Cc: "core@ietf.org WG" References: From: Achim Kraus Message-ID: <0ce231d7-fe5d-f616-c5ce-9b0ca2a55708@gmx.net> Date: Wed, 20 Oct 2021 07:41:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:tAqCu04s1GGIG9T9AxGzFxY+JWxtdrufir567qJ0QytRGRcxSfX mdzDRx++X1pN1Re0Uxy5q4gRSaJwQszv3Heqwv/9Qw4S5iSJhIGT0+ScYthTOnigzBMRzHV iQ8J4XWe34rakWCLtQZlY9Bpq4GKIbytnTbrV0Ed+ex7U7JRxn2BGwl/RqvYCTm/6qU1xfQ uo+clGNc3pNuYsr9Pi5/g== X-UI-Out-Filterresults: notjunk:1;V03:K0:OJJ7bepX47w=:/6RHusnjLIWhimMipv3jE6 LLTAZofoJQLKjmZ77bbZckMyzxK3WGPKchwaHe6CTHndiDQLgOEeM+PcBqh70KTGqoPRRr1b4 QEc1yq4e0NnSfT99yP+s3EN9QbrPOYTkqv0Mm2F5Kq5fIRCYTV9EVozqJ30ocE/2j9uWQUEGD NNBj3xg8YJd2pAlBrPa29GkTlxIoeU8atvTnm54yhT05Qpac8PZVpxhRWIR8pnGUq6lID8571 7Y1FzlXJ8IVrs0IWTWkPQ40Z+UFnbrJg4GokJRdWhNo/6dDrd9IbbFL/OyGM0YglBcMIaoHZ0 139n3VIMuaOHD7QHp6DhT6wPK4xP6ypnVU3A4VupMDQpCmMZB6fR8a78QWa9JQLneKwUogqEV ANUEH1+lPjKQ39Ou6ohzoFfsPz0xnyHOeDXZ4noj4ONLwOey2X+bYOMfrBUg34HOL4LV0N9LN qfiySjtVyGHW2Xz8r7kQ5HgMOk0/6cNGXjnn8XvPNVb7Xhybyh0knaR92Bnr9wef+Yt7+Mfk1 2yOg5s6CGB114g0FBvj6vdiPuA0c40z3xCDi7hO/r5yNs5U3+bSi3RXU4nb1WGKb+XQuj3mK8 k06bjuhE9Tipv8qr8HgAFtK1NX4r7v3/ZQuHSMTAeyX/CXxl8GfYKBVhD5cTK+0hmzRc1H++x TPeq20rnzOtgOGVt/YCmVyf/0luj2rt72LAGZcwmlkUJkIWID38YaN/1KHUxwQqS64KUFzsLP VEfp37n9ax40Nf23/AcHx9m4LSawL1mtS+KAm0A3pL7iDyE43VYPgRI5BhHNwzQxECSQh5F5Y e7MO/NmHIjtNhMOvE1qcqm9Ogp/7taIVMrC/r+3QAlrbou8oz3dW8mb/8ncqa9ADd7DiJmbok xUhZDqv941rXk2/aEbngCPy9K4P6P2VoomltmtR55U5+Aaxkm3LtWYJeFtf/kJ/Os5RNMlMAT chGvafRAFeglSJCHjC+GWnsVIsZjXNXOUecHGAroQWdTHLZX+wX8HReVfy8y0JVB79HqlHW11 UxK7cyiuBHrFDZzp16ep1/lu/V/qlfkvTFekRbu9lThL1iQyZIH/OXqHkt32wlLpic5rPQGad mwATdBTp1FF+PM= Archived-At: Subject: Re: [core] time to start the deprecation of CCM_8? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 20 Oct 2021 05:41:47 -0000 Hi Thomas, >> FMPOV it would help much more, and will get more acceptance, if the >> considerations about CCM8 weakness are clear, and applied to CoAP >> specific cases. > > That's super interesting stuff, but it's also a lot of non-trivial work. Unfortunately. Let me even add one more CoAP question: - is using a 4 bytes ACK (2 bytes fixed, 2 bytes variable, relevant lifetime up to 120s) for encrypted messages creating an attack surface? Otherwise, fixing CCM8 may be in vain, if the 4 bytes stuff is the larger hole. I guess, that coap specific questions will unfortunately not be answered in the next time. best regards Achim From nobody Tue Oct 19 23:52:24 2021 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 8EDF03A0945; Tue, 19 Oct 2021 23:51:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-core-sid@ietf.org, core-chairs@ietf.org, core@ietf.org, Carsten Bormann , jaime@iki.fi, jaime@iki.fi X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <163471269655.31149.5775241204402681281@ietfa.amsl.com> Date: Tue, 19 Oct 2021 23:51:36 -0700 Archived-At: Subject: [core] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-core-sid-16=3A_=28with_COMMENT=29?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2021 06:51:37 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-core-sid-16: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-sid/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. Based on the authors’ reply, I have now cleared one of my previous blocking DISCUSS points (related to section 7.5.2 and other SDO / mega ranges see also https://mailarchive.ietf.org/arch/msg/core/SyG1Ax5V2KmYM8v1_CFOmghpUs0/ ). I have kept the previous DISCUSS points below for archive. Please note that my COMMENT points are still unanswered as far as I can tell. I hope that this helps to improve the document, Regards, -éric == PREVIOUS DISCUSS == -- Section 3 -- As a YANG model can have several YANG modules, was there a discussion in the WG whether the SID range is assigned per module or per model ? The IANA section seems to refer to an allocation per RFC, i.e., per model and not per module. -- Section 7.5.2 -- AFAIK, many YANG modules are not originating at the IETF (Open Config, vendor specifics modules, ...). How can those non-IETF modules get a SID as the two ways to get a SID are based on RFC (if I understand correctly this section). == COMMENTS == I will let my OPS and Management AD to comment on the use of 'YANG schema' rather than 'YANG module' and about the word 'item' for many YANG-related concepts. I know that Alex Pelov is an author but was there any discussion with LPWAN WG on this? No need to reply but the use of ".sid" to qualify a file format reminded me of MS-DOS... ;-) I am somehow concerned by having so many SIDs being generated as it requires being careful in generating them and having a scalability issue when using them as the 'mapping table' could become quite large. -- Abstract -- Suggest to add the reason why using SID in constrained environments for people outside of CORE WG ;-) -- Section 4 -- In addition to a reference to RFC 7951, why not simply adding that the the ".sid" file is encoded in JSON ? -- Section 7.4.1 -- Out of sheer curiosity, why using a decimal million rather than the usual power of 2 ? Again just out of curiosity ;-) -- Section 7.5.3 -- Suggest to either remove entries related to ietf-anima-constrained-voucher or move this I-D in the normative references section. == NIT == -- Section 1 -- Suggest to expand "YANG SID" again as the abstract is not really part of the document. From nobody Wed Oct 20 01:38:52 2021 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 75C073A0DA8 for ; Wed, 20 Oct 2021 01:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 ySfSswNUdAfe for ; Wed, 20 Oct 2021 01:38:49 -0700 (PDT) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 E9B213A08AE for ; Wed, 20 Oct 2021 01:38:48 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id j21so13636199lfe.0 for ; Wed, 20 Oct 2021 01:38:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=29dfqyFnWBWzaugU3qV+1uJ08oYknH4w/+Y6GVATm/8=; b=AtEdMdIuz2vsSKN6CZCNV7XTKiPl+dIUIiS8jlP73iAB+naedsC9hvTnzttNuj7tVN JvLhjpKw4nCfceBVnJGf7I5tss8Klu5gWUhy8sS5AJYLVxJbSeZE1quhGqdMKx+L/2Zx theLarAia47nFgSK7W1txJUHe9PEWBZ78KoMZqfurlzMiSqzzPV2XKne6j9DsZV6uCG9 VBp3l368ZX9j1mmjFpbtOnQgShovGL9MirL95hPUGJP7fTmfn2H8UnVQcQfhSwVzYDhh R/EqcZc+BPRiJW974FVTfPKGTGNyT+6CGnfGbEHYwo41KCbzvvxQWp3qsisOEo6sKU6T SZDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=29dfqyFnWBWzaugU3qV+1uJ08oYknH4w/+Y6GVATm/8=; b=xpwd//E8HytNtQgVaV+1u/hDHlA4C0X+b/GP0jaWW7fZYzncJMOpLjXEirewBa+uj4 TDDVhJd7uqd3qnMsSQbVh+/IWEaHlxT+OzbhIQce6GpRH5EeEYKBqCCnxXnqw0Kt3hU4 G8voio8e+LMIywktl2QHQ7wMKR/HpA5Xc4uVo4xh/Y4EPE6OpfFjvqjq59ZDmM1vThtd R/dVvT3dYRcs90VsT0GnSvqLPZckJ6Wx9Qtdet72cm/4I4MMf7qkqHzkr3hszzJAMgjj ANCB1DaCvBqdelPYOqVwnZjNDWVkjnXHJu4cz/OIBwkL8W5661MKDvthssCor9wjxY5j r4Yw== X-Gm-Message-State: AOAM530dIJvonxPV1bPDserfxXYchOXcKArFYgR/27XvwaidfoZQ6Y+v MDaEpq0gK+F8gqNlIWoaZXqh/6iJkd8r1n6Mjb5QEymZ X-Google-Smtp-Source: ABdhPJyIXP8gCnhfKbssftYtcf9qeHj/4I9M/Vdi8kGKNxGErEHylkjRjjbYZGmn94de301E7SIwINc/x2feFteCS5w= X-Received: by 2002:ac2:443b:: with SMTP id w27mr10968968lfl.63.1634719125194; Wed, 20 Oct 2021 01:38:45 -0700 (PDT) MIME-Version: 1.0 References: <0ce231d7-fe5d-f616-c5ce-9b0ca2a55708@gmx.net> In-Reply-To: <0ce231d7-fe5d-f616-c5ce-9b0ca2a55708@gmx.net> From: Thomas Fossati Date: Wed, 20 Oct 2021 09:38:34 +0100 Message-ID: To: Achim Kraus Cc: "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [core] time to start the deprecation of CCM_8? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 20 Oct 2021 08:38:51 -0000 hey Achim! On Wed, Oct 20, 2021 at 6:41 AM Achim Kraus wrote: > Unfortunately. Let me even add one more CoAP question: > > - is using a 4 bytes ACK (2 bytes fixed, 2 bytes variable, relevant > lifetime up to 120s) for encrypted messages creating an attack surface? > Otherwise, fixing CCM8 may be in vain, if the 4 bytes stuff is the > larger hole. I don't think so, it's the size of the key (and of the integrity tag) that is relevant. cheers, -- Thomas From nobody Wed Oct 20 01:46:46 2021 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 0AFC23A0872 for ; Wed, 20 Oct 2021 01:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 qHZqYSAWQ2Hz for ; Wed, 20 Oct 2021 01:46:36 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 987B73A084F for ; Wed, 20 Oct 2021 01:46:36 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id t9so13561080lfd.1 for ; Wed, 20 Oct 2021 01:46:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=5vi4ndHpPIuKmpve/VdxqKqVKMthyDvyHgsDqcbgVog=; b=LBSjjwLrsACLgtK4Xu9cL1tVnFnQYoriyLCgiPT8VkYN9Xua86NoEwRX/6BkmHsH5B 5UXXmMqPIV75FsrF3Zi2manI/dFeGvYaQOvD66iUJeV846hijUOXL3akdpfjoV+cCxdZ TkKFtU6+x+9YHi75DgXM/Z0gAGm1llcZBtnbfIs6HhAkH+4S+w9M5ay3B1dQFfDHLKxE E+DvIadxDiPFWuMAqxrNuOIRhxsIjgibHHWJZIBuHdGQ6o8FoCCDdf1s+DE8jC3OdDqt tU518VVg1vPNKLTA7WBYRRO57B/dk2iyGSEeLJ8ObpULkjb3Su57OehyJspw6fLm/6XT WWOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=5vi4ndHpPIuKmpve/VdxqKqVKMthyDvyHgsDqcbgVog=; b=kU0ZIaJFst5w7RrgwbLeGuHvKY5Jcyot/B+6E35dUcPBD8jJdHCkN/SWfth21+aieK nvsmk2yc1phohY/11dKR4ofkhHUh2iNdKrGFmuMbUW9YX2oylzB7+jqoz/rUcsrcDOpD 7Ywt+Eo+YX+sBc3qixLXy8/fp48V3wAsuFvULGvmnAXkL+crof6RUaMt+qhA5/ZXsLv7 b9XCZsJREVh0YsXXijeexfnGzbcM1VshbGiFx8HI8ILr/7YPulR5knRPD4Y9sLVyPioJ +EZ3VDaeSOHawiuH5a51WNtc+o5dYq5frx1K/QVZXjoFqwEcKVM0SjNMXo3j/zTTFZIj wTCA== X-Gm-Message-State: AOAM531lW/JXRRymWSudW3XLjDOpIIzvIlFodMFmlmlkTcPZibAjJBlu mWmfqBImAo3V64sQSOgA3GzqG3X7+UJMSTFGAd4= X-Google-Smtp-Source: ABdhPJyan1VxIxJy72ov5kHBuQFufjlbw0ulQZWxWO9xIrpd/rIc2mTS5rmmNJmgaGlHhfN4FnxCWTQ1SBF0fsQvr60= X-Received: by 2002:ac2:4bc2:: with SMTP id o2mr10950435lfq.501.1634719592507; Wed, 20 Oct 2021 01:46:32 -0700 (PDT) MIME-Version: 1.0 References: <081C80A8-5317-4DB1-BBCB-21654AE6F444@tzi.org> <20585.1634642284@localhost> In-Reply-To: <20585.1634642284@localhost> From: Thomas Fossati Date: Wed, 20 Oct 2021 09:46:21 +0100 Message-ID: To: Michael Richardson Cc: Carsten Bormann , "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] time to start the deprecation of CCM_8? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 20 Oct 2021 08:46:42 -0000 hi Michael, On Tue, Oct 19, 2021 at 12:18 PM Michael Richardson wrote: > > I think XYZ should be based on Keccak, but of course people will wa= nt > > to make use of their AES hardware=E2=80=A6 > > CCM_8 has been a thorn in the side of IoT to cloud in my experience. > I'm all for an XYZ that is strong enough to be part of the standard web s= et. If that is the case, then maybe full-tag CCM (which has the otherwise excellent property of being easy to upgrade to) may not be the best choice: $ openssl version OpenSSL 1.1.1l 24 Aug 2021 both $ openssl ciphers -s -tls1_2 | sed -e 's/:/\n/g' | grep CCM $ openssl ciphers -s -tls1_3 | sed -e 's/:/\n/g' | grep CCM return the empty set :-( GCM would seem like a better choice under that requirement. cheers, t From nobody Wed Oct 20 01:55:14 2021 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 1DC6A3A08FD for ; Wed, 20 Oct 2021 01:55:11 -0700 (PDT) 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, SPF_HELO_NONE=0.001, 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 N5CLIUxEMtld for ; Wed, 20 Oct 2021 01:55:07 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5BBD3A08FB for ; Wed, 20 Oct 2021 01:55:07 -0700 (PDT) Received: from [192.168.217.118] (p5089a10c.dip0.t-ipconnect.de [80.137.161.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4HZ4F343L7z30Ks; Wed, 20 Oct 2021 10:55:03 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: Date: Wed, 20 Oct 2021 10:55:03 +0200 Cc: Michael Richardson , "core@ietf.org WG" X-Mao-Original-Outgoing-Id: 656412902.802128-352970a54ad3201e3a78b0dafec92f7e Content-Transfer-Encoding: quoted-printable Message-Id: <4603B5A0-8179-40D7-9335-52D9FD59BAE8@tzi.org> References: <081C80A8-5317-4DB1-BBCB-21654AE6F444@tzi.org> <20585.1634642284@localhost> To: Thomas Fossati X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] time to start the deprecation of CCM_8? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 20 Oct 2021 08:55:12 -0000 On 2021-10-20, at 10:46, Thomas Fossati wrote: >=20 >> CCM_8 has been a thorn in the side of IoT to cloud in my experience. >> I'm all for an XYZ that is strong enough to be part of the standard = web set. >=20 > If that is the case, then maybe full-tag CCM (which has the otherwise > excellent property of being easy to upgrade to) may not be the best > choice: So you now switched to solving a different problem: Finding a cipher suite that works in TLS 1.2 and 1.3, is not brittle, = and is supported in the default list of openssl ciphers (where that can = change any moment). That is an interesting problem, but maybe not the one we are solving = here. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Oct 20 01:58:58 2021 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 5763C3A0867 for ; Wed, 20 Oct 2021 01:58:56 -0700 (PDT) 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, SPF_HELO_NONE=0.001, 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 Ann1kkWs1Afs for ; Wed, 20 Oct 2021 01:58:51 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D1393A08FD for ; Wed, 20 Oct 2021 01:58:39 -0700 (PDT) Received: from [192.168.217.118] (p5089a10c.dip0.t-ipconnect.de [80.137.161.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4HZ4K75hpCz30LL; Wed, 20 Oct 2021 10:58:35 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <4603B5A0-8179-40D7-9335-52D9FD59BAE8@tzi.org> Date: Wed, 20 Oct 2021 10:58:35 +0200 Cc: Michael Richardson , "core@ietf.org WG" X-Mao-Original-Outgoing-Id: 656413115.416544-992a0346e33a7209572d06f01844129f Content-Transfer-Encoding: quoted-printable Message-Id: <3B735512-CAAE-433E-BBF1-446088E3FFD2@tzi.org> References: <081C80A8-5317-4DB1-BBCB-21654AE6F444@tzi.org> <20585.1634642284@localhost> <4603B5A0-8179-40D7-9335-52D9FD59BAE8@tzi.org> To: Thomas Fossati X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] time to start the deprecation of CCM_8? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 20 Oct 2021 08:58:57 -0000 On 2021-10-20, at 10:55, Carsten Bormann wrote: >=20 > Finding a cipher suite that works in TLS 1.2 and 1.3, is not brittle, = and is supported in the default list of openssl ciphers (where that can = change any moment). And the bonus of course is having an 8-byte version that as well (that = is supported by default by openssl, to ensure that this is entirely = impossible to achieve). Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Oct 20 02:05:56 2021 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 4AB553A0F4D for ; Wed, 20 Oct 2021 02:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.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 sd7gUUNQJdYe for ; Wed, 20 Oct 2021 02:05:45 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 674C13A0EFF for ; Wed, 20 Oct 2021 02:05:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1634720737; bh=S7dwjMc9dBPKni7l9hlvfHySdUpr6oKsb+PPuUDqoZ4=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=i85hWrKXI57bSQRu1cQvyydD+wmEVySR/dq7blPM8yKT+TUQ628qWOfziYb0ZYO+Q LkAFZhmyuPay96vyjcKs2giapfAFqsxVJgaen8txyZs6zpeFOtzNwwD4qSduRYP8Ay /cK1ZbX/tmKHttSTtkpT6oz2vMu69sX3OvlXu/kY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.10] ([5.146.193.130]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MC30P-1mQm8D3fq9-00CRFE; Wed, 20 Oct 2021 11:05:36 +0200 To: Thomas Fossati , Michael Richardson Cc: "core@ietf.org WG" References: <081C80A8-5317-4DB1-BBCB-21654AE6F444@tzi.org> <20585.1634642284@localhost> From: Achim Kraus Message-ID: <3e6ba342-9712-15c3-c0e3-2d3194ff23dc@gmx.net> Date: Wed, 20 Oct 2021 11:05:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:RxRLOlg0bc5W+j9sPH0L7Twu1fgE0CCcqhxF0sW46iWRseprYSC yCQ7PV79vbNlmaOKt1We0Iq7/MHg8FJy2igpuYgPFr9lnA6H+El9Ex6V0rCo8E3nNHk10eY M9hp7IXffFuRbsP+FWpml9Hg4ozUMfB5uT/uohunHW7j+9usQYhtijdyMTmOwiZ+pbfqsv+ aIlnRN7IBQyeRQC3o8KTw== X-UI-Out-Filterresults: notjunk:1;V03:K0:Iagf/845Ek4=:4r8M+1+R3aaZVl+2y9HP7L 2hyv4M/GjkG2A1VP8cxNGHyQ+sfNTGCjt+ob3gEOwM/zKkTQmMAWqgH8apUEG02/8V63UbHTo v2vrkP17w3sVT0OatvZP3zMICWNYTKmtVbv7ZH9W9VhSy3njsL6EPTlm2AfFKtAsBxHq7cqSi iiOJQeAFOUisdslmgj+Cgy5J2jDuTK0u8lxnCb2izQ3THSj6H0h8uufBHjogzDuPtSHFjhUPx +DmHVL52A1sS3vYaBfshqRjuNN6s76T/B0+pXnpb69q5558GdftNmZbhmQNdDVqjtzybBhLdk 3J8grHvOjb9XS6Dt7WSqiUQ9ENw3VFLAdQE9VVqwhCc4sf3cJG+UC5ebx4cgc0eUBdywqqmR2 hVnBf1QXd8DFxHpGnOvF66p9l5UG2PJyfJXRFUCPxUFQ6VF43IvsXUp9aApEauhnnhbHVI/PS +K8F2eFMVise0aRBJdA/408d4L215H+quUiHVKhYy6cgHJfHnvxl3rLr/gGEU3c0Ns4vqxwOG APEdzsQ3Yd3F2vNytPpWPLkK0f26xnNx/SHhgTHuJMna1F2jqp9Kzcc/M6gOg8n3YM0fPY9Bh xBpWApa52GVsmbIMX0fk+cMBd8rsizt+qwa/iAUkgExfI6+XRNZOcPur/B9obgDV+ti0PXa10 KEjhazO4rFK7fl1Vbcl49h1xGaVj0lAa87C+kzVgl/4VZRv87rhTWo3mHoTw2qqrvoVnK0NoC O67pVOuHvNO3L8/CIMfcHSgcLupo8XGxjDrol0nDoxLn6XkAz7GDYjPsUtorfXQP6FdLJ0NFN alS9Rt7Sh7aCcavITwnzLMBkVZhQGnCBYWEmdueJmAGf/d1As6TPRabXGlxtktLLlGW7dOg7R N0Va5fyGedBYg043+smg0QlP/Uyj5h9hnzrQ8Qw44OLX9Yqc8oCTXdRiW7XMO3FPpqlfvAGr2 +S7BMkWB/3UWD++3Q/81xKojzp16rsEm1Qh2hVLooYyKhSYAW8yBKl9QsaEXazxmcHhbKk/Pl zVVx+D/zybNQtEXXVWPmh5l4hE2r+2FMywWQzDjhBN9ELTZ//ywNjv6Zms5IWOLdRci24XT02 EISN0iC2exbzL0= Archived-At: Subject: Re: [core] time to start the deprecation of CCM_8? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 20 Oct 2021 09:05:53 -0000 Hi Thomas, > $ openssl version > OpenSSL 1.1.1l 24 Aug 2021 > both > $ openssl ciphers -s -tls1_2 | sed -e 's/:/\n/g' | grep CCM > $ openssl ciphers -s -tls1_3 | sed -e 's/:/\n/g' | grep CCM > return the empty set :-( but the CCM stuff could be enabled, even CCM8. In my opinion, for the cloud-connectivity, it's more interesting, what the big-scaler offers, and not so, what openssl does on default. best regards Achim Am 20.10.21 um 10:46 schrieb Thomas Fossati: > hi Michael, > > On Tue, Oct 19, 2021 at 12:18 PM Michael Richardson > wrote: >> > I think XYZ should be based on Keccak, but of course people will= want >> > to make use of their AES hardware=E2=80=A6 >> >> CCM_8 has been a thorn in the side of IoT to cloud in my experience. >> I'm all for an XYZ that is strong enough to be part of the standard web= set. > > If that is the case, then maybe full-tag CCM (which has the otherwise > excellent property of being easy to upgrade to) may not be the best > choice: > > $ openssl version > OpenSSL 1.1.1l 24 Aug 2021 > both > $ openssl ciphers -s -tls1_2 | sed -e 's/:/\n/g' | grep CCM > $ openssl ciphers -s -tls1_3 | sed -e 's/:/\n/g' | grep CCM > return the empty set :-( > > GCM would seem like a better choice under that requirement. > > cheers, t > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From nobody Wed Oct 20 02:16:36 2021 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 1DA993A0FAE for ; Wed, 20 Oct 2021 02:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 xEOmqyzWTTNJ for ; Wed, 20 Oct 2021 02:16:28 -0700 (PDT) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 400EC3A0F9D for ; Wed, 20 Oct 2021 02:16:28 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id x27so13709541lfu.5 for ; Wed, 20 Oct 2021 02:16:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HI1qj+NOLZmmHSYMOAC3yrS9CYEHoKtcOclqdDQpNmk=; b=qkf4ynA9zSdPC1gsU+JBLl0m+2Y7e+44Yrhn0gmzNOwtqyZTxBGLwsVfZIhyQj+Y/7 SkT8Z70OmW6DJWYPmrrn636T5ILDmV9txF61FeFwCPEZI0IOnCqQiUx07V9uoTqAat4w fBEnMCqWHTGCLrbD2uMoMlxAo/o0ajx2mw0hoAUv4xhfqganB6WpepeEoNj+/CV80e40 9ysySa0XrccwEC65kCXojbJxLWMI+r3tnmRbQLWTOl0MDjnpA/9zUPif46yuPYQlxTbm AbYVNF8zgw4EKF9aolNVjcfK81ZtvA1P8yEDOJjUfY9piDrFpxGQQW93bjcJuB/mO9xm xiKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HI1qj+NOLZmmHSYMOAC3yrS9CYEHoKtcOclqdDQpNmk=; b=Q40ayeT+oLMp1NbDiLx3n04f2+aKUptbWoyd/NcRpv9Pr138J9a3ttGMSFnTktXEqT j3fQfK8t/TfyBmEQbWyhyGg0DsI1HFI3odm7dtv79qoWs8xI20OuzqBnc5eqkPsDiXDg RcTJlRdFzx2/ubHY09K3/ZgYsMtavRX748400oWiFNGET5BjM4XjuE2Zb1OtDJmndM+Q pyKq8dvmiHar4QtUYKAi3EAIgs3yZYdMngS6cGBzWCeKlQQOfRP651YweXPQ/hQXPIHu HpAHKVNdT+JQ8xogsgrGQ+RES1gANd3gG7qOgciuVItSxR0ppQ/4p2maFyxWuVaMgqzH sCaQ== X-Gm-Message-State: AOAM533dgxLPec980SpAdTgx5Z0zWAkl9t+fXHkE6CrlubFzLHPjGDC0 AIShbDqHE2Az9fjFcof/UB2EEwGeWnJLMsARrZA= X-Google-Smtp-Source: ABdhPJzUL5foZCnrMZ3LryJKDq03Jogh3bwwZQUAGBSNZLa0OeHghcEEDdSa3be9BOSCSSnTMUPWQFSxoUZGkku0MyU= X-Received: by 2002:ac2:4e85:: with SMTP id o5mr11065457lfr.105.1634721385241; Wed, 20 Oct 2021 02:16:25 -0700 (PDT) MIME-Version: 1.0 References: <081C80A8-5317-4DB1-BBCB-21654AE6F444@tzi.org> <20585.1634642284@localhost> <4603B5A0-8179-40D7-9335-52D9FD59BAE8@tzi.org> In-Reply-To: <4603B5A0-8179-40D7-9335-52D9FD59BAE8@tzi.org> From: Thomas Fossati Date: Wed, 20 Oct 2021 10:16:14 +0100 Message-ID: To: Carsten Bormann Cc: Michael Richardson , "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [core] time to start the deprecation of CCM_8? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 20 Oct 2021 09:16:34 -0000 On Wed, Oct 20, 2021 at 9:55 AM Carsten Bormann wrote: > So you now switched to solving a different problem: > Finding a cipher suite that works in TLS 1.2 and 1.3, is not brittle, and is supported in the default list of openssl ciphers (where that can change any moment). I was providing one (to me surprising) datapoint which seemed relevant to Michael's comment. (The comment being "I'm all for an XYZ that is strong enough to be part of the **standard web set.**") -- Thomas From nobody Wed Oct 20 02:31:44 2021 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 27F0B3A0856; Wed, 20 Oct 2021 02:31:00 -0700 (PDT) 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, SPF_HELO_NONE=0.001, 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 OvcCkp9GH-Mo; Wed, 20 Oct 2021 02:30:55 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E6C03A0855; Wed, 20 Oct 2021 02:30:55 -0700 (PDT) Received: from [192.168.217.118] (p5089a10c.dip0.t-ipconnect.de [80.137.161.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4HZ52P1QWJz30Lx; Wed, 20 Oct 2021 11:30:53 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <163199251278.32143.9125277138231739491@ietfa.amsl.com> Date: Wed, 20 Oct 2021 11:30:52 +0200 Cc: The IESG , draft-ietf-core-senml-data-ct@ietf.org, core-chairs@ietf.org, "core@ietf.org WG" , Jaime Jimenez X-Mao-Original-Outgoing-Id: 656415052.64104-201bd2965ea443bf0dc02243d9107ffc Content-Transfer-Encoding: quoted-printable Message-Id: <546C3C20-0928-4D76-99D3-B73824E0D811@tzi.org> References: <163199251278.32143.9125277138231739491@ietfa.amsl.com> To: Roman Danyliw X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] Roman Danyliw's No Objection on draft-ietf-core-senml-data-ct-05: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 20 Oct 2021 09:31:01 -0000 Hi Roman, Francesca reminded me never replied to your comments. Sorry about that. > On 2021-09-18, at 21:15, Roman Danyliw via Datatracker = wrote: [=E2=80=A6] > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Is there any generic guidance to provide on expected error handling = behavior if: >=20 > -- ct (or bct) contains a number outside of the 0-65535 range, or an > unregistered value per the CoAP Content-Formats? >=20 > -- ct (or bct) contains a text value that is not a registered > Content-Format-String? >=20 > -- ct (or bct) contains a valid Content-Format-String, but an = unregistered=20 > Content-Format? >=20 > Or is this application specific? Based on the discussion at the CoRE Virtual interim - 2021-10-13 [1], in = -06 we actually decided to answer the question you didn=E2=80=99t ask, = and added a subsection [2]: =20 +## Evolution + +As with SenML in general, there is no expectation that the creator of +a SenML pack knows (or has negotiated with) the consumer of that pack, +which may be very remote in space and particularly in time. +This means that the SenML creator has no way to know whether the +consumer knows: + +- each specific media-type name used +- each parameter and each parameter value used +- each content-coding in use +- each content-format number in use for a combination of these + +What SenML, as well as the new fields defined here, guarantees is that +a recipient implementation *knows* when it needs to be updated to +understand these field values and the values controlled by them; +registries are used to evolve these name spaces in a controlled way. +SenML packs can be processed by a consumer while not understanding all +the information in them, and information can generally be preserved in +this processing such that it is useful for further consumers. I hope this, indirectly, does answer your question, as evolution can = make it look like a creator used unregistered values (that the consumer = just hasn=E2=80=99t heard about yet), and that needs to be handled = exactly the same way. (The content-format being out of range is the only error that can be = reliably detected by a consumer the writer of which didn=E2=80=99t have = a crystal ball. I think at some point we=E2=80=99ll write an informative document about = SenML best practices, and that will also contain some hints about error = handling. But putting this here would be going outside the scope of the = specification of this single pair of fields.) Gr=C3=BC=C3=9Fe, Carsten [1]: = https://datatracker.ietf.org/doc/minutes-interim-2021-core-12-202110131600= / [2]: https://github.com/core-wg/senml-data-ct/commit/0a57952 and = https://www.ietf.org/archive/id/draft-ietf-core-senml-data-ct-06.html#name= -evolution From nobody Wed Oct 20 02:43:49 2021 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 C400D3A08D3 for ; Wed, 20 Oct 2021 02:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 jx5afpBsH1h9 for ; Wed, 20 Oct 2021 02:42:55 -0700 (PDT) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 3DDE33A07AA for ; Wed, 20 Oct 2021 02:42:55 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id y26so13782695lfa.11 for ; Wed, 20 Oct 2021 02:42:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aeSFW1p8gZZhXhbZa1Qjgc0zRK8V1BQ6Eja5viFVb24=; b=NA8K7lSiQspDLsjSwbf+kXylVnPpE7iOvz1BvFK8pPbPZwGVw/GeMzu6o6YZa+VA9D 4bw9CbPVRUSDMT0giaCRmQFyUalhYW+QhT29DMcUJIZU7gZfTy5xSTVbn1r5dzI7v27l Qum/ImophrNl0KXHCTijIhUXvOczHfzaQbValKFwLYAqxrmCIwZ6aGicAeu5zO9tzFbV cga9rAfIEGfVMkD9RBFoDbLl+1A7CITLvGhHswZm3htDFY4LqR2MsJn8bRXeqYDRYM+3 T+7lNy1UBL/qGFdyJCiqVbZPY8cdHEndOB8mlGAcIeNhtxXvtTIbjIU4r/4YdvMtSINS II9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aeSFW1p8gZZhXhbZa1Qjgc0zRK8V1BQ6Eja5viFVb24=; b=K63cLb5wra/eCjKrkMWlNqC5iA5JwZi1nx8PYEf/wYFeVoyXwI25WpU7I9iNcbfc6f G4vVP/oD9ENRR707hI0K8kKZtKHR76Rm1dK1PhcCjndE6xvlx2di5hut0C8GzHRdeiCL AxUx3ui3JHJHLXppFhRGZ7gL6brcY1KF6EgNulGCMAkebDAJZqdv0CJ16xXSFAWcFK1J dZOKsJpcUvMD2SP6ttPzHfnCe3yFYlizLn+kyGs6jbymHvEi8NkKKI58Y2l++wAHScKF ktuFuxDkq99mt7D1jpCr8xuZ7SQQMkiiWTYKChPG3OPNuaMHxU8vlcgij1gzswlp76Wc uLsQ== X-Gm-Message-State: AOAM531BPxfpZNIlWcDJGxCBKrdU5Y28WxW9DTXQhyEy9xuDM/zqCTzL Fmu4SxYVTq6s3Uxwfsd23Sm9ZOu9jhjZWs4j0Dw= X-Google-Smtp-Source: ABdhPJzEK3jENdxRof0TG/iQ72k1Kb07ADu1/o/DpQ+ek+6Vmj9w6RfhWAVU4xmimEl9YRMwAGHwiUE1a+T9olG4OVQ= X-Received: by 2002:a05:6512:2025:: with SMTP id s5mr10910005lfs.30.1634722970182; Wed, 20 Oct 2021 02:42:50 -0700 (PDT) MIME-Version: 1.0 References: <081C80A8-5317-4DB1-BBCB-21654AE6F444@tzi.org> <20585.1634642284@localhost> <3e6ba342-9712-15c3-c0e3-2d3194ff23dc@gmx.net> In-Reply-To: <3e6ba342-9712-15c3-c0e3-2d3194ff23dc@gmx.net> From: Thomas Fossati Date: Wed, 20 Oct 2021 10:42:39 +0100 Message-ID: To: Achim Kraus Cc: Michael Richardson , "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [core] time to start the deprecation of CCM_8? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 20 Oct 2021 09:43:00 -0000 hi Achim, On Wed, Oct 20, 2021 at 10:05 AM Achim Kraus wrote: > but the CCM stuff could be enabled, even CCM8. Sure, but sometimes this is a configuration choice that others make for you and that you can't control. What I'm saying is -- WRT Michael's desideratum -- GCM may be a better fit. > In my opinion, for the cloud-connectivity, it's more interesting, what > the big-scaler offers, and not so, what openssl does on default. Good point. A quick googling returns these results: Amazon IoT, no CCM: https://docs.aws.amazon.com/iot/latest/developerguide/transport-security.html Azure IoT, no CCM: https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-tls-support Google IoT, no CCM: https://security.googleblog.com/2015/09/disabling-sslv3-and-rc4.html cheers, thanks From nobody Wed Oct 20 02:45:13 2021 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 4349C3A095D for ; Wed, 20 Oct 2021 02:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 iKYX8NotK8as for ; Wed, 20 Oct 2021 02:45:04 -0700 (PDT) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 984533A07AA for ; Wed, 20 Oct 2021 02:45:04 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id r19so13776249lfe.10 for ; Wed, 20 Oct 2021 02:45:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FrmznKb68oBRydtZI9lrx9uqj8XaHhkqVaV0pXBSy2s=; b=OzRZ4WrVVr0UdxtYlHs1h0u9u4OmqoDjGI6srJ/y+xJvgr0OOLUUCvYYmbkohOMCdW Eks6euZQSZNU9KRjbntqHJjM0M9VYcFBHHNxt3iy570G55/2W567Hm5mUCdjQoF3UJEe g7YiKwppn/6RpfVXJoXZUxCv90GqcVs9EqpyQsb8aaZrkzytVLGiwuyjZG9sV6fBiVA8 8VDnLMH95IZ8rr7ROZILGyi8UiLPECBhiPIS3dRyZLO+7xfSdMSFKa/iiA8FLu4VdUJ4 F4CJhzS3i9dDjZWeuq++TMl+XeR5cBWmdmL9QNVxpGsNcczKNVaVOM9yWfZj4M4BlM08 YTuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FrmznKb68oBRydtZI9lrx9uqj8XaHhkqVaV0pXBSy2s=; b=GQaZ9gZJaiId1FwNtIYVz/YaDkGs89dkquYkoXqmuZ+kkttHsjgX4Lo9wGBNJ9Z/vO qUXglLCBENVuqzOWHcZKfiVY8/MMxTtW6lnukg7RgiVGmF2LiEaFgP4BvU7IR36gIkjG VEk0HDCkIZjfQ+4eCVoge3e+MTqy0Bflskp0gqrObHYtY+ZD/gZEBrAnV5HGb9axkUnU Y48KXaHa9LU+b7+ZF5xDQ6lOb/JhwJc5P46wPicP7WWNg071XNWql81/GoBXZlyMWgi4 Tukx2eIJ+IXBzO5oeb6MKcM4fm64z95py3cRMgveRu06jFUH1cgJxFXZtetcn9AXmU2b g8ig== X-Gm-Message-State: AOAM5314jgkqBBMxMabdoOnbJ/C7cPsKzZrZ6gcREHdAy6ebgNcNQjzz 57Z/KnbyjVDoLbgVxI/yfG33XquZo4D9rvGMlg0= X-Google-Smtp-Source: ABdhPJwZUdFkltLWIOyT/XhzHBvXU6QXQpfiLa+BH2uVIn8VED1e5Q+9i0lrHUt64nRS3lTw42d7T6huoNjKMRz2xWQ= X-Received: by 2002:ac2:4e85:: with SMTP id o5mr11178055lfr.105.1634723101657; Wed, 20 Oct 2021 02:45:01 -0700 (PDT) MIME-Version: 1.0 References: <081C80A8-5317-4DB1-BBCB-21654AE6F444@tzi.org> <20585.1634642284@localhost> <4603B5A0-8179-40D7-9335-52D9FD59BAE8@tzi.org> <3B735512-CAAE-433E-BBF1-446088E3FFD2@tzi.org> In-Reply-To: <3B735512-CAAE-433E-BBF1-446088E3FFD2@tzi.org> From: Thomas Fossati Date: Wed, 20 Oct 2021 10:44:50 +0100 Message-ID: To: Carsten Bormann Cc: Michael Richardson , "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [core] time to start the deprecation of CCM_8? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 20 Oct 2021 09:45:11 -0000 On Wed, Oct 20, 2021 at 9:58 AM Carsten Bormann wrote: > And the bonus of course is having an 8-byte version that as well (that is supported by default by openssl, to ensure that this is entirely impossible to achieve). Not sure I understand this comment: irrespective of what openssl does, what other chiphersuite provides 8-byte auth tags? If the requirement is an 8-byte auth tag version you are left with no other choice than CCM. Is this your requirement? -- Thomas From nobody Wed Oct 20 04:12:57 2021 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 6E44A3A0A78 for ; Wed, 20 Oct 2021 04:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.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 WEslT0dXCHPT for ; Wed, 20 Oct 2021 04:12:48 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.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 DF3993A0B1D for ; Wed, 20 Oct 2021 04:12:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1634728359; bh=N7KhvZ2CeFcTSXxMAB4AumQIkvqOTCCu9lM1v6gRlkw=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=AvAA4RxHZBnQgRNEpLGFeXj2X+5MftuqIhPH2y2WgHOh90oiiWfnIHH7tIiAiYnmC Ssb8Y20wpdklySH+zD+oIIMcgn92USRfy2+S0I2e46rbMPxEQmK0j2pnrJQkYMNYCt k9aT7ICSFTuAqz0gpavgstZHX1pxjZuCpa/NMwxU= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.10] ([5.146.193.130]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MvbBu-1mstxB2OEI-00sgHh; Wed, 20 Oct 2021 13:12:39 +0200 To: Thomas Fossati Cc: Michael Richardson , "core@ietf.org WG" References: <081C80A8-5317-4DB1-BBCB-21654AE6F444@tzi.org> <20585.1634642284@localhost> <3e6ba342-9712-15c3-c0e3-2d3194ff23dc@gmx.net> From: Achim Kraus Message-ID: <7f27fd21-35d9-5e78-3bed-cafc885a837f@gmx.net> Date: Wed, 20 Oct 2021 13:12:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:2tYTUCIR9ShppX188HVqw5KNajY9W2RZItQX5hdQj7oupHXpNdZ b6HV/j68kbcjlEFyAqhcqcy+Ggx3Ou7PDaSbZxwkKBEoXUrpil33zF43YbPUjlV9goT6FlC +AoQAwi+CWdfK1Y7ke4Ehw6F4YFLycFXt7wPh7kUUL0K8nvICVjEgJXGyFhmFUFLYt3pTSu k/9t0GGd9yKdM2fKympKQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:2XWDak6GS3A=:JDa/+414Ym4V+zfh/95bUx 4xIzui84gk4AtkNJJ4bH1mVaztY2Nx8nj8pkNHAU4TwaUHNx0V0avkqK91o6xzZyVLDbTFy7G rAig5wJlEEtO1coLcqL5GdFXhL24wYNk1F9/tyBjM7My2YeFMnYun5C09B9GieBmYlDC10lRU b3rQzNsDr3GnMv1OWTpm4y1nzXq3wY/pMuRK9ZbZD0libMl8SZWM7vPdSTkHp+ct4BBCHibVi btqzJsjv3uj6bE7rrQi95atkrETcMoMP4/e/3VgVGSalkgnY0cXGP/9fosmbcKBaRt2tmzGnF v3p337cmyBGc0bPYYXeE+4HBQzOScoCYUmkikJ87pnh/j+oBR5O6+FNVmu3JyYOZMT9ldlEw5 TpgAB+7nyOoJEUBMIOYEoHJqlZYhYyFNr6a6jbCP2p6rIC44VCqFuvqfjQ8WtvKA6e89xxFCG k1ElJrMYQCt1/4RK4lTMGCQbxntY+Di9hIjLq/vP9XbVPgZv+jfn9r5V9ZHZfGfiu03SYuzDZ 21KDhihsFXidS0jG/bWtAn0YAYmhKk1uFF1xNzo55xp4RsHxIVI5zbnR5PvH1buouERp1FO0j VZuzhRMYpurdeQDiuO5rFwq0M2ZFhoTDZzn/Nwsu404sivR3tIPrhDo6MK6y2o1SEzYOZ66DI BMVbvV8bynSoitaAFROenuyhY9p3lBdIiRvzterWEXg9Geb+KM6jbyx5/YzLy1GharRaJSIef DKCg2Q+XCEga7t2Snln5DjDbdprsQqlZcTeExuQ9J/cVWt9blkOVyRKB+OtfdnWpZv6A5Vl/c 1QepvPYJCjIXN48YMRDsEfL5R68TAkjhe46Z0gtBdQnQSCMkrf+HrRweMyoss2lHU3M3hh/ns TT8kipOygu89higG6rn6FwycBZG+a6O7FBuRHxG/Vsel4LEkkyBuav9hY7WBFYa3CRvIEajvs zVtiFOCd9c9ihy6oKu+WG8ueh+crwfkedH2jpzOlR+mlXvcWW7mK79m+maYRD31+pTdYvqtE3 AEHtlLt1T4IeuIUhd61cNeixq9g4s+26j8Wl+FVdOyKN70FJGjpIHVcvL6ldBkbJYMQywJI/J 5Dpt+RScOlYl30= Archived-At: Subject: Re: [core] time to start the deprecation of CCM_8? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 20 Oct 2021 11:12:54 -0000 Hi Thomas, great! Even though, I would still prefer CCM (maybe additional), because the migration costs for the CCM_8 deployments/implementations will be low. That may be important for the acceptance in relation with CoAP, especially, if the CoAP related analysis will not be done. best regards Achim Am 20.10.21 um 11:42 schrieb Thomas Fossati: > hi Achim, > > On Wed, Oct 20, 2021 at 10:05 AM Achim Kraus wrote: >> but the CCM stuff could be enabled, even CCM8. > > Sure, but sometimes this is a configuration choice that others make > for you and that you can't control. > What I'm saying is -- WRT Michael's desideratum -- GCM may be a better f= it. > >> In my opinion, for the cloud-connectivity, it's more interesting, what >> the big-scaler offers, and not so, what openssl does on default. > > Good point. A quick googling returns these results: > > Amazon IoT, no CCM: > https://docs.aws.amazon.com/iot/latest/developerguide/transport-security= .html > > Azure IoT, no CCM: > https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-tls-support > > Google IoT, no CCM: > https://security.googleblog.com/2015/09/disabling-sslv3-and-rc4.html > > cheers, thanks > From nobody Wed Oct 20 04:25:19 2021 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 774A83A107E for ; Wed, 20 Oct 2021 04:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.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 eJa4ky7XPzNg for ; Wed, 20 Oct 2021 04:25:13 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.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 9776B3A105B for ; Wed, 20 Oct 2021 04:25:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1634729110; bh=xczddgNaw8ixxT7ePciU9uzfN+encdcgyUq/1gK2xIA=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=dXSNRvqA+XTiNvTKuKxRh+c/iRZVxCpBx9uFvS/95ro8L260HYJgTxZe/3a7AYica fZaFA2f8p8whnM+XMpKKXeJKZaV7lwKEZeqfhAmhm4Raz7ROCIfAkEo+8B6I/TxgCe 4PWEmq9OTYqMoKQR4k4b48p7yc8W3gC4/RMhcpiM= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.10] ([5.146.193.130]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1McH9Y-1n8u2E0zIy-00cdrW; Wed, 20 Oct 2021 13:25:10 +0200 To: Thomas Fossati Cc: "core@ietf.org WG" References: <0ce231d7-fe5d-f616-c5ce-9b0ca2a55708@gmx.net> From: Achim Kraus Message-ID: <9c4e21d6-b824-8287-02e4-d8b034a02359@gmx.net> Date: Wed, 20 Oct 2021 13:25:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-AT-frami Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:4aB4mP9ixPS/96mWhQPimiGAcG1qFjMsdTR1JC0b3mAykgIrbwV AJ9Yd8AZNBzPlgrfQ+IWNR0k0Hzr83951udleGbRe/kY5CQd/j3G0X1BdQnfqwXbbDj3uaI ZBaVva7BOsym6I5dEs9biyCd3OYe7xoqpG3wj25T40hmhqOpuQhqkjM2W32G9e8vR2/2viW 0MIXwfYmbfHOvBcK9UIrw== X-UI-Out-Filterresults: notjunk:1;V03:K0:MnCbJtiUX1I=:km6A0VwYJd3IKQkpcCCfHZ eGieTNhRc/xntn/ayElrbZpMslno0WYP58M3nOhJuGNqRbOL3TB8888ksTIwIisZvpS+8E/tl aJxPdqtoBhaBietY6f0EkqYOqJUeYvw+oAPYy94jUf+iXC6Yz7alFf5WGIxRarhSr1zsH8pyo 2u3TXvqjtgx9dU3OidaewbWi3b8qysyyAVD0ACfKumLoSfIVCSox0MG/h3TEplqHOAIyMMkA2 t8EJqT1ETCYrnK7591dW4Y2DqdQ3efBWb2Ls9szCHJp1b4wZuLTdzdiQrO3CW6g1hz2HZGf3S E0HpaB+sUgK3tohkjReEHjS2rZ1mqXzg8gSlGqWUOs6DtlFeOVE7sQH2w4/ieIrYkpFTNXJJ9 XjAcMHBQ5SjycwfUWdKMpKS4RH3GpKDeZ5B5ORv6MXLlIlwyjN8IURy0ZjKBB5iSJzaX3incz ihu9aqSx64o4xER5Cd0BLItxBziEDj60k/iCmGMhtJIkS54cXWrIB5mScxJrMCKcNOMzCqrAV t0PQsNjrDyeH0SQgigvHaPYKj+nDHmk5FQNFfU2e71LUdgxolYNmJSwT7xIvARrCamC7VZpZo G6LrccqCf6U9yDzRmRR9XPOpSZLtgNbBCmJT6lOUvo+OUu/iG0NYWg1o6mZCR/+tuqxXIiPBg fcD27ieUZp07qLyrrMSXOq8Akd8JISIkpEYt/iRwVYiWo/7ItAUf11i2NnCRInWxPe3YoMPfu r2vkfKTu+fQ5n53ZlHXMyg+NLD6N+M7/MAH+ScRhaHs/LBVjzB572ac37SD5CIFj0aIhPLUHO 63c/k3oCqzdY4XL7CbmhXdu87neRo7z9St2f8sDMO/IuAk1VCPg0muQzz6c7ox4er1wjKiDyY HoIskcN59UOaapYfPFNJWFj590dd1fJgYaKxZkX7T1dY6Eeq+2eRcb9diKn/8NAiEUc7TRfT4 KpN55eclrkC72FQI56kErm+KeGBhKqHkza6jmZF9SNAQy/FyyeOLUXhHM5bEknqZgGLa3La2h M8MOvoxP8VdPYH2bJ05x3bKi4hrFUVqef2VkkH2Re73dOLUQkRL3wsAS3UC5acW70Qh1++r9f Cm3knYmfELEEO4= Archived-At: Subject: Re: [core] time to start the deprecation of CCM_8? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 20 Oct 2021 11:25:17 -0000 Hi Thomas, > I don't think so, it's the size of the key (and of the integrity tag) > that is relevant. I'm not that sure about this. (I already wrote, that the amount of papers to read is mixing up.) In "Limits on Authenticated Encryption Use in TLS", 2017, "3 Computing the Bounds" the input length is considered! And again, if 2 bytes are fix, that may be also an issue. best regards Achim From nobody Wed Oct 20 04:33:58 2021 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 584223A0A88 for ; Wed, 20 Oct 2021 04:33:55 -0700 (PDT) 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, SPF_HELO_NONE=0.001, 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 Or9RECVuEwth for ; Wed, 20 Oct 2021 04:33:44 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD7EF3A0AE2 for ; Wed, 20 Oct 2021 04:33:25 -0700 (PDT) Received: from smtpclient.apple (p5089a10c.dip0.t-ipconnect.de [80.137.161.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4HZ7lh6FnNz30Y1; Wed, 20 Oct 2021 13:33:20 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Carsten Bormann In-Reply-To: Date: Wed, 20 Oct 2021 13:33:20 +0200 Cc: Michael Richardson , "core@ietf.org WG" Content-Transfer-Encoding: quoted-printable Message-Id: <166EBE02-113B-4054-9B99-043EC31A68FB@tzi.org> References: <081C80A8-5317-4DB1-BBCB-21654AE6F444@tzi.org> <20585.1634642284@localhost> <4603B5A0-8179-40D7-9335-52D9FD59BAE8@tzi.org> <3B735512-CAAE-433E-BBF1-446088E3FFD2@tzi.org> To: Thomas Fossati X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [core] time to start the deprecation of CCM_8? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 20 Oct 2021 11:33:56 -0000 On 20. Oct 2021, at 11:44, Thomas Fossati wrote: >=20 > Not sure I understand this comment: irrespective of what openssl does, > what other chiphersuite provides 8-byte auth tags? If the requirement > is an 8-byte auth tag version you are left with no other choice than > CCM. Is this your requirement? If we want to replace CCM_8, it would be natural to choose something = that has similar performance characteristics. I can imagine openssl doesn=E2=80=99t have a 64-bit authenticator = option; maybe we need to cough up one. (Or we could leave CCM_8 in place, i.e., deprecate it slightly less.) Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Oct 20 05:03:33 2021 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 EE02D3A00C3; Wed, 20 Oct 2021 05:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=seicmu.onmicrosoft.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 6POoKQEOKQIu; Wed, 20 Oct 2021 05:03:22 -0700 (PDT) Received: from USG02-BN3-obe.outbound.protection.office365.us (mail-bn3usg02on0121.outbound.protection.office365.us [23.103.208.121]) (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 103FC3A0063; Wed, 20 Oct 2021 05:03:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=AbP2Q1Q8u9oodJdzFXQhJvHFb4r20/vSXmnYo3do8d8P+or+IFJ2dxaSLIJ5PKi2jZoYGbOXFfXrarxjpQx2GfH/FXL4el1x9L2AkTFIJN6R1jR8IlPm2GQld2h7AABZV2XMKt7R4w2yeISnaxP8ijHS+D1PNH3AOF57j8dDPRIUMFnkz3q1a7gHG5CGpifIN5lCLcvLFr8b8tcsJ3UsWD6Qho7Ax6dBZKdJ3YzNtxQxUx77uMWzMFpk5e3Z2aeaEUna+6febLe9uFuDpQaKNGhJY4Y6G3vUfqVBLrP3auxYsVuK+3oLcUdytb6R9WlhbN7qX1QRXcI9tIyCVRhi+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector5401; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zqbAwzKukuNb2mPqArYBw6Huu8s45zrpglMZNdfaFmk=; b=u0j+ClxmI+o4H6pOXFJLbonfL+COcPlw6SP41bjN53PvD7Edtb/XyZ7hOTr78PLpu3t02pnH90qrJC02PXL8BTeQM4Q3Q6DVzG/8pyROn1qpI5yAwTNc1/fA9v219vjE2XngLwxTndHmx+m/N9SikO8TrQcr574Kh+4G9U491dmSl+DTmg28pHAhYsQPL92d5dC0pMaPFjeoHhzFzP5sSo6MTlZ9jLcXQjR2mJwNAksPb2dWXikn98xqc7rSpfhP/snoD/U3IBbwSfgiaM+IespShXfWH/4sdG55QOhe7aRmX8hWV96c2okLNRSYCofEMMvRYADdTzAg0+rhZbgk7g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cert.org; dmarc=pass action=none header.from=cert.org; dkim=pass header.d=cert.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seicmu.onmicrosoft.com; s=selector1-seicmu-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zqbAwzKukuNb2mPqArYBw6Huu8s45zrpglMZNdfaFmk=; b=ACxB7nLoWsPwVLN1tSXoErQkWcs+wUK+O+lncOViO+52KzT+54iBAoz1kK2m65YKkTTDtvk9faooCX88OvVti8TI8f/ZMGinZTW8vrHJzB1rqITESVF4u6y5cSsLydlt+iH7h/vVx3FHjRTTREY315GmQRnUOppYlnBzUj/6kI4= Received: from BN1P110MB0939.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:134::12) by BN1P110MB0707.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:135::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.16; Wed, 20 Oct 2021 12:03:11 +0000 Received: from BN1P110MB0939.NAMP110.PROD.OUTLOOK.COM ([fe80::4463:48d1:9769:567f]) by BN1P110MB0939.NAMP110.PROD.OUTLOOK.COM ([fe80::4463:48d1:9769:567f%6]) with mapi id 15.20.4608.018; Wed, 20 Oct 2021 12:03:10 +0000 From: Roman Danyliw To: Carsten Bormann CC: Jaime Jimenez , "draft-ietf-core-senml-data-ct@ietf.org" , "core-chairs@ietf.org" , The IESG , "core@ietf.org WG" Thread-Topic: Roman Danyliw's No Objection on draft-ietf-core-senml-data-ct-05: (with COMMENT) Thread-Index: AQHXrMGRIdxrbjUCQEeFiS9xGxPw8Kvb0NYAgAAqEEA= Date: Wed, 20 Oct 2021 12:03:10 +0000 Message-ID: References: <163199251278.32143.9125277138231739491@ietfa.amsl.com> <546C3C20-0928-4D76-99D3-B73824E0D811@tzi.org> In-Reply-To: <546C3C20-0928-4D76-99D3-B73824E0D811@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=cert.org; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0148c1d5-d738-49ff-5e29-08d993c1963f x-ms-traffictypediagnostic: BN1P110MB0707: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: QeCdKSr3+YtppH2yCO5aJCIaGDj+7DRi0LVy/jFAzYZnXWQTk5as1PV+Yanap6IFuXXVu37+CQmdxVBuv4OVOYohSd+jzmhv2TiUHdKGTwplr68r3zYpbvWUOoRaFJRuoAFMucwCK3npJSE5x82SOg+5znP6XM6Bp+bRZDNxMVsAJui5w3vaDYHVhctTiimPqSQsymrqDASpE6T4ZbVmsonEn79fftj4JB5sBktA+t+I6qcIZ9DmQ6MbAQ7AqDZzZd1yeYUQkhuHDr7sntvU4+gf/kihKjiMrwUhx1riQ10fot3FafuRqv3IxeIenJn3Um76iBpOlw9NBga7HGFjYdXgdCPN34HMxKR759hx98L6WrTzAxezp8CVWPzWEeQKrbGs6SroPrSzFa/+NUvY+lgcmn8ETiSrDMpE1gVMXThZTJscjQS0k7YWIrs/s2dFUazz+oKe+xTOwOASglp440lFQLwhFw62v/VEfX8SHbvVB6Kuwa3V7sVDgrLI9VEWWJsJKhCl7ur3hBU9lYf9n9oMMI4XdGGfR8JpPfNO+wgFZV/72VtRjbU6pS8QYn6w1wKdp4k+uRt1WXKyNJtyG9SgCkNt8RWwiHBzJS1hEsGqha1q2qaNe1am7efnP2tRZ6pLAMNl+54o+1t2vVHggBgYm4vGeeoj2om/gAq0IaCHXIt7CAb/TpqwexYVmTAbigkSO8D1d4oSFSFrS/NMMw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN1P110MB0939.NAMP110.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(86362001)(38070700005)(53546011)(71200400001)(66476007)(26005)(54906003)(2906002)(83380400001)(6506007)(8936002)(76116006)(55016002)(66946007)(6916009)(186003)(82960400001)(9686003)(8676002)(4326008)(122000001)(33656002)(7696005)(966005)(498600001)(66446008)(5660300002)(38100700002)(64756008)(4001150100001)(52536014)(66556008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: KJ+ckxD8/qMzId5BZpi+u0zCOqId0yr6560kAn2FDgJs+PSG9cmeu3SuLd/MM2aCuNnQbNnl1fC2ZTfwl175qy+B3pnOUqkeCCDed8V0odHBbJeKEJMP2oXFT3iXBhg0R+CWSwQgte/wlalgRejbwrPL44A4ydGUNGHDxZhuNbIsefjg9DQdUOxvXTvZ7DbO5f79Iw7X624gn9qLmVME7lR+grN+AMyNH6TkTsCuWO8SNrzYvfWg341/5nK4UZo7Tggda7G0/5/iFv4tiQy+rzVKqQ2evGMs+xWeEjTeR/jGA39SzcwRvoz+0M9W5eVYfDvBvEaFq1xTN79wj7ZB0uVH7Aa6kASw6kFdopx+GnrrqVSoW9GhO+qqu1eu9hglhuKIptwsSs1ZiPS7RtY6KatXF8uAZpOP21CU7nvSzgoCXdFcAodIwxwsDd+Th55XlvWJ3xmFo4Fhd2s8LCoi3FRyAUoHMKVibu8TME9xGL80KtgrI37VLy7zpmKsq0e5Ke4iISgJFCThz9WpYbMzL2dXNpFiJ+eMhaN9wsP2JSCneVwFU1M3jXcWafnbZNKh21M4PkD59WVo0YkEBVAuHYA2Xq20+Vcz3Pz2QS/HdvLbjuALuPCXAsUdMfWW/MeHiGVmJnLPCjeBUIAJEyIrFYSybaREPAak6Jvg+1d+FnHgSQOZZOqEebkSDlo9o2dBdwTWjjZAPnxL3YDac/EobCwyEoaU0SBlBzPHTU0FJS0= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: cert.org X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN1P110MB0939.NAMP110.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 0148c1d5-d738-49ff-5e29-08d993c1963f X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2021 12:03:10.6223 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 95a9dce2-04f2-4043-995d-1ec3861911c6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1P110MB0707 Archived-At: Subject: Re: [core] Roman Danyliw's No Objection on draft-ietf-core-senml-data-ct-05: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 20 Oct 2021 12:03:30 -0000 SGkgQ2Fyc3RlbiENCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpZXNn IDxpZXNnLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBDYXJzdGVuIEJvcm1hbm4NCj4g U2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDIwLCAyMDIxIDU6MzEgQU0NCj4gVG86IFJvbWFuIERh bnlsaXcgPHJkZEBjZXJ0Lm9yZz4NCj4gQ2M6IEphaW1lIEppbWVuZXogPGphaW1lQGlraS5maT47 IGRyYWZ0LWlldGYtY29yZS1zZW5tbC1kYXRhLWN0QGlldGYub3JnOyBjb3JlLQ0KPiBjaGFpcnNA aWV0Zi5vcmc7IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPjsgY29yZUBpZXRmLm9yZyBXRyA8Y29y ZUBpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFJvbWFuIERhbnlsaXcncyBObyBPYmplY3Rpb24g b24gZHJhZnQtaWV0Zi1jb3JlLXNlbm1sLWRhdGEtY3QtMDU6DQo+ICh3aXRoIENPTU1FTlQpDQo+ IA0KPiBIaSBSb21hbiwNCj4gDQo+IEZyYW5jZXNjYSByZW1pbmRlZCBtZSBuZXZlciByZXBsaWVk IHRvIHlvdXIgY29tbWVudHMuDQo+IFNvcnJ5IGFib3V0IHRoYXQuDQo+IA0KPiA+IE9uIDIwMjEt MDktMTgsIGF0IDIxOjE1LCBSb21hbiBEYW55bGl3IHZpYSBEYXRhdHJhY2tlciA8bm9yZXBseUBp ZXRmLm9yZz4NCj4gd3JvdGU6DQo+IFvigKZdDQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IENPTU1F TlQ6DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+DQo+ID4gSXMgdGhlcmUgYW55IGdlbmVyaWMgZ3Vp ZGFuY2UgdG8gcHJvdmlkZSBvbiBleHBlY3RlZCBlcnJvciBoYW5kbGluZyBiZWhhdmlvcg0KPiBp ZjoNCj4gPg0KPiA+IC0tIGN0IChvciBiY3QpIGNvbnRhaW5zIGEgbnVtYmVyIG91dHNpZGUgb2Yg dGhlIDAtNjU1MzUgcmFuZ2UsIG9yIGFuDQo+ID4gdW5yZWdpc3RlcmVkIHZhbHVlIHBlciB0aGUg Q29BUCBDb250ZW50LUZvcm1hdHM/DQo+ID4NCj4gPiAtLSBjdCAob3IgYmN0KSBjb250YWlucyBh IHRleHQgdmFsdWUgdGhhdCBpcyBub3QgYSByZWdpc3RlcmVkDQo+ID4gQ29udGVudC1Gb3JtYXQt U3RyaW5nPw0KPiA+DQo+ID4gLS0gY3QgKG9yIGJjdCkgY29udGFpbnMgYSB2YWxpZCBDb250ZW50 LUZvcm1hdC1TdHJpbmcsIGJ1dCBhbg0KPiA+IHVucmVnaXN0ZXJlZCBDb250ZW50LUZvcm1hdD8N Cj4gPg0KPiA+IE9yIGlzIHRoaXMgYXBwbGljYXRpb24gc3BlY2lmaWM/DQo+IA0KPiBCYXNlZCBv biB0aGUgZGlzY3Vzc2lvbiBhdCB0aGUgQ29SRSBWaXJ0dWFsIGludGVyaW0gLSAyMDIxLTEwLTEz IFsxXSwgaW4gLTA2IHdlDQo+IGFjdHVhbGx5IGRlY2lkZWQgdG8gYW5zd2VyIHRoZSBxdWVzdGlv biB5b3UgZGlkbuKAmXQgYXNrLCBhbmQgYWRkZWQgYSBzdWJzZWN0aW9uDQo+IFsyXToNCj4gDQo+ ICsjIyBFdm9sdXRpb24NCj4gKw0KPiArQXMgd2l0aCBTZW5NTCBpbiBnZW5lcmFsLCB0aGVyZSBp cyBubyBleHBlY3RhdGlvbiB0aGF0IHRoZSBjcmVhdG9yIG9mIGENCj4gK1Nlbk1MIHBhY2sga25v d3MgKG9yIGhhcyBuZWdvdGlhdGVkIHdpdGgpIHRoZSBjb25zdW1lciBvZiB0aGF0IHBhY2ssDQo+ ICt3aGljaCBtYXkgYmUgdmVyeSByZW1vdGUgaW4gc3BhY2UgYW5kIHBhcnRpY3VsYXJseSBpbiB0 aW1lLg0KPiArVGhpcyBtZWFucyB0aGF0IHRoZSBTZW5NTCBjcmVhdG9yIGhhcyBubyB3YXkgdG8g a25vdyB3aGV0aGVyIHRoZQ0KPiArY29uc3VtZXIga25vd3M6DQo+ICsNCj4gKy0gZWFjaCBzcGVj aWZpYyBtZWRpYS10eXBlIG5hbWUgdXNlZA0KPiArLSBlYWNoIHBhcmFtZXRlciBhbmQgZWFjaCBw YXJhbWV0ZXIgdmFsdWUgdXNlZA0KPiArLSBlYWNoIGNvbnRlbnQtY29kaW5nIGluIHVzZQ0KPiAr LSBlYWNoIGNvbnRlbnQtZm9ybWF0IG51bWJlciBpbiB1c2UgZm9yIGEgY29tYmluYXRpb24gb2Yg dGhlc2UNCj4gKw0KPiArV2hhdCBTZW5NTCwgYXMgd2VsbCBhcyB0aGUgbmV3IGZpZWxkcyBkZWZp bmVkIGhlcmUsIGd1YXJhbnRlZXMgaXMgdGhhdA0KPiArYSByZWNpcGllbnQgaW1wbGVtZW50YXRp b24gKmtub3dzKiB3aGVuIGl0IG5lZWRzIHRvIGJlIHVwZGF0ZWQgdG8NCj4gK3VuZGVyc3RhbmQg dGhlc2UgZmllbGQgdmFsdWVzIGFuZCB0aGUgdmFsdWVzIGNvbnRyb2xsZWQgYnkgdGhlbTsNCj4g K3JlZ2lzdHJpZXMgYXJlIHVzZWQgdG8gZXZvbHZlIHRoZXNlIG5hbWUgc3BhY2VzIGluIGEgY29u dHJvbGxlZCB3YXkuDQo+ICtTZW5NTCBwYWNrcyBjYW4gYmUgcHJvY2Vzc2VkIGJ5IGEgY29uc3Vt ZXIgd2hpbGUgbm90IHVuZGVyc3RhbmRpbmcgYWxsDQo+ICt0aGUgaW5mb3JtYXRpb24gaW4gdGhl bSwgYW5kIGluZm9ybWF0aW9uIGNhbiBnZW5lcmFsbHkgYmUgcHJlc2VydmVkIGluDQo+ICt0aGlz IHByb2Nlc3Npbmcgc3VjaCB0aGF0IGl0IGlzIHVzZWZ1bCBmb3IgZnVydGhlciBjb25zdW1lcnMu DQo+IA0KPiBJIGhvcGUgdGhpcywgaW5kaXJlY3RseSwgZG9lcyBhbnN3ZXIgeW91ciBxdWVzdGlv biwgYXMgZXZvbHV0aW9uIGNhbiBtYWtlIGl0IGxvb2sNCj4gbGlrZSBhIGNyZWF0b3IgdXNlZCB1 bnJlZ2lzdGVyZWQgdmFsdWVzICh0aGF0IHRoZSBjb25zdW1lciBqdXN0IGhhc27igJl0IGhlYXJk DQo+IGFib3V0IHlldCksIGFuZCB0aGF0IG5lZWRzIHRvIGJlIGhhbmRsZWQgZXhhY3RseSB0aGUg c2FtZSB3YXkuDQo+IA0KPiAoVGhlIGNvbnRlbnQtZm9ybWF0IGJlaW5nIG91dCBvZiByYW5nZSBp cyB0aGUgb25seSBlcnJvciB0aGF0IGNhbiBiZSByZWxpYWJseQ0KPiBkZXRlY3RlZCBieSBhIGNv bnN1bWVyIHRoZSB3cml0ZXIgb2Ygd2hpY2ggZGlkbuKAmXQgaGF2ZSBhIGNyeXN0YWwgYmFsbC4N Cj4gSSB0aGluayBhdCBzb21lIHBvaW50IHdl4oCZbGwgd3JpdGUgYW4gaW5mb3JtYXRpdmUgZG9j dW1lbnQgYWJvdXQgU2VuTUwgYmVzdA0KPiBwcmFjdGljZXMsIGFuZCB0aGF0IHdpbGwgYWxzbyBj b250YWluIHNvbWUgaGludHMgYWJvdXQgZXJyb3IgaGFuZGxpbmcuDQo+IEJ1dCBwdXR0aW5nIHRo aXMgaGVyZSB3b3VsZCBiZSBnb2luZyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGUgc3BlY2lmaWNh dGlvbiBvZg0KPiB0aGlzIHNpbmdsZSBwYWlyIG9mIGZpZWxkcy4pDQoNClRoaXMgZXhwbGFuYXRv cnkgdGV4dCBpcyBoZWxwZnVsIG9uIGxheWluZyBvdXQgdGhlIGV4cGVjdGF0aW9ucyBvZiB0aGUg aW52b2x2ZWQgcGFydGllcy4gIFRoYW5rcyBmb3IgY2xhcmlmeWluZy4NCg0KQ29uc2lkZXIgbXkg Q09NTUVOVCByZXNvbHZlZC4NCg0KUm9tYW4NCg0KPiBHcsO8w59lLCBDYXJzdGVuDQo+IA0KPiBb MV06IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL21pbnV0ZXMtaW50ZXJpbS0yMDIx LWNvcmUtMTItDQo+IDIwMjExMDEzMTYwMC8NCj4gWzJdOiBodHRwczovL2dpdGh1Yi5jb20vY29y ZS13Zy9zZW5tbC1kYXRhLWN0L2NvbW1pdC8wYTU3OTUyIGFuZA0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9hcmNoaXZlL2lkL2RyYWZ0LWlldGYtY29yZS1zZW5tbC1kYXRhLWN0LTA2Lmh0bWwjbmFt ZS0NCj4gZXZvbHV0aW9uDQoNCg== From nobody Wed Oct 20 05:06:34 2021 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 6416B3A00B2 for ; Wed, 20 Oct 2021 05:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 uGHjug7J_MI7 for ; Wed, 20 Oct 2021 05:06:28 -0700 (PDT) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 499A63A00C3 for ; Wed, 20 Oct 2021 05:06:28 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id p16so14621220lfa.2 for ; Wed, 20 Oct 2021 05:06:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=M5LlickXm8WFiJM5UjGQsYb25ZjQ2ERCBckHZAAEK6s=; b=Rhub3yXNdxlfe0yeZcrAaGGY04oy5ABNOP9Y0lbANQTtF/hOwmTurgtqD+xv5zDZs/ xO+ALa7JC2hh0NQ5YrAZzp9FAq7FSsoSZVQ4bnyZUuBxfnArmQjPqfmCPlulusOsXvWe xHEq68SSgK29t1viSQJRkl/sx1F0xi/UGeCBEsrVS1J1fWB3Cw0G90TatiDDOCGmNT/X 1EkjmfQFzcqZwz7xjfEJZam4foc6HssdI8/5Pd4qFBwmk3qVlqTuMydyPwpwzhjRdmoo TX60KGCTDwkc7GiHrq6L/cLY0x17WVj+xJbFIugKakASIUptlEWh6vMd+oXZZqMYPWWn RnGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=M5LlickXm8WFiJM5UjGQsYb25ZjQ2ERCBckHZAAEK6s=; b=UGM/XyZmq0nUu4xPXErPWLI8FilTMde3nV1ageHTNL1UZgl4/Re1ij0dzHmmYzvXKy 7Tol7RqZXzllfY498sMAqWs4PY43f7PT0lAQvuIxbziUAZQaIjeJM1vN5l3Ss/UbwYWn W2svqGQ5yVwn3gO+i5ZmLqiKtJYhOR2ONG804zia68bZgd60RNiewuSoU0YRJFqtj1NY lhqNmLs9y8+VXX4WORtJUorfXRHQ593H5XE9CrIkFa/+vmwJpOkrjqJ3WynnuozRW581 57Pd6C6PYUtuLUmTpqMA5TYq68Dq7YD91McCFFdkKlWqMV/2hKomQiOVveOIdG2CzGVy mLdA== X-Gm-Message-State: AOAM532DfFd96t0hEr7s8rf1FWwMqoSqVJ6HppnSm5h1g/7xU6DFjI3r 91LWPnW3CUd7E1DPjCgfaMO8IX+3xaNWqU5jrImmL/a9VOE= X-Google-Smtp-Source: ABdhPJx7PcwsQ2GebWnsi5CP+TC5t0xsUNojDuXtSJJkloSS3E8DpB8DbUsaJb6ADmju8LI14uWZW1DrJzjYoU/jevQ= X-Received: by 2002:ac2:443b:: with SMTP id w27mr11807108lfl.63.1634731586456; Wed, 20 Oct 2021 05:06:26 -0700 (PDT) MIME-Version: 1.0 References: <0ce231d7-fe5d-f616-c5ce-9b0ca2a55708@gmx.net> <9c4e21d6-b824-8287-02e4-d8b034a02359@gmx.net> In-Reply-To: <9c4e21d6-b824-8287-02e4-d8b034a02359@gmx.net> From: Thomas Fossati Date: Wed, 20 Oct 2021 13:06:15 +0100 Message-ID: To: Achim Kraus Cc: "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [core] time to start the deprecation of CCM_8? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 20 Oct 2021 12:06:32 -0000 hi Achim! On Wed, Oct 20, 2021 at 12:25 PM Achim Kraus wrote: > > I don't think so, it's the size of the key (and of the integrity tag) that is relevant. > I'm not that sure about this. > (I already wrote, that the amount of papers to read is mixing up.) > > In "Limits on Authenticated Encryption Use in TLS", 2017, > "3 Computing the Bounds" the input length is considered! Correct, but in both (1) and (5) (integrity and confidentiality, respectively), \sigma and \ell are in the numerator, so the smaller the better. > And again, if 2 bytes are fix, that may be also an issue. That shouldn't be an issue since all modern ciphers are (supposed to be) KPA-resistant. From nobody Wed Oct 20 05:09:01 2021 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 B44523A00D2 for ; Wed, 20 Oct 2021 05:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 BVZ5VhzyUMWd for ; Wed, 20 Oct 2021 05:08:58 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 EF0973A00C3 for ; Wed, 20 Oct 2021 05:08:57 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id e19so12086788ljk.12 for ; Wed, 20 Oct 2021 05:08:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dvGnKgvjT4Ucg0Vb5cSFyG9W1dMkhnC49QPwPpncf9g=; b=UiDK1/ASAFhWhtpx+EoOJ8rqda6VUpU+1bmEh+YKPCHHpyKdlRpvllr8ivst7zsqbK tMRac5LakzPQQWOcFCvP/0AUw0603VnC4/xE+j+xa0AZ4sB67gnnMbsn+uyzDutY3lAy OX9Zy3IxTGkJST88TuQiL2rafyqMAYYIqh5CYFESYR3tF07towzoESy4j2aXoeVsoPa5 KWAaLOaA1GeIEUUyjXZUbTsxL72JmwYPWDtaf4ESm/0q7/dBsaMfikZxWrKOibeV2G95 ToUezJSMZCMY4T61LxWl1IHpF5illiXzD8gpXUqQahY437T8FX1d11HnS3jpux3gCzRp 2lOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dvGnKgvjT4Ucg0Vb5cSFyG9W1dMkhnC49QPwPpncf9g=; b=Z+zsgbMCrTa59y25cWXu0AYO42TRC/A+E/jfLBwOu7eeArH+qTkoJ54psanhV3Gpdq nL9QfZ4FfPIM+HjNNagdo5lD32/0IEDssCP8QRGsY+wdoIHCGrsNX7p3GdXMvruQ4War 2HjmxonO0HgeHj1WOPPboar81yU2E5ceMVIgqm/yt2vUlZJnPUA7zAJdss81pCyjBUab /ehVFcomkhgMd7TfAixlWpBUwx76rjhImjeT/XAIe+vd+b5Mi3azbw8qJSSsSvimZvOY n8jF9AKQv/r293YzLjhBDU5TgkIUt9BESML1e93evfU2YHPUCjWmQmIROJYwjRNyr4qg 4i4A== X-Gm-Message-State: AOAM530JIj3St3LP3IPjMCP8Ma/Cf32ciiH6+JjfSiMBNSn4GiM6A1CU 9SEYGvWusoKA8reoMxTSRKK4ryg9IyQ4Y/BRGJMuCjzH X-Google-Smtp-Source: ABdhPJxg10MUbL8GcO95hoPIeFRs9y34UQ3xo9ZHUctdDeRHiNeyJWi9/JcNQcDPZAlY6OIaK2vk5ttlGvJq8SeOTlk= X-Received: by 2002:a2e:b88f:: with SMTP id r15mr11724011ljp.474.1634731736003; Wed, 20 Oct 2021 05:08:56 -0700 (PDT) MIME-Version: 1.0 References: <081C80A8-5317-4DB1-BBCB-21654AE6F444@tzi.org> <20585.1634642284@localhost> <3e6ba342-9712-15c3-c0e3-2d3194ff23dc@gmx.net> <7f27fd21-35d9-5e78-3bed-cafc885a837f@gmx.net> In-Reply-To: <7f27fd21-35d9-5e78-3bed-cafc885a837f@gmx.net> From: Thomas Fossati Date: Wed, 20 Oct 2021 13:08:45 +0100 Message-ID: To: Achim Kraus Cc: Michael Richardson , "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [core] time to start the deprecation of CCM_8? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 20 Oct 2021 12:09:00 -0000 On Wed, Oct 20, 2021 at 12:12 PM Achim Kraus wrote: > Even though, I would still prefer CCM (maybe additional), because the > migration costs for the CCM_8 deployments/implementations will be low. The smoothness of the upgrade path here is unquestionable :-) From nobody Wed Oct 20 07:36:30 2021 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 966923A00B2 for ; Wed, 20 Oct 2021 07:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 J9ctSp5YTZ4z for ; Wed, 20 Oct 2021 07:36:22 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 9C2653A040A for ; Wed, 20 Oct 2021 07:36:03 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id n7so12982741ljp.5 for ; Wed, 20 Oct 2021 07:36:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=E+NmmmjIHjw2Eh6x8/jF8R2rcF7GmUlMhweVMK5t7VY=; b=CPeQYOkTWqXo3q4D6/Md+pTnC1aO6uak2XnwFfDYrdTWts/CeARq5OhTVGreTt1Ota plO5ws9H0V/fLMQHePDI1EHeyeFbIJbwOxJQGBviLccjoge3mE4SZ05QFoHJLMdSYJI/ 8RdhfX61hYObv6J5U81vc2O5gjePwVp5rLrDfb5wDGaMf9NPtxohFTM7vU9/NgbQoIfM zxEvRXAJgMhgoFsrYutti+Id1fE+9J2Kak+tzXP9CSTy51w2KivvO+sbjKaxHSkWnZsr vymCVOLC6T5phVgyI4PF7FskbM5X+LWrr3YTQNmv2CgkUWrVYKJ4WY3lUDlf7Nif5HBJ cBBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=E+NmmmjIHjw2Eh6x8/jF8R2rcF7GmUlMhweVMK5t7VY=; b=tb8UzU8O483kdOko7KC8gyXZusJ+5ehAHJMWqqG7GgYoZbt4AVAYpx2RZ6KVgztYFN wOcuxUBqcB0rvNGwWR5e1WNhOb5jD0U+NUBWms1LFKwpuhkCwyvofk97oDiP4jEo+9Uq SkRLPkT/eB8AlEdUxL9LTXC0irbqISr1YOqfPMriJZKkbR22NUaLoeKUmDmwWJIpH553 Ap9tJuASGr0sN/EAg/VXMnM7aWS6NNKVQw9HFPUEf4HfRYQ4fQOK3uIl2oRDWHq/POhl oDkMur50STq1rr1fHxUqYtEFi3193dPQf5qd5zSBtH7u3RKcznFxwwNg6TdB/UUHOXhD ljfQ== X-Gm-Message-State: AOAM531X96OsTB250rzh8HnXWbfvwk/C4XFghZ8aw7frPpLLzwPzVGPB v6rqjl3pbcLdfBN4IsMDP2PMqq0WSZU0KAglhwo= X-Google-Smtp-Source: ABdhPJxsPSHz1dXu1JI2Hcrnf6E9oII6Ks9gBeJOeja1zEgKGy6vi/HSXyxaDf1nrCgyy/mNbrtEf7HnpQ605Kwv+Eg= X-Received: by 2002:a2e:a713:: with SMTP id s19mr32510lje.492.1634740561107; Wed, 20 Oct 2021 07:36:01 -0700 (PDT) MIME-Version: 1.0 References: <081C80A8-5317-4DB1-BBCB-21654AE6F444@tzi.org> <20585.1634642284@localhost> <4603B5A0-8179-40D7-9335-52D9FD59BAE8@tzi.org> <3B735512-CAAE-433E-BBF1-446088E3FFD2@tzi.org> <166EBE02-113B-4054-9B99-043EC31A68FB@tzi.org> In-Reply-To: <166EBE02-113B-4054-9B99-043EC31A68FB@tzi.org> From: Thomas Fossati Date: Wed, 20 Oct 2021 15:35:49 +0100 Message-ID: To: Carsten Bormann Cc: Michael Richardson , "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] time to start the deprecation of CCM_8? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 20 Oct 2021 14:36:28 -0000 On Wed, Oct 20, 2021 at 1:41 PM Carsten Bormann wrote: > On 20. Oct 2021, at 11:44, Thomas Fossati wrote: > > > > Not sure I understand this comment: irrespective of what openssl does, > > what other chiphersuite provides 8-byte auth tags? If the requirement > > is an 8-byte auth tag version you are left with no other choice than > > CCM. Is this your requirement? > > If we want to replace CCM_8, it would be natural to choose something that= has similar performance characteristics. By performance characteristic I assume you refer to the wire image size, correct? If so, that's exactly the problem: the small tag size (which is the major factor in the size reduction) is what makes CCM_8 a bad choice unless ${insert_long_and_complicated_list_of_considerations}. However, I strongly suspect we'd end up in a similar situation with regards to the integrity bounds if we hypothetically came up with a ciphersuite based on a different primitive and/or mode but sporting similarly sized auth tags. So ... (continues below) > I can imagine openssl doesn=E2=80=99t have a 64-bit authenticator option;= maybe we need to cough up one. (I guess s/openssl/TLS/ ?) ... if you mean defining a new XYZ_8 ciphersuite I'd rather stay with CCM_8 since the analysis is already done and implementations exist. > (Or we could leave CCM_8 in place, i.e., deprecate it slightly less.) By "deprecating slightly less" what do you mean exactly? Is it: * MAY CCM_8 if ... instead of * SHOULD NOT CCM_8 unless ... and * MUST/SHOULD XYZ ? --=20 Thomas From nobody Wed Oct 20 07:46:44 2021 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 5D16E3A040A for ; Wed, 20 Oct 2021 07:46:41 -0700 (PDT) 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, SPF_HELO_NONE=0.001, 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 RJozvS7OAaxh for ; Wed, 20 Oct 2021 07:46:34 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BDA03A00D2 for ; Wed, 20 Oct 2021 07:46:34 -0700 (PDT) Received: from [192.168.217.118] (p5089a10c.dip0.t-ipconnect.de [80.137.161.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4HZD2Z3HZwz30N5; Wed, 20 Oct 2021 16:46:30 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: Date: Wed, 20 Oct 2021 16:46:30 +0200 Cc: Michael Richardson , "core@ietf.org WG" X-Mao-Original-Outgoing-Id: 656433989.916077-87d7b97a28591f6336f156d058623d54 Content-Transfer-Encoding: quoted-printable Message-Id: <569437DE-A7A4-497F-8427-627A7E137F92@tzi.org> References: <081C80A8-5317-4DB1-BBCB-21654AE6F444@tzi.org> <20585.1634642284@localhost> <4603B5A0-8179-40D7-9335-52D9FD59BAE8@tzi.org> <3B735512-CAAE-433E-BBF1-446088E3FFD2@tzi.org> <166EBE02-113B-4054-9B99-043EC31A68FB@tzi.org> To: Thomas Fossati X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] time to start the deprecation of CCM_8? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 20 Oct 2021 14:46:42 -0000 On 2021-10-20, at 16:35, Thomas Fossati wrote: >=20 > On Wed, Oct 20, 2021 at 1:41 PM Carsten Bormann wrote: >> On 20. Oct 2021, at 11:44, Thomas Fossati wrote: >>>=20 >>> Not sure I understand this comment: irrespective of what openssl = does, >>> what other chiphersuite provides 8-byte auth tags? If the = requirement >>> is an 8-byte auth tag version you are left with no other choice than >>> CCM. Is this your requirement? >>=20 >> If we want to replace CCM_8, it would be natural to choose something = that has similar performance characteristics. >=20 > By performance characteristic I assume you refer to the wire image > size, correct? If so, that's exactly the problem: the small tag size > (which is the major factor in the size reduction) is what makes CCM_8 > a bad choice unless > ${insert_long_and_complicated_list_of_considerations}. However, I > strongly suspect we'd end up in a similar situation with regards to > the integrity bounds if we hypothetically came up with a ciphersuite > based on a different primitive and/or mode but sporting similarly > sized auth tags. So ... (continues below) The NIST document that was earlier referenced in this thread does = deprecated 32-bit tags (no wonder), but does leave room for 64-bit tags. So I was assuming they are still in the realm of consideration. >> I can imagine openssl doesn=E2=80=99t have a 64-bit authenticator = option; maybe we need to cough up one. >=20 > (I guess s/openssl/TLS/ ?) >=20 > ... if you mean defining a new XYZ_8 ciphersuite I'd rather stay with > CCM_8 since the analysis is already done and implementations exist. Which works for me :-) I=E2=80=99d like to have John=E2=80=99s numbers written up somewhere so = we can point to the usage limitations. >> (Or we could leave CCM_8 in place, i.e., deprecate it slightly less.) >=20 > By "deprecating slightly less" what do you mean exactly? Is it: > * MAY CCM_8 if ... > instead of > * SHOULD NOT CCM_8 unless ... > and > * MUST/SHOULD XYZ I used wishy-washy words because I=E2=80=99m not sure of the language = either. Instead of carefully selecting a word of deprecation, I think we should = be explicit about the remaining area of application. We can then put in = a strong word for applications outside that boundary. * MUST NOT be used with manually keyed environments * SHOULD only be used where the performance difference between 8-byte = and 16-byte tags is a deciding factor in the viability of the = application, and where the somewhat increased risk (see table 1) is = acceptable. * MUST be used with a mechanism that keeps visibility over whether the = usage limits are being reached. (Well, 1 follows from 3, but better be explicit.) Insert your requirements (and table 1) here... Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Oct 21 08:24:16 2021 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 7A3D03A17D2; Thu, 21 Oct 2021 08:23:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Murray Kucherawy via Datatracker To: "The IESG" Cc: draft-ietf-core-senml-data-ct@ietf.org, core-chairs@ietf.org, core@ietf.org, Jaime Jimenez X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Murray Kucherawy Message-ID: <163482979947.30858.13453750155375195808@ietfa.amsl.com> Date: Thu, 21 Oct 2021 08:23:19 -0700 Archived-At: Subject: [core] Murray Kucherawy's No Objection on draft-ietf-core-senml-data-ct-06: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2021 15:23:20 -0000 Murray Kucherawy has entered the following ballot position for draft-ietf-core-senml-data-ct-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-senml-data-ct/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to Bron Gondwana for the ARTART review. From nobody Thu Oct 21 09:56:43 2021 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 B80963A0817; Thu, 21 Oct 2021 09:56:38 -0700 (PDT) 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: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <163483539870.30570.12325797196227400420@ietfa.amsl.com> Date: Thu, 21 Oct 2021 09:56:38 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-senml-data-ct-07.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2021 16:56:39 -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 : SenML Data Value Content-Format Indication Authors : Ari Keränen Carsten Bormann Filename : draft-ietf-core-senml-data-ct-07.txt Pages : 11 Date : 2021-10-21 Abstract: The Sensor Measurement Lists (SenML) media type supports multiple types of values, from numbers to text strings and arbitrary binary data values. In order to facilitate processing of binary data values, this document specifies a pair of new SenML fields for indicating the content format of those binary data values, i.e., their Internet media type including parameters as well as any content codings applied. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-senml-data-ct/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-core-senml-data-ct-07.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-senml-data-ct-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 22 09:17:23 2021 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 C28AB3A10E0 for ; Fri, 22 Oct 2021 09:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, 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 VWPthhkW8TfO for ; Fri, 22 Oct 2021 09:17:15 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D08B3A10E2 for ; Fri, 22 Oct 2021 09:17:15 -0700 (PDT) Received: from fraeml707-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HbTtb2w3yz67sQR for ; Sat, 23 Oct 2021 00:13:59 +0800 (CST) Received: from kwepeml500004.china.huawei.com (7.221.188.141) by fraeml707-chm.china.huawei.com (10.206.15.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Fri, 22 Oct 2021 18:17:06 +0200 Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by kwepeml500004.china.huawei.com (7.221.188.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Sat, 23 Oct 2021 00:17:04 +0800 Received: from fraeml714-chm.china.huawei.com ([10.206.15.33]) by fraeml714-chm.china.huawei.com ([10.206.15.33]) with mapi id 15.01.2308.015; Fri, 22 Oct 2021 18:17:02 +0200 From: Giuseppe Fioccola To: "core@ietf.org" CC: Tianran Zhou , Mauro Cociglio , Fabio Bulgarella , Massimo Nilo Thread-Topic: New Version Notification for draft-fz-core-coap-pm-00.txt Thread-Index: AQHXx17e3fh7XXlrQEuEwuZTp3pIr6vfMGlA Date: Fri, 22 Oct 2021 16:17:02 +0000 Message-ID: References: <163491881526.20431.3603752246262277164@ietfa.amsl.com> In-Reply-To: <163491881526.20431.3603752246262277164@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.48.212.122] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [core] FW: New Version Notification for draft-fz-core-coap-pm-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 22 Oct 2021 16:17:21 -0000 SGVsbG8gQ09SRSB3b3JraW5nIGdyb3VwLA0KV2UgaGF2ZSBqdXN0IHVwbG9hZGVkIGEgbmV3IGRy YWZ0IG9uIENvQVAgUGVyZm9ybWFuY2UgTWVhc3VyZW1lbnQgT3B0aW9uLCB3aGljaCB3ZSBob3Bl IHRvIGRpc2N1c3MgYXQgSUVURiAxMTIuICBUaGlzIGRvY3VtZW50IGFpbXMgdG8gc3BlY2lmeSBh IG1ldGhvZCBmb3IgdGhlIFBlcmZvcm1hbmNlIE1lYXN1cmVtZW50IG9mIENvQVAuDQoNCldlIGFy ZSBsb29raW5nIGZvcndhcmQgdG8geW91ciBmZWVkYmFjay4NCg0KQmVzdCBSZWdhcmRzLA0KDQpH aXVzZXBwZQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmcgPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gDQpTZW50OiBGcmlkYXks IE9jdG9iZXIgMjIsIDIwMjEgNjowNyBQTQ0KVG86IEZhYmlvIEJ1bGdhcmVsbGEgPGZhYmlvLmJ1 bGdhcmVsbGFAZ3Vlc3QudGVsZWNvbWl0YWxpYS5pdD47IEdpdXNlcHBlIEZpb2Njb2xhIDxnaXVz ZXBwZS5maW9jY29sYUBodWF3ZWkuY29tPjsgTWFzc2ltbyBOaWxvIDxtYXNzaW1vLm5pbG9AdGVs ZWNvbWl0YWxpYS5pdD47IE1hdXJvIENvY2lnbGlvIDxtYXVyby5jb2NpZ2xpb0B0ZWxlY29taXRh bGlhLml0PjsgVGlhbnJhbiBaaG91IDx6aG91dGlhbnJhbkBodWF3ZWkuY29tPg0KU3ViamVjdDog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1mei1jb3JlLWNvYXAtcG0tMDAudHh0 DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWZ6LWNvcmUtY29hcC1wbS0wMC50eHQg aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBHaXVzZXBwZSBGaW9jY29sYSBhbmQg cG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1mei1jb3JlLWNv YXAtcG0NClJldmlzaW9uOgkwMA0KVGl0bGU6CQlDb25zdHJhaW5lZCBBcHBsaWNhdGlvbiBQcm90 b2NvbCAoQ29BUCkgUGVyZm9ybWFuY2UgTWVhc3VyZW1lbnQgT3B0aW9uDQpEb2N1bWVudCBkYXRl OgkyMDIxLTEwLTIyDQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQk5DQpV Ukw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1mei1j b3JlLWNvYXAtcG0tMDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtZnotY29yZS1jb2FwLXBtLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtZnotY29yZS1jb2FwLXBtDQoN Cg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBhIG1ldGhvZCBmb3IgdGhl IFBlcmZvcm1hbmNlIE1lYXN1cmVtZW50IG9mDQogICB0aGUgQ29uc3RyYWluZWQgQXBwbGljYXRp b24gUHJvdG9jb2wgKENvQVApLiAgQSBuZXcgQ29BUCBvcHRpb24gaXMNCiAgIGRlZmluZWQgaW4g b3JkZXIgdG8gZW5hYmxlIG5ldHdvcmsgdGVsZW1ldHJ5LiAgVGhlIHByZXNlbmNlIG9mIHRoZQ0K ICAgb24tcGF0aCBvYnNlcnZlciBpcyBhbHNvIGNvbnNpZGVyZWQuDQoNCg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0K From nobody Fri Oct 22 14:05:16 2021 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 8A0FA3A0905; Fri, 22 Oct 2021 14:02:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Cc: Jaime Jimenez , The IESG , core-chairs@ietf.org, core@ietf.org, draft-ietf-core-senml-data-ct@ietf.org, francesca.palombini@ericsson.com, jaime@iki.fi, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-ID: <163493655454.28898.7541838380323845422@ietfa.amsl.com> Date: Fri, 22 Oct 2021 14:02:34 -0700 Archived-At: Subject: [core] Protocol Action: 'SenML Data Value Content-Format Indication' to Proposed Standard (draft-ietf-core-senml-data-ct-07.txt) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2021 21:02:36 -0000 The IESG has approved the following document: - 'SenML Data Value Content-Format Indication' (draft-ietf-core-senml-data-ct-07.txt) as Proposed Standard This document is the product of the Constrained RESTful Environments Working Group. The IESG contact persons are Murray Kucherawy and Francesca Palombini. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-core-senml-data-ct/ Technical Summary The Sensor Measurement Lists (SenML) media type supports multiple types of values, from numbers to text strings and arbitrary binary data values. In order to simplify processing of the data values, this document proposes to specify a new SenML field for indicating the Content-Format of the data. Working Group Summary Consensus has been reached on the scope, content and level of detail of the document. Document Quality The document has been discussed on multiple IETF meetings and CoRE interim meetings, and has gone through multiple expert reviews. The last version includes terminology information and the ABNF as requested on one of the reviews (https://github.com/core-wg/senml-data-ct/issues/2). It was also decided to migrate the relevant terminology definitions from draft-bormann-core-media-content-type-format into the terminology section of this draft and to remove the normative reference to the previous document. Personnel Document Shepherd: Jaime Jiménez Area Director: Francesca Palombini From nobody Mon Oct 25 04:10:03 2021 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 372213A0B1A; Mon, 25 Oct 2021 04:09:56 -0700 (PDT) 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: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <163516019615.2591.16629472530639118053@ietfa.amsl.com> Date: Mon, 25 Oct 2021 04:09:56 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-coral-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 11:09:56 -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 : The Constrained RESTful Application Language (CoRAL) Authors : Christian Amsüss Thomas Fossati Filename : draft-ietf-core-coral-04.txt Pages : 47 Date : 2021-10-25 Abstract: The Constrained RESTful Application Language (CoRAL) defines a data model and interaction model as well as a compact serialization formats for the description of typed connections between resources on the Web ("links"), possible operations on such resources ("forms"), and simple resource metadata. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-coral/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-core-coral-04.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-coral-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 25 07:00:31 2021 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 AF9AC3A0B18; Mon, 25 Oct 2021 07:00:28 -0700 (PDT) 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: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <163517042866.11487.12550446593828326110@ietfa.amsl.com> Date: Mon, 25 Oct 2021 07:00:28 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-oscore-groupcomm-13.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 14:00:29 -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 : Group OSCORE - Secure Group Communication for CoAP Authors : Marco Tiloca Göran Selander Francesca Palombini John Preuss Mattsson Jiye Park Filename : draft-ietf-core-oscore-groupcomm-13.txt Pages : 98 Date : 2021-10-25 Abstract: This document defines Group Object Security for Constrained RESTful Environments (Group OSCORE), providing end-to-end security of CoAP messages exchanged between members of a group, e.g., sent over IP multicast. In particular, the described approach defines how OSCORE is used in a group communication setting to provide source authentication for CoAP group requests, sent by a client to multiple servers, and for protection of the corresponding CoAP responses. Group OSCORE also defines a pairwise mode where each member of the group can efficiently derive a symmetric pairwise key with any other member of the group for pairwise OSCORE communication. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-oscore-groupcomm/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-core-oscore-groupcomm-13.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-oscore-groupcomm-13 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 25 07:04:49 2021 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 4BE653A0FC3; Mon, 25 Oct 2021 07:04:41 -0700 (PDT) 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: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <163517068127.4383.12405261690407847589@ietfa.amsl.com> Date: Mon, 25 Oct 2021 07:04:41 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-groupcomm-bis-05.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 14:04:44 -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 : Group Communication for the Constrained Application Protocol (CoAP) Authors : Esko Dijk Chonggang Wang Marco Tiloca Filename : draft-ietf-core-groupcomm-bis-05.txt Pages : 60 Date : 2021-10-25 Abstract: This document specifies the use of the Constrained Application Protocol (CoAP) for group communication, including the use of UDP/IP multicast as the default underlying data transport. Both unsecured and secured CoAP group communication are specified. Security is achieved by use of the Group Object Security for Constrained RESTful Environments (Group OSCORE) protocol. The target application area of this specification is any group communication use cases that involve resource-constrained devices or networks that support CoAP. This document replaces RFC 7390, while it updates RFC 7252 and RFC 7641. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm-bis/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-core-groupcomm-bis-05.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-groupcomm-bis-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 25 07:06:41 2021 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 692613A0912; Mon, 25 Oct 2021 07:06:37 -0700 (PDT) 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: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <163517079740.26326.11500855220357241054@ietfa.amsl.com> Date: Mon, 25 Oct 2021 07:06:37 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-observe-multicast-notifications-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 14:06:37 -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 : Observe Notifications as CoAP Multicast Responses Authors : Marco Tiloca Rikard Höglund Christian Amsüss Francesca Palombini Filename : draft-ietf-core-observe-multicast-notifications-02.txt Pages : 79 Date : 2021-10-25 Abstract: The Constrained Application Protocol (CoAP) allows clients to "observe" resources at a server, and receive notifications as unicast responses upon changes of the resource state. In some use cases, such as based on publish-subscribe, it would be convenient for the server to send a single notification addressed to all the clients observing a same target resource. This document updates RFC7252 and RFC7641, and defines how a server sends observe notifications as response messages over multicast, synchronizing all the observers of a same resource on a same shared Token value. Besides, this document defines how Group OSCORE can be used to protect multicast notifications end-to-end between the server and the observer clients. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-observe-multicast-notifications/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-core-observe-multicast-notifications-02.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-observe-multicast-notifications-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 25 07:08:03 2021 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 B379C3A0912; Mon, 25 Oct 2021 07:08:02 -0700 (PDT) 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: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <163517088268.31055.2076689496473436323@ietfa.amsl.com> Date: Mon, 25 Oct 2021 07:08:02 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-oscore-edhoc-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 14:08:03 -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 : Profiling EDHOC for CoAP and OSCORE Authors : Francesca Palombini Marco Tiloca Rikard Hoeglund Stefan Hristozov Goeran Selander Filename : draft-ietf-core-oscore-edhoc-02.txt Pages : 23 Date : 2021-10-25 Abstract: The lightweight authenticated key exchange protocol EDHOC can be run over CoAP and used by two peers to establish an OSCORE Security Context. This document further profiles this use of the EDHOC protocol, by specifying a number of additional and optional mechanisms. These especially include an optimization approach for combining the execution of EDHOC with the first subsequent OSCORE transaction. This combination reduces the number of round trips required to set up an OSCORE Security Context and to complete an OSCORE transaction using that Security Context. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-oscore-edhoc/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-core-oscore-edhoc-02.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-oscore-edhoc-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 25 14:09:26 2021 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 75F8F3A0764 for ; Mon, 25 Oct 2021 14:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, 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 bRbKChUGrt10 for ; Mon, 25 Oct 2021 14:09:19 -0700 (PDT) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 4BE6E3A0798 for ; Mon, 25 Oct 2021 14:09:08 -0700 (PDT) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.94) for core@ietf.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (envelope-from ) id 1mf7DO-0001aG-6E; Mon, 25 Oct 2021 23:09:06 +0200 Received: from ip5b41a15d.dynamic.kabel-deutschland.de ([91.65.161.93] helo=[192.168.5.32]) by inpost2.zedat.fu-berlin.de (Exim 4.94) for core@ietf.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (envelope-from ) id 1mf7DN-002v1l-Qu; Mon, 25 Oct 2021 23:09:06 +0200 Message-ID: Date: Mon, 25 Oct 2021 23:09:05 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 References: <163519544260.15652.3439102117699403607@ietfa.amsl.com> Content-Language: en-US To: "core@ietf.org" From: Martine Sophie Lenders In-Reply-To: <163519544260.15652.3439102117699403607@ietfa.amsl.com> X-Forwarded-Message-Id: <163519544260.15652.3439102117699403607@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------sULcYv8iDaEyEnMYpEl0dp2r" X-Original-Sender: m.lenders@fu-berlin.de X-Originating-IP: 91.65.161.93 X-ZEDAT-Hint: A Archived-At: Subject: [core] Fwd: New Version Notification for draft-lenders-dns-over-coap-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 25 Oct 2021 21:09:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------sULcYv8iDaEyEnMYpEl0dp2r Content-Type: multipart/mixed; boundary="------------fVxypLOyaVQkHToACp7V3kNP"; protected-headers="v1" From: Martine Sophie Lenders To: "core@ietf.org" Message-ID: Subject: Fwd: New Version Notification for draft-lenders-dns-over-coap-02.txt References: <163519544260.15652.3439102117699403607@ietfa.amsl.com> In-Reply-To: <163519544260.15652.3439102117699403607@ietfa.amsl.com> --------------fVxypLOyaVQkHToACp7V3kNP Content-Type: multipart/mixed; boundary="------------wVNV1TIponxurseKnRiKcfsz" --------------wVNV1TIponxurseKnRiKcfsz Content-Type: multipart/alternative; boundary="------------DSbdlzV6aqHMrfvpQSqsv4EJ" --------------DSbdlzV6aqHMrfvpQSqsv4EJ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 SGkhDQoNCmFzIHByb21pc2VkIGR1cmluZyB0aGUgbGFzdCBpbnRlcmltLCB3ZSBwcm92aWRl ZCBhbiB1cGRhdGUgb2Ygb3VyIGRyYWZ0IA0Kb24gRE5TIG92ZXIgQ29BUCB3aGljaCBzaG91 bGQgYWRkcmVzcyBhbGwgdGhlIHJlcXVlc3RlZCBjaGFuZ2VzIG1hZGUgDQpkdXJpbmcgdGhh dCBtZWV0aW5nLg0KDQpUaGUgbW9zdCBpbXBvcnRhbnQgY2hhbmdlcyBlbmNvbXBhc3M6DQoN Ci0gUmVtb3ZlIEdFVCBhbmQgUE9TVCBtZXRob2RzDQotIEFkZCBub3RlIG9uIEVUYWcgb3B0 aW9uIGFuZCByZXNwb25zZSBjb2Rlcw0KLSBQcm92aWRlIHJlcXVpcmVtZW50IGNvbmZsaWN0 IGZvciBETlMgb3ZlciBRVUlDDQotIENsYXJpZnkgQ29udGVudC1Gb3JtYXQgLyBBY2NlcHQg aGFuZGxpbmcNCg0KQ29tbWVudHMgYXJlLCBhcyBhbHdheXMsIHZlcnkgbXVjaCB3ZWxjb21l Lg0KDQpUaGFua3MsDQpNYXJ0aW5lDQpvbiBiZWhhbHZlIG9mIGFsbCBjby1hdXRob3JzDQoN Ci0tLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tLS0NClN1YmplY3Q6IAlOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxlbmRlcnMtZG5zLW92ZXItY29hcC0wMi50 eHQNCkRhdGU6IAlNb24sIDI1IE9jdCAyMDIxIDEzOjU3OjIyIC0wNzAwDQpGcm9tOiAJaW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnDQpUbzogCVRob21hcyBDLiBTY2htaWR0IDx0LnNjaG1p ZHRAaGF3LWhhbWJ1cmcuZGU+LCBDZW5rIEfDvG5kb8SfYW4gDQo8Y2Vuay5ndWVuZG9nYW5A aGF3LWhhbWJ1cmcuZGU+LCBDaHJpc3RpYW4gQW1zw7xzcyANCjxjaHJpc3RpYW5AYW1zdWVz cy5jb20+LCBNYXR0aGlhcyBXw6RobGlzY2ggPG0ud2FlaGxpc2NoQGZ1LWJlcmxpbi5kZT4s IA0KTWFydGluZSBTb3BoaWUgTGVuZGVycyA8bS5sZW5kZXJzQGZ1LWJlcmxpbi5kZT4NCg0K DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWxlbmRlcnMtZG5zLW92ZXItY29h cC0wMi50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTWFydGluZSBM ZW5kZXJzIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6IGRy YWZ0LWxlbmRlcnMtZG5zLW92ZXItY29hcA0KUmV2aXNpb246IDAyDQpUaXRsZTogRE5TIFF1 ZXJpZXMgb3ZlciBDb0FQIChEb0MpDQpEb2N1bWVudCBkYXRlOiAyMDIxLTEwLTI1DQpHcm91 cDogSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogMTMNClVSTDogaHR0cHM6Ly93d3cu aWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1sZW5kZXJzLWRucy1vdmVyLWNvYXAtMDIudHh0 DQpTdGF0dXM6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxlbmRl cnMtZG5zLW92ZXItY29hcC8NCkh0bWw6IGh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUv aWQvZHJhZnQtbGVuZGVycy1kbnMtb3Zlci1jb2FwLTAyLmh0bWwNCkh0bWxpemVkOiBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWxlbmRlcnMtZG5zLW92 ZXItY29hcA0KRGlmZjogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0 LWxlbmRlcnMtZG5zLW92ZXItY29hcC0wMg0KDQpBYnN0cmFjdDoNClRoaXMgZG9jdW1lbnQg ZGVmaW5lcyBhIHByb3RvY29sIGZvciBzZW5kaW5nIEROUyBtZXNzYWdlcyBvdmVyIHRoZQ0K Q29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVApLiBUaGVzZSBDb0FQIG1l c3NhZ2VzIGFyZQ0KcHJvdGVjdGVkIGJ5IERUTFMtU2VjdXJlZCBDb0FQIChDb0FQUykgb3Ig T2JqZWN0IFNlY3VyaXR5IGZvcg0KQ29uc3RyYWluZWQgUkVTVGZ1bCBFbnZpcm9ubWVudHMg KE9TQ09SRSkgdG8gcHJvdmlkZSBlbmNyeXB0ZWQgRE5TDQptZXNzYWdlIGV4Y2hhbmdlIGZv ciBjb25zdHJhaW5lZCBkZXZpY2VzIGluIHRoZSBJbnRlcm5ldCBvZiBUaGluZ3MNCihJb1Qp Lg0KDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg== --------------DSbdlzV6aqHMrfvpQSqsv4EJ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Fwd: New Version Notification for draft-lenders-dns-over-coap-02.txt Hi!

as promised during the last interim, we provided an update of our draft on DNS over CoAP which should address all the requested changes made during that meeting.

The most important changes encompass:

- Remove GET and POST methods
- Add note on ETag option and response codes
- Provide requirement conflict for DNS over QUIC
- Clarify Content-Format / Accept handling

Comments are, as always, very much welcome.

Thanks,
Martine
on behalve of all co-authors

-------- Original Message --------
Sub= ject: New Version Notification for draft-lenders-dns-over-coap-02.txt
Dat= e: Mon, 25 Oct 2021 13:57:22 -0700
Fro= m: internet-drafts@ietf.org
To:= Thomas C. Schmidt <t.schmidt@haw-hamburg.de>= , Cenk G=C3=BCndo=C4=9Fan <cenk.guendogan@haw-hamburg.de&= gt;, Christian Ams=C3=BCss <christian@amsuess.com>, Matthias W=C3= =A4hlisch <m.waehlisch@fu-berlin.de>, Martine Sophie Len= ders <m.lenders@fu-berlin.de>



A new version of I-D, draft-lenders-dns-over-coap-02.txt
has been successfully submitted by Martine Lenders and posted to the
IETF repository.

Name: draft-lenders-dns-over-coap
Revision: 02
Title: DNS Queries over CoAP (DoC)
Document date: 2021-10-25
Group: Individual Submission
Pages: 13
URL: https://www.ietf.org/archive/= id/draft-lenders-dns-over-coap-02.txt
Status: https://datatracker.ietf.org/doc= /draft-lenders-dns-over-coap/
Html: https://www.ietf.org/archive= /id/draft-lenders-dns-over-coap-02.html
Htmlized: https://datatracker.ietf.org= /doc/html/draft-lenders-dns-over-coap
Diff: https://www.ietf.org/rfcdiff?= url2=3Ddraft-lenders-dns-over-coap-02

Abstract:
This document defines a protocol for sending DNS messages over the<= br> Constrained Application Protocol (CoAP). These CoAP messages are protected by DTLS-Secured CoAP (CoAPS) or Object Security for
Constrained RESTful Environments (OSCORE) to provide encrypted DNS<= br> message exchange for constrained devices in the Internet of Things<= br> (IoT).



The IETF Secretariat
--------------DSbdlzV6aqHMrfvpQSqsv4EJ-- --------------wVNV1TIponxurseKnRiKcfsz Content-Type: application/pgp-keys; name="OpenPGP_0xD3555B9E03C098C7.asc" Content-Disposition: attachment; filename="OpenPGP_0xD3555B9E03C098C7.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBGDso7IBEADGJRHw9WPIiLpHpqA9+lHqTPM9ydRG1E4QSjKrJjWzk63HE1SUEnrHR/1ag= Qqk tn6Q3Zx0ezeQdaE/09AiKPnLKLwX/KQNINe1RzADakj3CjwGApPIox7D19VJ+qqNAPZmu/DXB= Reh LzjJlCfbIkkijCZP6A2okYrhpmm8i0ZD6koH3BChpdut9R2dsSPGt5ZKG6J18z+jh0Ond0vqN= dPw RVa6zF8XyYE3q76OqmZHS3FOp2KX2Yl0Mw2AYvqsnbzLKSm64gv0wvZm+jED1LQAhnFGEIJ/1= B8o 2jAzmr414w9iMalMA2RcIsw4sDIJE45/9gweJv+/u2Ocy+vbbIwdBB7chE1lcghTEIBZqNHxC= AEm xcX//IPSt4TmX2AIdT1rNYl9uZ3F23DTqAfnNx7ZBj7/51EGB/ip+M7Gxy+HM9O0Ob18TkT3Q= 7al aOmu36EhpaJ29x0o+IdWlUxFSByYMKoGvyZatZtME8fkUg8qjLk5uaQ7TvdFhjjhgsvy0XkNf= 8Ff tHply5G6gh72sXAGncltXWMQGcf2TkB9qOtPkHipSq4g9W40bhp2awOdRlyi5LoTu3kzoabEd= gZj KC190a8jYYu30Of1tqHvykSKPQcGzDsFzpa2N+Oj/EUdFlGbdOpTz3/gj1To87bZqD5z2sz1h= 7nJ Va4JLUcBYkgZeQARAQABzTBNYXJ0aW5lIFNvcGhpZSBMZW5kZXJzIDxtYWlsQG1hcnRpbmUtb= GVu ZGVycy5ldT7CwZcEEwEKAEECGwMFCQPCZwAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AWIQSGM= a6u CWMHSOh6ioXTVVueA8CYxwUCYOylmwIZAQAKCRDTVVueA8CYxzkHD/4teYlsF9CZYcD300/dI= z+k svsxg9S8gc4DfQwPClzDWshSblv8LZzqwFCFOmh/AxI5zjdY4NGWOKUk4fxmlErD0faInJSON= oi3 myW71YLtQF68l7hez6CCFAIvXmCdH5AqmB1gVckvT66KK15dNPIEwrY1brNNxANBDvh2o4kuO= ZwL PaBjIBw31yFRtHxDdvOVek8WKIniEpj9oYQJ09Op7P5j+Id01fphrPHTTbo0v4ZiL8UcZj77P= Q3U IsAiniyo7TroepnyvxuInYWKcvT4zU9kdg/S9hdj67pqSvTk8VMEE5h70wVSVma/HElQdl8Zs= kR7 b/HvgzMsN5Jr+OvRP7R7tW5n1rbSnnmgAxSy7wxJiRTb+sFPUkOwTNRKU+QSs6OQRX+IpgYki= BQK w2gb76BXVrTUzEQV6gg6BZlyCTxpv/RZF47+lLeCZka9lSie3cUjN2CZLdKi8F6nWxm3bh9VT= 4TM 866KtomgDsTrBimXK184dTflzM80QE/wIfVCAuhtQWLPwHee5/PmoFn3egjqsQTqogkiMZWu7= wX+ 9QN5keD6uF9RHR1elzcK0761PfejnC5UsKq3GN7/Bg/nZg6Gp63YnIr+0Ihu78Nn+LsAo29tk= O7g jX4wrRGb86Gs9NXxljo50hNzSuFmx5VYxn8p8/Tj8pfOqizGdJyoX80vTWFydGluZSBTb3Boa= WUg TGVuZGVycyA8bS5sZW5kZXJzQGZ1LWJlcmxpbi5kZT7CwZQEEwEKAD4WIQSGMa6uCWMHSOh6i= oXT VVueA8CYxwUCYOyksQIbAwUJA8JnAAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRDTVVueA= 8CY xz+hD/0SpVUL2uudqFqgMIVJm8DjPQ/Kgu1UOZSGnV8UyhffZVT8POJrC4ve2JU02hBiY0Rat= aJh fWd7iJ3cSD7m4BbvxtDEfc+5t54Qe8c3jWse9XMNXFxbp6ZDRPgfNMO5G+cfgAaUYgbuAQvOv= x6n xbB4jQcYYlrZZpRLC86vvu8SUoP/NOxqWZ/Cfve6/rtTD3gnsuUIvuJHTI1OFpFr7AX8phYGr= hQo q1xdfimmnHj9KEdXgK9JGhEhz5RcpcozjVIrYHowKr1azDue7BZqXhi7TpVM+dsXgHeINm85S= 60o 6aWS+Kj2rpv5vdBmp4YAsakaiLJsbYfM8nb6zzKFkW4SeMoY388w5pZ/wUb8vwHym65t62CcA= y8Q mSIiM59Geyehv6Yjv3uOjGFYF7a/FCTQiXfHE4ZLoDugtV7yUoFFw0VVvrWUbcRcpRjDVFV2f= uZg JivyCH9ws+9jwsc0+v7IJUJwN5dvv+wRZmd0XmbqOCVb8RgO+Q9asDWB1mZjXaf5e88HAUOt1= ZRK 7sqlWDEqemNpeohdo9ujLqoF/5Dhh2swV7DldpgNoHl7Ct0b6DXRhP2OeaqhiNet82Qnszxpj= tm+ /+bC2KTe/n8tkl36IGMOG3IlWiEfDGeH1W1D3shZHUoBrf6CLXNiiIet8WKVyEz2iL/xMCR1t= nSp AoJHcM0vTWFydGluZSBTb3BoaWUgTGVuZGVycyA8YXV0aG1pbGxlbm9uQGdtYWlsLmNvbT7Cw= ZQE EwEKAD4WIQSGMa6uCWMHSOh6ioXTVVueA8CYxwUCYOylYQIbAwUJA8JnAAULCQgHAgYVCgkIC= wIE FgIDAQIeAQIXgAAKCRDTVVueA8CYx6VXD/4x4c5bFOssAe9HGkEM/rwyK+f3YRKsIvltrMmXe= 4Jx i+zEAJceP03ksOn9p+F8E03fTloG94QHVYstuy7CX9TZWFoZ7evdD8x8X6hUUL09HwTrv/5Yw= tEn V5/EiFcJLsODxG25P0/ZhS2RuMLkCwClHBei5nvM9ebSzSkKcGKRdXvMUqNdiGq5vl1taFejt= jNb +UR1gYWs411qaBhdEcMsv0p1Ydcv46RkeJfRSfv1s90zCOR8+t2YBAanLWCngzfYls8b/l18v= 0UK zNJuZ+4sLaEWbx2W9F0bdVyTUUsLkJTIr2gY8PPqEC97SRQABil/1WLBp09Vcnh+U+GkzHtKq= a8e m7TdrPPvZPwjP0XMk/Ra+qVU8i938WaHQ/mvdmq903VVAEH3bcDU0h4eJ1zNw3rrKxxh+U/3m= 6Yj +Vz+w+HX27DrVeqNiLnau5yCyyqgkLktTOVdwBEn6clJwIcLEbQd+20J2GXo+9YmVFZysxeNw= SGB Raow0DEdxcke3v4p9EkpL9lNTx/clwYoNdTyH3Mn9mwS/d7Xmag5LxjAYtcCurFXObAcTmCWm= 3Vd 3CFpQDmNjDyj0qfBJySTp8cRdoil5Kk3I8sZ4PsOjgquIsL0SsYfGnX7/H+cv0j6LUYJMZHtt= smt 0eN1wK5YmqZlJ72zPKp4+AhIXcGacCnqx80tTWFydGluZSBTb3BoaWUgTGVuZGVycyA8bWxlb= mRl cnNAcmlvdC1vcy5vcmc+wsGUBBMBCgA+FiEEhjGurgljB0joeoqF01VbngPAmMcFAmDspZQCG= wMF CQPCZwAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ01VbngPAmMcJERAAsSOUPRMpZsJk9= Hth TIibBbKqPu6hXHcQSuIKXdAhGecCZo4L9W1Y7JO2gfia92lxyL/dOZd/Df3YK4Cc1Hu7BJGTn= U89 YZV0qMsoxqJPPZfdcMDqaGPFSuuJ03VtJQe6OMkMU5BBqqiT6VjLnRL4IvVVu2Lf9CmSBdCJF= fOb FTE2yHFwRJ1uKldhYuUJUvjkDCuswCqF0K1JlYTjFYH7eHae0SDR6zu8+rgGdhWsCL1a9oQzO= j/e mZKbr9C4waatjDd5LD93IRRDAGMStNZiKjNNfXXHTBpTjuAJZGS81G3uruVqXYbeJf58Io4Zv= hL3 DCoD4uoX5RdQ1p4FWv7J8T9yhiEs8TO0HsaTAjcy2Z/3jTTfBwGhfVZjUHMkwV/971Ye8k1Cn= 4ii CRk2eyowGVrFzfQox/AX2tNve5uKtrgF6euHjeSCeXskjsBqLf113bdUCHlTcm2dv5NWALukb= 4vy +zPEnryvehIP0BjYiFIs0yYQYKYi8Fft5P2KN6H9IH3TjYoFhrxmamQnoxOw9WPLHcq+VZ3Vv= /0k 9Zbe38EbnhMvRTcX6hDuKpdfDIO18ILrMapvvXOImGiUKlDYIwJP/sQDMgKM6aZaZ+OoRPPEz= GP6 f4Qsqyok9GHxxl8TVpz0todwUyM+evRUR7uqvXHf/WBEIcAfub26yYCWLPvOwU0EYOyjsgEQA= NEy zAnTN2uB14XGvatXX0XqMWye/oZqEw6IsawGi4WYHc5XzeTn5sDNaTHaTqMC/QMEfpgOKO023= lVv uQAOa1dW7tKZ3Q+xh7I0tYg2cGwmVaZXvrau0s+AshwGiZjp1Y4bTrcge2KAtpWj1xY9r5J+J= 710 4nyUfyx5qCWf1wxWmBDKntGrVeFdomNKQbjEX2egOAcG4YKhr6/a67h1kAcwccBGoxqY2tvLc= Qfo j4I881irp/bBmaTQGyoBF3hqySBtLOVpgweEIoEpPit+9oxRLvranf7EgP248kPkZ0bml8svC= Qxp q5KETHeVWUr6HF/YY6HGKGsx0chWh8TUxQomW7aDBWgdO6tQn5yGWeX1CRMonJgFGWq3gKldx= W/3 cepUXTl/exsd/QjFkzbYsGc/NwTQk0izRy9HkNMLlgf3pI+YSM6yenmpICz57l1E0xx6GxVzd= CBs 2PchMgXaN7Kc0LEr0/x8trkzyxM8wTHJtX1RoIbtocAsK9J8FdeP/Zx3qZP6bkZZc5JbMu0Vu= 5sO N8nkN3Zx8XFVG79LbBN+N/H+5tpTUJ/uab8GuhDcIX1rE16SZDustD0psh0LwgLUhAjgWklDc= WFP /e8wuSJA31W/KSxgtY4rvf7h0yo2iWq42spB2YZubgY/G41h36znddZJiOFAdda8Uatqexh/A= BEB AAHCwXwEGAEKACYWIQSGMa6uCWMHSOh6ioXTVVueA8CYxwUCYOyjsgIbDAUJA8JnAAAKCRDTV= Vue A8CYx6v+D/9m3TB+kVsKhpHgaiPd0qqqyxPoORpfNP2Gxad7rpnfAwXUl++fU5fIVyqhZbhsc= 7HL nR9kbZf+E3CuZkUvLcuFwp43lP7UDdFojk29hQdcP76cbFZB0xTJgPHNRfFx5WYn3ZpnvI8cQ= ADj vnXtvq7XvjEanYyM3ZT8K2wR+qM4NP6LebiUqo90eLHbU0ecmoWeetmSiUHSkJ2lHYEHUJb6E= vTT OmOX0v+jffwKpgTv0yHz5yu6Z3EXoTvSAXjt8XM204TMD4TOhAXhus0zH3W/AtxX1u5YVrlI+= i3c 9TLAhLceq5tHLy5T2+XBkU5suIDIpG4Np1MypD3GdEhFF+RkVUkZp1V/XSunQQt5tgR9/Orkz= JBE kXK0GUlC4qw31dunv073T4eRfI4mx1GOCMONLchC7YAxFD6HtTYXHIBXGDsSXI202GnIBhHaP= pGh UMeJxlOsH+eXUkz82a03vAR6QDunM4g3pC2TLnAv13oI+j+zxX9xow9PuYNqksZGMUgU8ZcOa= SJu S1ExIPT4Wh3OfCijKt9XbK5PGtalPokrKgaTXHCfDo3fJGv13tZp1yyTCLTB2V7tmcMHvWsSe= nfM NTJYhQe3beaV5JsmjnhV+AuOqelHoCXZL4mCETcqy5ypGvywMPZkrZpvmxY3dSGX6EzCn3H1L= n7I X+SO/yWOAc7BTQRg7KWgARAAqp/eHTFTEkPQwUbfMTNlBDPh3P69q+wpiYeTPDSe51Qg2Gaup= OFT 8FOpCbRJk2zqFSo3MtzOLG1Cgi8GNV1eZTBW8ObsUmCJtOXlUfZuOKXZvjy2VcFwtu5qpDcwm= iUu EVOIy8WNkTTpLL0tk4emAmwa1fJsU9+9KSIYZZL7+ewOUZh7h8WIdn4mLyZ3ESzIdYvhdGehz= 9XF eliI6sdM4ev4bLGrU4cLh8Sv8CuNK2YWov+Z4gu+FagyhoNzMa0wSBVyq7fczJ4ViGydl6F3M= zsX YiTYF8xIzIQVEyvsa0hC91hD1lawY2H+YUiX7y385K/k2i52H/DE2/9Hl898wguN99QR2uTXU= 7ex mQ6xXuUT/qbnl0W9Ll1qByfSeNBCstgm1uhLBJVUEJfJ73NMVklx2hF365odpqRIx3DtV+7iV= Etc LEksL2VHKL0c/Escx5V7cZCjHvC7uaM5EUEXSskXe9Jc3OfWpNnOinenSXHiN65Nm/uYM0H3o= WpD 4krcHLrFh05uhHz19cu5fYJokvCVCalzdEw1I1e+5G2D2lgoxy63t7tj+OpGcQ94tOTcbBwAz= mia rvemoSL67FeN4yzCShZ2HxQhvFglkFPiql7JpZcPMA/LjihApVxj/vLk7BJwbHHsnNw4U+MU0= YPv Ace3nm7UkJrIcM4mtWzGI88AEQEAAcLDsgQYAQoAJhYhBIYxrq4JYwdI6HqKhdNVW54DwJjHB= QJg 7KWgAhsCBQkDwmcAAkAJENNVW54DwJjHwXQgBBkBCgAdFiEEx0d0J413JFDpx+b8ITTXelM23= YAF AmDspaAACgkQITTXelM23YBzNg/7BoQDOXEyzdG0in1SFYaGfkU+QlSlHDOK5D1KbI9Ls3s4c= dYD 413s06z+evrIcPjjZ/1Dte1xJR8B58ZVzXVJcsVByp90e2ONcEOo8CJtOzq/31EmAe6SL3rl1= P8/ 3XVSN6JDVTZkgv4fG6YrOWlhXRE+b/MGhAHqIiQZ4Q1ryVbvA203LaeP57utHtYzu38Iy02Lp= OpL 4DRECDoL41+YAfcwqsKCZu8DS/tf77s0ggvHILaE6SdrjAQsVRu/Vmoarj7GibaAHGJNFb/5m= JwG iWdJoMUu/QOxTWHoD2ypGSxKCJte3drB/taGzpplULedfLFuOtV6dgOUwb8J/w/T7eJuS0ivO= jmp QRehI+KB4togVi4ZRvgC19g7TlVxoBl14jX3rcDzWDcRuEMJ184kEGbY77TUaWgoFD5YBu3VQ= SNU 62MWKP8SAPJBK2G590uRDtdJwNnlm3Ps7Kfjd7IL4eiCBjcqM365SXj/jDVd57AJrwDpH48rV= FOK FRZG+Tet0zy1oV7+MX1j/9RVejdWiXhoefDMSZCnUTPZfWCHW0kt5wEmnNkN+V1r08UHwQlDt= gQz P+GmRrF3/0rXWnb3ePhlikudBxRxBfUVn294x8rabxESxD/ucGSFuIc68hOxfAxNrq0DLtRcq= WDo 4At1Wqr5Kv2kwlmP/J0igTSVxMC4bQ//VJcjiFHkll4KjzbhWFuZh0O23xB9pSQwWkcB2o9Zx= j+Z tqB915OMnzwxPO0cif7fxQTqXBW6J7mkp2DxMn1RWBtOrLYxWR0s3vyuHDJoO+lB67sTCq7oT= ob/ Ow0O2nwoQyfITCfDG0Ii7NwxK0Rg0Ym+WTBYCuqCvmBd+K7QlZEyrHK08uPqHhLpQWc52lqi3= IlO f6yIqm1UycMV/T4rHXLiobrBgTHI/7QshX3/WDNBbQ2GfZDxp2DzXeFDK2kEE+LO/ufksZlr9= 9il Nxf6e6sbkQ8K2noaHrIBL3mwLIM2qWU9VWPlw5tcjpHmCS1IFCxp0BBBuElHK6OLMaCKQ+sPH= +pY G26+IEjA8KP11AOtA98xd7r3xPSvwgyWSNuqIf6/nMNd2rhuo2ICTeEWI/zFO2kcdJpETPtO5= 0qL sCpq+EPKQpc4QYjpPWBKLgqGMa9J0UIO9Yx30B1rfGV9Gk0s/oSE5L2j+QQ2l+lfJjiUUz1A5= 2Ia PfuxwcoqcvEywmvHGD9vYS8/YDohz3w5mVDb0mwWCiY4gMUJO4Q/LK4b2Spi38998PmAGhsEb= FWt z0+ojAlmjNkEMc7ZfK/y1zJvDDwkB7+cLnSgbOO0jcXOVnsjPLjNsTwccbsbxmiD3J5ZDDuyx= 3F/ WYdKsSEpuUsVdjDaFiRq8INzI1aqIXE=3D =3DBmZj -----END PGP PUBLIC KEY BLOCK----- --------------wVNV1TIponxurseKnRiKcfsz-- --------------fVxypLOyaVQkHToACp7V3kNP-- --------------sULcYv8iDaEyEnMYpEl0dp2r Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEx0d0J413JFDpx+b8ITTXelM23YAFAmF3HPEFAwAAAAAACgkQITTXelM23YAG 3BAAjMZj86V/qkKw7o6kekNfJkgYD3lldT7S1MaVCkOMEQswbigV9A91jqE/XEaIGBeyYNICe27N 1ck9t5ViYbpS2GgafGsnBUvi8Q2z7z2F+mdiBzBHcHx/a0v1967YWXk3l1MxTXBpBKRmm9mZI1gH Zov9/OTVVfc7d/KSNgvgXovSaB5djKYJ8H1vHzYD9151Xa4rEcAj66qmzSSXAdtSS+ZI/vEsXemD vse/Gd4x9SYtTOW4/bKBJqxWOLpITq9M1L0BflBlYmzy//2yw/QgYfZxLNOwl+C4M0YqJkLZhXrL 0yanVj3h+GL/0LRexLhcGn+Z7ah6pIXUdJgbA4cYE4YtokPJNiC1wSC/BZQalLkzGFl0YO5ByCXK VkphxbD68fW5iKHnpuAmFC354EnSIaounMHk3pykzVNQLFnI8O3bX5xtYS2R3/fN56KQNSgNFby0 o6PAnEkxDWdmUBXL0eAF8DgAkqkAYizy9iKk9GA9VzG0M0vpFLg5kisVX4ZQlY9pg3jif4rSqLIl 8qgMPfOFK0Q65wR1LvAcA4KMPFYru9wdBaHGGEbqC/RbIkwLECgSMstkPvnJzcyAGV9RayqVkN+r mSl4BJDqrIif93n8hJ5NybXUqKPbvorHQDQFfgCZs6JZmsJSuDh10197dawICxdIks5YdUcBeU+Q ni0= =Vasu -----END PGP SIGNATURE----- --------------sULcYv8iDaEyEnMYpEl0dp2r-- From nobody Mon Oct 25 14:54:24 2021 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 AF1AF3A103A; Mon, 25 Oct 2021 14:54:18 -0700 (PDT) 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: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <163519885864.7126.11577957403489700933@ietfa.amsl.com> Date: Mon, 25 Oct 2021 14:54:18 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-href-07.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 21:54:19 -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 : Constrained Resource Identifiers Authors : Carsten Bormann Henk Birkholz Filename : draft-ietf-core-href-07.txt Pages : 21 Date : 2021-10-25 Abstract: The Constrained Resource Identifier (CRI) is a complement to the Uniform Resource Identifier (URI) that serializes the URI components in Concise Binary Object Representation (CBOR) instead of a sequence of characters. This simplifies parsing, comparison and reference resolution in environments with severe limitations on processing power, code size, and memory size. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-href/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-core-href-07.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-href-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 25 15:04:44 2021 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 516473A10F0; Mon, 25 Oct 2021 15:04:33 -0700 (PDT) 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: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <163519947330.11386.3577247314472382126@ietfa.amsl.com> Date: Mon, 25 Oct 2021 15:04:33 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-yang-cbor-17.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 22:04:39 -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 Ivaylo Petrov Alexander Pelov Carsten Bormann Michael Richardson Filename : draft-ietf-core-yang-cbor-17.txt Pages : 49 Date : 2021-10-25 Abstract: Based on the Concise Binary Object Representation (CBOR, RFC 8949), this document defines encoding rules for representing configuration data, state data, parameters and results of Remote Procedure Call (RPC) operations or actions, and notifications, defined using YANG (RFC 7950). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-core-yang-cbor-17.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-yang-cbor-17 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 25 15:05:04 2021 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 3738C3A0E26; Mon, 25 Oct 2021 15:04:56 -0700 (PDT) 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: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <163519949619.14148.5688061704858684987@ietfa.amsl.com> Date: Mon, 25 Oct 2021 15:04:56 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-sid-17.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 22:05:03 -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 : YANG Schema Item iDentifier (YANG SID) Authors : Michel Veillette Alexander Pelov Ivaylo Petrov Carsten Bormann Michael Richardson Filename : draft-ietf-core-sid-17.txt Pages : 40 Date : 2021-10-25 Abstract: YANG Schema Item iDentifiers (YANG SID) are globally unique 63-bit unsigned integers used to identify YANG items, as a more compact method to identify YANG items that can be used for efficiency and in constrained environments (RFC 7228). This document defines the semantics, the registration, and assignment processes of YANG SIDs for IETF managed YANG modules. To enable the implementation of these processes, this document also defines a file format used to persist and publish assigned YANG SIDs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-sid/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-core-sid-17.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-sid-17 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 26 02:53:27 2021 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 2C3CF3A0883 for ; Tue, 26 Oct 2021 02:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=ri.se 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 2kCsQGN5BWBe for ; Tue, 26 Oct 2021 02:53:20 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150080.outbound.protection.outlook.com [40.107.15.80]) (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 2E6543A0880 for ; Tue, 26 Oct 2021 02:53:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=O/JNejXbfH5IigdqHxOdjPCjHB+pZ//XUDAIthqDqqCJx0YSwIR++NOIGfebLTqZ9OL/n2hz36SzQ2g8fZjLgvdDj+epqn/BpW6o0ba96N6qdEWHY0t5N1AHNZVktb7zBaehDlD5CXGOEZ24NbDBjHLHR5iGRVSGlEDq5hZUyCKQ5d8geywDO0dvhggXZxbh9gU981QLy1HNQdgYjZ2VJNIy24CK9Vp+zjHtGAdSY/9dpVfgjRi/VgSlTP1yHBkh/1JT/KIjDV0TBVNQ0SLm+IY82EVO8WvebGw4VfOstTxIVMgLIwgnIdJjTuHa9i1N+NqesA0qN1uZ3TE6aZT9Mw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=XNFH2TcrEbM6e52WviAsvDKJyeWjVzqueotabf8hdpM=; b=bIKVEi2lSqbUgEUTxDLKc5nn5rBNsYmR13VnF2VSBCpaBWACWvkqPfRtnk/eAUROok3ojrFGMO48cFdv8gHVrCPjJrYubDpM/nxIFBcEffGwL/0quQt7e+8F0yYHpStkAld/vKP0n6cLdBbuNgBVsSkqdnC3TOyM90JnQFpNPZVsrTyYQryq7UqRB+GpuOW3w5KeL31FaTgc7ZputdUMPDA17pSLEbv0BtNLgeYUnHwuM9Zl4GXX0yz0KlGErjq73TGag1utwxpkLaLGGEJyj67eOF19O7NTcxJMQ+scoFBP1bExWtYg90DJVONcH4R6QCgYDGtrXduuTLNhSgC5Iw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XNFH2TcrEbM6e52WviAsvDKJyeWjVzqueotabf8hdpM=; b=YnDRWUg8Jc/KzREgBcGnOu0SjwUBKEnlY+tEBcBi/ZS+E2zT272rUKseM+4ddc70WGUl0nBaqCeYic8yH25zCVd50+6yGFDS5Yz9+Z7jxR5iy7QZX8g1Pd0OTUNB5AOeogOljFL4f+/4eIU3tTSY6/S6KbjVwOZJX8q0hqPQRAI= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB6P18901MB0166.EURP189.PROD.OUTLOOK.COM (2603:10a6:4:27::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.18; Tue, 26 Oct 2021 09:53:16 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::4dd0:ed4b:e776:d560]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::4dd0:ed4b:e776:d560%4]) with mapi id 15.20.4628.020; Tue, 26 Oct 2021 09:53:16 +0000 To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca Message-ID: <2978e9b9-af58-7b5e-554f-9e99253d41ce@ri.se> Date: Tue, 26 Oct 2021 11:53:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GbubPcXzO3as3EYU7i3cZpZj7BmgxXtOu" X-ClientProxiedBy: HE1P18901CA0015.EURP189.PROD.OUTLOOK.COM (2603:10a6:3:8b::25) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 Received: from [10.8.1.4] (45.83.91.189) by HE1P18901CA0015.EURP189.PROD.OUTLOOK.COM (2603:10a6:3:8b::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.18 via Frontend Transport; Tue, 26 Oct 2021 09:53:16 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f0c68e08-8c88-453b-bb80-08d998666ed2 X-MS-TrafficTypeDiagnostic: DB6P18901MB0166: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:6108; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Y+Jce63FQZcIHIxOSJduqotif9fA2xYcyJv263cEvRRNohrg3QOuOunvR+TE68eBwAFG7kYD+VlWjV4zREehlhyMBNFriVB9jYfCVam3qYhcYuLSpxruqToDRjoZgbYCDVyfYSJxXhhQgJkDDDEIJXZPhqHzD3QeAb7cOHy9gUvvY1WSzwX65mIjU1B2jmXvGmyEkVS8GxQSJ0luLjLdEb6TaWpYcmhVBb/ILKAB+V/UzZH1JiwSZueJPdjWA6NiBUXapPGJ3SSW/Vka9oOIht39xnHJfL0VhndrkH8dBHaHD/xET5INJH+3F0FOaCU0sxGkL3eyTvhc8sPhQt0pldBL1v9kswiq5MzqkbqlPDfWf1swwsBMLPflD+wh75wwx72x3PrDLZnZ+XkUHX6LTfHk/l0ui6cZTy+YQ8+uhUv63Xi6y66wHv7ENFwwQfSU0EFRTdo0mx9TuCu2PBpoIG/AK4GQwHHoeKUrxn9Gp2KlVEXWJKaQQLe2OdRjbIWKaGL61xIt3VY+LGZeG62sCV+TzUBbG+JUQqETE5ZR5RpyEKQMK6eTKYsEbEqytJybnjmSp6llXknY962r69NmYkaKMLX6WIT5UhfHgEK8Q5S4ytWXy3syvvMKq9L2HnJyS44NzgU+6N7K0SmZKLjLgQ6CzvseUOACNNL7WngwwyE09+HDtkgZ8d+DKkkihSJfinHweeturC/z96cbudi799IwSs0Kf5OVBIqnMpnZvoiFeqh8LIUiuV8utKeag+GudYXhy3lhEfdJPRMeXoV58Pk4fXXIFVqJD64g2i6VMqGUU1fLoK+TqQPlDCNeen81 X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(2906002)(26005)(38100700002)(86362001)(4001150100001)(66574015)(2616005)(5660300002)(8676002)(83380400001)(6486002)(186003)(36756003)(44832011)(66476007)(8936002)(956004)(316002)(235185007)(6916009)(16576012)(966005)(508600001)(33964004)(31686004)(66946007)(66556008)(31696002)(21480400003)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?V1JodkpzSDBkZ0t3VnZsb1A5S3N5bmZVSVlZVjR5M3FZQ3JiT2R3dm1LZU53?= =?utf-8?B?Ni9aU2hQRFFGK2szSWk2R2d2UjJWQjNPMFk4dGNCaklXTS9pYTYwZWJKUDgr?= =?utf-8?B?TVZYYWl3ZjgrSnlmSVU4WlF1WGRYSS9VQnc1UU1IS2FaZktwVXpoU0I1bVlX?= =?utf-8?B?QmVEUGtxMDhzN3greEp1aHhDSjJsZHNtR2daV2x6S1ZLVlJ1b2VWc3l4dVNt?= =?utf-8?B?WGx1Q3NoNFJhNlZWek9wZVVLaUd1UllQUzRBNGY5U1lTOHFTc1VwazBXaE9I?= =?utf-8?B?TDBwL0RlN0g2b2sxS25CdG1MR1dyMGwydXdIMG10TDZEWUVKdUozWE1pM0Rq?= =?utf-8?B?YkpaeHUyMVhCZTR4OGZGVDJJWGNwN0MvRHliQlB2YjBPVm1YQ21ueGhlZnVn?= =?utf-8?B?dXAva0tCMFg2eW1DYjY5STh6N1VUMnpJTlVubGh0azJQRU5MVGh2cEpRRkJE?= =?utf-8?B?dlJlWTg4cFUrWEd3UjBkQzFJOHRoaEFCYm1RVDBiaUJndE8rM1lCeXBSSnl3?= =?utf-8?B?Q0ZOS2RzM1grRDYwVG0xbTB3YUI1ZGNhUGJEMkxjQjd5bmNkci9oZktVNXlC?= =?utf-8?B?MFpKZEtNNjhCSGRXUjA3YmtrbkVMNVM1MEl0UzNhUVhPeHlkNzRkY25FTXZr?= =?utf-8?B?dmJkUFhSLzdteXYzK3pOSDBmS1JuSUt0RHhCR2hob09obmw2cVh6SWUzV3JU?= =?utf-8?B?SU9wc3h2THRRNnlzUGxTTUQ2UHl4dHZFazNQTmRrZnBPbDh2TW53SjJLb093?= =?utf-8?B?SGVySVNJU1JPZ2hNaWk2bTJLRGNpbm5MWnYzU2g5SEJVaVdjSHBBd1luQVVF?= =?utf-8?B?OVZFdWNyVlpxT2IxcFlXNHEzbU1FVWg4S2JQcXNtM3JWOHFhNG9vaVRjMXBZ?= =?utf-8?B?VE5JWlVHdnpLZlRjc3BRWWN1bHNkSGVFZXcydFZtZER6ZXMyZTh5NFFqcnlV?= =?utf-8?B?dldVL2FpaTBlaFFPamFoUkFsakIvaGNqdXU4b3NkMUZVTmhKaFA2YjRiRlU3?= =?utf-8?B?SHBuMElKWTVMSzJRRnFCalcwcEFKVFhuYmVoR3Z6Z1IrbFkyaUxwaW52THJ5?= =?utf-8?B?TmRxOTQvaW5ObmpNU1pKdHFPbnZ3Nkxab0RLVzB2TmIycEJldlpRNkFTa2JC?= =?utf-8?B?YStEY1JJTW5ndU9iZHFIdW1yb1ZtK05vK0tMdXlwaGhsTTVyZmhLUzQrcDBz?= =?utf-8?B?MW5FSkltTnNzdGl1d3ZNRlU4YjJQVWpoN0tHK0paNEw5UVhnK3Y0T3dEbmVS?= =?utf-8?B?RlZoWmpnNExoZHpjaU5xUmhwbktTMDRBSWQ3cU9id1lMd1lvYkI3UXRQalhE?= =?utf-8?B?elNFM28xajFxU3VVZzFLZ21lRGFtejhPeTRvenRHNzl5N1ZJOGwxV2QxKzN3?= =?utf-8?B?UG5qS0xtNzFhazFOTlpleHBhWDFFK2JhZ1ZGSGVlcVQvY3RMK1VkdHFPaGFl?= =?utf-8?B?VFFRMVdrSVhOSm9nN01SREhUQTJhcGJEaWxLOUlGVlZFT2luYjFZeFNtUzl0?= =?utf-8?B?ZnU3R1Zaa0h6dUxoSnNkbU5iZytYSzV5WGh1USswam90WGY3SGUvbWEvb1lW?= =?utf-8?B?RTlKWTFOdjJBaUk1UkRFQ2RYOGR1YW1RRFRZckx2bEl1aHNob3lnVVBuWm9x?= =?utf-8?B?NkRkR25JRDFMZG9OaGgreHlxendsRzZLU1ZVZU5MSTlMVUg4cGl1aXV3UVRw?= =?utf-8?B?VDgyVDExaW02VGRTVlZGaXhMcG1nRmphNUVaam9BaUI5ZWRZTTNZWHB6TjBS?= =?utf-8?B?ZVFURXI0eFo4bVZxU0R3Um1VZERRd0piVXVSc215QUk5YXV4VzJZTUNiaE5y?= =?utf-8?B?alZHNTVPUEg1azJ4NzdibGJvYUk3dGlpNndnTlhTZmhHQXpnMnFualdtVlVj?= =?utf-8?B?bzRxUnpKcm9rOVF5OXRqcWpTQmUvSld2L2RLUDJLSGZzTjd5dFpIc3N1cEt6?= =?utf-8?B?NzlmRWwxMG1xcmZRdVJtV2d3OWR5RjZLUUZ2MWZHNkcvWWFTbFM0cWQ5QjZQ?= =?utf-8?B?eHBGMG1Fek84R1oxVnZoVGRoY1BXOTFmeXFaVFNERE1BVC9jZFdoNElraERE?= =?utf-8?B?c3NPbDB5eEhhSnZyWXorT21rcXhDVEE4WEZNQUdqZEQ3SEpZRlBFMnU3eEJX?= =?utf-8?B?YkY3bWxvUjd1aWQwNmFsYk81RE0yNzhEa3RITVd5dWJtdVgwY1ZYNlY5RnRK?= =?utf-8?Q?n7Zj+T58GmqP7BxtH5nmVg8=3D?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: f0c68e08-8c88-453b-bb80-08d998666ed2 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2021 09:53:16.5067 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: O1pNdPOxjDJn/6oy6ffnXE93kAE+qgn/2aOcOuqJ2NgcTHFkbsxcSYVJmKirk/5Pzdx+JV0xfwYpYnAYvGhuXQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P18901MB0166 Archived-At: Subject: [core] CoRE WG Virtual Interim 2021-10-27 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 26 Oct 2021 09:53:26 -0000 --GbubPcXzO3as3EYU7i3cZpZj7BmgxXtOu Content-Type: multipart/mixed; boundary="TzEZWFGRNENyuep1PcCOJ3X2g3CjLWbyG"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: <2978e9b9-af58-7b5e-554f-9e99253d41ce@ri.se> Subject: [core] CoRE WG Virtual Interim 2021-10-27 --TzEZWFGRNENyuep1PcCOJ3X2g3CjLWbyG Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, Just a reminder that we'll have a virtual interim meeting tomorrow=20 (Wednesday), October 27th at 14:00 UTC. The agenda is available at [1]. As per the Datatracker, the meeting will be on Meetecho [2], while=20 minutes will be taken at [3]. Best, Marco and Jaime [1] https://datatracker.ietf.org/meeting/interim-2021-core-13/session/cor= e [2]=20 https://meetings.conf.meetecho.com/interim/?short=3D4b108e95-9886-4b1f-94= dc-aee7b0a004ce [3] https://codimd.ietf.org/notes-ietf-interim-2021-core-13-core --=20 Marco Tiloca Ph.D., Senior Researcher Division: Digital System Department: Computer Science Unit: Cybersecurity RISE Research Institutes of Sweden https://www.ri.se Phone: +46 (0)70 60 46 501 Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) --TzEZWFGRNENyuep1PcCOJ3X2g3CjLWbyG-- --GbubPcXzO3as3EYU7i3cZpZj7BmgxXtOu Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmF30AoFAwAAAAAACgkQ7iZktA5Y2kMi TAf/eBo8Y+p5RaWuxcu4bwHoBA0C4c/Po+ArJlDSRoke5mPEkcMqig0as+8STmDn73nXhjFEHNMF OED2CtjBV8VBV4qxBHeKV1gu3q81jkYQaRJIjnTv8yreYKVZ9WsCpezpRrmh+TAAY/4P+ayrMdNC 44QuX5pi5T78fgYebFQwIeLp71zCmPQu1DImiBbz9gOPO9veKo4qxlLm0Gvf16vU/nSlcEaFLsFk XuYpCKHGiol4K49kh5zbPB+s/lQaCe7DIpT5zDq2gA6EHDd8E0F/4NtMOSBxLv1PXyQJfNymSe+C KynAtf4Xq+z6Rz6OCd3UWIvsWGtvxLY8HYaB/+/TSw== =2rT1 -----END PGP SIGNATURE----- --GbubPcXzO3as3EYU7i3cZpZj7BmgxXtOu-- From nobody Tue Oct 26 07:52:29 2021 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 E26A33A1230; Tue, 26 Oct 2021 07:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 U27YrapTmxzn; Tue, 26 Oct 2021 07:52:23 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A0103A1233; Tue, 26 Oct 2021 07:52:23 -0700 (PDT) Received: from [192.168.217.118] (p5089a10c.dip0.t-ipconnect.de [80.137.161.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4HdvtX6Tffz2xKN; Tue, 26 Oct 2021 16:52:20 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann Date: Tue, 26 Oct 2021 16:52:20 +0200 Cc: iotops@ietf.org, "core@ietf.org WG" X-Mao-Original-Outgoing-Id: 656952740.178381-760efe90eb2043aa78355be699c0350e Content-Transfer-Encoding: quoted-printable Message-Id: To: t2trg@irtf.org X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: [core] T2TRG meeting starting in 10 minutes (1500Z) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 26 Oct 2021 14:52:28 -0000 This is just a quick reminder that we are using meetecho for today=E2=80=99= s T2TRG summary meeting: = https://meetings.conf.meetecho.com/interim/?short=3Df98494b9-cf8e-465a-9fc= 6-2884529c7c6b Coordinates at: https://github.com/t2trg/2021-10-summary#draft-agenda Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Oct 27 13:30:56 2021 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 4E9A63A11ED for ; Wed, 27 Oct 2021 13:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, 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=ri.se 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 VlNVAgjdG1dx for ; Wed, 27 Oct 2021 13:30:49 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03on0623.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe09::623]) (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 2B0423A11D2 for ; Wed, 27 Oct 2021 13:30:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nkInCzWH5JuLogFkp47waGj+vFG6ocGUdMYaAsSSBY72d6tvHVl4YuQmj6gxMkGZpmTou47hS3pq4bWNxaj3O+cmqIMasFNpnPNRqypywfBqfjzDuudEAJCYsilUE13Qi4BxB41PSs0kGz5wWOjKN3xu8kx7YryorflxpQCglzMTT96BMZiipz4pjp6SmuoGvPWO6/XmKNLhdFW6dPGzFjESxVF2Ek0g6yV5uW/SldruwTTPAATOto8P3sMQGes9qJVEmFajh+JAf2sEUzolyRrU7sB9Ii4eh8HPY9BWShz+nJyhtFbgp9YR3nV258HFzyZoBy3WGxOqTI+Sn6R4vA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=KRpn5GChstRdplq3vI5ddgNHT/+oyxdNbNTAxkZqNsc=; b=dAiUKXO3b0XuqOXHOS5dV4VHsxJ5T4v//tFnwxYsTj1zqvHil/IFip+z5AuY3+z7yQfL6tCh0d8T0Vyiq9GgSTzj80iUCaZ4Pfi1TBjFZj3LAOtZEHOdl43lz3pgzI8zIUaa3Vg+HL4JV9ONd/cTpzTwTp9GBB9hHQ2xf3d9lXgWTufs/ciRqdIbSR0JKi5ZevYnNlqqfp5sbdjlZc5bBctMPrCX7ALalyQma6Zjim+CmE6wSEw2NXodv3rg/Ho7QM5dxFLr52yp/SOuLARlmtdOxgMMer3YKOUofdYXrALUZHMsH86O/r1fArx5+ksg7RKX/7mvP91rC7uZHVIWjQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KRpn5GChstRdplq3vI5ddgNHT/+oyxdNbNTAxkZqNsc=; b=brfk547euFU2JFKqp04e1xynx/dFl4IoJqsQM7WGnG/jSqTjMrEob63GUzFO1UP+F76P5ZIEGdsWy9NlTbfYWTKJLzva6Rtln86ifZU3rkD+usfy4s22p2tVoyi+O4ApvWVykO0SDNnmo+LmKnFsCdgjuxlqCsU2/IoZfCt0wc8= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB9P189MB1531.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:2a4::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.18; Wed, 27 Oct 2021 20:30:42 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::4dd0:ed4b:e776:d560]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::4dd0:ed4b:e776:d560%4]) with mapi id 15.20.4628.020; Wed, 27 Oct 2021 20:30:42 +0000 To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca Message-ID: <12858828-4b4b-cabf-29e4-92907fa4181b@ri.se> Date: Wed, 27 Oct 2021 22:30:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BPFKjLaEk7OdZ3bkcTmIb9c3CpsaqhYgF" X-ClientProxiedBy: HE1P189CA0033.EURP189.PROD.OUTLOOK.COM (2603:10a6:7:53::46) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 Received: from [10.8.3.6] (45.83.91.236) by HE1P189CA0033.EURP189.PROD.OUTLOOK.COM (2603:10a6:7:53::46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.16 via Frontend Transport; Wed, 27 Oct 2021 20:30:41 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 73aae172-dc5b-4ac0-5c27-08d99988a544 X-MS-TrafficTypeDiagnostic: DB9P189MB1531: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 1FPKAWhXTE+oU7ohW5xy7lDapS5RNC0ZQwnf28gibFup6oOY4ETQZl28Nl8jkdwjI16ub/toP+KPXbjKCzPOo7GT76rE3FyCUigtcyH+Qipr9u2UrQz0g8hZ+PC+VtMn7NpJIgzme8EUBTK1MWkB4mCsFSMO1ydoaYdqIC7C52iEWuhvi7YxfoVAvTwArt0F9vJokQ+GbjrF3Jwj1RWhfNdiXZZ7tU4dN7Z2ncLDqmWUlubKMYMXcf+7u8r8AMLCRF92a4V0KewmHO2mDaxLAW2Z2jAisqwdAOLExno3Oij8E1Yx9EGQ2h06JSZynziROJAnY9t2Gz499Hyfylvdz3CtoA1LJIo2OxJ5BxeS6KcHnkWP4VSvNZi4t16j1Z0GQz7mK+WQGF8gDkJOJd+hzj90t7F5VN5NQUCSuxMq6tGYUM5AvNfOzvAQLU/wHjD6oDbEIv2NJbUnW3f3C2ibBrQgy3h3ySV8EBwkdZvyxNK8SW+a66JUh2I1LDjTocgvVysu+vzJrfQ8OBOAnrZWk6YA71quMBVYrPzZkwK3LCcOhX8yhC0c+JtQA/PYKs/b2LxrwEJpP11MYiBrkxm5ckhSV6sbsmUeLSJKqypU41aYbofbSY5x52TqCqy6aN4/+EDslmqnTb93lV576tdyqmOWxo0dS0t6MmcJrHBWVvDRa65WCc5L2Nbcvx/s+X4aTc7hFrtudgse3v4032CFbrcRAnKxgZfxhrPnIBhyNc+rS+tPWDT2H3Wzre5Kvb2orp0huwHIu71ZWxRJ2Hc5xNm6RIgXNmMof6B5H1U2UdOgJ3o3JABCe3ohrQmpOx3X X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(508600001)(66476007)(186003)(31686004)(235185007)(66556008)(66946007)(44832011)(38100700002)(956004)(2616005)(966005)(21480400003)(2906002)(5660300002)(31696002)(6486002)(33964004)(316002)(83380400001)(8936002)(86362001)(26005)(16576012)(6916009)(8676002)(36756003)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?N1lMczdObVlpVDl0ak9xdlUrNzltSVJ2bC9nSmtRN2Z1SWlPVUJuMFZuTURU?= =?utf-8?B?RmJMby9TWi9ZaXMzdnBzZGoxeEtqNUxMM2pDdWhLTEJaWlVOeTRoRm5aQnNU?= =?utf-8?B?emZhZnh1VUppcndYcHExMG5hOFBtNmU4Z0ZtbWc0b1diZzQwdXgyU0VIZkxI?= =?utf-8?B?d1lQc2JvVVRQUHdlaVBMSWRCOWdaYW9WSUxhZlR4RGVQQkM3bHVnVmN5ZzIz?= =?utf-8?B?VEdUS1RzenhlUTlMNFh4MTNHTUU5cHh6UWtvYWJEK3A1VHRCTFVKUlczWFB5?= =?utf-8?B?d0I2YXh6SC8zZUVWeVVteTd1MG52MWs1MUlpdnRZMUtjeVhGZWNNZlp1M0tD?= =?utf-8?B?Mk9za2kzblZmdVBBSFFkcVFYcFNMSDZ4N1hjS2tUTGN0RW91RXc5VVhjMnp3?= =?utf-8?B?ZzdDVU1BbmNlTHRQMzNIa3c4alFlNlI2YlZCam94eS9lREt5VmkrZ0RuaHhO?= =?utf-8?B?Nzg5QlAzVmtCYjZaL3UzMEZXSDMrN0pBWkdlU0ZnMXk3R1NVZWNjSmliNTYx?= =?utf-8?B?cjZpTXpJSzl6S3QvNnNCQVVpSWVlSm5nQlY2WTU4ZUNRc05wTUV2bk84aTU3?= =?utf-8?B?cVF1dGREcHVlSEdRVDFqMnF1V2NCeG0rL3JlL1hKclVCa3NoR0pBSFRuUjB0?= =?utf-8?B?bTVlWUt2WVFBbmVlY2x5aHprR3FQcE5lckhXNUJ6ZWxtZkhrS2YzY2FmV3F2?= =?utf-8?B?UE5JdUVMZFd6ak1NekxEenNiNktFekJIc05iQ2JVL0lONmdZeE1xYUdxTWlG?= =?utf-8?B?cUsxdVNuSnV3V0RuYW1NQ0hjSGUrcnc1ZFIwTVlEVG01RTR2U0lWQUZDV2Na?= =?utf-8?B?bTdlTCt5VEtZSkpPS215V1VDQzQwOS9PT0dpeHJ6Z3hKamtGTkRkbjJWcm1u?= =?utf-8?B?WTFkNzJVREdDTUhmVnd3bGV0SXBvTHRZaWtzU0JKQWc2Vjh6RzdnMGRrVHhV?= =?utf-8?B?NngzU2pZQ1N3OTBnSDhodlo4L0RJYXdXZG15QVB0dnhzOFF3ZUM0enpWNXhU?= =?utf-8?B?ejVGV01wYzd3K3BpQ082bXpYUTZ5aGtKMzRVbm1LQ3YrL213NkJ1TmVHMHds?= =?utf-8?B?VENQTFpNRmJhMzJxMEpNRTZTQzhCRk5rak9YNTZaL1ZBT1I2NGJERDRCTXd4?= =?utf-8?B?eVQzK3BUNGYzeDhhUDZmaHh0NHFyNmUrK1M3SmEwSWxwMzdmdzFpTXVMOVh0?= =?utf-8?B?dnZ5dUtXMWgvamhMdDJyRlVuV3RmVXZkUUJKNGY3dHk2cFJUWXJ1Slk2MFdv?= =?utf-8?B?OUtiWUEyaEJTMG5sdFZUdGpiOEVRWWpFek5US0hlR2JYL2JnWndQOTlVa2ZG?= =?utf-8?B?RlZ0bHBuZURacjNJc0t5VUFKaFpXU05uTlF6bVNPSFY1ekRvMFZ5N3U5N0JG?= =?utf-8?B?cVNMRkFNZjlpTEw4N2F3WWNhWFhXekN1WDFBSWRXSUVuaXI1NFkvbGQ1L0NT?= =?utf-8?B?QWdjajNIM3lPYlFHcDVkRG5oSURLSDFLd2FXVDE1SWtVUjN5eDJ3blNrWXZV?= =?utf-8?B?angxQlBHSWtmVWFZQnBsMzBQTE05VXdLdGpzUzV0TnhWbGJTUnhtV24vUDNG?= =?utf-8?B?dWx4YzE4VmdxU1pUdmtXZFVkNjBXa1JTSGV1enJHYTFJV0VYSllTcFV1SG1C?= =?utf-8?B?QXl4Nk9tcENEaE1wd0R6d3VOUVNSTXh4RFJHR1VnQnZ6dDA3bndpNU1WTzRH?= =?utf-8?B?MVdYV2Q4V1pvc3ZvTFRLN1BVVlFKaFAyNXAwcjRFSFp1NCtmN05GZ0FiNnBL?= =?utf-8?B?WVhoVWo5dHU2cnNrYjNvOFowNDY5WllvUWFSVVRxYVBrb1FDM1U1OVpvN1FZ?= =?utf-8?B?L09xWHNYQ3hrM0tPWTdibGVUOStrWVMvZXdaOHFsdE9oQnFpMis0VUd5aXN5?= =?utf-8?B?YlF0a0YySnVXMEg4K2hxL1RyRldFeldpdURJNWNYVGZ2WWxoblFtSnFYUVBl?= =?utf-8?B?aU1HQkpOaG94MDNQTHlKOVNXLzZJUS92V0dJNERYaW4yWEJITFVOK1YrYzdv?= =?utf-8?B?VXp4a0VsUUhhNE9JTWY5Y280MHRXMVpYM0UzTzU4N1BVc2lWMUdKcGR0akNB?= =?utf-8?B?bDRWZEREV3FST2MrV21jZzJBbnN1V29CYVcxZkhxNmc0dlFDbzZIOGJxc1VN?= =?utf-8?B?QXNEbmU4bDBsOFVUWHNzODdtcDZaZ21wWnFXWDZnaTIrUG81TVFxOUEzWE1P?= =?utf-8?Q?f9Gc1vOFxVbQ0aA4sKK1/jE=3D?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 73aae172-dc5b-4ac0-5c27-08d99988a544 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2021 20:30:41.9288 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Py1HvBW3yoDshmhzZjbxjcPNXh7N5Q8Y756EMFTceCTsrBzM1yUhXNF/RxCbLI9JTwgBOk0xPKRXvABgyWMe/Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9P189MB1531 Archived-At: Subject: [core] CoRE Agenda for IETF 112 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 27 Oct 2021 20:30:54 -0000 --BPFKjLaEk7OdZ3bkcTmIb9c3CpsaqhYgF Content-Type: multipart/mixed; boundary="vqIrpm5eP5q1b2zDqS2MsYbIKzT6qGRjU"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: <12858828-4b4b-cabf-29e4-92907fa4181b@ri.se> Subject: [core] CoRE Agenda for IETF 112 --vqIrpm5eP5q1b2zDqS2MsYbIKzT6qGRjU Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, An agenda based on what has been submitted and on recently ongoing=20 activities is now available at: https://datatracker.ietf.org/doc/agenda-112-core/ Those who want to run a slot, please: - check the person suggested to run the slot and possibly provide an=20 alternative; - check that the estimated time for the slot is ok Please, send a mail with this information or other comments to=20 core-chairs@ietf.org Best, Marco and Jaime --=20 Marco Tiloca Ph.D., Senior Researcher Division: Digital System Department: Computer Science Unit: Cybersecurity RISE Research Institutes of Sweden https://www.ri.se Phone: +46 (0)70 60 46 501 Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) --vqIrpm5eP5q1b2zDqS2MsYbIKzT6qGRjU-- --BPFKjLaEk7OdZ3bkcTmIb9c3CpsaqhYgF Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmF5tu8FAwAAAAAACgkQ7iZktA5Y2kN1 MAf8CIpnz0nAfhhdU2rtSxNClZ8PfAEkRWk1BiHaMNz9Lq8pJHFoU8jLHVQFg3k1VfxsgRJQy3GS 8Fws74hpNoShyCTjgy9pV+pk1Wf1Hx0MtPIk7U9UBusuD/j6dHXqn8n8iTSfFk3cxATCi/Q/o4ok ebLGcx6L0PS50kiYlhikvQyhtLx6O3ya/tYxs5xL36PMUENozrpI4rx8HJsvIvevf0LmaEgxJ4OM a8e1G7MIbITY9PMtX8g6whKyMus6EiBjGzxvFlNms+Ow6HzcTNKDXH1eXq+/sQTuzwj4Sn03qtOq 3wyhGp3otUQ6wZ2jjmIkiBmHN/uU939lbZy9B8IL6w== =vpqd -----END PGP SIGNATURE----- --BPFKjLaEk7OdZ3bkcTmIb9c3CpsaqhYgF-- From nobody Wed Oct 27 16:02:32 2021 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 E8EFC3A0982; Wed, 27 Oct 2021 16:02:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163537574581.6944.17165821680236301235@ietfa.amsl.com> Date: Wed, 27 Oct 2021 16:02:25 -0700 Archived-At: Subject: [core] Constrained RESTful Environments (core) WG Virtual Meeting: 2021-12-08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2021 23:02:26 -0000 The Constrained RESTful Environments (core) WG will hold a virtual interim meeting on 2021-12-08 from 16:00 to 17:30 Europe/Stockholm (15:00 to 16:30 UTC). Agenda: (No agenda submitted) Information about remote participation: https://meetings.conf.meetecho.com/interim/?short=d0d8d377-c8f9-46ef-8708-1f13d069af9f From nobody Wed Oct 27 16:02:52 2021 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 1D7103A09E3; Wed, 27 Oct 2021 16:02:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163537576208.23758.1798823823205384048@ietfa.amsl.com> Date: Wed, 27 Oct 2021 16:02:42 -0700 Archived-At: Subject: [core] Constrained RESTful Environments (core) WG Virtual Meeting: 2022-01-19 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2021 23:02:50 -0000 The Constrained RESTful Environments (core) WG will hold a virtual interim meeting on 2022-01-19 from 16:00 to 17:30 Europe/Stockholm (15:00 to 16:30 UTC). Agenda: (No agenda submitted) Information about remote participation: https://meetings.conf.meetecho.com/interim/?short=ae5982a9-e70c-4936-b066-487e96dc93ab From nobody Wed Oct 27 16:03:08 2021 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 4C1D73A0A3B; Wed, 27 Oct 2021 16:03:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163537578027.3232.14305336975786889356@ietfa.amsl.com> Date: Wed, 27 Oct 2021 16:03:00 -0700 Archived-At: Subject: [core] Constrained RESTful Environments (core) WG Virtual Meeting: 2022-02-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2021 23:03:07 -0000 The Constrained RESTful Environments (core) WG will hold a virtual interim meeting on 2022-02-02 from 16:00 to 17:30 Europe/Stockholm (15:00 to 16:30 UTC). Agenda: (No agenda submitted) Information about remote participation: https://meetings.conf.meetecho.com/interim/?short=2691d628-2315-480d-992e-8275e383e820 From nobody Wed Oct 27 16:03:37 2021 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 1369B3A0A49; Wed, 27 Oct 2021 16:03:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163537580204.2164.17224999657197051608@ietfa.amsl.com> Date: Wed, 27 Oct 2021 16:03:22 -0700 Archived-At: Subject: [core] Constrained RESTful Environments (core) WG Virtual Meeting: 2022-02-16 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2021 23:03:30 -0000 The Constrained RESTful Environments (core) WG will hold a virtual interim meeting on 2022-02-16 from 16:00 to 17:30 Europe/Stockholm (15:00 to 16:30 UTC). Agenda: (No agenda submitted) Information about remote participation: https://meetings.conf.meetecho.com/interim/?short=7de9040c-269c-465b-b7a8-f89bd61a8549 From nobody Wed Oct 27 16:03:51 2021 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 E05763A0CDA; Wed, 27 Oct 2021 16:03:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163537581988.14648.17120070667120635959@ietfa.amsl.com> Date: Wed, 27 Oct 2021 16:03:39 -0700 Archived-At: Subject: [core] Constrained RESTful Environments (core) WG Virtual Meeting: 2022-03-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2021 23:03:47 -0000 The Constrained RESTful Environments (core) WG will hold a virtual interim meeting on 2022-03-02 from 16:00 to 17:30 Europe/Stockholm (15:00 to 16:30 UTC). Agenda: (No agenda submitted) Information about remote participation: https://meetings.conf.meetecho.com/interim/?short=68582070-4342-4d01-a2d9-fc79a2e86173 From nobody Wed Oct 27 17:23:49 2021 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 386893A1240; Wed, 27 Oct 2021 17:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 MFzeyXi2m9fH; Wed, 27 Oct 2021 17:23:43 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 066A23A12A4; Wed, 27 Oct 2021 17:23:31 -0700 (PDT) Received: from smtpclient.apple (p5089a10c.dip0.t-ipconnect.de [80.137.161.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4HfmW52tSRz2xKV; Thu, 28 Oct 2021 02:23:29 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Carsten Bormann In-Reply-To: <163519885887.7126.17571756083377155596@ietfa.amsl.com> Date: Thu, 28 Oct 2021 02:23:28 +0200 Cc: draft-ietf-core-href@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <163519885887.7126.17571756083377155596@ietfa.amsl.com> To: "core@ietf.org WG" X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [core] New Version Notification for draft-ietf-core-href-07.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 28 Oct 2021 00:23:48 -0000 Revision -07 has additional discussion on the constraints that CRIs = bring with them compared to text-based URIs (and, conversely, things you = can do in CRIs you cannot do in URIs). The ABNF also is more explicit in naming various constants. I=E2=80=99m afraid we got one of these wrong: no-authority =3D NOAUTH-NOSLASH / NOAUTH-LEADINGSLASH=09 NOAUTH-NOSLASH =3D null=09 NOAUTH-LEADINGSLASH =3D true NOAUTH-NOSLASH is not further discussed in the text, but null actually = is the value for having a leading slash in the path, while true is the = value for removing that (as in URNs, W3C DID URIs, etc.). Gr=C3=BC=C3=9Fe, Carsten > On 25. Oct 2021, at 23:54, internet-drafts@ietf.org wrote: >=20 >=20 > A new version of I-D, draft-ietf-core-href-07.txt > has been successfully submitted by Carsten Bormann and posted to the > IETF repository. >=20 > Name: draft-ietf-core-href > Revision: 07 > Title: Constrained Resource Identifiers > Document date: 2021-10-25 > Group: core > Pages: 21 > URL: = https://www.ietf.org/archive/id/draft-ietf-core-href-07.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-core-href/ > Html: = https://www.ietf.org/archive/id/draft-ietf-core-href-07.html > Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-core-href > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-href-07 >=20 > Abstract: > The Constrained Resource Identifier (CRI) is a complement to the > Uniform Resource Identifier (URI) that serializes the URI components > in Concise Binary Object Representation (CBOR) instead of a sequence > of characters. This simplifies parsing, comparison and reference > resolution in environments with severe limitations on processing > power, code size, and memory size. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 >=20 From nobody Thu Oct 28 05:37:19 2021 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 2B4FF3A0E00 for ; Thu, 28 Oct 2021 05:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 vbBIw5ke9G4c for ; Thu, 28 Oct 2021 05:37:13 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (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 26BE43A0DFF for ; Thu, 28 Oct 2021 05:37:13 -0700 (PDT) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfedar21.francetelecom.fr (ESMTP service) with ESMTPS id 4Hg4ng2Wvxz7v8Y; Thu, 28 Oct 2021 14:37:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1635424631; bh=aIZ/mNIeci/gtKdCAr24unOpuKGZ+LwAJUiiHRFe6N0=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=dVSJUsXtICr86W75X4Fyc76aCgmUw7B+nVEHTD9tkHRUsUtt7/u0D8CIHT53fylZ0 XBa4iRSNtLvhucFEOpfKLxtD9U8HKI68qAC0Hu35Euektoiqhb/8o7irbGY4xDj3Kk TvhdR98L9zbYcy5NTM7MM7sWacaTPnwvKj0+08BY80wEneU3i/s0xWcS4Nw/Z4LFtF mT9+vqDbG0kc7P+ZPX3jwFLwzd+jZZ2ctmo36B2ShayXHIytqzrH/EA9CQ23AybLQB uuKFF0R19oAW7IKNVc+KphZyAxKrHNHHUcegBYd4P2vB55WKAIZJlxetLzhvDcUPzN OBH/OSW5B1+xA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfedar01.francetelecom.fr (ESMTP service) with ESMTPS id 4Hg4ng1fDRzBrLy; Thu, 28 Oct 2021 14:37:11 +0200 (CEST) From: To: Martine Sophie Lenders , "core@ietf.org" Thread-Topic: [core] Fwd: New Version Notification for draft-lenders-dns-over-coap-02.txt Thread-Index: AQHXyeSeV+v8n05Y1U+B/+DKqkYaDqvoVKxA Content-Class: Date: Thu, 28 Oct 2021 12:37:10 +0000 Message-ID: <20544_1635424631_617A9977_20544_154_1_787AE7BB302AE849A7480A190F8B933035436EF5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <163519544260.15652.3439102117699403607@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2021-10-28T12:26:36Z; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=c2a7e065-6ebc-4b31-8750-03af72d4b4a5; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0 x-originating-ip: [10.114.13.245] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933035436EF5OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [core] Fwd: New Version Notification for draft-lenders-dns-over-coap-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 28 Oct 2021 12:37:18 -0000 --_000_787AE7BB302AE849A7480A190F8B933035436EF5OPEXCAUBMA2corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFydGluZSwgYWxsLA0KDQpGb3IgdGhpcyBpdGVtIDoNCg0KDQrigJxESENQIGFuZCBSQSBv cHRpb25zIHRvIGRlbGl2ZXI/ICBbSS1ELnBldGVyc29uLWRvaC1kaGNwXeKAnQ0KDQoNCg0KWW91 IG1heSBjb25zaWRlciBwb2ludGluZyB0byBkcmFmdC1pZXRmLWFkZC1kbnIgd2hpY2ggY2FuIGJl IHVzZWQgdG8gZGlzY292ZXIgYW55IGVuY3J5cHRlZCBETlMuIFRoaXMgd2lsbCBiYXNpY2FsbHkg cmV0dXJuIGFuIGF1dGhlbnRpY2F0aW9uIG5hbWUgKyBhIGxpc3Qgb2YgSVAgYWRkcmVzc2VzLiBU aGF0IEktRCBjb3ZlcnMgUkEsIERIQ1AsIGFuZCBESENQdjYuDQoNCg0KQ2hlZXJzLA0KTWVkDQoN CkRlIDogY29yZSA8Y29yZS1ib3VuY2VzQGlldGYub3JnPiBEZSBsYSBwYXJ0IGRlIE1hcnRpbmUg U29waGllIExlbmRlcnMNCkVudm95w6kgOiBsdW5kaSAyNSBvY3RvYnJlIDIwMjEgMjM6MDkNCsOA IDogY29yZUBpZXRmLm9yZw0KT2JqZXQgOiBbY29yZV0gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LWxlbmRlcnMtZG5zLW92ZXItY29hcC0wMi50eHQNCg0KSGkhDQoNCmFz IHByb21pc2VkIGR1cmluZyB0aGUgbGFzdCBpbnRlcmltLCB3ZSBwcm92aWRlZCBhbiB1cGRhdGUg b2Ygb3VyIGRyYWZ0IG9uIEROUyBvdmVyIENvQVAgd2hpY2ggc2hvdWxkIGFkZHJlc3MgYWxsIHRo ZSByZXF1ZXN0ZWQgY2hhbmdlcyBtYWRlIGR1cmluZyB0aGF0IG1lZXRpbmcuDQoNClRoZSBtb3N0 IGltcG9ydGFudCBjaGFuZ2VzIGVuY29tcGFzczoNCg0KLSBSZW1vdmUgR0VUIGFuZCBQT1NUIG1l dGhvZHMNCi0gQWRkIG5vdGUgb24gRVRhZyBvcHRpb24gYW5kIHJlc3BvbnNlIGNvZGVzDQotIFBy b3ZpZGUgcmVxdWlyZW1lbnQgY29uZmxpY3QgZm9yIEROUyBvdmVyIFFVSUMNCi0gQ2xhcmlmeSBD b250ZW50LUZvcm1hdCAvIEFjY2VwdCBoYW5kbGluZw0KDQpDb21tZW50cyBhcmUsIGFzIGFsd2F5 cywgdmVyeSBtdWNoIHdlbGNvbWUuDQoNClRoYW5rcywNCk1hcnRpbmUNCm9uIGJlaGFsdmUgb2Yg YWxsIGNvLWF1dGhvcnMNCg0KLS0tLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLS0tLQ0KU3Vi amVjdDoNCg0KTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1sZW5kZXJzLWRucy1v dmVyLWNvYXAtMDIudHh0DQoNCkRhdGU6DQoNCk1vbiwgMjUgT2N0IDIwMjEgMTM6NTc6MjIgLTA3 MDANCg0KRnJvbToNCg0KaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmc+DQoNClRvOg0KDQpUaG9tYXMgQy4gU2NobWlkdCA8dC5zY2htaWR0QGhh dy1oYW1idXJnLmRlPjxtYWlsdG86dC5zY2htaWR0QGhhdy1oYW1idXJnLmRlPiwgQ2VuayBHw7xu ZG/En2FuIDxjZW5rLmd1ZW5kb2dhbkBoYXctaGFtYnVyZy5kZT48bWFpbHRvOmNlbmsuZ3VlbmRv Z2FuQGhhdy1oYW1idXJnLmRlPiwgQ2hyaXN0aWFuIEFtc8O8c3MgPGNocmlzdGlhbkBhbXN1ZXNz LmNvbT48bWFpbHRvOmNocmlzdGlhbkBhbXN1ZXNzLmNvbT4sIE1hdHRoaWFzIFfDpGhsaXNjaCA8 bS53YWVobGlzY2hAZnUtYmVybGluLmRlPjxtYWlsdG86bS53YWVobGlzY2hAZnUtYmVybGluLmRl PiwgTWFydGluZSBTb3BoaWUgTGVuZGVycyA8bS5sZW5kZXJzQGZ1LWJlcmxpbi5kZT48bWFpbHRv Om0ubGVuZGVyc0BmdS1iZXJsaW4uZGU+DQoNCg0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBk cmFmdC1sZW5kZXJzLWRucy1vdmVyLWNvYXAtMDIudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkg c3VibWl0dGVkIGJ5IE1hcnRpbmUgTGVuZGVycyBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBv c2l0b3J5Lg0KDQpOYW1lOiBkcmFmdC1sZW5kZXJzLWRucy1vdmVyLWNvYXANClJldmlzaW9uOiAw Mg0KVGl0bGU6IEROUyBRdWVyaWVzIG92ZXIgQ29BUCAoRG9DKQ0KRG9jdW1lbnQgZGF0ZTogMjAy MS0xMC0yNQ0KR3JvdXA6IEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6IDEzDQpVUkw6IGh0 dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtbGVuZGVycy1kbnMtb3Zlci1jb2Fw LTAyLnR4dA0KU3RhdHVzOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1s ZW5kZXJzLWRucy1vdmVyLWNvYXAvDQpIdG1sOiBodHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZl L2lkL2RyYWZ0LWxlbmRlcnMtZG5zLW92ZXItY29hcC0wMi5odG1sDQpIdG1saXplZDogaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1sZW5kZXJzLWRucy1vdmVyLWNv YXANCkRpZmY6IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1sZW5kZXJz LWRucy1vdmVyLWNvYXAtMDINCg0KQWJzdHJhY3Q6DQpUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBw cm90b2NvbCBmb3Igc2VuZGluZyBETlMgbWVzc2FnZXMgb3ZlciB0aGUNCkNvbnN0cmFpbmVkIEFw cGxpY2F0aW9uIFByb3RvY29sIChDb0FQKS4gVGhlc2UgQ29BUCBtZXNzYWdlcyBhcmUNCnByb3Rl Y3RlZCBieSBEVExTLVNlY3VyZWQgQ29BUCAoQ29BUFMpIG9yIE9iamVjdCBTZWN1cml0eSBmb3IN CkNvbnN0cmFpbmVkIFJFU1RmdWwgRW52aXJvbm1lbnRzIChPU0NPUkUpIHRvIHByb3ZpZGUgZW5j cnlwdGVkIEROUw0KbWVzc2FnZSBleGNoYW5nZSBmb3IgY29uc3RyYWluZWQgZGV2aWNlcyBpbiB0 aGUgSW50ZXJuZXQgb2YgVGhpbmdzDQooSW9UKS4NCg0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0 DQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250 ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQg bmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNh bnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIs IHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNp IHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50 IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNh YmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBN ZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZp ZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBi eSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0 aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVy cm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5k IGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90 IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3Ig ZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= --_000_787AE7BB302AE849A7480A190F8B933035436EF5OPEXCAUBMA2corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHRpdGxl PkZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1sZW5kZXJzLWRucy1vdmVy LWNvYXAtMDIudHh0PC90aXRsZT4NCjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICov DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIg NCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0K CXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsN CgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uUHJmb3JtYXRIVE1MQ2FyDQoJe21zby1zdHlsZS1u YW1lOiJQcsOpZm9ybWF0w6kgSFRNTCBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiUHLDqWZvcm1hdMOpIEhUTUwiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0Kc3Bhbi5oMQ0KCXttc28tc3R5bGUtbmFtZTpoMTt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3 MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZSIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGkgTWFydGluZSwgYWxsLA0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPkZvciB0aGlzIGl0ZW0mbmJzcDs6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4gbGFu Zz0iRU4tVVMiPuKAnERIQ1AgYW5kIFJBIG9wdGlvbnMgdG8gZGVsaXZlcj8mbmJzcDsgW0ktRC5w ZXRlcnNvbi1kb2gtZGhjcF3igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs YW5nPSJFTi1VUyI+WW91IG1heSBjb25zaWRlciBwb2ludGluZyB0byA8c3BhbiBjbGFzcz0iaDEi PmRyYWZ0LWlldGYtYWRkLWRuciB3aGljaCBjYW4gYmUgdXNlZCB0byBkaXNjb3ZlciBhbnkgZW5j cnlwdGVkIEROUy4gVGhpcyB3aWxsIGJhc2ljYWxseSByZXR1cm4gYW4gYXV0aGVudGljYXRpb24g bmFtZSAmIzQzOyBhIGxpc3Qgb2YgSVAgYWRkcmVzc2VzLiBUaGF0IEktRCBjb3ZlcnMgUkEsIERI Q1AsIGFuZCBESENQdjYuPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBjbGFzcz0iaDEiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPk1lZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5E ZSZuYnNwOzo8L2I+IGNvcmUgJmx0O2NvcmUtYm91bmNlc0BpZXRmLm9yZyZndDsgPGI+RGUgbGEg cGFydCBkZTwvYj4gTWFydGluZSBTb3BoaWUgTGVuZGVyczxicj4NCjxiPkVudm95w6kmbmJzcDs6 PC9iPiBsdW5kaSAyNSBvY3RvYnJlIDIwMjEgMjM6MDk8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IGNv cmVAaWV0Zi5vcmc8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFtjb3JlXSBGd2Q6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGVuZGVycy1kbnMtb3Zlci1jb2FwLTAyLnR4dDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkhPGJyPg0KPGJyPg0KYXMg cHJvbWlzZWQgZHVyaW5nIHRoZSBsYXN0IGludGVyaW0sIHdlIHByb3ZpZGVkIGFuIHVwZGF0ZSBv ZiBvdXIgZHJhZnQgb24gRE5TIG92ZXIgQ29BUCB3aGljaCBzaG91bGQgYWRkcmVzcyBhbGwgdGhl IHJlcXVlc3RlZCBjaGFuZ2VzIG1hZGUgZHVyaW5nIHRoYXQgbWVldGluZy48YnI+DQo8YnI+DQpU aGUgbW9zdCBpbXBvcnRhbnQgY2hhbmdlcyBlbmNvbXBhc3M6PGJyPg0KPGJyPg0KLSBSZW1vdmUg R0VUIGFuZCBQT1NUIG1ldGhvZHM8YnI+DQotIEFkZCBub3RlIG9uIEVUYWcgb3B0aW9uIGFuZCBy ZXNwb25zZSBjb2Rlczxicj4NCi0gUHJvdmlkZSByZXF1aXJlbWVudCBjb25mbGljdCBmb3IgRE5T IG92ZXIgUVVJQzxicj4NCi0gQ2xhcmlmeSBDb250ZW50LUZvcm1hdCAvIEFjY2VwdCBoYW5kbGlu ZyA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpDb21t ZW50cyBhcmUsIGFzIGFsd2F5cywgdmVyeSBtdWNoIHdlbGNvbWUuPGJyPg0KPGJyPg0KVGhhbmtz LDxicj4NCk1hcnRpbmU8YnI+DQpvbiBiZWhhbHZlIG9mIGFsbCBjby1hdXRob3JzPGJyPg0KPGJy Pg0KLS0tLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLS0tLSA8bzpwPjwvbzpwPjwvcD4NCjx0 YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNl bGxwYWRkaW5nPSIwIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3Ai IHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBh bGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48Yj5TdWJqZWN0OiA8bzpwPjwv bzpwPjwvYj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5OZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LWxlbmRlcnMtZG5zLW92ZXItY29hcC0wMi50eHQ8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3Ry Pg0KPHRyPg0KPHRkIG5vd3JhcD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGNtIDBj bSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRl eHQtYWxpZ246cmlnaHQiPjxiPkRhdGU6IDxvOnA+PC9vOnA+PC9iPjwvcD4NCjwvdGQ+DQo8dGQg c3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1v biwgMjUgT2N0IDIwMjEgMTM6NTc6MjIgLTA3MDA8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3Ry Pg0KPHRyPg0KPHRkIG5vd3JhcD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGNtIDBj bSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRl eHQtYWxpZ246cmlnaHQiPjxiPkZyb206IDxvOnA+PC9vOnA+PC9iPjwvcD4NCjwvdGQ+DQo8dGQg c3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxh IGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPmludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIG5vd3Jh cD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmlnaHQiPjxi PlRvOiA8bzpwPjwvbzpwPjwvYj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaG9tYXMgQy4gU2NobWlkdCA8YSBo cmVmPSJtYWlsdG86dC5zY2htaWR0QGhhdy1oYW1idXJnLmRlIj4NCiZsdDt0LnNjaG1pZHRAaGF3 LWhhbWJ1cmcuZGUmZ3Q7PC9hPiwgQ2VuayBHw7xuZG/En2FuIDxhIGhyZWY9Im1haWx0bzpjZW5r Lmd1ZW5kb2dhbkBoYXctaGFtYnVyZy5kZSI+DQombHQ7Y2Vuay5ndWVuZG9nYW5AaGF3LWhhbWJ1 cmcuZGUmZ3Q7PC9hPiwgQ2hyaXN0aWFuIEFtc8O8c3MgPGEgaHJlZj0ibWFpbHRvOmNocmlzdGlh bkBhbXN1ZXNzLmNvbSI+DQombHQ7Y2hyaXN0aWFuQGFtc3Vlc3MuY29tJmd0OzwvYT4sIE1hdHRo aWFzIFfDpGhsaXNjaCA8YSBocmVmPSJtYWlsdG86bS53YWVobGlzY2hAZnUtYmVybGluLmRlIj4N CiZsdDttLndhZWhsaXNjaEBmdS1iZXJsaW4uZGUmZ3Q7PC9hPiwgTWFydGluZSBTb3BoaWUgTGVu ZGVycyA8YSBocmVmPSJtYWlsdG86bS5sZW5kZXJzQGZ1LWJlcmxpbi5kZSI+DQombHQ7bS5sZW5k ZXJzQGZ1LWJlcmxpbi5kZSZndDs8L2E+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwv dGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OndoaXRlIj48YnI+DQo8L3NwYW4+PGJyPg0KPGJyPg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy YWZ0LWxlbmRlcnMtZG5zLW92ZXItY29hcC0wMi50eHQ8YnI+DQpoYXMgYmVlbiBzdWNjZXNzZnVs bHkgc3VibWl0dGVkIGJ5IE1hcnRpbmUgTGVuZGVycyBhbmQgcG9zdGVkIHRvIHRoZTxicj4NCklF VEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+DQpOYW1lOiBkcmFmdC1sZW5kZXJzLWRucy1vdmVyLWNv YXA8YnI+DQpSZXZpc2lvbjogMDI8YnI+DQpUaXRsZTogRE5TIFF1ZXJpZXMgb3ZlciBDb0FQIChE b0MpPGJyPg0KRG9jdW1lbnQgZGF0ZTogMjAyMS0xMC0yNTxicj4NCkdyb3VwOiBJbmRpdmlkdWFs IFN1Ym1pc3Npb248YnI+DQpQYWdlczogMTM8YnI+DQpVUkw6IDxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtbGVuZGVycy1kbnMtb3Zlci1jb2FwLTAyLnR4dCI+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LWxlbmRlcnMtZG5zLW92ZXIt Y29hcC0wMi50eHQ8L2E+PGJyPg0KU3RhdHVzOiA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1sZW5kZXJzLWRucy1vdmVyLWNvYXAvIj5odHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1sZW5kZXJzLWRucy1vdmVyLWNvYXAvPC9hPjxicj4N Ckh0bWw6IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtbGVu ZGVycy1kbnMtb3Zlci1jb2FwLTAyLmh0bWwiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2 ZS9pZC9kcmFmdC1sZW5kZXJzLWRucy1vdmVyLWNvYXAtMDIuaHRtbDwvYT48YnI+DQpIdG1saXpl ZDogPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1s ZW5kZXJzLWRucy1vdmVyLWNvYXAiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv aHRtbC9kcmFmdC1sZW5kZXJzLWRucy1vdmVyLWNvYXA8L2E+PGJyPg0KRGlmZjogPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWxlbmRlcnMtZG5zLW92ZXIt Y29hcC0wMiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbGVuZGVy cy1kbnMtb3Zlci1jb2FwLTAyPC9hPjxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4NClRoaXMgZG9j dW1lbnQgZGVmaW5lcyBhIHByb3RvY29sIGZvciBzZW5kaW5nIEROUyBtZXNzYWdlcyBvdmVyIHRo ZTxicj4NCkNvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29sIChDb0FQKS4gVGhlc2UgQ29B UCBtZXNzYWdlcyBhcmU8YnI+DQpwcm90ZWN0ZWQgYnkgRFRMUy1TZWN1cmVkIENvQVAgKENvQVBT KSBvciBPYmplY3QgU2VjdXJpdHkgZm9yPGJyPg0KQ29uc3RyYWluZWQgUkVTVGZ1bCBFbnZpcm9u bWVudHMgKE9TQ09SRSkgdG8gcHJvdmlkZSBlbmNyeXB0ZWQgRE5TPGJyPg0KbWVzc2FnZSBleGNo YW5nZSBmb3IgY29uc3RyYWluZWQgZGV2aWNlcyBpbiB0aGUgSW50ZXJuZXQgb2YgVGhpbmdzPGJy Pg0KKElvVCkuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KVGhlIElFVEYgU2VjcmV0YXJpYXQ8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxQUkU+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVz c2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRp b25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBh cyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBT aSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25h bGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpv aW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2Fs dGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3Nh Z2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxl Z2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxk IG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9u LgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5 IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4K QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2Fn ZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5 b3UuCjwvUFJFPjwvYm9keT4NCjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B933035436EF5OPEXCAUBMA2corp_-- From nobody Thu Oct 28 10:34:12 2021 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 728873A08C0 for ; Thu, 28 Oct 2021 10:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.248 X-Spam-Level: X-Spam-Status: No, score=-5.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-3.33, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, 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 0lGHghdZaxyT for ; Thu, 28 Oct 2021 10:34:04 -0700 (PDT) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 9C1C43A08BE for ; Thu, 28 Oct 2021 10:34:04 -0700 (PDT) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.94) with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (envelope-from ) id 1mg9Ht-000OX3-4Y; Thu, 28 Oct 2021 19:34:01 +0200 Received: from [5.61.189.164] (helo=[192.168.101.6]) by inpost2.zedat.fu-berlin.de (Exim 4.94) with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (envelope-from ) id 1mg9Hs-001MBk-BZ; Thu, 28 Oct 2021 19:34:01 +0200 Message-ID: <9886223e-8851-22e0-136e-2a20e8c50a50@fu-berlin.de> Date: Thu, 28 Oct 2021 19:33:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 Content-Language: en-US To: mohamed.boucadair@orange.com, "core@ietf.org" References: <163519544260.15652.3439102117699403607@ietfa.amsl.com> <20544_1635424631_617A9977_20544_154_1_787AE7BB302AE849A7480A190F8B933035436EF5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Martine Sophie Lenders In-Reply-To: <20544_1635424631_617A9977_20544_154_1_787AE7BB302AE849A7480A190F8B933035436EF5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------Deq0pmXRoBbOqlyPfAOuc29h" X-Original-Sender: m.lenders@fu-berlin.de X-Originating-IP: 5.61.189.164 X-ZEDAT-Hint: A Archived-At: Subject: Re: [core] Fwd: New Version Notification for draft-lenders-dns-over-coap-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 28 Oct 2021 17:34:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------Deq0pmXRoBbOqlyPfAOuc29h Content-Type: multipart/mixed; boundary="------------y40Td6W8CbedxQLE033tzIg4"; protected-headers="v1" From: Martine Sophie Lenders To: mohamed.boucadair@orange.com, "core@ietf.org" Message-ID: <9886223e-8851-22e0-136e-2a20e8c50a50@fu-berlin.de> Subject: Re: [core] Fwd: New Version Notification for draft-lenders-dns-over-coap-02.txt References: <163519544260.15652.3439102117699403607@ietfa.amsl.com> <20544_1635424631_617A9977_20544_154_1_787AE7BB302AE849A7480A190F8B933035436EF5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <20544_1635424631_617A9977_20544_154_1_787AE7BB302AE849A7480A190F8B933035436EF5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> --------------y40Td6W8CbedxQLE033tzIg4 Content-Type: multipart/mixed; boundary="------------NwMutl0FEyL4JLrRXfAkZR33" --------------NwMutl0FEyL4JLrRXfAkZR33 Content-Type: multipart/alternative; boundary="------------1ueFLOE19KMRVBB70j3prldA" --------------1ueFLOE19KMRVBB70j3prldA Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 SGkgTWVkLA0KDQp3aGlsZSBvdXIgbWFpbiBpZGVhIHNvIGZhciB3YXMgdG8gZGlzY292ZXIg dGhlIERvQyByZXNvdXJjZSB2aWEgQ29SRS1SRCwgDQp0aGlzIGlzIGRlZmluaXRlbHkgc29t ZXRoaW5nIHRvIGxvb2sgaW50byBhcyBhIGZhbGxiYWNrIG9yIGFsdGVybmF0aXZlIA0KZGlz Y292ZXJ5IG9wdGlvbi4NCg0KQ2hlZXJzLA0KTWFydGluZQ0KDQpBbSAyOC4xMC4yMSB1bSAx NDozNyBzY2hyaWViIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb206DQo+IEZ3ZDogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1sZW5kZXJzLWRucy1vdmVyLWNvYXAt MDIudHh0DQo+DQo+IEhpIE1hcnRpbmUsIGFsbCwNCj4NCj4gRm9yIHRoaXMgaXRlbcKgOg0K Pg0KPiDigJxESENQIGFuZCBSQSBvcHRpb25zIHRvIGRlbGl2ZXI/wqAgW0ktRC5wZXRlcnNv bi1kb2gtZGhjcF3igJ0NCj4gWW91IG1heSBjb25zaWRlciBwb2ludGluZyB0byBkcmFmdC1p ZXRmLWFkZC1kbnIgd2hpY2ggY2FuIGJlIHVzZWQgdG8gDQo+IGRpc2NvdmVyIGFueSBlbmNy eXB0ZWQgRE5TLiBUaGlzIHdpbGwgYmFzaWNhbGx5IHJldHVybiBhbiANCj4gYXV0aGVudGlj YXRpb24gbmFtZSArIGEgbGlzdCBvZiBJUCBhZGRyZXNzZXMuIFRoYXQgSS1EIGNvdmVycyBS QSwgDQo+IERIQ1AsIGFuZCBESENQdjYuDQo+DQo+IENoZWVycywNCj4NCj4gTWVkDQo+DQo+ ICpEZcKgOiogY29yZSA8Y29yZS1ib3VuY2VzQGlldGYub3JnPiAqRGUgbGEgcGFydCBkZSog TWFydGluZSBTb3BoaWUgTGVuZGVycw0KPiAqRW52b3nDqcKgOiogbHVuZGkgMjUgb2N0b2Jy ZSAyMDIxIDIzOjA5DQo+ICrDgMKgOiogY29yZUBpZXRmLm9yZw0KPiAqT2JqZXTCoDoqIFtj b3JlXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgDQo+IGRyYWZ0LWxlbmRl cnMtZG5zLW92ZXItY29hcC0wMi50eHQNCj4NCj4gSGkhDQo+DQo+IGFzIHByb21pc2VkIGR1 cmluZyB0aGUgbGFzdCBpbnRlcmltLCB3ZSBwcm92aWRlZCBhbiB1cGRhdGUgb2Ygb3VyIA0K PiBkcmFmdCBvbiBETlMgb3ZlciBDb0FQIHdoaWNoIHNob3VsZCBhZGRyZXNzIGFsbCB0aGUg cmVxdWVzdGVkIGNoYW5nZXMgDQo+IG1hZGUgZHVyaW5nIHRoYXQgbWVldGluZy4NCj4NCj4g VGhlIG1vc3QgaW1wb3J0YW50IGNoYW5nZXMgZW5jb21wYXNzOg0KPg0KPiAtIFJlbW92ZSBH RVQgYW5kIFBPU1QgbWV0aG9kcw0KPiAtIEFkZCBub3RlIG9uIEVUYWcgb3B0aW9uIGFuZCBy ZXNwb25zZSBjb2Rlcw0KPiAtIFByb3ZpZGUgcmVxdWlyZW1lbnQgY29uZmxpY3QgZm9yIERO UyBvdmVyIFFVSUMNCj4gLSBDbGFyaWZ5IENvbnRlbnQtRm9ybWF0IC8gQWNjZXB0IGhhbmRs aW5nDQo+DQo+DQo+IENvbW1lbnRzIGFyZSwgYXMgYWx3YXlzLCB2ZXJ5IG11Y2ggd2VsY29t ZS4NCj4NCj4gVGhhbmtzLA0KPiBNYXJ0aW5lDQo+IG9uIGJlaGFsdmUgb2YgYWxsIGNvLWF1 dGhvcnMNCj4NCj4gLS0tLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLS0tLQ0KPg0KPiAq U3ViamVjdDogKg0KPg0KPiAJDQo+DQo+IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig ZHJhZnQtbGVuZGVycy1kbnMtb3Zlci1jb2FwLTAyLnR4dA0KPg0KPiAqRGF0ZTogKg0KPg0K PiAJDQo+DQo+IE1vbiwgMjUgT2N0IDIwMjEgMTM6NTc6MjIgLTA3MDANCj4NCj4gKkZyb206 ICoNCj4NCj4gCQ0KPg0KPiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCj4NCj4gKlRvOiAq DQo+DQo+IAkNCj4NCj4gVGhvbWFzIEMuIFNjaG1pZHQgPHQuc2NobWlkdEBoYXctaGFtYnVy Zy5kZT4gDQo+IDxtYWlsdG86dC5zY2htaWR0QGhhdy1oYW1idXJnLmRlPiwgQ2VuayBHw7xu ZG/En2FuIA0KPiA8Y2Vuay5ndWVuZG9nYW5AaGF3LWhhbWJ1cmcuZGU+IA0KPiA8bWFpbHRv OmNlbmsuZ3VlbmRvZ2FuQGhhdy1oYW1idXJnLmRlPiwgQ2hyaXN0aWFuIEFtc8O8c3MgDQo+ IDxjaHJpc3RpYW5AYW1zdWVzcy5jb20+IDxtYWlsdG86Y2hyaXN0aWFuQGFtc3Vlc3MuY29t PiwgTWF0dGhpYXMgDQo+IFfDpGhsaXNjaCA8bS53YWVobGlzY2hAZnUtYmVybGluLmRlPiA8 bWFpbHRvOm0ud2FlaGxpc2NoQGZ1LWJlcmxpbi5kZT4sIA0KPiBNYXJ0aW5lIFNvcGhpZSBM ZW5kZXJzIDxtLmxlbmRlcnNAZnUtYmVybGluLmRlPiANCj4gPG1haWx0bzptLmxlbmRlcnNA ZnUtYmVybGluLmRlPg0KPg0KPg0KPg0KPg0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJh ZnQtbGVuZGVycy1kbnMtb3Zlci1jb2FwLTAyLnR4dA0KPiBoYXMgYmVlbiBzdWNjZXNzZnVs bHkgc3VibWl0dGVkIGJ5IE1hcnRpbmUgTGVuZGVycyBhbmQgcG9zdGVkIHRvIHRoZQ0KPiBJ RVRGIHJlcG9zaXRvcnkuDQo+DQo+IE5hbWU6IGRyYWZ0LWxlbmRlcnMtZG5zLW92ZXItY29h cA0KPiBSZXZpc2lvbjogMDINCj4gVGl0bGU6IEROUyBRdWVyaWVzIG92ZXIgQ29BUCAoRG9D KQ0KPiBEb2N1bWVudCBkYXRlOiAyMDIxLTEwLTI1DQo+IEdyb3VwOiBJbmRpdmlkdWFsIFN1 Ym1pc3Npb24NCj4gUGFnZXM6IDEzDQo+IFVSTDogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJj aGl2ZS9pZC9kcmFmdC1sZW5kZXJzLWRucy1vdmVyLWNvYXAtMDIudHh0DQo+IFN0YXR1czog aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGVuZGVycy1kbnMtb3Zl ci1jb2FwLw0KPiBIdG1sOiBodHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0 LWxlbmRlcnMtZG5zLW92ZXItY29hcC0wMi5odG1sDQo+IEh0bWxpemVkOiANCj4gaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1sZW5kZXJzLWRucy1vdmVy LWNvYXANCj4gRGlmZjogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0 LWxlbmRlcnMtZG5zLW92ZXItY29hcC0wMg0KPg0KPiBBYnN0cmFjdDoNCj4gVGhpcyBkb2N1 bWVudCBkZWZpbmVzIGEgcHJvdG9jb2wgZm9yIHNlbmRpbmcgRE5TIG1lc3NhZ2VzIG92ZXIg dGhlDQo+IENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29sIChDb0FQKS4gVGhlc2Ug Q29BUCBtZXNzYWdlcyBhcmUNCj4gcHJvdGVjdGVkIGJ5IERUTFMtU2VjdXJlZCBDb0FQIChD b0FQUykgb3IgT2JqZWN0IFNlY3VyaXR5IGZvcg0KPiBDb25zdHJhaW5lZCBSRVNUZnVsIEVu dmlyb25tZW50cyAoT1NDT1JFKSB0byBwcm92aWRlIGVuY3J5cHRlZCBETlMNCj4gbWVzc2Fn ZSBleGNoYW5nZSBmb3IgY29uc3RyYWluZWQgZGV2aWNlcyBpbiB0aGUgSW50ZXJuZXQgb2Yg VGhpbmdzDQo+IChJb1QpLg0KPg0KPg0KPg0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPg0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+DQo+IENlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVz IHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3Ug cHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KPiBwYXMgZXRyZSBkaWZmdXNlcywg ZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJl Y3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KPiBhIGwn ZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVz LiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRl cmF0aW9uLA0KPiBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBt ZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQo+DQo+ IFRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBi eSBsYXc7DQo+IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3Bp ZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KPiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0 aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCj4gQXMgZW1haWxzIG1heSBiZSBh bHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJl ZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KPiBUaGFuayB5b3UuDQoNCg== --------------1ueFLOE19KMRVBB70j3prldA Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Med,

while our main idea so far was to discover the DoC resource via CoRE-RD, this is definitely something to look into as a fallback or alternative discovery option.

Cheers,
Martine

Am 28.10.21 um 14:37 schrieb mohamed.boucadair@orange.com:
Fwd: New Version Notification for draft-lenders-dns-over-coap-02.txt

Hi Martine, all,

=C2= =A0

For this= item=C2=A0:

=C2= =A0

=E2=80=9CDHCP and RA options to deliver=
?=C2=A0 [I-D.peterson-doh-dhcp]=E2=80=9D
=C2=A0
You may consider pointing to draft-ietf-add-dnr which can be used to discover any encrypted D=
NS. This will basically return an authentication name + a list of IP addr=
esses. That I-D covers RA, DHCP, and DHCPv6.
        
=C2=A0

        
Cheers,<=
o:p>

        
Med=


        
=C2=
=A0

        

          

            

              
De=C2=A0: core
                <core-bounces@ietf.org> De la part de
                Martine Sophie Lenders

                Envoy=C3=A9=C2=A0: lundi 25 octobre 2021 23:09
=

                =C3=80=C2=A0: core@ietf.org

                Objet=C2=A0: [core] Fwd: New Version Notification =
for
                draft-lenders-dns-over-coap-02.txt

            

          

          
=C2=A0

          
Hi!

            

            as promised during the last interim, we provided an update
            of our draft on DNS over CoAP which should address all the
            requested changes made during that meeting.

            

            The most important changes encompass:

            

            - Remove GET and POST methods

            - Add note on ETag option and response codes

            - Provide requirement conflict for DNS over QUIC

            - Clarify Content-Format / Accept handling 

          

            


              Comments are, as always, very much welcome.

              

              Thanks,

              Martine

              on behalve of all co-authors

              

              -------- Original Message -------- 

            

              
                

                  
                    
Subject: 

                  		
                  
                    
New Version Notification for
                      draft-lenders-dns-over-coap-02.txt

                  		
                

                

                  
                    
Date: 

                  		
                  
                    
Mon, 25 Oct 2021 13:57:22 -070=
0

                  		
                

                

                  
                    
From: 

                  		
                  
                    
internet-drafts@i=
etf.org

                  		
                

                

                  
                    
To: 

                  		
                  
                    
Thomas C. Schmidt 
                        <t.schmidt@haw-hamburg.de>, Cenk
                      G=C3=BCndo=C4=9Fan 
                        <cenk.guendogan@haw-hamburg.de>,
                      Christian Ams=C3=BCss 
                        <christian@amsuess.com>, Matthias
                      W=C3=A4hlisch 
                        <m.waehlisch@fu-berlin.de>, Martine
                      Sophie Lenders 
                        <m.lenders@fu-berlin.de>
=

                  		
                

              
            

            


              

              

              A new version of I-D, draft-lenders-dns-over-coap-02.txt
              has been successfully submitted by Martine Lenders and
              posted to the

              IETF repository.

              

              Name: draft-lenders-dns-over-coap

              Revision: 02

              Title: DNS Queries over CoAP (DoC)

              Document date: 2021-10-25

              Group: Individual Submission

              Pages: 13

              URL: =

https://www.ietf.org/archive/id/draft-lenders-dns-over-coap-02.txt
              Status: =
https://datatracker.ietf.org/doc/draft-lenders-dns-over-coap/

              Html: =

https://www.ietf.org/archive/id/draft-lenders-dns-over-coap-02.html
              Htmlized: =

https://datatracker.ietf.org/doc/html/draft-lenders-dns-over-coap
=

              Diff: =

https://www.ietf.org/rfcdiff?url2=3Ddraft-lenders-dns-over-coap-02
              

              Abstract:

              This document defines a protocol for sending DNS messages
              over the

              Constrained Application Protocol (CoAP). These CoAP
              messages are

              protected by DTLS-Secured CoAP (CoAPS) or Object Security
              for

              Constrained RESTful Environments (OSCORE) to provide
              encrypted DNS

              message exchange for constrained devices in the Internet
              of Things

              (IoT).

              

              

              

              The IETF Secretariat

          

        

      
______________________________________________________________=
___________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confid=
entielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re=
cu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages =
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme o=
u falsifie. Merci.

This message and its attachments may contain confidential or privileged i=
nformation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
Thank you.

--------------1ueFLOE19KMRVBB70j3prldA-- --------------NwMutl0FEyL4JLrRXfAkZR33 Content-Type: application/pgp-keys; name="OpenPGP_0xD3555B9E03C098C7.asc" Content-Disposition: attachment; filename="OpenPGP_0xD3555B9E03C098C7.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBGDso7IBEADGJRHw9WPIiLpHpqA9+lHqTPM9ydRG1E4QSjKrJjWzk63HE1SUEnrHR/1ag= Qqk tn6Q3Zx0ezeQdaE/09AiKPnLKLwX/KQNINe1RzADakj3CjwGApPIox7D19VJ+qqNAPZmu/DXB= Reh LzjJlCfbIkkijCZP6A2okYrhpmm8i0ZD6koH3BChpdut9R2dsSPGt5ZKG6J18z+jh0Ond0vqN= dPw RVa6zF8XyYE3q76OqmZHS3FOp2KX2Yl0Mw2AYvqsnbzLKSm64gv0wvZm+jED1LQAhnFGEIJ/1= B8o 2jAzmr414w9iMalMA2RcIsw4sDIJE45/9gweJv+/u2Ocy+vbbIwdBB7chE1lcghTEIBZqNHxC= AEm xcX//IPSt4TmX2AIdT1rNYl9uZ3F23DTqAfnNx7ZBj7/51EGB/ip+M7Gxy+HM9O0Ob18TkT3Q= 7al aOmu36EhpaJ29x0o+IdWlUxFSByYMKoGvyZatZtME8fkUg8qjLk5uaQ7TvdFhjjhgsvy0XkNf= 8Ff tHply5G6gh72sXAGncltXWMQGcf2TkB9qOtPkHipSq4g9W40bhp2awOdRlyi5LoTu3kzoabEd= gZj KC190a8jYYu30Of1tqHvykSKPQcGzDsFzpa2N+Oj/EUdFlGbdOpTz3/gj1To87bZqD5z2sz1h= 7nJ Va4JLUcBYkgZeQARAQABzTBNYXJ0aW5lIFNvcGhpZSBMZW5kZXJzIDxtYWlsQG1hcnRpbmUtb= GVu ZGVycy5ldT7CwZcEEwEKAEECGwMFCQPCZwAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AWIQSGM= a6u CWMHSOh6ioXTVVueA8CYxwUCYOylmwIZAQAKCRDTVVueA8CYxzkHD/4teYlsF9CZYcD300/dI= z+k svsxg9S8gc4DfQwPClzDWshSblv8LZzqwFCFOmh/AxI5zjdY4NGWOKUk4fxmlErD0faInJSON= oi3 myW71YLtQF68l7hez6CCFAIvXmCdH5AqmB1gVckvT66KK15dNPIEwrY1brNNxANBDvh2o4kuO= ZwL PaBjIBw31yFRtHxDdvOVek8WKIniEpj9oYQJ09Op7P5j+Id01fphrPHTTbo0v4ZiL8UcZj77P= Q3U IsAiniyo7TroepnyvxuInYWKcvT4zU9kdg/S9hdj67pqSvTk8VMEE5h70wVSVma/HElQdl8Zs= kR7 b/HvgzMsN5Jr+OvRP7R7tW5n1rbSnnmgAxSy7wxJiRTb+sFPUkOwTNRKU+QSs6OQRX+IpgYki= BQK w2gb76BXVrTUzEQV6gg6BZlyCTxpv/RZF47+lLeCZka9lSie3cUjN2CZLdKi8F6nWxm3bh9VT= 4TM 866KtomgDsTrBimXK184dTflzM80QE/wIfVCAuhtQWLPwHee5/PmoFn3egjqsQTqogkiMZWu7= wX+ 9QN5keD6uF9RHR1elzcK0761PfejnC5UsKq3GN7/Bg/nZg6Gp63YnIr+0Ihu78Nn+LsAo29tk= O7g jX4wrRGb86Gs9NXxljo50hNzSuFmx5VYxn8p8/Tj8pfOqizGdJyoX80vTWFydGluZSBTb3Boa= WUg TGVuZGVycyA8bS5sZW5kZXJzQGZ1LWJlcmxpbi5kZT7CwZQEEwEKAD4WIQSGMa6uCWMHSOh6i= oXT VVueA8CYxwUCYOyksQIbAwUJA8JnAAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRDTVVueA= 8CY xz+hD/0SpVUL2uudqFqgMIVJm8DjPQ/Kgu1UOZSGnV8UyhffZVT8POJrC4ve2JU02hBiY0Rat= aJh fWd7iJ3cSD7m4BbvxtDEfc+5t54Qe8c3jWse9XMNXFxbp6ZDRPgfNMO5G+cfgAaUYgbuAQvOv= x6n xbB4jQcYYlrZZpRLC86vvu8SUoP/NOxqWZ/Cfve6/rtTD3gnsuUIvuJHTI1OFpFr7AX8phYGr= hQo q1xdfimmnHj9KEdXgK9JGhEhz5RcpcozjVIrYHowKr1azDue7BZqXhi7TpVM+dsXgHeINm85S= 60o 6aWS+Kj2rpv5vdBmp4YAsakaiLJsbYfM8nb6zzKFkW4SeMoY388w5pZ/wUb8vwHym65t62CcA= y8Q mSIiM59Geyehv6Yjv3uOjGFYF7a/FCTQiXfHE4ZLoDugtV7yUoFFw0VVvrWUbcRcpRjDVFV2f= uZg JivyCH9ws+9jwsc0+v7IJUJwN5dvv+wRZmd0XmbqOCVb8RgO+Q9asDWB1mZjXaf5e88HAUOt1= ZRK 7sqlWDEqemNpeohdo9ujLqoF/5Dhh2swV7DldpgNoHl7Ct0b6DXRhP2OeaqhiNet82Qnszxpj= tm+ /+bC2KTe/n8tkl36IGMOG3IlWiEfDGeH1W1D3shZHUoBrf6CLXNiiIet8WKVyEz2iL/xMCR1t= nSp AoJHcM0vTWFydGluZSBTb3BoaWUgTGVuZGVycyA8YXV0aG1pbGxlbm9uQGdtYWlsLmNvbT7Cw= ZQE EwEKAD4WIQSGMa6uCWMHSOh6ioXTVVueA8CYxwUCYOylYQIbAwUJA8JnAAULCQgHAgYVCgkIC= wIE FgIDAQIeAQIXgAAKCRDTVVueA8CYx6VXD/4x4c5bFOssAe9HGkEM/rwyK+f3YRKsIvltrMmXe= 4Jx i+zEAJceP03ksOn9p+F8E03fTloG94QHVYstuy7CX9TZWFoZ7evdD8x8X6hUUL09HwTrv/5Yw= tEn V5/EiFcJLsODxG25P0/ZhS2RuMLkCwClHBei5nvM9ebSzSkKcGKRdXvMUqNdiGq5vl1taFejt= jNb +UR1gYWs411qaBhdEcMsv0p1Ydcv46RkeJfRSfv1s90zCOR8+t2YBAanLWCngzfYls8b/l18v= 0UK zNJuZ+4sLaEWbx2W9F0bdVyTUUsLkJTIr2gY8PPqEC97SRQABil/1WLBp09Vcnh+U+GkzHtKq= a8e m7TdrPPvZPwjP0XMk/Ra+qVU8i938WaHQ/mvdmq903VVAEH3bcDU0h4eJ1zNw3rrKxxh+U/3m= 6Yj +Vz+w+HX27DrVeqNiLnau5yCyyqgkLktTOVdwBEn6clJwIcLEbQd+20J2GXo+9YmVFZysxeNw= SGB Raow0DEdxcke3v4p9EkpL9lNTx/clwYoNdTyH3Mn9mwS/d7Xmag5LxjAYtcCurFXObAcTmCWm= 3Vd 3CFpQDmNjDyj0qfBJySTp8cRdoil5Kk3I8sZ4PsOjgquIsL0SsYfGnX7/H+cv0j6LUYJMZHtt= smt 0eN1wK5YmqZlJ72zPKp4+AhIXcGacCnqx80tTWFydGluZSBTb3BoaWUgTGVuZGVycyA8bWxlb= mRl cnNAcmlvdC1vcy5vcmc+wsGUBBMBCgA+FiEEhjGurgljB0joeoqF01VbngPAmMcFAmDspZQCG= wMF CQPCZwAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ01VbngPAmMcJERAAsSOUPRMpZsJk9= Hth TIibBbKqPu6hXHcQSuIKXdAhGecCZo4L9W1Y7JO2gfia92lxyL/dOZd/Df3YK4Cc1Hu7BJGTn= U89 YZV0qMsoxqJPPZfdcMDqaGPFSuuJ03VtJQe6OMkMU5BBqqiT6VjLnRL4IvVVu2Lf9CmSBdCJF= fOb FTE2yHFwRJ1uKldhYuUJUvjkDCuswCqF0K1JlYTjFYH7eHae0SDR6zu8+rgGdhWsCL1a9oQzO= j/e mZKbr9C4waatjDd5LD93IRRDAGMStNZiKjNNfXXHTBpTjuAJZGS81G3uruVqXYbeJf58Io4Zv= hL3 DCoD4uoX5RdQ1p4FWv7J8T9yhiEs8TO0HsaTAjcy2Z/3jTTfBwGhfVZjUHMkwV/971Ye8k1Cn= 4ii CRk2eyowGVrFzfQox/AX2tNve5uKtrgF6euHjeSCeXskjsBqLf113bdUCHlTcm2dv5NWALukb= 4vy +zPEnryvehIP0BjYiFIs0yYQYKYi8Fft5P2KN6H9IH3TjYoFhrxmamQnoxOw9WPLHcq+VZ3Vv= /0k 9Zbe38EbnhMvRTcX6hDuKpdfDIO18ILrMapvvXOImGiUKlDYIwJP/sQDMgKM6aZaZ+OoRPPEz= GP6 f4Qsqyok9GHxxl8TVpz0todwUyM+evRUR7uqvXHf/WBEIcAfub26yYCWLPvOwU0EYOyjsgEQA= NEy zAnTN2uB14XGvatXX0XqMWye/oZqEw6IsawGi4WYHc5XzeTn5sDNaTHaTqMC/QMEfpgOKO023= lVv uQAOa1dW7tKZ3Q+xh7I0tYg2cGwmVaZXvrau0s+AshwGiZjp1Y4bTrcge2KAtpWj1xY9r5J+J= 710 4nyUfyx5qCWf1wxWmBDKntGrVeFdomNKQbjEX2egOAcG4YKhr6/a67h1kAcwccBGoxqY2tvLc= Qfo j4I881irp/bBmaTQGyoBF3hqySBtLOVpgweEIoEpPit+9oxRLvranf7EgP248kPkZ0bml8svC= Qxp q5KETHeVWUr6HF/YY6HGKGsx0chWh8TUxQomW7aDBWgdO6tQn5yGWeX1CRMonJgFGWq3gKldx= W/3 cepUXTl/exsd/QjFkzbYsGc/NwTQk0izRy9HkNMLlgf3pI+YSM6yenmpICz57l1E0xx6GxVzd= CBs 2PchMgXaN7Kc0LEr0/x8trkzyxM8wTHJtX1RoIbtocAsK9J8FdeP/Zx3qZP6bkZZc5JbMu0Vu= 5sO N8nkN3Zx8XFVG79LbBN+N/H+5tpTUJ/uab8GuhDcIX1rE16SZDustD0psh0LwgLUhAjgWklDc= WFP /e8wuSJA31W/KSxgtY4rvf7h0yo2iWq42spB2YZubgY/G41h36znddZJiOFAdda8Uatqexh/A= BEB AAHCwXwEGAEKACYWIQSGMa6uCWMHSOh6ioXTVVueA8CYxwUCYOyjsgIbDAUJA8JnAAAKCRDTV= Vue A8CYx6v+D/9m3TB+kVsKhpHgaiPd0qqqyxPoORpfNP2Gxad7rpnfAwXUl++fU5fIVyqhZbhsc= 7HL nR9kbZf+E3CuZkUvLcuFwp43lP7UDdFojk29hQdcP76cbFZB0xTJgPHNRfFx5WYn3ZpnvI8cQ= ADj vnXtvq7XvjEanYyM3ZT8K2wR+qM4NP6LebiUqo90eLHbU0ecmoWeetmSiUHSkJ2lHYEHUJb6E= vTT OmOX0v+jffwKpgTv0yHz5yu6Z3EXoTvSAXjt8XM204TMD4TOhAXhus0zH3W/AtxX1u5YVrlI+= i3c 9TLAhLceq5tHLy5T2+XBkU5suIDIpG4Np1MypD3GdEhFF+RkVUkZp1V/XSunQQt5tgR9/Orkz= JBE kXK0GUlC4qw31dunv073T4eRfI4mx1GOCMONLchC7YAxFD6HtTYXHIBXGDsSXI202GnIBhHaP= pGh UMeJxlOsH+eXUkz82a03vAR6QDunM4g3pC2TLnAv13oI+j+zxX9xow9PuYNqksZGMUgU8ZcOa= SJu S1ExIPT4Wh3OfCijKt9XbK5PGtalPokrKgaTXHCfDo3fJGv13tZp1yyTCLTB2V7tmcMHvWsSe= nfM NTJYhQe3beaV5JsmjnhV+AuOqelHoCXZL4mCETcqy5ypGvywMPZkrZpvmxY3dSGX6EzCn3H1L= n7I X+SO/yWOAc7BTQRg7KWgARAAqp/eHTFTEkPQwUbfMTNlBDPh3P69q+wpiYeTPDSe51Qg2Gaup= OFT 8FOpCbRJk2zqFSo3MtzOLG1Cgi8GNV1eZTBW8ObsUmCJtOXlUfZuOKXZvjy2VcFwtu5qpDcwm= iUu EVOIy8WNkTTpLL0tk4emAmwa1fJsU9+9KSIYZZL7+ewOUZh7h8WIdn4mLyZ3ESzIdYvhdGehz= 9XF eliI6sdM4ev4bLGrU4cLh8Sv8CuNK2YWov+Z4gu+FagyhoNzMa0wSBVyq7fczJ4ViGydl6F3M= zsX YiTYF8xIzIQVEyvsa0hC91hD1lawY2H+YUiX7y385K/k2i52H/DE2/9Hl898wguN99QR2uTXU= 7ex mQ6xXuUT/qbnl0W9Ll1qByfSeNBCstgm1uhLBJVUEJfJ73NMVklx2hF365odpqRIx3DtV+7iV= Etc LEksL2VHKL0c/Escx5V7cZCjHvC7uaM5EUEXSskXe9Jc3OfWpNnOinenSXHiN65Nm/uYM0H3o= WpD 4krcHLrFh05uhHz19cu5fYJokvCVCalzdEw1I1e+5G2D2lgoxy63t7tj+OpGcQ94tOTcbBwAz= mia rvemoSL67FeN4yzCShZ2HxQhvFglkFPiql7JpZcPMA/LjihApVxj/vLk7BJwbHHsnNw4U+MU0= YPv Ace3nm7UkJrIcM4mtWzGI88AEQEAAcLDsgQYAQoAJhYhBIYxrq4JYwdI6HqKhdNVW54DwJjHB= QJg 7KWgAhsCBQkDwmcAAkAJENNVW54DwJjHwXQgBBkBCgAdFiEEx0d0J413JFDpx+b8ITTXelM23= YAF AmDspaAACgkQITTXelM23YBzNg/7BoQDOXEyzdG0in1SFYaGfkU+QlSlHDOK5D1KbI9Ls3s4c= dYD 413s06z+evrIcPjjZ/1Dte1xJR8B58ZVzXVJcsVByp90e2ONcEOo8CJtOzq/31EmAe6SL3rl1= P8/ 3XVSN6JDVTZkgv4fG6YrOWlhXRE+b/MGhAHqIiQZ4Q1ryVbvA203LaeP57utHtYzu38Iy02Lp= OpL 4DRECDoL41+YAfcwqsKCZu8DS/tf77s0ggvHILaE6SdrjAQsVRu/Vmoarj7GibaAHGJNFb/5m= JwG iWdJoMUu/QOxTWHoD2ypGSxKCJte3drB/taGzpplULedfLFuOtV6dgOUwb8J/w/T7eJuS0ivO= jmp QRehI+KB4togVi4ZRvgC19g7TlVxoBl14jX3rcDzWDcRuEMJ184kEGbY77TUaWgoFD5YBu3VQ= SNU 62MWKP8SAPJBK2G590uRDtdJwNnlm3Ps7Kfjd7IL4eiCBjcqM365SXj/jDVd57AJrwDpH48rV= FOK FRZG+Tet0zy1oV7+MX1j/9RVejdWiXhoefDMSZCnUTPZfWCHW0kt5wEmnNkN+V1r08UHwQlDt= gQz P+GmRrF3/0rXWnb3ePhlikudBxRxBfUVn294x8rabxESxD/ucGSFuIc68hOxfAxNrq0DLtRcq= WDo 4At1Wqr5Kv2kwlmP/J0igTSVxMC4bQ//VJcjiFHkll4KjzbhWFuZh0O23xB9pSQwWkcB2o9Zx= j+Z tqB915OMnzwxPO0cif7fxQTqXBW6J7mkp2DxMn1RWBtOrLYxWR0s3vyuHDJoO+lB67sTCq7oT= ob/ Ow0O2nwoQyfITCfDG0Ii7NwxK0Rg0Ym+WTBYCuqCvmBd+K7QlZEyrHK08uPqHhLpQWc52lqi3= IlO f6yIqm1UycMV/T4rHXLiobrBgTHI/7QshX3/WDNBbQ2GfZDxp2DzXeFDK2kEE+LO/ufksZlr9= 9il Nxf6e6sbkQ8K2noaHrIBL3mwLIM2qWU9VWPlw5tcjpHmCS1IFCxp0BBBuElHK6OLMaCKQ+sPH= +pY G26+IEjA8KP11AOtA98xd7r3xPSvwgyWSNuqIf6/nMNd2rhuo2ICTeEWI/zFO2kcdJpETPtO5= 0qL sCpq+EPKQpc4QYjpPWBKLgqGMa9J0UIO9Yx30B1rfGV9Gk0s/oSE5L2j+QQ2l+lfJjiUUz1A5= 2Ia PfuxwcoqcvEywmvHGD9vYS8/YDohz3w5mVDb0mwWCiY4gMUJO4Q/LK4b2Spi38998PmAGhsEb= FWt z0+ojAlmjNkEMc7ZfK/y1zJvDDwkB7+cLnSgbOO0jcXOVnsjPLjNsTwccbsbxmiD3J5ZDDuyx= 3F/ WYdKsSEpuUsVdjDaFiRq8INzI1aqIXE=3D =3DBmZj -----END PGP PUBLIC KEY BLOCK----- --------------NwMutl0FEyL4JLrRXfAkZR33-- --------------y40Td6W8CbedxQLE033tzIg4-- --------------Deq0pmXRoBbOqlyPfAOuc29h Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEx0d0J413JFDpx+b8ITTXelM23YAFAmF63wcFAwAAAAAACgkQITTXelM23YBK OhAAlIvhT1ioKinqkfOEO6NqtmD1waXVPrJtjA/gUq261lN7T69veVWYt9mIUnKMcnyIAzxLocZg ojsNiW17LS++s1lE2EUgzNF4dqBcnpfuwctP3fmIfsmL1DBvOO81pU/yWGEPvQ9ywZq/4fwYDh1b tmylEPSvZUS0LG+thltRjopoEl3IJ0dVslXQ8ox2SxiGpx7sTj82uBBVFkfIxIJQQfVj67yku0aX B8HUKRI+zLJ0diGES3gwTIE4yIrM2gVWL3y0DwBFYKZho8RZ0cNtmOJvbSsbgPwv6jCBjjaiTMQs FEwwHmWZV9z+GJN0AOUnt0CdNMwAu7Sn0+mFEtnDew4aylSqsLNQtIhOk+6iEauTDA6gVwbmavWj v7+jFGPT7Qn5V3HE8BH6U2/hpn5CyH1hiYL8gePCi33w1ambwqyOvrdJfs+piO9p+IhnXQ3O4mcQ iJ2IbCtgLOLrcXtYt5WyI4nScEeVn/DVKHKr3UamE/8QVcWO0Ty+sn/vEUdDfrY3nSpLUrP/3xGS ouz1kSI7kPuebAA1XD2sULPpndKFNoQyiWlh4/RoAMznTkZhzVDMAoyIFpXZWAFu3iK1ZXAROaz6 dAl3+DHvEIek663pvEqyDxih8c0Rnq5ZooBC6oOzgnXuq2lCnYCf4Bx6UUCyYl7Kerah61W5cwhU Gao= =bvgA -----END PGP SIGNATURE----- --------------Deq0pmXRoBbOqlyPfAOuc29h-- From nobody Fri Oct 29 11:45:17 2021 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 37A103A158B; Fri, 29 Oct 2021 11:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 YizrIDjLpo6s; Fri, 29 Oct 2021 11:45:10 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A703B3A1589; Fri, 29 Oct 2021 11:45:04 -0700 (PDT) Received: from [192.168.217.118] (p5089a10c.dip0.t-ipconnect.de [80.137.161.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Hgrvd06F1z30ZY; Fri, 29 Oct 2021 20:45:00 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <162634134491.20957.9891384677904460366@ietfa.amsl.com> Date: Fri, 29 Oct 2021 20:45:00 +0200 Cc: The IESG , draft-ietf-core-sid@ietf.org, core-chairs@ietf.org, core@ietf.org, jaime@iki.fi X-Mao-Original-Outgoing-Id: 657225900.471499-b2a8de865cf3684b02cfe4d99bdd5398 Content-Transfer-Encoding: quoted-printable Message-Id: <0133A9EE-45A5-4240-85FC-60D30280F4B0@tzi.org> References: <162634134491.20957.9891384677904460366@ietfa.amsl.com> To: Zaheduzzaman Sarker X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] Zaheduzzaman Sarker's Discuss on draft-ietf-core-sid-16: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 29 Oct 2021 18:45:15 -0000 [Duplicate copy because of mail weirdness:] Hi Zahed, it took us a while to process the DISCUSS positions and COMMENTS on = core-sid. We didn=E2=80=99t quite finish before the I-D deadline, but did submit a = -17. Link to diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-sid-17.txt > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 >=20 > This should be very easy to resolve and I want to make sure that we = understand > the situation here better - >=20 > *Section 3 : says - >=20 > "The creation of this new version of the ".sid" file > SHOULD be performed using an automated tool" >=20 > If this is supposed to be the automation process written in appendix B = then > putting a reference here makes sense. If not, then as this is very = important > tool, more information need to be added here in this specification = (like, > where to find it, who create and maintains it, any reference to such = an > existing tools). Also I am missing what consequences one need to = consider if > the process is not automated. If this is same as written in the = introduction - >=20 > "Assignment of SIDs to YANG items can be automated. For more details > how this can be achieved, please consult Appendix B." >=20 > Then we have two kind of instructions for the same thing - "can be" = and a > normative "SHOULD". Hence it need to be clarified which one should = prevail. Indeed. We have converged on SHOULD. -17 says: (Intro:) Assignment of SIDs to YANG items SHOULD be automated. For more details how this can be achieved, and when manual interventions may be appropriate, see Appendix B. [=E2=80=A6] At the time of writing, a tool for automated SID file generation is available as part of the open-source project PYANG [PYANG]. (Informative References:) [PYANG] Bjorklund, M., "An extensible YANG validator and converter in python", . (Appendix B:) Assignment of SIDs to YANG items SHOULD be automated. The recommended process to assign SIDs is as follows: [=E2=80=A6] > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thanks for the efforts in this document. >=20 > * I support Robert Wilton's Discuss and Benjamin Kaduk's discuss no.2 We will address these in separate emails. > One more clarification comment - >=20 > * Section 7.5.2: says - >=20 > " The > maximum SID range size is 1000. A larger size may be requested by > the authors if this recommendation is considered insufficient. It is > important to note that an additional SID range can be allocated to an > existing YANG module if the initial range is exhausted." >=20 > I have hard time understanding the mentioning of the maximum SID range = here. > does this mean this document sets the maximum range to 1000 but others = can > have more? please clarify. This text was indeed a bit clumsy. It now says: The SID range size SHOULD NOT exceed 1000; a larger size may be requested by the authors if this recommendation is considered insufficient. It is important to note that an additional SID range can be allocated to an existing YANG module if the initial range is exhausted; this then just leads to slightly less efficient representation. Gr=C3=BC=C3=9Fe, Carsten