From nobody Wed Mar 1 08:24:35 2017 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 766601295BF for ; Wed, 1 Mar 2017 08:24:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.319 X-Spam-Level: X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L3=0.371, RP_MATCHES_RCVD=-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=vodafone.de 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 25hjCClVwu5F for ; Wed, 1 Mar 2017 08:24:30 -0800 (PST) Received: from pegasos-out.vodafone.de (pegasos-out.vodafone.de [80.84.1.38]) by ietfa.amsl.com (Postfix) with ESMTP id A10F3129591 for ; Wed, 1 Mar 2017 08:24:29 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by pegasos-out.vodafone.de (Rohrpostix1 Daemon) with ESMTP id 92AEE261EC9; Wed, 1 Mar 2017 17:24:28 +0100 (CET) X-Virus-Scanned: amavisd-new at vodafone.de Authentication-Results: rohrpostix1.prod.vfnet.de (amavisd-new); dkim=pass header.i=@vodafone.de Received: from pegasos-out.vodafone.de ([127.0.0.1]) by localhost (rohrpostix1.prod.vfnet.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wMXB1QLGVWg; Wed, 1 Mar 2017 17:24:24 +0100 (CET) Received: from smtp-03.vodafone.de (smtp-03.vodafone.de [10.215.254.38]) by pegasos-out.vodafone.de (Rohrpostix1 Daemon) with ESMTP id C480C261F05; Wed, 1 Mar 2017 17:24:24 +0100 (CET) X-DKIM: OpenDKIM Filter v2.6.8 pegasos-out.vodafone.de C480C261F05 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vodafone.de; s=mail; t=1488385464; bh=kKgxkFf1bSRnVCa0QLM+bjHzSOtoGDxdAsmrCOVvdnw=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=a56tbKnj6ofNUrDnDNUHx0FThvCIldAPzlAff1k1r1Hh3e13lO6l7est9L2eLBsmU VLCQ5UREayDg9intHkwcI1DlaigJMmUGB7PBfLzScK9nPFras+2PcgDnOGJFAn8hNQ ItkjMAHueXICqZMIKf7XNIoqGHzzjjbuRlR+9j2Q= X-Virus-Scanned: amavisd-new at vodafone.de Received: from smtp-03.vodafone.de ([127.0.0.1]) by localhost (xsmail-dmz7.prod.vfnet.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2q5EwKqNHMUL; Wed, 1 Mar 2017 17:24:23 +0100 (CET) Received: from friedhelms-air.fritz.box (dslb-088-064-151-253.088.064.pools.vodafone-ip.de [88.64.151.253]) by smtp-03.vodafone.de (Postfix) with ESMTPSA id E3C3EE4C3B; Wed, 1 Mar 2017 17:24:22 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Friedhelm Rodermund In-Reply-To: Date: Wed, 1 Mar 2017 17:24:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148765205970.26029.7456261335683678446.idtracker@ietfa.amsl.com> To: Christian Groves X-Mailer: Apple Mail (2.3259) Archived-At: Cc: core Subject: Re: [core] New Version Notification for draft-groves-core-obsattr-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 01 Mar 2017 16:24:33 -0000 Thanks Christian, I believe these attributes are very valuable to support additional use = cases with CoAP observe.=20 Regards, Friedhelm > On 24 Feb 2017, at 01:36, Christian Groves = wrote: >=20 > Hello >=20 > FYI, I've submitted a draft introducing several new binding and = observe attributes: >=20 > o Initialization Value (iv) >=20 > o Notification Band Minimum (bmn) >=20 > o Notification Band Maximum (bmx) >=20 > o Band Step (bst) >=20 > o Sample Number Window (snw) >=20 > o Sample Time Window (stw) >=20 > If people think these are valuable then the goal would be to add them = to draft-ietf-core-dynlink. >=20 > Comments? >=20 > Regards, Christian >=20 >=20 >=20 >=20 > -------- Forwarded Message -------- > Subject: New Version Notification for = draft-groves-core-obsattr-00.txt > Date: Mon, 20 Feb 2017 20:40:59 -0800 > From: internet-drafts@ietf.org > To: Christian Groves , Christian = Groves , Weiwei Yang = >=20 >=20 >=20 > A new version of I-D, draft-groves-core-obsattr-00.txt > has been successfully submitted by Christian Groves and posted to the > IETF repository. >=20 > Name: draft-groves-core-obsattr > Revision: 00 > Title: Additional CoAP Binding and Observe Attributes > Document date: 2017-02-21 > Group: Individual Submission > Pages: 13 > URL: = https://www.ietf.org/internet-drafts/draft-groves-core-obsattr-00.txt > Status: = https://datatracker.ietf.org/doc/draft-groves-core-obsattr/ > Htmlized: = https://tools.ietf.org/html/draft-groves-core-obsattr-00 >=20 >=20 > Abstract: > [I-D.ietf-core-dynlink] defines five CoAP Observaton attributes > (minimum period, maximum period, band step, less than and greater > than) to control when notifications are sent. These attributes are > insufficient for some use cases. This document specifies additional > attributes allowing for notification bands, initialization values, > band step, sample number window and sample time window to allow for = a > wider range of use cases. >=20 > = =20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 > . >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Wed Mar 1 08:42:02 2017 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 BCF27129605 for ; Wed, 1 Mar 2017 08:42:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.319 X-Spam-Level: X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L3=0.371, RP_MATCHES_RCVD=-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=vodafone.de 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 6tbdNhVthwxE for ; Wed, 1 Mar 2017 08:41:59 -0800 (PST) Received: from pegasos-out.vodafone.de (pegasos-out.vodafone.de [80.84.1.38]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBBA1295FB for ; Wed, 1 Mar 2017 08:41:57 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by pegasos-out.vodafone.de (Rohrpostix1 Daemon) with ESMTP id 97A3B261E3C; Wed, 1 Mar 2017 17:41:56 +0100 (CET) X-Virus-Scanned: amavisd-new at vodafone.de Authentication-Results: rohrpostix1.prod.vfnet.de (amavisd-new); dkim=pass header.i=@vodafone.de Received: from pegasos-out.vodafone.de ([127.0.0.1]) by localhost (rohrpostix1.prod.vfnet.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMZL0EbllugM; Wed, 1 Mar 2017 17:41:53 +0100 (CET) Received: from smtp-03.vodafone.de (xsmail-dmz9.prod.vfnet.de [10.215.254.40]) by pegasos-out.vodafone.de (Rohrpostix1 Daemon) with ESMTP id 72D50261ECE; Wed, 1 Mar 2017 17:41:53 +0100 (CET) X-DKIM: OpenDKIM Filter v2.6.8 pegasos-out.vodafone.de 72D50261ECE DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vodafone.de; s=mail; t=1488386513; bh=IUMhu1CDi8OiNYZvOiE5y1bcrNgUD33jP9iGqeEf3MM=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=10n3l1ynIqk7B8QAkYiHbdzExo2je29+xnp2LL0h8/I+bgp/pQWLoNCBiR6cCKwIo 7ZLzSTd9ru4yK96+yWbv2sbL+SgIkP95iJc6mDju3YGirMjDbaKenxm+5wp0bkrlmN LcXuvbKXRigu6jacZCqk1LduqHY1ElDh523T8cdA= X-Virus-Scanned: amavisd-new at vodafone.de Received: from smtp-03.vodafone.de ([127.0.0.1]) by localhost (xsmail-dmz9.prod.vfnet.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZ7mkRHmtw6g; Wed, 1 Mar 2017 17:41:52 +0100 (CET) Received: from friedhelms-air.fritz.box (dslb-088-064-151-253.088.064.pools.vodafone-ip.de [88.64.151.253]) by smtp-03.vodafone.de (Postfix) with ESMTPSA id F1CFAE620B; Wed, 1 Mar 2017 17:41:51 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Friedhelm Rodermund In-Reply-To: <12768758-039e-0a14-eb5a-511a9489e0c7@gmail.com> Date: Wed, 1 Mar 2017 17:41:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148765208755.26069.6296092128269483309.idtracker@ietfa.amsl.com> <12768758-039e-0a14-eb5a-511a9489e0c7@gmail.com> To: Christian Groves X-Mailer: Apple Mail (2.3259) Archived-At: Cc: core Subject: Re: [core] New Version Notification for draft-groves-core-bas-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 01 Mar 2017 16:42:02 -0000 Thanks Christian, I agree it would be very valuable to support this use case. Regards, Friedhelm > On 24 Feb 2017, at 01:42, Christian Groves = wrote: >=20 > Hello all, >=20 > FYI I've submitted a draft addressing the use case discussed on the = list allowing the value of one resource to trigger the notification of = other resources. >=20 > It proposes to use a collection that would allow binding/observe = attributes on a sub-resource (item). Once the criteria is met then the = value of the collection is returned. The batch and/or linked batch = interfaces are used to control the resources that are returned. >=20 > There's also a discussion of a more complex use case utilising the = FETCH method. >=20 > Like the other attributes the goal would be to have this as part of = draft-ietf-core-dynlink. >=20 > Comments? >=20 > Regards, Christian >=20 >=20 >=20 > -------- Forwarded Message -------- > Subject: New Version Notification for = draft-groves-core-bas-00.txt > Date: Mon, 20 Feb 2017 20:41:27 -0800 > From: internet-drafts@ietf.org > To: Christian Groves , Christian = Groves , Weiwei Yang = >=20 >=20 >=20 > A new version of I-D, draft-groves-core-bas-00.txt > has been successfully submitted by Christian Groves and posted to the > IETF repository. >=20 > Name: draft-groves-core-bas > Revision: 00 > Title: Binding Attribute Scope > Document date: 2017-02-21 > Group: Individual Submission > Pages: 7 > URL: = https://www.ietf.org/internet-drafts/draft-groves-core-bas-00.txt > Status: = https://datatracker.ietf.org/doc/draft-groves-core-bas/ > Htmlized: https://tools.ietf.org/html/draft-groves-core-bas-00 >=20 >=20 > Abstract: > This document specifies an additional CoAP binding attribute that > allows binding attributes to be scoped to an item (sub-resource) in = a > collection resource. This allows synchronisation of multiple > resources in a collection based on the value of one resource. >=20 > = =20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 > . >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Fri Mar 3 05:03:06 2017 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 BE20A129850 for ; Fri, 3 Mar 2017 05:03:04 -0800 (PST) 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, 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 XB_i8WH3wSZl for ; Fri, 3 Mar 2017 05:03:03 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02D3812950E for ; Fri, 3 Mar 2017 05:03:02 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id A7D3846689; Fri, 3 Mar 2017 14:02:58 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id B798A34A; Fri, 3 Mar 2017 14:02:16 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 8FE06542; Fri, 3 Mar 2017 14:02:12 +0100 (CET) Received: (nullmailer pid 8773 invoked by uid 1000); Fri, 03 Mar 2017 13:02:11 -0000 Date: Fri, 3 Mar 2017 14:02:11 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: =?iso-8859-1?Q?G=F6ran?= Selander Message-ID: <20170303130211.zqn4i26mfdydqtcx@hephaistos.amsuess.com> References: <122f01d288b8$04a073f0$0de15bd0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4vhkwenowzdmqt5h" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Cc: "core@ietf.org" Subject: Re: [core] Blocking and OSCOAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 03 Mar 2017 13:03:05 -0000 --4vhkwenowzdmqt5h Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, On Sun, Feb 19, 2017 at 05:46:05AM +0000, G=C3=B6ran Selander wrote: > >1. There are differing views on the desirability of having an integrity > >check that covers the entire message and what the best way to do this is. >=20 > I think this is desirable and I did not note any disagreement on that > point. On the topic of =E2=80=9Chow=E2=80=9D, one proposal is to define s= eparate resources > containing checksums of (large) representations: >=20 > https://mailarchive.ietf.org/arch/msg/core/gjVdDCptJ9DfYvy3uhb35uKwK54 >=20 > Would that not address the issue? >=20 > (It seems I missed to answer your question "Is this something to be done > at the COSE or at the CoAP layer?=E2=80=9D =E2=80=94 I would say neither.= This is on top > of CoAP. The checksum resource could be just a hash of the representation. > Hence you can access this resource with CoAP over your favourite security > protocol to protect it from change.) (Once more, I'm focusing on block2 here for simplicity reasons). I still don't quite see how inner ETags on inner blockwise transfers could reproduce an erroneous state transfer via OSCOAP between a well-behaved server and client. (I'd say that well-behaved server means that it implements an ETag that is a (collision-free) function of the resource state and all blocks it ever produces for a representation fit together, and that well-behaved client means it only modifies the the block number when querying successive blocks). As I understand CoAP, there is no such thing as an "entire message". > >2. Blocking requires that two concurrent 'sessions' not exist for > >the same resource from the same endpoint. I'm shaping the Request-Tag proposal[1] into a generally usable draft. This would mitigate both the situation around all block requests hitting the same server resource from the same port and the integrity protection of POST bodies and that like. > >Which means that although the client might think it is trying to get > >two different resources, the message that is being transmitted is now > >only dealing with a single resource name for the outer blocking. That only affects outer blockwise, where the client strictly speaking would need to detect that it's doing a block1 operation on the same resource and thus serialize the requests. Outer blockwise on a GET request needs to hit some deduplication / caching layer before OSCOAP anyway (lest it trigger a replay protection), at which point the relationship to the original request is established. > >Note that if there is inner blocking, then this can be a > >unique value for each different message that comes out of the inner > >blocking. If there is inner blocking, I don't think we should have any indication on the outside at all. The correlation between the requesting messages should happen purely on encrypted identifiers, both securing the connection and mitigating leaks. > RFC7959 does not support a single endpoint to perform multiple > concurrently proceeding block-wise, but hints at a work-around using > different cache keys. Christian proposed a new option "Request-Tag=E2=80= =9D, > analogously to ETag, the new option would generate different cache keys > and thus identify different representations being pushed by the client. > With the use of this new option, the chaining of integrity values between > blocks currently in OSCOAP can be removed which simplifies the processing. >=20 > Since no one has objected I guess this is an acceptable solution, but it > still remains to decide whether the new option should be defined in OSCOAP > or in a separate draft. I'd sketch it up as a standalone draft, because I think it has applications both for proxies and any other situations where two communication partners are "running out of endpoints". Best regards Christian [1]: https://mailarchive.ietf.org/arch/msg/core/gc1e2NRsNunG09P8PSbyU5E26co --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --4vhkwenowzdmqt5h Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAli5aVAACgkQOY0REtOk veGEVw/+Pm8juXRMqbmBs/xjp/OnsTg2zeFVoeL4dQi0zVXYmXYXEagHlYJAmrrX eUwUl1dcW28r7wShAJDcjABgVEVm9JFxO4YLv2qph/jsZ5vagZVIDdRaj4z3ZWhk SbyMkux5D/6GtYIe7SGb1fthveiyFDIZPTeMLoXMzbBHoD4c4gLTm/LiPGowuoDQ zqBHWedgBdPeYrYhUJYGikhfsCHEpEpbZ1vgUBLmJtcYnl5kJt0xL2h2oaRDl8uY pSWJYUbu/LE/UhxmkzSqDe6o5jP+cr/atuY3aDqt35anI+EPmiLAhkELDuUCIe9I VOt9hqvK3doS4fIlP6HhCzFsBC2YPbHvhdtO7n46Z/kCixn/akzsDEw84xmV2E0z +CdZd2UKB2mdd1KhgFhwGN9kforyuleFMHsnjiqUgSDNj336yPXf7mZxuuCfQWmN sAUzVDgUhLWU4Du0KxY6gE5qrfHZ2A/eehuYbsGauoH+yQaSSLLKuBUkMRQ+KFF1 dlKtnCKcyK7mXB7kYFw7RhQ8oEPnNB7HU4wL+iD85dFG035V1yU5BHQwQG59XuO0 ASy1s55A7gHvNN0jeTTfdF/72O2/fs3avtLlf2NZZG9FJLyJcyJB49an1rIQEphH Invsj0wn/ufSaEd15YOUe1MgIMuCvYH7FuGQEJ3M1tu1rDBo2OM= =eZVt -----END PGP SIGNATURE----- --4vhkwenowzdmqt5h-- From nobody Fri Mar 3 09:32:39 2017 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 9654912952F for ; Fri, 3 Mar 2017 09:32:38 -0800 (PST) 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, 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 3d-WZ3It9azZ for ; Fri, 3 Mar 2017 09:32:35 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 731AE129536 for ; Fri, 3 Mar 2017 09:32:34 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id AFF5F46689 for ; Fri, 3 Mar 2017 18:32:32 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id B943C322 for ; Fri, 3 Mar 2017 18:32:30 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 82C17442 for ; Fri, 3 Mar 2017 18:32:30 +0100 (CET) Received: (nullmailer pid 21358 invoked by uid 1000); Fri, 03 Mar 2017 17:32:29 -0000 Date: Fri, 3 Mar 2017 18:32:29 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: "core@ietf.org" Message-ID: <20170303173229.uj7av3xia4prxku3@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="757nx7d7k5z3xcwq" Content-Disposition: inline User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: [core] pre-draft: Request-Tag X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 03 Mar 2017 17:32:38 -0000 --757nx7d7k5z3xcwq Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello working group, hello OSCOAP people, discussion from the OSCOAP draft has at different layers hit the problem of blockwise requests being linked together only via the endpoint address[1]. Encouraged by G=F6ran, I'd like to suggest a new option to CoAP that would primarily solve OSCOAP's problem, but also allow faster responses from proxies by simultaneous processing of block1 requests. Below is an early version of what I'd like to submit as a draft. I would appreciate feedback on it, especially on the approach of packing this into the endpoint definition instead of just defining a blockwise extension. Note that the actual definition of the change is more concise now than in my previous sketch, because many things I spellt out ther explicitly fall into place automatically because of the endpoint discrimination. (For example, the "atomic vs non-atomic" considerations are now merely a reference to what blockwise already noted in its security context). Best regards Christian PS. what's the expected level of maturity for an individual submission upload into the data tracker? [1]: http://www.ietf.org/mail-archive/web/core/current/msg08299.html =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Request-Discriminator option =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Abstract =3D=3D=3D=3D=3D=3D=3D=3D This memo describes an optional extension to the Constrained Application Protocol (CoAP, RFC7252) that allows extending the endpoint context of a request with an additional discriminator. This allows processing concurrent requests that would otherwise be serialized by proxies in presence of blockwise transfer, and linking blockwise requests on transports that do provide authentication but no ordering guarantees. Introduction =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Blockwise transfer [RFC7959] in the presence of Block1 ties an exchange to a combination of resource and remote endpoint, keeping any two exchanges where those parameters match from happening simultaneously. Wherever either of those parameters get conflated (eg. because a proxy acts as a single endpoint towards a server when forwarding operations on the same resource, or in Object Security of CoAP (OSCOAP) where all a client's request are targetted at the same resource from an outside point of view), the client needs to queue up requests to keep the transfers from overriding each other. (@@@ who else references 'same Endpoint'? other documents could be affected of profit) The OSCOAP security layer provides message integrity and replay protection, but with blockwise, the security context (which augments the endpoint address) alone is insufficient protection because it does not (and does not indent to) forbid out-of-order delivery. Both situations can be mitigated by allowing the client to add an additional discriminator (the Request-Disciminator option), which must be treated as a part of the (security context of an) endpoint as defined in RFC7252 section 1.2. Terminology =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The terms Endpoint, byte, @@@ are used as in RFC7252. An exchange is @@@ the thing with tokens and not MIDs -- should check with OSCOAP, i never really considered it there, and it didn't happen in the tests Request Discriminator: An opaque identifier chosen by the client. It can be absent or a string of up to 8 bytes, including the empty string. The phrasing as two words always indicates such a value, while Request-Discriminator (with dash) is the CoAP option in which it is transferred. The Request-Discriminator option =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D A new option is defined for all request methods: +-----+---+---+---+---+-----------------------+--------+--------+------= ---+ | No. | C | U | N | R | Name | Format | Length | Defau= lt | +-----+---+---+---+---+-----------------------+--------+--------+------= ---+ | TBD | x | x | - | | Request-Discriminator | opaque | 0-8 | (none= ) | +-----+---+---+---+---+-----------------------+--------+--------+------= ---+ =20 C=3DCritical, U=3DUnsafe, N=3DNoCacheKey, R=3DRepeatable It is critical (because mechanisms may rely on endpoint identities not to be conflated), unsafe (because the channels implied by endpoint identities terminate at proxies), not repeatable. (@@@ unsafe makes nocachekey irrelevant, but should we or not set it to ease proxy implementations?) A client may set a Request-Discriminator option to indicate that the message's Endpoint is to be augmented with the opaque option value. The server MUST NOT treat the message's endpoint as equal to any other message's endpoint that does not have the identical Request-Discriminator. The absence of the option and a zero-length option are distinct. (@@@ i wouldn't insist on that -- especially with the inclusion in the AAD it might be better to have absence and h"" equal, so we don't have variable types in the AAD) The option is not used in responses. Response messages implicitly bear their corresponding (via the token @@@ or better refer to Exchange definition?) request's discriminator. If a request that uses Request-Discriminator is rejected with 4.02 Bad Option, the client SHOULD retry the request without it, but only if and when * no limitations on simultaneous operations on the same endpoint are in place, and * the application does not use distinct Request Discriminators to preclude out-of-order delivery on the same endpoint. For inclusion in OSCOAP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D @@@ if this stays a document of its own, oscoap should make a normative reference to it and state something like Whenever the Block1 option is used as inner option, it is associated with a Request Discriminator. The same Request Discriminator MUST NOT be reused within a security context unless every single block sent has elicted a protected response (and its sequence number is consequently marked used). (@@@ if we're cautious, we could s/unless.*/at all/, but i don't see any harm in allowing it.) OSCOAP requires that out-of-order delivery of blockwise transfers is caught by the Request-Discriminator option, so a client MUST NOT fall back to not using the Request-Discriminator option if it encounters a 4.02 Bad Option response. Note that this does not require the use of the Request-Discriminator in many cases. An application implementing OSCOAP MUST use that option at least when a Block1 request has not been losslessly concluded[*], and a server MUST NOT respond with 4.02 due to the presence of a Request-Discriminator option. (@@@ or they could declare the complete context invalid, but i don't think we want contexts to be that volatile) [*]: Simple package loss will not make a discriminator unusable, because there is still CoAP retransmission in place. Only when the block transfer is aborted, or when the same block gets sent with a different sequence number (@@@ may that be at all?), the discriminator is unusable for any further blockwise transfer. A Request-Discriminator option MAY be used when initializing a Block2 transfer as well. A server SHOULD, inside a Request-Discriminator, only send response messages with matching ETags if they can be expected to assemble into a consistent representation again. (@@@ imo that's a requirement that there already is from the ETags themselves. jim, do you think this is a starting point for your concerns about validating the whole message?) @@@ this is more of a verbal patch than something actually includable The associated Request Discriminator will need to be included in the AAD. Whether we include that in the request too to keep the AAD the same both for request and response, or have it in responses only, I don't care. The Request-Discriminator option is added to the "E*" category and like and listed together with Block1/2. Notes on applications =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D @@@ spell out example exchanges: proxy forwarding multiple requests, oscoap application. include a case with non-piggybacked reponses. > Client Foe Server >=20 > POST "incarcerate"(1/2) ---> ---> > <--- <--- 2.31 CONTINUE > POST "valjean"(2/2) --->@ > <---RST >=20 > (Client: Odd, but let's go on and promote Javert) >=20 > POST "promote"(1/2) ---> ---> > <--- <--- 2.31 CONTINUE > @ ---> > <--- 2.04 Valjean Promoted! >=20 > (The @ indicates a maliciously delayed / wormholed package as used in this can't happen in oscoap now any more because the incomplete first POST permanently poisons the first request's request discriminator, and the second request will have a different one, for which the server will not accept the delayed "valjean" any more. Rationale =3D=3D=3D=3D=3D=3D=3D=3D=3D This part is informative and serves to illustrate why this option is necessary, and how it is different from similar concepts. Why not use... * another port: Proxy implementations can work around the simultaneous transfer restrictions by using different ports as a client. This is not possible with some constrained implementations (which typically get their one static socket from the operating system). Moreover, for the OSOCAP inner-bockwise application, the best equivalent would be starting another context, which is application dependent and very costly. Moreover, some transports do not have any such variability (@@@ over-serial, or is there something more complete that has the same limitation?) * extend the blockwise mechanism with another option: That would not make things easier in the author's opinion. * put a discriminator into OSCOAP: That would have the same effect for the OSCOAP inner-blockwise case. It would still not allow different OSCOAP requests to happen concurrently on a device (especially in the presence of proxying). How is this identifier different from the... * message ID and token: Both are defined on the same level as the Request Discriminator (that is, from endpoint to endpoint), but the discriminator has an even longer lifetime than the token in that it at least spans all the requests transferred within a blockwise transfer. * OSCOAP's sequence number: As the above, the sequence number is only used for a single exchange, and does not span a blockwise transfer. Implementations might, however, opt to use the sequence number of the first package of a blockwise transfer as the Request Discriminator for the whole transfer. * ETag: While the Request Discriminator option serves a similar purpose in blockwise transfers as the ETag (ETag allows the client to filter non-matching Block2 responses, Request-Discriminator allows the server to filter non-matching Block1 requests), the ETag is stably determined by the server (and can thus be used for caching), while the Request Discriminator is an ephemeral label used exclusively during the transfer. The naming of options =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D @@@ this section will obviously be removed over time. The naming of options is a difficult matter -- especially here where the use to the application (describing which requests of a blockwise bunch belong together) deviates from what it by its definition (and in implementation) does, that is, provide a lightweight sub-channel inside the channel described by the endpoint address. Alternatives under current consideration are: * Request-Tag: More on the Block1 application side, in parallel to the ETag that the client uses to make sure the responses to its Block2 request match up. Could lead to confusion when used in any context that relies on endpoints but is not blockwise. * Endpoint-Discriminator: On the other end of the spectrum. Technically correct, but its use in a blockwise transfer is not immediately obvious. * Request-Discriminator: Some middle ground. I'd understand it not as much as something that discriminates between requests, but a discriminator introduced by the requester. Standard hygiene =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D @@@ if this stays in at all, it'll be shortened into some kind of 'additional considerations' -- depending on how much discussion there is on it. This draft does something that might be considered dirty in terms of RFC interaction: It defines, when implemented, additional semantics into the term "same endpoint" -- one could say that it hijacks the term to be an extension point. This is done right now because: * It keeps RFC interdependencies low. * It is compatible in the sense that whoever does not implement this option (and consequently responds 4.02 Bad Option to its use) do trivially implement the changed semantics by just not allowing the Request-Discriminator option to take any other value than none. * It allows later or concurrent drafts to use the "same endpoint" semantics and optionally utilize this extension without mandating it as a dependency. * RFC7252 already defines "Endpoint" to include the security association. Given this protects blockwise transfers against a very small range of attacks (those where the attacker can't modify the message, but delay it), this can be seen as a security mode and then plug into the extension point described in RFC7252 4.1. Security Considerations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The Request Discriminator is limited in its used between a pair of end points. If used conservatively (ie. only when necessary, and with as-small-as-possible random discriminators), it only indicates that (and roughly how many) operations that require distinct endpoints are in simultaneous use or have previously been unsuccessful. When used to preclude out-of-order situations between endpoints (as for example in OSCOAP), it is essential that implementations store the usable state of a discriminator for as long as required (eg. in parallel with sequence numbers). Failure to do so leads to reuse of a discriminator, and thus opens up the possibility of replays. Servers that rely on consistent states set by clients must be aware that the out-of-order guarantees added by this mechanism only cover operations that are required by RFC7959 to originate from the same endpoint (or security association). Block1 requests should therefore be limited to atomic operations as outlined in that document's security considerations. IANA Considerations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D @@@ have a number assigned and the option known References =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CoAP @@@ i think i can get away with only having coap as a normative reference here (plus 2119 if keywords are used), though blockwise might be required too due to it updating coap. Informative References ---------------------- OSCOAP blockwise coap-over-serial if referenced --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --757nx7d7k5z3xcwq Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAli5qKkACgkQOY0REtOk veG7XRAAz5CIfU5OPpl/4Rh7QzpX7XtFdSbg9RAX8r85UOSY0Cke5+x3xIpZfJ4a NWoueksgPMCvQ76uQJVcox8AzQQivP3MignaBlyjlOW7WMr6EDHHyMC3LN/ZKWFf 8aGM+m5MVWk7WZ6J6SnU7YxHexpLFERWAI79vEOkSjFblTnjU0J1dn7UyoJBsd6L X/IKXkfqzloSK10OBCURzisr//wgKlKQffa0iNIN2JF3AXfCGy4sdU1m8yv021rX vTlRshEiMvTm4mslRTW8cp+4lmO4dlkbCrwnlx6HwHcsKxCpWjoY5MkDhhOaNUX8 1iJwSVGD4ZKnMX5JAlnW4PDzFsN6WQO2rIhoAg+KTT52PbG9icGmDVuHRiX2gIFu 5MxWnl4kFKGHFXx4JizUQ2U9U/BAqI85QwTDA742fexQwNODYpYC7bW6iFLFEJNU AyIIYlV67F20BvaNXqYDN7cMKw4WtnnuLa2h7JUKzHgmw/oQh0EA9ljDt+Rxy1YX UHRQCXgP/wegQsj7N3fu/NkTLeqCMB2LHXIkAkA8AuN+hQ94m+spBmXOXlunoMl1 zCOzOSnBRJ57NTn+xd24tDp5BEMG26HldWnd9ZNg0+Hh6FBmeBCto1bO3J8aONqX OFhqmRT2cfbqkspg1o00wAv//3Q619EkzE3hXFXhD204R6toS0A= =qhzM -----END PGP SIGNATURE----- --757nx7d7k5z3xcwq-- From nobody Fri Mar 3 16:04:31 2017 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 7ACDD129A99; Fri, 3 Mar 2017 15:55:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148858534149.15846.9202795875026165468.idtracker@ietfa.amsl.com> Date: Fri, 03 Mar 2017 15:55:41 -0800 Archived-At: Cc: core@ietf.org, aamelnikov@fastmail.fm Subject: [core] core - Requested sessions have been scheduled for IETF 98 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 23:55:41 -0000 Dear Jaime Jimenez, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. core Session 1 (1:30:00) Tuesday, Afternoon Session I 1300-1430 Room Name: Zurich C size: 100 --------------------------------------------- core Session 2 (1:30:00) Friday, Afternoon Session I 1150-1320 Room Name: Zurich C size: 100 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Constrained RESTful Environments Area Name: Applications and Real-Time Area Session Requester: Jaime Jimenez Number of Sessions: 2 Length of Session(s): 1.5 Hours, 1.5 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: artarea dispatch t2trg ace lpwan 6lo roll detnet Second Priority: quic dnssd saag irtfopen 6tisch netconf netmod sacm Third Priority: lwig httpbis v6ops opsarea cfrg icnrg homenet People who must be present: Carsten Bormann Alexey Melnikov Jaime Jimenez Resources Requested: Meetecho support in room Special Requests: If CBOR WG is already set, it shouldn't conflict with CoRE. Please also avoid any IoT related BOFs that might come up. *Preferred* pairing: Tue/Thu or other space between; Friday is no problem. --------------------------------------------------------- From nobody Fri Mar 3 16:25:08 2017 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 9C65612706D; Fri, 3 Mar 2017 16:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frFQV70myTzd; Fri, 3 Mar 2017 16:25:00 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03E0B128AB0; Fri, 3 Mar 2017 16:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v240Oj9j005097; Sat, 4 Mar 2017 01:24:45 +0100 (CET) Received: from [192.168.217.124] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vZmyj0KjVzDJ6h; Sat, 4 Mar 2017 01:24:45 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: <880044A0-E3F0-436D-BB45-6751A01EDB6B@tzi.org> Date: Sat, 4 Mar 2017 01:24:44 +0100 X-Mao-Original-Outgoing-Id: 510279884.362881-152b94dac84d17b5022d5bfde5097d7b Content-Transfer-Encoding: quoted-printable Message-Id: References: <880044A0-E3F0-436D-BB45-6751A01EDB6B@tzi.org> To: ace@ietf.org, "core@ietf.org WG" , cose@ietf.org, cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [core] Constrained Node/Network Cluster @ IETF98: FINAL AGENDA X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 04 Mar 2017 00:25:02 -0000 Here is my usual eclectic condensed agenda based on the "FINAL" AGENDA for IETF98. Remember that agenda definitions are never really "FINAL"... "While this is considered the final agenda for printing, changes may be made to the agenda up until and during the meeting. Updates will be reflected on the web versions of the agenda." Compared to the draft agenda, this has mostly room changes. v6ops moved around, and tsvarea got extended to an almost four-hour meeting. All times are CDT (UTC-0500) -- yes, the US will be on DST already for a couple of weeks, while Europe moves over right on Mar 26th. (The browser timezone function still is not yet reinstated on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten SUNDAY, March 26, 2017 0900-1700 IRTF*** icnrg, with some t2trg-related items on the = agenda MONDAY, March 27, 2017 0900-1130 Morning Session I Zurich A ART dispatch Dispatch WG Zurich D INT homenet Home Networking WG Zurich C SEC *** ace Authentication and Authorization for = Constrained Environments WG 1300-1500 Afternoon Session I Vevey 1/2 IRTF*** t2trg Thing-to-Thing Zurich A OPS anima Autonomic Networking Integrated Model = and Approach WG Zurich B RTG bier Bit Indexed Explicit Replication WG Zurich G RTG detnet Deterministic Networking WG Zurich E/F TSV tsvarea Transport Area Open Meeting 1520-1650 Afternoon Session II Zurich A SEC tokbind Token Binding WG Zurich E/F TSV tsvarea Transport Area Open Meeting 1710-1810 Afternoon Session III Zurich E/F GEN wugh WGs Using GitHub BOF Zurich D INT *** lwig Light-Weight Implementation Guidance WG Montreux 3 SEC curdle CURves, Deprecating and a Little more = Encryption WG Zurich C SEC oauth Web Authorization Protocol WG Vevey 1/2 TSV tsvwg Transport Area Working Group WG TUESDAY, March 28, 2017 0900-1130 Morning Session I Zurich C INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Zurich D IRTF maprg Measurement and Analysis for Protocols Zurich E/F SEC tls Transport Layer Security WG 1300-1430 Afternoon Session I Zurich C ART *** core Constrained RESTful Environments WG Zurich D INT intarea Internet Area Working Group WG Zurich A RTG babel Babel routing protocol WG 1450-1620 Afternoon Session II Zurich G ART uta Using TLS in Applications WG Zurich E/F SEC *** teep A Protocol for Dynamic Trusted Execution = Environment Enablement BOF 1640-1840 Afternoon Session III Zurich B INT dnssd Extensions for Scalable DNS Service = Discovery WG Zurich E/F TSV taps Transport Services WG WEDNESDAY, March 29, 2017 0900-1130 Morning Session I Zurich A INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG 1300-1500 Afternoon Session I Zurich C INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Zurich A OPS v6ops IPv6 Operations WG Montreux 3 TSV tcpinc TCP Increased Security WG THURSDAY, March 30, 2017 0900-1130 Morning Session I Zurich D INT 6man IPv6 Maintenance WG Zurich C IRTF icnrg Information-Centric Networking Zurich E/F RTG rtgarea Routing Area Open Meeting Vevey 1/2 TSV quic QUIC WG 1300-1500 Afternoon Session I Zurich B ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Zurich G SEC acme Automated Certificate Management = Environment WG Zurich A TSV tsvwg Transport Area Working Group WG 1520-1720 Afternoon Session II Zurich D SEC saag Security Area Open Meeting 1740-1840 Afternoon Session III Zurich B RTG *** roll Routing Over Low power and Lossy = networks WG FRIDAY, March 31, 2017 0900-1130 Morning Session I Vevey 1/2 ART httpbis Hypertext Transfer Protocol WG Zurich E/F INT ipwave IP Wireless Access in Vehicular = Environments WG Zurich A OPS anima Autonomic Networking Integrated Model = and Approach WG Zurich C SEC oauth Web Authorization Protocol WG 1150-1320 Afternoon Session I Zurich C ART *** core Constrained RESTful Environments WG From nobody Sat Mar 4 08:42:06 2017 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 F234B1294F6 for ; Sat, 4 Mar 2017 08:42:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 iat8FTVwC0wH for ; Sat, 4 Mar 2017 08:42:04 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 482CA1294F3 for ; Sat, 4 Mar 2017 08:42:04 -0800 (PST) X-AuditID: c1b4fb25-4b3ff70000007fa8-5b-58baee58314c Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id 1C.CB.32680.85EEAB85; Sat, 4 Mar 2017 17:42:02 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.200]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0319.002; Sat, 4 Mar 2017 17:41:59 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= Thread-Topic: [core] Blocking and OSCOAP Thread-Index: AQHSiPxbkpNdB0v1ikmSnUEd45ekM6GDGgGAgAHgfgA= Date: Sat, 4 Mar 2017 16:41:58 +0000 Message-ID: References: <122f01d288b8$04a073f0$0de15bd0$@augustcellars.com> <20170303130211.zqn4i26mfdydqtcx@hephaistos.amsuess.com> In-Reply-To: <20170303130211.zqn4i26mfdydqtcx@hephaistos.amsuess.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBIsWRmVeSWpSXmKPExsUyM2K7vW7Uu10RBuv3Mlosv/CcxWLf2/XM Fqunf2dzYPbYOGc6m8fW/XeZPJYs+ckUwBzFZZOSmpNZllqkb5fAlXFl7xuWghc2FXd+XGFt YFxg3cXIwSEhYCKxbE1UFyMXh5DAOkaJP1vPsUA4ixkl3m/fztTFyMnBJuAi8aDhEZgtIuAh MXHpF3YQmxnI7mv+xApiCwuoS3y4t5INZKiIgIbErfvyEOVWEjuaN7KB2CwCKhLbzh8Ea+UV sJBYOv0eE8SulYwSCw9/BZvDKeAqseTUBBYQm1FATOL7qTVMELvEJW49mQ9mSwgISCzZc54Z whaVePn4H1ivqICexPLna6DiShIrtl9iBLmHWUBTYv0ufYgx1hJf/t5igbAVJaZ0P4S6R1Di 5MwnLBMYxWch2TYLoXsWku5ZSLpnIelewMi6ilG0OLU4KTfdyFgvtSgzubg4P08vL7VkEyMw /g5u+a26g/HyG8dDjAIcjEo8vAZ7d0YIsSaWFVfmHmKU4GBWEuHt2w0U4k1JrKxKLcqPLyrN SS0+xCjNwaIkzmu28n64kEB6YklqdmpqQWoRTJaJg1OqgdHsySq3lTOnhxonvYlsDSgQfhs3 p0S/umvKUhOTR5eXJ315WHxE/gF/stMZz20zf3UtdZDJlJG5crD5bdwWpaOPL/qtPCakkfz6 of/vZVoG6UVfIrPPfTN5k33WiSHdSnzxnhwhpYRmtx3u3hrX/VNZ/wc9sKlMOr/KW+3ZD7cm Ze/UD9Jt15RYijMSDbWYi4oTASbk/F27AgAA Archived-At: Cc: "core@ietf.org" Subject: Re: [core] Blocking and OSCOAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 04 Mar 2017 16:42:06 -0000 SGkgQ2hyaXN0aWFuLA0KDQpPbiAyMDE3LTAzLTAzIDE0OjAyLCAiQ2hyaXN0aWFuIEFtc8O8c3Mi IDxjLmFtc3Vlc3NAZW5lcmd5aGFydmVzdGluZy5hdD4NCndyb3RlOg0KDQo+SGVsbG8sDQo+DQo+ T24gU3VuLCBGZWIgMTksIDIwMTcgYXQgMDU6NDY6MDVBTSArMDAwMCwgR8O2cmFuIFNlbGFuZGVy IHdyb3RlOg0KPj4gPjEuICBUaGVyZSBhcmUgZGlmZmVyaW5nIHZpZXdzIG9uIHRoZSBkZXNpcmFi aWxpdHkgb2YgaGF2aW5nIGFuDQo+PmludGVncml0eQ0KPj4gPmNoZWNrIHRoYXQgY292ZXJzIHRo ZSBlbnRpcmUgbWVzc2FnZSBhbmQgd2hhdCB0aGUgYmVzdCB3YXkgdG8gZG8gdGhpcw0KPj5pcy4N Cj4+IA0KPj4gSSB0aGluayB0aGlzIGlzIGRlc2lyYWJsZSBhbmQgSSBkaWQgbm90IG5vdGUgYW55 IGRpc2FncmVlbWVudCBvbiB0aGF0DQo+PiBwb2ludC4gT24gdGhlIHRvcGljIG9mIOKAnGhvd+KA nSwgb25lIHByb3Bvc2FsIGlzIHRvIGRlZmluZSBzZXBhcmF0ZQ0KPj5yZXNvdXJjZXMNCj4+IGNv bnRhaW5pbmcgY2hlY2tzdW1zIG9mIChsYXJnZSkgcmVwcmVzZW50YXRpb25zOg0KPj4gDQo+PiBo dHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2NvcmUvZ2pWZERDcHRKOURmWXZ5 M3VoYjM1dUt3SzU0DQo+PiANCj4+IFdvdWxkIHRoYXQgbm90IGFkZHJlc3MgdGhlIGlzc3VlPw0K Pj4gDQo+PiAoSXQgc2VlbXMgSSBtaXNzZWQgdG8gYW5zd2VyIHlvdXIgcXVlc3Rpb24gIklzIHRo aXMgc29tZXRoaW5nIHRvIGJlIGRvbmUNCj4+IGF0IHRoZSBDT1NFIG9yIGF0IHRoZSBDb0FQIGxh eWVyP+KAnSDigJQgSSB3b3VsZCBzYXkgbmVpdGhlci4gVGhpcyBpcyBvbiB0b3ANCj4+IG9mIENv QVAuIFRoZSBjaGVja3N1bSByZXNvdXJjZSBjb3VsZCBiZSBqdXN0IGEgaGFzaCBvZiB0aGUNCj4+ cmVwcmVzZW50YXRpb24uDQo+PiBIZW5jZSB5b3UgY2FuIGFjY2VzcyB0aGlzIHJlc291cmNlIHdp dGggQ29BUCBvdmVyIHlvdXIgZmF2b3VyaXRlDQo+PnNlY3VyaXR5DQo+PiBwcm90b2NvbCB0byBw cm90ZWN0IGl0IGZyb20gY2hhbmdlLikNCj4NCj4oT25jZSBtb3JlLCBJJ20gZm9jdXNpbmcgb24g YmxvY2syIGhlcmUgZm9yIHNpbXBsaWNpdHkgcmVhc29ucykuDQo+DQo+SSBzdGlsbCBkb24ndCBx dWl0ZSBzZWUgaG93IGlubmVyIEVUYWdzIG9uIGlubmVyIGJsb2Nrd2lzZSB0cmFuc2ZlcnMNCj5j b3VsZCByZXByb2R1Y2UgYW4gZXJyb25lb3VzIHN0YXRlIHRyYW5zZmVyIHZpYSBPU0NPQVAgYmV0 d2VlbiBhDQo+d2VsbC1iZWhhdmVkIHNlcnZlciBhbmQgY2xpZW50Lg0KDQpZb3UgYXJlIHJpZ2h0 LCB0aGVyZSBpcyBubyBpc3N1ZSB3aXRoIEdFVC4gQWxsIGJsb2NrcywgaW5jbHVkaW5nIGJsb2Nr DQpudW1iZXJzLCByZWxhdGVkIHRvIGEgcGFydGljdWxhciByZXByZXNlbnRhdGlvbiAoPWJvZHks IHNlZSBiZWxvdykgZm9yDQp3aGljaCBFVGFnIGlzIHVzZWQgY2FuIGJlIHZlcmlmaWVkLCBhbmQg aGVuY2Ugc28gY2FuIHRoZSB3aG9sZQ0KcmVwcmVzZW50YXRpb24vYm9keS4gSmlt4oCZcyBjb21t ZW50IChpdGVtIDEgYWJvdmUpIGFzIEkgdW5kZXJzdGFuZCBpdCB3YXMNCmFuIGFkZGl0aW9uYWwg ZmVhdHVyZSB0byBnZXQgYW4gaW50ZWdyaXR5IHZhbHVlIG9mIHRoZSB3aG9sZQ0KcmVwcmVzZW50 YXRpb24vYm9keS4gQW5kIHRoZSBzb2x1dGlvbiBJIG1lbnRpb25lZCB3YXMgdG8gZGVmaW5lIGEg c3BlY2lhbA0KcmVzb3VyY2Ugd2hpY2ggY2FuIGJlIHVzZWQgZm9yIHRoYXQuIEJ1dCB0aGF0IGRv ZXNu4oCZdCBoYXZlIHRvIGJlDQpzdGFuZGFyZGlzZWQuDQoNCj4oSSdkIHNheSB0aGF0IHdlbGwt YmVoYXZlZCBzZXJ2ZXIgbWVhbnMNCj50aGF0IGl0IGltcGxlbWVudHMgYW4gRVRhZyB0aGF0IGlz IGEgKGNvbGxpc2lvbi1mcmVlKSBmdW5jdGlvbiBvZiB0aGUNCj5yZXNvdXJjZSBzdGF0ZSBhbmQg YWxsIGJsb2NrcyBpdCBldmVyIHByb2R1Y2VzIGZvciBhIHJlcHJlc2VudGF0aW9uIGZpdA0KPnRv Z2V0aGVyLCBhbmQgdGhhdCB3ZWxsLWJlaGF2ZWQgY2xpZW50IG1lYW5zIGl0IG9ubHkgbW9kaWZp ZXMgdGhlIHRoZQ0KPmJsb2NrIG51bWJlciB3aGVuIHF1ZXJ5aW5nIHN1Y2Nlc3NpdmUgYmxvY2tz KS4NCj4NCj5BcyBJIHVuZGVyc3RhbmQgQ29BUCwgdGhlcmUgaXMgbm8gc3VjaCB0aGluZyBhcyBh biAiZW50aXJlIG1lc3NhZ2UiLg0KDQpSRkM3OTU5ICjigJxibG9ja3dpc2XigJ0pIGRpc3Rpbmd1 aXNoZXMgYmV0d2VlbiDigJxwYXlsb2Fk4oCdIGFuZCDigJxib2R54oCdLCB3b3VsZCBpdA0KbWFr ZSBtb3JlIHNlbnNlIHRvIHVzZSAgdGhvc2UgdGVybXMgaW5zdGVhZD8NCg0KICAgIkluIHRoZSBm b2xsb3dpbmcsIHRoZSB0ZXJtICJwYXlsb2FkIiB3aWxsIGJlIHVzZWQgZm9yIHRoZSBhY3R1YWwN CiAgIGNvbnRlbnQgb2YgYSBzaW5nbGUgQ29BUCBtZXNzYWdlLCBpLmUuLCBhIHNpbmdsZSBibG9j ayBiZWluZw0KICAgdHJhbnNmZXJyZWQsIHdoaWxlIHRoZSB0ZXJtICJib2R5IiB3aWxsIGJlIHVz ZWQgZm9yIHRoZSBlbnRpcmUNCiAgIHJlc291cmNlIHJlcHJlc2VudGF0aW9uIHRoYXQgaXMgYmVp bmcgdHJhbnNmZXJyZWQgaW4gYSBibG9jay13aXNlDQogICBmYXNoaW9uLiAgVGhlIENvbnRlbnQt Rm9ybWF0IE9wdGlvbiBhcHBsaWVzIHRvIHRoZSBib2R5LCBub3QgdG8gdGhlDQogICBwYXlsb2Fk OyBpbiBwYXJ0aWN1bGFyLCB0aGUgYm91bmRhcmllcyBiZXR3ZWVuIHRoZSBibG9ja3MgbWF5IGJl IGluDQogICBwbGFjZXMgdGhhdCBhcmUgbm90IHNlcGFyYXRpbmcgd2hvbGUgdW5pdHMgaW4gdGVy bXMgb2YgdGhlIHN0cnVjdHVyZSwNCiAgIGVuY29kaW5nLCBvciBjb250ZW50LWNvZGluZyB1c2Vk IGJ5IHRoZSBDb250ZW50LUZvcm1hdC4gIChTaW1pbGFybHksDQogICB0aGUgRVRhZyBPcHRpb24g ZGVmaW5lZCBpbiBTZWN0aW9uIDUuMTAuNiBvZiBbUkZDNzI1Ml0NCjxodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjNzI1MiNzZWN0aW9uLTUuMTAuNj4gYXBwbGllcyB0byB0aGUNCiAgIHdo b2xlIHJlcHJlc2VudGF0aW9uIG9mIHRoZSByZXNvdXJjZSwgYW5kIHRodXMgdG8gdGhlIGJvZHkg b2YgdGhlDQogICByZXNwb25zZS4pIg0KDQoNCkfDtnJhbg0KDQo+DQo+PiA+Mi4gIEJsb2NraW5n IHJlcXVpcmVzIHRoYXQgdHdvIGNvbmN1cnJlbnQgJ3Nlc3Npb25zJyBub3QgZXhpc3QgZm9yDQo+ PiA+dGhlIHNhbWUgcmVzb3VyY2UgZnJvbSB0aGUgc2FtZSBlbmRwb2ludC4NCj4NCj5JJ20gc2hh cGluZyB0aGUgUmVxdWVzdC1UYWcgcHJvcG9zYWxbMV0gaW50byBhIGdlbmVyYWxseSB1c2FibGUg ZHJhZnQuDQo+VGhpcyB3b3VsZCBtaXRpZ2F0ZSBib3RoIHRoZSBzaXR1YXRpb24gYXJvdW5kIGFs bCBibG9jayByZXF1ZXN0cyBoaXR0aW5nDQo+dGhlIHNhbWUgc2VydmVyIHJlc291cmNlIGZyb20g dGhlIHNhbWUgcG9ydCBhbmQgdGhlIGludGVncml0eSBwcm90ZWN0aW9uDQo+b2YgUE9TVCBib2Rp ZXMgYW5kIHRoYXQgbGlrZS4NCj4NCj4+ID5XaGljaCBtZWFucyB0aGF0IGFsdGhvdWdoIHRoZSBj bGllbnQgbWlnaHQgdGhpbmsgaXQgaXMgdHJ5aW5nIHRvIGdldA0KPj4gPnR3byBkaWZmZXJlbnQg cmVzb3VyY2VzLCB0aGUgbWVzc2FnZSB0aGF0IGlzIGJlaW5nIHRyYW5zbWl0dGVkIGlzIG5vdw0K Pj4gPm9ubHkgZGVhbGluZyB3aXRoIGEgc2luZ2xlIHJlc291cmNlIG5hbWUgZm9yIHRoZSBvdXRl ciBibG9ja2luZy4NCj4NCj5UaGF0IG9ubHkgYWZmZWN0cyBvdXRlciBibG9ja3dpc2UsIHdoZXJl IHRoZSBjbGllbnQgc3RyaWN0bHkgc3BlYWtpbmcNCj53b3VsZCBuZWVkIHRvIGRldGVjdCB0aGF0 IGl0J3MgZG9pbmcgYSBibG9jazEgb3BlcmF0aW9uIG9uIHRoZSBzYW1lDQo+cmVzb3VyY2UgYW5k IHRodXMgc2VyaWFsaXplIHRoZSByZXF1ZXN0cy4NCj4NCj5PdXRlciBibG9ja3dpc2Ugb24gYSBH RVQgcmVxdWVzdCBuZWVkcyB0byBoaXQgc29tZSBkZWR1cGxpY2F0aW9uIC8NCj5jYWNoaW5nIGxh eWVyIGJlZm9yZSBPU0NPQVAgYW55d2F5IChsZXN0IGl0IHRyaWdnZXIgYSByZXBsYXkNCj5wcm90 ZWN0aW9uKSwgYXQgd2hpY2ggcG9pbnQgdGhlIHJlbGF0aW9uc2hpcCB0byB0aGUgb3JpZ2luYWwg cmVxdWVzdCBpcw0KPmVzdGFibGlzaGVkLg0KPg0KPj4gPk5vdGUgdGhhdCBpZiB0aGVyZSBpcyBp bm5lciBibG9ja2luZywgdGhlbiB0aGlzIGNhbiBiZSBhDQo+PiA+dW5pcXVlIHZhbHVlIGZvciBl YWNoIGRpZmZlcmVudCBtZXNzYWdlIHRoYXQgY29tZXMgb3V0IG9mIHRoZSBpbm5lcg0KPj4gPmJs b2NraW5nLg0KPg0KPklmIHRoZXJlIGlzIGlubmVyIGJsb2NraW5nLCBJIGRvbid0IHRoaW5rIHdl IHNob3VsZCBoYXZlIGFueSBpbmRpY2F0aW9uDQo+b24gdGhlIG91dHNpZGUgYXQgYWxsLiBUaGUg Y29ycmVsYXRpb24gYmV0d2VlbiB0aGUgcmVxdWVzdGluZyBtZXNzYWdlcw0KPnNob3VsZCBoYXBw ZW4gcHVyZWx5IG9uIGVuY3J5cHRlZCBpZGVudGlmaWVycywgYm90aCBzZWN1cmluZyB0aGUNCj5j b25uZWN0aW9uIGFuZCBtaXRpZ2F0aW5nIGxlYWtzLg0KPg0KPj4gUkZDNzk1OSBkb2VzIG5vdCBz dXBwb3J0IGEgc2luZ2xlIGVuZHBvaW50IHRvIHBlcmZvcm0gbXVsdGlwbGUNCj4+IGNvbmN1cnJl bnRseSBwcm9jZWVkaW5nIGJsb2NrLXdpc2UsIGJ1dCBoaW50cyBhdCBhIHdvcmstYXJvdW5kIHVz aW5nDQo+PiBkaWZmZXJlbnQgY2FjaGUga2V5cy4gQ2hyaXN0aWFuIHByb3Bvc2VkIGEgbmV3IG9w dGlvbiAiUmVxdWVzdC1UYWfigJ0sDQo+PiBhbmFsb2dvdXNseSB0byBFVGFnLCB0aGUgbmV3IG9w dGlvbiB3b3VsZCBnZW5lcmF0ZSBkaWZmZXJlbnQgY2FjaGUga2V5cw0KPj4gYW5kIHRodXMgaWRl bnRpZnkgZGlmZmVyZW50IHJlcHJlc2VudGF0aW9ucyBiZWluZyBwdXNoZWQgYnkgdGhlIGNsaWVu dC4NCj4+IFdpdGggdGhlIHVzZSBvZiB0aGlzIG5ldyBvcHRpb24sIHRoZSBjaGFpbmluZyBvZiBp bnRlZ3JpdHkgdmFsdWVzDQo+PmJldHdlZW4NCj4+IGJsb2NrcyBjdXJyZW50bHkgaW4gT1NDT0FQ IGNhbiBiZSByZW1vdmVkIHdoaWNoIHNpbXBsaWZpZXMgdGhlDQo+PnByb2Nlc3NpbmcuDQo+PiAN Cj4+IFNpbmNlIG5vIG9uZSBoYXMgb2JqZWN0ZWQgSSBndWVzcyB0aGlzIGlzIGFuIGFjY2VwdGFi bGUgc29sdXRpb24sIGJ1dCBpdA0KPj4gc3RpbGwgcmVtYWlucyB0byBkZWNpZGUgd2hldGhlciB0 aGUgbmV3IG9wdGlvbiBzaG91bGQgYmUgZGVmaW5lZCBpbg0KPj5PU0NPQVANCj4+IG9yIGluIGEg c2VwYXJhdGUgZHJhZnQuDQo+DQo+SSdkIHNrZXRjaCBpdCB1cCBhcyBhIHN0YW5kYWxvbmUgZHJh ZnQsIGJlY2F1c2UgSSB0aGluayBpdCBoYXMNCj5hcHBsaWNhdGlvbnMgYm90aCBmb3IgcHJveGll cyBhbmQgYW55IG90aGVyIHNpdHVhdGlvbnMgd2hlcmUgdHdvDQo+Y29tbXVuaWNhdGlvbiBwYXJ0 bmVycyBhcmUgInJ1bm5pbmcgb3V0IG9mIGVuZHBvaW50cyIuDQo+DQo+QmVzdCByZWdhcmRzDQo+ Q2hyaXN0aWFuDQo+DQo+WzFdOiANCj5odHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gv bXNnL2NvcmUvZ2MxZTJOUnNOdW5HMDlQOFBTYnlVNUUyNmNvDQo+DQo+LS0gDQo+VG8gdXNlIHJh dyBwb3dlciBpcyB0byBtYWtlIHlvdXJzZWxmIGluZmluaXRlbHkgdnVsbmVyYWJsZSB0byBncmVh dGVyDQo+cG93ZXJzLg0KPiAgLS0gQmVuZSBHZXNzZXJpdCBheGlvbQ0KDQo= From nobody Sat Mar 4 08:53:44 2017 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 D7DDE129495 for ; Sat, 4 Mar 2017 08:53:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9_cMmMd5USL for ; Sat, 4 Mar 2017 08:53:41 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08D94129420 for ; Sat, 4 Mar 2017 08:53:40 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v24GrWa7015020; Sat, 4 Mar 2017 17:53:33 +0100 (CET) Received: from client-0003.vpn.uni-bremen.de (client-0003.vpn.uni-bremen.de [134.102.107.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vbBvc5xWszDJGm; Sat, 4 Mar 2017 17:53:32 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: Date: Sat, 4 Mar 2017 17:53:32 +0100 X-Mao-Original-Outgoing-Id: 510339211.814252-304547080f1cd62f35c2e59f8f664bce Content-Transfer-Encoding: quoted-printable Message-Id: References: <122f01d288b8$04a073f0$0de15bd0$@augustcellars.com> <20170303130211.zqn4i26mfdydqtcx@hephaistos.amsuess.com> To: =?utf-8?Q?G=C3=B6ran_Selander?= X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "core@ietf.org" , =?utf-8?Q?Christian_Ams=C3=BCss?= Subject: Re: [core] Blocking and OSCOAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 04 Mar 2017 16:53:43 -0000 On 4 Mar 2017, at 17:41, G=C3=B6ran Selander = wrote: >=20 > RFC7959 (=E2=80=9Cblockwise=E2=80=9D) distinguishes between = =E2=80=9Cpayload=E2=80=9D and =E2=80=9Cbody=E2=80=9D, would it > make more sense to use those terms instead? Indeed; I was going to say this, too. Gr=C3=BC=C3=9Fe, Carsten From nobody Sat Mar 4 15:45:30 2017 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 5B4831295E8 for ; Sat, 4 Mar 2017 15:45:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 jKVimceJWOKD for ; Sat, 4 Mar 2017 15:45:26 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 090DA129418 for ; Sat, 4 Mar 2017 15:45:25 -0800 (PST) X-AuditID: c1b4fb3a-ea7ff7000000484c-3a-58bb51926029 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by (Symantec Mail Security) with SMTP id 22.9C.18508.2915BB85; Sun, 5 Mar 2017 00:45:24 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.200]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0319.002; Sun, 5 Mar 2017 00:45:30 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= , "core@ietf.org" Thread-Topic: [core] pre-draft: Request-Tag Thread-Index: AQHSlEQryuFBmaIKF027d9Ie4Dq776GFWjqA Date: Sat, 4 Mar 2017 23:45:21 +0000 Message-ID: References: <20170303173229.uj7av3xia4prxku3@hephaistos.amsuess.com> In-Reply-To: <20170303173229.uj7av3xia4prxku3@hephaistos.amsuess.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-ID: <02DC2028EA7B61408FB5FA9F8557D9B4@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyM2K7t+6UwN0RBqe3sVssv/CcxWLf2/XM DkweW/ffZfJYsuQnUwBTFJdNSmpOZllqkb5dAlfG2pkP2QsurWOsmPCriaWBccoqxi5GTg4J AROJBwdXsncxcnEICaxjlNjQ3g/lLGaUuPjnCBNIFZuAi8SDhkdgtohAtsSiuf0sILawgJbE j50LoeLaEnufn4eyjSSOz3zJDmKzCKhIfLjzmxXE5hWwkDh97gFzFyMH0AIXib4DNSBhTgFX id6eqWCtjAJiEt9PrQGzmQXEJW49mc8EcaiAxJI955khbFGJl4//gY0UFdCTWP58DVRcSWLt 4e0sIOOZBTQl1u/ShxhjLfG+8QMjhK0oMaX7ITvENYISJ2c+YZnAKDYLybZZCN2zkHTPQtI9 C0n3AkbWVYyixanFxbnpRkZ6qUWZycXF+Xl6eaklmxiBcXVwy2+rHYwHnzseYhTgYFTi4d3A tztCiDWxrLgy9xCjBAezkgjvJAugEG9KYmVValF+fFFpTmrxIUZpDhYlcV6zlffDhQTSE0tS s1NTC1KLYLJMHJxSDYyF+/d3zFxXocfPsnnKKTv7w3NVrvgsYf949LDdQ4GDs4KCtxz0+BOn /UbvTZTxdlPmI5erbcLWNduyu+taKz42uX38xCmz+7/qrxsdb9vx7MfSFUxneMIEXrUym9/u VZpfv8M/fcHGHJdfngeftqnP8y3Yt36uenHkdf53Royd6XmpWzM2i4UrsRRnJBpqMRcVJwIA jGuw+acCAAA= Archived-At: Subject: Re: [core] pre-draft: Request-Tag X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 04 Mar 2017 23:45:28 -0000 VGhhbmtzIGZvciBjb21waWxpbmcgdGhpcy4NCg0KSSB0aGluayB0aGVyZSBpcyBzdWZmaWNpZW50 IG1hdGVyaWFsIGhlcmUgZm9yIGEgZHJhZnQuDQoNCg0KSWYgSSB1bmRlcnN0YW5kIHJpZ2h0LCB5 b3UgcHJvcG9zZSBhbiBhdWdtZW50YXRpb24gdG8gdGhlIGVuZHBvaW50DQppZGVudGlmaWVyLiBJ IHdhcyB0aGlua2luZyBvZiB0aGUgc29sdXRpb24gYXMgYSAgImJvZHktaWRlbnRpZmllcuKAnSAo dXNpbmcNClJGQzc5NTnigJlzIGRpc3RpbmN0aW9uIGJldHdlZW4gImJvZHkiIGFuZCDigJxwYXls b2Fk4oCdKSwgbm90IGxpbWl0ZWQgdG8gc2VydmVyDQpyZXNwb25zZSBhcyBFVGFnIGJ1dCBhbHNv IGFwcGxpY2FibGUgdG8gY2xpZW50IHJlcXVlc3QgKGFuZCBwcm94eQ0KcmVxdWVzdC9yZXNwb25z ZSkuDQoNCldoYXQgd291bGQgYmUgdGhlIGNvbnMgb2YgaW5zdGVhZCBpZGVudGlmeWluZyB0aGUg Ym9keT8NCg0KVGhhbmtzDQpHw7ZyYW4NCg0KDQoNCk9uIDIwMTctMDMtMDMgMTg6MzIsICJjb3Jl IG9uIGJlaGFsZiBvZiBDaHJpc3RpYW4gQW1zw7xzcyINCjxjb3JlLWJvdW5jZXNAaWV0Zi5vcmcg b24gYmVoYWxmIG9mIGMuYW1zdWVzc0BlbmVyZ3loYXJ2ZXN0aW5nLmF0PiB3cm90ZToNCg0KPkhl bGxvIHdvcmtpbmcgZ3JvdXAsIGhlbGxvIE9TQ09BUCBwZW9wbGUsDQo+DQo+ZGlzY3Vzc2lvbiBm cm9tIHRoZSBPU0NPQVAgZHJhZnQgaGFzIGF0IGRpZmZlcmVudCBsYXllcnMgaGl0IHRoZSBwcm9i bGVtDQo+b2YgYmxvY2t3aXNlIHJlcXVlc3RzIGJlaW5nIGxpbmtlZCB0b2dldGhlciBvbmx5IHZp YSB0aGUgZW5kcG9pbnQNCj5hZGRyZXNzWzFdLg0KPg0KPkVuY291cmFnZWQgYnkgR8O2cmFuLCBJ J2QgbGlrZSB0byBzdWdnZXN0IGEgbmV3IG9wdGlvbiB0byBDb0FQIHRoYXQgd291bGQNCj5wcmlt YXJpbHkgc29sdmUgT1NDT0FQJ3MgcHJvYmxlbSwgYnV0IGFsc28gYWxsb3cgZmFzdGVyIHJlc3Bv bnNlcyBmcm9tDQo+cHJveGllcyBieSBzaW11bHRhbmVvdXMgcHJvY2Vzc2luZyBvZiBibG9jazEg cmVxdWVzdHMuDQo+DQo+QmVsb3cgaXMgYW4gZWFybHkgdmVyc2lvbiBvZiB3aGF0IEknZCBsaWtl IHRvIHN1Ym1pdCBhcyBhIGRyYWZ0LiBJIHdvdWxkDQo+YXBwcmVjaWF0ZSBmZWVkYmFjayBvbiBp dCwgZXNwZWNpYWxseSBvbiB0aGUgYXBwcm9hY2ggb2YgcGFja2luZyB0aGlzDQo+aW50byB0aGUg ZW5kcG9pbnQgZGVmaW5pdGlvbiBpbnN0ZWFkIG9mIGp1c3QgZGVmaW5pbmcgYSBibG9ja3dpc2UN Cj5leHRlbnNpb24uIE5vdGUgdGhhdCB0aGUgYWN0dWFsIGRlZmluaXRpb24gb2YgdGhlIGNoYW5n ZSBpcyBtb3JlIGNvbmNpc2UNCj5ub3cgdGhhbiBpbiBteSBwcmV2aW91cyBza2V0Y2gsIGJlY2F1 c2UgbWFueSB0aGluZ3MgSSBzcGVsbHQgb3V0IHRoZXINCj5leHBsaWNpdGx5IGZhbGwgaW50byBw bGFjZSBhdXRvbWF0aWNhbGx5IGJlY2F1c2Ugb2YgdGhlIGVuZHBvaW50DQo+ZGlzY3JpbWluYXRp b24uIChGb3IgZXhhbXBsZSwgdGhlICJhdG9taWMgdnMgbm9uLWF0b21pYyIgY29uc2lkZXJhdGlv bnMNCj5hcmUgbm93IG1lcmVseSBhIHJlZmVyZW5jZSB0byB3aGF0IGJsb2Nrd2lzZSBhbHJlYWR5 IG5vdGVkIGluIGl0cw0KPnNlY3VyaXR5IGNvbnRleHQpLg0KPg0KPkJlc3QgcmVnYXJkcw0KPkNo cmlzdGlhbg0KPg0KPlBTLiB3aGF0J3MgdGhlIGV4cGVjdGVkIGxldmVsIG9mIG1hdHVyaXR5IGZv ciBhbiBpbmRpdmlkdWFsIHN1Ym1pc3Npb24NCj51cGxvYWQgaW50byB0aGUgZGF0YSB0cmFja2Vy Pw0KPg0KPlsxXTogaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2NvcmUvY3Vy cmVudC9tc2cwODI5OS5odG1sDQo+DQo+DQo+PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0K PlJlcXVlc3QtRGlzY3JpbWluYXRvciBvcHRpb24NCj49PT09PT09PT09PT09PT09PT09PT09PT09 PT09DQo+DQo+QWJzdHJhY3QNCj49PT09PT09PQ0KPg0KPlRoaXMgbWVtbyBkZXNjcmliZXMgYW4g b3B0aW9uYWwgZXh0ZW5zaW9uIHRvIHRoZSBDb25zdHJhaW5lZCBBcHBsaWNhdGlvbg0KPlByb3Rv Y29sIChDb0FQLCBSRkM3MjUyKSB0aGF0IGFsbG93cyBleHRlbmRpbmcgdGhlIGVuZHBvaW50IGNv bnRleHQgb2YgYQ0KPnJlcXVlc3Qgd2l0aCBhbiBhZGRpdGlvbmFsIGRpc2NyaW1pbmF0b3IuIFRo aXMgYWxsb3dzIHByb2Nlc3NpbmcNCj5jb25jdXJyZW50IHJlcXVlc3RzIHRoYXQgd291bGQgb3Ro ZXJ3aXNlIGJlIHNlcmlhbGl6ZWQgYnkgcHJveGllcyBpbg0KPnByZXNlbmNlIG9mIGJsb2Nrd2lz ZSB0cmFuc2ZlciwgYW5kIGxpbmtpbmcgYmxvY2t3aXNlIHJlcXVlc3RzIG9uDQo+dHJhbnNwb3J0 cyB0aGF0IGRvIHByb3ZpZGUgYXV0aGVudGljYXRpb24gYnV0IG5vIG9yZGVyaW5nIGd1YXJhbnRl ZXMuDQo+DQo+SW50cm9kdWN0aW9uDQo+PT09PT09PT09PT09DQo+DQo+QmxvY2t3aXNlIHRyYW5z ZmVyIFtSRkM3OTU5XSBpbiB0aGUgcHJlc2VuY2Ugb2YgQmxvY2sxIHRpZXMgYW4gZXhjaGFuZ2UN Cj50byBhIGNvbWJpbmF0aW9uIG9mIHJlc291cmNlIGFuZCByZW1vdGUgZW5kcG9pbnQsIGtlZXBp bmcgYW55IHR3bw0KPmV4Y2hhbmdlcyB3aGVyZSB0aG9zZSBwYXJhbWV0ZXJzIG1hdGNoIGZyb20g aGFwcGVuaW5nIHNpbXVsdGFuZW91c2x5Lg0KPldoZXJldmVyIGVpdGhlciBvZiB0aG9zZSBwYXJh bWV0ZXJzIGdldCBjb25mbGF0ZWQgKGVnLiBiZWNhdXNlIGEgcHJveHkNCj5hY3RzIGFzIGEgc2lu Z2xlIGVuZHBvaW50IHRvd2FyZHMgYSBzZXJ2ZXIgd2hlbiBmb3J3YXJkaW5nIG9wZXJhdGlvbnMg b24NCj50aGUgc2FtZSByZXNvdXJjZSwgb3IgaW4gT2JqZWN0IFNlY3VyaXR5IG9mIENvQVAgKE9T Q09BUCkgd2hlcmUgYWxsIGENCj5jbGllbnQncyByZXF1ZXN0IGFyZSB0YXJnZXR0ZWQgYXQgdGhl IHNhbWUgcmVzb3VyY2UgZnJvbSBhbiBvdXRzaWRlDQo+cG9pbnQgb2YgdmlldyksIHRoZSBjbGll bnQgbmVlZHMgdG8gcXVldWUgdXAgcmVxdWVzdHMgdG8ga2VlcCB0aGUNCj50cmFuc2ZlcnMgZnJv bSBvdmVycmlkaW5nIGVhY2ggb3RoZXIuDQo+DQo+KEBAQCB3aG8gZWxzZSByZWZlcmVuY2VzICdz YW1lIEVuZHBvaW50Jz8gb3RoZXIgZG9jdW1lbnRzIGNvdWxkIGJlDQo+YWZmZWN0ZWQgb2YgcHJv Zml0KQ0KPg0KPlRoZSBPU0NPQVAgc2VjdXJpdHkgbGF5ZXIgcHJvdmlkZXMgbWVzc2FnZSBpbnRl Z3JpdHkgYW5kIHJlcGxheQ0KPnByb3RlY3Rpb24sIGJ1dCB3aXRoIGJsb2Nrd2lzZSwgdGhlIHNl Y3VyaXR5IGNvbnRleHQgKHdoaWNoIGF1Z21lbnRzIHRoZQ0KPmVuZHBvaW50IGFkZHJlc3MpIGFs b25lIGlzIGluc3VmZmljaWVudCBwcm90ZWN0aW9uIGJlY2F1c2UgaXQgZG9lcyBub3QNCj4oYW5k IGRvZXMgbm90IGluZGVudCB0bykgZm9yYmlkIG91dC1vZi1vcmRlciBkZWxpdmVyeS4NCj4NCj5C b3RoIHNpdHVhdGlvbnMgY2FuIGJlIG1pdGlnYXRlZCBieSBhbGxvd2luZyB0aGUgY2xpZW50IHRv IGFkZCBhbg0KPmFkZGl0aW9uYWwgZGlzY3JpbWluYXRvciAodGhlIFJlcXVlc3QtRGlzY2ltaW5h dG9yIG9wdGlvbiksIHdoaWNoIG11c3QNCj5iZSB0cmVhdGVkIGFzIGEgcGFydCBvZiB0aGUgKHNl Y3VyaXR5IGNvbnRleHQgb2YgYW4pIGVuZHBvaW50IGFzIGRlZmluZWQNCj5pbiBSRkM3MjUyIHNl Y3Rpb24gMS4yLg0KPg0KPlRlcm1pbm9sb2d5DQo+PT09PT09PT09PT0NCj4NCj5UaGUgdGVybXMg RW5kcG9pbnQsIGJ5dGUsIEBAQCBhcmUgdXNlZCBhcyBpbiBSRkM3MjUyLg0KPg0KPkFuIGV4Y2hh bmdlIGlzIEBAQCB0aGUgdGhpbmcgd2l0aCB0b2tlbnMgYW5kIG5vdCBNSURzIC0tIHNob3VsZCBj aGVjaw0KPndpdGggT1NDT0FQLCBpIG5ldmVyIHJlYWxseSBjb25zaWRlcmVkIGl0IHRoZXJlLCBh bmQgaXQgZGlkbid0IGhhcHBlbiBpbg0KPnRoZSB0ZXN0cw0KPg0KPlJlcXVlc3QgRGlzY3JpbWlu YXRvcjogQW4gb3BhcXVlIGlkZW50aWZpZXIgY2hvc2VuIGJ5IHRoZSBjbGllbnQuIEl0IGNhbg0K PiAgYmUgYWJzZW50IG9yIGEgc3RyaW5nIG9mIHVwIHRvIDggYnl0ZXMsIGluY2x1ZGluZyB0aGUg ZW1wdHkgc3RyaW5nLg0KPiAgVGhlIHBocmFzaW5nIGFzIHR3byB3b3JkcyBhbHdheXMgaW5kaWNh dGVzIHN1Y2ggYSB2YWx1ZSwgd2hpbGUNCj4gIFJlcXVlc3QtRGlzY3JpbWluYXRvciAod2l0aCBk YXNoKSBpcyB0aGUgQ29BUCBvcHRpb24gaW4gd2hpY2ggaXQgaXMNCj4gIHRyYW5zZmVycmVkLg0K Pg0KPlRoZSBSZXF1ZXN0LURpc2NyaW1pbmF0b3Igb3B0aW9uDQo+PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0NCj4NCj5BIG5ldyBvcHRpb24gaXMgZGVmaW5lZCBmb3IgYWxsIHJlcXVl c3QgbWV0aG9kczoNCj4NCj4gICAgDQo+Ky0tLS0tKy0tLSstLS0rLS0tKy0tLSstLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tLS0NCj4rDQo+ICAgIHwgTm8u IHwgQyB8IFUgfCBOIHwgUiB8IE5hbWUgICAgICAgICAgICAgICAgICB8IEZvcm1hdCB8IExlbmd0 aCB8DQo+RGVmYXVsdCB8DQo+ICAgIA0KPistLS0tLSstLS0rLS0tKy0tLSstLS0rLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLS0tDQo+Kw0KPiAgICB8IFRC RCB8IHggfCB4IHwgLSB8ICAgfCBSZXF1ZXN0LURpc2NyaW1pbmF0b3IgfCBvcGFxdWUgfCAgICAw LTggfA0KPihub25lKSAgfA0KPiAgICANCj4rLS0tLS0rLS0tKy0tLSstLS0rLS0tKy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0tLQ0KPisNCj4gICAgDQo+ ICAgIEM9Q3JpdGljYWwsIFU9VW5zYWZlLCBOPU5vQ2FjaGVLZXksIFI9UmVwZWF0YWJsZQ0KPg0K Pkl0IGlzIGNyaXRpY2FsIChiZWNhdXNlIG1lY2hhbmlzbXMgbWF5IHJlbHkgb24gZW5kcG9pbnQg aWRlbnRpdGllcyBub3QNCj50byBiZSBjb25mbGF0ZWQpLCB1bnNhZmUgKGJlY2F1c2UgdGhlIGNo YW5uZWxzIGltcGxpZWQgYnkgZW5kcG9pbnQNCj5pZGVudGl0aWVzIHRlcm1pbmF0ZSBhdCBwcm94 aWVzKSwgbm90IHJlcGVhdGFibGUuIChAQEAgdW5zYWZlIG1ha2VzDQo+bm9jYWNoZWtleSBpcnJl bGV2YW50LCBidXQgc2hvdWxkIHdlIG9yIG5vdCBzZXQgaXQgdG8gZWFzZSBwcm94eQ0KPmltcGxl bWVudGF0aW9ucz8pDQo+DQo+QSBjbGllbnQgbWF5IHNldCBhIFJlcXVlc3QtRGlzY3JpbWluYXRv ciBvcHRpb24gdG8gaW5kaWNhdGUgdGhhdCB0aGUNCj5tZXNzYWdlJ3MgRW5kcG9pbnQgaXMgdG8g YmUgYXVnbWVudGVkIHdpdGggdGhlIG9wYXF1ZSBvcHRpb24gdmFsdWUuIFRoZQ0KPnNlcnZlciBN VVNUIE5PVCB0cmVhdCB0aGUgbWVzc2FnZSdzIGVuZHBvaW50IGFzIGVxdWFsIHRvIGFueSBvdGhl cg0KPm1lc3NhZ2UncyBlbmRwb2ludCB0aGF0IGRvZXMgbm90IGhhdmUgdGhlIGlkZW50aWNhbA0K PlJlcXVlc3QtRGlzY3JpbWluYXRvci4gVGhlIGFic2VuY2Ugb2YgdGhlIG9wdGlvbiBhbmQgYSB6 ZXJvLWxlbmd0aA0KPm9wdGlvbiBhcmUgZGlzdGluY3QuIChAQEAgaSB3b3VsZG4ndCBpbnNpc3Qg b24gdGhhdCAtLSBlc3BlY2lhbGx5IHdpdGgNCj50aGUgaW5jbHVzaW9uIGluIHRoZSBBQUQgaXQg bWlnaHQgYmUgYmV0dGVyIHRvIGhhdmUgYWJzZW5jZSBhbmQgaCIiDQo+ZXF1YWwsIHNvIHdlIGRv bid0IGhhdmUgdmFyaWFibGUgdHlwZXMgaW4gdGhlIEFBRCkNCj4NCj5UaGUgb3B0aW9uIGlzIG5v dCB1c2VkIGluIHJlc3BvbnNlcy4gUmVzcG9uc2UgbWVzc2FnZXMgaW1wbGljaXRseSBiZWFyDQo+ dGhlaXIgY29ycmVzcG9uZGluZyAodmlhIHRoZSB0b2tlbiBAQEAgb3IgYmV0dGVyIHJlZmVyIHRv IEV4Y2hhbmdlDQo+ZGVmaW5pdGlvbj8pIHJlcXVlc3QncyBkaXNjcmltaW5hdG9yLg0KPg0KPklm IGEgcmVxdWVzdCB0aGF0IHVzZXMgUmVxdWVzdC1EaXNjcmltaW5hdG9yIGlzIHJlamVjdGVkIHdp dGggNC4wMiBCYWQNCj5PcHRpb24sIHRoZSBjbGllbnQgU0hPVUxEIHJldHJ5IHRoZSByZXF1ZXN0 IHdpdGhvdXQgaXQsIGJ1dCBvbmx5IGlmIGFuZA0KPndoZW4NCj4NCj4qIG5vIGxpbWl0YXRpb25z IG9uIHNpbXVsdGFuZW91cyBvcGVyYXRpb25zIG9uIHRoZSBzYW1lIGVuZHBvaW50IGFyZSBpbg0K PiAgcGxhY2UsIGFuZA0KPg0KPiogdGhlIGFwcGxpY2F0aW9uIGRvZXMgbm90IHVzZSBkaXN0aW5j dCBSZXF1ZXN0IERpc2NyaW1pbmF0b3JzIHRvDQo+ICBwcmVjbHVkZSBvdXQtb2Ytb3JkZXIgZGVs aXZlcnkgb24gdGhlIHNhbWUgZW5kcG9pbnQuDQo+DQo+DQo+Rm9yIGluY2x1c2lvbiBpbiBPU0NP QVANCj49PT09PT09PT09PT09PT09PT09PT09PQ0KPg0KPkBAQCBpZiB0aGlzIHN0YXlzIGEgZG9j dW1lbnQgb2YgaXRzIG93biwgb3Njb2FwIHNob3VsZCBtYWtlIGEgbm9ybWF0aXZlDQo+cmVmZXJl bmNlIHRvIGl0IGFuZCBzdGF0ZSBzb21ldGhpbmcgbGlrZQ0KPg0KPldoZW5ldmVyIHRoZSBCbG9j azEgb3B0aW9uIGlzIHVzZWQgYXMgaW5uZXIgb3B0aW9uLCBpdCBpcyBhc3NvY2lhdGVkDQo+d2l0 aCBhIFJlcXVlc3QgRGlzY3JpbWluYXRvci4gVGhlIHNhbWUgUmVxdWVzdCBEaXNjcmltaW5hdG9y IE1VU1QgTk9UIGJlDQo+cmV1c2VkIHdpdGhpbiBhIHNlY3VyaXR5IGNvbnRleHQgdW5sZXNzIGV2 ZXJ5IHNpbmdsZSBibG9jayBzZW50IGhhcw0KPmVsaWN0ZWQgYSBwcm90ZWN0ZWQgcmVzcG9uc2Ug KGFuZCBpdHMgc2VxdWVuY2UgbnVtYmVyIGlzIGNvbnNlcXVlbnRseQ0KPm1hcmtlZCB1c2VkKS4g KEBAQCBpZiB3ZSdyZSBjYXV0aW91cywgd2UgY291bGQgcy91bmxlc3MuKi9hdCBhbGwvLCBidXQg aQ0KPmRvbid0IHNlZSBhbnkgaGFybSBpbiBhbGxvd2luZyBpdC4pIE9TQ09BUCByZXF1aXJlcyB0 aGF0IG91dC1vZi1vcmRlcg0KPmRlbGl2ZXJ5IG9mIGJsb2Nrd2lzZSB0cmFuc2ZlcnMgaXMgY2F1 Z2h0IGJ5IHRoZSBSZXF1ZXN0LURpc2NyaW1pbmF0b3INCj5vcHRpb24sIHNvIGEgY2xpZW50IE1V U1QgTk9UIGZhbGwgYmFjayB0byBub3QgdXNpbmcgdGhlDQo+UmVxdWVzdC1EaXNjcmltaW5hdG9y IG9wdGlvbiBpZiBpdCBlbmNvdW50ZXJzIGEgNC4wMiBCYWQgT3B0aW9uDQo+cmVzcG9uc2UuDQo+ DQo+Tm90ZSB0aGF0IHRoaXMgZG9lcyBub3QgcmVxdWlyZSB0aGUgdXNlIG9mIHRoZSBSZXF1ZXN0 LURpc2NyaW1pbmF0b3IgaW4NCj5tYW55IGNhc2VzLiBBbiBhcHBsaWNhdGlvbiBpbXBsZW1lbnRp bmcgT1NDT0FQIE1VU1QgdXNlIHRoYXQgb3B0aW9uIGF0DQo+bGVhc3Qgd2hlbiBhIEJsb2NrMSBy ZXF1ZXN0IGhhcyBub3QgYmVlbiBsb3NzbGVzc2x5IGNvbmNsdWRlZFsqXSwgYW5kIGENCj5zZXJ2 ZXIgTVVTVCBOT1QgcmVzcG9uZCB3aXRoIDQuMDIgZHVlIHRvIHRoZSBwcmVzZW5jZSBvZiBhDQo+ UmVxdWVzdC1EaXNjcmltaW5hdG9yIG9wdGlvbi4gKEBAQCBvciB0aGV5IGNvdWxkIGRlY2xhcmUg dGhlIGNvbXBsZXRlDQo+Y29udGV4dCBpbnZhbGlkLCBidXQgaSBkb24ndCB0aGluayB3ZSB3YW50 IGNvbnRleHRzIHRvIGJlIHRoYXQgdm9sYXRpbGUpDQo+DQo+WypdOiBTaW1wbGUgcGFja2FnZSBs b3NzIHdpbGwgbm90IG1ha2UgYSBkaXNjcmltaW5hdG9yIHVudXNhYmxlLCBiZWNhdXNlDQo+dGhl cmUgaXMgc3RpbGwgQ29BUCByZXRyYW5zbWlzc2lvbiBpbiBwbGFjZS4gT25seSB3aGVuIHRoZSBi bG9jaw0KPnRyYW5zZmVyIGlzIGFib3J0ZWQsIG9yIHdoZW4gdGhlIHNhbWUgYmxvY2sgZ2V0cyBz ZW50IHdpdGggYSBkaWZmZXJlbnQNCj5zZXF1ZW5jZSBudW1iZXIgKEBAQCBtYXkgdGhhdCBiZSBh dCBhbGw/KSwgdGhlIGRpc2NyaW1pbmF0b3IgaXMgdW51c2FibGUNCj5mb3IgYW55IGZ1cnRoZXIg YmxvY2t3aXNlIHRyYW5zZmVyLg0KPg0KPkEgUmVxdWVzdC1EaXNjcmltaW5hdG9yIG9wdGlvbiBN QVkgYmUgdXNlZCB3aGVuIGluaXRpYWxpemluZyBhIEJsb2NrMg0KPnRyYW5zZmVyIGFzIHdlbGwu IEEgc2VydmVyIFNIT1VMRCwgaW5zaWRlIGEgUmVxdWVzdC1EaXNjcmltaW5hdG9yLCBvbmx5DQo+ c2VuZCByZXNwb25zZSBtZXNzYWdlcyB3aXRoIG1hdGNoaW5nIEVUYWdzIGlmIHRoZXkgY2FuIGJl IGV4cGVjdGVkIHRvDQo+YXNzZW1ibGUgaW50byBhIGNvbnNpc3RlbnQgcmVwcmVzZW50YXRpb24g YWdhaW4uIChAQEAgaW1vIHRoYXQncyBhDQo+cmVxdWlyZW1lbnQgdGhhdCB0aGVyZSBhbHJlYWR5 IGlzIGZyb20gdGhlIEVUYWdzIHRoZW1zZWx2ZXMuIGppbSwgZG8geW91DQo+dGhpbmsgdGhpcyBp cyBhIHN0YXJ0aW5nIHBvaW50IGZvciB5b3VyIGNvbmNlcm5zIGFib3V0IHZhbGlkYXRpbmcgdGhl DQo+d2hvbGUgbWVzc2FnZT8pDQo+DQo+DQo+QEBAIHRoaXMgaXMgbW9yZSBvZiBhIHZlcmJhbCBw YXRjaCB0aGFuIHNvbWV0aGluZyBhY3R1YWxseSBpbmNsdWRhYmxlDQo+DQo+VGhlIGFzc29jaWF0 ZWQgUmVxdWVzdCBEaXNjcmltaW5hdG9yIHdpbGwgbmVlZCB0byBiZSBpbmNsdWRlZCBpbiB0aGUN Cj5BQUQuIFdoZXRoZXIgd2UgaW5jbHVkZSB0aGF0IGluIHRoZSByZXF1ZXN0IHRvbyB0byBrZWVw IHRoZSBBQUQgdGhlDQo+c2FtZSBib3RoIGZvciByZXF1ZXN0IGFuZCByZXNwb25zZSwgb3IgaGF2 ZSBpdCBpbiByZXNwb25zZXMgb25seSwgSQ0KPmRvbid0IGNhcmUuDQo+DQo+VGhlIFJlcXVlc3Qt RGlzY3JpbWluYXRvciBvcHRpb24gaXMgYWRkZWQgdG8gdGhlICJFKiIgY2F0ZWdvcnkgYW5kDQo+ bGlrZSBhbmQgbGlzdGVkIHRvZ2V0aGVyIHdpdGggQmxvY2sxLzIuDQo+DQo+DQo+Tm90ZXMgb24g YXBwbGljYXRpb25zDQo+PT09PT09PT09PT09PT09PT09PT09DQo+DQo+QEBAIHNwZWxsIG91dCBl eGFtcGxlIGV4Y2hhbmdlczogcHJveHkgZm9yd2FyZGluZyBtdWx0aXBsZSByZXF1ZXN0cywNCj5v c2NvYXAgYXBwbGljYXRpb24uIGluY2x1ZGUgYSBjYXNlIHdpdGggbm9uLXBpZ2d5YmFja2VkIHJl cG9uc2VzLg0KPg0KPj4gICAgICAgICBDbGllbnQgICAgICAgICAgICAgIEZvZSAgICAgICAgIFNl cnZlcg0KPj4gDQo+PiBQT1NUICJpbmNhcmNlcmF0ZSIoMS8yKSAtLS0+ICAtLS0+DQo+PiAgICAg ICAgICAgICAgICAgICAgICAgIDwtLS0gIDwtLS0gICAyLjMxIENPTlRJTlVFDQo+PiBQT1NUICJ2 YWxqZWFuIigyLzIpICAgICAtLS0+QA0KPj4gICAgICAgICAgICAgICAgICAgICAgICA8LS0tUlNU DQo+PiANCj4+IChDbGllbnQ6IE9kZCwgYnV0IGxldCdzIGdvIG9uIGFuZCBwcm9tb3RlIEphdmVy dCkNCj4+IA0KPj4gUE9TVCAicHJvbW90ZSIoMS8yKSAgICAtLS0+ICAtLS0+DQo+PiAgICAgICAg ICAgICAgICAgICAgICAgPC0tLSAgPC0tLSAgICAyLjMxIENPTlRJTlVFDQo+PiAgICAgICAgICAg ICAgICAgICAgICAgICAgICBAIC0tLT4NCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8 LS0tICAgIDIuMDQgVmFsamVhbiBQcm9tb3RlZCENCj4+IA0KPj4gKFRoZSBAIGluZGljYXRlcyBh IG1hbGljaW91c2x5IGRlbGF5ZWQgLyB3b3JtaG9sZWQgcGFja2FnZSBhcyB1c2VkIGluDQo+DQo+ dGhpcyBjYW4ndCBoYXBwZW4gaW4gb3Njb2FwIG5vdyBhbnkgbW9yZSBiZWNhdXNlIHRoZSBpbmNv bXBsZXRlIGZpcnN0DQo+UE9TVCBwZXJtYW5lbnRseSBwb2lzb25zIHRoZSBmaXJzdCByZXF1ZXN0 J3MgcmVxdWVzdCBkaXNjcmltaW5hdG9yLCBhbmQNCj50aGUgc2Vjb25kIHJlcXVlc3Qgd2lsbCBo YXZlIGEgZGlmZmVyZW50IG9uZSwgZm9yIHdoaWNoIHRoZSBzZXJ2ZXIgd2lsbA0KPm5vdCBhY2Nl cHQgdGhlIGRlbGF5ZWQgInZhbGplYW4iIGFueSBtb3JlLg0KPg0KPlJhdGlvbmFsZQ0KPj09PT09 PT09PQ0KPg0KPlRoaXMgcGFydCBpcyBpbmZvcm1hdGl2ZSBhbmQgc2VydmVzIHRvIGlsbHVzdHJh dGUgd2h5IHRoaXMgb3B0aW9uIGlzDQo+bmVjZXNzYXJ5LCBhbmQgaG93IGl0IGlzIGRpZmZlcmVu dCBmcm9tIHNpbWlsYXIgY29uY2VwdHMuDQo+DQo+V2h5IG5vdCB1c2UuLi4NCj4NCj4qIGFub3Ro ZXIgcG9ydDogUHJveHkgaW1wbGVtZW50YXRpb25zIGNhbiB3b3JrIGFyb3VuZCB0aGUgc2ltdWx0 YW5lb3VzDQo+ICB0cmFuc2ZlciByZXN0cmljdGlvbnMgYnkgdXNpbmcgZGlmZmVyZW50IHBvcnRz IGFzIGEgY2xpZW50LiBUaGlzIGlzDQo+ICBub3QgcG9zc2libGUgd2l0aCBzb21lIGNvbnN0cmFp bmVkIGltcGxlbWVudGF0aW9ucyAod2hpY2ggdHlwaWNhbGx5DQo+ICBnZXQgdGhlaXIgb25lIHN0 YXRpYyBzb2NrZXQgZnJvbSB0aGUgb3BlcmF0aW5nIHN5c3RlbSkuIE1vcmVvdmVyLCBmb3INCj4g IHRoZSBPU09DQVAgaW5uZXItYm9ja3dpc2UgYXBwbGljYXRpb24sIHRoZSBiZXN0IGVxdWl2YWxl bnQgd291bGQgYmUNCj4gIHN0YXJ0aW5nIGFub3RoZXIgY29udGV4dCwgd2hpY2ggaXMgYXBwbGlj YXRpb24gZGVwZW5kZW50IGFuZCB2ZXJ5DQo+ICBjb3N0bHkuDQo+DQo+ICBNb3Jlb3Zlciwgc29t ZSB0cmFuc3BvcnRzIGRvIG5vdCBoYXZlIGFueSBzdWNoIHZhcmlhYmlsaXR5IChAQEANCj4gIG92 ZXItc2VyaWFsLCBvciBpcyB0aGVyZSBzb21ldGhpbmcgbW9yZSBjb21wbGV0ZSB0aGF0IGhhcyB0 aGUgc2FtZQ0KPiAgbGltaXRhdGlvbj8pDQo+DQo+KiBleHRlbmQgdGhlIGJsb2Nrd2lzZSBtZWNo YW5pc20gd2l0aCBhbm90aGVyIG9wdGlvbjogVGhhdCB3b3VsZCBub3QNCj4gIG1ha2UgdGhpbmdz IGVhc2llciBpbiB0aGUgYXV0aG9yJ3Mgb3Bpbmlvbi4NCj4NCj4qIHB1dCBhIGRpc2NyaW1pbmF0 b3IgaW50byBPU0NPQVA6IFRoYXQgd291bGQgaGF2ZSB0aGUgc2FtZSBlZmZlY3QgZm9yDQo+ICB0 aGUgT1NDT0FQIGlubmVyLWJsb2Nrd2lzZSBjYXNlLiBJdCB3b3VsZCBzdGlsbCBub3QgYWxsb3cg ZGlmZmVyZW50DQo+ICBPU0NPQVAgcmVxdWVzdHMgdG8gaGFwcGVuIGNvbmN1cnJlbnRseSBvbiBh IGRldmljZSAoZXNwZWNpYWxseSBpbiB0aGUNCj4gIHByZXNlbmNlIG9mIHByb3h5aW5nKS4NCj4N Cj5Ib3cgaXMgdGhpcyBpZGVudGlmaWVyIGRpZmZlcmVudCBmcm9tIHRoZS4uLg0KPg0KPiogbWVz c2FnZSBJRCBhbmQgdG9rZW46IEJvdGggYXJlIGRlZmluZWQgb24gdGhlIHNhbWUgbGV2ZWwgYXMg dGhlDQo+ICBSZXF1ZXN0IERpc2NyaW1pbmF0b3IgKHRoYXQgaXMsIGZyb20gZW5kcG9pbnQgdG8g ZW5kcG9pbnQpLCBidXQgdGhlDQo+ICBkaXNjcmltaW5hdG9yIGhhcyBhbiBldmVuIGxvbmdlciBs aWZldGltZSB0aGFuIHRoZSB0b2tlbiBpbiB0aGF0IGl0DQo+ICBhdCBsZWFzdCBzcGFucyBhbGwg dGhlIHJlcXVlc3RzIHRyYW5zZmVycmVkIHdpdGhpbiBhIGJsb2Nrd2lzZQ0KPiAgdHJhbnNmZXIu DQo+DQo+KiBPU0NPQVAncyBzZXF1ZW5jZSBudW1iZXI6IEFzIHRoZSBhYm92ZSwgdGhlIHNlcXVl bmNlIG51bWJlciBpcyBvbmx5DQo+ICB1c2VkIGZvciBhIHNpbmdsZSBleGNoYW5nZSwgYW5kIGRv ZXMgbm90IHNwYW4gYSBibG9ja3dpc2UgdHJhbnNmZXIuDQo+ICBJbXBsZW1lbnRhdGlvbnMgbWln aHQsIGhvd2V2ZXIsIG9wdCB0byB1c2UgdGhlIHNlcXVlbmNlIG51bWJlciBvZiB0aGUNCj4gIGZp cnN0IHBhY2thZ2Ugb2YgYSBibG9ja3dpc2UgdHJhbnNmZXIgYXMgdGhlIFJlcXVlc3QgRGlzY3Jp bWluYXRvciBmb3INCj4gIHRoZSB3aG9sZSB0cmFuc2Zlci4NCj4NCj4qIEVUYWc6IFdoaWxlIHRo ZSBSZXF1ZXN0IERpc2NyaW1pbmF0b3Igb3B0aW9uIHNlcnZlcyBhIHNpbWlsYXIgcHVycG9zZQ0K PiAgaW4gYmxvY2t3aXNlIHRyYW5zZmVycyBhcyB0aGUgRVRhZyAoRVRhZyBhbGxvd3MgdGhlIGNs aWVudCB0byBmaWx0ZXINCj4gIG5vbi1tYXRjaGluZyBCbG9jazIgcmVzcG9uc2VzLCBSZXF1ZXN0 LURpc2NyaW1pbmF0b3IgYWxsb3dzIHRoZSBzZXJ2ZXINCj4gIHRvIGZpbHRlciBub24tbWF0Y2hp bmcgQmxvY2sxIHJlcXVlc3RzKSwgdGhlIEVUYWcgaXMgc3RhYmx5IGRldGVybWluZWQNCj4gIGJ5 IHRoZSBzZXJ2ZXIgKGFuZCBjYW4gdGh1cyBiZSB1c2VkIGZvciBjYWNoaW5nKSwgd2hpbGUgdGhl IFJlcXVlc3QNCj4gIERpc2NyaW1pbmF0b3IgaXMgYW4gZXBoZW1lcmFsIGxhYmVsIHVzZWQgZXhj bHVzaXZlbHkgZHVyaW5nIHRoZQ0KPiAgdHJhbnNmZXIuDQo+DQo+VGhlIG5hbWluZyBvZiBvcHRp b25zDQo+PT09PT09PT09PT09PT09PT09PT09DQo+DQo+QEBAIHRoaXMgc2VjdGlvbiB3aWxsIG9i dmlvdXNseSBiZSByZW1vdmVkIG92ZXIgdGltZS4NCj4NCj5UaGUgbmFtaW5nIG9mIG9wdGlvbnMg aXMgYSBkaWZmaWN1bHQgbWF0dGVyIC0tIGVzcGVjaWFsbHkgaGVyZSB3aGVyZSB0aGUNCj51c2Ug dG8gdGhlIGFwcGxpY2F0aW9uIChkZXNjcmliaW5nIHdoaWNoIHJlcXVlc3RzIG9mIGEgYmxvY2t3 aXNlIGJ1bmNoDQo+YmVsb25nIHRvZ2V0aGVyKSBkZXZpYXRlcyBmcm9tIHdoYXQgaXQgYnkgaXRz IGRlZmluaXRpb24gKGFuZCBpbg0KPmltcGxlbWVudGF0aW9uKSBkb2VzLCB0aGF0IGlzLCBwcm92 aWRlIGEgbGlnaHR3ZWlnaHQgc3ViLWNoYW5uZWwgaW5zaWRlDQo+dGhlIGNoYW5uZWwgZGVzY3Jp YmVkIGJ5IHRoZSBlbmRwb2ludCBhZGRyZXNzLg0KPg0KPkFsdGVybmF0aXZlcyB1bmRlciBjdXJy ZW50IGNvbnNpZGVyYXRpb24gYXJlOg0KPg0KPiogUmVxdWVzdC1UYWc6IE1vcmUgb24gdGhlIEJs b2NrMSBhcHBsaWNhdGlvbiBzaWRlLCBpbiBwYXJhbGxlbCB0byB0aGUNCj4gIEVUYWcgdGhhdCB0 aGUgY2xpZW50IHVzZXMgdG8gbWFrZSBzdXJlIHRoZSByZXNwb25zZXMgdG8gaXRzIEJsb2NrMg0K PiAgcmVxdWVzdCBtYXRjaCB1cC4NCj4NCj4gIENvdWxkIGxlYWQgdG8gY29uZnVzaW9uIHdoZW4g dXNlZCBpbiBhbnkgY29udGV4dCB0aGF0IHJlbGllcyBvbg0KPiAgZW5kcG9pbnRzIGJ1dCBpcyBu b3QgYmxvY2t3aXNlLg0KPg0KPiogRW5kcG9pbnQtRGlzY3JpbWluYXRvcjogT24gdGhlIG90aGVy IGVuZCBvZiB0aGUgc3BlY3RydW0uIFRlY2huaWNhbGx5DQo+ICBjb3JyZWN0LCBidXQgaXRzIHVz ZSBpbiBhIGJsb2Nrd2lzZSB0cmFuc2ZlciBpcyBub3QgaW1tZWRpYXRlbHkNCj4gIG9idmlvdXMu DQo+DQo+KiBSZXF1ZXN0LURpc2NyaW1pbmF0b3I6IFNvbWUgbWlkZGxlIGdyb3VuZC4gSSdkIHVu ZGVyc3RhbmQgaXQgbm90IGFzDQo+ICBtdWNoIGFzIHNvbWV0aGluZyB0aGF0IGRpc2NyaW1pbmF0 ZXMgYmV0d2VlbiByZXF1ZXN0cywgYnV0IGENCj4gIGRpc2NyaW1pbmF0b3IgaW50cm9kdWNlZCBi eSB0aGUgcmVxdWVzdGVyLg0KPg0KPlN0YW5kYXJkIGh5Z2llbmUNCj49PT09PT09PT09PT09PT09 DQo+DQo+QEBAIGlmIHRoaXMgc3RheXMgaW4gYXQgYWxsLCBpdCdsbCBiZSBzaG9ydGVuZWQgaW50 byBzb21lIGtpbmQgb2YNCj4nYWRkaXRpb25hbCBjb25zaWRlcmF0aW9ucycgLS0gZGVwZW5kaW5n IG9uIGhvdyBtdWNoIGRpc2N1c3Npb24gdGhlcmUgaXMNCj5vbiBpdC4NCj4NCj5UaGlzIGRyYWZ0 IGRvZXMgc29tZXRoaW5nIHRoYXQgbWlnaHQgYmUgY29uc2lkZXJlZCBkaXJ0eSBpbiB0ZXJtcyBv ZiBSRkMNCj5pbnRlcmFjdGlvbjogSXQgZGVmaW5lcywgd2hlbiBpbXBsZW1lbnRlZCwgYWRkaXRp b25hbCBzZW1hbnRpY3MgaW50byB0aGUNCj50ZXJtICJzYW1lIGVuZHBvaW50IiAtLSBvbmUgY291 bGQgc2F5IHRoYXQgaXQgaGlqYWNrcyB0aGUgdGVybSB0byBiZSBhbg0KPmV4dGVuc2lvbiBwb2lu dC4gVGhpcyBpcyBkb25lIHJpZ2h0IG5vdyBiZWNhdXNlOg0KPg0KPiogSXQga2VlcHMgUkZDIGlu dGVyZGVwZW5kZW5jaWVzIGxvdy4NCj4NCj4qIEl0IGlzIGNvbXBhdGlibGUgaW4gdGhlIHNlbnNl IHRoYXQgd2hvZXZlciBkb2VzIG5vdCBpbXBsZW1lbnQgdGhpcw0KPiAgb3B0aW9uIChhbmQgY29u c2VxdWVudGx5IHJlc3BvbmRzIDQuMDIgQmFkIE9wdGlvbiB0byBpdHMgdXNlKSBkbw0KPiAgdHJp dmlhbGx5IGltcGxlbWVudCB0aGUgY2hhbmdlZCBzZW1hbnRpY3MgYnkganVzdCBub3QgYWxsb3dp bmcgdGhlDQo+ICBSZXF1ZXN0LURpc2NyaW1pbmF0b3Igb3B0aW9uIHRvIHRha2UgYW55IG90aGVy IHZhbHVlIHRoYW4gbm9uZS4NCj4NCj4qIEl0IGFsbG93cyBsYXRlciBvciBjb25jdXJyZW50IGRy YWZ0cyB0byB1c2UgdGhlICJzYW1lIGVuZHBvaW50Ig0KPiAgc2VtYW50aWNzIGFuZCBvcHRpb25h bGx5IHV0aWxpemUgdGhpcyBleHRlbnNpb24gd2l0aG91dCBtYW5kYXRpbmcgaXQNCj4gIGFzIGEg ZGVwZW5kZW5jeS4NCj4NCj4qIFJGQzcyNTIgYWxyZWFkeSBkZWZpbmVzICJFbmRwb2ludCIgdG8g aW5jbHVkZSB0aGUgc2VjdXJpdHkNCj4gIGFzc29jaWF0aW9uLiBHaXZlbiB0aGlzIHByb3RlY3Rz IGJsb2Nrd2lzZSB0cmFuc2ZlcnMgYWdhaW5zdCBhIHZlcnkNCj4gIHNtYWxsIHJhbmdlIG9mIGF0 dGFja3MgKHRob3NlIHdoZXJlIHRoZSBhdHRhY2tlciBjYW4ndCBtb2RpZnkgdGhlDQo+ICBtZXNz YWdlLCBidXQgZGVsYXkgaXQpLCB0aGlzIGNhbiBiZSBzZWVuIGFzIGEgc2VjdXJpdHkgbW9kZSBh bmQgdGhlbg0KPiAgcGx1ZyBpbnRvIHRoZSBleHRlbnNpb24gcG9pbnQgZGVzY3JpYmVkIGluIFJG QzcyNTIgNC4xLg0KPg0KPlNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQo+PT09PT09PT09PT09PT09 PT09PT09PT0NCj4NCj5UaGUgUmVxdWVzdCBEaXNjcmltaW5hdG9yIGlzIGxpbWl0ZWQgaW4gaXRz IHVzZWQgYmV0d2VlbiBhIHBhaXIgb2YgZW5kDQo+cG9pbnRzLiBJZiB1c2VkIGNvbnNlcnZhdGl2 ZWx5IChpZS4gb25seSB3aGVuIG5lY2Vzc2FyeSwgYW5kIHdpdGgNCj5hcy1zbWFsbC1hcy1wb3Nz aWJsZSByYW5kb20gZGlzY3JpbWluYXRvcnMpLCBpdCBvbmx5IGluZGljYXRlcyB0aGF0IChhbmQN Cj5yb3VnaGx5IGhvdyBtYW55KSBvcGVyYXRpb25zIHRoYXQgcmVxdWlyZSBkaXN0aW5jdCBlbmRw b2ludHMgYXJlIGluDQo+c2ltdWx0YW5lb3VzIHVzZSBvciBoYXZlIHByZXZpb3VzbHkgYmVlbiB1 bnN1Y2Nlc3NmdWwuDQo+DQo+V2hlbiB1c2VkIHRvIHByZWNsdWRlIG91dC1vZi1vcmRlciBzaXR1 YXRpb25zIGJldHdlZW4gZW5kcG9pbnRzIChhcyBmb3INCj5leGFtcGxlIGluIE9TQ09BUCksIGl0 IGlzIGVzc2VudGlhbCB0aGF0IGltcGxlbWVudGF0aW9ucyBzdG9yZSB0aGUNCj51c2FibGUgc3Rh dGUgb2YgYSBkaXNjcmltaW5hdG9yIGZvciBhcyBsb25nIGFzIHJlcXVpcmVkIChlZy4gaW4gcGFy YWxsZWwNCj53aXRoIHNlcXVlbmNlIG51bWJlcnMpLiBGYWlsdXJlIHRvIGRvIHNvIGxlYWRzIHRv IHJldXNlIG9mIGENCj5kaXNjcmltaW5hdG9yLCBhbmQgdGh1cyBvcGVucyB1cCB0aGUgcG9zc2li aWxpdHkgb2YgcmVwbGF5cy4NCj4NCj5TZXJ2ZXJzIHRoYXQgcmVseSBvbiBjb25zaXN0ZW50IHN0 YXRlcyBzZXQgYnkgY2xpZW50cyBtdXN0IGJlIGF3YXJlIHRoYXQNCj50aGUgb3V0LW9mLW9yZGVy IGd1YXJhbnRlZXMgYWRkZWQgYnkgdGhpcyBtZWNoYW5pc20gb25seSBjb3Zlcg0KPm9wZXJhdGlv bnMgdGhhdCBhcmUgcmVxdWlyZWQgYnkgUkZDNzk1OSB0byBvcmlnaW5hdGUgZnJvbSB0aGUgc2Ft ZQ0KPmVuZHBvaW50IChvciBzZWN1cml0eSBhc3NvY2lhdGlvbikuIEJsb2NrMSByZXF1ZXN0cyBz aG91bGQgdGhlcmVmb3JlIGJlDQo+bGltaXRlZCB0byBhdG9taWMgb3BlcmF0aW9ucyBhcyBvdXRs aW5lZCBpbiB0aGF0IGRvY3VtZW50J3Mgc2VjdXJpdHkNCj5jb25zaWRlcmF0aW9ucy4NCj4NCj5J QU5BIENvbnNpZGVyYXRpb25zDQo+PT09PT09PT09PT09PT09PT09PQ0KPg0KPkBAQCBoYXZlIGEg bnVtYmVyIGFzc2lnbmVkIGFuZCB0aGUgb3B0aW9uIGtub3duDQo+DQo+UmVmZXJlbmNlcw0KPj09 PT09PT09PT0NCj4NCj5Db0FQDQo+DQo+QEBAIGkgdGhpbmsgaSBjYW4gZ2V0IGF3YXkgd2l0aCBv bmx5IGhhdmluZyBjb2FwIGFzIGEgbm9ybWF0aXZlDQo+cmVmZXJlbmNlIGhlcmUgKHBsdXMgMjEx OSBpZiBrZXl3b3JkcyBhcmUgdXNlZCksIHRob3VnaCBibG9ja3dpc2UgbWlnaHQNCj5iZSByZXF1 aXJlZCB0b28gZHVlIHRvIGl0IHVwZGF0aW5nIGNvYXAuDQo+DQo+SW5mb3JtYXRpdmUgUmVmZXJl bmNlcw0KPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4NCj5PU0NPQVANCj5ibG9ja3dpc2UNCj5j b2FwLW92ZXItc2VyaWFsIGlmIHJlZmVyZW5jZWQNCj4NCj4tLSANCj5DaHJpc3RpYW4gQW1zw7xz cyAgICAgICAgICAgICAgICAgICAgICB8IEVuZXJneSBIYXJ2ZXN0aW5nIFNvbHV0aW9ucyBHbWJI DQo+Zm91bmRlciwgc3lzdGVtIGFyY2hpdGVjdCAgICAgICAgICAgICB8IGhlYWRxdWFydGVyOg0K Pm1haWx0bzpjLmFtc3Vlc3NAZW5lcmd5aGFydmVzdGluZy5hdCAgfCBBcmJlaXRlcmdhc3NlIDE1 LCBBLTQ0MDAgU3RleXINCj50ZWw6KzQzLTY2NC05Ny05MC02LTM5ICAgICAgICAgICAgICAgIHwg aHR0cDovL3d3dy5lbmVyZ3loYXJ2ZXN0aW5nLmF0Lw0KPiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCBBVFU2ODQ3NjYxNA0KDQo= From nobody Sun Mar 5 21:47:17 2017 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 413CB129424 for ; Sun, 5 Mar 2017 21:47:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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=augustcellars.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 3AIbVjrn1UKE for ; Sun, 5 Mar 2017 21:47:14 -0800 (PST) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25D1C129401 for ; Sun, 5 Mar 2017 21:47:13 -0800 (PST) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1488779230; h=from:subject:to:date:message-id; bh=56PAs4DiVmP6RVEQb5yIZS4BmEIcYQHWDUzHbf+5N90=; b=jkCusLOnbr4xpPtPdybcOi2XX8fzOl3ucPHPEs9BtQdG0EQZ00lEcPkbGLkOFdr8o2zq7ZgFxGy SR1XXePlv5STY1ID/Ba3l7DTYRpTxzOD2PFy4JZy03xmMqmbG4tlMxE5tSDXsbkNkobMn23drYGGo UAQDJXga5bdv/rS6LJ0jT4TmbzfUltS7BbIQGTNyc59zuM7u6YX6bJaYNCcRLcr4OGcZkoESNThBC XFxwi0XAjgFRTYwKoI5hKrDJ3uJEyPiawJU3XxgWR02pCJHAexRE70n3yBmKyN2GXjAv49I9U0L80 A136juc/es7CQM9+9D5Jd7igJmm4cAQosHxg== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 5 Mar 2017 21:47:09 -0800 Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 5 Mar 2017 21:44:52 -0800 From: Jim Schaad To: =?iso-8859-1?Q?'Christian_Ams=FCss'?= , References: <20170303173229.uj7av3xia4prxku3@hephaistos.amsuess.com> In-Reply-To: <20170303173229.uj7av3xia4prxku3@hephaistos.amsuess.com> Date: Sun, 5 Mar 2017 21:47:03 -0800 Message-ID: <069c01d2963d$16fda9e0$44f8fda0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHgVXLESQVLl1aeZRwIVJwzh3yX/qFprNWg X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [core] pre-draft: Request-Tag X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 06 Mar 2017 05:47:16 -0000 Christian, I am sorry, but I do not believe that this is the correct approach to = take. 1. I want a value that can be modified in transit. For that reason, it should not be authenticated. The ability for a proxy to change means = that it always has the ability to do the disambiguation if two different = clients come in apparently asking for the same thing, but with a different and masked disambiguation. 2. It is my belief that the cue to use the new option is not correct at all. The new option is not needed for any OSCOAP internal blocking. It = is needed solely to deal with outer blocking. This means that it is more likely to be needed if an inner Block1 is absent than if it is present. = The assumption if it is present is that it SHOULD be sufficient to deal with = the problem. =20 As I read the problem that you have outlined below, it does not appear = to match the same problem that I think needs to be solved. I don't know if your problem is real or not, I don't have a sufficient understanding of = your description and should go look at the mail message referenced to see if = that helps, but I have been having a problem getting to things this weekend. In regarding to states of drafts to publish. I have done everything = from a sketch of a draft to a fully written draft as a first document = published. Don't let that be a barrier to publication. The only question is do you think you have enough to give a brief overview of the problem. Often = times it is easier to see ASCII art in drafts since they are a fixed width = font. Jim > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Christian = Ams=FCss > Sent: Friday, March 3, 2017 9:32 AM > To: core@ietf.org > Subject: [core] pre-draft: Request-Tag >=20 > Hello working group, hello OSCOAP people, >=20 > discussion from the OSCOAP draft has at different layers hit the = problem of > blockwise requests being linked together only via the endpoint = address[1]. >=20 > Encouraged by G=F6ran, I'd like to suggest a new option to CoAP that = would > primarily solve OSCOAP's problem, but also allow faster responses from > proxies by simultaneous processing of block1 requests. >=20 > Below is an early version of what I'd like to submit as a draft. I = would > appreciate feedback on it, especially on the approach of packing this = into the > endpoint definition instead of just defining a blockwise extension. = Note that > the actual definition of the change is more concise now than in my previous > sketch, because many things I spellt out ther explicitly fall into = place > automatically because of the endpoint discrimination. (For example, = the > "atomic vs non-atomic" considerations are now merely a reference to = what > blockwise already noted in its security context). >=20 > Best regards > Christian >=20 > PS. what's the expected level of maturity for an individual submission upload > into the data tracker? >=20 > [1]: http://www.ietf.org/mail-archive/web/core/current/msg08299.html >=20 >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Request-Discriminator option > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Abstract > =3D=3D=3D=3D=3D=3D=3D=3D >=20 > This memo describes an optional extension to the Constrained = Application > Protocol (CoAP, RFC7252) that allows extending the endpoint context of = a > request with an additional discriminator. This allows processing concurrent > requests that would otherwise be serialized by proxies in presence of > blockwise transfer, and linking blockwise requests on transports that = do > provide authentication but no ordering guarantees. >=20 > Introduction > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Blockwise transfer [RFC7959] in the presence of Block1 ties an = exchange to a > combination of resource and remote endpoint, keeping any two exchanges > where those parameters match from happening simultaneously. > Wherever either of those parameters get conflated (eg. because a proxy acts > as a single endpoint towards a server when forwarding operations on = the > same resource, or in Object Security of CoAP (OSCOAP) where all a = client's > request are targetted at the same resource from an outside point of = view), > the client needs to queue up requests to keep the transfers from overriding > each other. >=20 > (@@@ who else references 'same Endpoint'? other documents could be > affected of profit) >=20 > The OSCOAP security layer provides message integrity and replay protection, > but with blockwise, the security context (which augments the endpoint > address) alone is insufficient protection because it does not (and = does not > indent to) forbid out-of-order delivery. >=20 > Both situations can be mitigated by allowing the client to add an additional > discriminator (the Request-Disciminator option), which must be treated = as a > part of the (security context of an) endpoint as defined in RFC7252 section > 1.2. >=20 > Terminology > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > The terms Endpoint, byte, @@@ are used as in RFC7252. >=20 > An exchange is @@@ the thing with tokens and not MIDs -- should check > with OSCOAP, i never really considered it there, and it didn't happen = in the > tests >=20 > Request Discriminator: An opaque identifier chosen by the client. It = can > be absent or a string of up to 8 bytes, including the empty string. > The phrasing as two words always indicates such a value, while > Request-Discriminator (with dash) is the CoAP option in which it is > transferred. >=20 > The Request-Discriminator option > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >=20 > A new option is defined for all request methods: >=20 > +-----+---+---+---+---+-----------------------+--------+--------+--------= -+ > | No. | C | U | N | R | Name | Format | Length | Default | > +-----+---+---+---+---+-----------------------+--------+--------+--------= -+ > | TBD | x | x | - | | Request-Discriminator | opaque | 0-8 | (none) | > +-----+---+---+---+---+-----------------------+--------+--------+--------= -+ >=20 > C=3DCritical, U=3DUnsafe, N=3DNoCacheKey, R=3DRepeatable >=20 > It is critical (because mechanisms may rely on endpoint identities not = to be > conflated), unsafe (because the channels implied by endpoint = identities > terminate at proxies), not repeatable. (@@@ unsafe makes nocachekey > irrelevant, but should we or not set it to ease proxy > implementations?) >=20 > A client may set a Request-Discriminator option to indicate that the > message's Endpoint is to be augmented with the opaque option value. = The > server MUST NOT treat the message's endpoint as equal to any other > message's endpoint that does not have the identical = Request-Discriminator. > The absence of the option and a zero-length option are distinct. (@@@ = i > wouldn't insist on that -- especially with the inclusion in the AAD it might be > better to have absence and h"" > equal, so we don't have variable types in the AAD) >=20 > The option is not used in responses. Response messages implicitly bear their > corresponding (via the token @@@ or better refer to Exchange > definition?) request's discriminator. >=20 > If a request that uses Request-Discriminator is rejected with 4.02 Bad Option, > the client SHOULD retry the request without it, but only if and when >=20 > * no limitations on simultaneous operations on the same endpoint are = in > place, and >=20 > * the application does not use distinct Request Discriminators to > preclude out-of-order delivery on the same endpoint. >=20 >=20 > For inclusion in OSCOAP > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > @@@ if this stays a document of its own, oscoap should make a = normative > reference to it and state something like >=20 > Whenever the Block1 option is used as inner option, it is associated = with a > Request Discriminator. The same Request Discriminator MUST NOT be > reused within a security context unless every single block sent has elicted a > protected response (and its sequence number is consequently marked > used). (@@@ if we're cautious, we could s/unless.*/at all/, but i = don't see > any harm in allowing it.) OSCOAP requires that out-of-order delivery = of > blockwise transfers is caught by the Request-Discriminator option, so = a client > MUST NOT fall back to not using the Request-Discriminator option if it > encounters a 4.02 Bad Option response. >=20 > Note that this does not require the use of the Request-Discriminator = in many > cases. An application implementing OSCOAP MUST use that option at = least > when a Block1 request has not been losslessly concluded[*], and a = server > MUST NOT respond with 4.02 due to the presence of a Request- > Discriminator option. (@@@ or they could declare the complete context > invalid, but i don't think we want contexts to be that volatile) >=20 > [*]: Simple package loss will not make a discriminator unusable, = because > there is still CoAP retransmission in place. Only when the block = transfer is > aborted, or when the same block gets sent with a different sequence > number (@@@ may that be at all?), the discriminator is unusable for = any > further blockwise transfer. >=20 > A Request-Discriminator option MAY be used when initializing a Block2 > transfer as well. A server SHOULD, inside a Request-Discriminator, = only send > response messages with matching ETags if they can be expected to = assemble > into a consistent representation again. (@@@ imo that's a requirement = that > there already is from the ETags themselves. jim, do you think this is = a starting > point for your concerns about validating the whole message?) >=20 >=20 > @@@ this is more of a verbal patch than something actually includable >=20 > The associated Request Discriminator will need to be included in the = AAD. > Whether we include that in the request too to keep the AAD the same = both > for request and response, or have it in responses only, I don't care. >=20 > The Request-Discriminator option is added to the "E*" category and = like and > listed together with Block1/2. >=20 >=20 > Notes on applications > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > @@@ spell out example exchanges: proxy forwarding multiple requests, > oscoap application. include a case with non-piggybacked reponses. >=20 > > Client Foe Server > > > > POST "incarcerate"(1/2) ---> ---> > > <--- <--- 2.31 CONTINUE > > POST "valjean"(2/2) --->@ > > <---RST > > > > (Client: Odd, but let's go on and promote Javert) > > > > POST "promote"(1/2) ---> ---> > > <--- <--- 2.31 CONTINUE > > @ ---> > > <--- 2.04 Valjean Promoted! > > > > (The @ indicates a maliciously delayed / wormholed package as used = in >=20 > this can't happen in oscoap now any more because the incomplete first = POST > permanently poisons the first request's request discriminator, and the > second request will have a different one, for which the server will = not accept > the delayed "valjean" any more. >=20 > Rationale > =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > This part is informative and serves to illustrate why this option is necessary, > and how it is different from similar concepts. >=20 > Why not use... >=20 > * another port: Proxy implementations can work around the simultaneous > transfer restrictions by using different ports as a client. This is > not possible with some constrained implementations (which typically > get their one static socket from the operating system). Moreover, = for > the OSOCAP inner-bockwise application, the best equivalent would be > starting another context, which is application dependent and very > costly. >=20 > Moreover, some transports do not have any such variability (@@@ > over-serial, or is there something more complete that has the same > limitation?) >=20 > * extend the blockwise mechanism with another option: That would not > make things easier in the author's opinion. >=20 > * put a discriminator into OSCOAP: That would have the same effect for > the OSCOAP inner-blockwise case. It would still not allow different > OSCOAP requests to happen concurrently on a device (especially in = the > presence of proxying). >=20 > How is this identifier different from the... >=20 > * message ID and token: Both are defined on the same level as the > Request Discriminator (that is, from endpoint to endpoint), but the > discriminator has an even longer lifetime than the token in that it > at least spans all the requests transferred within a blockwise > transfer. >=20 > * OSCOAP's sequence number: As the above, the sequence number is only > used for a single exchange, and does not span a blockwise transfer. > Implementations might, however, opt to use the sequence number of = the > first package of a blockwise transfer as the Request Discriminator = for > the whole transfer. >=20 > * ETag: While the Request Discriminator option serves a similar = purpose > in blockwise transfers as the ETag (ETag allows the client to filter > non-matching Block2 responses, Request-Discriminator allows the = server > to filter non-matching Block1 requests), the ETag is stably = determined > by the server (and can thus be used for caching), while the Request > Discriminator is an ephemeral label used exclusively during the > transfer. >=20 > The naming of options > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > @@@ this section will obviously be removed over time. >=20 > The naming of options is a difficult matter -- especially here where = the use to > the application (describing which requests of a blockwise bunch belong > together) deviates from what it by its definition (and in > implementation) does, that is, provide a lightweight sub-channel = inside the > channel described by the endpoint address. >=20 > Alternatives under current consideration are: >=20 > * Request-Tag: More on the Block1 application side, in parallel to the > ETag that the client uses to make sure the responses to its Block2 > request match up. >=20 > Could lead to confusion when used in any context that relies on > endpoints but is not blockwise. >=20 > * Endpoint-Discriminator: On the other end of the spectrum. = Technically > correct, but its use in a blockwise transfer is not immediately > obvious. >=20 > * Request-Discriminator: Some middle ground. I'd understand it not as > much as something that discriminates between requests, but a > discriminator introduced by the requester. >=20 > Standard hygiene > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > @@@ if this stays in at all, it'll be shortened into some kind of 'additional > considerations' -- depending on how much discussion there is on it. >=20 > This draft does something that might be considered dirty in terms of = RFC > interaction: It defines, when implemented, additional semantics into = the > term "same endpoint" -- one could say that it hijacks the term to be = an > extension point. This is done right now because: >=20 > * It keeps RFC interdependencies low. >=20 > * It is compatible in the sense that whoever does not implement this > option (and consequently responds 4.02 Bad Option to its use) do > trivially implement the changed semantics by just not allowing the > Request-Discriminator option to take any other value than none. >=20 > * It allows later or concurrent drafts to use the "same endpoint" > semantics and optionally utilize this extension without mandating it > as a dependency. >=20 > * RFC7252 already defines "Endpoint" to include the security > association. Given this protects blockwise transfers against a very > small range of attacks (those where the attacker can't modify the > message, but delay it), this can be seen as a security mode and then > plug into the extension point described in RFC7252 4.1. >=20 > Security Considerations > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > The Request Discriminator is limited in its used between a pair of end points. > If used conservatively (ie. only when necessary, and with as-small-as- > possible random discriminators), it only indicates that (and roughly = how > many) operations that require distinct endpoints are in simultaneous = use or > have previously been unsuccessful. >=20 > When used to preclude out-of-order situations between endpoints (as = for > example in OSCOAP), it is essential that implementations store the = usable > state of a discriminator for as long as required (eg. in parallel with sequence > numbers). Failure to do so leads to reuse of a discriminator, and thus opens > up the possibility of replays. >=20 > Servers that rely on consistent states set by clients must be aware = that the > out-of-order guarantees added by this mechanism only cover operations > that are required by RFC7959 to originate from the same endpoint (or > security association). Block1 requests should therefore be limited to atomic > operations as outlined in that document's security considerations. >=20 > IANA Considerations > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > @@@ have a number assigned and the option known >=20 > References > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > CoAP >=20 > @@@ i think i can get away with only having coap as a normative = reference > here (plus 2119 if keywords are used), though blockwise might be = required > too due to it updating coap. >=20 > Informative References > ---------------------- >=20 > OSCOAP > blockwise > coap-over-serial if referenced >=20 > -- > Christian Ams=FCss | Energy Harvesting Solutions = GmbH > founder, system architect | headquarter: > mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr > tel:+43-664-97-90-6-39 | = http://www.energyharvesting.at/ > | ATU68476614 From nobody Mon Mar 6 01:06:23 2017 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 1A92812961F; Mon, 6 Mar 2017 01:06:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 1LdHR8lVZknR; Mon, 6 Mar 2017 01:06:20 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E81F812961D; Mon, 6 Mar 2017 01:06:19 -0800 (PST) X-AuditID: c1b4fb2d-3f1b7980000042de-3b-58bd268958cf Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id 7D.F5.17118.9862DB85; Mon, 6 Mar 2017 10:06:18 +0100 (CET) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.81) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 6 Mar 2017 10:05:57 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZU31XWFoFnnCKunrGCWYOr65GprH+/2CCSrygJuIA4E=; b=ict312eqfiQl1Popz9LvPjltJAK9aE+OHax3r+DrK+oDYUbL1K+WGEbUBr5w6jXHUIF0pkN6FpGNHYrcODIWduU2cbT+lhUGhtmvcGDWesXbc1MpdoOae1c+tD8otHn77C7Ozdp0IunX6LSkh2Mo0+4sh/ZnAw1/6kTQLOmJiW4= Received: from HE1PR0701MB2539.eurprd07.prod.outlook.com (10.168.129.17) by HE1PR0701MB2537.eurprd07.prod.outlook.com (10.168.129.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.2; Mon, 6 Mar 2017 09:05:56 +0000 Received: from HE1PR0701MB2539.eurprd07.prod.outlook.com ([10.168.129.17]) by HE1PR0701MB2539.eurprd07.prod.outlook.com ([10.168.129.17]) with mapi id 15.01.0947.012; Mon, 6 Mar 2017 09:05:56 +0000 From: Francesca Palombini To: "core@ietf.org" , "core-chairs@ietf.org" Thread-Topic: OSCOAP interop Thread-Index: AdJ7AjwWfpUhEI5pR2KZP1Baw5GM3QbVYYsA Date: Mon, 6 Mar 2017 09:05:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.36.157.200] x-ms-office365-filtering-correlation-id: 8ef5f367-d0a2-457c-24f4-08d4646fffdf x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:HE1PR0701MB2537; x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2537; 7:F5v1zhnhueVtPsqxrtv0uPycLK+po+2empSB1UgtZ1bGcLhIxNGYKPMSI+jlfx35uwROQhsae06Em61WPISLLq9tf4M4VOFzjFy0ru50bZSmrKh5k5tcFibmpidId6v6jeBa1hyuRmqiPEEiAE848TBHbAeRIMPDo2/Ze09+9Dw/q5biKOWTN4ehNkq1X8bQT5lFHV5rSaFaTo93owYwaj+esuOmkvdXk98+8QEE85wgdYzicI7vPu9TOF1A0ZWvqkPB4/rJFKO+MM0VjqWbaHbCdkIRS03LS5L88UAWxHwpZtckTKKWXeuWkdS8gQiujk04GPpQmMTn5oc5N2PoiQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123558025)(20161123560025)(6072148); SRVR:HE1PR0701MB2537; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2537; x-forefront-prvs: 0238AEEDB0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(790700001)(9686003)(2900100001)(81166006)(86362001)(102836003)(8676002)(77096006)(3480700004)(3660700001)(189998001)(236005)(7906003)(54896002)(6436002)(25786008)(6306002)(6506006)(2501003)(6116002)(50986999)(54356999)(76176999)(3846002)(606005)(19609705001)(99286003)(55016002)(5660300001)(2906002)(66066001)(3280700002)(8936002)(74316002)(92566002)(229853002)(7736002)(122556002)(2950100002)(7696004)(221733001)(450100001)(53936002)(38730400002)(7116003)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2537; H:HE1PR0701MB2539.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB2539B377F10CFFFE7832A5E7982C0HE1PR0701MB2539_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2017 09:05:55.9891 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2537 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0iTURjGOd9lfVqD45z5Mg1kRIKlKy0xkDAqCqTSMJIi2sgvteYm+5ao EHgl1Jy2pLyEmQ4tpctS02qulGqKZdLMUNastLwlWllWtmjbp+B/v/d5nnPe88BhSFEdLWGS VVpWo1IopQJPqiK+LTa4cENH/Ob6ASrivrFfEGGeuUNGEfsMht9EDDrqGZnAKpPTWI1sh9wz 6WO+kUh9vi3d0V1KZqFmWSHyYABvhaGXhXQh8mRE+DaCB08XKH6wILCOXBW4BgoXk7CQ94tw HRHhcgLseh8+1YPAUesgXYYAR0L/h1naxWIcB4/Hsp1XMYw39oPPtXt52R8GLW9X8RwKUxad mym8Hmb/tiJXXIjl0P3Jy4UiJ9ZVHXAlPLACrOO97kUIr4P57CY3k9gXhseuEXwZDAbTK5Jn H5gc/ecuhnARgrnqwaWQFNpzqpZC+8H8rGxJPwjGHLu7PGAdCTP2G0uGGhxTJTTP0TBZUELz oWoCbGVFFG/4Q8PQe8QbZTTocvTuFd5YAu8GChDP/jBh66D5d6uhdP47XYoCK1fUqFxhuViI vaCnYozi9U1Q8+ibgOeNUH99mlzmF09GiZV6DVrViHw4luNSEkPDQlhN8kmOU6tCVKz2HnJ+ nc6WxeB21DS9swthBknXCFPLTfEiWpHGZaR0IWBIqVjY2eKUhAmKjExWoz6hOatkuS7kx1BS X2H4zZEjIpyo0LJnWDaV1Sy7BOMhyUJhvUmL1kaD7ZbeYG5Ye6yk95SvyXJ8Viee2m5NKIrL FaYppQGyzD6uLqB1sNjkofxq39U8nOj4efrcj/OXasLnVFVvRBPi1ZH58q4YVOc3Gjj+MLrN 2HA4XXLBdqVk8LI8sHlI9Dq2Lzfvi8yyJyhfK77752KHPuuQzRwVOrpbSnFJii1BpIZT/Ae5 YwkJNgMAAA== Archived-At: Subject: Re: [core] OSCOAP interop X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 06 Mar 2017 09:06:22 -0000 --_000_HE1PR0701MB2539B377F10CFFFE7832A5E7982C0HE1PR0701MB2539_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi CoRE members, Big thanks to the implementers and all the participants in the remote inter= op for OSCOAP. I compiled a short report (thank you Christian for taking notes too!), whic= h you can find here: https://ericssonresearch.github.io/OSCOAP/interop.html (the test specifications are now moved to: https://ericssonresearch.github.= io/OSCOAP/test-spec.html ) Best regards, Francesca OSCOAP: https://github.com/core-wg/oscoap Interop test spec and report: https://ericssonresearch.github.io/OSCOAP/ From: core [mailto:core-bounces@ietf.org] On Behalf Of Francesca Palombini Sent: den 30 januari 2017 15:13 To: core@ietf.org; core-chairs@ietf.org Subject: [core] OSCOAP interop Hello CoRE members, The first remote interop for OSCOAP (https://github.com/core-wg/oscoap) wil= l take place Monday 27th February at 8:00 (CET). We are aiming for 3 hours, but we will be flexible based on participants av= ailability. A first draft for the tests specification is available here: https://ericss= onresearch.github.io/OSCOAP/ Don't hesitate to send comments, feedback, ideas. If you are interested in participating, as implementers or as observers, pl= ease get in contact with me, and I'll keep you updated. Thanks, Francesca --_000_HE1PR0701MB2539B377F10CFFFE7832A5E7982C0HE1PR0701MB2539_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi CoRE members,

 

Big thanks to the implementers and all the participa= nts in the remote interop for OSCOAP.
I compiled a short report (thank you Christian for taking notes too!), whic= h you can find here:

 

https://ericssonresearch.github.io/OSCOAP/interop.html

 

(the test specifications are now moved to: https://ericssonresearch.github.io/OSCOAP/test-spec.html )

 

Best regards,
Francesca

 

OSCOAP: https://github.com/core-wg/oscoap

Interop test spec and report: https://ericssonresearch.github.io/OSCOAP/

 

 

From: core [mailto:core-bounces@ietf.org] = On Behalf Of Francesca Palombini
Sent: den 30 januari 2017 15:13
To: core@ietf.org; core-chairs@ietf.org
Subject: [core] OSCOAP interop

 

Hello CoRE members,

 

The first remote interop for OSCOAP (https://github.com/core-wg/oscoap) will take place Monday 27th February at 8:00 (CET).

We are aiming for 3 hours, but we will be flexible b= ased on participants availability.

 

A first draft for the tests specification is availab= le here: https://ericssonrese= arch.github.io/OSCOAP/

Don’t hesitate to send comments, feedback, ide= as.

 

If you are interested in participating, as implement= ers or as observers, please get in contact with me, and I’ll keep you= updated.

 

Thanks,

Francesca

--_000_HE1PR0701MB2539B377F10CFFFE7832A5E7982C0HE1PR0701MB2539_-- From nobody Mon Mar 6 01:08:07 2017 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 A718F126BF6 for ; Mon, 6 Mar 2017 01:08:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=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 EBDiM1r4Xxf0 for ; Mon, 6 Mar 2017 01:08:06 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0345D12947D for ; Mon, 6 Mar 2017 01:01:14 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 84C02466C2; Mon, 6 Mar 2017 10:01:12 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id E82EB36; Mon, 6 Mar 2017 10:01:10 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 93199388; Mon, 6 Mar 2017 10:01:10 +0100 (CET) Received: (nullmailer pid 16292 invoked by uid 1000); Mon, 06 Mar 2017 09:01:09 -0000 Date: Mon, 6 Mar 2017 10:01:08 +0100 From: 'Christian =?iso-8859-1?Q?Ams=FCss'?= To: Jim Schaad Message-ID: <20170306090108.pvlliuyuzq35sqd6@hephaistos.amsuess.com> References: <20170303173229.uj7av3xia4prxku3@hephaistos.amsuess.com> <069c01d2963d$16fda9e0$44f8fda0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="aoijq7shodvz3ltl" Content-Disposition: inline In-Reply-To: <069c01d2963d$16fda9e0$44f8fda0$@augustcellars.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Cc: core@ietf.org Subject: Re: [core] pre-draft: Request-Tag X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 06 Mar 2017 09:08:07 -0000 --aoijq7shodvz3ltl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Jim, > As I read the problem that you have outlined below, it does not appear to > match the same problem that I think needs to be solved. =66rom the points you've brought up it appears to me that I failed to keep the two uses I see for the described option: > 1. I want a value that can be modified in transit. This is what the Request-Discriminator option would be used for in outer messages. It's unencrypted, unauthenticated, and its scope is between endpoints on CoAP level, so typically between a proxy and a server. That option must not be reflected in the AAD. Now for a distinct use case: > 2. It is my belief that the cue to use the new option is not correct at > all. The new option is not needed for any OSCOAP internal blocking. It = is > needed solely to deal with outer blocking. This means that it is more > likely to be needed if an inner Block1 is absent than if it is present. = The > assumption if it is present is that it SHOULD be sufficient to deal with = the > problem. =20 The OSCOAP application of this option is with what I'd hope to address the issues of inner-blockwise transfers falling victim to out-of-order attacks, or what you described in earlier mails as protecting the integrity of the complete message (or as I see it the body). The draft-ietf-core-object-security-01 draft had the tag-previous-block fields in the external AAD. That has been removed in the latest editors copy (git b14b3c7d9bd), so we are again missing protection against block 2 of a request being blackholed by a MITM (with the whole block transfer then failing) and replayed as block 2 of a different request. This is where the Request-Discriminator option comes into play as an option in the inner message (together with inner block options). > Often times it is easier to see ASCII art in drafts since they are a > fixed width font. Good point, didn't think of non-fixedwidth mail clients. Thanks Christian --=20 You don't use science to show that you're right, you use science to become = right. -- Randall Munroe --aoijq7shodvz3ltl Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAli9JVEACgkQOY0REtOk veEQdw/+MIsnVw1uFt6SJgBJlMT2m4OaMG0HdCyY/gbkSela+U5m/BFpEVocGceS rMbizAeCY5CXB6ZtI5tGQhaLXGHLWtwtWRJF0TVPkW2G8w5/5SZ4koM0Wbk0G7TZ gTUNxIFR3xxvgKN/rTQ0CU5Ab0IZZHE9vrA5aAP8kQ5WnBAjzeLxwzA8eCICs2Kk IaIIa3rS4sOcpFtGFME0hO6MDsKU5xIPSJrfxfvmCidHvjL5Z0LBZv64kMBSRgoG gtFPbkPrvAgUI6BfO5WToim6DBfSTWiOG7DbTxbmilLXaHGhrfjandQ0Uzr+VpPa Kjukvf4l/HBj5HxjhU1V9VmbuJTzhq6hTA9nffRU+sbp3ZPfiXds+nXkzjW1gzBk GpHHsemXSLHJPymdfuR3xnhB01NhKK3D0e1UlCXoX5TKGsZvfOpMgvASt82QBTdX f10rpatkJYAV1TMWYQMFyI3i3Tuh4VWmo3wH3ZdmvRbQm0VM+8df43JlzazDb2ZX C3hgYkMlQwTTKm7XMtKuzdTiGdEdL+Xg+6qozLRvOwEWD/Ips0oaowESNm1WC30h APxVB/Nv3lNieXCbxjaTOEeDRipeWNfrsoloXsEN/ReA/hFd8nnICIQvLDFf4OtT yklO1Gldm4rpGk3ec4K+lfRl9tmrgx6VlbOfmpMjK0mY/tQ9NnQ= =2suS -----END PGP SIGNATURE----- --aoijq7shodvz3ltl-- From nobody Mon Mar 6 04:01:36 2017 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 98D3D12965F for ; Mon, 6 Mar 2017 04:01:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tb7GE_hVwGi7 for ; Mon, 6 Mar 2017 04:01:34 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D01E412965A for ; Mon, 6 Mar 2017 04:01:33 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 1D2B2466CC; Mon, 6 Mar 2017 13:01:32 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id BC02961; Mon, 6 Mar 2017 13:01:30 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 615F9388; Mon, 6 Mar 2017 13:01:30 +0100 (CET) Received: (nullmailer pid 18853 invoked by uid 1000); Mon, 06 Mar 2017 12:01:29 -0000 Date: Mon, 6 Mar 2017 13:01:29 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: =?iso-8859-1?Q?G=F6ran?= Selander Message-ID: <20170306120129.o2doq4qtagoh7o7p@hephaistos.amsuess.com> References: <20170303173229.uj7av3xia4prxku3@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="blfhqkuej2eg5ju4" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Cc: "core@ietf.org" Subject: Re: [core] pre-draft: Request-Tag X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 06 Mar 2017 12:01:35 -0000 --blfhqkuej2eg5ju4 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello G=C3=B6ran, On Sat, Mar 04, 2017 at 11:45:21PM +0000, G=C3=B6ran Selander wrote: > If I understand right, you propose an augmentation to the endpoint > identifier. I was thinking of the solution as a "body-identifier=E2=80= =9D (using > RFC7959=E2=80=99s distinction between "body" and =E2=80=9Cpayload=E2=80= =9D), not limited to server > response as ETag but also applicable to client request (and proxy > request/response). >=20 > What would be the cons of instead identifying the body? I'm aiming for the endpoint identifier because * it works better with implementations (libraries) where the application (resource handler) can opt in to do block handling itself (which is especially relevant in all scenarios where the application can't give its underlying library a memmapped view of the body. In those cases, if we did touched the blockwise transfer, the resource implementation would need to become aware that it needs to do additional work for the underlying OSCOAP layer, while with this, the OSCOAP layer would merely need to detect that there is a Block1 option present, and add an appropriate Request-Tag. * I think it can be expressed more compactly this way. The existing (and probably necessary) complexity of block handling is not involved. * It may (or, as always with this phrase, may not) help differentiate between requests that should be linked together (like the blockwise requests do) in other CoAP extensions. I did not find any when quickly thinking through the current specs, because Observe responses can all be linked to their single request. But basically, yes, I could reshape the draft in a way that it becomes a pure Block1-Tag. It would achieve the same thing and could (just like the Request-Discriminator) draft be applicable both to CoAP messages (and solve the outer "all requests hit /" problem, as well as help proxies) and to OSCOAP messages (where it would solve the "promote valjean" replay-of-blackholed-request problem). If there develops an informed mood of "it's better as an additional block option", I'll happily write up such a version. Best regards Christian --=20 You don't use science to show that you're right, you use science to become right. -- Randall Munroe --blfhqkuej2eg5ju4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAli9T5YACgkQOY0REtOk veGxixAAwV7AWdmQAJ8ljyxJZicnO2fIAZ4eaKP6mTGezC7xDe5DYQxMzcfCPYNn 77gteXc970LIzBJBpbKvxzF/WIx8/+Ztc1Fg4w2XLYA059WHRNH6sujxbWiWQH9k paZoviqS5UJOlbgPB03rjYjX0GzaSOtospfAeF3r82VNvpRJ9MH0pB6q7qvZYSvD SBxEbOSOT1/y4hHsHXLqqcMpnDnMlaxvQIzobgT5YbcFzULg79P3i+TUbExy0LJB xfqAbErwDhqqL1xygWezaBN+7jx/PFklYViaMXSXamEZtF1J68yb3Q0U/SgTCB2b 0PC6bvwk0iDJejAgMlCDsrU2+FlBoAh498k1kiI/2TgGfgClPwaUltTWbfbCn7ZZ MoQKk53EvMsTOkH5JJ+jeu+rUQYR88oUSsQZx3w/+Pql4Fqc2BDooBxIZWB575k1 mDDzH/jcwBbQU6cW6KExor3ZUGHuNCU6IqSyLZ3nm8Kp65ic4Z6ZkHy97GzqiU5p vBhNYQa5WfYUICbiSlNyCtjzjZbqaxHdGopPACKy61n773octOltaotobFwejKQ9 2gNpRYjLJkwpZrqt3uVhnWYYnqdR6Lxzxbw1PhidnVaq+UXuw1gdofiJOD0uwyge 1MEu1EkcorPQxciVWiCKNGPAp6Wvv3BTC6MgZPEKPvaQz5jq/r0= =ahUX -----END PGP SIGNATURE----- --blfhqkuej2eg5ju4-- From nobody Mon Mar 6 07:06:30 2017 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 28B79128824 for ; Mon, 6 Mar 2017 07:06:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yt3qrHJgieTe for ; Mon, 6 Mar 2017 07:06:26 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55F141297EF for ; Mon, 6 Mar 2017 07:06:26 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 942E0466CC for ; Mon, 6 Mar 2017 16:06:24 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 9BAB936 for ; Mon, 6 Mar 2017 16:06:23 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 4DFB8388 for ; Mon, 6 Mar 2017 16:06:23 +0100 (CET) Received: (nullmailer pid 6743 invoked by uid 1000); Mon, 06 Mar 2017 15:06:22 -0000 Date: Mon, 6 Mar 2017 16:06:22 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: "core@ietf.org" Message-ID: <20170306150622.mxhuggsfaojso4xv@hephaistos.amsuess.com> References: <20170303173229.uj7av3xia4prxku3@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dpvirt3yqlyzn4du" Content-Disposition: inline In-Reply-To: <20170303173229.uj7av3xia4prxku3@hephaistos.amsuess.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [core] pre-draft: Request-Tag X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 06 Mar 2017 15:06:29 -0000 --dpvirt3yqlyzn4du Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello core list, and especially hello people versed in CoAP over DTLS, based on on-list and personal / relayed feedback, I'd like to add the following clarification, and a question: * Clarify expected uses: This draft will predominantly be useful in OSCOAP's outer messages, where all requests are on first sight targeted at the `/` resource, or in OSCOAP's inner messages. Without OSCOAP, this is probably a corner case (for who else has several PUT/POST requests transmitted over a proxy delivered to the same resource simultaneously, and expects a non-4.08 outcome?), that by conforming proxies is solved by queueing up requests for sequential processing. Nevertheless it is a concern to be discussed with the CoAP community as a whole because this corner case gets triggered by OSCOAP in proxies that "we" will use even though they do not implement object security and can keep proxies blocked by a single client. * Alternative approaches still under consideration: - Introducing a tag that is common to all parts of a single body would be a viable alternative, and largely equivalent to the proposal, just different to implement in text and code. - It might be worth considering to plainly demand of non-initial blocks that if they are to belong to a first block, they need to have larger sequence numbers if the security layer used provides any. That'd be an update (maybe even Erratum) for RFC7959, and would solve the OSCOAP inner-blockwise issues, and leave the proxy+block1 issue to another (maybe even slimmer) solution. * CoAP over DTLS question: How does CoAP over DTLS deal with delayed PUTs? As I see it (but not having implemented CoAP over DTLS myself yet), the same attack as described on OSCOAP can be carried out on DTLS too, as long as it happens inside the replay window. Worse yet, as DTLS sequence numbers vary between retransmits of the same message ID (and thus block request), the application might not even notice that a package was "blackholed". (To spare you the lookup, the attack sequence is: Client POSTs "incarcerate" (block 0, more to come). Server returns 2.31 Continue. Client POSTs "valjean" (block 1, end of request), but MITM blackholes the request (and subsequent retransmits) for further use. Later, Client POSTs "promote" (block 0, more to come). Server returns 2.31 Continue. MITM injects the previously stored "valjean" package. Server duefully promotes Valjean. ) Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --dpvirt3yqlyzn4du Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAli9euoACgkQOY0REtOk veFcXg/+OtHIZ2PuPycglr0L96kouv2EGWop2XDcXGFgARnZk3FOdPjCmjePHlE7 EPd30y5NtqDcmKiFYWIEcBrl0EoRl1NwtYwtZbfBCGOZmERSI7wprQIAylxuAMQ7 wJFkvvbY53Hcf/mJ/qc8RgLDMbAvJjRPHwWmWkPGSxWe0tNMxPe6GhG8JRVgqL5G HLExkSStcfeI2kmr+Yb7K+0mR8oOm3Gte//AV/8yFkpQhC9LtoDi3DCz0xvLMnMA AgI3h4ByZNaWJ7kxLf8FTLRF2lrVNj6dyupvsA43bnHcrWZb/3CijFSl0mr0e3jt P+rfFgdnOBrGa0cWTxgtL/MOmgc6ycDOpW4q8k5y2o6Ya4Qd4py1WDqdlPRf66ra XPb5ekDh63IukZXSbcvBoM6u8X27JE3E8qLjgSncL5xeQLvwzFJlrK58RIkW7Uro 51+PE6TyokyEuxM85ENJNrvtX1YzCWA0pw+CnTMoHA7k4taYkx6iSR5/ALPX4f8u vrfZwjYqUlQaikzy76j+h/5Q1H1c/ZAFGQEZfCOwg3j/aZ6X0OIAqVDbeGVJkqmZ 2ZgmGp3hbuXJ6FuUVzNiydqzXHzwLwLV21vN4LtD+j7T8Bb+ei2W9eMFljH6Lwwe di/vG8Wpazt0TBptJlP6a8+TFselB3BJrdXOvRqP2qWNadED6lQ= =jzue -----END PGP SIGNATURE----- --dpvirt3yqlyzn4du-- From nobody Mon Mar 6 08:52:06 2017 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 85680129888; Mon, 6 Mar 2017 08:52:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148881912154.15065.4795761440616595089.idtracker@ietfa.amsl.com> Date: Mon, 06 Mar 2017 08:52:01 -0800 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-coap-tcp-tls-07.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 16:52:01 -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 of the IETF. Title : CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets Authors : Carsten Bormann Simon Lemay Hannes Tschofenig Klaus Hartke Bilhanan Silverajan Brian Raymor Filename : draft-ietf-core-coap-tcp-tls-07.txt Pages : 48 Date : 2017-03-06 Abstract: The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of the CoAP over UDP protocol includes support for reliable delivery, simple congestion control, and flow control. Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or TLS. This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. It also formally updates [RFC7641] for use with these transports. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-coap-tcp-tls-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 7 09:45:45 2017 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 D20D6129527 for ; Tue, 7 Mar 2017 09:45:42 -0800 (PST) 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 QOLZ_QOCzbsp for ; Tue, 7 Mar 2017 09:45:37 -0800 (PST) Received: from buffalo.u-blox.com (buffalo.u-blox.com [195.34.89.137]) by ietfa.amsl.com (Postfix) with SMTP id 839C01295E3 for ; Tue, 7 Mar 2017 09:45:35 -0800 (PST) Received: from mail_filter (localhost [127.0.0.1]) by buffalo.u-blox.com (PF_LO_10026) with ESMTP id 5E81615F69E for ; Tue, 7 Mar 2017 18:45:34 +0100 (CET) Received: from ASSP.nospam (localhost [127.0.0.1]) by buffalo.u-blox.com (Postfix) with ESMTP id 2CE6C15F633; Tue, 7 Mar 2017 18:45:34 +0100 (CET) Received: from unknown ([127.0.0.1] helo=anyhost.local) by ASSP.nospam with SMTP (2.4.7); 7 Mar 2017 18:45:34 +0100 From: =?windows-1252?Q?Mojan_Mohajer?= To: =?windows-1252?Q?Friedhelm_Rodermund?= , =?windows-1252?Q?Christian_Groves?= Date: Tue, 7 Mar 2017 18:45:34 +0100 Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable In-Reply-To: References: <148765208755.26069.6296092128269483309.idtracker@ietfa.amsl.com> X-Priority: 3 (Normal) X-Mailer: Zarafa 7.1.14-51822 Thread-Index: AdKXap4e7/pqPURbRNGo+KJjIkdyUg== Message-Id: X-Assp-Version: 2.4.7(16004) on ASSP.nospam X-Assp-ID: ASSP.nospam 08734-16647 X-Assp-Session: 6CC42C18 (mail 1) X-Assp-Original-Subject: RE: [core] New Version Notification for draft-groves-core-bas-00.txt X-Virus-Scanned: clamav-milter 0.99.2 at buffalo X-Virus-Status: Clean Archived-At: Cc: =?windows-1252?Q?core?= Subject: Re: [core] New Version Notification for draft-groves-core-bas-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 07 Mar 2017 17:45:43 -0000 Hello Christian, et al The "bas" attribute looks extremely useful and certainly addresses a number important use cases. It can also perhaps be extended to cover a more generic use case where each resource within the reported collection can have its own separate set of observation parameters. For example, a typical scenario could be to monitor a temperature sensor, device battery level that the sensor is physically attached to and measured radio signal strength when device accesses cellular network. Each of these monitored resources can/should have independent observation parameters such as:=20 * Measured temperature value is reported when it exceeds a set threshold, or at least once a day (gth=3D21.2 celsius; pmax=3D86400) * Battery level to be reported based on st, lth, pmin and pmax observation parameters such as notification is sent when it drops below a certain % or there is a marked step change which could indicate unusual/unauthorised activity. In the absence of the first two conditions it should be reported at least once a week or at most once a day=3F * Measured radio signal strength to be included in every notification message My reading of =93bas=94 attribute is that it can only be applied to one resource in the collection and cannot be used to specify different observation parameters on each resource within the collection as highlighted in the above use case. Best Regards, Mojan -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Friedhelm Rodermund Sent: 01 March 2017 16:42 To: Christian Groves Cc: core Subject: Re: [core] New Version Notification for draft-groves-core-bas-00.txt Thanks Christian, I agree it would be very valuable to support this use case. Regards, Friedhelm > On 24 Feb 2017, at 01:42, Christian Groves wrote: >=20 > Hello all, >=20 > FYI I've submitted a draft addressing the use case discussed on the list allowing the value of one resource to trigger the notification of other resources. >=20 > It proposes to use a collection that would allow binding/observe attributes on a sub-resource (item). Once the criteria is met then the value of the collection is returned. The batch and/or linked batch interfaces are used to control the resources that are returned. >=20 > There's also a discussion of a more complex use case utilising the FETCH method. >=20 > Like the other attributes the goal would be to have this as part of draft-ietf-core-dynlink. >=20 > Comments=3F >=20 > Regards, Christian >=20 >=20 >=20 > -------- Forwarded Message -------- > Subject: =09New Version Notification for draft-groves-core-bas-00.txt > Date: =09Mon, 20 Feb 2017 20:41:27 -0800 > From: =09internet-drafts@ietf.org > To: =09Christian Groves , Christian Groves , Weiwei Yang >=20 >=20 >=20 > A new version of I-D, draft-groves-core-bas-00.txt has been=20 > successfully submitted by Christian Groves and posted to the IETF=20 > repository. >=20 > Name:=09=09draft-groves-core-bas > Revision:=0900 > Title:=09=09Binding Attribute Scope > Document date:=092017-02-21 > Group:=09=09Individual Submission > Pages:=09=097 > URL: https://www.ietf.org/internet-drafts/draft-groves-core-bas-00.txt > Status: https://datatracker.ietf.org/doc/draft-groves-core-bas/ > Htmlized: https://tools.ietf.org/html/draft-groves-core-bas-00 >=20 >=20 > Abstract: > This document specifies an additional CoAP binding attribute that > allows binding attributes to be scoped to an item (sub-resource) in a > collection resource. This allows synchronisation of multiple > resources in a collection based on the value of one resource. >=20 > =20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 > . >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Tue Mar 7 20:56:32 2017 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 AB692127ABE for ; Tue, 7 Mar 2017 20:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] 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 B1Lo6SNvkuNo for ; Tue, 7 Mar 2017 20:56:30 -0800 (PST) Received: from msh04.myshophosting.com (msh04.myshophosting.com [101.0.86.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 0A1711279EB for ; Tue, 7 Mar 2017 20:56:30 -0800 (PST) Received: from ppp118-209-171-106.lns20.mel8.internode.on.net ([118.209.171.106]:58124 helo=[192.168.1.22]) by msh04.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1clTdn-004Iif-9s; Wed, 08 Mar 2017 15:55:59 +1100 To: Mojan Mohajer , Friedhelm Rodermund References: <148765208755.26069.6296092128269483309.idtracker@ietfa.amsl.com> From: Christian Groves Message-ID: <09da8459-90d1-84a2-8aae-8181ea3d4036@gmail.com> Date: Wed, 8 Mar 2017 15:55:56 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh04.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gmail.com X-Get-Message-Sender-Via: msh04.myshophosting.com: authenticated_id: christian@kunstmade.com.au X-Authenticated-Sender: msh04.myshophosting.com: christian@kunstmade.com.au X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: core Subject: Re: [core] New Version Notification for draft-groves-core-bas-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 08 Mar 2017 04:56:31 -0000 Hello Mojan, Thanks for your comments and additional scenarios. It would be possible to support your scenarios below utilising bas from the current draft by doing multiple observes on the collection. E.g. Given the following link structure: /collection /collection/temperature /collection/batterylevel /collection/signalstrength Two observations would be enough to satisfy the scenario below. 1. GET /collection?bas=temp, gth=21.2 cel, pmax=86400 (Token: 0x01, Observe: 0) 2. GET /collection?bas=battery level, st, lth, pmin & pmax (Token: 0x02, Observe: 0) The signal strength, battery level and temperature would be returned at each notification because the entire collection is returned upon meeting the observation parameters. Does this suffice? Having more complicated logic where there's an interaction between the resources (e.g. a notification due to battery level would satisfy the temperature "once a day" criteria) is envisaged to be handled by the FETCH method described in the draft. Regards, Christian On 8/03/2017 4:45 AM, Mojan Mohajer wrote: > Hello Christian, et al > The "bas" attribute looks extremely useful and certainly addresses a number important use cases. It can also perhaps be extended to cover a more generic use case where each resource within the reported collection can have its own separate set of observation parameters. For example, a typical scenario could be to monitor a temperature sensor, device battery level that the sensor is physically attached to and measured radio signal strength when device accesses cellular network. Each of these monitored resources can/should have independent observation parameters such as: > * Measured temperature value is reported when it exceeds a set threshold, or at least once a day (gth=21.2 celsius; pmax=86400) > * Battery level to be reported based on st, lth, pmin and pmax observation parameters such as notification is sent when it drops below a certain % or there is a marked step change which could indicate unusual/unauthorised activity. In the absence of the first two conditions it should be reported at least once a week or at most once a day? > * Measured radio signal strength to be included in every notification message > My reading of bas attribute is that it can only be applied to one resource in the collection and cannot be used to specify different observation parameters on each resource within the collection as highlighted in the above use case. > Best Regards, > Mojan > > > > > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Friedhelm Rodermund > Sent: 01 March 2017 16:42 > To: Christian Groves > Cc: core > Subject: Re: [core] New Version Notification for draft-groves-core-bas-00.txt > > Thanks Christian, > > I agree it would be very valuable to support this use case. > > Regards, > Friedhelm > > >> On 24 Feb 2017, at 01:42, Christian Groves wrote: >> >> Hello all, >> >> FYI I've submitted a draft addressing the use case discussed on the list allowing the value of one resource to trigger the notification of other resources. >> >> It proposes to use a collection that would allow binding/observe attributes on a sub-resource (item). Once the criteria is met then the value of the collection is returned. The batch and/or linked batch interfaces are used to control the resources that are returned. >> >> There's also a discussion of a more complex use case utilising the FETCH method. >> >> Like the other attributes the goal would be to have this as part of draft-ietf-core-dynlink. >> >> Comments? >> >> Regards, Christian >> >> >> >> -------- Forwarded Message -------- >> Subject: New Version Notification for draft-groves-core-bas-00.txt >> Date: Mon, 20 Feb 2017 20:41:27 -0800 >> From: internet-drafts@ietf.org >> To: Christian Groves , Christian Groves , Weiwei Yang >> >> >> >> A new version of I-D, draft-groves-core-bas-00.txt has been >> successfully submitted by Christian Groves and posted to the IETF >> repository. >> >> Name: draft-groves-core-bas >> Revision: 00 >> Title: Binding Attribute Scope >> Document date: 2017-02-21 >> Group: Individual Submission >> Pages: 7 >> URL: https://www.ietf.org/internet-drafts/draft-groves-core-bas-00.txt >> Status: https://datatracker.ietf.org/doc/draft-groves-core-bas/ >> Htmlized: https://tools.ietf.org/html/draft-groves-core-bas-00 >> >> >> Abstract: >> This document specifies an additional CoAP binding attribute that >> allows binding attributes to be scoped to an item (sub-resource) in a >> collection resource. This allows synchronisation of multiple >> resources in a collection based on the value of one resource. >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> . >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > From nobody Wed Mar 8 02:13:31 2017 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 9957D129466 for ; Wed, 8 Mar 2017 02:13:30 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 V5XUPIXP5Gf1 for ; Wed, 8 Mar 2017 02:13:27 -0800 (PST) Received: from blade-a1-vm-relay.servers.aueb.gr (blade-a1-vm-relay.servers.aueb.gr [195.251.255.150]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF271293D8 for ; Wed, 8 Mar 2017 02:13:26 -0800 (PST) Received: from blade-a1-vm-smtp.servers.aueb.gr (blade-a1-vm-smtp.servers.aueb.gr [::ffff:195.251.255.107]) by blade-a1-vm-relay.servers.aueb.gr with ESMTP; Wed, 08 Mar 2017 12:13:22 +0200 id 00000000000011FA.0000000058BFD942.00004F76 Received: from [192.168.1.2] (77-69-87-215.dynamic.cyta.gr [::ffff:77.69.87.215]) (AUTH: LOGIN fotiou, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by blade-a1-vm-smtp.servers.aueb.gr with ESMTPSA; Wed, 08 Mar 2017 12:13:22 +0200 id 000000000000051F.0000000058BFD942.00001429 To: core@ietf.org References: <148765208755.26069.6296092128269483309.idtracker@ietfa.amsl.com> From: Nikos Fotiou Message-ID: <4f51d959-7e26-0c42-bc18-b0e60d1cb18a@aueb.gr> Date: Wed, 8 Mar 2017 12:13:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [core] New Version Notification for draft-groves-core-bas-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 08 Mar 2017 10:13:30 -0000 Hi all, I have a naive question. Why all these should be provided by CoAP and not by the application layer? IMHO this functionality overloads CoAP with semantics. Isn't there the danger to result with a bloated protocol? Best, Nikos On 7/3/2017 7:45 μμ, Mojan Mohajer wrote: > Hello Christian, et al > The "bas" attribute looks extremely useful and certainly addresses a number important use cases. It can also perhaps be extended to cover a more generic use case where each resource within the reported collection can have its own separate set of observation parameters. For example, a typical scenario could be to monitor a temperature sensor, device battery level that the sensor is physically attached to and measured radio signal strength when device accesses cellular network. Each of these monitored resources can/should have independent observation parameters such as: > * Measured temperature value is reported when it exceeds a set threshold, or at least once a day (gth=21.2 celsius; pmax=86400) > * Battery level to be reported based on st, lth, pmin and pmax observation parameters such as notification is sent when it drops below a certain % or there is a marked step change which could indicate unusual/unauthorised activity. In the absence of the first two conditions it should be reported at least once a week or at most once a day? > * Measured radio signal strength to be included in every notification message > My reading of “bas” attribute is that it can only be applied to one resource in the collection and cannot be used to specify different observation parameters on each resource within the collection as highlighted in the above use case. > Best Regards, > Mojan > > > > > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Friedhelm Rodermund > Sent: 01 March 2017 16:42 > To: Christian Groves > Cc: core > Subject: Re: [core] New Version Notification for draft-groves-core-bas-00.txt > > Thanks Christian, > > I agree it would be very valuable to support this use case. > > Regards, > Friedhelm > > >> On 24 Feb 2017, at 01:42, Christian Groves wrote: >> >> Hello all, >> >> FYI I've submitted a draft addressing the use case discussed on the list allowing the value of one resource to trigger the notification of other resources. >> >> It proposes to use a collection that would allow binding/observe attributes on a sub-resource (item). Once the criteria is met then the value of the collection is returned. The batch and/or linked batch interfaces are used to control the resources that are returned. >> >> There's also a discussion of a more complex use case utilising the FETCH method. >> >> Like the other attributes the goal would be to have this as part of draft-ietf-core-dynlink. >> >> Comments? >> >> Regards, Christian >> >> >> >> -------- Forwarded Message -------- >> Subject: New Version Notification for draft-groves-core-bas-00.txt >> Date: Mon, 20 Feb 2017 20:41:27 -0800 >> From: internet-drafts@ietf.org >> To: Christian Groves , Christian Groves , Weiwei Yang >> >> >> >> A new version of I-D, draft-groves-core-bas-00.txt has been >> successfully submitted by Christian Groves and posted to the IETF >> repository. >> >> Name: draft-groves-core-bas >> Revision: 00 >> Title: Binding Attribute Scope >> Document date: 2017-02-21 >> Group: Individual Submission >> Pages: 7 >> URL: https://www.ietf.org/internet-drafts/draft-groves-core-bas-00.txt >> Status: https://datatracker.ietf.org/doc/draft-groves-core-bas/ >> Htmlized: https://tools.ietf.org/html/draft-groves-core-bas-00 >> >> >> Abstract: >> This document specifies an additional CoAP binding attribute that >> allows binding attributes to be scoped to an item (sub-resource) in a >> collection resource. This allows synchronisation of multiple >> resources in a collection based on the value of one resource. >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> . >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From nobody Wed Mar 8 02:23:02 2017 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 DC4841270B4 for ; Wed, 8 Mar 2017 02:23:01 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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 9V5F31erFg59 for ; Wed, 8 Mar 2017 02:22:58 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 A880B127071 for ; Wed, 8 Mar 2017 02:22:57 -0800 (PST) Received: from [192.168.91.177] ([80.92.114.23]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LcmN9-1c1XH41EMZ-00kBEO; Wed, 08 Mar 2017 11:22:49 +0100 To: Nikos Fotiou , core@ietf.org References: <148765208755.26069.6296092128269483309.idtracker@ietfa.amsl.com> <4f51d959-7e26-0c42-bc18-b0e60d1cb18a@aueb.gr> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <73a6427f-3f0d-6de3-b021-c0b7a40421fc@gmx.net> Date: Wed, 8 Mar 2017 11:22:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <4f51d959-7e26-0c42-bc18-b0e60d1cb18a@aueb.gr> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fTlqlmdQHOF1d4VeQnnCCDFCikMUJ8JRr" X-Provags-ID: V03:K0:thH5FgDjSy+/QsMjV11YNjywpF/Te94SLrr66yEcQJ+v/f9JaK9 4bKtSfL3BKcxYe7Xvwc3XsDyfqONkLokIAKP9u2XMP2PVjQKQFAAGg2rin7/YmCAFOCgH+6 x5xO9Ft98aEg52FPcxzZ1hdap9+2nSjphwus7VCL9UKPuDXlA7egAv2Ve7DeybRELElgS+7 t/qNH+Eb5rbbEocQGw7rQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:D8X9TYBNkwc=:d+0KU+ymUFSTSaQdJ1n54b AdsE9KioMS3MxEmAE9y8UDXeMmiiOGT0qVhjtg5cazXIbyiYaNSUBnKAIl/P9FcMqSfmHnXf8 Kc3FuyNuA8HwvePOUafrVBZBM5PtBdyHScZQ8hcQq/uMGPX8adtaQZVqlvjgtNaOCJNyEogdX BAfmkdxTzkt/+z9fV3bkHUuCIKdxETq1bymkmjXwG/54qrSdealSUAVToSCKgRAq7NhCqD7Lw AL5aNTIXXvRpW+6/Hi0Yt1YMmJ4DeyKlTm1qVBCQ2KvX3IDnynlsiXYhRiybxWQoZRYaL64f+ vjecrZmC0jwfM80wLoEtvOVWNKra2YkxBL0+EYOj8CzeVMIAygEdgjRei4YyYHEaMs+HES9p6 Q7tfEHLZxIpyJsW1pV9h8BW3/UG6dYDs020c88jvwavmh7LsWP/NyrTbZexPHQsZekxV8Kveb 7TMv/L6HkJe30iRbCnjjcUV6DZCTuFaqXBp8o0gHwPlwxglkkSPIn6UQ9fUMb+4Jyuk0XPJBj 3JhmM+AUoncX8eQQkmSvSaI5PZLRxt3AF/RXAiTzCvakoar6xz4HMj+ijh+DR/pEwaQrya7HT nuqP/ado9i+0lWc+9NmKr8Bfus7BRnrC25FwtL/uFK0XTGPJUu6m3YPdpiS2OvbFFWCJ17d/W S5QvTfjYvgQzsoit0YIJo3PeJlJFH83pxgYV9h8MeJXovz0dq726NklkxFgqipN/7h4qHPIQJ eygkq1keQIIYo32skvvEI5JkYKxCbUYURMjSap9wsQRJO4kBtz4WQQGJEcE= Archived-At: Subject: Re: [core] New Version Notification for draft-groves-core-bas-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 08 Mar 2017 10:23:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fTlqlmdQHOF1d4VeQnnCCDFCikMUJ8JRr Content-Type: multipart/mixed; boundary="Ksn1JFR2EI38DFdHDtfdXXHPX6RdL3Jmt"; protected-headers="v1" From: Hannes Tschofenig To: Nikos Fotiou , core@ietf.org Message-ID: <73a6427f-3f0d-6de3-b021-c0b7a40421fc@gmx.net> Subject: Re: [core] New Version Notification for draft-groves-core-bas-00.txt References: <148765208755.26069.6296092128269483309.idtracker@ietfa.amsl.com> <4f51d959-7e26-0c42-bc18-b0e60d1cb18a@aueb.gr> In-Reply-To: <4f51d959-7e26-0c42-bc18-b0e60d1cb18a@aueb.gr> --Ksn1JFR2EI38DFdHDtfdXXHPX6RdL3Jmt Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Nikos, Mojan provided examples below to illustrate how the functionality defined in the draft could be used. Furthermore, draft-groves-core-bas-00 is an extension to the Dynamic Resource Linking draft, which itself is an extension to the CoAP Observe mechanism. CoAP is already published as an RFC and cannot be "bloated" as such. Ciao Hannes On 03/08/2017 11:13 AM, Nikos Fotiou wrote: > Hi all, > I have a naive question. Why all these should be provided by CoAP and > not by the application layer? IMHO this functionality overloads CoAP > with semantics. Isn't there the danger to result with a bloated protoco= l? >=20 > Best, > Nikos >=20 > On 7/3/2017 7:45 =CE=BC=CE=BC, Mojan Mohajer wrote: >> Hello Christian, et al >> The "bas" attribute looks extremely useful and certainly addresses a >> number important use cases. It can also perhaps be extended to cover a= >> more generic use case where each resource within the reported >> collection can have its own separate set of observation parameters. >> For example, a typical scenario could be to monitor a temperature >> sensor, device battery level that the sensor is physically attached to= >> and measured radio signal strength when device accesses cellular >> network. Each of these monitored resources can/should have independent= >> observation parameters such as: >> * Measured temperature value is reported when it exceeds a set >> threshold, or at least once a day (gth=3D21.2 celsius; pmax=3D86400) >> * Battery level to be reported based on st, lth, pmin and pmax >> observation parameters such as notification is sent when it drops >> below a certain % or there is a marked step change which could >> indicate unusual/unauthorised activity. In the absence of the first >> two conditions it should be reported at least once a week or at most >> once a day? >> * Measured radio signal strength to be included in every >> notification message >> My reading of =E2=80=9Cbas=E2=80=9D attribute is that it can only be a= pplied to one >> resource in the collection and cannot be used to specify different >> observation parameters on each resource within the collection as >> highlighted in the above use case. >> Best Regards, >> Mojan >> >> >> >> >> -----Original Message----- >> From: core [mailto:core-bounces@ietf.org] On Behalf Of Friedhelm >> Rodermund >> Sent: 01 March 2017 16:42 >> To: Christian Groves >> Cc: core >> Subject: Re: [core] New Version Notification for >> draft-groves-core-bas-00.txt >> >> Thanks Christian, >> >> I agree it would be very valuable to support this use case. >> >> Regards, >> Friedhelm >> >> >>> On 24 Feb 2017, at 01:42, Christian Groves >>> wrote: >>> >>> Hello all, >>> >>> FYI I've submitted a draft addressing the use case discussed on the >>> list allowing the value of one resource to trigger the notification >>> of other resources. >>> >>> It proposes to use a collection that would allow binding/observe >>> attributes on a sub-resource (item). Once the criteria is met then >>> the value of the collection is returned. The batch and/or linked >>> batch interfaces are used to control the resources that are returned.= >>> >>> There's also a discussion of a more complex use case utilising the >>> FETCH method. >>> >>> Like the other attributes the goal would be to have this as part of >>> draft-ietf-core-dynlink. >>> >>> Comments? >>> >>> Regards, Christian >>> >>> >>> >>> -------- Forwarded Message -------- >>> Subject: New Version Notification for draft-groves-core-bas-00.tx= t >>> Date: Mon, 20 Feb 2017 20:41:27 -0800 >>> From: internet-drafts@ietf.org >>> To: Christian Groves , >>> Christian Groves , Weiwei Yang >>> >>> >>> >>> >>> A new version of I-D, draft-groves-core-bas-00.txt has been >>> successfully submitted by Christian Groves and posted to the IETF >>> repository. >>> >>> Name: draft-groves-core-bas >>> Revision: 00 >>> Title: Binding Attribute Scope >>> Document date: 2017-02-21 >>> Group: Individual Submission >>> Pages: 7 >>> URL: =20 >>> https://www.ietf.org/internet-drafts/draft-groves-core-bas-00.txt >>> Status: https://datatracker.ietf.org/doc/draft-groves-core-ba= s/ >>> Htmlized: https://tools.ietf.org/html/draft-groves-core-bas-00 >>> >>> >>> Abstract: >>> This document specifies an additional CoAP binding attribute that >>> allows binding attributes to be scoped to an item (sub-resource) in= a >>> collection resource. This allows synchronisation of multiple >>> resources in a collection based on the value of one resource. >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission until the htmlized version and diff are available at >>> tools.ietf.org. >>> >>> The IETF Secretariat >>> >>> . >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --Ksn1JFR2EI38DFdHDtfdXXHPX6RdL3Jmt-- --fTlqlmdQHOF1d4VeQnnCCDFCikMUJ8JRr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJYv9t3AAoJEGhJURNOOiAtqAoH/jVXh899un5Layj6aJeQR9NZ 2f3ZKLKmWgBuo4Be210NmwzlZaQwix6PhRiGjTKbmo4edG5ulMwhtvw7Io/dOBuc yn9Kk6RLrm2jdKEPZmCF4nZVjaA8iQyXh2AkQfbvyL8pFGr6p8jsEsFi4tMsGEl8 wo40Ney68LJ/8eDGsQU5mrNnLCd/NlzbdyS1iQRL+ruRbkWWDRfdF82THrzIVkXL KKfwQzrY6+NcMfY6OiJO0iSiih+u1mDNIyLHbdfScOfUdQETkVTg6+SASVUNvVTU LFDr7VPBczK9zUCelsKhSU5ijExQETb9oDEc7huUqWD61v6hHFwK5p6LNl6h1tM= =V0BH -----END PGP SIGNATURE----- --fTlqlmdQHOF1d4VeQnnCCDFCikMUJ8JRr-- From nobody Wed Mar 8 02:45:08 2017 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 ABDE2129572 for ; Wed, 8 Mar 2017 02:45:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 v77mojd2fiKX for ; Wed, 8 Mar 2017 02:45:03 -0800 (PST) Received: from buffalo.u-blox.com (buffalo.u-blox.com [195.34.89.137]) by ietfa.amsl.com (Postfix) with SMTP id 7B05E12947B for ; Wed, 8 Mar 2017 02:45:02 -0800 (PST) Received: from mail_filter (localhost [127.0.0.1]) by buffalo.u-blox.com (PF_LO_10026) with ESMTP id A8C1E15F68B for ; Wed, 8 Mar 2017 11:45:00 +0100 (CET) Received: from ASSP.nospam (localhost [127.0.0.1]) by buffalo.u-blox.com (Postfix) with ESMTP id 756AD15F630; Wed, 8 Mar 2017 11:45:00 +0100 (CET) Received: from unknown ([127.0.0.1] helo=anyhost.local) by ASSP.nospam with SMTP (2.4.7); 8 Mar 2017 11:45:00 +0100 From: =?windows-1252?Q?Mojan_Mohajer?= To: =?windows-1252?Q?Christian_Groves?= , =?windows-1252?Q?Friedhelm_Rodermund?= Date: Wed, 8 Mar 2017 11:45:00 +0100 Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable In-Reply-To: <09da8459-90d1-84a2-8aae-8181ea3d4036@gmail.com> References: <148765208755.26069.6296092128269483309.idtracker@ietfa.amsl.com> X-Priority: 3 (Normal) X-Mailer: Zarafa 7.1.14-51822 Thread-Index: AdKX+Qg3nSVaQY9fSO+Z9QPiJktksQ== Message-Id: X-Assp-Version: 2.4.7(16004) on ASSP.nospam X-Assp-ID: ASSP.nospam 69900-27215 X-Assp-Session: 5DB88C38 (mail 1) X-Assp-Original-Subject: RE: [core] New Version Notification for draft-groves-core-bas-00.txt X-Virus-Scanned: clamav-milter 0.99.2 at buffalo X-Virus-Status: Clean Archived-At: Cc: =?windows-1252?Q?core?= Subject: Re: [core] New Version Notification for draft-groves-core-bas-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 08 Mar 2017 10:45:06 -0000 Hello Christian, Yes, I can see the current proposals actually caters for the example scenario. Thanks for pointing this out. I guess in this example after CoAP server receives the second observe request it can use either Token 0x01 or 0x02 when notifying the resources in the collection back to the client and client can match it to its observe requests as appropriate. Best Regards, Mojan -----Original Message----- From: Christian Groves [mailto:cngroves.std@gmail.com]=20 Sent: 08 March 2017 04:56 To: Mojan Mohajer; Friedhelm Rodermund Cc: core Subject: Re: [core] New Version Notification for draft-groves-core-bas-00.txt Hello Mojan, Thanks for your comments and additional scenarios. It would be possible to support your scenarios below utilising bas from the current draft by doing multiple observes on the collection. E.g. Given the following link structure: /collection /collection/temperature /collection/batterylevel /collection/signalstrength Two observations would be enough to satisfy the scenario below. 1. GET /collection=3Fbas=3Dtemp, gth=3D21.2 cel, pmax=3D86400 (Token: 0x01, Observe: 0) 2. GET /collection=3Fbas=3Dbattery level, st, lth, pmin & pmax (Token: 0x02, Observe: 0) The signal strength, battery level and temperature would be returned at each notification because the entire collection is returned upon meeting the observation parameters. Does this suffice=3F Having more complicated logic where there's an interaction between the resources (e.g. a notification due to battery level would satisfy the temperature "once a day" criteria) is envisaged to be handled by the FETCH method described in the draft. Regards, Christian On 8/03/2017 4:45 AM, Mojan Mohajer wrote: > Hello Christian, et al > The "bas" attribute looks extremely useful and certainly addresses a number important use cases. It can also perhaps be extended to cover a more generic use case where each resource within the reported collection can have its own separate set of observation parameters. For example, a typical scenario could be to monitor a temperature sensor, device battery level that the sensor is physically attached to and measured radio signal strength when device accesses cellular network. Each of these monitored resources can/should have independent observation parameters such as: > * Measured temperature value is reported when it exceeds a set threshold, or at least once a day (gth=3D21.2 celsius; pmax=3D86400) > * Battery level to be reported based on st, lth, pmin and pmax observation parameters such as notification is sent when it drops below a certain % or there is a marked step change which could indicate unusual/unauthorised activity. In the absence of the first two conditions it should be reported at least once a week or at most once a day=3F > * Measured radio signal strength to be included in every=20 > notification message My reading of =93bas=94 attribute is that it can only be applied to one resource in the collection and cannot be used to specify different observation parameters on each resource within the collection as highlighted in the above use case. > Best Regards, > Mojan > > > > > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Friedhelm=20 > Rodermund > Sent: 01 March 2017 16:42 > To: Christian Groves > Cc: core > Subject: Re: [core] New Version Notification for=20 > draft-groves-core-bas-00.txt > > Thanks Christian, > > I agree it would be very valuable to support this use case. > > Regards, > Friedhelm > > >> On 24 Feb 2017, at 01:42, Christian Groves wrote: >> >> Hello all, >> >> FYI I've submitted a draft addressing the use case discussed on the list allowing the value of one resource to trigger the notification of other resources. >> >> It proposes to use a collection that would allow binding/observe attributes on a sub-resource (item). Once the criteria is met then the value of the collection is returned. The batch and/or linked batch interfaces are used to control the resources that are returned. >> >> There's also a discussion of a more complex use case utilising the FETCH method. >> >> Like the other attributes the goal would be to have this as part of draft-ietf-core-dynlink. >> >> Comments=3F >> >> Regards, Christian >> >> >> >> -------- Forwarded Message -------- >> Subject: =09New Version Notification for draft-groves-core-bas-00.txt >> Date: =09Mon, 20 Feb 2017 20:41:27 -0800 >> From: =09internet-drafts@ietf.org >> To: =09Christian Groves , Christian Groves , Weiwei Yang >> >> >> >> A new version of I-D, draft-groves-core-bas-00.txt has been=20 >> successfully submitted by Christian Groves and posted to the IETF=20 >> repository. >> >> Name:=09=09draft-groves-core-bas >> Revision:=0900 >> Title:=09=09Binding Attribute Scope >> Document date:=092017-02-21 >> Group:=09=09Individual Submission >> Pages:=09=097 >> URL: https://www.ietf.org/internet-drafts/draft-groves-core-bas-00.txt >> Status: https://datatracker.ietf.org/doc/draft-groves-core-bas/ >> Htmlized: https://tools.ietf.org/html/draft-groves-core-bas-00 >> >> >> Abstract: >> This document specifies an additional CoAP binding attribute that >> allows binding attributes to be scoped to an item (sub-resource) in a >> collection resource. This allows synchronisation of multiple >> resources in a collection based on the value of one resource. >> >> =20 >> >> Please note that it may take a couple of minutes from the time of=20 >> submission until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> . >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > From nobody Wed Mar 8 02:51:37 2017 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 8EC08129555 for ; Wed, 8 Mar 2017 02:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 6FljuslXLJ5q for ; Wed, 8 Mar 2017 02:51:33 -0800 (PST) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (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 280B01270B4 for ; Wed, 8 Mar 2017 02:51:32 -0800 (PST) Received: by mail-oi0-x235.google.com with SMTP id m124so16728338oig.1 for ; Wed, 08 Mar 2017 02:51:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=ghTTYv9JJeKLe/995Ma3tNjSlX8WWfZx82iLgPOA/+U=; b=ApD8Mg+ASjpYkUrXvypbZDPbaIYCqO3Jc45MdA/tSEYbLzvkjVidMxPl/caorFGAU0 GSewiC/LHozivDgmNKMoYVdSAlZKrClXkMGpaEkng/KkaOCksXd/wpWU3G28o6k6tRPg OzMa4J/+OfN7UGKGdbRowu2IQZjClUQZU3+8wiUqkeFNZjmo67tY9etUMrO63rnEeywh 7/49f89qehMOxEXk+GgBMDeFLDMNueU99K2L3QjENgpc03MX/WEb9vqMx4o0Ez40kpq3 SVx+d401teaILgQod7YnkK/KAHxBjnN+FbmJfqNas+N0yejTD8deYLp3VGZYdMOpjf/t HbMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=ghTTYv9JJeKLe/995Ma3tNjSlX8WWfZx82iLgPOA/+U=; b=hY9YHgNChYnJ52NHu21ahnMVAsXYkaG7KOctBQJc6Ey9mCjPen6muFRrxStd7bmfXg mKDhCB/5q4NhNXt6NrcPUPxjxVIsL7bYTBgmoD0vQ9AZ81D4xGKhAEfVVMJXcqQ2jKun 5Okrp4jXDO5rRjM9ClLZMLRZzy9Zp0NJetquilym0qPz2+34oE/uXVBNrmNU+0HxNzw5 mDuHjV0SlWeXvi2MH4lMEgSkmAfjhZ9O8AAj7HfglsBd/SRmINxji8uH7Hi/IKjPJhRa LVb+Z206gAKok0Mm+CsuHS+KaR/DxBNDgdEDA3qyUA7UH5NQVwLRE3MG12gEO7AHdSqz /VoA== X-Gm-Message-State: AMke39nqRAvmuV24i9jsRSRtUn2vnmqUnZ6B0IB135+w+wIMUSXNPTrGgAsHYyrjAQuO4Q== X-Received: by 10.202.229.11 with SMTP id c11mr2842219oih.72.1488970292378; Wed, 08 Mar 2017 02:51:32 -0800 (PST) Received: from [172.20.21.5] (rrcs-97-79-186-2.sw.biz.rr.com. [97.79.186.2]) by smtp.gmail.com with ESMTPSA id u131sm1340958oig.24.2017.03.08.02.51.31 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 08 Mar 2017 02:51:31 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_FC093272-9BF7-4B27-8A92-F95D875526D9" From: Michael Koster X-Priority: 3 (Normal) In-Reply-To: Date: Wed, 8 Mar 2017 04:51:30 -0600 Message-Id: <682CCE2D-9E92-4856-8B7B-32043F449EEF@gmail.com> References: <148765208755.26069.6296092128269483309.idtracker@ietfa.amsl.com> To: Mojan Mohajer X-Mailer: Apple Mail (2.2104) Archived-At: Cc: core Subject: Re: [core] New Version Notification for draft-groves-core-bas-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 08 Mar 2017 10:51:35 -0000 --Apple-Mail=_FC093272-9BF7-4B27-8A92-F95D875526D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Clearly, each observe request and response stream needs to respect it's = own token sequence. > On Mar 8, 2017, at 4:45 AM, Mojan Mohajer = wrote: >=20 > after CoAP server receives the second observe request it can use = either Token 0x01 or 0x02 when notifying the resources in the collection = back to the client and client can match it to its observe requests as = appropriate --Apple-Mail=_FC093272-9BF7-4B27-8A92-F95D875526D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Clearly, each observe request and response stream needs to = respect it's own token sequence.

On = Mar 8, 2017, at 4:45 AM, Mojan Mohajer <mojan.mohajer@u-blox.com> wrote:

after CoAP server receives the second observe = request it can use either Token 0x01 or 0x02 when notifying the = resources in the collection back to the client and client can match it = to its observe requests as = appropriate

= --Apple-Mail=_FC093272-9BF7-4B27-8A92-F95D875526D9-- From nobody Wed Mar 8 08:10:36 2017 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 9E335127077 for ; Wed, 8 Mar 2017 08:10:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 gEa1Xj3h6yvZ for ; Wed, 8 Mar 2017 08:10:34 -0800 (PST) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 78145126DFB for ; Wed, 8 Mar 2017 08:10:34 -0800 (PST) Received: by mail-oi0-x22b.google.com with SMTP id 2so21095825oif.0 for ; Wed, 08 Mar 2017 08:10:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=upvdergOFZ2bn7t6rdAWJw1TnXqCGiFwNv48Ca4tQ50=; b=B5Sy9RkgSApsSa4psZRt3GbtOIA52hbUARlS5vpIN/KCvK2CXW/y1IV4tR3UoaJ6A2 XA94D68WFZYKRd6L1+UHilV71yq7Y8l1U5ZjrfVN6Q6XbuH1VsjA51nbSoAW9DUjnZAQ HyaKh3xnswRdvUKmvC+cg6dNCKbJmthO+2gasARBm6VJkIdJZKaksi3kc5gVgPyiEXde Le9lgaohrh0F6NSXKXuJLl97KC+tPXRsXyJfn4XXuLSxxnrWtdEngjToS2BchN1V9SOv MkjdhJ2cTeZ86eZIZyZaIAGiNShFOMqYXMhAA6Jh7oJgUPXGtorGi7S76UWf0AgILZPQ jdcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=upvdergOFZ2bn7t6rdAWJw1TnXqCGiFwNv48Ca4tQ50=; b=osZkgqBPxZP2HyzCt694pHhLkGhk75NTnV8JfxiXv4TACNOH+OtvDo/fW3w6nSU9j/ fHbo3lp8D1nJtP6OQ3zWH/ylVlWGB+XlYbw0xdIn7eZLkyLIFCev6lyHVJbMqVlHcj1o prrIHV6kBsbZyxNbT95hg1BDNihTmsAJ1POjU2005r82QpErPTQ54WbOa9bnY+SpBA7i kq2mri17F3YXc3NL9aGDg31DHp6Yqy+ICQlfcZpp/pPAOciHt1X+pw7FGCdPPqiuVreg 82QGftfvnb84NW64UTzhHAnxrC4hkGOVo2bRiI5nPrcwaviNbWmhH1YLMCp1Hhf0ecHl sqzA== X-Gm-Message-State: AMke39mLJ2R5cQrqROEsc1q2NO6FaVI2rf5IGLhpspqPgmrc7N1xHNrUVaqH0o9p9zVL6Q== X-Received: by 10.202.194.193 with SMTP id s184mr3510311oif.4.1488989433808; Wed, 08 Mar 2017 08:10:33 -0800 (PST) Received: from [172.20.21.5] (rrcs-97-79-186-2.sw.biz.rr.com. [97.79.186.2]) by smtp.gmail.com with ESMTPSA id j76sm1672712oih.13.2017.03.08.08.10.32 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 08 Mar 2017 08:10:33 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_2194E726-C3C2-4DF8-8F29-F3D65290E282" From: Michael Koster X-Priority: 3 (Normal) In-Reply-To: Date: Wed, 8 Mar 2017 10:10:31 -0600 Message-Id: References: <148765208755.26069.6296092128269483309.idtracker@ietfa.amsl.com> To: Christian Groves X-Mailer: Apple Mail (2.2104) Archived-At: Cc: core Subject: Re: [core] New Version Notification for draft-groves-core-bas-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 08 Mar 2017 16:10:35 -0000 --Apple-Mail=_2194E726-C3C2-4DF8-8F29-F3D65290E282 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 In section 2.1 The current text of [I-D.ietf-core-interfaces] indicates that observe may be supported on an item in a collection not on the collection itself. =20 I don't think we should say that observe isn't supported on collections.=20= Observe should be supported for any resource, and by definition "caches" = the entire method call (for example GET with all its options) for = subsequent responses. Observe doesn't say what triggers the subsequent responses, which = dynlink and bas do specify. Do I understand it correctly? Best regards, Michael= --Apple-Mail=_2194E726-C3C2-4DF8-8F29-F3D65290E282 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=windows-1252 In section 2.1
   The current text of [I-D.ietf-core-interfaces] indicates that observe
   may be supported on an item in a collection not on the collection
   itself.
I don't think we should say that observe isn't supported on collections. 

Observe should be supported for any resource, and by definition "caches" the entire method call (for example GET with all its options) for subsequent responses.

Observe doesn't say what triggers the subsequent responses, which dynlink and bas do specify.

Do I understand it correctly?

Best regards,

Michael
--Apple-Mail=_2194E726-C3C2-4DF8-8F29-F3D65290E282-- From nobody Thu Mar 9 02:14:08 2017 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 7E4E1129428 for ; Thu, 9 Mar 2017 02:14:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.332 X-Spam-Level: X-Spam-Status: No, score=-0.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, 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 poacUyh-CgpO for ; Thu, 9 Mar 2017 02:14:05 -0800 (PST) Received: from msh04.myshophosting.com (msh04.myshophosting.com [101.0.86.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 E451A12711D for ; Thu, 9 Mar 2017 02:14:04 -0800 (PST) Received: from ppp118-209-171-106.lns20.mel8.internode.on.net ([118.209.171.106]:52713 helo=[192.168.1.159]) by msh04.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1clv58-002KvJ-7t for core@ietf.org; Thu, 09 Mar 2017 21:14:02 +1100 To: core@ietf.org References: <148765208755.26069.6296092128269483309.idtracker@ietfa.amsl.com> <4f51d959-7e26-0c42-bc18-b0e60d1cb18a@aueb.gr> <73a6427f-3f0d-6de3-b021-c0b7a40421fc@gmx.net> From: Christian Groves Message-ID: <8c90c8b2-d4ea-c3b0-5498-36673e6ec088@gmail.com> Date: Thu, 9 Mar 2017 21:13:57 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <73a6427f-3f0d-6de3-b021-c0b7a40421fc@gmx.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh04.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gmail.com X-Get-Message-Sender-Via: msh04.myshophosting.com: authenticated_id: christian@kunstmade.com.au X-Authenticated-Sender: msh04.myshophosting.com: christian@kunstmade.com.au X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [core] New Version Notification for draft-groves-core-bas-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2017 10:14:06 -0000 Hello Nikos, I agree with Hannes' comments. Plus to me introducing multiple application specific ways to perform the same functionality is a form of bloat. Having this generic functionality prevents having to define multiple ways to do the same thing. Regards, Christian On 8/03/2017 9:22 PM, Hannes Tschofenig wrote: > Hi Nikos, > > Mojan provided examples below to illustrate how the functionality > defined in the draft could be used. > > Furthermore, draft-groves-core-bas-00 is an extension to the Dynamic > Resource Linking draft, which itself is an extension to the CoAP Observe > mechanism. CoAP is already published as an RFC and cannot be "bloated" > as such. > > Ciao > Hannes > > > On 03/08/2017 11:13 AM, Nikos Fotiou wrote: >> Hi all, >> I have a naive question. Why all these should be provided by CoAP and >> not by the application layer? IMHO this functionality overloads CoAP >> with semantics. Isn't there the danger to result with a bloated protocol? >> >> Best, >> Nikos >> >> On 7/3/2017 7:45 μμ, Mojan Mohajer wrote: >>> Hello Christian, et al >>> The "bas" attribute looks extremely useful and certainly addresses a >>> number important use cases. It can also perhaps be extended to cover a >>> more generic use case where each resource within the reported >>> collection can have its own separate set of observation parameters. >>> For example, a typical scenario could be to monitor a temperature >>> sensor, device battery level that the sensor is physically attached to >>> and measured radio signal strength when device accesses cellular >>> network. Each of these monitored resources can/should have independent >>> observation parameters such as: >>> * Measured temperature value is reported when it exceeds a set >>> threshold, or at least once a day (gth=21.2 celsius; pmax=86400) >>> * Battery level to be reported based on st, lth, pmin and pmax >>> observation parameters such as notification is sent when it drops >>> below a certain % or there is a marked step change which could >>> indicate unusual/unauthorised activity. In the absence of the first >>> two conditions it should be reported at least once a week or at most >>> once a day? >>> * Measured radio signal strength to be included in every >>> notification message >>> My reading of “bas” attribute is that it can only be applied to one >>> resource in the collection and cannot be used to specify different >>> observation parameters on each resource within the collection as >>> highlighted in the above use case. >>> Best Regards, >>> Mojan >>> >>> >>> >>> >>> -----Original Message----- >>> From: core [mailto:core-bounces@ietf.org] On Behalf Of Friedhelm >>> Rodermund >>> Sent: 01 March 2017 16:42 >>> To: Christian Groves >>> Cc: core >>> Subject: Re: [core] New Version Notification for >>> draft-groves-core-bas-00.txt >>> >>> Thanks Christian, >>> >>> I agree it would be very valuable to support this use case. >>> >>> Regards, >>> Friedhelm >>> >>> >>>> On 24 Feb 2017, at 01:42, Christian Groves >>>> wrote: >>>> >>>> Hello all, >>>> >>>> FYI I've submitted a draft addressing the use case discussed on the >>>> list allowing the value of one resource to trigger the notification >>>> of other resources. >>>> >>>> It proposes to use a collection that would allow binding/observe >>>> attributes on a sub-resource (item). Once the criteria is met then >>>> the value of the collection is returned. The batch and/or linked >>>> batch interfaces are used to control the resources that are returned. >>>> >>>> There's also a discussion of a more complex use case utilising the >>>> FETCH method. >>>> >>>> Like the other attributes the goal would be to have this as part of >>>> draft-ietf-core-dynlink. >>>> >>>> Comments? >>>> >>>> Regards, Christian >>>> >>>> >>>> >>>> -------- Forwarded Message -------- >>>> Subject: New Version Notification for draft-groves-core-bas-00.txt >>>> Date: Mon, 20 Feb 2017 20:41:27 -0800 >>>> From: internet-drafts@ietf.org >>>> To: Christian Groves , >>>> Christian Groves , Weiwei Yang >>>> >>>> >>>> >>>> >>>> A new version of I-D, draft-groves-core-bas-00.txt has been >>>> successfully submitted by Christian Groves and posted to the IETF >>>> repository. >>>> >>>> Name: draft-groves-core-bas >>>> Revision: 00 >>>> Title: Binding Attribute Scope >>>> Document date: 2017-02-21 >>>> Group: Individual Submission >>>> Pages: 7 >>>> URL: >>>> https://www.ietf.org/internet-drafts/draft-groves-core-bas-00.txt >>>> Status: https://datatracker.ietf.org/doc/draft-groves-core-bas/ >>>> Htmlized: https://tools.ietf.org/html/draft-groves-core-bas-00 >>>> >>>> >>>> Abstract: >>>> This document specifies an additional CoAP binding attribute that >>>> allows binding attributes to be scoped to an item (sub-resource) in a >>>> collection resource. This allows synchronisation of multiple >>>> resources in a collection based on the value of one resource. >>>> >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission until the htmlized version and diff are available at >>>> tools.ietf.org. >>>> >>>> The IETF Secretariat >>>> >>>> . >>>> >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Thu Mar 9 02:19:15 2017 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 59E591294F6 for ; Thu, 9 Mar 2017 02:19:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.332 X-Spam-Level: X-Spam-Status: No, score=-0.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, 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 u2dOzPN55hC6 for ; Thu, 9 Mar 2017 02:19:12 -0800 (PST) Received: from msh04.myshophosting.com (msh04.myshophosting.com [101.0.86.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 E0CBA1294ED for ; Thu, 9 Mar 2017 02:19:11 -0800 (PST) Received: from ppp118-209-171-106.lns20.mel8.internode.on.net ([118.209.171.106]:52816 helo=[192.168.1.159]) by msh04.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1clvA3-002LKB-1V; Thu, 09 Mar 2017 21:19:07 +1100 To: Mojan Mohajer , Friedhelm Rodermund References: <148765208755.26069.6296092128269483309.idtracker@ietfa.amsl.com> From: Christian Groves Message-ID: Date: Thu, 9 Mar 2017 21:19:02 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh04.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gmail.com X-Get-Message-Sender-Via: msh04.myshophosting.com: authenticated_id: christian@kunstmade.com.au X-Authenticated-Sender: msh04.myshophosting.com: christian@kunstmade.com.au X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: core Subject: Re: [core] New Version Notification for draft-groves-core-bas-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2017 10:19:13 -0000 Hello Mojan, As Michael points out the server would have to respect the tokens in the Observe request. E.g. if /collection?bas=temp results in a notification then Token: 0x01 would be used. Regards, Christian On 8/03/2017 9:45 PM, Mojan Mohajer wrote: > Hello Christian, > Yes, I can see the current proposals actually caters for the example scenario. Thanks for pointing this out. > I guess in this example after CoAP server receives the second observe request it can use either Token 0x01 or 0x02 when notifying the resources in the collection back to the client and client can match it to its observe requests as appropriate. > Best Regards, > Mojan > > -----Original Message----- > From: Christian Groves [mailto:cngroves.std@gmail.com] > Sent: 08 March 2017 04:56 > To: Mojan Mohajer; Friedhelm Rodermund > Cc: core > Subject: Re: [core] New Version Notification for draft-groves-core-bas-00.txt > > Hello Mojan, > > Thanks for your comments and additional scenarios. > > It would be possible to support your scenarios below utilising bas from the current draft by doing multiple observes on the collection. E.g. > > Given the following link structure: > > /collection > > /collection/temperature > > /collection/batterylevel > > /collection/signalstrength > > Two observations would be enough to satisfy the scenario below. > > 1. GET /collection?bas=temp, gth=21.2 cel, pmax=86400 (Token: 0x01, > Observe: 0) > > 2. GET /collection?bas=battery level, st, lth, pmin & pmax (Token: 0x02, > Observe: 0) > > The signal strength, battery level and temperature would be returned at each notification because the entire collection is returned upon meeting the observation parameters. > > Does this suffice? > > Having more complicated logic where there's an interaction between the resources (e.g. a notification due to battery level would satisfy the temperature "once a day" criteria) is envisaged to be handled by the FETCH method described in the draft. > > Regards, Christian > > > On 8/03/2017 4:45 AM, Mojan Mohajer wrote: >> Hello Christian, et al >> The "bas" attribute looks extremely useful and certainly addresses a number important use cases. It can also perhaps be extended to cover a more generic use case where each resource within the reported collection can have its own separate set of observation parameters. For example, a typical scenario could be to monitor a temperature sensor, device battery level that the sensor is physically attached to and measured radio signal strength when device accesses cellular network. Each of these monitored resources can/should have independent observation parameters such as: >> * Measured temperature value is reported when it exceeds a set threshold, or at least once a day (gth=21.2 celsius; pmax=86400) >> * Battery level to be reported based on st, lth, pmin and pmax observation parameters such as notification is sent when it drops below a certain % or there is a marked step change which could indicate unusual/unauthorised activity. In the absence of the first two conditions it should be reported at least once a week or at most once a day? >> * Measured radio signal strength to be included in every >> notification message My reading of bas attribute is that it can only be applied to one resource in the collection and cannot be used to specify different observation parameters on each resource within the collection as highlighted in the above use case. >> Best Regards, >> Mojan >> >> >> >> >> -----Original Message----- >> From: core [mailto:core-bounces@ietf.org] On Behalf Of Friedhelm >> Rodermund >> Sent: 01 March 2017 16:42 >> To: Christian Groves >> Cc: core >> Subject: Re: [core] New Version Notification for >> draft-groves-core-bas-00.txt >> >> Thanks Christian, >> >> I agree it would be very valuable to support this use case. >> >> Regards, >> Friedhelm >> >> >>> On 24 Feb 2017, at 01:42, Christian Groves wrote: >>> >>> Hello all, >>> >>> FYI I've submitted a draft addressing the use case discussed on the list allowing the value of one resource to trigger the notification of other resources. >>> >>> It proposes to use a collection that would allow binding/observe attributes on a sub-resource (item). Once the criteria is met then the value of the collection is returned. The batch and/or linked batch interfaces are used to control the resources that are returned. >>> >>> There's also a discussion of a more complex use case utilising the FETCH method. >>> >>> Like the other attributes the goal would be to have this as part of draft-ietf-core-dynlink. >>> >>> Comments? >>> >>> Regards, Christian >>> >>> >>> >>> -------- Forwarded Message -------- >>> Subject: New Version Notification for draft-groves-core-bas-00.txt >>> Date: Mon, 20 Feb 2017 20:41:27 -0800 >>> From: internet-drafts@ietf.org >>> To: Christian Groves , Christian Groves , Weiwei Yang >>> >>> >>> >>> A new version of I-D, draft-groves-core-bas-00.txt has been >>> successfully submitted by Christian Groves and posted to the IETF >>> repository. >>> >>> Name: draft-groves-core-bas >>> Revision: 00 >>> Title: Binding Attribute Scope >>> Document date: 2017-02-21 >>> Group: Individual Submission >>> Pages: 7 >>> URL: https://www.ietf.org/internet-drafts/draft-groves-core-bas-00.txt >>> Status: https://datatracker.ietf.org/doc/draft-groves-core-bas/ >>> Htmlized: https://tools.ietf.org/html/draft-groves-core-bas-00 >>> >>> >>> Abstract: >>> This document specifies an additional CoAP binding attribute that >>> allows binding attributes to be scoped to an item (sub-resource) in a >>> collection resource. This allows synchronisation of multiple >>> resources in a collection based on the value of one resource. >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >>> >>> . >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> > > From nobody Thu Mar 9 02:34:08 2017 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 59AA0129446 for ; Thu, 9 Mar 2017 02:34:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.332 X-Spam-Level: X-Spam-Status: No, score=-0.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, 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 f-G-bvNBaE_a for ; Thu, 9 Mar 2017 02:34:05 -0800 (PST) Received: from msh04.myshophosting.com (msh04.myshophosting.com [101.0.86.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 58E19128DF6 for ; Thu, 9 Mar 2017 02:34:05 -0800 (PST) Received: from ppp118-209-171-106.lns20.mel8.internode.on.net ([118.209.171.106]:53202 helo=[192.168.1.159]) by msh04.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1clvOI-002MBU-Bo; Thu, 09 Mar 2017 21:33:50 +1100 To: Michael Koster References: <148765208755.26069.6296092128269483309.idtracker@ietfa.amsl.com> From: Christian Groves Message-ID: Date: Thu, 9 Mar 2017 21:33:45 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh04.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gmail.com X-Get-Message-Sender-Via: msh04.myshophosting.com: authenticated_id: christian@kunstmade.com.au X-Authenticated-Sender: msh04.myshophosting.com: christian@kunstmade.com.au X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: core Subject: Re: [core] New Version Notification for draft-groves-core-bas-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2017 10:34:06 -0000 Hello Michael, The text on collections was a left over from before I took over the editorship. The text in [I-D.ietf-core-interfaces] is: 3.6 . Observing Collections Resource Observation via [I-D.ietf-core-dynlink ] using CoAP [RFC7252 ] MAY be supported on items in a collection. A subset of the conditional observe parameters MAY be specified to apply. In most cases pmin and pmax are useful. Resource observation on a collection's items resource MAY report any changes of resource state in any item in the collection. Observation Responses, or notifications, SHOULD provide representations of the resources that have changed in SenML Content-Format. Notifications MAY include multiple observations of a particular resource, with SenML time stamps indicating the observation times. The text in 2.1 of the BAS draft is just trying a paraphrase that. Did you want to clarify that text? Regards, Christian On 9/03/2017 3:10 AM, Michael Koster wrote: > In section 2.1 > The current text of [I-D.ietf-core-interfaces] indicates that observe > may be supported on an item in a collection not on the collection > itself. > I don't think we should say that observe isn't supported on collections. > > Observe should be supported for any resource, and by definition > "caches" the entire method call (for example GET with all its options) > for subsequent responses. > > Observe doesn't say what triggers the subsequent responses, which > dynlink and bas do specify. > > Do I understand it correctly? > > Best regards, > > Michael From nobody Thu Mar 9 04:33:03 2017 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 0777F1295D8 for ; Thu, 9 Mar 2017 04:33:02 -0800 (PST) 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, 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 AaAq-QkBYpvj for ; Thu, 9 Mar 2017 04:33:00 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 107F51295C3 for ; Thu, 9 Mar 2017 04:32:59 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id D50FD46841; Thu, 9 Mar 2017 13:32:56 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id B41EB288; Thu, 9 Mar 2017 13:32:54 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 2E71B439; Thu, 9 Mar 2017 12:56:41 +0100 (CET) Received: (nullmailer pid 12775 invoked by uid 1000); Thu, 09 Mar 2017 11:56:24 -0000 Date: Thu, 9 Mar 2017 12:56:24 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Nikos Fotiou Message-ID: <20170309115623.irspeqzxvdh6zj5p@hephaistos.amsuess.com> References: <148765208755.26069.6296092128269483309.idtracker@ietfa.amsl.com> <4f51d959-7e26-0c42-bc18-b0e60d1cb18a@aueb.gr> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ipm2ymu56rcpvtoy" Content-Disposition: inline In-Reply-To: <4f51d959-7e26-0c42-bc18-b0e60d1cb18a@aueb.gr> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Cc: core@ietf.org Subject: Re: [core] New Version Notification for draft-groves-core-bas-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2017 12:33:02 -0000 --ipm2ymu56rcpvtoy Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Nikos, On Wed, Mar 08, 2017 at 12:13:21PM +0200, Nikos Fotiou wrote: > I have a naive question. Why all these should be provided by CoAP and not= by > the application layer? I'd see these extensions in a similar fashion as the core-interfaces: it provides one (suggested but not prescribed) way to use observable CoAP resources. > IMHO this functionality overloads CoAP with semantics. Isn't there the > danger to result with a bloated protocol? I do agree that in general, parameter names should stay free for applications to choose. Even though the Function Set terminology has been abandoned AFAIR, could we use a if=3D value (possibly piggy-backing on one of the core-interfaces or dynlink values) to ensure that the 'bas=3D' parameter does not gain meaning (thus becoming practically reserved) for all resources, but only those that implement it? Best regards Christian --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --ipm2ymu56rcpvtoy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAljBQuUACgkQOY0REtOk veGAKhAAvwm21Qk7WFKkexjRpNxYKWWQ8VfWik4fpERsuHY8RG2LzhDGVKT6O+mx hdnlJev25ZVMPnOlRj45Nm+qDRBghiVHIvS/Udee+A5YOKdEhmkvtsQGaBBde80l plRVEXAn9QOcXthn22djFvxCEGKvh9O2ruoO50XDLTD0eaikeMutvLHxR8QT5cad kgY9gU/rt0QUfMkQ/9fC1FqaaAK24NBuDcgnuK9De7GNq4tuRlhUqHAaM07sDrA9 VVrF0xmJxpiabHX1vkxPGd93d3KUBYjc8fU0XgV5VxzgeO5XOqZuh1skUZFG/Whj OcegwTxkuxOfZCUzObOTEn2BPHPN/sMml0paWifuHWeaoHz+nf5xvnbmqDOfItMr wfpsZ1XReJn1EY+YGU0SKkpC63OhzZKgSvohFIFqXrBgV1ipQ7c5bXGJIsgo+z1H /QDMBRJ2WvTzzrwoby8pftgxcf1eApMyP5exOOovCuY85RKo3DJDk6a4+Ayc2Lr3 Xi5JKuPQFq14U+jn/KtjkAeHBSKDgrvzZvRWHNa7F+FZON/PGWp4tSemSFFHtTrE fPpqixomGdaRc9wAtN+QQ/N180Om4oQKG/hlROR+o1iK4S8Y4sFZAGFly/EaQ5ve CEUflxNvnJWwobxRJr8QbiZ14nSt7/SuRLxlQV3JF81PqXyup5Y= =u0V6 -----END PGP SIGNATURE----- --ipm2ymu56rcpvtoy-- From nobody Thu Mar 9 05:47:23 2017 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 F0B8112960F for ; Thu, 9 Mar 2017 05:47:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 zDHcpW8AWPdS for ; Thu, 9 Mar 2017 05:47:20 -0800 (PST) Received: from lb3-smtp-cloud2.xs4all.net (lb3-smtp-cloud2.xs4all.net [194.109.24.29]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09CCE12941A for ; Thu, 9 Mar 2017 05:47:19 -0800 (PST) Received: from webmail.xs4all.nl ([194.109.20.200]) by smtp-cloud2.xs4all.net with ESMTP id tpnJ1u0084K0fSy01pnJZT; Thu, 09 Mar 2017 14:47:18 +0100 Received: from 2001:983:a264:1:8562:6a83:d41:d7ce by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 09 Mar 2017 14:47:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 09 Mar 2017 14:47:18 +0100 From: peter van der Stok To: Core Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <148821732067.21153.4973524108355820931.idtracker@ietfa.amsl.com> References: <148821732067.21153.4973524108355820931.idtracker@ietfa.amsl.com> Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Subject: [core] Fwd: New Version Notification for draft-hartke-core-pending-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 13:47:22 -0000 Hi Core, This draft was motivated by the draft vanderstok-ace-coap-est, submitted to ACE. I look forward to present its motivation and use during the core meeting in Chicago, Peter A new version of I-D, draft-hartke-core-pending-00.txt has been successfully submitted by Klaus Hartke and posted to the IETF repository. Name: draft-hartke-core-pending Revision: 00 Title: The 'Pending' Response Code for the Constrained Application Protocol (CoAP) Document date: 2017-02-27 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-hartke-core-pending-00.txt Status: https://datatracker.ietf.org/doc/draft-hartke-core-pending/ Htmlized: https://tools.ietf.org/html/draft-hartke-core-pending-00 Abstract: This document proposes a new CoAP response code, 2.06 Pending. A CoAP server can use this response code to signal that it has accepted the request but has not yet started processing it or that processing the request will take longer than a client is typically willing to wait for a response. A 2.06 response can include status information and indicate a location where the result will become available. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Thu Mar 9 08:06:12 2017 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 2B27812969C for ; Thu, 9 Mar 2017 08:06:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 yMXOFh0MA3vU for ; Thu, 9 Mar 2017 08:06:07 -0800 (PST) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::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 B4685129680 for ; Thu, 9 Mar 2017 08:06:07 -0800 (PST) Received: by mail-oi0-x230.google.com with SMTP id 126so38432336oig.3 for ; Thu, 09 Mar 2017 08:06:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=md9SFdfW0bvyM19fJRskCp1nHlsgB6+3QyyJ9pzLgWw=; b=hpuD9JHMWJ8GWDSN8yZGTr2WVcfSPZ97McqWaSYcm9NpjkP/vIPBZX3mMLppqXnaV8 1/h5C12XHIVrjkTZH6M+pWcHf28mz2e2BZShaWGHLrwftQJKiKI8PksfptxHLH4/3Muo deXxzObVnby/E68BRtxRF26xQqwiv0wA5tRr2vZ21D3tutG+RE0mbsT0dRDR2lXujjEv JoKUdmL1W+6lbJf8PlwRccTj/aGXgrOmxkywrl3kxef/36RWrBYNtce7uV/2i0c0bmCu L/qKQJJfbgPggiHmC7Z+4oUQY/H9s9j3aO9M5XX3hk5Y2/Fc8hPox5gNhomUV1UMzeUg 7vTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=md9SFdfW0bvyM19fJRskCp1nHlsgB6+3QyyJ9pzLgWw=; b=QokPSGcrMHXDoJN4idaygT2AEEq+GCXBKtV6NOffPZG4mkodU+sss+dyHDBWMDvGi6 vV6Q0zYHu1YIlZyQy3Bx/8lltML+uEIv05dya47/bMHSbLzWrggRVw02zyFF3RilJjxL VO3T8oJtIYMRNXGNvczgeQyMejztSLR9K9iUeVqYgJdGE33F5fKthuFCTeQTZ34mK1+u M1PHRkCvxpJqqMGoJFjzxQa6jnu6b7s7zw5f06cPe3Z6Pc6ZhycWNtjxkpJOaB0JS9cl wuFfKdS/NsJrFyphWqvhc8XIa+rkrgMdRLINtAoFfuVV7WaLwF5NKFWgZZSDaL3rn4HR U3WA== X-Gm-Message-State: AMke39nvsnxI95uV83VbFdbOaNvIZFvBZkNaEPHmuEHZwd0yoHFAbxQZ/uBlSdvVO4ovsw== X-Received: by 10.202.252.23 with SMTP id a23mr7149384oii.153.1489075566959; Thu, 09 Mar 2017 08:06:06 -0800 (PST) Received: from [172.20.21.5] (rrcs-97-79-186-2.sw.biz.rr.com. [97.79.186.2]) by smtp.gmail.com with ESMTPSA id o76sm2978359ota.56.2017.03.09.08.06.06 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 09 Mar 2017 08:06:06 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: Date: Thu, 9 Mar 2017 10:06:04 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <0E74FB71-3B52-4816-AEC8-305FF513D9B2@gmail.com> References: <148765208755.26069.6296092128269483309.idtracker@ietfa.amsl.com> To: Christian Groves X-Mailer: Apple Mail (2.2104) Archived-At: Cc: core Subject: Re: [core] New Version Notification for draft-groves-core-bas-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2017 16:06:09 -0000 Yes, the text below should be changed. The description here seems to be = a little inconsistent with the definition of observe, in that it suggest = you may only need to send the representations for resources that have = changed.=20 I think my description in the email is more what we want to say, that = the collection representation specified in the original request is = returned. We should mention conditional observe on collections in a way that = leaves it open for bas Best regards, Michael > On Mar 9, 2017, at 4:33 AM, Christian Groves = wrote: >=20 > Hello Michael, >=20 > The text on collections was a left over from before I took over the = editorship. The text in [I-D.ietf-core-interfaces] is: >=20 >=20 > 3.6 > = . > Observing Collections >=20 >=20 >=20 > Resource Observation via [I-D.ietf-core-dynlink = ] using CoAP [RFC7252 ] > MAY be supported on items in a collection. A subset of the > conditional observe parameters MAY be specified to apply. In most > cases pmin and pmax are useful. Resource observation on a > collection's items resource MAY report any changes of resource state > in any item in the collection. Observation Responses, or > notifications, SHOULD provide representations of the resources that > have changed in SenML Content-Format. Notifications MAY include > multiple observations of a particular resource, with SenML time > stamps indicating the observation times. >=20 >=20 > The text in 2.1 of the BAS draft is just trying a paraphrase that. Did = you want to clarify that text? >=20 > Regards, Christian >=20 >=20 > On 9/03/2017 3:10 AM, Michael Koster wrote: >> In section 2.1 >> The current text of [I-D.ietf-core-interfaces] indicates that = observe >> may be supported on an item in a collection not on the collection >> itself. >> I don't think we should say that observe isn't supported on = collections. >>=20 >> Observe should be supported for any resource, and by definition = "caches" the entire method call (for example GET with all its options) = for subsequent responses. >>=20 >> Observe doesn't say what triggers the subsequent responses, which = dynlink and bas do specify. >>=20 >> Do I understand it correctly? >>=20 >> Best regards, >>=20 >> Michael >=20 From nobody Thu Mar 9 08:10:43 2017 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 2DAC312948B for ; Thu, 9 Mar 2017 08:10:42 -0800 (PST) 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 58L847cSxJlI for ; Thu, 9 Mar 2017 08:10:39 -0800 (PST) Received: from buffalo.u-blox.com (buffalo.u-blox.com [195.34.89.137]) by ietfa.amsl.com (Postfix) with SMTP id 66D6912955D for ; Thu, 9 Mar 2017 08:10:38 -0800 (PST) Received: from mail_filter (localhost [127.0.0.1]) by buffalo.u-blox.com (PF_LO_10026) with ESMTP id AF02415F68E for ; Thu, 9 Mar 2017 17:10:37 +0100 (CET) Received: from ASSP.nospam (localhost [127.0.0.1]) by buffalo.u-blox.com (Postfix) with ESMTP id 7A1E615F630; Thu, 9 Mar 2017 17:10:37 +0100 (CET) Received: from unknown ([127.0.0.1] helo=anyhost.local) by ASSP.nospam with SMTP (2.4.7); 9 Mar 2017 17:10:37 +0100 From: =?windows-1252?Q?Mojan_Mohajer?= To: =?windows-1252?Q?Christian_Groves?= , =?windows-1252?Q?Friedhelm_Rodermund?= Date: Thu, 9 Mar 2017 17:10:37 +0100 Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable In-Reply-To: References: <148765208755.26069.6296092128269483309.idtracker@ietfa.amsl.com> X-Priority: 3 (Normal) X-Mailer: Zarafa 7.1.14-51822 Thread-Index: AdKY769AKhJf7HQMQ8ekhHN6x1ALYA== Message-Id: X-Assp-Version: 2.4.7(16004) on ASSP.nospam X-Assp-ID: ASSP.nospam 75837-00218 X-Assp-Session: 7292ECB4 (mail 1) X-Assp-Original-Subject: RE: [core] New Version Notification for draft-groves-core-bas-00.txt X-Virus-Scanned: clamav-milter 0.99.2 at buffalo X-Virus-Status: Clean Archived-At: Cc: =?windows-1252?Q?core?= Subject: Re: [core] New Version Notification for draft-groves-core-bas-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2017 16:10:42 -0000 Hello Michael & Christian, Thanks for the clarifications. If you decide to include an example scenario like the one we've been discussing in the future drafts, it may be worth showing separate responses from the server with correct tokens to emphasise this.=20 It may also be worth indicating the expected behaviour when pmin is specified as observe parameter on a sub-resource in a collection when there is more than one observes request as per previous example: 1. GET /collection=3Fbas=3Dtemp & gth=3D21.2 cel, pmax=3D86400 (Token: 0x01, Observe: 0) 2. GET /collection=3Fbas=3Dbattery_level, st=3D2, lth=3D40, pmin=3D14400, pmax=3D604800 (Token: 0x02, Observe: 0) time=3Dx : temperature goes over the specified threshold and the server reports the values of sub-resources in the collection (temp, battery level, signal strength) time=3Dx+400: battery level drops below 40% or changes by 2% or more. If pmin for battery level reporting is taken to start from time x, then the step change or battery level dropping below specified threshold will not generate a report from the server for another 14000 seconds, i.e. till time=3Dx+14400. Not sure if this behaviour will be in-line with clients' expectations. Best Regards, Mojan -----Original Message----- From: Christian Groves [mailto:cngroves.std@gmail.com]=20 Sent: 09 March 2017 10:19 To: Mojan Mohajer; Friedhelm Rodermund Cc: core Subject: Re: [core] New Version Notification for draft-groves-core-bas-00.txt Hello Mojan, As Michael points out the server would have to respect the tokens in the Observe request. E.g. if /collection=3Fbas=3Dtemp results in a notification then Token: 0x01 would be used. Regards, Christian On 8/03/2017 9:45 PM, Mojan Mohajer wrote: > Hello Christian, > Yes, I can see the current proposals actually caters for the example scenario. Thanks for pointing this out. > I guess in this example after CoAP server receives the second observe request it can use either Token 0x01 or 0x02 when notifying the resources in the collection back to the client and client can match it to its observe requests as appropriate. > Best Regards, > Mojan > > -----Original Message----- > From: Christian Groves [mailto:cngroves.std@gmail.com] > Sent: 08 March 2017 04:56 > To: Mojan Mohajer; Friedhelm Rodermund > Cc: core > Subject: Re: [core] New Version Notification for=20 > draft-groves-core-bas-00.txt > > Hello Mojan, > > Thanks for your comments and additional scenarios. > > It would be possible to support your scenarios below utilising bas from the current draft by doing multiple observes on the collection. E.g. > > Given the following link structure: > > /collection > > /collection/temperature > > /collection/batterylevel > > /collection/signalstrength > > Two observations would be enough to satisfy the scenario below. > > 1. GET /collection=3Fbas=3Dtemp, gth=3D21.2 cel, pmax=3D86400 (Token: 0x01, > Observe: 0) > > 2. GET /collection=3Fbas=3Dbattery level, st, lth, pmin & pmax (Token:=20 > 0x02, > Observe: 0) > > The signal strength, battery level and temperature would be returned at each notification because the entire collection is returned upon meeting the observation parameters. > > Does this suffice=3F > > Having more complicated logic where there's an interaction between the resources (e.g. a notification due to battery level would satisfy the temperature "once a day" criteria) is envisaged to be handled by the FETCH method described in the draft. > > Regards, Christian > > > On 8/03/2017 4:45 AM, Mojan Mohajer wrote: >> Hello Christian, et al >> The "bas" attribute looks extremely useful and certainly addresses a number important use cases. It can also perhaps be extended to cover a more generic use case where each resource within the reported collection can have its own separate set of observation parameters. For example, a typical scenario could be to monitor a temperature sensor, device battery level that the sensor is physically attached to and measured radio signal strength when device accesses cellular network. Each of these monitored resources can/should have independent observation parameters such as: >> * Measured temperature value is reported when it exceeds a set threshold, or at least once a day (gth=3D21.2 celsius; pmax=3D86400) >> * Battery level to be reported based on st, lth, pmin and pmax observation parameters such as notification is sent when it drops below a certain % or there is a marked step change which could indicate unusual/unauthorised activity. In the absence of the first two conditions it should be reported at least once a week or at most once a day=3F >> * Measured radio signal strength to be included in every=20 >> notification message My reading of =93bas=94 attribute is that it can only be applied to one resource in the collection and cannot be used to specify different observation parameters on each resource within the collection as highlighted in the above use case. >> Best Regards, >> Mojan >> >> >> >> >> -----Original Message----- >> From: core [mailto:core-bounces@ietf.org] On Behalf Of Friedhelm=20 >> Rodermund >> Sent: 01 March 2017 16:42 >> To: Christian Groves >> Cc: core >> Subject: Re: [core] New Version Notification for=20 >> draft-groves-core-bas-00.txt >> >> Thanks Christian, >> >> I agree it would be very valuable to support this use case. >> >> Regards, >> Friedhelm >> >> >>> On 24 Feb 2017, at 01:42, Christian Groves wrote: >>> >>> Hello all, >>> >>> FYI I've submitted a draft addressing the use case discussed on the list allowing the value of one resource to trigger the notification of other resources. >>> >>> It proposes to use a collection that would allow binding/observe attributes on a sub-resource (item). Once the criteria is met then the value of the collection is returned. The batch and/or linked batch interfaces are used to control the resources that are returned. >>> >>> There's also a discussion of a more complex use case utilising the FETCH method. >>> >>> Like the other attributes the goal would be to have this as part of draft-ietf-core-dynlink. >>> >>> Comments=3F >>> >>> Regards, Christian >>> >>> >>> >>> -------- Forwarded Message -------- >>> Subject: =09New Version Notification for draft-groves-core-bas-00.txt >>> Date: =09Mon, 20 Feb 2017 20:41:27 -0800 >>> From: =09internet-drafts@ietf.org >>> To: =09Christian Groves , Christian Groves , Weiwei Yang >>> >>> >>> >>> A new version of I-D, draft-groves-core-bas-00.txt has been=20 >>> successfully submitted by Christian Groves and posted to the IETF=20 >>> repository. >>> >>> Name:=09=09draft-groves-core-bas >>> Revision:=0900 >>> Title:=09=09Binding Attribute Scope >>> Document date:=092017-02-21 >>> Group:=09=09Individual Submission >>> Pages:=09=097 >>> URL: https://www.ietf.org/internet-drafts/draft-groves-core-bas-00.txt >>> Status: https://datatracker.ietf.org/doc/draft-groves-core-bas/ >>> Htmlized: https://tools.ietf.org/html/draft-groves-core-bas-00 >>> >>> >>> Abstract: >>> This document specifies an additional CoAP binding attribute that >>> allows binding attributes to be scoped to an item (sub-resource) in a >>> collection resource. This allows synchronisation of multiple >>> resources in a collection based on the value of one resource. >>> >>> =20 >>> >>> Please note that it may take a couple of minutes from the time of=20 >>> submission until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >>> >>> . >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> > > From nobody Thu Mar 9 21:26:52 2017 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 DC91E1294DB for ; Thu, 9 Mar 2017 21:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] 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 WupBYOM9Tcjx for ; Thu, 9 Mar 2017 21:26:50 -0800 (PST) Received: from msh04.myshophosting.com (msh04.myshophosting.com [101.0.86.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 D62C512941C for ; Thu, 9 Mar 2017 21:26:49 -0800 (PST) Received: from ppp118-209-171-106.lns20.mel8.internode.on.net ([118.209.171.106]:61722 helo=[192.168.1.22]) by msh04.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1cmD4h-003sL1-43 for core@ietf.org; Fri, 10 Mar 2017 16:26:47 +1100 To: core@ietf.org References: <148765208755.26069.6296092128269483309.idtracker@ietfa.amsl.com> <4f51d959-7e26-0c42-bc18-b0e60d1cb18a@aueb.gr> <20170309115623.irspeqzxvdh6zj5p@hephaistos.amsuess.com> From: Christian Groves Message-ID: <8d8649a5-732c-7ab3-10c0-951e4547748b@gmail.com> Date: Fri, 10 Mar 2017 16:26:41 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170309115623.irspeqzxvdh6zj5p@hephaistos.amsuess.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh04.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gmail.com X-Get-Message-Sender-Via: msh04.myshophosting.com: authenticated_id: christian@kunstmade.com.au X-Authenticated-Sender: msh04.myshophosting.com: christian@kunstmade.com.au X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [core] New Version Notification for draft-groves-core-bas-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 05:26:52 -0000 Hello Christian, It's something to be discussed in Chicago whether we roll the bas parameter into the dynlink draft or to keep it separate. With regards to the reservation of parameter names if we allow a free for all on naming then we'll end up with problems of overlapping parameters exactly like we've already had between the resource directory and dynlink drafts on the name "lt" achieving two different functions. I mentioned in the discussion about dynlink on the list about the possibility to update the RD draft to create a generic registry for CoAP query parameters. I think this could easily be achieved by adding an extra column to the table in section 12.4/draft-ietf-core-resource-directory indicating some sort of context/scope e.g. the applicable interface description or resource types. Again this is something that CoRE could discuss in Chicago. Regards, Christian On 9/03/2017 10:56 PM, Christian Amsss wrote: > Hello Nikos, > > On Wed, Mar 08, 2017 at 12:13:21PM +0200, Nikos Fotiou wrote: >> I have a naive question. Why all these should be provided by CoAP and not by >> the application layer? > I'd see these extensions in a similar fashion as the core-interfaces: it > provides one (suggested but not prescribed) way to use observable CoAP > resources. > >> IMHO this functionality overloads CoAP with semantics. Isn't there the >> danger to result with a bloated protocol? > I do agree that in general, parameter names should stay free for > applications to choose. > > Even though the Function Set terminology has been abandoned AFAIR, > could we use a if= value (possibly piggy-backing on one of the > core-interfaces or dynlink values) to ensure that the 'bas=' parameter > does not gain meaning (thus becoming practically reserved) for all > resources, but only those that implement it? > > Best regards > Christian > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Thu Mar 9 21:39:14 2017 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 735DC1295C6 for ; Thu, 9 Mar 2017 21:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] 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 PEqBPoEM1vgU for ; Thu, 9 Mar 2017 21:39:09 -0800 (PST) Received: from msh04.myshophosting.com (msh04.myshophosting.com [101.0.86.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 227651295B5 for ; Thu, 9 Mar 2017 21:39:09 -0800 (PST) Received: from ppp118-209-171-106.lns20.mel8.internode.on.net ([118.209.171.106]:62053 helo=[192.168.1.22]) by msh04.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1cmDGF-003tEJ-Nx; Fri, 10 Mar 2017 16:38:43 +1100 To: Mojan Mohajer , Friedhelm Rodermund References: <148765208755.26069.6296092128269483309.idtracker@ietfa.amsl.com> From: Christian Groves Message-ID: <5c0b85c4-6c2c-1c41-bcac-480e131f6de5@gmail.com> Date: Fri, 10 Mar 2017 16:38:36 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh04.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gmail.com X-Get-Message-Sender-Via: msh04.myshophosting.com: authenticated_id: christian@kunstmade.com.au X-Authenticated-Sender: msh04.myshophosting.com: christian@kunstmade.com.au X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: core Subject: Re: [core] New Version Notification for draft-groves-core-bas-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 05:39:10 -0000 Hello Mojan, I can add something in the next version. I'm not sure whether i'll get to it before the document deadline for Chicago though. With regards to time=x+14400 and pmin, if the client sets pmin=14400 that's the behaviour it should expect. BTW if the client wants further notifications below the 40% mark then it would be better off using the band parameters defined in draft-groves-core-obsattr. The lth and gth only trigger when the value goes through the threshold. Regards, Christian On 10/03/2017 3:10 AM, Mojan Mohajer wrote: > Hello Michael & Christian, > Thanks for the clarifications. If you decide to include an example scenario like the one we've been discussing in the future drafts, it may be worth showing separate responses from the server with correct tokens to emphasise this. > It may also be worth indicating the expected behaviour when pmin is specified as observe parameter on a sub-resource in a collection when there is more than one observes request as per previous example: > > 1. GET /collection?bas=temp & gth=21.2 cel, pmax=86400 (Token: 0x01, Observe: 0) > 2. GET /collection?bas=battery_level, st=2, lth=40, pmin=14400, pmax=604800 (Token: 0x02, Observe: 0) > > time=x : temperature goes over the specified threshold and the server reports the values of sub-resources in the collection (temp, battery level, signal strength) > time=x+400: battery level drops below 40% or changes by 2% or more. > > If pmin for battery level reporting is taken to start from time x, then the step change or battery level dropping below specified threshold will not generate a report from the server for another 14000 seconds, i.e. till time=x+14400. Not sure if this behaviour will be in-line with clients' expectations. > Best Regards, > Mojan > > > -----Original Message----- > From: Christian Groves [mailto:cngroves.std@gmail.com] > Sent: 09 March 2017 10:19 > To: Mojan Mohajer; Friedhelm Rodermund > Cc: core > Subject: Re: [core] New Version Notification for draft-groves-core-bas-00.txt > > Hello Mojan, > > As Michael points out the server would have to respect the tokens in the Observe request. E.g. if /collection?bas=temp results in a notification then Token: 0x01 would be used. > > Regards, Christian > > > On 8/03/2017 9:45 PM, Mojan Mohajer wrote: >> Hello Christian, >> Yes, I can see the current proposals actually caters for the example scenario. Thanks for pointing this out. >> I guess in this example after CoAP server receives the second observe request it can use either Token 0x01 or 0x02 when notifying the resources in the collection back to the client and client can match it to its observe requests as appropriate. >> Best Regards, >> Mojan >> >> -----Original Message----- >> From: Christian Groves [mailto:cngroves.std@gmail.com] >> Sent: 08 March 2017 04:56 >> To: Mojan Mohajer; Friedhelm Rodermund >> Cc: core >> Subject: Re: [core] New Version Notification for >> draft-groves-core-bas-00.txt >> >> Hello Mojan, >> >> Thanks for your comments and additional scenarios. >> >> It would be possible to support your scenarios below utilising bas from the current draft by doing multiple observes on the collection. E.g. >> >> Given the following link structure: >> >> /collection >> >> /collection/temperature >> >> /collection/batterylevel >> >> /collection/signalstrength >> >> Two observations would be enough to satisfy the scenario below. >> >> 1. GET /collection?bas=temp, gth=21.2 cel, pmax=86400 (Token: 0x01, >> Observe: 0) >> >> 2. GET /collection?bas=battery level, st, lth, pmin & pmax (Token: >> 0x02, >> Observe: 0) >> >> The signal strength, battery level and temperature would be returned at each notification because the entire collection is returned upon meeting the observation parameters. >> >> Does this suffice? >> >> Having more complicated logic where there's an interaction between the resources (e.g. a notification due to battery level would satisfy the temperature "once a day" criteria) is envisaged to be handled by the FETCH method described in the draft. >> >> Regards, Christian >> >> >> On 8/03/2017 4:45 AM, Mojan Mohajer wrote: >>> Hello Christian, et al >>> The "bas" attribute looks extremely useful and certainly addresses a number important use cases. It can also perhaps be extended to cover a more generic use case where each resource within the reported collection can have its own separate set of observation parameters. For example, a typical scenario could be to monitor a temperature sensor, device battery level that the sensor is physically attached to and measured radio signal strength when device accesses cellular network. Each of these monitored resources can/should have independent observation parameters such as: >>> * Measured temperature value is reported when it exceeds a set threshold, or at least once a day (gth=21.2 celsius; pmax=86400) >>> * Battery level to be reported based on st, lth, pmin and pmax observation parameters such as notification is sent when it drops below a certain % or there is a marked step change which could indicate unusual/unauthorised activity. In the absence of the first two conditions it should be reported at least once a week or at most once a day? >>> * Measured radio signal strength to be included in every >>> notification message My reading of bas attribute is that it can only be applied to one resource in the collection and cannot be used to specify different observation parameters on each resource within the collection as highlighted in the above use case. >>> Best Regards, >>> Mojan >>> >>> >>> >>> >>> -----Original Message----- >>> From: core [mailto:core-bounces@ietf.org] On Behalf Of Friedhelm >>> Rodermund >>> Sent: 01 March 2017 16:42 >>> To: Christian Groves >>> Cc: core >>> Subject: Re: [core] New Version Notification for >>> draft-groves-core-bas-00.txt >>> >>> Thanks Christian, >>> >>> I agree it would be very valuable to support this use case. >>> >>> Regards, >>> Friedhelm >>> >>> >>>> On 24 Feb 2017, at 01:42, Christian Groves wrote: >>>> >>>> Hello all, >>>> >>>> FYI I've submitted a draft addressing the use case discussed on the list allowing the value of one resource to trigger the notification of other resources. >>>> >>>> It proposes to use a collection that would allow binding/observe attributes on a sub-resource (item). Once the criteria is met then the value of the collection is returned. The batch and/or linked batch interfaces are used to control the resources that are returned. >>>> >>>> There's also a discussion of a more complex use case utilising the FETCH method. >>>> >>>> Like the other attributes the goal would be to have this as part of draft-ietf-core-dynlink. >>>> >>>> Comments? >>>> >>>> Regards, Christian >>>> >>>> >>>> >>>> -------- Forwarded Message -------- >>>> Subject: New Version Notification for draft-groves-core-bas-00.txt >>>> Date: Mon, 20 Feb 2017 20:41:27 -0800 >>>> From: internet-drafts@ietf.org >>>> To: Christian Groves , Christian Groves , Weiwei Yang >>>> >>>> >>>> >>>> A new version of I-D, draft-groves-core-bas-00.txt has been >>>> successfully submitted by Christian Groves and posted to the IETF >>>> repository. >>>> >>>> Name: draft-groves-core-bas >>>> Revision: 00 >>>> Title: Binding Attribute Scope >>>> Document date: 2017-02-21 >>>> Group: Individual Submission >>>> Pages: 7 >>>> URL: https://www.ietf.org/internet-drafts/draft-groves-core-bas-00.txt >>>> Status: https://datatracker.ietf.org/doc/draft-groves-core-bas/ >>>> Htmlized: https://tools.ietf.org/html/draft-groves-core-bas-00 >>>> >>>> >>>> Abstract: >>>> This document specifies an additional CoAP binding attribute that >>>> allows binding attributes to be scoped to an item (sub-resource) in a >>>> collection resource. This allows synchronisation of multiple >>>> resources in a collection based on the value of one resource. >>>> >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission until the htmlized version and diff are available at tools.ietf.org. >>>> >>>> The IETF Secretariat >>>> >>>> . >>>> >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> >>> >> > > From nobody Thu Mar 9 21:55:15 2017 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 C732B127A90 for ; Thu, 9 Mar 2017 21:55:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] 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 Co-iT_IjhQL5 for ; Thu, 9 Mar 2017 21:55:13 -0800 (PST) Received: from msh04.myshophosting.com (msh04.myshophosting.com [101.0.86.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 D1629124281 for ; Thu, 9 Mar 2017 21:55:12 -0800 (PST) Received: from ppp118-209-171-106.lns20.mel8.internode.on.net ([118.209.171.106]:62620 helo=[192.168.1.22]) by msh04.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1cmDWB-003uSq-1o for core@ietf.org; Fri, 10 Mar 2017 16:55:11 +1100 References: <148912314641.5730.14064447847116030290.idtracker@ietfa.amsl.com> To: core From: Christian Groves X-Forwarded-Message-Id: <148912314641.5730.14064447847116030290.idtracker@ietfa.amsl.com> Message-ID: <853bbfad-debb-f40c-344c-cff8bd9a89cd@gmail.com> Date: Fri, 10 Mar 2017 16:55:04 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <148912314641.5730.14064447847116030290.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh04.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gmail.com X-Get-Message-Sender-Via: msh04.myshophosting.com: authenticated_id: christian@kunstmade.com.au X-Authenticated-Sender: msh04.myshophosting.com: christian@kunstmade.com.au X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: [core] Fwd: New Version Notification for draft-groves-core-senml-options-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 05:55:14 -0000 Hello all, FYI I've submitted a draft to discuss the problem of the behaviour of endpoints if they encounter an unknown SenML attribute such as BTO. This was raised at the Seoul meeting. Regards, Christian -------- Forwarded Message -------- Subject: New Version Notification for draft-groves-core-senml-options-00.txt Date: Thu, 9 Mar 2017 21:19:06 -0800 From: internet-drafts@ietf.org To: Weiwei Yang , Christian Groves , Christian Groves A new version of I-D, draft-groves-core-senml-options-00.txt has been successfully submitted by Christian Groves and posted to the IETF repository. Name: draft-groves-core-senml-options Revision: 00 Title: SenML Options Document date: 2017-03-10 Group: Individual Submission Pages: 13 URL: https://www.ietf.org/internet-drafts/draft-groves-core-senml-options-00.txt Status: https://datatracker.ietf.org/doc/draft-groves-core-senml-options/ Htmlized: https://tools.ietf.org/html/draft-groves-core-senml-options-00 Abstract: SenML [I-D.ietf-core-senml] defines an initial set of base and regular attributes which are tied to a particular version of SenML. SenML also allows the definition of additional attributes by extending the syntax with a new label. Allowing the extension of attributes brings the problem of how do endpoints negotiate whether the new attribute can be used or not? This document discusses the issue and proposes some potential solutions to this issue. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat . From nobody Fri Mar 10 00:04:37 2017 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 8EA4C12971B for ; Fri, 10 Mar 2017 00:04:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ao1Gz4ngZUPH for ; Fri, 10 Mar 2017 00:04:33 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA13F129715 for ; Fri, 10 Mar 2017 00:04:33 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 3CDA446848; Fri, 10 Mar 2017 09:04:31 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id E1A31DB; Fri, 10 Mar 2017 09:04:29 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 82C78441; Fri, 10 Mar 2017 09:04:29 +0100 (CET) Received: (nullmailer pid 14782 invoked by uid 1000); Fri, 10 Mar 2017 08:04:28 -0000 Date: Fri, 10 Mar 2017 09:04:28 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Christian Groves , Michael Koster Message-ID: <20170310080428.2capee5w4oqecs3l@hephaistos.amsuess.com> References: <148765208755.26069.6296092128269483309.idtracker@ietfa.amsl.com> <4f51d959-7e26-0c42-bc18-b0e60d1cb18a@aueb.gr> <20170309115623.irspeqzxvdh6zj5p@hephaistos.amsuess.com> <8d8649a5-732c-7ab3-10c0-951e4547748b@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="aosku2bkc2znyq6s" Content-Disposition: inline In-Reply-To: <8d8649a5-732c-7ab3-10c0-951e4547748b@gmail.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Cc: core@ietf.org Subject: [core] bas and RD query parameters list (was: New Version Notification for draft-groves-core-bas-00.txt) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 08:04:35 -0000 --aosku2bkc2znyq6s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello bas & RD planners, On Fri, Mar 10, 2017 at 04:26:41PM +1100, Christian Groves wrote: > [...] problems of overlapping parameters [...] "lt" achieving two > different functions. >=20 > [...] update the RD draft to create a generic registry for CoAP > query parameters. I think this could easily be achieved by adding an extra > column to the table in section 12.4/draft-ietf-core-resource-directory > indicating some sort of context/scope e.g. the applicable interface > description or resource types. I think this is a good approach. It should be worded in a way it makes sure that people can use query parameters as they like, as long as they don't implement any of the listed if=3D/rt=3D values and conflict with those names; maybe even along the lines of "This registry documents query parameters used by particular interfaces or resource types. Registering a specification's query parameters in it allows applications to simultaneously implement different interfaces without parameter name conflicts". It's still problematic w/rt RFC7320 (due to which we don't hardcode /rd [1]) section 2.4 [2], but should resolve any qualms about CoAP extensions restricting applications'/owners' freedom to pick their own query parameters. Best regards Christian [1]: https://mailarchive.ietf.org/arch/msg/core/X6Fv5NZYCuPDEPkIcJ0b-0UdA7s [2]: If I read it correctly, we should allow even pagination etc to happen as specified by the server, but that'd require URI template or similar capabilities we're probably not ready to mandate in constrained clients. --=20 Yesterday is history, tomorrow is a mystery, and today is a gift. That is why it is called the present. -- ancient saying --aosku2bkc2znyq6s Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAljCXgUACgkQOY0REtOk veEW+Q/8CsgRNCycBXwTNAgyoWlbFFhPwghQBLqG21uRmXaskk9Pe52Zso4XGjdZ RIBTYj8lOVHh76TXytRPq1kF3+Yv29SKyn7sjmsPFhytYDbFjUz99GdTVxLmXyAh 4jPfARkKMMYufYFNTm7NdfjFLWbwjYRRSW+kVzxbgREef5Skhmxl/9FH6mpVmQoU wnPyKntsVlCQVYVLDrR7SSvIl04Q9VNqFi1rvgC6jjlOy6DStC4bHVcGKq5UEq2C CpNOdQObir4Vgi6MXeLQmtKvylXgpCw40h/VZbxyIGSTD4vSvCtin8MgOhUc8cSL URMdHAwg7/MFUftDg46UIZ1WGZcJH2TP0dZuF6pFrN58ZQ7GgyLZKhHxO4Q6/y0g 4jeQfqd9IR8i8WWjYGOeHANzKhMft32iy1Ssfx51xh58hJeD0d/EWOweyzjJR6Zn 0PD4bEKHJFS22c1rwY2DPMwGb9AAOzyxh3d6jYq4TMEz/YffwAOxgU/aNu8z9K/C x4MPuv8NrpPAGP75GNDIT9JJZwVGPoss8h+M6PcHgp4Wpmtu2Pzzx9DTiegYpc88 /k764Wj9fc2V6Kwuh0m2wiC98GfrHkh1we4tpFWEnvvuxrvyLGSW7jG54wDVmFl1 FH3Bru3LMMbv05puCgV8OAnCHjIyR/J9zyUBHRQaegxn20sJMMQ= =BOca -----END PGP SIGNATURE----- --aosku2bkc2znyq6s-- From nobody Fri Mar 10 02:02:35 2017 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 3E070129875 for ; Fri, 10 Mar 2017 02:02:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01kotwBY61vA for ; Fri, 10 Mar 2017 02:02:32 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D58C3129871 for ; Fri, 10 Mar 2017 02:02:31 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v2AA2Niu004462; Fri, 10 Mar 2017 11:02:24 +0100 (CET) Received: from aung.tzi.org (unknown [134.102.172.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vfjVR6RkFzDHLy; Fri, 10 Mar 2017 11:02:23 +0100 (CET) From: Olaf Bergmann To: Christian =?utf-8?Q?Ams=C3=BCss?= References: <20170303173229.uj7av3xia4prxku3@hephaistos.amsuess.com> <20170306150622.mxhuggsfaojso4xv@hephaistos.amsuess.com> Date: Fri, 10 Mar 2017 11:02:23 +0100 In-Reply-To: <20170306150622.mxhuggsfaojso4xv@hephaistos.amsuess.com> ("Christian \=\?utf-8\?Q\?Ams\=C3\=BCss\=22's\?\= message of "Mon, 6 Mar 2017 16:06:22 +0100") Message-ID: <874lz1e9g0.fsf@aung.informatik.uni-bremen.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "core@ietf.org" Subject: Re: [core] pre-draft: Request-Tag X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 10:02:34 -0000 Hi Christian, (I have not been following this discussion, so please be patient if I am opening a can or worms here that has alreading been discussed in length...) Christian Ams=C3=BCss writes: > * CoAP over DTLS question: How does CoAP over DTLS deal with delayed > PUTs? As I see it (but not having implemented CoAP over DTLS myself > yet), the same attack as described on OSCOAP can be carried out on > DTLS too, as long as it happens inside the replay window. Worse yet, > as DTLS sequence numbers vary between retransmits of the same message > ID (and thus block request), the application might not even notice > that a package was "blackholed". I guess by "blackholed" you mean an artifically created 100 % packet loss? (If not you can stop reading here.) > (To spare you the lookup, the attack sequence is: > > Client POSTs "incarcerate" (block 0, more to come). > Server returns 2.31 Continue. > Client POSTs "valjean" (block 1, end of request), but > MITM blackholes the request (and subsequent retransmits) for further us= e. > Later, Client POSTs "promote" (block 0, more to come). > Server returns 2.31 Continue. > MITM injects the previously stored "valjean" package. > Server duefully promotes Valjean. I do not see any problem here where securing CoAP as a transfer protocol could be of any use. And DTLS doesn't. To understand why this is not a problem, take a step back and look what happens in your scenario: 1. Client sends a request to change the Server state to X. The server's response tells Client that the server is now in state X. 2. Client sends a request to change the Server state to Y. Client never gets a response and thus does not know whether Server is in state Y (or X' because something else has happened since step 1.) 3. At some time, Client stops waiting for a response and discards its transaction state. 4. Even later, Client sends a request to change the Server state to Z. The server's response tells the Client that the server is now in state Z. 5. The server receives a request to change its state to Y. In absence of an attacker, the very same scenario would occur if, for some reason, the request in 2 would have taken a very long time and thus would have been delivered out of order. Both, Client and Server must be aware that this might happen. A robust application layer protocol thus would have to be designed in a way that you could detect (and possibly resolve) this situation. CoAP as a REST-based transfer protocol does not help here. (What you are suggesting is to invent a protocol element with application layer semantics that helps.) And by the way: Proper authorization could help mitigating the effects of this scenario/attack. That is the reason why the DCAF proposal had made extensive use of timestamps. Gr=C3=BC=C3=9Fe Olaf From nobody Fri Mar 10 02:37:08 2017 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 445D312944A for ; Fri, 10 Mar 2017 02:37:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPHDi-SMlZoh for ; Fri, 10 Mar 2017 02:37:05 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA3DD129431 for ; Fri, 10 Mar 2017 02:37:05 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 56EC74685C; Fri, 10 Mar 2017 11:37:03 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 2AB2EDB; Fri, 10 Mar 2017 11:36:47 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 8C4CD439; Fri, 10 Mar 2017 11:36:46 +0100 (CET) Received: (nullmailer pid 25630 invoked by uid 1000); Fri, 10 Mar 2017 10:36:44 -0000 Date: Fri, 10 Mar 2017 11:36:44 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Olaf Bergmann Message-ID: <20170310103644.7bqzppdz7yhtaa3k@hephaistos.amsuess.com> References: <20170303173229.uj7av3xia4prxku3@hephaistos.amsuess.com> <20170306150622.mxhuggsfaojso4xv@hephaistos.amsuess.com> <874lz1e9g0.fsf@aung.informatik.uni-bremen.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sbasgm5e5advwtzs" Content-Disposition: inline In-Reply-To: <874lz1e9g0.fsf@aung.informatik.uni-bremen.de> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Cc: "core@ietf.org" Subject: Re: [core] pre-draft: Request-Tag X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 10:37:07 -0000 --sbasgm5e5advwtzs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Olaf, thanks for your input. On Fri, Mar 10, 2017 at 11:02:23AM +0100, Olaf Bergmann wrote: > I guess by "blackholed" you mean an artifically created 100 % packet > loss? (If not you can stop reading here.) Stored for further use, and then artificially lost along with all retransmission attempts. > I do not see any problem here where securing CoAP as a transfer protocol > could be of any use. And DTLS doesn't. To understand why this is not a > problem, take a step back and look what happens in your scenario: >=20 > 1. Client sends a request to change the Server state to X. This would be acceptable if we were talking about a PUT (especially when processing is not atomic, ie. does not create a 2.13 responses). In a POST request with atomic processing, the "but there is a valid request to put part 2 the resource in state Y" doesn't hold. > In absence of an attacker, the very same scenario would occur if, for > some reason, the request in 2 would have taken a very long time and thus > would have been delivered out of order. Yes, it would; but it would need to lose all retransmission attempts that either have the same sequence number (in the OSCOAP case) or the same message ID (in the DTLS or unsecured case). > Both, Client and Server must be aware that this might happen. A robust > application layer protocol thus would have to be designed in a way that > you could detect (and possibly resolve) this situation. CoAP as a > REST-based transfer protocol does not help here. (What you are > suggesting is to invent a protocol element with application layer > semantics that helps.) CoAP with blockwise advertises the possibility to process larger-than-MTU payloads (ie. bodies) as a whole. At least in OSCOAP, there is the expectation to obtain a blockwise'd body in a way that it is cryptographically secured to originate from the given peer. Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --sbasgm5e5advwtzs Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAljCgbcACgkQOY0REtOk veEQjg//cxhm1iwky4OiOiCOLwTH22RcolRlgX/Yv5KN0rnv4HUfyulxNFagtlfE E/4aITtuFelRJBiOjhnWhblEc/q7xKsfiKmhSjA8+69gB6JU9l+sQPILyWuVO7F6 rIJCrduuXe0Zm2LAMpNi8zi0EfLlj7bSqCagfRXVZwGBJyKY+foXxjQQs17FMypV +9AMVrH77YYIa6fcj3ohjyS3sSd1wMv5yWc+nKe3NUoUT58QBMGihLnSol/qZ5RC 4mZzDH64a048TTxxpzj1UggVUKKxMxrhnuoRf66EUWmTJM+HJXA7brvavknu5amF BVyXwKBk2PeH20bQepzt+AS54XWA7fJzvyAexBli3Wn94PcOIQZDsaMsOJvlMIkg chzJREx7TTWWDhM6i7k9JlfKpgKJNWdojogsm24PhJr1IVVVSiBr/+W1NoE5aK18 VLFoA9YKggzMJZZgp1nInFX50rikQFbhFa6dQJV9q0gFryID9HFVqZHSt+sHOXfb MdJHv6WxBAJt24NnqKP3Yb5he3uF7jG6XevVXswGXItg7/tBgzTOa8v1ol0KoQ9y cnDPFVWi/Jx4RjgV9aSSyK4/1v6nBWpW4rEYex6jzOeB/t3S4o5AMms2bJgUnTas 6AIFNd5d4180RY6xBUm+cHp3uBgG9nrW31aW1iZ18R1eucwdbfM= =Uxit -----END PGP SIGNATURE----- --sbasgm5e5advwtzs-- From nobody Fri Mar 10 02:52:25 2017 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 14D9712987C for ; Fri, 10 Mar 2017 02:52:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 E4Xo3casdFGU for ; Fri, 10 Mar 2017 02:52:22 -0800 (PST) Received: from buffalo.u-blox.com (buffalo.u-blox.com [195.34.89.137]) by ietfa.amsl.com (Postfix) with SMTP id 11907129428 for ; Fri, 10 Mar 2017 02:52:21 -0800 (PST) Received: from mail_filter (localhost [127.0.0.1]) by buffalo.u-blox.com (PF_LO_10026) with ESMTP id 6846115F6A2 for ; Fri, 10 Mar 2017 11:52:19 +0100 (CET) Received: from ASSP.nospam (localhost [127.0.0.1]) by buffalo.u-blox.com (Postfix) with ESMTP id 4982E15F695 for ; Fri, 10 Mar 2017 11:52:19 +0100 (CET) Received: from unknown ([127.0.0.1] helo=anyhost.local) by ASSP.nospam with SMTP (2.4.7); 10 Mar 2017 11:52:19 +0100 From: =?windows-1252?Q?Mojan_Mohajer?= To: =?windows-1252?Q?core?= Date: Fri, 10 Mar 2017 11:52:19 +0100 Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-Mailer: Zarafa 7.1.14-51822 Thread-Index: AdKZiTL8L+CXcNrbShOnUomNtQ4mag== Message-Id: X-Assp-Version: 2.4.7(16004) on ASSP.nospam X-Assp-ID: ASSP.nospam 43139-22422 X-Assp-Session: 196A0A38 (mail 1) X-Assp-Original-Subject: Questions/comments on draft-ietf-core-dynlink-02 X-Virus-Scanned: clamav-milter 0.99.2 at buffalo X-Virus-Status: Clean Archived-At: Subject: [core] Questions/comments on draft-ietf-core-dynlink-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 10:52:24 -0000 1)The latest draft has renamed "gt" and "lt" attributes to "gth" and "lth" respectively. Has any consideration been given to the impact of this name change on other SDOs and their specifications where CoAP and these attributes are used. For example, OMA LwM2M v1.0 which has recently been formally released uses CoAP as its application layer protocol and these attributes for notification purposes. 2) Section 4.2 which covers resource observation attributes (pmin, pmax, st, =85) states that that: =85=94These query parameters MUST be treated as resources that are read using GET and updated using PUT, and MUST NOT be included in the Observe request=94 =85. However, looking at newly added Annex A which provides observation examples, these observation attributes are passed as query parameters of a Get request with Observe option set to 0. There seems to be some contradiction between the text in section 4.2 and the example in Annex A. Best Regards, Mojan From nobody Fri Mar 10 07:54:32 2017 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 909B912965C for ; Fri, 10 Mar 2017 07:54:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1I0U8AVJDjg for ; Fri, 10 Mar 2017 07:54:30 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A96412965B for ; Fri, 10 Mar 2017 07:54:29 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v2AFsLmn004434; Fri, 10 Mar 2017 16:54:21 +0100 (CET) Received: from aung.tzi.org (pD9F61D3E.dip0.t-ipconnect.de [217.246.29.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vfsJX6ngbzDHVh; Fri, 10 Mar 2017 16:54:20 +0100 (CET) From: Olaf Bergmann To: Christian =?utf-8?Q?Ams=C3=BCss?= References: <20170303173229.uj7av3xia4prxku3@hephaistos.amsuess.com> <20170306150622.mxhuggsfaojso4xv@hephaistos.amsuess.com> <874lz1e9g0.fsf@aung.informatik.uni-bremen.de> <20170310103644.7bqzppdz7yhtaa3k@hephaistos.amsuess.com> Date: Fri, 10 Mar 2017 16:54:20 +0100 In-Reply-To: <20170310103644.7bqzppdz7yhtaa3k@hephaistos.amsuess.com> ("Christian \=\?utf-8\?Q\?Ams\=C3\=BCss\=22's\?\= message of "Fri, 10 Mar 2017 11:36:44 +0100") Message-ID: <87zigtunyr.fsf@aung.informatik.uni-bremen.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "core@ietf.org" Subject: Re: [core] pre-draft: Request-Tag X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 15:54:31 -0000 Hi Christian, Christian Ams=C3=BCss writes: >> 1. Client sends a request to change the Server state to X. > > This would be acceptable if we were talking about a PUT (especially when > processing is not atomic, ie. does not create a 2.13 responses). > > In a POST request with atomic processing, the "but there is a valid > request to put part 2 the resource in state Y" doesn't hold. No, you are putting to much application semantics into this reasoning. First of all, the initial request (PUT or POST) is a REST operation that changes state in the server. There is no "but we want do something else in the future" on that layer.=20 > CoAP with blockwise advertises the possibility to process > larger-than-MTU payloads (ie. bodies) as a whole. At least in OSCOAP, > there is the expectation to obtain a blockwise'd body in a way that it > is cryptographically secured to originate from the given peer. Which it does as you have described. My personal opinion is that the freshness issue in your scenario is not something that must be solved in the transfer protocol. Gr=C3=BC=C3=9Fe Olaf From nobody Fri Mar 10 12:12:52 2017 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 434B9129440 for ; Fri, 10 Mar 2017 12:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E73_oYX7hfOe for ; Fri, 10 Mar 2017 12:12:49 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (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 35C721293FB for ; Fri, 10 Mar 2017 12:12:49 -0800 (PST) Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id C72AD2B8D4CE9; Fri, 10 Mar 2017 20:12:44 +0000 (GMT) Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id v2AKClRG016013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Mar 2017 20:12:47 GMT Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id v2AKCl8o021258 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Mar 2017 20:12:47 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.74]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0301.000; Fri, 10 Mar 2017 15:12:47 -0500 From: "Carey, Timothy (Nokia - US)" To: Mojan Mohajer , core Thread-Topic: [core] Questions/comments on draft-ietf-core-dynlink-02 Thread-Index: AQHSmdkK7VgKxW94xUGnyHuxQn3LpaGOgLHQ Date: Fri, 10 Mar 2017 20:12:45 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A8AA931@US70UWXCHMBA05.zam.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [core] Questions/comments on draft-ietf-core-dynlink-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 20:12:51 -0000 Mojan, I certainly agree - we should be careful about renaming these attributes; t= he attributes have been around for a while and are used by OMA for sure. Yes you are indeed correct the examples do not align with normative languag= e of section 4.2 - this again can cause problems in other SDOs. BR, Tim -----Original Message----- From: Mojan Mohajer [mailto:mojan.mohajer@u-blox.com]=20 Sent: Friday, March 10, 2017 4:52 AM To: core Subject: [core] Questions/comments on draft-ietf-core-dynlink-02 1)The latest draft has renamed "gt" and "lt" attributes to "gth" and "lth" = respectively. Has any consideration been given to the impact of this name c= hange on other SDOs and their specifications where CoAP and these attribute= s are used. For example, OMA LwM2M v1.0 which has recently been formally re= leased uses CoAP as its application layer protocol and these attributes for= notification purposes. 2) Section 4.2 which covers resource observation attributes (pmin, pmax, st= , ...) states that that: ..."These query parameters MUST be treated as reso= urces that are read using GET and updated using PUT, and MUST NOT be includ= ed in the Observe request" .... However, looking at newly added Annex A which provides observation examples= , these observation attributes are passed as query parameters of a Get requ= est with Observe option set to 0. There seems to be some contradiction betw= een the text in section 4.2 and the example in Annex A. Best Regards, Mojan From nobody Sun Mar 12 06:05:08 2017 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 9F91D12944A for ; Sun, 12 Mar 2017 06:05:06 -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] 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 EKFnAKjdmEDX for ; Sun, 12 Mar 2017 06:05:05 -0700 (PDT) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EC68129422 for ; Sun, 12 Mar 2017 06:05:04 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 032AE46689; Sun, 12 Mar 2017 14:05:02 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id A840ED2; Sun, 12 Mar 2017 14:05:00 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id A6FD4406; Sun, 12 Mar 2017 14:04:59 +0100 (CET) Received: (nullmailer pid 17165 invoked by uid 1000); Sun, 12 Mar 2017 13:04:58 -0000 Date: Sun, 12 Mar 2017 14:04:58 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: =?iso-8859-1?Q?G=F6ran?= Selander , Jim Schaad , Francesca Palombini Message-ID: <20170312130458.qwq5vykp3iil4kum@hephaistos.amsuess.com> References: <20170303173229.uj7av3xia4prxku3@hephaistos.amsuess.com> <20170306150622.mxhuggsfaojso4xv@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="esc4tlss2s33h4jv" Content-Disposition: inline In-Reply-To: <20170306150622.mxhuggsfaojso4xv@hephaistos.amsuess.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Cc: "core@ietf.org" Subject: Re: [core] pre-draft: Request-Tag X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 12 Mar 2017 13:05:06 -0000 --esc4tlss2s33h4jv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello OSCOAP people, > * CoAP over DTLS question: How does CoAP over DTLS deal with delayed > PUTs? I've received word back on and off list from DTLS implementors (Olaf and Matthias), and their take on this sounds to me rather that blocks being misassignable between blockwise requests is more of an application issue than something blockwise and crypto should protect us from. On the other hand, the last published draft version did include preparations for chaining inner-blockwise requests into a cryptographically secured total. Before we push further the "how", is there agreement among the OSCOAP authors that we want a way to protect the body of a blockwise request, even in the light of Olaf's comments? (My personal take on this is that there are protection-worthy REST transactions atop the blockwise layer, and that blockwise mode itself knowingly sacrifices complete RESTfulness in favor of slimness (that's how the "same endpoint" language gets in there, but it avoids additional round trips and allocations for creation of a per-transaction resource). Thus, I think that it'd be within the scope of the OSCOAP layer to link those messages cryptographically -- but then again, I'm not too firm with the theoretical background of REST.) Best regards Christian --=20 I shouldn't have written all those tank programs. -- Kevin Flynn --esc4tlss2s33h4jv Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAljFR3YACgkQOY0REtOk veGtnA/9F3e0i3ly20wTx1ylJkZt2o3xYqKOrk2RTH505wRC9VioNgXn6pi3SzTV X0mByZVb2xiSnrfvZIwrFNvMLQZMLeX/x9qNt5zQ3zop8Mae6PrNrQIBrcDB2IBm fz4giMkFONZNfJ+Xc+iJAUDKXUNK8ZPGsHZrBoj9bGVNDn3OZBAt1g2hNC6TlVR/ YiycffGLmn3f5rYbywc4n1Gq1Ymi8DgUIkC6dDZUVAA/f0u3QIAC6zY30KEL4Jae YQEmZNquYmrpbHRbNxJPh4fumYzzyxGeiXQIWcdwS18Y2Z++laGyWo5mJ2QV/qnT kgeMBeZ5imzA/yyTCG96jHrGl/XOXn6yTqUyPzxloRgBX82DXgcuEuxTWpsNzubE W8YcpYi7mEzTEbgYLOLm6953tuiZkv8mB7eg0jCzIaGsMzrdYafWS4nBO8zAxitp hP/S/gsN2Gnrqr7enlkoRrqpWkppqvqLea2wA+P8vorkRa2VgjprWLD5sw6GQV6+ GL9n1IHG2nr03X438+k8TQbklFZkzF6D6JkWgE34kyPLQQw5R9FIkRoH+VmU87A7 HsGmymzGjlzsP/ybSckW4fLlgWU3o6E3GDijAGnu8j8nq2CZNS6v3Nxscwk24yBW i35/KNzgl8kb9FfmLOdmAoGFwtKIBgm4txBatZZtL1x7QStUByk= =/5pn -----END PGP SIGNATURE----- --esc4tlss2s33h4jv-- From nobody Sun Mar 12 07:38:35 2017 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 E0FB212947C for ; Sun, 12 Mar 2017 07:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 aK-2wfk5gYEv for ; Sun, 12 Mar 2017 07:38:33 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 AA043120724 for ; Sun, 12 Mar 2017 07:38:32 -0700 (PDT) X-AuditID: c1b4fb30-f6fff70000006a1c-85-58c55d650d10 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by (Symantec Mail Security) with SMTP id AB.76.27164.56D55C85; Sun, 12 Mar 2017 15:38:30 +0100 (CET) Received: from ESESSMB107.ericsson.se ([169.254.7.76]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0319.002; Sun, 12 Mar 2017 15:38:29 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= , "Jim Schaad" , Francesca Palombini Thread-Topic: [core] pre-draft: Request-Tag Thread-Index: AQHSlEQryuFBmaIKF027d9Ie4Dq776GH3SIAgAlMEgCAACrigA== Date: Sun, 12 Mar 2017 14:38:29 +0000 Message-ID: References: <20170303173229.uj7av3xia4prxku3@hephaistos.amsuess.com> <20170306150622.mxhuggsfaojso4xv@hephaistos.amsuess.com> <20170312130458.qwq5vykp3iil4kum@hephaistos.amsuess.com> In-Reply-To: <20170312130458.qwq5vykp3iil4kum@hephaistos.amsuess.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-ID: <0CB24748195CC744B5FD8514FDE10FB3@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFIsWRmVeSWpSXmKPExsUyM2K7h25a7NEIgxlvLC2WX3jOYrHv7Xpm i9XTv7M5MHtsnDOdzWPr/rtMHkuW/GQKYI7isklJzcksSy3St0vgypi/+SVLwQ/RilkzFBsY N4h2MXJySAiYSHxdspq5i5GLQ0hgHaNE7549LBDOYkaJb8d/sIJUsQm4SDxoeMQEkhARWM0o 8XbJYkaQBLOAssTx2YfBioQFtCR+7FzIBGKLCGhL7H1+Hsp2knjeehPMZhFQlfjxpQWsnlfA QuLJkQtsENt2MUpcX/QHLMEp4Crxfu8+FhCbUUBM4vupNUwQy8Qlbj2ZzwRxt4DEkj3nmSFs UYmXj/+B9YoK6Eksf74GKq4k0bjkCVCcA6hXU2L9Ln2IMdYSX66vYYWwFSWmdD9kh7hHUOLk zCcsExjFZyHZNguhexaS7llIumch6V7AyLqKUbQ4tTgpN93ISC+1KDO5uDg/Ty8vtWQTIzAG D275bbCD8eVzx0OMAhyMSjy8Bp5HIoRYE8uKK3MPMUpwMCuJ8JaGH40Q4k1JrKxKLcqPLyrN SS0+xCjNwaIkzmu28n64kEB6YklqdmpqQWoRTJaJg1OqgTHxS9Oh3aUSNozC6df+Pa/9uX3y HZH1WjyxoW2bxdbtSrBdvOBljPfFpKgN852CZ9ZO7FnB6HP2cO7CsGsGm/X4v+yOXlx8Uyjg Z2COQmSF4V5VpdnrxXfVPn9+WXrrdaWDd1+avGWUnFW+J9sm+8W5XLZtJyum19vt7Mi4VCPK k/4+K9+rUE2JpTgj0VCLuag4EQD5stPivQIAAA== Archived-At: Cc: "core@ietf.org" Subject: Re: [core] pre-draft: Request-Tag X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 12 Mar 2017 14:38:34 -0000 SGkgQ2hyaXN0aWFuLA0KDQpJ4oCZbSBpbiBmYXZvdXIgb2Ygc3BlY2lmeWluZyBob3cgdG8gZGlz YW1iaWd1YXRlIG11bHRpcGxlIGNvbmN1cnJlbnQgYmxvY2sNCmZyYWdtZW50YXRpb25zLCBhbmQg eW91ciBwcm9wb3NhbCBzZWVtcyBlZmZpY2llbnQgZnJvbSB0aGUgcG9pbnQgb2Ygdmlldw0Kb2Yg Zml0dGluZyBpbnRvIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucy4NCg0KU28gSSB0aGluayB5b3Ug c2hvdWxkIHN1Ym1pdCB0aGF0LCBhbmQgbGV0IHVzIGhhdmUgYSBkaXNjdXNzaW9uIHdoZXJlIHRo aXMNCmZlYXR1cmUgbWF5IGFsc28gYmUgdXNlZnVsIChvdXRzaWRlIE9TQ09BUCwgd2hlcmUgaXQg aXMgZGVmaW5pdGVseQ0KdXNlZnVsKS4gRXZlbiBpZiB0aGUgaXNzdWUgaXMgdXAgdG8gdGhlIGFw cGxpY2F0aW9uIHRvIGhhbmRsZSwgZ2l2ZW4gdGhhdA0KdGhpcyBmZWF0dXJlIGlzIHNwZWNpZmll ZCBpdCBpcyBlYXN5IGZvciBhcHBsaWNhdGlvbnMgdG8ganVzdCB1c2Ugd2l0aG91dA0KaGF2aW5n IHRvIHJlLWludmVudCBpdC4NCg0KR8O2cmFuDQoNCg0KDQpPbiAyMDE3LTAzLTEyIDE0OjA0LCAi Q2hyaXN0aWFuIEFtc8O8c3MiIDxjLmFtc3Vlc3NAZW5lcmd5aGFydmVzdGluZy5hdD4NCndyb3Rl Og0KDQo+SGVsbG8gT1NDT0FQIHBlb3BsZSwNCj4NCj4+ICogQ29BUCBvdmVyIERUTFMgcXVlc3Rp b246IEhvdyBkb2VzIENvQVAgb3ZlciBEVExTIGRlYWwgd2l0aCBkZWxheWVkDQo+PiAgIFBVVHM/ DQo+DQo+SSd2ZSByZWNlaXZlZCB3b3JkIGJhY2sgb24gYW5kIG9mZiBsaXN0IGZyb20gRFRMUyBp bXBsZW1lbnRvcnMgKE9sYWYgYW5kDQo+TWF0dGhpYXMpLCBhbmQgdGhlaXIgdGFrZSBvbiB0aGlz IHNvdW5kcyB0byBtZSByYXRoZXIgdGhhdCBibG9ja3MgYmVpbmcNCj5taXNhc3NpZ25hYmxlIGJl dHdlZW4gYmxvY2t3aXNlIHJlcXVlc3RzIGlzIG1vcmUgb2YgYW4gYXBwbGljYXRpb24gaXNzdWUN Cj50aGFuIHNvbWV0aGluZyBibG9ja3dpc2UgYW5kIGNyeXB0byBzaG91bGQgcHJvdGVjdCB1cyBm cm9tLg0KPg0KPk9uIHRoZSBvdGhlciBoYW5kLCB0aGUgbGFzdCBwdWJsaXNoZWQgZHJhZnQgdmVy c2lvbiBkaWQgaW5jbHVkZQ0KPnByZXBhcmF0aW9ucyBmb3IgY2hhaW5pbmcgaW5uZXItYmxvY2t3 aXNlIHJlcXVlc3RzIGludG8gYQ0KPmNyeXB0b2dyYXBoaWNhbGx5IHNlY3VyZWQgdG90YWwuDQo+ DQo+QmVmb3JlIHdlIHB1c2ggZnVydGhlciB0aGUgImhvdyIsIGlzIHRoZXJlIGFncmVlbWVudCBh bW9uZyB0aGUgT1NDT0FQDQo+YXV0aG9ycyB0aGF0IHdlIHdhbnQgYSB3YXkgdG8gcHJvdGVjdCB0 aGUgYm9keSBvZiBhIGJsb2Nrd2lzZSByZXF1ZXN0LA0KPmV2ZW4gaW4gdGhlIGxpZ2h0IG9mIE9s YWYncyBjb21tZW50cz8NCj4NCj4oTXkgcGVyc29uYWwgdGFrZSBvbiB0aGlzIGlzIHRoYXQgdGhl cmUgYXJlIHByb3RlY3Rpb24td29ydGh5IFJFU1QNCj50cmFuc2FjdGlvbnMgYXRvcCB0aGUgYmxv Y2t3aXNlIGxheWVyLCBhbmQgdGhhdCBibG9ja3dpc2UgbW9kZSBpdHNlbGYNCj5rbm93aW5nbHkg c2FjcmlmaWNlcyBjb21wbGV0ZSBSRVNUZnVsbmVzcyBpbiBmYXZvciBvZiBzbGltbmVzcyAodGhh dCdzDQo+aG93IHRoZSAic2FtZSBlbmRwb2ludCIgbGFuZ3VhZ2UgZ2V0cyBpbiB0aGVyZSwgYnV0 IGl0IGF2b2lkcyBhZGRpdGlvbmFsDQo+cm91bmQgdHJpcHMgYW5kIGFsbG9jYXRpb25zIGZvciBj cmVhdGlvbiBvZiBhIHBlci10cmFuc2FjdGlvbiByZXNvdXJjZSkuDQo+VGh1cywgSSB0aGluayB0 aGF0IGl0J2QgYmUgd2l0aGluIHRoZSBzY29wZSBvZiB0aGUgT1NDT0FQIGxheWVyIHRvIGxpbmsN Cj50aG9zZSBtZXNzYWdlcyBjcnlwdG9ncmFwaGljYWxseSAtLSBidXQgdGhlbiBhZ2FpbiwgSSdt IG5vdCB0b28gZmlybQ0KPndpdGggdGhlIHRoZW9yZXRpY2FsIGJhY2tncm91bmQgb2YgUkVTVC4p DQo+DQo+QmVzdCByZWdhcmRzDQo+Q2hyaXN0aWFuDQo+DQo+LS0gDQo+SSBzaG91bGRuJ3QgaGF2 ZSB3cml0dGVuIGFsbCB0aG9zZSB0YW5rIHByb2dyYW1zLg0KPiAgLS0gS2V2aW4gRmx5bm4NCg0K From nobody Sun Mar 12 12:53:20 2017 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 55D931294C8 for ; Sun, 12 Mar 2017 12:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 gj7OHpAbr3Fr for ; Sun, 12 Mar 2017 12:53:16 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1CD91294C7 for ; Sun, 12 Mar 2017 12:53:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2054; q=dns/txt; s=iport; t=1489348396; x=1490557996; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=gjYfynJGkQQPYWGDs1lzPCim9NqYx89Dc3LEdTAzGHA=; b=dcK0oT032WfO23+noV+o8eMz3CL6An3YmCHtsybBSsraFrrd7qb7kFRa 92q5BFFuJaOWKsEIpibHXNfn3Q6Qj53z9+bTj5a37I/muiUvs/OAl2zUn D8tl9SEd6VVuDYz18iZ5f3+K/yfizTUPbsSIvUTk5r9KmvTmtK57K+cyk c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B6AQD/pcVY/4MNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgycqYYEKB4NZig6RTpU7gg4qhXgCGoInPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?VAQEBAQIBIxFFBQsCAQgYAgImAgICMBUQAgQOBYl4CA6xK4ImilcBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEYBYELh0iCaoQ+FoMGLoIxBYkgkyEBhnWLQ5EljyGEIQE?= =?us-ascii?q?fOIEEWBVSAYZFdQGIYIENAQEB?= X-IronPort-AV: E=Sophos;i="5.36,154,1486425600"; d="scan'208";a="397062895" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Mar 2017 19:53:15 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v2CJrF7K026939 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 12 Mar 2017 19:53:15 GMT Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 12 Mar 2017 15:53:15 -0400 Received: from xch-rtp-004.cisco.com ([64.101.220.144]) by XCH-RTP-004.cisco.com ([64.101.220.144]) with mapi id 15.00.1210.000; Sun, 12 Mar 2017 15:53:14 -0400 From: "Cullen Jennings (fluffy)" To: =?utf-8?B?QXJpIEtlcsOkbmVu?= Thread-Topic: [core] URI fragment use for SenML Thread-Index: AQHSm2pJwO9NAfnOIkqrrix4p2n4+g== Date: Sun, 12 Mar 2017 19:53:14 +0000 Message-ID: <8ED3AFE4-B0D5-4FE6-9D47-1C7C79E2B0AD@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="utf-8" Content-ID: <29448FCB568E864EB64D81A388CA4B66@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-core-senml@tools.ietf.org" , core Subject: Re: [core] URI fragment use for SenML X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 12 Mar 2017 19:53:18 -0000 DQoNCj4gT24gTm92IDE3LCAyMDE2LCBhdCAxOjU1IEFNLCBBcmkgS2Vyw6RuZW4gPGFyaS5rZXJh bmVuQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSBhbGwsDQo+IA0KPiBXaGVuIHVwZGF0 aW5nIHRoZSBUMlRSRyBSRVNUZnVsIGRlc2lnbiBkcmFmdCB3ZSBkaXNjdXNzZWQgcm9sZSBvZiBV UkkgZnJhZ21lbnRzIGluIElvVCBzY2VuYXJpb3MgYW5kIHJlYWxpemVkIHRoYXQgdGhpcyBjb3Vs ZCBiZSB1c2VmdWwgZm9yIFNlbk1MIHRvbyBmb3IgYWRkcmVzc2luZyBwYXJ0cyBvZiBhIFNlbk1M IHBhY2suDQo+IA0KPiBJdCdzIGdvb2QgdG8gbm90ZSB0aGF0IFVSSSBmcmFnbWVudHMgYXJlIGZv ciBjbGllbnQgc2lkZSBwcm9jZXNzaW5nIG9ubHkgYW5kIG5ldmVyIHNlbnQgb24gdGhlIHdpcmUu IFNvIHRoZSBzZXJ2ZXIgd291bGQgc3RpbGwgc2VuZCBhIGZ1bGwgcmVwcmVzZW50YXRpb24sIGJ1 dCBhIGZyYWdtZW50IGlkZW50aWZpZXIgYWxsb3dzIGFwcGxpY2F0aW9ucyBvbiB0aGUgY2xpZW50 IHRvIHJlZmVyIHRvIHNwZWNpZmljIHBhcnRzIG9mIFNlbk1MIHBhY2tzLg0KPiANCj4gQSBwb3Rl bnRpYWwgd2F5IHRvIGltcGxlbWVudCB0aGlzIGlzIHRvIHVzZSB0aGUgUkZDIDcxMTEgKCJVUkkg RnJhZ21lbnQgSWRlbnRpZmllcnMgZm9yIHRoZSB0ZXh0L2NzdiBNZWRpYSBUeXBlIikgcm93LXBh cnQgc3R5bGUgKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MTExI3NlY3Rpb24tMi4x KS4gRm9yIGV4YW1wbGUsIG9uIGEgU2VuTUwgcGFjayBmcm9tICJzZW5zb3JzL3RlbXAiLCBvbmUg Y291bGQgYWRkcmVzczoNCj4gDQo+IDNyZCByZWNvcmQ6IHNlbnNvcnMvdGVtcCNyZWM9Mw0KPiBS ZWNvcmRzIDQgdG8gNzogc2Vuc29ycy90ZW1wI3JlYz00LTcNCj4gUmVjb3JkcyBmcm9tIDQgdG8g bGFzdDogc2Vuc29ycy90ZW1wI3JlYz00LSoNCj4gDQo+IFRvIGhhbmRsZSBiYXNlIHZhbHVlcywg d2UgY291bGQgc3BlY2lmeSBzb21ldGhpbmcgYWxvbmcgdGhlIGxpbmVzIG9mICJGcmFnbWVudCBN VVNUIHJlc29sdmUgKGkuZS4sIGZpbGwgYmFzZSB2YWx1ZXMpIHRvIHRoZSBzYW1lIHZhbHVlcyBh cyB0aGUgZ2l2ZW4gcmFuZ2UgaW4gdGhlIHdob2xlIHBhY2sgd291bGQiLg0KPiANCj4gSXMgdGhp cyBzb21ldGhpbmcgeW91IHdvdWxkIGNvbnNpZGVyIHVzZWZ1bD8gU2hvdWxkIGl0IGJlIGFkZGVk IHRvIHRoZSBTZW5NTCBzcGVjIG1lZGlhIHR5cGUgZGVmaW5pdGlvbnM/DQo+IA0KDQoNCkknbSBz b3J0IG9mIHRyeWluZyB0byBmaWd1cmUgb3V0IHdoZXJlIHdlIHdvdWxkIHVzZSB0aGVzZXMgLSBp dCBzZWVtIG1vcmUgbGlrZSBxdWVyeSBzcGVjaWZpZXJzIHdpdGggPyBvbiBVUkxzIG1pZ2h0IGJl IG1vcmUgdXNlZnVsLiBJJ20gbm90IHN1cmUuIEJ1dCBlaXRoZXIgd2F5LCBJIHRoaW5rIEknZCBw cmVmZXIgdG8gZG8gdGhlbSBpbiBhbiBleHRlbnNpb24gc3BlYyBhbmQgbm90IHRoZSBiYXNlIFNl bk1MIHNwZWMuIA0KDQoNCg== From nobody Sun Mar 12 23:19:03 2017 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 249A5128B37 for ; Sun, 12 Mar 2017 23:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.332 X-Spam-Level: X-Spam-Status: No, score=-0.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, 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 MLWEMPDtCaE5 for ; Sun, 12 Mar 2017 23:19:00 -0700 (PDT) Received: from msh04.myshophosting.com (msh04.myshophosting.com [101.0.86.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 BBF1C12953C for ; Sun, 12 Mar 2017 23:19:00 -0700 (PDT) Received: from ppp118-209-171-106.lns20.mel8.internode.on.net ([118.209.171.106]:61483 helo=[192.168.1.22]) by msh04.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1cnJJp-000pIN-Dl for core@ietf.org; Mon, 13 Mar 2017 17:18:57 +1100 To: core@ietf.org References: <9966516C6EB5FC4381E05BF80AA55F77012A8AA931@US70UWXCHMBA05.zam.alcatel-lucent.com> From: Christian Groves Message-ID: <423e74ab-df2e-e11d-2525-346caee86bc1@gmail.com> Date: Mon, 13 Mar 2017 17:18:55 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A8AA931@US70UWXCHMBA05.zam.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh04.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gmail.com X-Get-Message-Sender-Via: msh04.myshophosting.com: authenticated_id: christian@kunstmade.com.au X-Authenticated-Sender: msh04.myshophosting.com: christian@kunstmade.com.au X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [core] Questions/comments on draft-ietf-core-dynlink-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 06:19:02 -0000 Hello Mojan and Tim, For the attribute renaming there was already discussion on the list about it and it seemed there was agreement to change the dynlink parameter and not the RD parameter. Usage by other SDOs was raised. My plan is to raise this issue in the upcoming Chicago meeting to see if we can get it resolved there. Thanks for pointing out the error in the examples. I'll fix it in the next version. Regards, Christian On 11/03/2017 7:12 AM, Carey, Timothy (Nokia - US) wrote: > Mojan, > > I certainly agree - we should be careful about renaming these attributes; the attributes have been around for a while and are used by OMA for sure. > > Yes you are indeed correct the examples do not align with normative language of section 4.2 - this again can cause problems in other SDOs. > > BR, > Tim > > -----Original Message----- > From: Mojan Mohajer [mailto:mojan.mohajer@u-blox.com] > Sent: Friday, March 10, 2017 4:52 AM > To: core > Subject: [core] Questions/comments on draft-ietf-core-dynlink-02 > > 1)The latest draft has renamed "gt" and "lt" attributes to "gth" and "lth" respectively. Has any consideration been given to the impact of this name change on other SDOs and their specifications where CoAP and these attributes are used. For example, OMA LwM2M v1.0 which has recently been formally released uses CoAP as its application layer protocol and these attributes for notification purposes. > > 2) Section 4.2 which covers resource observation attributes (pmin, pmax, st, ...) states that that: ..."These query parameters MUST be treated as resources that are read using GET and updated using PUT, and MUST NOT be included in the Observe request" .... > However, looking at newly added Annex A which provides observation examples, these observation attributes are passed as query parameters of a Get request with Observe option set to 0. There seems to be some contradiction between the text in section 4.2 and the example in Annex A. > > Best Regards, > Mojan > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From nobody Mon Mar 13 00:19:47 2017 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 1F6ED129424 for ; Mon, 13 Mar 2017 00:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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=augustcellars.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 k2ms9TgV1lYE for ; Mon, 13 Mar 2017 00:19:44 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81471126B6D for ; Mon, 13 Mar 2017 00:19:44 -0700 (PDT) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1489389581; h=from:subject:to:date:message-id; bh=ugL5qX/1i6WNlJMgIhuPTVxjVZKx4u8d75Ie75iyn6g=; b=DnqcHtWEVGAOSXTRD7n6WEE10gVMqfqMApOoMoWymTqrW6jHjIWrc8bEuzkNKtUnT4xLDR2AOcp XbAcSNnom+mojbSFAZnMMRFK9wfEZCi8d0eG4pWfcHSoiQJnUvF1JbG32rozH04znlojxauMrZTq4 vuJ5Fj17pd20mzLEg9xmbXrUVordcFFp+pRVs0G0ulhT0aOg1yw7x7fSrZakBF7VFk5KiYaBbXsPq zfXDMgglltHihxJGdERkqxy7UI+bGcrh1PSG7MlwG6pIn/SuBzdCiSpo5oBcRil+3KbsQSyOewPWa 82IqsdxM7lPD11NjLvQUi4QK0mKQGpozFAbw== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 13 Mar 2017 00:19:41 -0700 Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 13 Mar 2017 00:17:21 -0700 From: Jim Schaad To: =?iso-8859-1?Q?'Christian_Ams=FCss'?= , =?iso-8859-1?Q?'G=F6ran_Selander'?= , "'Francesca Palombini'" References: <20170303173229.uj7av3xia4prxku3@hephaistos.amsuess.com> <20170306150622.mxhuggsfaojso4xv@hephaistos.amsuess.com> <20170312130458.qwq5vykp3iil4kum@hephaistos.amsuess.com> In-Reply-To: <20170312130458.qwq5vykp3iil4kum@hephaistos.amsuess.com> Date: Mon, 13 Mar 2017 00:19:35 -0700 Message-ID: <0b7601d29bca$2d3087e0$879197a0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHgVXLESQVLl1aeZRwIVJwzh3yX/gGgrzmaAiRqJWahWL6R8A== X-Originating-IP: [24.21.96.37] Archived-At: Cc: core@ietf.org Subject: Re: [core] pre-draft: Request-Tag X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 07:19:46 -0000 1. I still don't understand what exactly your problem is, but I think = that if one expects things to be changed together, then that would be an application problem rather than a CoAP problem. I think that I agree = with Olaf and Matthias on that point. 2. There is a different endpoint problem which needs to be solved for OSCOAP because of the removal of all URI-Path elements from the query = which means that endpoints collapse in a way that they do not with DTLS only solutions. 3. I think that there needs to be a solution for dealing with ensuring = that the correct content has been acquired after doing a series of bitwise transactions. This could be done either at the CoAP layer or at the application layer. Both are probably equally doable. The only thing = that might needs to be done in CoAP is the signaling of how to get the secure content checking structure. 4. My understanding of REST is that the idea of dividing a content = across multiple messages would not occur to them. One can obtain the entire = HTTP content over a TLS/DTLS connection in a "single" transaction and thus = the entire message content would be adequately protected. The fact that = CoAP breaks up the entire message content into multiple messages means that = this feature has been lost. I think that is probably too bad. > -----Original Message----- > From: Christian Ams=FCss [mailto:c.amsuess@energyharvesting.at] > Sent: Sunday, March 12, 2017 6:05 AM > To: G=F6ran Selander ; Jim Schaad > ; Francesca Palombini > > Cc: core@ietf.org > Subject: Re: [core] pre-draft: Request-Tag >=20 > Hello OSCOAP people, >=20 > > * CoAP over DTLS question: How does CoAP over DTLS deal with delayed > > PUTs? >=20 > I've received word back on and off list from DTLS implementors (Olaf = and > Matthias), and their take on this sounds to me rather that blocks = being > misassignable between blockwise requests is more of an application = issue > than something blockwise and crypto should protect us from. >=20 > On the other hand, the last published draft version did include preparations > for chaining inner-blockwise requests into a cryptographically secured total. >=20 > Before we push further the "how", is there agreement among the OSCOAP > authors that we want a way to protect the body of a blockwise request, even > in the light of Olaf's comments? >=20 > (My personal take on this is that there are protection-worthy REST > transactions atop the blockwise layer, and that blockwise mode itself > knowingly sacrifices complete RESTfulness in favor of slimness (that's = how > the "same endpoint" language gets in there, but it avoids additional = round > trips and allocations for creation of a per-transaction resource). > Thus, I think that it'd be within the scope of the OSCOAP layer to = link those > messages cryptographically -- but then again, I'm not too firm with = the > theoretical background of REST.) >=20 > Best regards > Christian >=20 > -- > I shouldn't have written all those tank programs. > -- Kevin Flynn From nobody Mon Mar 13 03:05:11 2017 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 551A2129555 for ; Mon, 13 Mar 2017 03:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.279 X-Spam-Level: X-Spam-Status: No, score=0.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, SPF_SOFTFAIL=0.665, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" 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 4WUkAFpczV6E for ; Mon, 13 Mar 2017 03:05:09 -0700 (PDT) Received: from buffalo.u-blox.com (buffalo.u-blox.com [195.34.89.137]) by ietfa.amsl.com (Postfix) with SMTP id DA88C12956D for ; Mon, 13 Mar 2017 03:05:04 -0700 (PDT) Received: from mail_filter (localhost [127.0.0.1]) by buffalo.u-blox.com (PF_LO_10026) with ESMTP id 2C85315F6A3 for ; Mon, 13 Mar 2017 11:05:03 +0100 (CET) Received: from ASSP.nospam (localhost [127.0.0.1]) by buffalo.u-blox.com (Postfix) with ESMTP id 1835415F58D; Mon, 13 Mar 2017 11:05:03 +0100 (CET) X-Assp-Resend-Blocked: ASSP.nospam X-Assp-Version: 2.4.7(16004) on ASSP.nospam X-Assp-ID: ASSP.nospam 00325-16637 X-Assp-Session: 838358E4 (mail 1) X-Assp-Detected-RIP: 97.79.186.2 X-Assp-Source-IP: 97.79.186.2 X-Assp-Original-Subject: Re: [core] New Version Notification fordraft-groves-core-bas-00.txt X-Assp-Client-TLS: yes X-Assp-Delay: not delayed (gripvalue low: 0.04); 8 Mar 2017 20:12:06 +0100 X-Assp-Message-Score: -21 (209.85.218.0 in griplist (0.04)) X-Original-Authentication-Results: ASSP.nospam; spf=pass X-Assp-Message-Score: -1 (SPF pass) X-Assp-IP-Score: -1 (SPF pass) X-Assp-Message-Score: 50 (DNSBL: failed, 209.85.218.46 listed insafe.dnsbl.sorbs.net) X-Assp-IP-Score: 50 (DNSBL: failed, 209.85.218.46 listed in safe.dnsbl.sorbs.net) X-Assp-DNSBL: failed, 209.85.218.46 listed in (safe.dnsbl.sorbs.net<-127.0.0.6; ) X-Assp-Tag: DNSBL X-Assp-Spam-Reason: DNSBL, 209.85.218.46 listed in safe.dnsbl.sorbs.net X-Assp-Message-Totalscore: 28 Received: from mail-oi0-f46.google.com ([209.85.218.46] helo=mail-oi0-f46.google.com)by ASSP.nospam with SMTPS(AES128-GCM-SHA256) (2.4.7); 8 Mar 2017 20:12:04 +0100 Received: by mail-oi0-f46.google.com with SMTP id 62so25205852oih.2 for ; Wed, 08 Mar 2017 11:12:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=ghTTYv9JJeKLe/995Ma3tNjSlX8WWfZx82iLgPOA/+U=; b=ApD8Mg+ASjpYkUrXvypbZDPbaIYCqO3Jc45MdA/tSEYbLzvkjVidMxPl/caorFGAU0 GSewiC/LHozivDgmNKMoYVdSAlZKrClXkMGpaEkng/KkaOCksXd/wpWU3G28o6k6tRPg OzMa4J/+OfN7UGKGdbRowu2IQZjClUQZU3+8wiUqkeFNZjmo67tY9etUMrO63rnEeywh 7/49f89qehMOxEXk+GgBMDeFLDMNueU99K2L3QjENgpc03MX/WEb9vqMx4o0Ez40kpq3 SVx+d401teaILgQod7YnkK/KAHxBjnN+FbmJfqNas+N0yejTD8deYLp3VGZYdMOpjf/t HbMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=ghTTYv9JJeKLe/995Ma3tNjSlX8WWfZx82iLgPOA/+U=; b=ugS4ws1/WYFd2VWYSU43HEzIuZv4wsDsW7uGUUcYhpnGS3a6Nx5OiWE3sV1hIkGHaq kuS4qGj7uz3HUVv/wbeW4d/2UP5IqqAovngz3mTkpxJDbc2IkptsJNO+JsGCCVDgOjYD iGXzQOcB3ebG87FiXD/Q10zbEwSZQbIBv/5chme6HAp6kzRFqIpFT6IoCxR3NDInaF/z KIsmmEqV5dP8OdjoLzdK57HO4n6+NQjsiPRG+somtSQBa9mWxm4/YTKAJCqbo3a/VgfY 6dhkWcYWXXVGDewv5YEnGGQ3gefg+5LZmx6ySVPYHPJqeI06CZBEyyqzMFqM+Iw8CL3m Zajw== X-Gm-Message-State: AMke39nj3DjTvCI2tc/hPqB1ozarmHeMFdBd2nfPmuwHLnTAPTiHzNZcL3Jjakra/PZg7Q== X-Received: by 10.202.229.11 with SMTP id c11mr2842219oih.72.1488970292378; Wed, 08 Mar 2017 02:51:32 -0800 (PST) Received: from [172.20.21.5] (rrcs-97-79-186-2.sw.biz.rr.com. [97.79.186.2]) by smtp.gmail.com with ESMTPSA id u131sm1340958oig.24.2017.03.08.02.51.31 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 08 Mar 2017 02:51:31 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_FC093272-9BF7-4B27-8A92-F95D875526D9" From: Michael Koster X-Priority: 3 (Normal) In-Reply-To: Date: Wed, 8 Mar 2017 04:51:30 -0600 Message-Id: <682CCE2D-9E92-4856-8B7B-32043F449EEF@gmail.com> References: <148765208755.26069.6296092128269483309.idtracker@ietfa.amsl.com> To: Mojan Mohajer X-Mailer: Apple Mail (2.2104) X-Virus-Scanned: clamav-milter 0.99.2 at buffalo X-Virus-Status: Clean Archived-At: Cc: core Subject: Re: [core] New Version Notification for draft-groves-core-bas-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 10:05:10 -0000 --Apple-Mail=_FC093272-9BF7-4B27-8A92-F95D875526D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Clearly, each observe request and response stream needs to respect it's = own token sequence. > On Mar 8, 2017, at 4:45 AM, Mojan Mohajer = wrote: >=20 > after CoAP server receives the second observe request it can use = either Token 0x01 or 0x02 when notifying the resources in the collection = back to the client and client can match it to its observe requests as = appropriate --Apple-Mail=_FC093272-9BF7-4B27-8A92-F95D875526D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Clearly, each observe request and response stream needs to = respect it's own token sequence.

On = Mar 8, 2017, at 4:45 AM, Mojan Mohajer <mojan.mohajer@u-blox.com> wrote:

after CoAP server receives the second observe = request it can use either Token 0x01 or 0x02 when notifying the = resources in the collection back to the client and client can match it = to its observe requests as = appropriate

= --Apple-Mail=_FC093272-9BF7-4B27-8A92-F95D875526D9-- From nobody Mon Mar 13 03:05:48 2017 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 9BFBA129555 for ; Mon, 13 Mar 2017 03:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.279 X-Spam-Level: X-Spam-Status: No, score=0.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, SPF_SOFTFAIL=0.665, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" 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 h0oDpkzDmxb1 for ; Mon, 13 Mar 2017 03:05:45 -0700 (PDT) Received: from buffalo.u-blox.com (buffalo.u-blox.com [195.34.89.137]) by ietfa.amsl.com (Postfix) with SMTP id 77F41128AB0 for ; Mon, 13 Mar 2017 03:05:45 -0700 (PDT) Received: from mail_filter (localhost [127.0.0.1]) by buffalo.u-blox.com (PF_LO_10026) with ESMTP id 4828415F6A3 for ; Mon, 13 Mar 2017 11:05:44 +0100 (CET) Received: from ASSP.nospam (localhost [127.0.0.1]) by buffalo.u-blox.com (Postfix) with ESMTP id 35BBE15F5A0; Mon, 13 Mar 2017 11:05:44 +0100 (CET) X-Assp-Resend-Blocked: ASSP.nospam X-Assp-Version: 2.4.7(16004) on ASSP.nospam X-Assp-ID: ASSP.nospam 00325-16637 X-Assp-Session: 838358E4 (mail 1) X-Assp-Detected-RIP: 97.79.186.2 X-Assp-Source-IP: 97.79.186.2 X-Assp-Original-Subject: Re: [core] New Version Notification fordraft-groves-core-bas-00.txt X-Assp-Client-TLS: yes X-Assp-Delay: not delayed (gripvalue low: 0.04); 8 Mar 2017 20:12:06 +0100 X-Assp-Message-Score: -21 (209.85.218.0 in griplist (0.04)) X-Original-Authentication-Results: ASSP.nospam; spf=pass X-Assp-Message-Score: -1 (SPF pass) X-Assp-IP-Score: -1 (SPF pass) X-Assp-Message-Score: 50 (DNSBL: failed, 209.85.218.46 listed insafe.dnsbl.sorbs.net) X-Assp-IP-Score: 50 (DNSBL: failed, 209.85.218.46 listed in safe.dnsbl.sorbs.net) X-Assp-DNSBL: failed, 209.85.218.46 listed in (safe.dnsbl.sorbs.net<-127.0.0.6; ) X-Assp-Tag: DNSBL X-Assp-Spam-Reason: DNSBL, 209.85.218.46 listed in safe.dnsbl.sorbs.net X-Assp-Message-Totalscore: 28 Received: from mail-oi0-f46.google.com ([209.85.218.46] helo=mail-oi0-f46.google.com)by ASSP.nospam with SMTPS(AES128-GCM-SHA256) (2.4.7); 8 Mar 2017 20:12:04 +0100 Received: by mail-oi0-f46.google.com with SMTP id 62so25205852oih.2 for ; Wed, 08 Mar 2017 11:12:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=ghTTYv9JJeKLe/995Ma3tNjSlX8WWfZx82iLgPOA/+U=; b=ApD8Mg+ASjpYkUrXvypbZDPbaIYCqO3Jc45MdA/tSEYbLzvkjVidMxPl/caorFGAU0 GSewiC/LHozivDgmNKMoYVdSAlZKrClXkMGpaEkng/KkaOCksXd/wpWU3G28o6k6tRPg OzMa4J/+OfN7UGKGdbRowu2IQZjClUQZU3+8wiUqkeFNZjmo67tY9etUMrO63rnEeywh 7/49f89qehMOxEXk+GgBMDeFLDMNueU99K2L3QjENgpc03MX/WEb9vqMx4o0Ez40kpq3 SVx+d401teaILgQod7YnkK/KAHxBjnN+FbmJfqNas+N0yejTD8deYLp3VGZYdMOpjf/t HbMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=ghTTYv9JJeKLe/995Ma3tNjSlX8WWfZx82iLgPOA/+U=; b=ugS4ws1/WYFd2VWYSU43HEzIuZv4wsDsW7uGUUcYhpnGS3a6Nx5OiWE3sV1hIkGHaq kuS4qGj7uz3HUVv/wbeW4d/2UP5IqqAovngz3mTkpxJDbc2IkptsJNO+JsGCCVDgOjYD iGXzQOcB3ebG87FiXD/Q10zbEwSZQbIBv/5chme6HAp6kzRFqIpFT6IoCxR3NDInaF/z KIsmmEqV5dP8OdjoLzdK57HO4n6+NQjsiPRG+somtSQBa9mWxm4/YTKAJCqbo3a/VgfY 6dhkWcYWXXVGDewv5YEnGGQ3gefg+5LZmx6ySVPYHPJqeI06CZBEyyqzMFqM+Iw8CL3m Zajw== X-Gm-Message-State: AMke39nj3DjTvCI2tc/hPqB1ozarmHeMFdBd2nfPmuwHLnTAPTiHzNZcL3Jjakra/PZg7Q== X-Received: by 10.202.229.11 with SMTP id c11mr2842219oih.72.1488970292378; Wed, 08 Mar 2017 02:51:32 -0800 (PST) Received: from [172.20.21.5] (rrcs-97-79-186-2.sw.biz.rr.com. [97.79.186.2]) by smtp.gmail.com with ESMTPSA id u131sm1340958oig.24.2017.03.08.02.51.31 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 08 Mar 2017 02:51:31 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_FC093272-9BF7-4B27-8A92-F95D875526D9" From: Michael Koster X-Priority: 3 (Normal) In-Reply-To: Date: Wed, 8 Mar 2017 04:51:30 -0600 Message-Id: <682CCE2D-9E92-4856-8B7B-32043F449EEF@gmail.com> References: <148765208755.26069.6296092128269483309.idtracker@ietfa.amsl.com> To: Mojan Mohajer X-Mailer: Apple Mail (2.2104) X-Virus-Scanned: clamav-milter 0.99.2 at buffalo X-Virus-Status: Clean Archived-At: Cc: core Subject: Re: [core] New Version Notification for draft-groves-core-bas-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 10:05:46 -0000 --Apple-Mail=_FC093272-9BF7-4B27-8A92-F95D875526D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Clearly, each observe request and response stream needs to respect it's = own token sequence. > On Mar 8, 2017, at 4:45 AM, Mojan Mohajer = wrote: >=20 > after CoAP server receives the second observe request it can use = either Token 0x01 or 0x02 when notifying the resources in the collection = back to the client and client can match it to its observe requests as = appropriate --Apple-Mail=_FC093272-9BF7-4B27-8A92-F95D875526D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Clearly, each observe request and response stream needs to = respect it's own token sequence.

On = Mar 8, 2017, at 4:45 AM, Mojan Mohajer <mojan.mohajer@u-blox.com> wrote:

after CoAP server receives the second observe = request it can use either Token 0x01 or 0x02 when notifying the = resources in the collection back to the client and client can match it = to its observe requests as = appropriate

= --Apple-Mail=_FC093272-9BF7-4B27-8A92-F95D875526D9-- From nobody Mon Mar 13 03:06:39 2017 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 8CC561294F7 for ; Mon, 13 Mar 2017 03:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.279 X-Spam-Level: X-Spam-Status: No, score=0.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, SPF_SOFTFAIL=0.665, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" 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 5g4olWCd57ci for ; Mon, 13 Mar 2017 03:06:38 -0700 (PDT) Received: from buffalo.u-blox.com (buffalo.u-blox.com [195.34.89.137]) by ietfa.amsl.com (Postfix) with SMTP id 278241294E1 for ; Mon, 13 Mar 2017 03:06:33 -0700 (PDT) Received: from mail_filter (localhost [127.0.0.1]) by buffalo.u-blox.com (PF_LO_10026) with ESMTP id 4BFBE15F6B3 for ; Mon, 13 Mar 2017 11:06:33 +0100 (CET) Received: from ASSP.nospam (localhost [127.0.0.1]) by buffalo.u-blox.com (Postfix) with ESMTP id 367BB15F5A0; Mon, 13 Mar 2017 11:06:33 +0100 (CET) X-Assp-Resend-Blocked: ASSP.nospam X-Assp-Version: 2.4.7(16004) on ASSP.nospam X-Assp-ID: ASSP.nospam 70293-17582 X-Assp-Session: 407B81CC (mail 1) X-Assp-Detected-RIP: 97.79.186.2 X-Assp-Source-IP: 97.79.186.2 X-Assp-Original-Subject: Re: [core] New Version Notification fordraft-groves-core-bas-00.txt X-Assp-Client-TLS: yes X-Assp-Delay: not delayed (gripvalue low: 0.04); 8 Mar 2017 11:51:34 +0100 X-Assp-Message-Score: -21 (209.85.218.0 in griplist (0.04)) X-Original-Authentication-Results: ASSP.nospam; spf=pass X-Assp-Message-Score: -1 (SPF pass) X-Assp-IP-Score: -1 (SPF pass) X-Assp-Message-Score: 50 (DNSBL: failed, 209.85.218.52 listed insafe.dnsbl.sorbs.net) X-Assp-IP-Score: 50 (DNSBL: failed, 209.85.218.52 listed in safe.dnsbl.sorbs.net) X-Assp-DNSBL: failed, 209.85.218.52 listed in (safe.dnsbl.sorbs.net<-127.0.0.6; ) X-Assp-Tag: DNSBL X-Assp-Spam-Reason: DNSBL, 209.85.218.52 listed in safe.dnsbl.sorbs.net X-Assp-Message-Totalscore: 28 Received: from mail-oi0-f52.google.com ([209.85.218.52] helo=mail-oi0-f52.google.com)by ASSP.nospam with SMTPS(AES128-GCM-SHA256) (2.4.7); 8 Mar 2017 11:51:32 +0100 Received: by mail-oi0-f52.google.com with SMTP id m124so16728350oig.1 for ; Wed, 08 Mar 2017 02:51:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=ghTTYv9JJeKLe/995Ma3tNjSlX8WWfZx82iLgPOA/+U=; b=ApD8Mg+ASjpYkUrXvypbZDPbaIYCqO3Jc45MdA/tSEYbLzvkjVidMxPl/caorFGAU0 GSewiC/LHozivDgmNKMoYVdSAlZKrClXkMGpaEkng/KkaOCksXd/wpWU3G28o6k6tRPg OzMa4J/+OfN7UGKGdbRowu2IQZjClUQZU3+8wiUqkeFNZjmo67tY9etUMrO63rnEeywh 7/49f89qehMOxEXk+GgBMDeFLDMNueU99K2L3QjENgpc03MX/WEb9vqMx4o0Ez40kpq3 SVx+d401teaILgQod7YnkK/KAHxBjnN+FbmJfqNas+N0yejTD8deYLp3VGZYdMOpjf/t HbMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=ghTTYv9JJeKLe/995Ma3tNjSlX8WWfZx82iLgPOA/+U=; b=HmQOV8LI7WjAgYmLw5PpBXd46JiI4/Liupvrn3PtCZi8km3mwaUNsX7zuPf9jEdOTu pdkW0fYhfzrIsjTGtwr5LuxHZEqs4qqUHTJ+NNeIykO2br451oBzaK0CB8u5jmksx0pw 4QdnEuGYqilLqkvBDXrGBJgzHtq811Nm3QsW49O3uwzR84Fn7Wlm0b5+DYnn5Ta/QOa6 Pcrw+YiBOfBNIR5JdHQ0DEQmAiV9bDdPqrz676qpIksDCOkRKakE1uXH+yF7kRlToGLy zEY8gwGVCebCF0iDCbm50a5LVdGOK6zfqArbkeoyAw7fPuxMsZ47KPKvhz12m1TlM4J5 fhyg== X-Gm-Message-State: AMke39lri9eJ64P3xmvo0jtVRT9XGgkB6fpz9zUp5Y5vkHR+1frOtnnQfvi5Gd0d0PXpvw== X-Received: by 10.202.229.11 with SMTP id c11mr2842219oih.72.1488970292378; Wed, 08 Mar 2017 02:51:32 -0800 (PST) Received: from [172.20.21.5] (rrcs-97-79-186-2.sw.biz.rr.com. [97.79.186.2]) by smtp.gmail.com with ESMTPSA id u131sm1340958oig.24.2017.03.08.02.51.31 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 08 Mar 2017 02:51:31 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_FC093272-9BF7-4B27-8A92-F95D875526D9" From: Michael Koster X-Priority: 3 (Normal) In-Reply-To: Date: Wed, 8 Mar 2017 04:51:30 -0600 Message-Id: <682CCE2D-9E92-4856-8B7B-32043F449EEF@gmail.com> References: <148765208755.26069.6296092128269483309.idtracker@ietfa.amsl.com> To: Mojan Mohajer X-Mailer: Apple Mail (2.2104) X-Virus-Scanned: clamav-milter 0.99.2 at buffalo X-Virus-Status: Clean Archived-At: Cc: core Subject: Re: [core] New Version Notification for draft-groves-core-bas-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 10:06:38 -0000 --Apple-Mail=_FC093272-9BF7-4B27-8A92-F95D875526D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Clearly, each observe request and response stream needs to respect it's = own token sequence. > On Mar 8, 2017, at 4:45 AM, Mojan Mohajer = wrote: >=20 > after CoAP server receives the second observe request it can use = either Token 0x01 or 0x02 when notifying the resources in the collection = back to the client and client can match it to its observe requests as = appropriate --Apple-Mail=_FC093272-9BF7-4B27-8A92-F95D875526D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Clearly, each observe request and response stream needs to = respect it's own token sequence.

On = Mar 8, 2017, at 4:45 AM, Mojan Mohajer <mojan.mohajer@u-blox.com> wrote:

after CoAP server receives the second observe = request it can use either Token 0x01 or 0x02 when notifying the = resources in the collection back to the client and client can match it = to its observe requests as = appropriate

= --Apple-Mail=_FC093272-9BF7-4B27-8A92-F95D875526D9-- From nobody Mon Mar 13 03:06:42 2017 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 7349F129571 for ; Mon, 13 Mar 2017 03:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.221 X-Spam-Level: X-Spam-Status: No, score=-0.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" 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 wX-mXh2mX4CK for ; Mon, 13 Mar 2017 03:06:39 -0700 (PDT) Received: from buffalo.u-blox.com (buffalo.u-blox.com [195.34.89.137]) by ietfa.amsl.com (Postfix) with SMTP id 7A1C5129400 for ; Mon, 13 Mar 2017 03:06:38 -0700 (PDT) Received: from mail_filter (localhost [127.0.0.1]) by buffalo.u-blox.com (PF_LO_10026) with ESMTP id 5238315F6B6 for ; Mon, 13 Mar 2017 11:06:37 +0100 (CET) Received: from ASSP.nospam (localhost [127.0.0.1]) by buffalo.u-blox.com (Postfix) with ESMTP id 3DC6715F6A3; Mon, 13 Mar 2017 11:06:37 +0100 (CET) X-Assp-Resend-Blocked: ASSP.nospam X-Assp-Version: 2.4.7(16004) on ASSP.nospam X-Assp-ID: ASSP.nospam 70735-19274 X-Assp-Session: 40451528 (mail 1) X-Assp-Detected-RIP: 97.79.186.2 X-Assp-Source-IP: 97.79.186.2 X-Assp-Original-Subject: Re: [core] New Version Notification fordraft-groves-core-bas-00.txt X-Assp-Client-TLS: yes X-Assp-Delay: not delayed (gripvalue low: 0.04); 8 Mar 2017 11:58:55 +0100 X-Assp-Message-Score: -21 (209.85.218.0 in griplist (0.04)) X-Original-Authentication-Results: ASSP.nospam; spf=pass X-Assp-Message-Score: -1 (SPF pass) X-Assp-IP-Score: -1 (SPF pass) X-Assp-Message-Score: 50 (DNSBL: failed, 209.85.218.41 listed insafe.dnsbl.sorbs.net) X-Assp-IP-Score: 50 (DNSBL: failed, 209.85.218.41 listed in safe.dnsbl.sorbs.net) X-Assp-DNSBL: failed, 209.85.218.41 listed in (safe.dnsbl.sorbs.net<-127.0.0.6; ) X-Assp-Tag: DNSBL X-Assp-Spam-Reason: DNSBL, 209.85.218.41 listed in safe.dnsbl.sorbs.net X-Assp-Message-Totalscore: 28 Received: from mail-oi0-f41.google.com ([209.85.218.41] helo=mail-oi0-f41.google.com)by ASSP.nospam with SMTPS(AES128-GCM-SHA256) (2.4.7); 8 Mar 2017 11:58:54 +0100 Received: by mail-oi0-f41.google.com with SMTP id 2so16716011oif.0 for ; Wed, 08 Mar 2017 02:58:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=ghTTYv9JJeKLe/995Ma3tNjSlX8WWfZx82iLgPOA/+U=; b=ApD8Mg+ASjpYkUrXvypbZDPbaIYCqO3Jc45MdA/tSEYbLzvkjVidMxPl/caorFGAU0 GSewiC/LHozivDgmNKMoYVdSAlZKrClXkMGpaEkng/KkaOCksXd/wpWU3G28o6k6tRPg OzMa4J/+OfN7UGKGdbRowu2IQZjClUQZU3+8wiUqkeFNZjmo67tY9etUMrO63rnEeywh 7/49f89qehMOxEXk+GgBMDeFLDMNueU99K2L3QjENgpc03MX/WEb9vqMx4o0Ez40kpq3 SVx+d401teaILgQod7YnkK/KAHxBjnN+FbmJfqNas+N0yejTD8deYLp3VGZYdMOpjf/t HbMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=ghTTYv9JJeKLe/995Ma3tNjSlX8WWfZx82iLgPOA/+U=; b=kAvsroyOhDjEIDgeKp8C0eCJC4J0wG5tj+4vUT6unVj5ofrlVOlx8QYHm6gtpcAqWE D1rV0KOgfXx8i2JwJh+6lO2N8BqFSlMujCYcBGiwDq4ikaFI78VOWTILg/6OztMbhnsx 8qiYgW5wGp03rXN9n14pw4/+HaAIUnU/MkPZpCw1F1tccyeQuyktjbHVnxn7BL7P56xL ZS6N0CF1sQP74BGrIPBWk/AIg0xUjvINA8/3pqV3Jj54X++BKxmwZF4/xKiRClU8/DUf 6rO/aSkV0514mKvevg+DrERGRdOUmISCN/po7tzMtPoG26Mg6S2nWAq/dNBp6GNgE7C6 69wA== X-Gm-Message-State: AMke39lYASw9CrIGk3z2PVrzRC+1E+H6clgxgBaubu/DpHZ6JdDppoM2YvJHjzxbyos8xQ== X-Received: by 10.202.229.11 with SMTP id c11mr2842219oih.72.1488970292378; Wed, 08 Mar 2017 02:51:32 -0800 (PST) Received: from [172.20.21.5] (rrcs-97-79-186-2.sw.biz.rr.com. [97.79.186.2]) by smtp.gmail.com with ESMTPSA id u131sm1340958oig.24.2017.03.08.02.51.31 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 08 Mar 2017 02:51:31 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_FC093272-9BF7-4B27-8A92-F95D875526D9" From: Michael Koster X-Priority: 3 (Normal) In-Reply-To: Date: Wed, 8 Mar 2017 04:51:30 -0600 Message-Id: <682CCE2D-9E92-4856-8B7B-32043F449EEF@gmail.com> References: <148765208755.26069.6296092128269483309.idtracker@ietfa.amsl.com> To: Mojan Mohajer X-Mailer: Apple Mail (2.2104) X-Virus-Scanned: clamav-milter 0.99.2 at buffalo X-Virus-Status: Clean Archived-At: Cc: core Subject: Re: [core] New Version Notification for draft-groves-core-bas-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 10:06:39 -0000 --Apple-Mail=_FC093272-9BF7-4B27-8A92-F95D875526D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Clearly, each observe request and response stream needs to respect it's = own token sequence. > On Mar 8, 2017, at 4:45 AM, Mojan Mohajer = wrote: >=20 > after CoAP server receives the second observe request it can use = either Token 0x01 or 0x02 when notifying the resources in the collection = back to the client and client can match it to its observe requests as = appropriate --Apple-Mail=_FC093272-9BF7-4B27-8A92-F95D875526D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Clearly, each observe request and response stream needs to = respect it's own token sequence.

On = Mar 8, 2017, at 4:45 AM, Mojan Mohajer <mojan.mohajer@u-blox.com> wrote:

after CoAP server receives the second observe = request it can use either Token 0x01 or 0x02 when notifying the = resources in the collection back to the client and client can match it = to its observe requests as = appropriate

= --Apple-Mail=_FC093272-9BF7-4B27-8A92-F95D875526D9-- From nobody Mon Mar 13 03:14:24 2017 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 53DAA1294DF for ; Mon, 13 Mar 2017 03:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.279 X-Spam-Level: X-Spam-Status: No, score=0.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, SPF_SOFTFAIL=0.665, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" 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 WRzinXu4tZgq for ; Mon, 13 Mar 2017 03:14:21 -0700 (PDT) Received: from buffalo.u-blox.com (buffalo.u-blox.com [195.34.89.137]) by ietfa.amsl.com (Postfix) with SMTP id C7D6C12945D for ; Mon, 13 Mar 2017 03:14:20 -0700 (PDT) Received: from mail_filter (localhost [127.0.0.1]) by buffalo.u-blox.com (PF_LO_10026) with ESMTP id 192CB15F6A5 for ; Mon, 13 Mar 2017 11:06:44 +0100 (CET) Received: from ASSP.nospam (localhost [127.0.0.1]) by buffalo.u-blox.com (Postfix) with ESMTP id 0279F15F5A0; Mon, 13 Mar 2017 11:06:44 +0100 (CET) X-Assp-Resend-Blocked: ASSP.nospam X-Assp-Version: 2.4.7(16004) on ASSP.nospam X-Assp-ID: ASSP.nospam 00325-16637 X-Assp-Session: 838358E4 (mail 1) X-Assp-Detected-RIP: 97.79.186.2 X-Assp-Source-IP: 97.79.186.2 X-Assp-Original-Subject: Re: [core] New Version Notification fordraft-groves-core-bas-00.txt X-Assp-Client-TLS: yes X-Assp-Delay: not delayed (gripvalue low: 0.04); 8 Mar 2017 20:12:06 +0100 X-Assp-Message-Score: -21 (209.85.218.0 in griplist (0.04)) X-Original-Authentication-Results: ASSP.nospam; spf=pass X-Assp-Message-Score: -1 (SPF pass) X-Assp-IP-Score: -1 (SPF pass) X-Assp-Message-Score: 50 (DNSBL: failed, 209.85.218.46 listed insafe.dnsbl.sorbs.net) X-Assp-IP-Score: 50 (DNSBL: failed, 209.85.218.46 listed in safe.dnsbl.sorbs.net) X-Assp-DNSBL: failed, 209.85.218.46 listed in (safe.dnsbl.sorbs.net<-127.0.0.6; ) X-Assp-Tag: DNSBL X-Assp-Spam-Reason: DNSBL, 209.85.218.46 listed in safe.dnsbl.sorbs.net X-Assp-Message-Totalscore: 28 Received: from mail-oi0-f46.google.com ([209.85.218.46] helo=mail-oi0-f46.google.com)by ASSP.nospam with SMTPS(AES128-GCM-SHA256) (2.4.7); 8 Mar 2017 20:12:04 +0100 Received: by mail-oi0-f46.google.com with SMTP id 62so25205852oih.2 for ; Wed, 08 Mar 2017 11:12:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=ghTTYv9JJeKLe/995Ma3tNjSlX8WWfZx82iLgPOA/+U=; b=ApD8Mg+ASjpYkUrXvypbZDPbaIYCqO3Jc45MdA/tSEYbLzvkjVidMxPl/caorFGAU0 GSewiC/LHozivDgmNKMoYVdSAlZKrClXkMGpaEkng/KkaOCksXd/wpWU3G28o6k6tRPg OzMa4J/+OfN7UGKGdbRowu2IQZjClUQZU3+8wiUqkeFNZjmo67tY9etUMrO63rnEeywh 7/49f89qehMOxEXk+GgBMDeFLDMNueU99K2L3QjENgpc03MX/WEb9vqMx4o0Ez40kpq3 SVx+d401teaILgQod7YnkK/KAHxBjnN+FbmJfqNas+N0yejTD8deYLp3VGZYdMOpjf/t HbMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=ghTTYv9JJeKLe/995Ma3tNjSlX8WWfZx82iLgPOA/+U=; b=ugS4ws1/WYFd2VWYSU43HEzIuZv4wsDsW7uGUUcYhpnGS3a6Nx5OiWE3sV1hIkGHaq kuS4qGj7uz3HUVv/wbeW4d/2UP5IqqAovngz3mTkpxJDbc2IkptsJNO+JsGCCVDgOjYD iGXzQOcB3ebG87FiXD/Q10zbEwSZQbIBv/5chme6HAp6kzRFqIpFT6IoCxR3NDInaF/z KIsmmEqV5dP8OdjoLzdK57HO4n6+NQjsiPRG+somtSQBa9mWxm4/YTKAJCqbo3a/VgfY 6dhkWcYWXXVGDewv5YEnGGQ3gefg+5LZmx6ySVPYHPJqeI06CZBEyyqzMFqM+Iw8CL3m Zajw== X-Gm-Message-State: AMke39nj3DjTvCI2tc/hPqB1ozarmHeMFdBd2nfPmuwHLnTAPTiHzNZcL3Jjakra/PZg7Q== X-Received: by 10.202.229.11 with SMTP id c11mr2842219oih.72.1488970292378; Wed, 08 Mar 2017 02:51:32 -0800 (PST) Received: from [172.20.21.5] (rrcs-97-79-186-2.sw.biz.rr.com. [97.79.186.2]) by smtp.gmail.com with ESMTPSA id u131sm1340958oig.24.2017.03.08.02.51.31 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 08 Mar 2017 02:51:31 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_FC093272-9BF7-4B27-8A92-F95D875526D9" From: Michael Koster X-Priority: 3 (Normal) In-Reply-To: Date: Wed, 8 Mar 2017 04:51:30 -0600 Message-Id: <682CCE2D-9E92-4856-8B7B-32043F449EEF@gmail.com> References: <148765208755.26069.6296092128269483309.idtracker@ietfa.amsl.com> To: Mojan Mohajer X-Mailer: Apple Mail (2.2104) X-Virus-Scanned: clamav-milter 0.99.2 at buffalo X-Virus-Status: Clean Archived-At: Cc: core Subject: Re: [core] New Version Notification for draft-groves-core-bas-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 10:14:22 -0000 --Apple-Mail=_FC093272-9BF7-4B27-8A92-F95D875526D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Clearly, each observe request and response stream needs to respect it's = own token sequence. > On Mar 8, 2017, at 4:45 AM, Mojan Mohajer = wrote: >=20 > after CoAP server receives the second observe request it can use = either Token 0x01 or 0x02 when notifying the resources in the collection = back to the client and client can match it to its observe requests as = appropriate --Apple-Mail=_FC093272-9BF7-4B27-8A92-F95D875526D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Clearly, each observe request and response stream needs to = respect it's own token sequence.

On = Mar 8, 2017, at 4:45 AM, Mojan Mohajer <mojan.mohajer@u-blox.com> wrote:

after CoAP server receives the second observe = request it can use either Token 0x01 or 0x02 when notifying the = resources in the collection back to the client and client can match it = to its observe requests as = appropriate

= --Apple-Mail=_FC093272-9BF7-4B27-8A92-F95D875526D9-- From nobody Mon Mar 13 03:51:21 2017 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 1E4251293FD for ; Mon, 13 Mar 2017 03:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8luLdBqRQZpp for ; Mon, 13 Mar 2017 03:51:19 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9974126D73 for ; Mon, 13 Mar 2017 03:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v2DAp8um029637; Mon, 13 Mar 2017 11:51:09 +0100 (CET) Received: from [172.17.2.2] (unknown [87.140.194.222]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vhZRJ52jpzDJFc; Mon, 13 Mar 2017 11:51:08 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: <8ED3AFE4-B0D5-4FE6-9D47-1C7C79E2B0AD@cisco.com> Date: Mon, 13 Mar 2017 11:51:08 +0100 X-Mao-Original-Outgoing-Id: 511095067.975901-463c19a1ac124a09f6354ff650d337d6 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8ED3AFE4-B0D5-4FE6-9D47-1C7C79E2B0AD@cisco.com> To: "Cullen Jennings (fluffy)" X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "draft-ietf-core-senml@tools.ietf.org" , core Subject: Re: [core] URI fragment use for SenML X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 10:51:20 -0000 > I'm sort of trying to figure out where we would use theses - it seem = more like query specifiers with ? on URLs might be more useful. I'm not = sure. But either way, I think I'd prefer to do them in an extension spec = and not the base SenML spec.=20 Extending media type registrations post-facto to include new fragment = identifier considerations is a bit icky (it can be done, but it requires = special license from the IESG). Ari and I believe we have figured it out, and it is not rocket-science, = but of course contains a number of bike-sheds that we will all paint = orange now. (We can fix any dissonance that might come up in WGLC.) Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Mar 13 04:52:32 2017 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 D3D94129488 for ; Mon, 13 Mar 2017 04:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMoDW1aNyG2U for ; Mon, 13 Mar 2017 04:52:30 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id F0D40128874 for ; Mon, 13 Mar 2017 04:52:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1489405949; d=isode.com; s=june2016; i=@isode.com; bh=DdFnlpNPKKVR9yCS4A9cMjpwj2FYM8Ji8yvdiOa47rE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=KyrGpIhIQDM2Xt2v6kc/zm/oBlDWf2nehaKUpNmFXzP91Z3DUbQ7XJRdp3dKvabPQ6Jxlt d2P+CPFUuGzrvzG7XNY0MGQGo6URzKS4myDixzbitKcGvu3Fom2eWEkM4V1oHefJUYiPc5 ztmqNQIBLscwk2ldg5KKk9uWU63UFUk=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 13 Mar 2017 11:52:28 +0000 To: Carsten Bormann , "Cullen Jennings (fluffy)" References: <8ED3AFE4-B0D5-4FE6-9D47-1C7C79E2B0AD@cisco.com> From: Alexey Melnikov Message-ID: <12e06d3d-7974-a491-196d-538b3ea1bae1@isode.com> Date: Mon, 13 Mar 2017 11:52:27 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-core-senml@tools.ietf.org" , core Subject: Re: [core] URI fragment use for SenML X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 11:52:31 -0000 On 13/03/2017 10:51, Carsten Bormann wrote: >> I'm sort of trying to figure out where we would use theses - it seem more like query specifiers with ? on URLs might be more useful. I'm not sure. But either way, I think I'd prefer to do them in an extension spec and not the base SenML spec. > Extending media type registrations post-facto to include new fragment identifier considerations is a bit icky (it can be done, but it requires special license from the IESG). It basically requires submitting a revised media type registration and would have to go through the same review process as the original registration. Nothing particularly special as far as IESG is concerned. > Ari and I believe we have figured it out, and it is not rocket-science, but of course contains a number of bike-sheds that we will all paint orange now. > (We can fix any dissonance that might come up in WGLC.) From nobody Mon Mar 13 05:58:16 2017 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 6E8891295E2 for ; Mon, 13 Mar 2017 05:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 XolnHWf6SToB for ; Mon, 13 Mar 2017 05:58:12 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 92DBC1295DA for ; Mon, 13 Mar 2017 05:58:12 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id v198so58046210ywc.2 for ; Mon, 13 Mar 2017 05:58:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=vwoMpRyfdCU0B48JWZitWlBG4XjELGXwmTARHWxIFgI=; b=UkbFG9tNMkNA3EwiTWS/O7Ql6f3zmi4PtZrq9e+FT8FXoK8q4o3X5Tq1zL/vQkPL/e Dltsz6kA1ha0oPMz6x6Q7TB5Dc2KyksVeE2+neF8dPk6/+p5FprE6QDGDvajy3jZUlWN FcT5570nTWu6D3DXudVGIVSCG3SIDmyKcdoseeGqn3L1lK6WJr7hYVmMj3Yvv1Swfw+R IrCytbVtU6bOFTt0D5stmN2ggPgWCszZrWFpAbcBxFfMNo9FJ347FcltKsiESSU8ete1 pomfWPunV+/C9ZK6gyFZantbbNvAfY/JjRrwF4kFHfkAhRccT6xV1d8HJVPvkOybMQqM m2jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=vwoMpRyfdCU0B48JWZitWlBG4XjELGXwmTARHWxIFgI=; b=HH4xEhVPSKy1BJEKQvyOyIEnDrnEGcYH7Ds9xP1uiWt9//xhKMaVaSUMFOUoFf5saA vdY7QYXInalft+wtR4lLk4Jal9yGNxW8Xkw9yKkN9oNE06LfJPBQk36/Jeh6dscCpqCL 0znuaXnAg4tsUGRKvWZC1bI1dZoMEqYrVEMWnluhk/GGVjtPePf/KmeQrwtidS3IFasr S5yYef9pDJGbYb8/ur7060+/aeYPyHlEe9KYb0244snYJugoijyxH5QmoHFN1RqkqoD6 DIXscW92dgReyLpAJx/W1kBwOSJackDdN3zIDDBhQmQPfWdHgosfqJgoNO0NZyzOe9A3 ljSA== X-Gm-Message-State: AMke39nv31g8dgsczNEEeXzKYLWzCgljTXbqU03fDBAvrxJ/uJAUCCk/OpqmAmMT4nYB5w== X-Received: by 10.37.173.218 with SMTP id d26mr17800861ybe.120.1489409891718; Mon, 13 Mar 2017 05:58:11 -0700 (PDT) Received: from [10.0.0.11] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id 1sm7381519ywb.72.2017.03.13.05.58.10 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 13 Mar 2017 05:58:11 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_6472F561-B955-44A4-811B-8772626B0AC9" From: Michael Koster X-Priority: 3 (Normal) In-Reply-To: Date: Mon, 13 Mar 2017 05:58:08 -0700 Message-Id: References: To: Mojan Mohajer X-Mailer: Apple Mail (2.2104) Archived-At: Cc: core Subject: Re: [core] Questions/comments on draft-ietf-core-dynlink-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 12:58:14 -0000 --Apple-Mail=_6472F561-B955-44A4-811B-8772626B0AC9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Mojan, I think this is the default behavior for OMA LWM2M using the "Write = Attributes" operation. The effect is to provide a single set of = notification parameters for all observe operations on that resource. I believe that we improve on that pattern and allow each observe request = to have its own attributes, set by including query parameters in the GET = operation. Section 4.2 also indicates that they are readable, but it's not clear to = me how that would work? In what format are they returned, also as query = parameters? These could be made readable (and updateable) througn a = special CoRE Interface, but we would need to specify how the content = format of these works vs. the content format of the resource state. LWM2M could be described in this draft as a legacy pattern. Does this make sense? Best regards, Michael > On Mar 10, 2017, at 2:52 AM, Mojan Mohajer = wrote: >=20 > 2) Section 4.2 which covers resource observation attributes (pmin, = pmax, st, =85) states that that: =85=94These query parameters MUST be = treated as resources that are read using GET and updated using PUT, and = MUST NOT be included in the Observe request=94 =85. > However, looking at newly added Annex A which provides observation = examples, these observation attributes are passed as query parameters of = a Get request with Observe option set to 0. There seems to be some = contradiction between the text in section 4.2 and the example in Annex = A. --Apple-Mail=_6472F561-B955-44A4-811B-8772626B0AC9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Mojan,

I= think this is the default behavior for OMA LWM2M using the "Write = Attributes" operation. The effect is to provide a single set of = notification parameters for all observe operations on that = resource.

I = believe that we improve on that pattern and allow each observe request = to have its own attributes, set by including query parameters in the GET = operation.

Section 4.2 also indicates that they are readable, but it's = not clear to me how that would work? In what format are they returned, = also as query parameters? These could be made readable (and updateable) = througn a special CoRE Interface, but we would need to specify how the = content format of these works vs. the content format of the resource = state.

LWM2M = could be described in this draft as a legacy pattern.

Does this make = sense?

Best = regards,

Michael


On Mar 10, 2017, at 2:52 AM, = Mojan Mohajer <mojan.mohajer@u-blox.com> wrote:

2) Section 4.2 which covers resource observation = attributes (pmin, pmax, st, =85) states that that: =85=94These query = parameters MUST be treated as resources that are read using GET and = updated using PUT, and MUST NOT be included in the Observe request=94 = =85.
However, looking at newly = added Annex A which provides observation examples, these observation = attributes are passed as query parameters of a Get request with Observe = option set to 0. There seems to be some contradiction between the text = in section 4.2 and the example in Annex A.

= --Apple-Mail=_6472F561-B955-44A4-811B-8772626B0AC9-- From nobody Mon Mar 13 06:08:15 2017 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 877ED1295E1 for ; Mon, 13 Mar 2017 06:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Cp_zsPC4Ur6I for ; Mon, 13 Mar 2017 06:08:13 -0700 (PDT) Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::22f]) (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 D76141295E7 for ; Mon, 13 Mar 2017 06:08:12 -0700 (PDT) Received: by mail-ot0-x22f.google.com with SMTP id i1so111959373ota.3 for ; Mon, 13 Mar 2017 06:08:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=9tbAk1ZmEIqLD37cD5EPj44PG9fyDpwXK70gZwHhatU=; b=FyDWXlo39h52g0T7t5cb3sJV2fD0ZwczzmU5T/JVNEx2oBzKxutgGlJHzsq+MOHmqK o3IFeQqR1GwT3UHD4UYJemvJ/CNG4A02mB7bunPHKWxovQ6vXyHhZmysP1qIonKVb7J2 n0SA5ubwTkE5i6pJOGu2OqAaF6vDaLzVKfOUuYx5Ev9NhQo3VkAxPTcVibIHkiJWN6Qx qx8nLn57JURycQiHFK6h4hzYtC/0qbH9lLykHpjpJANQq37W2ZV8YXaocUdXjB/FH2vd SNMu/RQk3QXAjaBidfc64YFRy1aL37mLiawIIfMpFO4p4hkNYjSzO4KLlOVAPSWN7W5c sFZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=9tbAk1ZmEIqLD37cD5EPj44PG9fyDpwXK70gZwHhatU=; b=BgXvnZQ9cgvB/FWzwNJ+xbpXROUZooA7FbyucD95AAT1JtgCJGDEHtAsYOgMyXgvz4 XTQcKx8XNMM1wyefbY7v06fW/joQV2UMflu2A3jqvCTVjj852MiOYEjdOvJNLx7cd46G P7GZrTCxwn7pmwrFwVdTjWzdiGwFWBflo/oSeKk2ERBjrMlAZ/seylRvDk8MuwodsoYo WNuphTbXuyTLIW5cu/ad+5ImUOT5QjkABGNSJKKLBI2MVYNasz131pntWhOYYFITpw8t Np6d6V+pdw+8YrCPMIr/4G5t+NGYqC7XSYUlYwKquFA+Hm9HFGDbSlVGSoG+3abrE6Cm oNYw== X-Gm-Message-State: AMke39kzPsZmruxT4+w3nI1gpMSmq1hA7fQxIdXk5zvQLWLzlKujauwUfaUJcu8X/8V/HA== X-Received: by 10.157.49.47 with SMTP id e44mr16417555otc.129.1489410492254; Mon, 13 Mar 2017 06:08:12 -0700 (PDT) Received: from [10.0.0.11] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id t8sm7986742oib.23.2017.03.13.06.08.11 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 13 Mar 2017 06:08:11 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_DC2C98F6-0C19-4E5B-B2C9-729FA39677F4" From: Michael Koster X-Priority: 3 (Normal) In-Reply-To: Date: Mon, 13 Mar 2017 06:08:09 -0700 Message-Id: References: To: Mojan Mohajer X-Mailer: Apple Mail (2.2104) Archived-At: Cc: core Subject: Re: [core] Questions/comments on draft-ietf-core-dynlink-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 13:08:14 -0000 --Apple-Mail=_DC2C98F6-0C19-4E5B-B2C9-729FA39677F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 To summarize, I recommend that we change 4.2 to specify using observe = attributes as query parameters in the OBSERVE operation to which they = apply. We could optionally make them writeable as a single set of attributes to = apply to all observations of that resource. If we want to make the single set readable, we will need to add more = specification. about the returned representation. Best regards, Michael > On Mar 13, 2017, at 5:58 AM, Michael Koster = wrote: >=20 > Hi Mojan, >=20 > I think this is the default behavior for OMA LWM2M using the "Write = Attributes" operation. The effect is to provide a single set of = notification parameters for all observe operations on that resource. >=20 > I believe that we improve on that pattern and allow each observe = request to have its own attributes, set by including query parameters in = the GET operation. >=20 > Section 4.2 also indicates that they are readable, but it's not clear = to me how that would work? In what format are they returned, also as = query parameters? These could be made readable (and updateable) througn = a special CoRE Interface, but we would need to specify how the content = format of these works vs. the content format of the resource state. >=20 > LWM2M could be described in this draft as a legacy pattern. >=20 > Does this make sense? >=20 > Best regards, >=20 > Michael >=20 >=20 >> On Mar 10, 2017, at 2:52 AM, Mojan Mohajer > wrote: >>=20 >> 2) Section 4.2 which covers resource observation attributes (pmin, = pmax, st, =85) states that that: =85=94These query parameters MUST be = treated as resources that are read using GET and updated using PUT, and = MUST NOT be included in the Observe request=94 =85. >> However, looking at newly added Annex A which provides observation = examples, these observation attributes are passed as query parameters of = a Get request with Observe option set to 0. There seems to be some = contradiction between the text in section 4.2 and the example in Annex = A. >=20 --Apple-Mail=_DC2C98F6-0C19-4E5B-B2C9-729FA39677F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 To summarize, I recommend that we change 4.2 to specify using = observe attributes as query parameters in the OBSERVE operation to which = they apply.

We could = optionally make them writeable as a single set of attributes to apply to = all observations of that resource.

If we want to make the single set = readable, we will need to add more specification. about the returned = representation.

Best regards,

Michael


On Mar 13, 2017, at 5:58 AM, = Michael Koster <michaeljohnkoster@gmail.com> wrote:

Hi Mojan,

I think this is the = default behavior for OMA LWM2M using the "Write Attributes" operation. = The effect is to provide a single set of notification parameters for all = observe operations on that resource.

I believe that we improve on that = pattern and allow each observe request to have its own attributes, set = by including query parameters in the GET operation.

Section 4.2 also = indicates that they are readable, but it's not clear to me how that = would work? In what format are they returned, also as query parameters? = These could be made readable (and updateable) througn a special CoRE = Interface, but we would need to specify how the content format of these = works vs. the content format of the resource state.

LWM2M could be described = in this draft as a legacy pattern.

Does this make sense?

Best regards,

Michael


On Mar 10, 2017, at 2:52 AM, Mojan Mohajer <mojan.mohajer@u-blox.com> wrote:

2) Section 4.2 which covers resource observation = attributes (pmin, pmax, st, =85) states that that: =85=94These query = parameters MUST be treated as resources that are read using GET and = updated using PUT, and MUST NOT be included in the Observe request=94 = =85.
However, looking at newly = added Annex A which provides observation examples, these observation = attributes are passed as query parameters of a Get request with Observe = option set to 0. There seems to be some contradiction between the text = in section 4.2 and the example in Annex A.


= --Apple-Mail=_DC2C98F6-0C19-4E5B-B2C9-729FA39677F4-- From nobody Mon Mar 13 07:02:23 2017 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 474D012965E; Mon, 13 Mar 2017 07:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 oQQRPUiEPNxi; Mon, 13 Mar 2017 07:02:19 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D1B1129659; Mon, 13 Mar 2017 07:02:18 -0700 (PDT) X-AuditID: c1b4fb25-a57ff70000004cad-e3-58c6a6667486 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by (Symantec Mail Security) with SMTP id BA.84.19629.666A6C85; Mon, 13 Mar 2017 15:02:17 +0100 (CET) Received: from ESESSMB107.ericsson.se ([169.254.7.76]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0319.002; Mon, 13 Mar 2017 15:02:14 +0100 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= To: "core@ietf.org WG" Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV0dMQyBkcmFmdC1pZXRmLWNvcmUtY29hcC10Y3AtdGxz?= Thread-Index: AQHSh4Vo+RQKlqeONEqm4jDyprXEpqGS5QWA Date: Mon, 13 Mar 2017 14:02:13 +0000 Message-ID: <938FB795-A352-448A-B380-ABBFA2F04DE9@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_938FB795A352448AB380ABBFA2F04DE9ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMIsWRmVeSWpSXmKPExsUyM2J7lG7msmMRBv8+s1jcn/eIyWLf2/XM Fn8mLmZ0YPZYsuQnk0frjr/sAUxRXDYpqTmZZalF+nYJXBl3z7QxF3y0rjjZ8pKpgXGaVRcj J4eEgInEl18PGbsYuTiEBNYxSmyYvJEZwlnMKLFq+jZmkCo2AWeJT88a2UFsEQE1idZJr9hA bGaBJkaJ69frQWxhgRSJ3y9XskLUhEm8uXOMEcI2kmh4swKsnkVAVeJt12kmEJtXwF7i1NYf YLYQkP1/yTUWEJtTwEHi0N1VYLsYBcQkvp9awwSxS1zi1pP5TBBXC0gs2XOeGcIWlXj5+B8r hK0ksfbwdqA5HED1yRL/FqZArBKUODnzCcsERpFZSCbNQqiahaQKIqwpsX6XPkS1osSU7ofs ELaGROucuVC2tcTXFxNZkdUsYORYxShanFqclJtuZKyXWpSZXFycn6eXl1qyiREYdQe3/Fbd wXj5jeMhRgEORiUe3g2zjkYIsSaWFVfmHmKU4GBWEuF1mQkU4k1JrKxKLcqPLyrNSS0+xCjN waIkzmu28n64kEB6YklqdmpqQWoRTJaJg1OqgVGG3UxPvSHNd+P+FR6LpL+Fz2DQtjCbe0LS SLuPecr95fvfTz7K/z9ZbnesE8N5xmxH1ZJ7K+OW7F68b9f23qX/9Rfe2OE+OWjlaeX/rz8b OG33PVYnmfvpnNVKA+lf+vJpau5x09xN5S+9ObBxqpFN/EcBBemHGtMD/56oECwt7v+fm654 ykiJpTgj0VCLuag4EQCIf0ogtgIAAA== Archived-At: Cc: "draft-ietf-core-coap-tcp-tls@ietf.org" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_draft-ietf-core-coap-tcp-tls?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 14:02:20 -0000 --_000_938FB795A352448AB380ABBFA2F04DE9ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBDb1JFIFdHLA0KDQp3ZSBoYXZlIGV4dGVuZGVkIGEgYml0IHRoZSBjYWxsIGFzIHRoZXJl IHdlcmUgZmV3IGlzc3VlcyBsZWZ0LiBBdCB0aGlzIHBvaW50IHRoZXJlIGFyZW7igJl0IGFueSBv dGhlciBpc3N1ZXMgd2Ugd2lsbCBjbG9zZSB0aGlzIGNhbGwgYW5kIG1vdmUgdGhlIGRvY3VtZW50 IGZvcndhcmQuDQpMYXRlc3QgdmVyc2lvbjogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtY29yZS1jb2FwLXRjcC10bHMtMDcNCg0KVGhhbmtzISENCkphaW1lIEppbcOpbmV6 DQoNCk9uIDE1IEZlYiAyMDE3LCBhdCAxNC4xNywgSmFpbWUgSmltw6luZXogPGphaW1lLmppbWVu ZXpAZXJpY3Nzb24uY29tPG1haWx0bzpqYWltZS5qaW1lbmV6QGVyaWNzc29uLmNvbT4+IHdyb3Rl Og0KDQpEZWFyIENvUkUgV0csDQoNClRoZXJlIGhhcyBiZWVuIHF1aXRlIHNvbWUgd29yayBvbiB0 aGUgIkNvQVAgKENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29sKSBvdmVyIFRDUCwgVExT LCBhbmQgV2ViU29ja2V0c+KAnSBkcmFmdCAoZHJhZnQtaWV0Zi1jb3JlLWNvYXAtdGNwLXRscykg c2luY2UgdGhlIGxhc3QgV0dMQy4NCkJJRyB0aGFua3MgdG8gQnJpYW4gZm9yIHRoZSB0aW1lIGFu ZCBlZmZvcnQgZGVkaWNhdGVkIGFzIEVkaXRvci4gSXQgbm93IHNlZW1zIGEgZ29vZCB0aW1lIGZv ciBhIGZpbmFsIFdHTEMgdG8gZ2V0IHRoZSBsYXN0IGNvbW1lbnRzIGZyb20gdGhlIGdyb3VwIGlu IG9yZGVyIHRvIG1vdmUgdGhlIHNwZWNpZmljYXRpb24gZm9yd2FyZC4NCg0KSW4gcGFydGljdWxh ciB0aGVyZSBoYXMgbm90IGJlZW4gbXVjaCBkaXNjdXNzaW9uIG9uIHNlY3VyaW5nIENvQVAgb3Zl ciBXZWJTb2NrZXRzIChodHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9jb2FwLXRjcC10bHMvaXNz dWVzLzEwMikgYXMgd2VsbCBhcyB0aGUgRGVmYXVsdCBVUkkgaG9zdCAoaHR0cHM6Ly9naXRodWIu Y29tL2NvcmUtd2cvY29hcC10Y3AtdGxzL2lzc3Vlcy8xMDgpIGZlZWRiYWNrIHdvdWxkIGJlIHZl cnkgbXVjaCB3ZWxjb21lZC4gUGxlYXNlIGdvIGFoZWFkIGFuZCBjaGVjayB0aGUgZGlzY3Vzc2lv bnMgb24gdGhlIG90aGVyIGlzc3VlcyBvZiB0aGlzIHZlcnNpb246IGh0dHBzOi8vZ2l0aHViLmNv bS9jb3JlLXdnL2NvYXAtdGNwLXRscy9taWxlc3RvbmUvND9jbG9zZWQ9MSAgYW5kIG9uIHRoZSBj aGFuZ2Vsb2cgc3VtbWFyeS4gSW4gYWRkaXRpb24gdG8gdGhhdCwgSSB3b3VsZCBsaWtlIHRvIGFz ayB0aGUgZ3JvdXAgdG8gbGV0IG1lIGtub3cgdGhlaXIgY3VycmVudCBpbXBsZW1lbnRhdGlvbiBz dGF0dXMgb2YgdGhlIGRyYWZ0IGZvciB0aGUgc2hlcGhlcmQgd3JpdGV1cCwgZXNwZWNpYWxseSBP cGVuIFNvdXJjZSBpbXBsZW1lbnRhdGlvbnMgb2YgdGhlIGRyYWZ0Lg0KDQpsYXRlc3QgdmVyc2lv bjogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS1jb2FwLXRjcC10 bHMtMDYNCmRpZmY6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWll dGYtY29yZS1jb2FwLXRjcC10bHMtMDYudHh0DQpjaGFuZ2Vsb2c6IGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNvcmUtY29hcC10Y3AtdGxzLTA2I2FwcGVuZGl4LUMuNA0K DQpUaGUgV0dMQyB3aWxsIGxhc3Qgb25lIHdlZWssIHVudGlsIDIwMTctMDItMjIgLg0KDQpUaGFu a3MhDQpKYWltZSBKaW3DqW5leg0KDQo= --_000_938FB795A352448AB380ABBFA2F04DE9ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <3C82617770942549B61C04AE14FE6A68@ericsson.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5EZWFyIENv UkUgV0csPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj53ZSBoYXZlIGV4dGVuZGVkIGEgYml0IHRoZSBjYWxsIGFzIHRoZXJlIHdlcmUgZmV3 IGlzc3VlcyBsZWZ0LiBBdCB0aGlzIHBvaW50IHRoZXJlIGFyZW7igJl0IGFueSBvdGhlciBpc3N1 ZXMgd2Ugd2lsbCBjbG9zZSB0aGlzIGNhbGwgYW5kIG1vdmUgdGhlIGRvY3VtZW50IGZvcndhcmQu Jm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5MYXRlc3QgdmVyc2lv bjombmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1j b3JlLWNvYXAtdGNwLXRscy0wNyIgY2xhc3M9IiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtY29yZS1jb2FwLXRjcC10bHMtMDc8L2E+PC9kaXY+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoYW5rcyEhPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPkphaW1lIEppbcOpbmV6PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj5PbiAxNSBGZWIgMjAxNywgYXQgMTQuMTcsIEphaW1lIEppbcOp bmV6ICZsdDs8YSBocmVmPSJtYWlsdG86amFpbWUuamltZW5lekBlcmljc3Nvbi5jb20iIGNsYXNz PSIiPmphaW1lLmppbWVuZXpAZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIg Y2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg c3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAt d2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPkRlYXIgQ29SRSBXRyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoZXJlIGhhcyBiZWVuIHF1aXRlIHNvbWUgd29yayBvbiB0 aGUgJnF1b3Q7Q29BUCAoQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wpIG92ZXIgVENQ LCBUTFMsIGFuZCBXZWJTb2NrZXRz4oCdIGRyYWZ0IChkcmFmdC1pZXRmLWNvcmUtY29hcC10Y3At dGxzKSBzaW5jZSB0aGUgbGFzdCBXR0xDLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5CSUcg dGhhbmtzIHRvIEJyaWFuIGZvciB0aGUgdGltZSBhbmQgZWZmb3J0IGRlZGljYXRlZCBhcyBFZGl0 b3IuIEl0IG5vdyBzZWVtcyBhIGdvb2QgdGltZSBmb3IgYSBmaW5hbCBXR0xDIHRvIGdldCB0aGUg bGFzdCBjb21tZW50cyBmcm9tIHRoZSBncm91cCBpbiBvcmRlciB0byBtb3ZlIHRoZSBzcGVjaWZp Y2F0aW9uIGZvcndhcmQuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JbiBwYXJ0aWN1bGFyIHRoZXJlIGhhcyBub3QgYmVlbiBt dWNoIGRpc2N1c3Npb24gb24gc2VjdXJpbmcgQ29BUCBvdmVyIFdlYlNvY2tldHMgKDxhIGhyZWY9 Imh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL2NvYXAtdGNwLXRscy9pc3N1ZXMvMTAyIiBjbGFz cz0iIj5odHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9jb2FwLXRjcC10bHMvaXNzdWVzLzEwMjwv YT4pIGFzIHdlbGwgYXMgdGhlIERlZmF1bHQgVVJJIGhvc3QgKDxhIGhyZWY9Imh0dHBzOi8vZ2l0 aHViLmNvbS9jb3JlLXdnL2NvYXAtdGNwLXRscy9pc3N1ZXMvMTA4IiBjbGFzcz0iIj5odHRwczov L2dpdGh1Yi5jb20vY29yZS13Zy9jb2FwLXRjcC10bHMvaXNzdWVzLzEwODwvYT4pDQogZmVlZGJh Y2sgd291bGQgYmUgdmVyeSBtdWNoIHdlbGNvbWVkLiBQbGVhc2UgZ28gYWhlYWQgYW5kIGNoZWNr IHRoZSBkaXNjdXNzaW9ucyBvbiB0aGUgb3RoZXIgaXNzdWVzIG9mIHRoaXMgdmVyc2lvbjombmJz cDs8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9jb2FwLXRjcC10bHMvbWlsZXN0 b25lLzQ/Y2xvc2VkPTEiIGNsYXNzPSIiPmh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL2NvYXAt dGNwLXRscy9taWxlc3RvbmUvND9jbG9zZWQ9MTwvYT4mbmJzcDsmbmJzcDthbmQNCiBvbiB0aGUg Y2hhbmdlbG9nIHN1bW1hcnkuIEluIGFkZGl0aW9uIHRvIHRoYXQsIEkgd291bGQgbGlrZSB0byBh c2sgdGhlIGdyb3VwIHRvIGxldCBtZSBrbm93IHRoZWlyIGN1cnJlbnQgaW1wbGVtZW50YXRpb24g c3RhdHVzIG9mIHRoZSBkcmFmdCBmb3IgdGhlIHNoZXBoZXJkIHdyaXRldXAsIGVzcGVjaWFsbHkg T3BlbiBTb3VyY2UgaW1wbGVtZW50YXRpb25zIG9mIHRoZSBkcmFmdC48L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij5sYXRlc3QgdmVyc2lvbjombmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1jb3JlLWNvYXAtdGNwLXRscy0wNiIgY2xhc3M9IiI+aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS1jb2FwLXRjcC10bHMtMDY8L2E+PC9kaXY+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ZGlmZjombmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xz LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWNvcmUtY29hcC10Y3AtdGxzLTA2LnR4 dCIgY2xhc3M9IiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0 Zi1jb3JlLWNvYXAtdGNwLXRscy0wNi50eHQ8L2E+Jm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIi PmNoYW5nZWxvZzombmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1jb3JlLWNvYXAtdGNwLXRscy0wNiNhcHBlbmRpeC1DLjQiIGNsYXNzPSIiPmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNvcmUtY29hcC10Y3AtdGxzLTA2I2Fw cGVuZGl4LUMuNDwvYT4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoZSBXR0xDIHdpbGwgbGFzdCBvbmUgd2VlaywgdW50aWwm bmJzcDs8YiBjbGFzcz0iIj4yMDE3LTAyLTIyPC9iPiAuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGFua3MhPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPkphaW1lIEppbcOpbmV6PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_938FB795A352448AB380ABBFA2F04DE9ericssoncom_-- From nobody Mon Mar 13 07:03:45 2017 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 AEEA012966F for ; Mon, 13 Mar 2017 07:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.832 X-Spam-Level: X-Spam-Status: No, score=-0.832 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 yfDiEU_SqrP1 for ; Mon, 13 Mar 2017 07:03:41 -0700 (PDT) Received: from buffalo.u-blox.com (buffalo.u-blox.com [195.34.89.137]) by ietfa.amsl.com (Postfix) with SMTP id 85001128824 for ; Mon, 13 Mar 2017 07:03:40 -0700 (PDT) Received: from mail_filter (localhost [127.0.0.1]) by buffalo.u-blox.com (PF_LO_10026) with ESMTP id 1AD4415F688 for ; Mon, 13 Mar 2017 15:03:38 +0100 (CET) Received: from ASSP.nospam (localhost [127.0.0.1]) by buffalo.u-blox.com (Postfix) with ESMTP id 0664815F63B; Mon, 13 Mar 2017 15:03:38 +0100 (CET) X-Assp-Resend-Blocked: ASSP.nospam X-Assp-Version: 2.4.7(16004) on ASSP.nospam X-Assp-ID: ASSP.nospam 10964-27264 X-Assp-Session: 7A46C024 (mail 1) X-Assp-Detected-RIP: 108.201.184.41 X-Assp-Source-IP: 108.201.184.41 X-Assp-Original-Subject: Re: [core] Questions/comments on draft-ietf-core-dynlink-02 X-Assp-Client-TLS: yes X-Assp-Delay: not delayed (gripvalue low: 0.08); 13 Mar 201714:16:04 +0100 X-Assp-Message-Score: -18 (74.125.82.0 in griplist (0.08)) X-Original-Authentication-Results: ASSP.nospam; spf=pass X-Assp-Message-Score: -1 (SPF pass) X-Assp-IP-Score: -1 (SPF pass) X-Assp-Message-Score: 49 (Bayesian Probability: 1.00000) X-Assp-IP-Score: 49 (Bayesian Probability: 1.00000) X-Assp-Spam-Prob: 1.00000 X-Assp-Tag: Bayesian X-Assp-Spam-Reason: Bayesian X-Assp-Message-Totalscore: 30 Received: from mail-ot0-f172.google.com ([74.125.82.172] helo=mail-ot0-f172.google.com)by ASSP.nospam with SMTPS(AES128-GCM-SHA256) (2.4.7); 13 Mar 2017 14:16:03 +0100 Received: by mail-ot0-f172.google.com with SMTP id i1so112099395ota.3 for ; Mon, 13 Mar 2017 06:16:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=9tbAk1ZmEIqLD37cD5EPj44PG9fyDpwXK70gZwHhatU=; b=FyDWXlo39h52g0T7t5cb3sJV2fD0ZwczzmU5T/JVNEx2oBzKxutgGlJHzsq+MOHmqK o3IFeQqR1GwT3UHD4UYJemvJ/CNG4A02mB7bunPHKWxovQ6vXyHhZmysP1qIonKVb7J2 n0SA5ubwTkE5i6pJOGu2OqAaF6vDaLzVKfOUuYx5Ev9NhQo3VkAxPTcVibIHkiJWN6Qx qx8nLn57JURycQiHFK6h4hzYtC/0qbH9lLykHpjpJANQq37W2ZV8YXaocUdXjB/FH2vd SNMu/RQk3QXAjaBidfc64YFRy1aL37mLiawIIfMpFO4p4hkNYjSzO4KLlOVAPSWN7W5c sFZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=9tbAk1ZmEIqLD37cD5EPj44PG9fyDpwXK70gZwHhatU=; b=OpRPGVkcf1P3hoUGy4FD+q9JIgMBzJwe+GtJJeWg32uPIfht5rfmUyN2xhU7uwy7/b 6tSKwj4kE7yo+MM2eV5nF1Q48pIAau2IK8olHZ2wseMPBI3sTnBTJVzN/IwBzO8RQRbA KxGMWKIRbDwyrMEB+GvrOgupmpWPGllvFmyAWVSq7/IRiLQHpyQMU7/Uuqz41KIkL3Hv VoAbyDD+iGGJ+LA3b0MjMwWewyIMML6Zkt9ErIcdhI0DJjaKmO8s7MzVqYoA7AbiT+Hw iKrpROajCpmFZnbwMzIPsoML6MajYAlBjTgLfy+ADT/CK4dE91ls5bhYsDxBdrA4tWVx 67Vw== X-Gm-Message-State: AMke39lPC52UnE2f5Uei//rkOIwABhOzSCA2QfjLm09L8+CXjYu6gRM3eEQRQLUwyue++w== X-Received: by 10.157.49.47 with SMTP id e44mr16417555otc.129.1489410492254; Mon, 13 Mar 2017 06:08:12 -0700 (PDT) Received: from [10.0.0.11] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id t8sm7986742oib.23.2017.03.13.06.08.11 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 13 Mar 2017 06:08:11 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_DC2C98F6-0C19-4E5B-B2C9-729FA39677F4" From: Michael Koster X-Priority: 3 (Normal) In-Reply-To: Date: Mon, 13 Mar 2017 06:08:09 -0700 Message-Id: References: To: Mojan Mohajer X-Mailer: Apple Mail (2.2104) X-Virus-Scanned: clamav-milter 0.99.2 at buffalo X-Virus-Status: Clean Archived-At: Cc: core Subject: Re: [core] Questions/comments on draft-ietf-core-dynlink-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 14:03:43 -0000 --Apple-Mail=_DC2C98F6-0C19-4E5B-B2C9-729FA39677F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 To summarize, I recommend that we change 4.2 to specify using observe = attributes as query parameters in the OBSERVE operation to which they = apply. We could optionally make them writeable as a single set of attributes to = apply to all observations of that resource. If we want to make the single set readable, we will need to add more = specification. about the returned representation. Best regards, Michael > On Mar 13, 2017, at 5:58 AM, Michael Koster = wrote: >=20 > Hi Mojan, >=20 > I think this is the default behavior for OMA LWM2M using the "Write = Attributes" operation. The effect is to provide a single set of = notification parameters for all observe operations on that resource. >=20 > I believe that we improve on that pattern and allow each observe = request to have its own attributes, set by including query parameters in = the GET operation. >=20 > Section 4.2 also indicates that they are readable, but it's not clear = to me how that would work? In what format are they returned, also as = query parameters? These could be made readable (and updateable) througn = a special CoRE Interface, but we would need to specify how the content = format of these works vs. the content format of the resource state. >=20 > LWM2M could be described in this draft as a legacy pattern. >=20 > Does this make sense? >=20 > Best regards, >=20 > Michael >=20 >=20 >> On Mar 10, 2017, at 2:52 AM, Mojan Mohajer > wrote: >>=20 >> 2) Section 4.2 which covers resource observation attributes (pmin, = pmax, st, =85) states that that: =85=94These query parameters MUST be = treated as resources that are read using GET and updated using PUT, and = MUST NOT be included in the Observe request=94 =85. >> However, looking at newly added Annex A which provides observation = examples, these observation attributes are passed as query parameters of = a Get request with Observe option set to 0. There seems to be some = contradiction between the text in section 4.2 and the example in Annex = A. >=20 --Apple-Mail=_DC2C98F6-0C19-4E5B-B2C9-729FA39677F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 To summarize, I recommend that we change 4.2 to specify using = observe attributes as query parameters in the OBSERVE operation to which = they apply.

We could = optionally make them writeable as a single set of attributes to apply to = all observations of that resource.

If we want to make the single set = readable, we will need to add more specification. about the returned = representation.

Best regards,

Michael


On Mar 13, 2017, at 5:58 AM, = Michael Koster <michaeljohnkoster@gmail.com> wrote:

Hi Mojan,

I think this is the = default behavior for OMA LWM2M using the "Write Attributes" operation. = The effect is to provide a single set of notification parameters for all = observe operations on that resource.

I believe that we improve on that = pattern and allow each observe request to have its own attributes, set = by including query parameters in the GET operation.

Section 4.2 also = indicates that they are readable, but it's not clear to me how that = would work? In what format are they returned, also as query parameters? = These could be made readable (and updateable) througn a special CoRE = Interface, but we would need to specify how the content format of these = works vs. the content format of the resource state.

LWM2M could be described = in this draft as a legacy pattern.

Does this make sense?

Best regards,

Michael


On Mar 10, 2017, at 2:52 AM, Mojan Mohajer <mojan.mohajer@u-blox.com> wrote:

2) Section 4.2 which covers resource observation = attributes (pmin, pmax, st, =85) states that that: =85=94These query = parameters MUST be treated as resources that are read using GET and = updated using PUT, and MUST NOT be included in the Observe request=94 = =85.
However, looking at newly = added Annex A which provides observation examples, these observation = attributes are passed as query parameters of a Get request with Observe = option set to 0. There seems to be some contradiction between the text = in section 4.2 and the example in Annex A.


= --Apple-Mail=_DC2C98F6-0C19-4E5B-B2C9-729FA39677F4-- From nobody Mon Mar 13 07:03:52 2017 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 ED94412966D for ; Mon, 13 Mar 2017 07:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.332 X-Spam-Level: X-Spam-Status: No, score=-1.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 jFNqMaI23dlz for ; Mon, 13 Mar 2017 07:03:51 -0700 (PDT) Received: from buffalo.u-blox.com (buffalo.u-blox.com [195.34.89.137]) by ietfa.amsl.com (Postfix) with SMTP id DECEE12966F for ; Mon, 13 Mar 2017 07:03:49 -0700 (PDT) Received: from mail_filter (localhost [127.0.0.1]) by buffalo.u-blox.com (PF_LO_10026) with ESMTP id 32D6A15F690 for ; Mon, 13 Mar 2017 15:03:48 +0100 (CET) Received: from ASSP.nospam (localhost [127.0.0.1]) by buffalo.u-blox.com (Postfix) with ESMTP id 1D8AD15F63B; Mon, 13 Mar 2017 15:03:48 +0100 (CET) X-Assp-Resend-Blocked: ASSP.nospam X-Assp-Version: 2.4.7(16004) on ASSP.nospam X-Assp-ID: ASSP.nospam 09893-06682 X-Assp-Session: F084B08 (mail 1) X-Assp-Detected-RIP: 108.201.184.41 X-Assp-Source-IP: 108.201.184.41 X-Assp-Original-Subject: Re: [core] Questions/comments on draft-ietf-core-dynlink-02 X-Assp-Client-TLS: yes X-Assp-Delay: not delayed (gripvalue low: 0.17); 13 Mar 201713:58:13 +0100 X-Assp-Message-Score: -10 (209.85.161.0 in griplist (0.17)) X-Original-Authentication-Results: ASSP.nospam; spf=pass X-Assp-Message-Score: -1 (SPF pass) X-Assp-IP-Score: -1 (SPF pass) X-Assp-Message-Score: 49 (Bayesian Probability: 1.00000) X-Assp-IP-Score: 49 (Bayesian Probability: 1.00000) X-Assp-Spam-Prob: 1.00000 X-Assp-Tag: Bayesian X-Assp-Spam-Reason: Bayesian X-Assp-Message-Totalscore: 38 Received: from mail-yw0-f177.google.com ([209.85.161.177] helo=mail-yw0-f177.google.com)by ASSP.nospam with SMTPS(AES128-GCM-SHA256) (2.4.7); 13 Mar 2017 13:58:12 +0100 Received: by mail-yw0-f177.google.com with SMTP id p77so58052662ywg.1 for ; Mon, 13 Mar 2017 05:58:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=vwoMpRyfdCU0B48JWZitWlBG4XjELGXwmTARHWxIFgI=; b=UkbFG9tNMkNA3EwiTWS/O7Ql6f3zmi4PtZrq9e+FT8FXoK8q4o3X5Tq1zL/vQkPL/e Dltsz6kA1ha0oPMz6x6Q7TB5Dc2KyksVeE2+neF8dPk6/+p5FprE6QDGDvajy3jZUlWN FcT5570nTWu6D3DXudVGIVSCG3SIDmyKcdoseeGqn3L1lK6WJr7hYVmMj3Yvv1Swfw+R IrCytbVtU6bOFTt0D5stmN2ggPgWCszZrWFpAbcBxFfMNo9FJ347FcltKsiESSU8ete1 pomfWPunV+/C9ZK6gyFZantbbNvAfY/JjRrwF4kFHfkAhRccT6xV1d8HJVPvkOybMQqM m2jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=vwoMpRyfdCU0B48JWZitWlBG4XjELGXwmTARHWxIFgI=; b=qLaz3k7NJyxQp4Qw40I7e/V+2FPXTu4jOqPufe5p84I6Dyj2GIupVgBkAz7Ikd01EP z8E3JbtTvhnRBTwBrK2qtbyF40bXRV7WbdmsJzB1/qhIPp5EfxR54ofmhrxmZbcHa15G 1WMgfNlERQo/N2JlNaDzWLaVkjX39P3Qf2esFfNEU6uOBtX1nuk0gm0ANLY7YNDqwGv4 //IAO7XVTkTcNfIqkIHeN+8/9U1TEUb91c7j0QvHV/QnDlQI2b3BYk3VWK1IMlMV8z4W Yf3efJNbx+dNJuINnOxrz6mAlTGvzLKGVe8wRH4NAVbYMyrzEGCjOvbP3sSDO/qVFpuV c6Pw== X-Gm-Message-State: AMke39nRiCm1eLSweJIiEIMzBOpqwTjKMj4UjfNh1ux36dt4ZFK6Y9hT2N9VLtJynjAYSQ== X-Received: by 10.37.173.218 with SMTP id d26mr17800861ybe.120.1489409891718; Mon, 13 Mar 2017 05:58:11 -0700 (PDT) Received: from [10.0.0.11] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id 1sm7381519ywb.72.2017.03.13.05.58.10 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 13 Mar 2017 05:58:11 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_6472F561-B955-44A4-811B-8772626B0AC9" From: Michael Koster X-Priority: 3 (Normal) In-Reply-To: Date: Mon, 13 Mar 2017 05:58:08 -0700 Message-Id: References: To: Mojan Mohajer X-Mailer: Apple Mail (2.2104) X-Virus-Scanned: clamav-milter 0.99.2 at buffalo X-Virus-Status: Clean Archived-At: Cc: core Subject: Re: [core] Questions/comments on draft-ietf-core-dynlink-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 14:03:52 -0000 --Apple-Mail=_6472F561-B955-44A4-811B-8772626B0AC9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Mojan, I think this is the default behavior for OMA LWM2M using the "Write = Attributes" operation. The effect is to provide a single set of = notification parameters for all observe operations on that resource. I believe that we improve on that pattern and allow each observe request = to have its own attributes, set by including query parameters in the GET = operation. Section 4.2 also indicates that they are readable, but it's not clear to = me how that would work? In what format are they returned, also as query = parameters? These could be made readable (and updateable) througn a = special CoRE Interface, but we would need to specify how the content = format of these works vs. the content format of the resource state. LWM2M could be described in this draft as a legacy pattern. Does this make sense? Best regards, Michael > On Mar 10, 2017, at 2:52 AM, Mojan Mohajer = wrote: >=20 > 2) Section 4.2 which covers resource observation attributes (pmin, = pmax, st, =85) states that that: =85=94These query parameters MUST be = treated as resources that are read using GET and updated using PUT, and = MUST NOT be included in the Observe request=94 =85. > However, looking at newly added Annex A which provides observation = examples, these observation attributes are passed as query parameters of = a Get request with Observe option set to 0. There seems to be some = contradiction between the text in section 4.2 and the example in Annex = A. --Apple-Mail=_6472F561-B955-44A4-811B-8772626B0AC9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Mojan,

I= think this is the default behavior for OMA LWM2M using the "Write = Attributes" operation. The effect is to provide a single set of = notification parameters for all observe operations on that = resource.

I = believe that we improve on that pattern and allow each observe request = to have its own attributes, set by including query parameters in the GET = operation.

Section 4.2 also indicates that they are readable, but it's = not clear to me how that would work? In what format are they returned, = also as query parameters? These could be made readable (and updateable) = througn a special CoRE Interface, but we would need to specify how the = content format of these works vs. the content format of the resource = state.

LWM2M = could be described in this draft as a legacy pattern.

Does this make = sense?

Best = regards,

Michael


On Mar 10, 2017, at 2:52 AM, = Mojan Mohajer <mojan.mohajer@u-blox.com> wrote:

2) Section 4.2 which covers resource observation = attributes (pmin, pmax, st, =85) states that that: =85=94These query = parameters MUST be treated as resources that are read using GET and = updated using PUT, and MUST NOT be included in the Observe request=94 = =85.
However, looking at newly = added Annex A which provides observation examples, these observation = attributes are passed as query parameters of a Get request with Observe = option set to 0. There seems to be some contradiction between the text = in section 4.2 and the example in Annex A.

= --Apple-Mail=_6472F561-B955-44A4-811B-8772626B0AC9-- From nobody Mon Mar 13 08:05:56 2017 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 B849B1296AA for ; Mon, 13 Mar 2017 08:05: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 JhwZbte3DG0f for ; Mon, 13 Mar 2017 08:05:52 -0700 (PDT) Received: from buffalo.u-blox.com (buffalo.u-blox.com [195.34.89.137]) by ietfa.amsl.com (Postfix) with SMTP id 2D70012960D for ; Mon, 13 Mar 2017 08:05:51 -0700 (PDT) Received: from mail_filter (localhost [127.0.0.1]) by buffalo.u-blox.com (PF_LO_10026) with ESMTP id C8ECE15F6B7 for ; Mon, 13 Mar 2017 16:05:49 +0100 (CET) Received: from ASSP.nospam (localhost [127.0.0.1]) by buffalo.u-blox.com (Postfix) with ESMTP id 9C52A15F6A3; Mon, 13 Mar 2017 16:05:49 +0100 (CET) Received: from unknown ([127.0.0.1] helo=anyhost.local) by ASSP.nospam with SMTP (2.4.7); 13 Mar 2017 16:05:49 +0100 From: =?windows-1252?Q?Mojan_Mohajer?= To: =?windows-1252?Q?Michael_Koster?= Date: Mon, 13 Mar 2017 16:05:49 +0100 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_dlHNX8dG-ZxwOAoUu6zZjMTcCdI5aSBt7YMZhiV-oKHREwvJ" In-Reply-To: References: X-Priority: 3 (Normal) X-Mailer: Zarafa 7.1.14-51822 Thread-Index: AdKcC0u6rUV8cuD0S4+w6iB+BbkTyQ== Message-Id: X-Assp-Version: 2.4.7(16004) on ASSP.nospam X-Assp-ID: ASSP.nospam 17549-22888 X-Assp-Session: 74FD6988 (mail 1) X-Assp-Original-Subject: RE: [core] Questions/comments on draft-ietf-core-dynlink-02 X-Virus-Scanned: clamav-milter 0.99.2 at buffalo X-Virus-Status: Clean Archived-At: Cc: =?windows-1252?Q?core?= Subject: Re: [core] Questions/comments on draft-ietf-core-dynlink-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 15:05:55 -0000 This is a multi-part message in MIME format. Your mail reader does not understand MIME message format. --=_dlHNX8dG-ZxwOAoUu6zZjMTcCdI5aSBt7YMZhiV-oKHREwvJ Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Michael,=0D=0A=0D=0AYes, the current version of LwM2M requires the use= of =93Write Attribute=94 which as you pointed out provides a single set = of notifications parameters. This in itself could be rather problematic i= n use cases where there are two observers of the same resource with diffe= ring requirements of observe attributes. As per example A in the document= and your suggestion it seems more logical to pass the observation attrib= utes in the get operation and make them somewhat transaction oriented rat= her than simply attached to the resource. By doing so, a resource can acc= ommodate multiple observers with different observation rules as required.= BTW, couple of companies have already put forward proposals to add suppo= rt for passing of these attributes in the GET operation in the next versi= on of OMA LwM2M specification.=20=0D=0A=0D=0ABest Regards,=0D=0A=0D=0AMoj= an=0D=0A=0D=0A=A0=0D=0A=A0=0D=0A=A0=0D=0AFrom: Michael Koster [mailto:mic= haeljohnkoster@gmail.com]=20=0D=0ASent: 13 March 2017 12:58=0D=0ATo: Moja= n Mohajer=0D=0ACc: core=0D=0ASubject: Re: [core] Questions/comments on dr= aft-ietf-core-dynlink-02=0D=0A=0D=0A=A0=0D=0AHi Mojan,=0D=0A=0D=0A=A0=0D=0A= I think this is the default behavior for OMA LWM2M using the "Write Attri= butes" operation. The effect is to provide a single set of notification p= arameters for all observe operations on that resource.=0D=0A=0D=0A=A0=0D=0A= I believe that we improve on that pattern and allow each observe request = to have its own attributes, set by including query parameters in the GET = operation.=0D=0A=0D=0A=A0=0D=0ASection 4.2 also indicates that they are r= eadable, but it's not clear to me how that would work=3F In what format a= re they returned, also as query parameters=3F These could be made readabl= e (and updateable) througn a special CoRE Interface, but we would need to= specify how the content format of these works vs. the content format of = the resource state.=0D=0A=0D=0A=A0=0D=0ALWM2M could be described in this = draft as a legacy pattern.=0D=0A=0D=0A=A0=0D=0ADoes this make sense=3F=0D= =0A=0D=0A=A0=0D=0ABest regards,=0D=0A=0D=0A=A0=0D=0AMichael=0D=0A=0D=0A=A0= =0D=0A=A0=0D=0AOn Mar 10, 2017, at 2:52 AM, Mojan Mohajer > wrote:=0D=0A=0D=0A=A0=0D=0A= 2) Section 4.2 which covers resource observation attributes (pmin, pmax, = st, =85) states that that: =85=94These query parameters MUST be treated a= s resources that are read using GET and updated using PUT, and MUST NOT b= e included in the Observe request=94 =85.=0D=0AHowever, looking at newly = added Annex A which provides observation examples, these observation attr= ibutes are passed as query parameters of a Get request with Observe optio= n set to 0. There seems to be some contradiction between the text in sect= ion 4.2 and the example in Annex A.=0D=0A=0D=0A=A0=0D=0A --=_dlHNX8dG-ZxwOAoUu6zZjMTcCdI5aSBt7YMZhiV-oKHREwvJ Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

= Hi Michael,

Y= es, the current version of LwM2M requires the use of “Write Attribu= te” which as you pointed out provides a single set of notifications= parameters. This in itself could be rather problematic in use cases wher= e there are two observers of the same resource with differing requirement= s of observe attributes. As per example A in the document and your sugges= tion it seems more logical to pass the observation attributes in the get = operation and make them somewhat transaction oriented rather than simply = attached to the resource. By doing so, a resource can accommodate multipl= e observers with different observation rules as required. BTW, couple of = companies have already put forward proposals to add support for passing o= f these attributes in the GET operation in the next version of OMA LwM2M = specification.

Best R= egards,

Mojan

 

 

 

From: Michael Koster [mailto:michaeljohn= koster@gmail.com]
Sent: 13 March 2017 12:58
To: Moja= n Mohajer
Cc: core
Subject: Re: [core] Questions/comm= ents on draft-ietf-core-dynlink-02

 

Hi Mojan,<= /o:p>

 

I think this is the default behavior for OMA LWM2M using t= he "Write Attributes" operation. The effect is to provide a sin= gle set of notification parameters for all observe operations on that res= ource.

 

I believe that we improve on that patter= n and allow each observe request to have its own attributes, set by inclu= ding query parameters in the GET operation.

 

Sec= tion 4.2 also indicates that they are readable, but it's not clear to me = how that would work=3F In what format are they returned, also as query pa= rameters=3F These could be made readable (and updateable) througn a speci= al CoRE Interface, but we would need to specify how the content format of= these works vs. the content format of the resource state.

=

 

LWM2M could be described in this draft as a legacy pattern.

 

Does this make sense=3F

<= p class=3DMsoNormal> 

= Best regards,

 

Michael

=

 

 

On Mar 10, 2017, at 2:5= 2 AM, Mojan Mohajer <mojan= =2Emohajer@u-blox.com> wrote:

 

2) Section 4.2 which cove= rs resource observation attributes (pmin, pmax, st, …) states that = that: …”These query parameters MUST be treated as resources t= hat are read using GET and updated using PUT, and MUST NOT be included in= the Observe request” ….
However, looking at newly added A= nnex A which provides observation examples, these observation attributes = are passed as query parameters of a Get request with Observe option set t= o 0. There seems to be some contradiction between the text in section 4.2= and the example in Annex A.

 

--=_dlHNX8dG-ZxwOAoUu6zZjMTcCdI5aSBt7YMZhiV-oKHREwvJ-- From nobody Mon Mar 13 08:28:53 2017 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 6FBD51294A2 for ; Mon, 13 Mar 2017 08:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 svdvNltp8sFj for ; Mon, 13 Mar 2017 08:28:51 -0700 (PDT) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::22c]) (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 CFF9412947C for ; Mon, 13 Mar 2017 08:28:50 -0700 (PDT) Received: by mail-ot0-x22c.google.com with SMTP id i1so114803333ota.3 for ; Mon, 13 Mar 2017 08:28:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=FeuDt7MOLJyCtxCYAUgcxL5ZHvYUlk2mgWIP6MCaojQ=; b=ZAvZS1H7RGDrrZPdxDGeALXKL7e8ppAWLAwrF/dS9DzKucsYzBW8D1NC4XUjAT+Gqy xpn67UQIB7ezBRY6035USw6sgItHU+LkRWYiksDy28REHCXw5xckIMR3fjekv+USgHyl xFdhxPEyq+GOrntKUOzCHfjnQBp/1TI4jxz0f/oHV+jgtfKHLg5ZmiXVQ+B+k4elsPpm 0Pa0Ec1nW9RwWIohKdQ69+nCVWms2ew0mAwtUiTU4VWoAENn5eFAtRKfoe95UGgclZRi 1TRLZPDqZdcThILzXuBAQTtSCykigoHkFIqeNxp7N/fVvyjYX83KXxS/g9OF4GC/eW1J Zq1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=FeuDt7MOLJyCtxCYAUgcxL5ZHvYUlk2mgWIP6MCaojQ=; b=alKmAjJ7U3ihkauHUbp/LLLFVY6uGznShA9DyeRKFa91gAb/mGHSEKZXliBZh8Iv/E mwVbDUOV71sCOp02L3zW8Ax3HE/mAmtPq7KT5yOTLxPiiNbpx+Olztof4OcStU3UTT/O axR0/vDUBGEJRavqA2/LB/i1NkAU1x3BG6HJ7KLQJxCFQEiBgaoP9IkF9znZ6HgC0oi/ +WZ31ueYoTprY2iXqnjFTQ1jbLUmTdCLj4TCttjs91O/dNTkU2ZEl2m7Iq75dZNdNLcL treHpfISo/ShX26kWS23NGpEoXGo5cEAJkvu0MRn/vTqJBrMJlT2jbg5Q3rlElyz3xhl HG8Q== X-Gm-Message-State: AMke39nsQnjhKJzyp8I0OiWuAoMLKJeA/yUwqyBWEbhbc4DkSbe9xjC0nfncQUkCWAUQrw== X-Received: by 10.157.63.119 with SMTP id m110mr15711938otc.63.1489418930239; Mon, 13 Mar 2017 08:28:50 -0700 (PDT) Received: from [10.0.0.11] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id b184sm8096404oia.34.2017.03.13.08.28.49 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 13 Mar 2017 08:28:49 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_C4065BAB-1752-4655-BB35-31ECCA96BABB" From: Michael Koster X-Priority: 3 (Normal) In-Reply-To: Date: Mon, 13 Mar 2017 08:28:47 -0700 Message-Id: <2188A0A1-3BD2-4BDE-AE17-7D434C001C06@gmail.com> References: To: Mojan Mohajer X-Mailer: Apple Mail (2.2104) Archived-At: Cc: core Subject: Re: [core] Questions/comments on draft-ietf-core-dynlink-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 15:28:52 -0000 --Apple-Mail=_C4065BAB-1752-4655-BB35-31ECCA96BABB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 OK, that makes sense. Do you think there is still a use case for a simple implementation (as I = did in ARM mbed) that only keeps a single set of attributes? Should we support both the global setting and a per-observe override? Or should we deprecte the single attribute set and only support = per-observe attributes going forward? FWIW, There is another SDO that is in the process of specifying an = optional (single) setting for each resource instance, using a "composed" = resource. Best regards, Michael > On Mar 13, 2017, at 8:05 AM, Mojan Mohajer = wrote: >=20 > Hi Michael, > Yes, the current version of LwM2M requires the use of =93Write = Attribute=94 which as you pointed out provides a single set of = notifications parameters. This in itself could be rather problematic in = use cases where there are two observers of the same resource with = differing requirements of observe attributes. As per example A in the = document and your suggestion it seems more logical to pass the = observation attributes in the get operation and make them somewhat = transaction oriented rather than simply attached to the resource. By = doing so, a resource can accommodate multiple observers with different = observation rules as required. BTW, couple of companies have already put = forward proposals to add support for passing of these attributes in the = GET operation in the next version of OMA LwM2M specification.=20 > Best Regards, > Mojan > =20 > =20 > =20 > From: Michael Koster [mailto:michaeljohnkoster@gmail.com]=20 > Sent: 13 March 2017 12:58 > To: Mojan Mohajer > Cc: core > Subject: Re: [core] Questions/comments on draft-ietf-core-dynlink-02 > =20 > Hi Mojan, > =20 > I think this is the default behavior for OMA LWM2M using the "Write = Attributes" operation. The effect is to provide a single set of = notification parameters for all observe operations on that resource. > =20 > I believe that we improve on that pattern and allow each observe = request to have its own attributes, set by including query parameters in = the GET operation. > =20 > Section 4.2 also indicates that they are readable, but it's not clear = to me how that would work? In what format are they returned, also as = query parameters? These could be made readable (and updateable) througn = a special CoRE Interface, but we would need to specify how the content = format of these works vs. the content format of the resource state. > =20 > LWM2M could be described in this draft as a legacy pattern. > =20 > Does this make sense? > =20 > Best regards, > =20 > Michael > =20 > =20 > On Mar 10, 2017, at 2:52 AM, Mojan Mohajer > wrote: > =20 > 2) Section 4.2 which covers resource observation attributes (pmin, = pmax, st, =85) states that that: =85=94These query parameters MUST be = treated as resources that are read using GET and updated using PUT, and = MUST NOT be included in the Observe request=94 =85. > However, looking at newly added Annex A which provides observation = examples, these observation attributes are passed as query parameters of = a Get request with Observe option set to 0. There seems to be some = contradiction between the text in section 4.2 and the example in Annex = A. --Apple-Mail=_C4065BAB-1752-4655-BB35-31ECCA96BABB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 OK, that makes sense.

Do you think there is still a use case for a simple = implementation (as I did in ARM mbed) that only keeps a single set of = attributes?

Should we support both the global setting and a per-observe = override?

Or = should we deprecte the single attribute set and only support per-observe = attributes going forward?

FWIW, There is another SDO that is in the process of = specifying an optional (single) setting for each resource instance, = using a "composed" resource.

Best regards,

Michael

On = Mar 13, 2017, at 8:05 AM, Mojan Mohajer <mojan.mohajer@u-blox.com> wrote:

Hi Michael,
Yes, the current version of LwM2M requires = the use of =93Write Attribute=94 which as you pointed out provides a = single set of notifications parameters. This in itself could be rather = problematic in use cases where there are two observers of the same = resource with differing requirements of observe attributes. As per = example A in the document and your suggestion it seems more logical to = pass the observation attributes in the get operation and make them = somewhat transaction oriented rather than simply attached to the = resource. By doing so, a resource can accommodate multiple observers = with different observation rules as required. BTW, couple of companies = have already put forward proposals to add support for passing of these = attributes in the GET operation in the next version of OMA LwM2M = specification. 
Best Regards,
Mojan
 
 
 
From: Michael = Koster [mailto:michaeljohnkoster@gmail.com] 
Sent: 13 = March 2017 12:58
To: Mojan Mohajer
Cc: core
Subject: Re: [core] = Questions/comments on draft-ietf-core-dynlink-02
 
Hi Mojan,
 
I think this is the default behavior for OMA LWM2M = using the "Write Attributes" operation. The effect is to provide a = single set of notification parameters for all observe operations on that = resource.
 
I believe that we improve on that pattern and allow = each observe request to have its own attributes, set by including query = parameters in the GET operation.
 
Section 4.2 also indicates that they are readable, = but it's not clear to me how that would work? In what format are they = returned, also as query parameters? These could be made readable (and = updateable) througn a special CoRE Interface, but we would need to = specify how the content format of these works vs. the content format of = the resource state.
 
LWM2M could be described in this draft as a legacy = pattern.
 
Does this make sense?
 
Best regards,
 
Michael
 
 
On = Mar 10, 2017, at 2:52 AM, Mojan Mohajer <mojan.mohajer@u-blox.com> = wrote:
 
2) Section 4.2 which = covers resource observation attributes (pmin, pmax, st, =85) states that = that: =85=94These query parameters MUST be treated as resources that are = read using GET and updated using PUT, and MUST NOT be included in the = Observe request=94 =85.
However, looking at newly added = Annex A which provides observation examples, these observation = attributes are passed as query parameters of a Get request with Observe = option set to 0. There seems to be some contradiction between the text = in section 4.2 and the example in Annex = A.

= --Apple-Mail=_C4065BAB-1752-4655-BB35-31ECCA96BABB-- From nobody Mon Mar 13 09:01:46 2017 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 473EC129506 for ; Mon, 13 Mar 2017 09:01:45 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 TaGSaeO7UuYe for ; Mon, 13 Mar 2017 09:01:42 -0700 (PDT) Received: from buffalo.u-blox.com (buffalo.u-blox.com [195.34.89.137]) by ietfa.amsl.com (Postfix) with SMTP id 34D5612941A for ; Mon, 13 Mar 2017 09:01:30 -0700 (PDT) Received: from mail_filter (localhost [127.0.0.1]) by buffalo.u-blox.com (PF_LO_10026) with ESMTP id 27B1A15F6AE for ; Mon, 13 Mar 2017 17:01:28 +0100 (CET) Received: from ASSP.nospam (localhost [127.0.0.1]) by buffalo.u-blox.com (Postfix) with ESMTP id E3D0F15F5DA; Mon, 13 Mar 2017 17:01:27 +0100 (CET) Received: from unknown ([127.0.0.1] helo=anyhost.local) by ASSP.nospam with SMTP (2.4.7); 13 Mar 2017 17:01:27 +0100 From: =?windows-1252?Q?Mojan_Mohajer?= To: =?windows-1252?Q?Michael_Koster?= Date: Mon, 13 Mar 2017 17:01:27 +0100 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_n9IN1Td0DDGTOO7pvEEdVAvFMQgzhFcnnLEV21JVeQFsy8gF" In-Reply-To: <2188A0A1-3BD2-4BDE-AE17-7D434C001C06@gmail.com> References: X-Priority: 3 (Normal) X-Mailer: Zarafa 7.1.14-51822 Thread-Index: AdKcExFG3EbiqeLnTWS+Oywq6degTw== Message-Id: X-Assp-Version: 2.4.7(16004) on ASSP.nospam X-Assp-ID: ASSP.nospam 20887-14853 X-Assp-Session: 955C8150 (mail 1) X-Assp-Original-Subject: RE: [core] Questions/comments on draft-ietf-core-dynlink-02 X-Virus-Scanned: clamav-milter 0.99.2 at buffalo X-Virus-Status: Clean Archived-At: Cc: =?windows-1252?Q?core?= Subject: Re: [core] Questions/comments on draft-ietf-core-dynlink-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 16:01:45 -0000 This is a multi-part message in MIME format. Your mail reader does not understand MIME message format. --=_n9IN1Td0DDGTOO7pvEEdVAvFMQgzhFcnnLEV21JVeQFsy8gF Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I think going forward the best compromise solution would be as you mentio= n continued support for global settings, i.e. single attributes set, as w= ell as per-observe override. This will have least impact on the existing = implementations and currently released specifications by other SDOs.=20=0D= =0A=0D=0AIf IETF decides to go down this route, it would be good clearly = state the rules for how the override should be applied and maybe couple o= f examples showing its application and effect. For example one scenario t= hat may require some clarification is where a resource has already got so= me observation attributes set up by observer 1 and a new observer, Observ= er 2, =A0wishes to simply be notified of any change to the resource and a= s such does not normally require to explicitly specify any observe parame= ters in its get request for observation.=0D=0A=0D=0ABest Regards,=0D=0A=0D= =0AMojan=0D=0A=0D=0A=20=0D=0A=0D=0A=A0=0D=0AFrom: Michael Koster [mailto:= michaeljohnkoster@gmail.com]=20=0D=0ASent: 13 March 2017 15:29=0D=0ATo: M= ojan Mohajer=0D=0ACc: core=0D=0ASubject: Re: [core] Questions/comments on= draft-ietf-core-dynlink-02=0D=0A=0D=0A=A0=0D=0AOK, that makes sense.=0D=0A= =0D=0A=A0=0D=0ADo you think there is still a use case for a simple implem= entation (as I did in ARM mbed) that only keeps a single set of attribute= s=3F=0D=0A=0D=0A=A0=0D=0AShould we support both the global setting and a = per-observe override=3F=0D=0A=0D=0A=A0=0D=0AOr should we deprecte the sin= gle attribute set and only support per-observe attributes going forward=3F= =0D=0A=0D=0A=A0=0D=0AFWIW, There is another SDO that is in the process of= specifying an optional (single) setting for each resource instance, usin= g a "composed" resource.=0D=0A=0D=0A=A0=0D=0ABest regards,=0D=0A=0D=0A=A0= =0D=0AMichael=0D=0A=0D=0A=A0=0D=0AOn Mar 13, 2017, at 8:05 AM, Mojan Moha= jer > wrote:=0D= =0A=0D=0A=A0=0D=0AHi Michael,=0D=0A=0D=0AYes, the current version of LwM2= M requires the use of =93Write Attribute=94 which as you pointed out prov= ides a single set of notifications parameters. This in itself could be ra= ther problematic in use cases where there are two observers of the same r= esource with differing requirements of observe attributes. As per example= A in the document and your suggestion it seems more logical to pass the = observation attributes in the get operation and make them somewhat transa= ction oriented rather than simply attached to the resource. By doing so, = a resource can accommodate multiple observers with different observation = rules as required. BTW, couple of companies have already put forward prop= osals to add support for passing of these attributes in the GET operation= in the next version of OMA LwM2M specification.=A0=0D=0A=0D=0ABest Regar= ds,=0D=0A=0D=0AMojan=0D=0A=0D=0A=A0=0D=0A=A0=0D=0A=A0=0D=0AFrom:=A0Michae= l Koster [mailto:michaeljohnkoster@gmail.com ]=A0=0D=0ASent:=A013 March 2017 12:58=0D=0ATo:=A0Mojan Mohajer=0D= =0ACc:=A0core=0D=0ASubject:=A0Re: [core] Questions/comments on draft-ietf= -core-dynlink-02=0D=0A=0D=0A=A0=0D=0AHi Mojan,=0D=0A=0D=0A=A0=0D=0AI thin= k this is the default behavior for OMA LWM2M using the "Write Attributes"= operation. The effect is to provide a single set of notification paramet= ers for all observe operations on that resource.=0D=0A=0D=0A=A0=0D=0AI be= lieve that we improve on that pattern and allow each observe request to h= ave its own attributes, set by including query parameters in the GET oper= ation.=0D=0A=0D=0A=A0=0D=0ASection 4.2 also indicates that they are reada= ble, but it's not clear to me how that would work=3F In what format are t= hey returned, also as query parameters=3F These could be made readable (a= nd updateable) througn a special CoRE Interface, but we would need to spe= cify how the content format of these works vs. the content format of the = resource state.=0D=0A=0D=0A=A0=0D=0ALWM2M could be described in this draf= t as a legacy pattern.=0D=0A=0D=0A=A0=0D=0ADoes this make sense=3F=0D=0A=0D= =0A=A0=0D=0ABest regards,=0D=0A=0D=0A=A0=0D=0AMichael=0D=0A=0D=0A=A0=0D=0A= =A0=0D=0AOn Mar 10, 2017, at 2:52 AM, Mojan Mohajer > wrote:=0D=0A=0D=0A=A0=0D=0A2) = Section 4.2 which covers resource observation attributes (pmin, pmax, st,= =85) states that that: =85=94These query parameters MUST be treated as r= esources that are read using GET and updated using PUT, and MUST NOT be i= ncluded in the Observe request=94 =85.=0D=0AHowever, looking at newly add= ed Annex A which provides observation examples, these observation attribu= tes are passed as query parameters of a Get request with Observe option s= et to 0. There seems to be some contradiction between the text in section= 4.2 and the example in Annex A.=0D=0A=0D=0A=A0=0D=0A --=_n9IN1Td0DDGTOO7pvEEdVAvFMQgzhFcnnLEV21JVeQFsy8gF Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

= I think going forward the best compromise solution would be as you mentio= n continued support for global settings, i.e. single attributes set, as w= ell as per-observe override. This will have least impact on the existing = implementations and currently released specifications by other SDOs.

If IETF decides to go dow= n this route, it would be good clearly state the rules for how the overri= de should be applied and maybe couple of examples showing its application= and effect. For example one scenario that may require some clarification= is where a resource has already got some observation attributes set up b= y observer 1 and a new observer, Observer 2,  wishes to simply be no= tified of any change to the resource and as such does not normally requir= e to explicitly specify any observe parameters in its get request for obs= ervation.

Best Regards= ,

Mojan

 

From: Michael Koster [mailto:michael= johnkoster@gmail.com]
Sent: 13 March 2017 15:29
To: = Mojan Mohajer
Cc: core
Subject: Re: [core] Questions/= comments on draft-ietf-core-dynlink-02

<= p class=3DMsoNormal> 

OK, that ma= kes sense.

 

<= /div>

Do you think there is still a use case for= a simple implementation (as I did in ARM mbed) that only keeps a single = set of attributes=3F

&= nbsp;

Should we support both the= global setting and a per-observe override=3F

 

O= r should we deprecte the single attribute set and only support per-observ= e attributes going forward=3F

 

FWIW, There is an= other SDO that is in the process of specifying an optional (single) setti= ng for each resource instance, using a "composed" resource.

 

Best regards,

 

Michael

 

On Mar 13, 2017, at 8:05 AM, Mojan Mohajer <mojan.mohajer@u-blox.com> wrote:

 

Hi Michael,

Yes, the current version of LwM2M requires the us= e of “Write Attribute” which as you pointed out provides a si= ngle set of notifications parameters. This in itself could be rather prob= lematic in use cases where there are two observers of the same resource w= ith differing requirements of observe attributes. As per example A in the= document and your suggestion it seems more logical to pass the observati= on attributes in the get operation and make them somewhat transaction ori= ented rather than simply attached to the resource. By doing so, a resourc= e can accommodate multiple observers with different observation rules as = required. BTW, couple of companies have already put forward proposals to = add support for passing of these attributes in the GET operation in the n= ext version of OMA LwM2M specification. 

Best Regards,

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#= 1F497D'>Mojan

 

&= nbsp;

 = ;

From: = Michael Koster [mailto:michaeljohnkoster@gmail.com] 
Sent: 13 March 2017 12:58
To: Mojan Mohajer
Cc: core
Subject: Re: [core] Questions/comments on draft-ietf-= core-dynlink-02

 

Hi Mojan,

 

I think this is the default behav= ior for OMA LWM2M using the "Write Attributes" operation. The e= ffect is to provide a single set of notification parameters for all obser= ve operations on that resource.

 

I believe that we improve on that pattern and allow each observe r= equest to have its own attributes, set by including query parameters in t= he GET operation.

 

Section= 4.2 also indicates that they are readable, but it's not clear to me how = that would work=3F In what format are they returned, also as query parame= ters=3F These could be made readable (and updateable) througn a special C= oRE Interface, but we would need to specify how the content format of the= se works vs. the content format of the resource state.

 

<= div>

LWM2M could be described in this draft as a= legacy pattern.

 

Does thi= s make sense=3F

=  

Best rega= rds,

 =

Michael

 

<= /div>

 

On Mar 10, 2017, at 2:52 AM, Mojan Mohajer <moj= an.mohajer@u-blox.com> wrote:

 

2) Section 4.2 which covers resource observation attributes (pmin, pm= ax, st, …) states that that: …”These query parameters M= UST be treated as resources that are read using GET and updated using PUT= , and MUST NOT be included in the Observe request” ….
Howe= ver, looking at newly added Annex A which provides observation examples, = these observation attributes are passed as query parameters of a Get requ= est with Observe option set to 0. There seems to be some contradiction be= tween the text in section 4.2 and the example in Annex A.

 

--=_n9IN1Td0DDGTOO7pvEEdVAvFMQgzhFcnnLEV21JVeQFsy8gF-- From nobody Mon Mar 13 09:06:59 2017 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 0330912960F; Mon, 13 Mar 2017 09:06:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148942121398.16860.14021589495420129076@ietfa.amsl.com> Date: Mon, 13 Mar 2017 09:06:53 -0700 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-senml-05.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 16:06:54 -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 of the IETF. Title : Media Types for Sensor Measurement Lists (SenML) Authors : Cullen Jennings Zach Shelby Jari Arkko Ari Keranen Carsten Bormann Filename : draft-ietf-core-senml-05.txt Pages : 46 Date : 2017-03-13 Abstract: This specification defines media types for representing simple sensor measurements and device parameters in the Sensor Measurement Lists (SenML). Representations are defined in JavaScript Object Notation (JSON), Concise Binary Object Representation (CBOR), eXtensible Markup Language (XML), and Efficient XML Interchange (EXI), which share the common SenML data model. A simple sensor, such as a temperature sensor, could use this media type in protocols such as HTTP or CoAP to transport the measurements of the sensor or to be configured. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-senml/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-senml-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-senml-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 13 09:36:20 2017 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 B2CF712951F; Mon, 13 Mar 2017 09:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1YEngqoZGFi; Mon, 13 Mar 2017 09:36:15 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A469D129527; Mon, 13 Mar 2017 09:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v2DGa9DZ004384; Mon, 13 Mar 2017 17:36:09 +0100 (CET) Received: from [192.168.217.124] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vhk5N6WtszDGtv; Mon, 13 Mar 2017 17:36:08 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: <148942258161.17007.2476084044691959118@ietfa.amsl.com> Date: Mon, 13 Mar 2017 17:36:08 +0100 X-Mao-Original-Outgoing-Id: 511115768.116454-d2b44b0a48943e044c0a0c5781b8d52d Content-Transfer-Encoding: quoted-printable Message-Id: References: <148942258161.17007.2476084044691959118@ietfa.amsl.com> To: lwip@ietf.org X-Mailer: Apple Mail (2.3259) Archived-At: Cc: core Subject: Re: [core] I-D Action: draft-ietf-lwig-coap-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: lwip@ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 16:36:16 -0000 We have updated LWIG-CoAP so it aligns with the recent work on = coap-tcp-tls which is reaching IESG submission in the CoRE WG. =20 The Chicago meeting of the LWIG WG may be a good time to check what else = we want to cover in this document and to move it forward. (CCing CoRE = WG, but please keep discussion on the lwip@ietf.org [sic] mailing list = for the LWIG WG.) Gr=C3=BC=C3=9Fe, Carsten > On 13 Mar 2017, at 17:29, 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 Light-Weight Implementation Guidance = of the IETF. >=20 > Title : CoAP Implementation Guidance [=E2=80=A6] >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lwig-coap-04 From nobody Mon Mar 13 10:02:39 2017 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 A71B512986C; Mon, 13 Mar 2017 10:02:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148942455766.17007.2647217349517798870@ietfa.amsl.com> Date: Mon, 13 Mar 2017 10:02:37 -0700 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-object-security-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 17:02: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 of the IETF. Title : Object Security of CoAP (OSCOAP) Authors : Göran Selander John Mattsson Francesca Palombini Ludwig Seitz Filename : draft-ietf-core-object-security-02.txt Pages : 41 Date : 2017-03-13 Abstract: This document defines Object Security of CoAP (OSCOAP), a method for application layer protection of the Constrained Application Protocol (CoAP), using the CBOR Object Signing and Encryption (COSE). OSCOAP provides end-to-end encryption, integrity and replay protection to CoAP payload, options, and header fields, as well as a secure message binding. OSCOAP is designed for constrained nodes and networks and can be used across intermediaries and over any layer. The use of OSCOAP is signaled with the CoAP option Object-Security, also defined in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-object-security/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-object-security-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-object-security-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 13 13:01:50 2017 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 8CA2B1294AC; Mon, 13 Mar 2017 13:01:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148943530454.20323.16258961043320992542@ietfa.amsl.com> Date: Mon, 13 Mar 2017 13:01:44 -0700 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-resource-directory-10.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 20:01: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 of the IETF. Title : CoRE Resource Directory Authors : Zach Shelby Michael Koster Carsten Bormann Peter van der Stok Filename : draft-ietf-core-resource-directory-10.txt Pages : 52 Date : 2017-03-13 Abstract: In many M2M applications, direct discovery of resources is not practical due to sleeping nodes, disperse networks, or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which hosts descriptions of resources held on other servers, allowing lookups to be performed for those resources. This document specifies the web interfaces that a Resource Directory supports in order for web servers to discover the RD and to register, maintain, lookup and remove resource descriptions. Furthermore, new link attributes useful in conjunction with an RD are defined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-resource-directory-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-resource-directory-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 13 13:06:40 2017 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 C50C81294FF; Mon, 13 Mar 2017 13:06:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148943559878.20264.7186564400631963729@ietfa.amsl.com> Date: Mon, 13 Mar 2017 13:06:38 -0700 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-coap-pubsub-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 20:06:38 -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 of the IETF. Title : Publish-Subscribe Broker for the Constrained Application Protocol (CoAP) Authors : Michael Koster Ari Keranen Jaime Jimenez Filename : draft-ietf-core-coap-pubsub-01.txt Pages : 23 Date : 2017-03-13 Abstract: The Constrained Application Protocol (CoAP), and related extensions are intended to support machine-to-machine communication in systems where one or more nodes are resource constrained, in particular for low power wireless sensor networks. This document defines a publish- subscribe broker for CoAP that extends the capabilities of CoAP for supporting nodes with long breaks in connectivity and/or up-time. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-coap-pubsub/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-coap-pubsub-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-coap-pubsub-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 13 13:21:23 2017 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 5C676129AF8; Mon, 13 Mar 2017 13:21:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148943648036.20337.15086726752750335196@ietfa.amsl.com> Date: Mon, 13 Mar 2017 13:21:20 -0700 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-cocoa-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 20:21:20 -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 of the IETF. Title : CoAP Simple Congestion Control/Advanced Authors : Carsten Bormann August Betzler Carles Gomez Ilker Demirkol Filename : draft-ietf-core-cocoa-01.txt Pages : 16 Date : 2017-03-13 Abstract: The CoAP protocol needs to be implemented in such a way that it does not cause persistent congestion on the network it uses. The CoRE CoAP specification defines basic behavior that exhibits low risk of congestion with minimal implementation requirements. It also leaves room for combining the base specification with advanced congestion control mechanisms with higher performance. This specification defines some simple advanced CoRE Congestion Control mechanisms, Simple CoCoA. It is making use of input from simulations and experiments in real networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-cocoa/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-cocoa-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-cocoa-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 13 13:30:08 2017 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 743BC12998C for ; Mon, 13 Mar 2017 13:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id feV66N0RlcP5 for ; Mon, 13 Mar 2017 13:30:05 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14DEE1294C0 for ; Mon, 13 Mar 2017 13:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v2DKU2EZ011347 for ; Mon, 13 Mar 2017 21:30:02 +0100 (CET) Received: from [192.168.217.124] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vhqHG06ZzzDGyK; Mon, 13 Mar 2017 21:30:01 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: <148943648036.20337.15086726752750335196@ietfa.amsl.com> Date: Mon, 13 Mar 2017 21:30:01 +0100 X-Mao-Original-Outgoing-Id: 511129801.207019-8a937f96ccf36cd4d64d65afc7dcf236 Content-Transfer-Encoding: quoted-printable Message-Id: <6E4A0EC7-0F91-48B6-820F-21BAA5B3743E@tzi.org> References: <148943648036.20337.15086726752750335196@ietfa.amsl.com> To: core X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [core] Cocoa now in WG document version -01 -- ready for WGLC? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 20:30:06 -0000 The authors believe that -01 (possibly minus the Appendix A, which still = needs to be factored out into a separate document) is now ready for WGLC = (which should be casting a wide net, including ICCRG and possibly groups = such as tcpm). The update to -01 mostly contains a new appendix with supporting = evidence. The WG can use the evidence provided in making its decision. Whether that appendix should then be part of the published RFC is = something to be decided as well. Other changes have been prompted by the upgrade of RFC 5405 to RFC 8085. Please see: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-cocoa-01 Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Mar 13 15:58:05 2017 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 0B3BC129AAF; Mon, 13 Mar 2017 15:57:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148944587901.20433.15963122706675936841@ietfa.amsl.com> Date: Mon, 13 Mar 2017 15:57:59 -0700 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-links-json-07.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 22:57:59 -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 of the IETF. Title : Representing CoRE Formats in JSON and CBOR Authors : Kepeng LI Akbar Rahman Carsten Bormann Filename : draft-ietf-core-links-json-07.txt Pages : 18 Date : 2017-03-13 Abstract: JavaScript Object Notation, JSON (RFC7159) is a text-based data format which is popular for Web based data exchange. Concise Binary Object Representation, CBOR (RFC7049) is a binary data format which has been optimized for data exchange for the Internet of Things (IoT). For many IoT scenarios, CBOR formats will be preferred since it can help decrease transmission payload sizes as well as implementation code sizes compared to other data formats. Web Linking (RFC5988) provides a way to represent links between Web resources as well as the relations expressed by them and attributes of such a link. In constrained networks, a collection of Web links can be exchanged in the CoRE link format (RFC6690). Outside of constrained environments, it may be useful to represent these collections of Web links in JSON, and similarly, inside constrained environments, in CBOR. This specification defines a common format for this. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-links-json/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-links-json-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-links-json-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 13 16:09:12 2017 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 37EEB129C32; Mon, 13 Mar 2017 16:09:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148944654421.20358.13734273062195751390@ietfa.amsl.com> Date: Mon, 13 Mar 2017 16:09:04 -0700 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-dynlink-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 23:09:04 -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 of the IETF. Title : Dynamic Resource Linking for Constrained RESTful Environments Authors : Zach Shelby Matthieu Vial Michael Koster Christian Groves Filename : draft-ietf-core-dynlink-03.txt Pages : 16 Date : 2017-03-13 Abstract: For CoAP [RFC7252] Dynamic linking of state updates between resources, either on an endpoint or between endpoints, is defined with the concept of Link Bindings. This specification defines conditional observation attributes that work with Link Bindings or with CoAP Observe [RFC7641]. Editor's note: o The git repository for the draft is found at https://github.com/ core-wg/dynlink The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-dynlink/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-dynlink-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-dynlink-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 13 16:25:21 2017 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 B6C99129C15; Mon, 13 Mar 2017 16:25:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148944751473.20345.10291630842091866985@ietfa.amsl.com> Date: Mon, 13 Mar 2017 16:25:14 -0700 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-interfaces-09.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 23:25:15 -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 of the IETF. Title : Reusable Interface Definitions for Constrained RESTful Environments Authors : Zach Shelby Matthieu Vial Michael Koster Christian Groves Filename : draft-ietf-core-interfaces-09.txt Pages : 27 Date : 2017-03-13 Abstract: This document defines a set of Constrained RESTful Environments (CoRE) Link Format Interface Descriptions [RFC6690] applicable for use in constrained environments. These include the: Actuator, Paramter, Read-only parameter, Sensor, Batch, Linked Batch and Link List interfaces. The Batch, Linked Batch and Link List interfaces make use of resource collections. This document further describes how collections relate to interfaces. Many applications require a set of interface descriptions in order provide the required functionality. This document defines the concept of function sets to specify this set of interfaces and resources. _Editor's note: The git repository for the draft is found at https://github.com/core-wg/interfaces_ _Editor's note: Two open issues are proposals for: Removing the binding interface in favour of the link list interface. Changing "rel" type from one attribute to two to indicate src and destination._ The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-interfaces/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-interfaces-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-interfaces-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 14 00:37:44 2017 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 EFEB11293DB for ; Tue, 14 Mar 2017 00:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnjpANIY2fzo for ; Tue, 14 Mar 2017 00:37:40 -0700 (PDT) Received: from lb3-smtp-cloud3.xs4all.net (lb3-smtp-cloud3.xs4all.net [194.109.24.30]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FF881294F4 for ; Tue, 14 Mar 2017 00:37:40 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:208]) by smtp-cloud3.xs4all.net with ESMTP id vjde1u00T4ydcfa01jdew8; Tue, 14 Mar 2017 08:37:38 +0100 Received: from 2001:983:a264:1:dced:4265:d926:d447 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 14 Mar 2017 08:37:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 14 Mar 2017 08:37:38 +0100 From: peter van der Stok To: Core Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <148943530454.20323.16258961043320992542@ietfa.amsl.com> References: <148943530454.20323.16258961043320992542@ietfa.amsl.com> Message-ID: <26bbb4e46e92a4b07076248c7612b173@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Subject: [core] Fwd: I-D Action: draft-ietf-core-resource-directory-10.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 07:37:43 -0000 Hi Core, This new version of the resource directory addresses the issues raised during the last few months on the ML. This new version includes: Con(text) query parameter better defined Simple discovery text improved Update and entry uniqueness improved Clarified existence of registration resource DNS extensions (exp, ins query parameters) removed And other mistakes and ambiguities removed. The authors think that this version is ready for WGLC Peter -------- Oorspronkelijke bericht -------- Onderwerp: [core] I-D Action: draft-ietf-core-resource-directory-10.txt Datum: 2017-03-13 21:01 Afzender: internet-drafts@ietf.org Ontvanger: Kopie: core@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments of the IETF. Title : CoRE Resource Directory Authors : Zach Shelby Michael Koster Carsten Bormann Peter van der Stok Filename : draft-ietf-core-resource-directory-10.txt Pages : 52 Date : 2017-03-13 Abstract: In many M2M applications, direct discovery of resources is not practical due to sleeping nodes, disperse networks, or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which hosts descriptions of resources held on other servers, allowing lookups to be performed for those resources. This document specifies the web interfaces that a Resource Directory supports in order for web servers to discover the RD and to register, maintain, lookup and remove resource descriptions. Furthermore, new link attributes useful in conjunction with an RD are defined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-resource-directory-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-resource-directory-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Tue Mar 14 01:47:21 2017 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 19532129441; Tue, 14 Mar 2017 01:47:14 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-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=philips.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 0JAIvEDdA1OG; Tue, 14 Mar 2017 01:47:10 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50123.outbound.protection.outlook.com [40.107.5.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D78AC126CD8; Tue, 14 Mar 2017 01:47:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Philips.onmicrosoft.com; s=selector1-philips-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8dc1cq2FfdNgmfvX6EjvWyTcu0kcQVAO06Ka+is4OkQ=; b=K2Fwr3B74QvPwonDlzw1H+9qNX3dUYWI7olKoRO4kpTqmNMbnlCBYVdgMc46nPV9GdXDHaQrXZrLhEJfSHjNmDekClh8p7FvEMmSsTG/3SPinuqHV1GUpitF6k10pHWo0oXu5GBDSQCR7scPN+7HlSLZVBXBshcx3R/9BIiGCbY= Received: from DB6P122CA0004.EURP122.PROD.OUTLOOK.COM (129.75.140.18) by DB6P122MB0039.EURP122.PROD.OUTLOOK.COM (129.75.140.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.17; Tue, 14 Mar 2017 08:47:07 +0000 Received: from DB3FFO11FD037.protection.gbl (2a01:111:f400:7e04::102) by DB6P122CA0004.outlook.office365.com (2603:10a6:24:2::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.17 via Frontend Transport; Tue, 14 Mar 2017 08:47:06 +0000 Authentication-Results: spf=neutral (sender IP is 23.103.228.36) smtp.mailfrom=philips.com; ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=philips.com; Received-SPF: Neutral (protection.outlook.com: 23.103.228.36 is neither permitted nor denied by domain of philips.com) Received: from 011-smtp-out.Philips.com (23.103.228.36) by DB3FFO11FD037.mail.protection.outlook.com (10.47.217.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.10 via Frontend Transport; Tue, 14 Mar 2017 08:47:06 +0000 Received: from AM3PR90MB0097.MGDPHG.emi.philips.com (141.251.117.145) by AM3PR90MB0099.MGDPHG.emi.philips.com (141.251.117.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.17; Tue, 14 Mar 2017 08:47:05 +0000 Received: from AM3PR90MB0097.MGDPHG.emi.philips.com ([141.251.117.145]) by AM3PR90MB0097.MGDPHG.emi.philips.com ([141.251.117.145]) with mapi id 15.01.0961.021; Tue, 14 Mar 2017 08:47:05 +0000 From: "Dijk, Esko" To: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= , "draft-ietf-core-coap-tcp-tls@ietf.org" Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV0dMQyBkcmFmdC1pZXRmLWNvcmUtY29hcC10Y3AtdGxz?= Thread-Index: AQHSnFVkHn8Z58Yne0KTgPnHpk1WCKGUBJIA Date: Tue, 14 Mar 2017 08:47:05 +0000 Message-ID: <8e2b2a0a00bb404d930adf0ae9ce08ad@AM3PR90MB0097.MGDPHG.emi.philips.com> References: <938FB795-A352-448A-B380-ABBFA2F04DE9@ericsson.com> In-Reply-To: <938FB795-A352-448A-B380-ABBFA2F04DE9@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [83.85.138.53] X-MS-Office365-Filtering-Correlation-Id: 37aaad82-32cd-402f-1e8d-08d46ab6b1e7 Content-Type: multipart/alternative; boundary="_000_8e2b2a0a00bb404d930adf0ae9ce08adAM3PR90MB0097MGDPHGemip_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: AM3PR90MB0099.MGDPHG.emi.philips.com X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:23.103.228.36; IPV:NLI; CTRY:; EFV:NLI; SFV:NSPM; SFS:(10019020)(39840400002)(39850400002)(39860400002)(39410400002)(39450400003)(2980300002)(24454002)(189002)(85714005)(377424004)(54534003)(374574003)(199003)(9170700003)(2900100001)(512874002)(5660300001)(606005)(55016002)(2950100002)(102836003)(84326002)(2501003)(7906003)(24736003)(86362001)(3846002)(790700001)(356003)(6116002)(7736002)(2906002)(54356999)(7696004)(4326008)(8936002)(81166006)(33646002)(236005)(189998001)(54896002)(6306002)(76176999)(106466001)(6246003)(38730400002)(105586002)(108616004)(53546007)(66066001)(229383001)(229853002)(230783001)(106116001)(53936002)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6P122MB0039; H:011-smtp-out.Philips.com; FPR:; SPF:Neutral; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DB3FFO11FD037; 1:cdrlFyfKLcod6xitSTj89jSGfnFIYk6nwNDJ5Hw3lZ9QwUbpxNQKwRUASG0DvDU/fGZsD5g/j5tY4RQp8rX38uGw7hFNaLjnpB3wfDmLx+J3Nouya4F4AaHy5O85EHw1z2H7BjscnwfjYFgUuQzoQj6+m6jSGnPsjX33yYDdZxFzAEGU8hWuRmwMKjeTVPdIfOw3NnZHo4pTBpHA+9Hu/eYKPjjcEWq/SiFxfseeAynf2Hz67rsBroMluGLmapUFPP7J61ro25npVqkPFWxdZBuhq67dEgNNAhQyEKpeq4K8gfKcSvKWmsXKPWw49sK/EHX8jwiPPyuv7qVjjK6/4R8ETvmohgux+frj0qwTd3aaED/Ww30F2dfo2ra5C1muiaPwHOAQmULD2MmEP55c7gDgbG32waSnbRYPXc+QVnq4ptoeo+zTilMc4B2vi4g03sFjCsz7taKdJnfe9vSz2Zx/hEwSrWKqwT3TqG8OnlIN6QFCJ8FTtNeYCF4jh7VR X-CrossPremisesHeadersPromoted: DB3FFO11FD037.protection.gbl X-CrossPremisesHeadersFiltered: DB3FFO11FD037.protection.gbl X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DB6P122MB0039; X-Microsoft-Exchange-Diagnostics: 1; DB6P122MB0039; 3:n/q7ScZ223xyfpRAR1rkFwcnYg/1ubv2jocYkotkQmjpgWfLf5s6uU7l339n8p9eTwlI0HDvN9gFQQCQLiYnP3AjWbamnQ6m0LALdnwOzhvOKvdnvRi+6ueknS14PPKHBlalqKp+6pjCnfIpwWV4WGM0kwy1F237+Vv9PonQVhqXRwREJt+Na80dKnQtHnbnU1IB4d4swqUEdbm2L+c52dZB6BupSH+MzZYLvAWPbhYA5z2iJxprfSjMyNX3SJrQ+MWRYW+UjHRHqMOelAHPpuF9AVQGhQT4XJRnHUO7JvrfpxOXgXxnfXaXdibycL1TcNoKFN9+dYj7a6GhOXiC0wGam/VnFAf6jaj1uBidzrA=; 25:N1ubOb7jEMb9jpoE1CVTNIyfOyxI275UrnP4tqx1ifsF1ZAOLjxCTjGh4oqQqdp4Hb9of1QhOKYl+CgtIIha5qioQ70B268OkOa5/MnktySPrsA8lz374hnDV6oLlMPFM/A1d7T+dfj+QDvm/WLK4CRHE5I6w5gU5XQli6NYHLaDsPIl4RFcmcfu435e4ghQJ7kOdKYcxMDen7t6cAJnI868WcKeob7UhRoXn5psmMyJ4KMOTqqPXiXchc+k06+LXsbBNfHdd0l/Pb/ZQjD0nbYz2ze/JRWP8v0b158AH1GHZU6GNinH+4/HjBZ+pkQFJ8IOWTg1BKJTmkAhGdvCPRagwacmPfS69ynur1Du4HsWu5AkVE0r7BhoetFUiq3QU0TD5H5Vqf5zItJ3BPnmhGYTugRPCXc7Em1nQwm3EGcvnrmbst1hmPlDdHErLgka6Bk9JbaVmVufJ+wxuSYhiw== X-Microsoft-Exchange-Diagnostics: 1; DB6P122MB0039; 31:x3PGXYKoOeIahDmfVo5DJhmCxUJkoY3bAlg5z7Ev7uwgvT7T/3Nh7A504Bd5RVMKnYqS4GiopPunnPvK04oX/8/9rifNY67n26Mn3Tp3Q+09b+8oLbKIPa552nKIhRP3PHdN/t7G1Q5/lK2pqG4HpABK8DEzM0s57NtNS9whffZfhS0kQg7FjhGsCIxsSD5J65j9bznbjLHRhhGZI4FLjwQCskXG5+kW2HVb36znRYYZ6hif2AvR7d030pAJc7peb+XVd9jMdpLgmGlrFSaxwEwQNGP1XKUj4TCWp60/Ghc=; 20:UNx4XVaGWwRoNZ5MnGro9xEHQhmRAM1+wzmaLhX3Yf8fw0B0l1TyDlGYjMGHs6GryXt1zshMvhW62onZuh1jRtCH/FG/WFP2j3kE7v+Ak3IjXtWGvoWtWPqnA4+8Xuh7z/EXJq5TzvOIoMMnONCSNBHM4JDV8wKr8Xm25/fhcI8b9AuYJ22r5k/3CV/q/sHxTFrKmNcxN/rbNHYW3SJ6N5UCW8Q36KbHUskmg4mTlP5vO4I8ukEKIe9WOlD+DYnfB1HOnaxHecEnIeG/pKRhUMbAfP6CWZY3dIku4nTmcFWzmMudyTKXEWymeUzBeyoq4HL8jsSbZqAwOKLF8RjtwB6JccyTm66JF19NX0hlMj+SQD1qfXowI+FlaYslH/6zpWKR4gpkeiwuaP9FeVzCH/OpiEBPsxpMFK84R8DaFwbdyWyE1R1KwNBAUWbFASmr/vUN3b8KR89/qcystBf8YSKx3nBvv8ERwkYN1J0uhIZJGaRXtkfvb0e10jC7I4CA X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(158342451672863)(166708455590820)(21748063052155); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(13018025)(5005006)(13016025)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(20161123558025)(20161123564025)(20161123560025)(6072148); SRVR:DB6P122MB0039; BCL:0; PCL:0; RULEID:; SRVR:DB6P122MB0039; X-Microsoft-Exchange-Diagnostics: 1; DB6P122MB0039; 4:Pitch1BKJ7/3LWlKUIPL+VdoAsL3IgeXVpbKn4bfdP9IJ522WBfVy6yUthoB3ddzaPDCG/sVtJVfvjeDn7oj8csa/7GVR17sYkn2SZcdooa3F1KEPC/OnJhIwzCnvN71n1g3uXxcmvvUapoL38SQkizqUDdlewUdM/EjkX91Bx9K2Cn1KkJv3DjRK/lKOFz7JsNibpIxiE73PK9IVhX179LVvvK0uYI9qE7br+A2wZUbAREm+08Ww9ofQ++RvHgPMDD0eusiuqfjYbg5z5I/O7qd7F7G+ic+tZOnU84K/6NQYx/BC84+BSMlFJkWFXSX1futy+bF4NrgHsFllzdYPNsImAY68W1p+g6gW3eBeT3PImytWQfqqmd5/9k2mgsJD6v+SIb+N1c7rk05jDOcW1IEkoh1wkPNgrD9Hava52DX5bwt8YH4lnlixguG0hGjXBB0dTk4qUxvvy66JU6AI1UbaWMTU2fMmUjsVEK/4XF9pjZOqYLi9HhfGlBseVk5PXt0e+OdJyBzfxgsUlVv0Cx1eVXB3snQbWpRN5SpFKR29/mHQfQWdY3BXad14/mfDLlcWzzJGAMS51pqn2v4tdb3C4ofeVXA7Zs4RJiYS/5XaoboK0SJXdL3DeAStyvXvsDmSM2UsK0ErHKJ2NAVFXcnVhiFS27lGxVSE5E0xXn0gnH/4YM8UUYJbHsEvvg0Xq2s/ax6vuJQxyHo/79SVAdXKLymgjx2RA0RC5ZAV+vOK2Jknp8KUmkq/a4SyFa0xlkXcalgImGlvHQlWfjgOmvFv435m0whJ+zX3c+VevU= X-Forefront-PRVS: 02462830BE X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DB6P122MB0039; 23:/UDxo+lAf0r5BLqGpqOTQdB9Q8QqwlSo/gbdCtzPq?= =?us-ascii?Q?61JP5ubK3pbrWxoHyUFYjWv4wPK+fRo4a8XPFZrAx9Aw22+06E+L3eyOR3tf?= =?us-ascii?Q?TnJdI+OzatHAM4Ne/v+tRO5u9QjzqVs+47J2f3jDi6bdNh1G1qdIJo8YJxaL?= =?us-ascii?Q?DxWy4Be6mNSBof0v2hOamBNFVrNczXOvg9PsWU22oPCNZgprEJWuI1aYUzsm?= =?us-ascii?Q?+0s6TNk2dF2Mbpg1LUAisYBs4VhRBkz+4WAUeoJMNIoX1+OALvR8T8CjdKt1?= =?us-ascii?Q?YhK8V/JwEKX4Ogm3d9FIJHfS3bjYEIqw2FVZth+ryPPv5DNh9yo4BrrxIaCY?= =?us-ascii?Q?nAgz7ns2wPaNBwXOaxa2Lm8wm3N57PINNhzHmM8XWcrxGspLBKcCsDwGJQ/s?= =?us-ascii?Q?bN+oe6jBOZH6wUY26AGari+gcfcNVXyp/kveTE/5CwdTMrFA1qzd1lNIerBx?= =?us-ascii?Q?UD8Wr3Y3z+A0vO5ibGkyHAYvXTbxW0r3ibXmVd3hjg/p5pA1BDnxt9zv1aU/?= =?us-ascii?Q?1v21ktR3iNwPSNvFUD0E/q1iKa04t/5G1DGnlOWuF52Q4PM3Cr3R8z937FFV?= =?us-ascii?Q?qnk3ac6MO+7P54Uwka51l0P0fQNvDkJdr7jGMtakOze07BEGgrjYZBbZVbLQ?= =?us-ascii?Q?JvKkDTz+ygQYxz5b99IETziiHibGpZkyTZecgmc/1bhGAT9ycHkd9aBznaTv?= =?us-ascii?Q?FBLL9xDZJzAQ7xHynGlYe9SRWliBTOnRZI391c2XJgxu3ODGgbIhji3sd+LH?= =?us-ascii?Q?UrxzHL19zAp4WId+f/cyE4jKmJt7Tl9obZqvhVHCzqvx8IBqtFZQlYmCd6pe?= =?us-ascii?Q?6LgOmcFmo92m7B+oy5xGi2jhwVTlXAfcEf/7SzK9gEEcMRYtJaiCXuKHjsiJ?= =?us-ascii?Q?qjDncCn1L0SRxdsaBwe6bspKGWLgSmHAHPzzO2MqPQenj/JTnxlUYfAtDMRm?= =?us-ascii?Q?ORC7qYhT6VE5Gs+8gUhhLdHTIXWjo8fs61xCttOyXlx8whY2JUpA+eykX9lO?= =?us-ascii?Q?tWg1/LcFAaiDNmzfSU9kzIgekAEBxsY6q5ofDiR95bhxkCEOht9dUa6PFQzA?= =?us-ascii?Q?noEYiIrY9+62dGofr1x6hbaRode4IbgxmBk1v4ljZ5OgkHQve/QWXhjGvDUc?= =?us-ascii?Q?E7hcecWVEVE0d8tgQ4xoBoAfgfZu6WBTZ24lA9s4jlspOD+6bLKiTbOoEqz9?= =?us-ascii?Q?voAYKbNbxNuD3t596f01vtX/iaDOlDreCELSv9MeRbiijiltfuoyMz1jKNT7?= =?us-ascii?Q?EPVeNa9ennYNy2X0N1Kmz5kcfa1JJobnKXGxZLMueTSCxXjYxXX2k9cv0Ti4?= =?us-ascii?Q?7ZnSCTeKD0K7iqgLuLzy71aVwEBuxsuVntgzvRt87HUMvZS++LoyXi0NZ7xh?= =?us-ascii?Q?3ifGA=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB6P122MB0039; 6:tPSiCo0RoW7e0CUOJYAuUHH7LwEjfPmzwrKshX09A0gSYwol955ZnUrK3DzgPT8LSektGrhtlOQ5F8SQu9C5EIqcfpmk+tovGP7UFHSdZ9nrIgfO7d0u+l5nCw1mIpmK5X9PW0xoCgyswVbb+xEqReNHqy2nJL7ofu290Nh09EUvQ63tNrLvEF3XxaAdXc/5iQHI8z1/AEDVHjxufp5WfpTBzCIdyN1QuZHT/zjPkNjG0UrcmklSFU5uwC3fWJwzTeoQt3I81f1iBvGooQTcbOJGYu1ARNyQm7VSWxDOefJapCAD47g60mmsf++NYHIGp2QNIZDnJdfc/EDbaI4iuaUGsz82UtIwK/cWiuDYEmJghX6mRjFNysm6hJEcD6mDGeXjggKjKgQNmrS/OEA0sW8WZikzdKCF6Fr1e+yb+dU=; 5:PgufrvOrpCz6H1UlwV2oGtrygDppzRXwiCu7Q5hKYYfm+4qmjLvTSXlOhnFvBgdR1Pq0qsbMpGsTNVB/0kSrGrSNUmSuKGN2t0lU2RLEe/yqjMUzEaSb6EmhAqgGy7sdb9GGIFWQCrfhskENEYtN3w==; 24:aKIJN3FXbFOqvuEdERcGeKQm5ZmlG7pAFr2tFl3jCVg5AuhfQn4imCceNMKPON8a7R9XiUUFkFRjfRSwhgi6JgSoqayTvPBK+YaEr358f48= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DB6P122MB0039; 7:iS3LmyHz+VkttuVpJTbn2G5XuLfKx1xYnS29EGzgxHV92LVNNvemp4T9MhrHY/2xEOoeO40rteQcC2j4Az4LqBBUAL91Lcq2Cd/1eCpXshWvb+b9Cqyy75LFbOEQWFr57QMseyuFGSTeqLXqHPSJzEzeuhbFOgPqHs6xFYDGI1GLr27IFXifsm21/PP/vISnRKXsVm774yGSO9sJQ5V0SN07fiKvmXppF0Zu9tLv39FXOeYTOp8wEH74K6hGmxjGDJkuuOY9T62G2t34hp0rGK76MiBoUM5OzICC1sE7To4qOjcIcpaSwxCeFmGnoAqWw9rTdr8nBsL1Y+2tOtahow== X-OriginatorOrg: philips.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Mar 2017 08:47:06.6920 (UTC) X-MS-Exchange-CrossTenant-Id: 1a407a2d-7675-4d17-8692-b3ac285306e4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=1a407a2d-7675-4d17-8692-b3ac285306e4; Ip=[23.103.228.36]; Helo=[011-smtp-out.Philips.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P122MB0039 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: AM3PR90MB0097.MGDPHG.emi.philips.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 83.85.138.53 X-MS-Exchange-CrossPremises-disclaimer-hash: 7fd5309d68bb4378c576a4d2c2ad972d336f5eb0475879c2a0b14da1aac98972 X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-AVStamp-Service: 1.0 X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating; SFV:NSPM; SKIP:0; X-OrganizationHeadersPreserved: DB6P122MB0039.EURP122.PROD.OUTLOOK.COM Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_draft-ietf-core-coap-tcp-tls?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 14 Mar 2017 08:47:14 -0000 --_000_8e2b2a0a00bb404d930adf0ae9ce08adAM3PR90MB0097MGDPHGemip_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SmFpbWUgJiBhdXRob3JzLA0KDQpsb29raW5nIGF0IHRoZSByZWNlbnQgY2hhbmdlcyBJIHNlZSBv bmx5IG9uZSBpc3N1ZSBsZWZ0OiB0aGUgZGVmaW5lZCBiZWhhdmlvciBvZiBhIENvQVAgZW5kcG9p bnQgdGhhdCBkb2Vzbid0IGltcGxlbWVudCBhIENvQVAgc2VydmVyLiBUaGUgbmV3IHRleHQgc3Rh dGVzOg0KDQoNCklmIG9uZSBzaWRlIGRvZXMgbm90IGltcGxlbWVudCBhDQoNCiAgICAgICAgICAg Q29BUCBzZXJ2ZXIsIGFuIGFwcHJvcHJpYXRlIGVycm9yIHJlc3BvbnNlIHN1Y2ggYXMgNC4wNCAo Tm90IEZvdW5kKQ0KDQogICAgICAgICAgIG9yIDUuMDEgKE5vdCBJbXBsZW1lbnRlZCkgTVVTVCBi ZSByZXR1cm5lZCBmb3IgYWxsIENvQVAgcmVxdWVzdHMgZnJvbQ0KDQogICAgICAgICAgIHRoZSBv dGhlciBzaWRlLg0KDQpSZXF1aXJpbmcgd2l0aCBNVVNUIHNvbWV0aGluZyB0aGF0J3MgdmFndWVs eSBkZWZpbmVkICgic3VjaCBhcyBYIG9yIFkiKSBzZWVtcyBhIGJhZCBpZGVhIHRvIG1lLiBCZXNp ZGVzLCB3aGVuIHRoZSBlbmRwb2ludCB3b3VsZCBzdGFydCByZXR1cm5pbmcgNC4wNCB0aGVuIGl0 IGFjdHVhbGx5ICppcyogYSBDb0FQIHNlcnZlciBhbGJlaXQgb25lIHdpdGhvdXQgYW55IHJlc291 cmNlcy4gU3RpbGwgaXQgaXMgZXhwZWN0ZWQgdG8gYmVoYXZlIGxpa2UgYSBDb0FQIHNlcnZlciB0 aGVuIOKAkyBlLmcuIHJldHVybiA0LjAyIGlmIGFuIHVua25vd24gY3JpdGljYWwgb3B0aW9uIGlz IGZvdW5kIGluIHRoZSByZXF1ZXN0LCBldGNldGVyYS4gVG8gYXZvaWQgYWxsIHRoZXNlIGlzc3Vl cyBhbmQgdG8gcmVhbGx5IG1ha2UgY2xlYXIgdGhlcmUgaXMgbm8gc2VydmVyIGF0IGFsbCDigJMg aS5lLiBpdCBpc24ndCBhYmxlIHRvIHByb2Nlc3Mgb3IgdmFsaWRhdGUgYW55IHJlcXVlc3Qg4oCT IHRoZSBmb2xsb3dpbmcgd291bGQgYmUgbXVjaCBiZXR0ZXI6DQoNCg0KSWYgb25lIHNpZGUgZG9l cyBub3QgaW1wbGVtZW50IGENCg0KICAgICAgICAgICBDb0FQIHNlcnZlciwgYW4gZXJyb3IgcmVz cG9uc2UgNS4wMSAoTm90IEltcGxlbWVudGVkKSBNVVNUIGJlDQoNCiAgICAgICAgICAgIHJldHVy bmVkIGZvciBhbGwgQ29BUCByZXF1ZXN0cyBmcm9tIHRoZSBvdGhlciBzaWRlLg0KDQoNCg0KNS4w MSBpbiB0aGlzIGNhc2UgbWVhbnMgdGhlIGVuZHBvaW50IGhhc24ndCBpbXBsZW1lbnRlZCBhbnkg Q29BUCBtZXRob2RzIHNvIGl0IGNsZWFybHkgc2lnbmFscyB0aGF0IHRoZXJlIGlzIG5vIENvQVAg c2VydmVyLiBBbmQgaWYgdGhlcmUgaXMgYSBDb0FQIHNlcnZlciB3aXRob3V0IHJlc291cmNlcyBp dCBjYW4gc3RhcnQgc2VuZGluZyA0LjA0LCBidXQgdGhhdCBpcyB0byBtZSBhIGRpZmZlcmVudCBj YXNlIQ0KDQoNCg0KYmVzdCByZWdhcmRzDQoNCkVza28NCg0KRnJvbTogY29yZSBbbWFpbHRvOmNv cmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEphaW1lIEppbcOpbmV6DQpTZW50OiBN b25kYXksIE1hcmNoIDEzLCAyMDE3IDE1OjAyDQpUbzogY29yZUBpZXRmLm9yZyBXRyA8Y29yZUBp ZXRmLm9yZz4NCkNjOiBkcmFmdC1pZXRmLWNvcmUtY29hcC10Y3AtdGxzQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogW2NvcmVdIPCflJQgV0dMQyBkcmFmdC1pZXRmLWNvcmUtY29hcC10Y3AtdGxzDQoN CkRlYXIgQ29SRSBXRywNCg0Kd2UgaGF2ZSBleHRlbmRlZCBhIGJpdCB0aGUgY2FsbCBhcyB0aGVy ZSB3ZXJlIGZldyBpc3N1ZXMgbGVmdC4gQXQgdGhpcyBwb2ludCB0aGVyZSBhcmVu4oCZdCBhbnkg b3RoZXIgaXNzdWVzIHdlIHdpbGwgY2xvc2UgdGhpcyBjYWxsIGFuZCBtb3ZlIHRoZSBkb2N1bWVu dCBmb3J3YXJkLg0KTGF0ZXN0IHZlcnNpb246IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWNvcmUtY29hcC10Y3AtdGxzLTA3DQoNClRoYW5rcyEhDQpKYWltZSBKaW3DqW5l eg0KDQpPbiAxNSBGZWIgMjAxNywgYXQgMTQuMTcsIEphaW1lIEppbcOpbmV6IDxqYWltZS5qaW1l bmV6QGVyaWNzc29uLmNvbTxtYWlsdG86amFpbWUuamltZW5lekBlcmljc3Nvbi5jb20+PiB3cm90 ZToNCg0KRGVhciBDb1JFIFdHLA0KDQpUaGVyZSBoYXMgYmVlbiBxdWl0ZSBzb21lIHdvcmsgb24g dGhlICJDb0FQIChDb25zdHJhaW5lZCBBcHBsaWNhdGlvbiBQcm90b2NvbCkgb3ZlciBUQ1AsIFRM UywgYW5kIFdlYlNvY2tldHPigJ0gZHJhZnQgKGRyYWZ0LWlldGYtY29yZS1jb2FwLXRjcC10bHMp IHNpbmNlIHRoZSBsYXN0IFdHTEMuDQpCSUcgdGhhbmtzIHRvIEJyaWFuIGZvciB0aGUgdGltZSBh bmQgZWZmb3J0IGRlZGljYXRlZCBhcyBFZGl0b3IuIEl0IG5vdyBzZWVtcyBhIGdvb2QgdGltZSBm b3IgYSBmaW5hbCBXR0xDIHRvIGdldCB0aGUgbGFzdCBjb21tZW50cyBmcm9tIHRoZSBncm91cCBp biBvcmRlciB0byBtb3ZlIHRoZSBzcGVjaWZpY2F0aW9uIGZvcndhcmQuDQoNCkluIHBhcnRpY3Vs YXIgdGhlcmUgaGFzIG5vdCBiZWVuIG11Y2ggZGlzY3Vzc2lvbiBvbiBzZWN1cmluZyBDb0FQIG92 ZXIgV2ViU29ja2V0cyAoaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvY29hcC10Y3AtdGxzL2lz c3Vlcy8xMDIpIGFzIHdlbGwgYXMgdGhlIERlZmF1bHQgVVJJIGhvc3QgKGh0dHBzOi8vZ2l0aHVi LmNvbS9jb3JlLXdnL2NvYXAtdGNwLXRscy9pc3N1ZXMvMTA4KSBmZWVkYmFjayB3b3VsZCBiZSB2 ZXJ5IG11Y2ggd2VsY29tZWQuIFBsZWFzZSBnbyBhaGVhZCBhbmQgY2hlY2sgdGhlIGRpc2N1c3Np b25zIG9uIHRoZSBvdGhlciBpc3N1ZXMgb2YgdGhpcyB2ZXJzaW9uOiBodHRwczovL2dpdGh1Yi5j b20vY29yZS13Zy9jb2FwLXRjcC10bHMvbWlsZXN0b25lLzQ/Y2xvc2VkPTEgIGFuZCBvbiB0aGUg Y2hhbmdlbG9nIHN1bW1hcnkuIEluIGFkZGl0aW9uIHRvIHRoYXQsIEkgd291bGQgbGlrZSB0byBh c2sgdGhlIGdyb3VwIHRvIGxldCBtZSBrbm93IHRoZWlyIGN1cnJlbnQgaW1wbGVtZW50YXRpb24g c3RhdHVzIG9mIHRoZSBkcmFmdCBmb3IgdGhlIHNoZXBoZXJkIHdyaXRldXAsIGVzcGVjaWFsbHkg T3BlbiBTb3VyY2UgaW1wbGVtZW50YXRpb25zIG9mIHRoZSBkcmFmdC4NCg0KbGF0ZXN0IHZlcnNp b246IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNvcmUtY29hcC10Y3At dGxzLTA2DQpkaWZmOiBodHRwczovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1p ZXRmLWNvcmUtY29hcC10Y3AtdGxzLTA2LnR4dA0KY2hhbmdlbG9nOiBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3JlLWNvYXAtdGNwLXRscy0wNiNhcHBlbmRpeC1DLjQN Cg0KVGhlIFdHTEMgd2lsbCBsYXN0IG9uZSB3ZWVrLCB1bnRpbCAyMDE3LTAyLTIyIC4NCg0KVGhh bmtzIQ0KSmFpbWUgSmltw6luZXoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3NhZ2UgbWF5IGJlIGNvbmZp ZGVudGlhbCBhbmQgbGVnYWxseSBwcm90ZWN0ZWQgdW5kZXIgYXBwbGljYWJsZSBsYXcuIFRoZSBt ZXNzYWdlIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZShzKS4gSWYgeW91IGFy ZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhh dCBhbnkgdXNlLCBmb3J3YXJkaW5nLCBkaXNzZW1pbmF0aW9uLCBvciByZXByb2R1Y3Rpb24gb2Yg dGhpcyBtZXNzYWdlIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4g SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhl IHNlbmRlciBieSByZXR1cm4gZS1tYWlsIGFuZCBkZXN0cm95IGFsbCBjb3BpZXMgb2YgdGhlIG9y aWdpbmFsIG1lc3NhZ2UuDQo= --_000_8e2b2a0a00bb404d930adf0ae9ce08adAM3PR90MB0097MGDPHGemip_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2Ft YnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJTZWdvZSBVSSBTeW1ib2wiOw0KCXBhbm9zZS0x OjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05v cm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K cA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5KYWltZSAmYW1wOyBh dXRob3JzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5sb29raW5nIGF0IHRoZSByZWNlbnQgY2hhbmdlcyBJIHNl ZSBvbmx5IG9uZSBpc3N1ZSBsZWZ0OiB0aGUgZGVmaW5lZCBiZWhhdmlvciBvZiBhIENvQVAgZW5k cG9pbnQgdGhhdCBkb2Vzbid0IGltcGxlbWVudCBhIENvQVAgc2VydmVyLiBUaGUgbmV3IHRleHQg c3RhdGVzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjBjbTttYXJn aW4tbGVmdDoyNy4wcHQ7bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+SWYgb25lIHNpZGUgZG9lcyBub3QgaW1wbGVtZW50IGEmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENvQVAgc2VydmVyLCBhbiBhcHByb3ByaWF0ZSBlcnJvciBy ZXNwb25zZSBzdWNoIGFzIDQuMDQgKE5vdCBGb3VuZCkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0i bWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IG9yIDUuMDEgKE5vdCBJbXBsZW1lbnRlZCkgTVVTVCBiZSByZXR1cm5lZCBmb3Ig YWxsIENvQVAgcmVxdWVzdHMgZnJvbSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGNt O21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg dGhlIG90aGVyIHNpZGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlJlcXVpcmluZyB3aXRoIE1VU1Qgc29tZXRo aW5nIHRoYXQncyB2YWd1ZWx5IGRlZmluZWQgKCZxdW90O3N1Y2ggYXMgWCBvciBZJnF1b3Q7KSBz ZWVtcyBhIGJhZCBpZGVhIHRvIG1lLiBCZXNpZGVzLCB3aGVuIHRoZSBlbmRwb2ludCB3b3VsZCBz dGFydCByZXR1cm5pbmcgNC4wNCB0aGVuIGl0IGFjdHVhbGx5ICo8Yj5pczwvYj4qDQogYSBDb0FQ IHNlcnZlciBhbGJlaXQgb25lIHdpdGhvdXQgYW55IHJlc291cmNlcy4gU3RpbGwgaXQgaXMgZXhw ZWN0ZWQgdG8gYmVoYXZlIGxpa2UgYSBDb0FQIHNlcnZlciB0aGVuIOKAkyBlLmcuIHJldHVybiA0 LjAyIGlmIGFuIHVua25vd24gY3JpdGljYWwgb3B0aW9uIGlzIGZvdW5kIGluIHRoZSByZXF1ZXN0 LCBldGNldGVyYS4gVG8gYXZvaWQgYWxsIHRoZXNlIGlzc3VlcyBhbmQgdG8gcmVhbGx5IG1ha2Ug Y2xlYXIgdGhlcmUgaXMgbm8gc2VydmVyDQogYXQgYWxsIOKAkyBpLmUuIGl0IGlzbid0IGFibGUg dG8gcHJvY2VzcyBvciB2YWxpZGF0ZSBhbnkgcmVxdWVzdCDigJMgdGhlIGZvbGxvd2luZyB3b3Vs ZCBiZSBtdWNoIGJldHRlcjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGNtO21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRv bTowY207bWFyZ2luLWxlZnQ6MjcuMHB0O21hcmdpbi1ib3R0b206LjAwMDFwdCI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPklmIG9uZSBzaWRlIGRvZXMgbm90IGltcGxlbWVudCBhJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBDb0FQIHNlcnZlciwgYW4gZXJyb3IgcmVz cG9uc2UgNS4wMSAoTm90IEltcGxlbWVudGVkKSBNVVNUIGJlDQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cmV0dXJuZWQgZm9yIGFsbCBDb0FQ IHJlcXVlc3RzIGZyb20mbmJzcDt0aGUgb3RoZXIgc2lkZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPjUuMDEgaW4gdGhpcyBjYXNlIG1lYW5zIHRoZSBlbmRwb2ludCBoYXNuJ3QgaW1wbGVt ZW50ZWQgYW55IENvQVAgbWV0aG9kcyBzbyBpdCBjbGVhcmx5IHNpZ25hbHMgdGhhdCB0aGVyZSBp cyBubyBDb0FQIHNlcnZlci4gQW5kIGlmIHRoZXJlDQogaXMgYSBDb0FQIHNlcnZlciB3aXRob3V0 IHJlc291cmNlcyBpdCBjYW4gc3RhcnQgc2VuZGluZyA0LjA0LCBidXQgdGhhdCBpcyB0byBtZSBh IGRpZmZlcmVudCBjYXNlITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46 MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4t Ym90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+YmVzdCByZWdhcmRz PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRv bTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkVza288bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiBjb3JlIFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+ T24gQmVoYWxmIE9mIDwvYj5KYWltZSBKaW3DqW5lejxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXks IE1hcmNoIDEzLCAyMDE3IDE1OjAyPGJyPg0KPGI+VG86PC9iPiBjb3JlQGlldGYub3JnIFdHICZs dDtjb3JlQGlldGYub3JnJmd0Ozxicj4NCjxiPkNjOjwvYj4gZHJhZnQtaWV0Zi1jb3JlLWNvYXAt dGNwLXRsc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2NvcmVdIDwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSBT eW1ib2wmcXVvdDssc2Fucy1zZXJpZiI+JiMxMjgyNzY7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ IFdHTEMgZHJhZnQtaWV0Zi1jb3JlLWNvYXAtdGNwLXRsczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZWFyIENvUkUgV0csPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPndlIGhhdmUgZXh0ZW5k ZWQgYSBiaXQgdGhlIGNhbGwgYXMgdGhlcmUgd2VyZSBmZXcgaXNzdWVzIGxlZnQuIEF0IHRoaXMg cG9pbnQgdGhlcmUgYXJlbuKAmXQgYW55IG90aGVyIGlzc3VlcyB3ZSB3aWxsIGNsb3NlIHRoaXMg Y2FsbCBhbmQgbW92ZSB0aGUgZG9jdW1lbnQgZm9yd2FyZC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5MYXRlc3QgdmVyc2lv bjombmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1j b3JlLWNvYXAtdGNwLXRscy0wNyI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtY29yZS1jb2FwLXRjcC10bHMtMDc8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzISE8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkphaW1lIEppbcOpbmV6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIDE1IEZlYiAyMDE3LCBhdCAxNC4xNywgSmFpbWUgSmltw6luZXogJmx0OzxhIGhyZWY9Im1h aWx0bzpqYWltZS5qaW1lbmV6QGVyaWNzc29uLmNvbSI+amFpbWUuamltZW5lekBlcmljc3Nvbi5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5EZWFyIENvUkUgV0csPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIGhhcyBiZWVuIHF1aXRlIHNvbWUgd29yayBv biB0aGUgJnF1b3Q7Q29BUCAoQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wpIG92ZXIg VENQLCBUTFMsIGFuZCBXZWJTb2NrZXRz4oCdIGRyYWZ0IChkcmFmdC1pZXRmLWNvcmUtY29hcC10 Y3AtdGxzKSBzaW5jZSB0aGUgbGFzdCBXR0xDLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QklHIHRoYW5rcyB0byBCcmlhbiBmb3IgdGhl IHRpbWUgYW5kIGVmZm9ydCBkZWRpY2F0ZWQgYXMgRWRpdG9yLiBJdCBub3cgc2VlbXMgYSBnb29k IHRpbWUgZm9yIGEgZmluYWwgV0dMQyB0byBnZXQgdGhlIGxhc3QgY29tbWVudHMgZnJvbSB0aGUg Z3JvdXAgaW4gb3JkZXIgdG8gbW92ZSB0aGUgc3BlY2lmaWNhdGlvbiBmb3J3YXJkLiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBw YXJ0aWN1bGFyIHRoZXJlIGhhcyBub3QgYmVlbiBtdWNoIGRpc2N1c3Npb24gb24gc2VjdXJpbmcg Q29BUCBvdmVyIFdlYlNvY2tldHMgKDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdn L2NvYXAtdGNwLXRscy9pc3N1ZXMvMTAyIj5odHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9jb2Fw LXRjcC10bHMvaXNzdWVzLzEwMjwvYT4pIGFzIHdlbGwgYXMgdGhlIERlZmF1bHQgVVJJIGhvc3Qg KDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL2NvYXAtdGNwLXRscy9pc3N1ZXMv MTA4Ij5odHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9jb2FwLXRjcC10bHMvaXNzdWVzLzEwODwv YT4pDQogZmVlZGJhY2sgd291bGQgYmUgdmVyeSBtdWNoIHdlbGNvbWVkLiBQbGVhc2UgZ28gYWhl YWQgYW5kIGNoZWNrIHRoZSBkaXNjdXNzaW9ucyBvbiB0aGUgb3RoZXIgaXNzdWVzIG9mIHRoaXMg dmVyc2lvbjombmJzcDs8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9jb2FwLXRj cC10bHMvbWlsZXN0b25lLzQ/Y2xvc2VkPTEiPmh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL2Nv YXAtdGNwLXRscy9taWxlc3RvbmUvND9jbG9zZWQ9MTwvYT4mbmJzcDsmbmJzcDthbmQNCiBvbiB0 aGUgY2hhbmdlbG9nIHN1bW1hcnkuIEluIGFkZGl0aW9uIHRvIHRoYXQsIEkgd291bGQgbGlrZSB0 byBhc2sgdGhlIGdyb3VwIHRvIGxldCBtZSBrbm93IHRoZWlyIGN1cnJlbnQgaW1wbGVtZW50YXRp b24gc3RhdHVzIG9mIHRoZSBkcmFmdCBmb3IgdGhlIHNoZXBoZXJkIHdyaXRldXAsIGVzcGVjaWFs bHkgT3BlbiBTb3VyY2UgaW1wbGVtZW50YXRpb25zIG9mIHRoZSBkcmFmdC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmxhdGVzdCB2 ZXJzaW9uOiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLWNvcmUtY29hcC10Y3AtdGxzLTA2Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1jb3JlLWNvYXAtdGNwLXRscy0wNjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZGlmZjombmJzcDs8YSBocmVmPSJo dHRwczovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWNvcmUtY29hcC10 Y3AtdGxzLTA2LnR4dCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt aWV0Zi1jb3JlLWNvYXAtdGNwLXRscy0wNi50eHQ8L2E+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5jaGFuZ2Vsb2c6Jm5ic3A7PGEgaHJl Zj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS1jb2FwLXRjcC10 bHMtMDYjYXBwZW5kaXgtQy40Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1jb3JlLWNvYXAtdGNwLXRscy0wNiNhcHBlbmRpeC1DLjQ8L2E+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBXR0xDIHdpbGwg bGFzdCBvbmUgd2VlaywgdW50aWwmbmJzcDs8Yj4yMDE3LTAyLTIyPC9iPiAuJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyE8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkphaW1l IEppbcOpbmV6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YnI+DQo8aHI+DQo8Zm9udCBmYWNlPSJBcmlhbCIgY29sb3I9IkdyYXkiIHNp emU9IjEiPlRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdlIG1heSBiZSBj b25maWRlbnRpYWwgYW5kIGxlZ2FsbHkgcHJvdGVjdGVkIHVuZGVyIGFwcGxpY2FibGUgbGF3LiBU aGUgbWVzc2FnZSBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNzZWUocykuIElmIHlv dSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVk DQogdGhhdCBhbnkgdXNlLCBmb3J3YXJkaW5nLCBkaXNzZW1pbmF0aW9uLCBvciByZXByb2R1Y3Rp b24gb2YgdGhpcyBtZXNzYWdlIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxh d2Z1bC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRh Y3QgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsIGFuZCBkZXN0cm95IGFsbCBjb3BpZXMgb2Yg dGhlIG9yaWdpbmFsIG1lc3NhZ2UuPGJyPg0KPC9mb250Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_8e2b2a0a00bb404d930adf0ae9ce08adAM3PR90MB0097MGDPHGemip_-- From nobody Tue Mar 14 02:03:17 2017 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 59F0B129524; Tue, 14 Mar 2017 02:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukcibPETHNcI; Tue, 14 Mar 2017 02:03:15 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1E04129469; Tue, 14 Mar 2017 02:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v2E93A5N012144; Tue, 14 Mar 2017 10:03:10 +0100 (CET) Received: from [192.168.217.124] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vj80G37PFzDH7r; Tue, 14 Mar 2017 10:03:10 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: <8e2b2a0a00bb404d930adf0ae9ce08ad@AM3PR90MB0097.MGDPHG.emi.philips.com> Date: Tue, 14 Mar 2017 10:03:09 +0100 X-Mao-Original-Outgoing-Id: 511174989.76073-42626466cebb9aec40f3d1da1baf3823 Content-Transfer-Encoding: quoted-printable Message-Id: <3C026127-6EDD-473D-B3CC-92AD7C0F6172@tzi.org> References: <938FB795-A352-448A-B380-ABBFA2F04DE9@ericsson.com> <8e2b2a0a00bb404d930adf0ae9ce08ad@AM3PR90MB0097.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "draft-ietf-core-coap-tcp-tls@ietf.org" , "core@ietf.org WG" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_draft-ietf-core-coap-tcp-tls?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 14 Mar 2017 09:03:16 -0000 Hi Esko, we didn=E2=80=99t quite feel that we should be restricting the behavior = too much. You are right that > If one side does not implement a =20 > CoAP server, an appropriate error response such as 4.04 = (Not Found) =20 > or 5.01 (Not Implemented) MUST be returned for all CoAP = requests from =20 > the other side. is somewhat self-defeating, because as soon as it sends 4.04s it *does* = implement a server, so the MUST no longer applies :-) So that does not really make a lot of difference to me from: > If one side does not implement a =20 > CoAP server, an error response 5.01 (Not Implemented) MUST = be > returned for all CoAP requests from the other side. And I agree that without the alternatives this is much easier to follow = as guidance. Maybe we can add that the alternative to 5.01 is to implement a mock = server that returns 4.04 or 4.02. So how about separating the MUST from = the implementation guidance: > If one side does not implement a =20 > CoAP server, an error response MUST be > returned for all CoAP requests from the other side. > The simplest way to do this is to always return 5.01 (Not = Implemented);=20 > a more elaborate mock server could also return 4.xx responses=20 > such as 4.04 or 4.02 where appropriate. (A mock server that returns 4.02 still has to implement the option = parsing for the requests, but that is the same as for the responses and = the signaling messages =E2=80=94 maybe we should document the minimal = behavior for a mock server with 4.02 etc., here or in the newly = resurrected lwig-coap draft.) Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Mar 14 02:16:36 2017 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 E351D129515; Tue, 14 Mar 2017 02:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.912 X-Spam-Level: X-Spam-Status: No, score=-2.912 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_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-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=philips.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 9NTx-84NGXCV; Tue, 14 Mar 2017 02:16:32 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0097.outbound.protection.outlook.com [104.47.2.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63D18129503; Tue, 14 Mar 2017 02:16:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Philips.onmicrosoft.com; s=selector1-philips-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yJpBz7RHjkHoW5tf5sWJyyvCXOahubJbZ/yobfh5RfQ=; b=E+IftPo2N/bwyjBuil673lt65elA2BmJkKOcbYGpjvR4ydhw1g7xHTwdFd1/t+konOAPgOC4yBWc3dsCgbZfQqcHRq5pAMjxlTwJ7P1fWbxBDOxXWCYTcoHfWJdAZDjEgUyDR2XdEbvcCfWOXmytaNjjBd5lamBj4jp+MWmolaE= Received: from DB6P122CA0004.EURP122.PROD.OUTLOOK.COM (129.75.140.18) by AM5P122MB0034.EURP122.PROD.OUTLOOK.COM (129.75.138.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.17; Tue, 14 Mar 2017 09:16:29 +0000 Received: from AM1FFO11FD016.protection.gbl (2a01:111:f400:7e00::174) by DB6P122CA0004.outlook.office365.com (2603:10a6:24:2::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.17 via Frontend Transport; Tue, 14 Mar 2017 09:16:29 +0000 Authentication-Results: spf=neutral (sender IP is 23.103.228.36) smtp.mailfrom=philips.com; tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=philips.com; Received-SPF: Neutral (protection.outlook.com: 23.103.228.36 is neither permitted nor denied by domain of philips.com) Received: from 011-smtp-out.Philips.com (23.103.228.36) by AM1FFO11FD016.mail.protection.outlook.com (10.174.64.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.10 via Frontend Transport; Tue, 14 Mar 2017 09:16:29 +0000 Received: from AM3PR90MB0097.MGDPHG.emi.philips.com (141.251.117.145) by AM3PR90MB0099.MGDPHG.emi.philips.com (141.251.117.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.17; Tue, 14 Mar 2017 09:16:28 +0000 Received: from AM3PR90MB0097.MGDPHG.emi.philips.com ([141.251.117.145]) by AM3PR90MB0097.MGDPHG.emi.philips.com ([141.251.117.145]) with mapi id 15.01.0961.021; Tue, 14 Mar 2017 09:16:28 +0000 From: "Dijk, Esko" To: Carsten Bormann Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV0dMQyBkcmFmdC1pZXRmLWNvcmUtY29hcC10Y3AtdGxz?= Thread-Index: AQHSnFVkHn8Z58Yne0KTgPnHpk1WCKGUBJIAgAAGXYCAAAM1YA== Date: Tue, 14 Mar 2017 09:16:28 +0000 Message-ID: References: <938FB795-A352-448A-B380-ABBFA2F04DE9@ericsson.com> <8e2b2a0a00bb404d930adf0ae9ce08ad@AM3PR90MB0097.MGDPHG.emi.philips.com> <3C026127-6EDD-473D-B3CC-92AD7C0F6172@tzi.org> In-Reply-To: <3C026127-6EDD-473D-B3CC-92AD7C0F6172@tzi.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [83.85.138.53] X-MS-Office365-Filtering-Correlation-Id: e3bf946c-0f9e-42a7-4635-08d46abaccb7 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OrganizationHeadersPreserved: AM3PR90MB0099.MGDPHG.emi.philips.com X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:23.103.228.36; IPV:NLI; CTRY:; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39840400002)(39450400003)(39850400002)(39860400002)(2980300002)(199003)(374574003)(85714005)(189002)(13464003)(9170700003)(6916009)(2950100002)(5660300001)(229853002)(7696004)(106466001)(106116001)(24736003)(105586002)(2900100001)(33646002)(229383001)(102836003)(6116002)(3846002)(2906002)(189998001)(356003)(23676002)(7736002)(8936002)(305945005)(66066001)(81166006)(4326008)(38730400002)(6246003)(110136004)(53546007)(86362001)(50986999)(55016002)(93886004)(108616004)(76176999)(47776003)(54356999)(54906002)(50466002)(230783001)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5P122MB0034; H:011-smtp-out.Philips.com; FPR:; SPF:Neutral; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11FD016; 1:4eJlRZiFns2RENJyjUlVeZwOV4plGb0Z+sgf8HmByF/0SjS5nnMCTyK2+/uuVN0mXAkS11VWiTyOsdh2vedgL2uurVU1YdenbxMrSP2jFcP5miU70mO8wQhBRzlaGlfxVuhQDhdCeDu14vwpE2DNWG3nBvmzT+5+ds685pqTEyuvbhvjy4KD2KRzbmwvy2xfy4ksGdkLp//pbF3BbdzqhBoBy+DYUNFtC84Sxa/NcRgwSgO+D58g6o1w1HtoMemsiOIZg+cD/d42q0Zbfey6rC7ZNHpDv7AtiyAqyoTRppXS5T4bvGROrYM8L3EffjKFt8b2Q1wAOQWYGkN0UTJ3Sr0AemKOzCRFbS7e8tKdyDZAepdu93xMIxcBCtpztDGZodnlwMd6575k4N1f59TNkep6ITX3rqH+RNHojhb/Dm88mZuRZr8JUTkkkeqHy/tyhNXlltnZRTYLXbk8NsDlvUk6HvnoCRDeJaWtHlAv7ABgK1GAgh6TkkpD0KM8Jn8l X-CrossPremisesHeadersPromoted: AM1FFO11FD016.protection.gbl X-CrossPremisesHeadersFiltered: AM1FFO11FD016.protection.gbl X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM5P122MB0034; X-Microsoft-Exchange-Diagnostics: 1; AM5P122MB0034; 3:HscTG/XT7ue49hRiCNM9S4a3aYK/oI+IwM0/1oqTb37ODdO76Z6bX2/o929UkBvFjUNR2XZV28fPVaOmSadBwSuOD7qQl28NXcWwwu0UERkPuqv1AsSe9V3PGPFTr0H5XDosT9t/koEQQLNddmqQaTiRFmIIob86A257ruqBSwwafhK//JltsYZDOGSL8qYvvFcCir/MdZ8na8wsdwdL7QvaC0vyQUTfKUpzvAFyo3tvSpG8LY+WjN6elWd+PkE3B7LeTDjDsOt4fMhqq3PEA3iqpyqFsHILv2+/R4ORPjV/VPSKeg4t8DFRepK1A9XSqGFvFPAuCv+cfJAPYM5dX8yDqUMfyuwKhWQ3BxUAxlE=; 25:XNsh9DvACrjqu0Qa7OSmD5JYHd3RZuSfUGHwqojEm/dqszSWuXwxcSP68IcULKx6rMxOUVx844i/cvy+jTmkgtjmup7oVrN4ax0oUBYXlX9WGULMx2NtZyAE6BwkFhacWDBl2akJ0YXoYRblJ/6VoMZgNrCgGtxluE1vqLVIAMxFatBnlQAnDmgpRVGyvl5Cma0pYVlFb7EiZh6R6WuD/kOWHl2hQTR+5zT2wFD9kNHdXRxkblpoOX7hdEHm+hH9xJGq3WYJ9LdHWE9R1jBFhlcAQ0I65bSiWjLTS+1VcKivfhm+iWigf2bP+1wncQkBqKX7uz1RwN5XU5ForPbuWTXOABpXAR5QmvbsKKz5pViFZxC3Q3IDGti4G4QqVTAlBoWbS6H5Gw4xdznfczkPW6fwFJU3ha/DwF3wwnbKqX7zJH2USUnyrPoK1UBlQ75r301748hK5lHkYJOKCieAeg== X-Microsoft-Exchange-Diagnostics: 1; AM5P122MB0034; 31:IDL57WUMFBJDgoOLOtka+6tQaqtZH267t4bUvb64CIn5qCGCO/4+BLEDtSe6mqhtcfvM3ivEwZWz/JtSNpjj+coBtFL8sT0cWwl0u+7iXeZlXY5iDSzuT9K+M3g5Pkd8d4q6I7hRaSHDy3FFudJ/TAjBCR899XCTmJsmfX5I+9GxN9ucbmovih5hYinxeFokf9yJHRziMLEEkUr39vkmHvf2RBquUV3z+4ZFk9aR9oPKCKjudIFT/UQA5d6cKkHahSahtDlZmAJ/YJWw5TqAOw==; 20:94nmSQ8Ji/j7KGMZE74ck/EjA2SO3YkrY/ui9qaUlseIWyfSkulhLSps/D6HHQvB+CfIAA6C98+Prf8sa1TnWxu2cgEPNhMShSlGeP+SleYJUfUZOF50GiuE3ESJXKnRRgbY6zJYyEAlA4t5RNFndPEMAcwtT4P/KZov+2w+gn9IOIMdCAwG6Ib56i1fcIrIS/Jkn208uXJss73RmbT++p1xyQvNzW+S5HBjKzQTgWKFtCU4tdP53PQRK5YR5/aU+kybIPRfG2FbGjpm+1E9Zhe7B6UiF/zC1lireyAD+5jdA3WD3mzNpkWKdmq7vxLtgRSst7rofTphm6+7Qb1w+MNEuQDVLeSLYFqQNgd2EVUdkI5nH/P/2TZha3U5yavHx/eO2jP2YfdYQgSStmY5PpjfJHp63HHJyCMNdKfcMS5swm6foJZeQ2aF0SY3bnIMmRm0HmcZJFeex+QhFdSpfwmHuGd5QzBhPVgiQ0M13LSMssTmCyrFPN6E/5zbJTUK X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(158342451672863)(260087099026482); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(13016025)(5005006)(8121501046)(13018025)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123564025)(20161123555025)(20161123558025)(20161123560025)(6072148); SRVR:AM5P122MB0034; BCL:0; PCL:0; RULEID:; SRVR:AM5P122MB0034; X-Microsoft-Exchange-Diagnostics: 1; AM5P122MB0034; 4:CIKKVbexCbPycdkHT9M5bnQUfUXd4g7F9dgUVuSvZlsf8L9SQ0Izr7qiX9FF3kMcW+K/HPliw4THQjY1SdFmIkqDgdBWBl4F5rsN6HycVMKvEDNDNVk8xPxmGJktpYWjN7xDEgGneKMx54fpW//T4Cqa85ccLOUFrVoOCM/xdT1KlQ7LmpwxJ3bgmrTdHh+IUW7WGTLVxmi1N05EEvyF7lkiCrLshdYD83R+Z9qufPCEBDYeNH/zk968ugz1YG5SjvV+J/HwpqwXB2gYHjNdK5izU1VIE5mVYgEXd6dD/nWLQwq5IBmmFCvet8n22BkU8Z4qWPWsHB6lfju56c7r7qEmsNsdukbyJcjthCssE1yMZJaaMBP4BPZf0TDYS+vw3/ssD06RaPhYmzequJ3rqdiBwX4KrPRK1GtfnuBRM7+VSfTjpPwP+A/FmaXsbM8UlButpC1ZZHge9F3Pz/NIdl4stKJcje9uhX/qlxsaCnpd3Ba4SmSmC3yc8pUiflsA8fEWOaPpQeWSt7EBKGBxJQtsyHpcjNjCTLzg8Vpf44HxovtwCBva+mbfbozb3oXJwYEXWfhjJ4vzMt1REH9hy5rKydivUKzS8+8gxHY2mN3sPHi3kg2/n+tl1OR8QTW9yWGLjVnkNB8Tj8fJwJWVG4tYK9RV/s0os+JOQguuYoO2msGpGWv4vHdlbVxLC5ZX4MV0RYxaeXuJEiqdW8SGZMJRxtx3Ec8e5NdZMvX3XxvtlRIILQvLGh6Sc4XpwSysouU0fb3/+ZcjZwBpNuMmCA== X-Forefront-PRVS: 02462830BE X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTVQMTIyTUIwMDM0OzIzOkpteTFDVWhnYjRuREFzUTN4Z2YzT2NQZlJE?= =?utf-8?B?bk9pejZMYmxpby9QUGxhaFhhZ0dMWDBPTU1aUjByclVxYmhwZGZndThJR1p0?= =?utf-8?B?ejhhczF3SDB2TVQrb21WYkszV09kYlN0cGZLSm5KTCtzL29WMzlsd2dCcE41?= =?utf-8?B?Q1hXZWJKd3ptNXBFSWZHY3ZsWmpNblM5a0ZFR1dhNnBQMHZiaUs5OFhZaHJG?= =?utf-8?B?MTZBZUpVV0VaeEdxZUxsMTk3WkZTVUcxZlN1MGp6OWJlS2VJbFYxOWlHUUxj?= =?utf-8?B?WjRCbUZjc0VCVDJSQVpFMmw4SDJBdW45T1ZQeG9ZSmhrVVArekFKak5Bd0lh?= =?utf-8?B?TFEvVTU0V0lubE9RTmMxQlFmcEdWYW9LcTUrdjd6OHRVSDNUa3RtczJ1WFo3?= =?utf-8?B?aHV1c1hyNEFXUWNTYjlTVUlsbyttODJ2V0ZoVURxVGdNeU9kMjZYaG1pTnFy?= =?utf-8?B?LytTbW01bWlKc2xIZFRUUnV5WmxsU0tJWFhMTUxXTnhhMllXc09BV3dra3BF?= =?utf-8?B?d05zeXVWcldLUWVhOFFpN0ZCZS9hMDA5VWxxVXZFMzhnQTN5bnB4WmgvcUxy?= =?utf-8?B?bjFKWUI0T3N1azBHNzk0SDRNMHFmZG9wb080bjBPMUhuNVhrYVM2Mk9QQVRx?= =?utf-8?B?NCtydm14MlNqblJMS29KQVN2NUVlamM3VEtvNE9Vbkl5ZEhsR2NSMzlneGxh?= =?utf-8?B?TVgxY0x4czRyTjVIMStjKzNUTzZzdCtWMmtjMk93OTJGSS9yUkNzRno5R1B6?= =?utf-8?B?SVlNSU5kN1hNMUZFNVFzcm5SYWRZcDN2Vy9Ddmo4NWxSU0d1b0h3UW85YnE3?= =?utf-8?B?UXNQRHVxR2ZUR0xmWExZa1VwTURPTEoyd1RjRW9UZWpLenovdnZSZmdrVGhl?= =?utf-8?B?NElFMEFPbEdtSGhhbU9ZY3owdVZvK1o3TXBVcXNwdUUzTFJOdmNaS256bkVK?= =?utf-8?B?b01zR2k2T012N2Q4eE1WNExiNlE5elpodks5K0UyT0pya1owVGlLVVFlMk5P?= =?utf-8?B?b1N0MnNmUm0vV1k0TSs5UXJMU3ViL0dVTy9PdHdLL3hWYzFvZzNUZ2Q5SmV5?= =?utf-8?B?dVNvSVU5UDNkQmdKT1QyL3RNWEFGVCt1eDhTMDVqUHJpUCtGbU96dFU5cExO?= =?utf-8?B?VTFHQzZVVDFERjQxUWw2MUJSMDlVZVh5ak9KNHZidmJqTW4zc2t0ODJQUDc0?= =?utf-8?B?NjFzYVUwYlpDV1JvK1Z1TmRvTWhiUWlpTkNHK0xtb3QvZmQ0TUtoQ2puQjR1?= =?utf-8?B?VjZGZHAzWk9OUTFxeVdRbXFmSWtZMkJ2bVYzRUxKZWNoa052bGtzL2M1cStE?= =?utf-8?B?UWdEVVpQY3R5cmFBVlNua0JhMSsyd3JNNC94OVJCODNLdFBUTUVmQk10ZGUz?= =?utf-8?B?SXpKamV0NlNQRys1dmV3TEVBdkZlTGJZbk41K0hTN0hSc2ZLR0tIMFhOWlFW?= =?utf-8?B?OVdoUXBqTW4rQ3RQcFE1b2YvL3pkMmJiV1BRajJ0MGpjN0k0Rm5UdVpQaUNV?= =?utf-8?B?ZWJpY2hRMzdzbzFQSUFCQlVuZlFNZUZ2V0l3Q25TeUZwT3JkeXFmbEFxNlZO?= =?utf-8?B?N1BQUVprbXgvalE1YVBiaGtwRG5wME1jTkR2QXBUVGFoNkExajYwWjNyUWdl?= =?utf-8?B?VkdVVnE4aHIxQ3kzZXc4U3hEV1NlRUthVUJPU0oxZ1RQVnp1amRMZGFRNHdE?= =?utf-8?B?VS9aNVhtczZFTlpNYXJLakhiaUJkZis0UHRGV0dtMld4MHJ0N0Y1b3Nrb3l4?= =?utf-8?Q?deyKfg+7yrow2xtYT8yDm2e4EzsAdnIj/+OSQ=3D?= X-Microsoft-Exchange-Diagnostics: 1; AM5P122MB0034; 6:k5ctg4PfamW8FQT6JXslkE8OQthmkP6arc2VYQOSO6Ppz8633joxULf1DvauNL+GkcFQnmN8KpHeHCNRJ+VgwAiWiKAmIPYIUj9OvIWSot/HoF7pWRirA4EjM3NwKvrsxNCtJP7rci5VXRiowEZKIKAc+bn4HAMUP5CJrpGzw5JI6/wO3XOvduoKb6rjkS7TF1/NBpJMdS009VOiw9hryLi3oAycfMV7lwF+jJqiEu4a9G6gYHdEWRAJGRRL+KPtzI4mEOq0f3yIg2MgKcnUYSu4W3jvGjWExVG2snPmxCVklzvk8i4jRizBQwSSYZCyaN+jU15Jg4N3Kigtl0mowy6Z54aOymnnd7UlDxWX/N2wUZhTeth5vKnIUEHjbPjZMUwxcZiVVUohoKdo1mAZwkcqqNykmCvEh+yMDSduHz0=; 5:sqs2wE3HsVZR9Ssyaz9Gj9KGGdJapolgwTXUyUSsgCGRy/BH6SpEIIOYVcJVAIDZzAHQKNeuKok1HaXtuYVOMuLZtW9YVPdXwtN7Fuy23YcAyAIkn9yR7QuY4ZyIHEztv8WPW6rfllRTA2qVhQ5F+ykEyqn2Pi1FkpFL9vU+xfk=; 24:hHledluRJMREPTpNlLEbjWc9tICMdZqLdISICuCLB1/POV4HS2HJCdi3kJ8s3PF/p7k51iferSthcEnWa7vS5w35rRfEPi09GMamGkY6koY= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AM5P122MB0034; 7:QAw9Lkw3fCThqkaT3z1Xd3PJ7fvJCtZ2mXoh2rr+cuTz65XwjD+bN6rFnLslKRNG1TOmTIBOOjeHcPghtro/uBPGGETXMXJyq7k0IIjQK2FbKLFNC3i953zuffWy+di//jAj9DbKE7FIWEbWvWxG9c2ArqF/kTobg54gN+4HaUqxyKgk5QhWq9hCrcVxD1YqmPpmVvIgGBkOnlmfauuJm+w8G0BSZOcQZ+uyrewvm8REhZowZxDsIooi7Rdhni64nqAHUm2qvUQL5zD3iVt2ZL9z6aOwethhJViRqISYVJY8CX6DBy9B3w+K7VKZc0+zdXCdI0hRx+vSUgdZ4PFevw== X-OriginatorOrg: philips.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Mar 2017 09:16:29.6170 (UTC) X-MS-Exchange-CrossTenant-Id: 1a407a2d-7675-4d17-8692-b3ac285306e4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=1a407a2d-7675-4d17-8692-b3ac285306e4; Ip=[23.103.228.36]; Helo=[011-smtp-out.Philips.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5P122MB0034 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: AM3PR90MB0097.MGDPHG.emi.philips.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 83.85.138.53 X-MS-Exchange-CrossPremises-disclaimer-hash: 7fd5309d68bb4378c576a4d2c2ad972d336f5eb0475879c2a0b14da1aac98972 X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-AVStamp-Service: 1.0 X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating; SFV:NSPM; SKIP:0; X-OrganizationHeadersPreserved: AM5P122MB0034.EURP122.PROD.OUTLOOK.COM Archived-At: Cc: "draft-ietf-core-coap-tcp-tls@ietf.org" , "core@ietf.org WG" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_draft-ietf-core-coap-tcp-tls?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 14 Mar 2017 09:16:35 -0000 SGVsbG8gQ2Fyc3RlbiwNCg0KYWdyZWUgLSB0aGlzIHNlcGFyYXRpb24gbWFrZXMgaXQgbW9yZSBj bGVhci4gQW5kIHRoZSBNVVNUIHJlcXVpcmVtZW50IGlzIGFsc28gc3BlY2lmaWMgbm93Lg0KDQpF c2tvDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBDYXJzdGVuIEJvcm1hbm4g W21haWx0bzpjYWJvQHR6aS5vcmddDQpTZW50OiBUdWVzZGF5LCBNYXJjaCAxNCwgMjAxNyAxMDow Mw0KVG86IERpamssIEVza28gPGVza28uZGlqa0BwaGlsaXBzLmNvbT4NCkNjOiBKYWltZSBKaW3D qW5leiA8amFpbWUuamltZW5lekBlcmljc3Nvbi5jb20+OyBkcmFmdC1pZXRmLWNvcmUtY29hcC10 Y3AtdGxzQGlldGYub3JnOyBjb3JlQGlldGYub3JnIFdHIDxjb3JlQGlldGYub3JnPg0KU3ViamVj dDogUmU6IFtjb3JlXSDwn5SUIFdHTEMgZHJhZnQtaWV0Zi1jb3JlLWNvYXAtdGNwLXRscw0KDQpI aSBFc2tvLA0KDQp3ZSBkaWRu4oCZdCBxdWl0ZSBmZWVsIHRoYXQgd2Ugc2hvdWxkIGJlIHJlc3Ry aWN0aW5nIHRoZSBiZWhhdmlvciB0b28gbXVjaC4NCg0KWW91IGFyZSByaWdodCB0aGF0DQoNCj4g SWYgb25lIHNpZGUgZG9lcyBub3QgaW1wbGVtZW50IGENCj4gICAgICAgICAgICBDb0FQIHNlcnZl ciwgYW4gYXBwcm9wcmlhdGUgZXJyb3IgcmVzcG9uc2Ugc3VjaCBhcyA0LjA0IChOb3QgRm91bmQp DQo+ICAgICAgICAgICAgb3IgNS4wMSAoTm90IEltcGxlbWVudGVkKSBNVVNUIGJlIHJldHVybmVk IGZvciBhbGwgQ29BUCByZXF1ZXN0cyBmcm9tDQo+ICAgICAgICAgICAgdGhlIG90aGVyIHNpZGUu DQoNCmlzIHNvbWV3aGF0IHNlbGYtZGVmZWF0aW5nLCBiZWNhdXNlIGFzIHNvb24gYXMgaXQgc2Vu ZHMgNC4wNHMgaXQgKmRvZXMqIGltcGxlbWVudCBhIHNlcnZlciwgc28gdGhlIE1VU1Qgbm8gbG9u Z2VyIGFwcGxpZXMgOi0pDQoNClNvIHRoYXQgZG9lcyBub3QgcmVhbGx5IG1ha2UgYSBsb3Qgb2Yg ZGlmZmVyZW5jZSB0byBtZSBmcm9tOg0KDQo+IElmIG9uZSBzaWRlIGRvZXMgbm90IGltcGxlbWVu dCBhDQo+ICAgICAgICAgICAgQ29BUCBzZXJ2ZXIsIGFuIGVycm9yIHJlc3BvbnNlIDUuMDEgKE5v dCBJbXBsZW1lbnRlZCkgTVVTVCBiZQ0KPiAgICAgICAgICAgICByZXR1cm5lZCBmb3IgYWxsIENv QVAgcmVxdWVzdHMgZnJvbSB0aGUgb3RoZXIgc2lkZS4NCg0KQW5kIEkgYWdyZWUgdGhhdCB3aXRo b3V0IHRoZSBhbHRlcm5hdGl2ZXMgdGhpcyBpcyBtdWNoIGVhc2llciB0byBmb2xsb3cgYXMgZ3Vp ZGFuY2UuDQpNYXliZSB3ZSBjYW4gYWRkIHRoYXQgdGhlIGFsdGVybmF0aXZlIHRvIDUuMDEgaXMg dG8gaW1wbGVtZW50IGEgbW9jayBzZXJ2ZXIgdGhhdCByZXR1cm5zIDQuMDQgb3IgNC4wMi4gIFNv IGhvdyBhYm91dCBzZXBhcmF0aW5nIHRoZSBNVVNUIGZyb20gdGhlIGltcGxlbWVudGF0aW9uIGd1 aWRhbmNlOg0KDQo+IElmIG9uZSBzaWRlIGRvZXMgbm90IGltcGxlbWVudCBhDQo+ICAgICAgICAg ICAgQ29BUCBzZXJ2ZXIsIGFuIGVycm9yIHJlc3BvbnNlIE1VU1QgYmUNCj4gICAgICAgICAgICAg cmV0dXJuZWQgZm9yIGFsbCBDb0FQIHJlcXVlc3RzIGZyb20gdGhlIG90aGVyIHNpZGUuDQo+IFRo ZSBzaW1wbGVzdCB3YXkgdG8gZG8gdGhpcyBpcyB0byBhbHdheXMgcmV0dXJuIDUuMDEgKE5vdA0K PiBJbXBsZW1lbnRlZCk7IGEgbW9yZSBlbGFib3JhdGUgbW9jayBzZXJ2ZXIgY291bGQgYWxzbyBy ZXR1cm4gNC54eA0KPiByZXNwb25zZXMgc3VjaCBhcyA0LjA0IG9yIDQuMDIgd2hlcmUgYXBwcm9w cmlhdGUuDQoNCihBIG1vY2sgc2VydmVyIHRoYXQgcmV0dXJucyA0LjAyIHN0aWxsIGhhcyB0byBp bXBsZW1lbnQgdGhlIG9wdGlvbiBwYXJzaW5nIGZvciB0aGUgcmVxdWVzdHMsIGJ1dCB0aGF0IGlz IHRoZSBzYW1lIGFzIGZvciB0aGUgcmVzcG9uc2VzIGFuZCB0aGUgc2lnbmFsaW5nIG1lc3NhZ2Vz IOKAlCBtYXliZSB3ZSBzaG91bGQgZG9jdW1lbnQgdGhlIG1pbmltYWwgYmVoYXZpb3IgZm9yIGEg bW9jayBzZXJ2ZXIgd2l0aCA0LjAyIGV0Yy4sIGhlcmUgb3IgaW4gdGhlIG5ld2x5IHJlc3VycmVj dGVkIGx3aWctY29hcCBkcmFmdC4pDQoNCkdyw7zDn2UsIENhcnN0ZW4NCg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlz IG1lc3NhZ2UgbWF5IGJlIGNvbmZpZGVudGlhbCBhbmQgbGVnYWxseSBwcm90ZWN0ZWQgdW5kZXIg YXBwbGljYWJsZSBsYXcuIFRoZSBtZXNzYWdlIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFk ZHJlc3NlZShzKS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFy ZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgdXNlLCBmb3J3YXJkaW5nLCBkaXNzZW1pbmF0aW9u LCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyBtZXNzYWdlIGlzIHN0cmljdGx5IHByb2hpYml0ZWQg YW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu dCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsIGFuZCBkZXN0cm95 IGFsbCBjb3BpZXMgb2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2UuDQo= From nobody Wed Mar 15 02:59:54 2017 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 B038D129A99 for ; Wed, 15 Mar 2017 02:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySNe-s9biFfN for ; Wed, 15 Mar 2017 02:59:51 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F2F1129A9D for ; Wed, 15 Mar 2017 02:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v2F9xjmR021608 for ; Wed, 15 Mar 2017 10:59:46 +0100 (CET) Received: from [192.168.217.124] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vjnC565jmzDHfd; Wed, 15 Mar 2017 10:59:45 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 511264785.217892-ea1e8f1dd8abd4c1ed11f8487f45b5b0 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 15 Mar 2017 10:59:45 +0100 Message-Id: To: "core@ietf.org WG" X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [core] Interop event for coap over tcp/tls/websockets? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 09:59:53 -0000 In the process of producing the writeup for the submission of = coap-tcp-tls to IESG, we noticed that we never asked about = implementations. It is well known that IoTivity has one (needing to be updated to a newer = version). Who else has an implementation that we could report in the writeup? Apart from the writeup, should we stage an interop event? The first opportunity would be at the Hackathon in Chicago. But maybe we should do a more widely announced one in April. In any case, this would be open to remote participation, just like the = recent OSCOAP interop. Who wants to join? Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Mar 15 03:38:56 2017 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 CEE84129AA6 for ; Wed, 15 Mar 2017 03:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moHm5JLC_tI7 for ; Wed, 15 Mar 2017 03:38:51 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C3BE129AC4 for ; Wed, 15 Mar 2017 03:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v2FAckDp025030 for ; Wed, 15 Mar 2017 11:38:46 +0100 (CET) Received: from [192.168.217.124] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vjp462ytLzDHj0; Wed, 15 Mar 2017 11:38:46 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: <5D2CB866-3E1A-4460-B014-3B74E14FB776@tuhh.de> Date: Wed, 15 Mar 2017 11:38:45 +0100 X-Mao-Original-Outgoing-Id: 511267125.899161-e5bcaa85cd82014a2de2b1c0245c3a43 Content-Transfer-Encoding: quoted-printable Message-Id: <4AB5423F-5C74-4E6E-9D06-8F4AB033893B@tzi.org> References: <5D2CB866-3E1A-4460-B014-3B74E14FB776@tuhh.de> To: "core@ietf.org WG" X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [core] draft-becker-core-coap-sms-gprs-05 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 10:38:55 -0000 > On 28 Feb 2017, at 12:21, Koojana Kuladinithi = wrote: >=20 > Hi Hannes and all, >=20 > we have submitted the new version of the above draft.=20 >=20 > >=20 > w.r.t. the current on going discussions, we would also like to get = your feedback on the section 8 of URI scheme. Is this the way to do it = for devices with telephone numbers? At the Chicago meeting, the chairs will ask: =E2=80=94 who has read this document? =E2=80=94 who thinks this is something the WG will work on? It would be good to get some feedback to these questions from the WG = even before the meeting. So, if you have read it, please indicate your = level of support. If not, please do have a look if you care about = cellular. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Mar 15 03:40:57 2017 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 8291F129ACC for ; Wed, 15 Mar 2017 03:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73UOkNhbI2ft for ; Wed, 15 Mar 2017 03:40:54 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6641129AD0 for ; Wed, 15 Mar 2017 03:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v2FAeo08028864 for ; Wed, 15 Mar 2017 11:40:50 +0100 (CET) Received: from [192.168.217.124] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vjp6V4NfYzDHjF for ; Wed, 15 Mar 2017 11:40:50 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: <5D2CB866-3E1A-4460-B014-3B74E14FB776@tuhh.de> Date: Wed, 15 Mar 2017 11:40:50 +0100 X-Mao-Original-Outgoing-Id: 511267250.085959-d09f6a5bec1165bcd7b67c11b427cbc1 Content-Transfer-Encoding: quoted-printable Message-Id: <14E1BC58-5ADA-4E6C-A79D-D165511CD85C@tzi.org> References: <5D2CB866-3E1A-4460-B014-3B74E14FB776@tuhh.de> To: "core@ietf.org WG" X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [core] draft-becker-core-coap-sms-gprs-06 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 10:40:55 -0000 (updated subject line) > On 28 Feb 2017, at 12:21, Koojana Kuladinithi = wrote: >=20 > Hi Hannes and all, >=20 > we have submitted the new version of the above draft.=20 >=20 > >=20 > w.r.t. the current on going discussions, we would also like to get = your feedback on the section 8 of URI scheme. Is this the way to do it = for devices with telephone numbers? At the Chicago meeting, the chairs will ask: =E2=80=94 who has read this document? =E2=80=94 who thinks this is something the WG will work on? It would be good to get some feedback to these questions from the WG = even before the meeting. So, if you have read it, please indicate your = level of support. If not, please do have a look if you care about = cellular. Gr=C3=BC=C3=9Fe, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Wed Mar 15 07:14:57 2017 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 47B14131551; Wed, 15 Mar 2017 07:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 wAtwDwrcAC6B; Wed, 15 Mar 2017 07:14:54 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 D168A131525; Wed, 15 Mar 2017 07:14:50 -0700 (PDT) X-AuditID: c1b4fb30-e77ff70000007738-47-58c94c5808bb Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id 98.40.30520.85C49C85; Wed, 15 Mar 2017 15:14:48 +0100 (CET) Received: from ESESSMB107.ericsson.se ([169.254.7.76]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0319.002; Wed, 15 Mar 2017 15:14:48 +0100 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= To: "core@ietf.org WG" CC: Carsten Bormann , "draft-ietf-core-links-json@ietf.org" Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV0dMQyBkcmFmdC1pZXRmLWNvcmUtbGlua3MtanNvbg==?= Thread-Index: AQHSnZaAv7Wr39/WBUyBbK0DqEQrcg== Date: Wed, 15 Mar 2017 14:14:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_EAD5857DA8894316BA3AC5EAF6795D2Dericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZGbHdUjfC52SEwZVTlhZHptxltdj3dj2z xddzuxkdmD2WLPnJ5DFtUWYAUxSXTUpqTmZZapG+XQJXxqttr1gKpipVXP9wjqmBsU+xi5GD Q0LARGL6DKEuRi4OIYF1jBKXNv5nh3AWM0rsPbOKuYuRk4NNwFni07NGdhBbREBNonXSKzYQ m1mgUKLn928mEFtYIFCi8elNNoiaMImbnw6xgiwQEdCT2P0qDyTMIqAqcf5xL9hIXgF7iWcH N4ONZBQQk/h+ag0TxEhxiVtP5oPZEgICEkv2nGeGsEUlXj7+xwphK0ms2H6JEaI+WeLZ8T5W iJmCEidnPmGZwCg0C8moWUjKZiEpmwV0HbOApsT6XfoQJYoSU7ofskPYGhKtc+ZC2dYSax40 sCGrWcDIsYpRtDi1OCk33chIL7UoM7m4OD9PLy+1ZBMjMIYObvltsIPx5XPHQ4wCHIxKPLwF rCcihFgTy4orcw8xSnAwK4nwenmfjBDiTUmsrEotyo8vKs1JLT7EKM3BoiTOa7byfriQQHpi SWp2ampBahFMlomDU6qBMSBsEoPeI2NRky3ywp5Hyqdcncu+zP9Dx+/oiVesSx5KCoVYb7sw Vb1S+u+pE0cOHWaL/PStfOp2/sXKhydarbNsWvSnfPbOtZnWBaYXZ7uWZRa4C+QvOT55yYny GxZvVV5MnyzKV/vsWFCVzPVJD9x/iJbN3nvKbHWQe5hL+pcVp6vMLiybbqTEUpyRaKjFXFSc CAAD4KjrnQIAAA== Archived-At: Subject: [core] =?utf-8?q?_=F0=9F=94=94_WGLC_draft-ietf-core-links-json?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 14:14:56 -0000 --_000_EAD5857DA8894316BA3AC5EAF6795D2Dericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBDb1JFIFdHLA0KDQpXZSBhcmUgYW5ub3VuY2luZyBhIG9uZSB3ZWVrIFdHTEMgZm9yIHRo ZSBmb2xsb3dpbmcgZHJhZnQ6DQoNCiJSZXByZXNlbnRpbmcgQ29SRSBGb3JtYXRzIGluIEpTT04g YW5kIENCT1IiDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3JlLWxp bmtzLWpzb24tMDcNCg0KVGhlIGRvY3VtZW50IHNlZW1zIGluIGdvb2Qgc2hhcGUgYW5kIHByZXNl bnRzIGEgc3RyYWlnaHRmb3J3YXJkIHRyYW5zbGF0aW9uIGZyb20gTGluay1mb3JtYXQgdG8gSlNP TiBhbmQgQ0JPUiAocHVyZSAmIGRpYWdub3N0aWMpLg0KDQpGb3IgdGhlIHJldmlldyBwcm9jZXNz IEkgaGF2ZSBwcmVwYXJlZCB0aGUgZm9sbG93aW5nIHdyaXRldXAgaHR0cDovL2phaW1lamltLmdp dGh1Yi5pby90ZW1wL2RyYWZ0LWlldGYtY29yZS1saW5rcy1qc29uIHdpdGggY29tbWVudHMgdGhh dCBJ4oCZZCBsaWtlIHRoZSBhdXRob3JzIHRvIGNoZWNrLCBhcyB3ZWxsIGFzIGFueSBvdGhlciBj b21tZW50cyBoYXBwZW5pbmcgZHVyaW5nIHRoaXMgd2Vlay4NCkFsc28sIGl04oCZZCBiZSBnb29k IHRvIGtub3cgb2Ygb3RoZXIgcmVmZXJlbmNlIGltcGxlbWVudGF0aW9ucyBkaWZmZXJlbnQgdGhh biB0aGF0IG9uIEFwcGVuZGl4IEEgb2YgdGhpcyBkb2N1bWVudC4NCg0KQ2lhbyENCi0gLSBKYWlt ZSBKaW3DqW5leg0KDQo= --_000_EAD5857DA8894316BA3AC5EAF6795D2Dericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <44481D8380A6554C9DBB964A00239071@ericsson.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KRGVhciBDb1JFIFdHLA0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+V2UgYXJlIGFubm91 bmNpbmcgYSBvbmUgd2VlayBXR0xDIGZvciB0aGUgZm9sbG93aW5nIGRyYWZ0OjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2I+PC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxpIGNsYXNzPSIiPiZxdW90O1JlcHJlc2VudGluZyBDb1JFIEZvcm1hdHMgaW4gSlNP TiBhbmQgQ0JPUiZxdW90OzwvaT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGkgY2xhc3M9IiI+PGEg aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS1saW5rcy1q c29uLTA3IiBjbGFzcz0iIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1j b3JlLWxpbmtzLWpzb24tMDc8L2E+Jm5ic3A7PC9pPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhlIGRvY3VtZW50IHNlZW1zIGluIGdv b2Qgc2hhcGUgYW5kIHByZXNlbnRzIGEgc3RyYWlnaHRmb3J3YXJkIHRyYW5zbGF0aW9uIGZyb20g TGluay1mb3JtYXQgdG8gSlNPTiBhbmQgQ0JPUiAocHVyZSAmYW1wOyBkaWFnbm9zdGljKS4mbmJz cDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPkZvciB0aGUgcmV2aWV3IHByb2Nlc3MgSSBoYXZlIHByZXBhcmVkIHRoZSBmb2xsb3dpbmcg d3JpdGV1cCZuYnNwOzxhIGhyZWY9Imh0dHA6Ly9qYWltZWppbS5naXRodWIuaW8vdGVtcC9kcmFm dC1pZXRmLWNvcmUtbGlua3MtanNvbiIgY2xhc3M9IiI+aHR0cDovL2phaW1lamltLmdpdGh1Yi5p by90ZW1wL2RyYWZ0LWlldGYtY29yZS1saW5rcy1qc29uPC9hPiZuYnNwO3dpdGggY29tbWVudHMg dGhhdCBJ4oCZZCBsaWtlIHRoZSBhdXRob3JzIHRvDQogY2hlY2ssIGFzIHdlbGwgYXMgYW55IG90 aGVyIGNvbW1lbnRzIGhhcHBlbmluZyBkdXJpbmcgdGhpcyB3ZWVrLiZuYnNwOzwvZGl2Pg0KPGRp diBjbGFzcz0iIj5BbHNvLCBpdOKAmWQgYmUgZ29vZCB0byBrbm93IG9mIG90aGVyIDxiIGNsYXNz PSIiPnJlZmVyZW5jZSBpbXBsZW1lbnRhdGlvbnM8L2I+IGRpZmZlcmVudCB0aGFuIHRoYXQgb24g QXBwZW5kaXggQSBvZiB0aGlzIGRvY3VtZW50LiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Q2lhbyE8YnIgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRv d3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Vi a2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxl PSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBh dXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3Jk OyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hp dGUtc3BhY2U7IiBjbGFzcz0iIj4NCi0gLSBKYWltZSBKaW3DqW5lejwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_EAD5857DA8894316BA3AC5EAF6795D2Dericssoncom_-- From nobody Wed Mar 15 08:27:20 2017 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 CE0B7131680; Wed, 15 Mar 2017 08:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTEnTsXA9pcy; Wed, 15 Mar 2017 08:27:17 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1087813167A; Wed, 15 Mar 2017 08:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v2FFREXp012548; Wed, 15 Mar 2017 16:27:14 +0100 (CET) Received: from [192.168.217.124] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vjwSy0xMjzDHvY; Wed, 15 Mar 2017 16:27:14 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: Date: Wed, 15 Mar 2017 16:27:13 +0100 Cc: "draft-ietf-core-links-json@ietf.org" X-Mao-Original-Outgoing-Id: 511284433.42599-1282f2da9619b673e55c3c7e09bd735f Content-Transfer-Encoding: quoted-printable Message-Id: <4C173783-8CDC-48C8-9F6D-3843E0928E4D@tzi.org> References: To: "core@ietf.org WG" X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_draft-ietf-core-links-json?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 15:27:19 -0000 On 15 Mar 2017, at 15:14, Jaime Jim=C3=A9nez = wrote: >=20 > one week WGLC (Clarification: This is a second WGLC. There was one in July last year; = there was a lot of discussion since around resource-directory, data hubs = etc., but in the end not too much changed in *this* document. So this = should be a quick review to do.) Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Mar 15 12:50:37 2017 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 AF5B81317D9 for ; Wed, 15 Mar 2017 12:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hb9SahvPEUH for ; Wed, 15 Mar 2017 12:50:35 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1FDC131801 for ; Wed, 15 Mar 2017 12:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v2FJoLZ9004293 for ; Wed, 15 Mar 2017 20:50:21 +0100 (CET) Received: from [192.168.217.124] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vk2JY0cLGzDJ11; Wed, 15 Mar 2017 20:50:21 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 511300220.342384-f2fda9c8e199cb857204d1ee55584584 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 15 Mar 2017 20:50:20 +0100 Message-Id: <7980F62B-A1B5-45C2-871B-B428BEF339BC@tzi.org> To: "core@ietf.org WG" X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [core] CoRE@IETF98 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 19:50:37 -0000 We have uploaded a 0.1 draft of the CoRE agenda for Chicago at: https://datatracker.ietf.org/meeting/98/agenda/core/ As usual, this is based on the documents we have on the plate. If you have a document, please check the above agenda that you have = adequate time at this meeting to drive your work forward. Please tell = us who will be managing the slot. (And start making slides=E2=80=A6 We=E2=80=99ll want them on Saturday, = March 25.) Anything else that should be on the agenda? (Note that we are a bit constrained with allocating time, as we asked = for 180 minutes total only for CoRE. So there is no flextime this time, = just a little bit of buffer on Friday for spillover from Tuesday.) Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Mar 15 13:19:09 2017 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 BC5B713181A; Wed, 15 Mar 2017 13:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-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=microsoft.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 uWZ9kB7A_WqP; Wed, 15 Mar 2017 13:19:05 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0123.outbound.protection.outlook.com [104.47.34.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFC30131815; Wed, 15 Mar 2017 13:19:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gYzTgjegaXEacj3uny9v+azSQw0v3npSU0OiYLeqPa8=; b=byH8GNx3iR3Lh1FGWpO7Eq4I9zPlV3Q6TClHAGhUOzb3V7yu/zSmNwiSP3dJZ3P6ZRMLXNULokIyFVSpV2990TpGB0FAAc0YXkFFeWYWR3sLxPGYJk2/PjdVWEfmcPBCL1VPARt+lu2naWI5cKDRIOeFu5uuqF4jdNyWbyY7aiw= Received: from DM2PR21MB0107.namprd21.prod.outlook.com (10.161.141.143) by DM2PR21MB0105.namprd21.prod.outlook.com (10.161.141.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.0; Wed, 15 Mar 2017 20:19:03 +0000 Received: from DM2PR21MB0107.namprd21.prod.outlook.com ([10.161.141.143]) by DM2PR21MB0107.namprd21.prod.outlook.com ([10.161.141.143]) with mapi id 15.01.0991.003; Wed, 15 Mar 2017 20:19:03 +0000 From: Brian Raymor To: "Dijk, Esko" , Carsten Bormann CC: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= , "draft-ietf-core-coap-tcp-tls@ietf.org" , "core@ietf.org WG" Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV0dMQyBkcmFmdC1pZXRmLWNvcmUtY29hcC10Y3AtdGxz?= Thread-Index: AQHSh4Voyork67XijE6/jnBfSsrf9qGS9cmAgAE6SICAAAR+gIAAA7gAgAJLI4A= Date: Wed, 15 Mar 2017 20:19:03 +0000 Message-ID: References: <938FB795-A352-448A-B380-ABBFA2F04DE9@ericsson.com> <8e2b2a0a00bb404d930adf0ae9ce08ad@AM3PR90MB0097.MGDPHG.emi.philips.com> <3C026127-6EDD-473D-B3CC-92AD7C0F6172@tzi.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: philips.com; dkim=none (message not signed) header.d=none;philips.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [174.61.159.182] x-microsoft-exchange-diagnostics: 1; DM2PR21MB0105; 7:pvbPCUcJsvDhWU7LOgsMxMJCSDpOxnT9me0ujzk15NkWPLQ4JWb5RTkf/jDH54zSDE1GylfAzofZQ8I3YprO53tfMpzRX8Rmcln/MzAiEkcm71fB/Q/QFT5PkWklNISgcUffq8k5T4kRlb5CNF4ohXw0juMMQytsdqCdUPm3MdmZXOdEE+7SBUZ68Ge4g2dyavS8OhqKQpNfbyF+oULlWHWGyaniAQnpXdIlV9U5kVqrvrTKR1Z3Fdff5mp8I/fHfpYhD9qJPx0dHcsJr1SXNGRKXRFmcCCoMf20KPGaHfOmtEBHMEYY1wrG1SKYMJUsWqgHMA4tWy4HUomCptxZPYXEuNbs+Bh+qeGQg2YL7yQ= x-ms-office365-filtering-correlation-id: f291cce4-781b-4fe9-1ce4-08d46be0862e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254024)(48565401081); SRVR:DM2PR21MB0105; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(158342451672863)(166708455590820)(260087099026482); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123560025)(20161123558025)(20161123564025)(20161123555025)(6072148); SRVR:DM2PR21MB0105; BCL:0; PCL:0; RULEID:; SRVR:DM2PR21MB0105; x-forefront-prvs: 02475B2A01 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39450400003)(39860400002)(39410400002)(377454003)(85714005)(374574003)(13464003)(55904004)(50986999)(76176999)(54356999)(53546007)(4326008)(86362001)(229383001)(54906002)(53936002)(229853002)(7736002)(10090500001)(6506006)(55016002)(6306002)(9686003)(99286003)(33656002)(3280700002)(6116002)(3846002)(77096006)(2900100001)(230783001)(93886004)(25786008)(66066001)(122556002)(5005710100001)(10290500002)(74316002)(7696004)(81166006)(8936002)(3660700001)(8990500004)(2906002)(5660300001)(305945005)(38730400002)(6246003)(6436002)(102836003)(189998001)(2950100002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR21MB0105; H:DM2PR21MB0107.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2017 20:19:03.2535 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR21MB0105 Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_draft-ietf-core-coap-tcp-tls?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 20:19:08 -0000 Q2FwdHVyZWQgQ2Fyc3RlbidzIHVwZGF0ZSBpbiBodHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9j b2FwLXRjcC10bHMvcHVsbC8xMjMNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogRGlqaywgRXNrbyBbbWFpbHRvOmVza28uZGlqa0BwaGlsaXBzLmNvbV0gDQpTZW50OiBUdWVz ZGF5LCBNYXJjaCAxNCwgMjAxNyAyOjE2IEFNDQpUbzogQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6 aS5vcmc+DQpDYzogSmFpbWUgSmltw6luZXogPGphaW1lLmppbWVuZXpAZXJpY3Nzb24uY29tPjsg ZHJhZnQtaWV0Zi1jb3JlLWNvYXAtdGNwLXRsc0BpZXRmLm9yZzsgY29yZUBpZXRmLm9yZyBXRyA8 Y29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbY29yZV0g8J+UlCBXR0xDIGRyYWZ0LWlldGYt Y29yZS1jb2FwLXRjcC10bHMNCg0KSGVsbG8gQ2Fyc3RlbiwNCg0KYWdyZWUgLSB0aGlzIHNlcGFy YXRpb24gbWFrZXMgaXQgbW9yZSBjbGVhci4gQW5kIHRoZSBNVVNUIHJlcXVpcmVtZW50IGlzIGFs c28gc3BlY2lmaWMgbm93Lg0KDQpFc2tvDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBDYXJzdGVuIEJvcm1hbm4gW21haWx0bzpjYWJvQHR6aS5vcmddDQpTZW50OiBUdWVzZGF5 LCBNYXJjaCAxNCwgMjAxNyAxMDowMw0KVG86IERpamssIEVza28gPGVza28uZGlqa0BwaGlsaXBz LmNvbT4NCkNjOiBKYWltZSBKaW3DqW5leiA8amFpbWUuamltZW5lekBlcmljc3Nvbi5jb20+OyBk cmFmdC1pZXRmLWNvcmUtY29hcC10Y3AtdGxzQGlldGYub3JnOyBjb3JlQGlldGYub3JnIFdHIDxj b3JlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtjb3JlXSDwn5SUIFdHTEMgZHJhZnQtaWV0Zi1j b3JlLWNvYXAtdGNwLXRscw0KDQpIaSBFc2tvLA0KDQp3ZSBkaWRu4oCZdCBxdWl0ZSBmZWVsIHRo YXQgd2Ugc2hvdWxkIGJlIHJlc3RyaWN0aW5nIHRoZSBiZWhhdmlvciB0b28gbXVjaC4NCg0KWW91 IGFyZSByaWdodCB0aGF0DQoNCj4gSWYgb25lIHNpZGUgZG9lcyBub3QgaW1wbGVtZW50IGENCj4g ICAgICAgICAgICBDb0FQIHNlcnZlciwgYW4gYXBwcm9wcmlhdGUgZXJyb3IgcmVzcG9uc2Ugc3Vj aCBhcyA0LjA0IChOb3QgRm91bmQpDQo+ICAgICAgICAgICAgb3IgNS4wMSAoTm90IEltcGxlbWVu dGVkKSBNVVNUIGJlIHJldHVybmVkIGZvciBhbGwgQ29BUCByZXF1ZXN0cyBmcm9tDQo+ICAgICAg ICAgICAgdGhlIG90aGVyIHNpZGUuDQoNCmlzIHNvbWV3aGF0IHNlbGYtZGVmZWF0aW5nLCBiZWNh dXNlIGFzIHNvb24gYXMgaXQgc2VuZHMgNC4wNHMgaXQgKmRvZXMqIGltcGxlbWVudCBhIHNlcnZl ciwgc28gdGhlIE1VU1Qgbm8gbG9uZ2VyIGFwcGxpZXMgOi0pDQoNClNvIHRoYXQgZG9lcyBub3Qg cmVhbGx5IG1ha2UgYSBsb3Qgb2YgZGlmZmVyZW5jZSB0byBtZSBmcm9tOg0KDQo+IElmIG9uZSBz aWRlIGRvZXMgbm90IGltcGxlbWVudCBhDQo+ICAgICAgICAgICAgQ29BUCBzZXJ2ZXIsIGFuIGVy cm9yIHJlc3BvbnNlIDUuMDEgKE5vdCBJbXBsZW1lbnRlZCkgTVVTVCBiZQ0KPiAgICAgICAgICAg ICByZXR1cm5lZCBmb3IgYWxsIENvQVAgcmVxdWVzdHMgZnJvbSB0aGUgb3RoZXIgc2lkZS4NCg0K QW5kIEkgYWdyZWUgdGhhdCB3aXRob3V0IHRoZSBhbHRlcm5hdGl2ZXMgdGhpcyBpcyBtdWNoIGVh c2llciB0byBmb2xsb3cgYXMgZ3VpZGFuY2UuDQpNYXliZSB3ZSBjYW4gYWRkIHRoYXQgdGhlIGFs dGVybmF0aXZlIHRvIDUuMDEgaXMgdG8gaW1wbGVtZW50IGEgbW9jayBzZXJ2ZXIgdGhhdCByZXR1 cm5zIDQuMDQgb3IgNC4wMi4gIFNvIGhvdyBhYm91dCBzZXBhcmF0aW5nIHRoZSBNVVNUIGZyb20g dGhlIGltcGxlbWVudGF0aW9uIGd1aWRhbmNlOg0KDQo+IElmIG9uZSBzaWRlIGRvZXMgbm90IGlt cGxlbWVudCBhDQo+ICAgICAgICAgICAgQ29BUCBzZXJ2ZXIsIGFuIGVycm9yIHJlc3BvbnNlIE1V U1QgYmUNCj4gICAgICAgICAgICAgcmV0dXJuZWQgZm9yIGFsbCBDb0FQIHJlcXVlc3RzIGZyb20g dGhlIG90aGVyIHNpZGUuDQo+IFRoZSBzaW1wbGVzdCB3YXkgdG8gZG8gdGhpcyBpcyB0byBhbHdh eXMgcmV0dXJuIDUuMDEgKE5vdCANCj4gSW1wbGVtZW50ZWQpOyBhIG1vcmUgZWxhYm9yYXRlIG1v Y2sgc2VydmVyIGNvdWxkIGFsc28gcmV0dXJuIDQueHggDQo+IHJlc3BvbnNlcyBzdWNoIGFzIDQu MDQgb3IgNC4wMiB3aGVyZSBhcHByb3ByaWF0ZS4NCg0KKEEgbW9jayBzZXJ2ZXIgdGhhdCByZXR1 cm5zIDQuMDIgc3RpbGwgaGFzIHRvIGltcGxlbWVudCB0aGUgb3B0aW9uIHBhcnNpbmcgZm9yIHRo ZSByZXF1ZXN0cywgYnV0IHRoYXQgaXMgdGhlIHNhbWUgYXMgZm9yIHRoZSByZXNwb25zZXMgYW5k IHRoZSBzaWduYWxpbmcgbWVzc2FnZXMg4oCUIG1heWJlIHdlIHNob3VsZCBkb2N1bWVudCB0aGUg bWluaW1hbCBiZWhhdmlvciBmb3IgYSBtb2NrIHNlcnZlciB3aXRoIDQuMDIgZXRjLiwgaGVyZSBv ciBpbiB0aGUgbmV3bHkgcmVzdXJyZWN0ZWQgbHdpZy1jb2FwIGRyYWZ0LikNCg0KR3LDvMOfZSwg Q2Fyc3Rlbg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUaGUgaW5mb3Jt YXRpb24gY29udGFpbmVkIGluIHRoaXMgbWVzc2FnZSBtYXkgYmUgY29uZmlkZW50aWFsIGFuZCBs ZWdhbGx5IHByb3RlY3RlZCB1bmRlciBhcHBsaWNhYmxlIGxhdy4gVGhlIG1lc3NhZ2UgaXMgaW50 ZW5kZWQgc29sZWx5IGZvciB0aGUgYWRkcmVzc2VlKHMpLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB1c2UsIGZv cndhcmRpbmcsIGRpc3NlbWluYXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIG1lc3NhZ2Ug aXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGJ5IHJl dHVybiBlLW1haWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0aGUgb3JpZ2luYWwgbWVzc2Fn ZS4NCg== From nobody Wed Mar 15 16:14:07 2017 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 1997F129C47 for ; Wed, 15 Mar 2017 16:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.332 X-Spam-Level: X-Spam-Status: No, score=-0.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, 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 lrbKc4e5MPmr for ; Wed, 15 Mar 2017 16:14:04 -0700 (PDT) Received: from msh04.myshophosting.com (msh04.myshophosting.com [101.0.86.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 8C07A129C4C for ; Wed, 15 Mar 2017 16:14:03 -0700 (PDT) Received: from ppp118-209-171-106.lns20.mel8.internode.on.net ([118.209.171.106]:50623 helo=[192.168.1.22]) by msh04.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1coI7D-002YD8-FY; Thu, 16 Mar 2017 10:13:59 +1100 To: Carsten Bormann , "core@ietf.org WG" References: <7980F62B-A1B5-45C2-871B-B428BEF339BC@tzi.org> From: Christian Groves Message-ID: Date: Thu, 16 Mar 2017 10:13:53 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <7980F62B-A1B5-45C2-871B-B428BEF339BC@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh04.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gmail.com X-Get-Message-Sender-Via: msh04.myshophosting.com: authenticated_id: christian@kunstmade.com.au X-Authenticated-Sender: msh04.myshophosting.com: christian@kunstmade.com.au X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [core] CoRE@IETF98 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 23:14:06 -0000 Hello Carsten, Given that draft-ietf-core-interfaces, draft-ietf-core-dynlink, draft-groves-core-obsattr and draft-groves-core-bas are all related it may be more efficient to present them as a block? I was also going to propose to discuss about the renaming of the "lt" parameter so I don't know if we should do that in conjunction with draft-ietf-core-resource-directory? It might take some time. There's also the proposal on the list regarding updating RD to make the IANA registration of query attributes more generic. With respect to draft-groves-core-rfc6690up I haven't done anything more on this so if you need more time it would be OK to drop it. However I'm happy to discuss it with people in Chicago. Yes draft-groves-coap-webrtcdc is not dead. My understanding from Seoul was that we'd hold off on it until draft-ietf-core-coap-tcp-tls was out of the way. Regards, Christian On 16/03/2017 6:50 AM, Carsten Bormann wrote: > We have uploaded a 0.1 draft of the CoRE agenda for Chicago at: > > https://datatracker.ietf.org/meeting/98/agenda/core/ > > As usual, this is based on the documents we have on the plate. > > If you have a document, please check the above agenda that you have adequate time at this meeting to drive your work forward. Please tell us who will be managing the slot. > (And start making slides… We’ll want them on Saturday, March 25.) > > Anything else that should be on the agenda? > > (Note that we are a bit constrained with allocating time, as we asked for 180 minutes total only for CoRE. So there is no flextime this time, just a little bit of buffer on Friday for spillover from Tuesday.) > > Grüße, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Wed Mar 15 23:17:35 2017 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 6A01A1243FE for ; Wed, 15 Mar 2017 23:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWm4sfJSGsKX for ; Wed, 15 Mar 2017 23:17:31 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEA891243F6 for ; Wed, 15 Mar 2017 23:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v2G6HLVt003751; Thu, 16 Mar 2017 07:17:21 +0100 (CET) Received: from [192.168.217.124] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vkJD05XVkzDJ6f; Thu, 16 Mar 2017 07:17:20 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: <20170222191348.6C64CB80A6F@rfc-editor.org> Date: Thu, 16 Mar 2017 07:17:19 +0100 Cc: Zach Shelby , Klaus Hartke , ben@nostrum.com, Alissa Cooper , Alexey Melnikov , =?utf-8?Q?Jaime_Jim=C3=A9nez?= , "core@ietf.org WG" X-Mao-Original-Outgoing-Id: 511337839.191878-24e2c23ac69a1784f430182eaa372a0b Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170222191348.6C64CB80A6F@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [core] [Technical Errata Reported] RFC7252 (4946) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 06:17:33 -0000 Adding a little background to this errata (extracted from = https://github.com/core-wg/coap-tcp-tls/issues/124 =E2=80=94 = coap-tcp-tls-07 has the same issue): Fragment identifiers are not used in a transfer protocol; their use is a = local matter on the client side. The mistake we made in RFC 7252 is = providing ABNF that doesn't show fragment identifiers at all in the URI = syntax. While CoAP as a protocol does not care about them, they are = intended to be allowed in CoAP URIs so they can indeed be used on the = client side. The note in Section 5.10.1 of RFC 7252 mentions this, but = the ABNF does not reflect that: =C2=BBNote: Fragments ([RFC3986], Section 3.5) are not part of the = request URI and thus will not be transmitted in a CoAP request.=C2=AB Does it matter? The meaning of fragment identifiers is defined by the = media type. So far, there has been little use of fragment identifiers in = the media types being used with CoAP. Now, SenML actually does go ahead = and defines a meaning for them, and other media types in the future = might as well. So it would be good if the ABNF in the CoAP standards did = not give the impression fragment identifiers cannot be used at all with = CoAP URIs. Gr=C3=BC=C3=9Fe, Carsten > On 22 Feb 2017, at 20:13, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC7252, > "The Constrained Application Protocol (CoAP)". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D7252&eid=3D4946 >=20 > -------------------------------------- > Type: Technical > Reported by: Klaus Hartke >=20 > Section: 6.1 >=20 > Original Text > ------------- > coap-URI =3D "coap:" "//" host [ ":" port ] path-abempty [ "?" query ] >=20 > Corrected Text > -------------- > coap-URI =3D "coap:" "//" host [ ":" port ] path-abempty [ "?" query ] > [ "#" fragment ] >=20 > Notes > ----- > The optional fragment component allows for indirect identification of = a secondary resource, as defined in Section 3.5 of RFC 3986. The = fragment identifier is separated from the rest of the URI prior to a = dereference; fragment identifiers are processed client-side and are not = included in CoAP requests. The original text shows the syntax of coap:// = URIs _after_ separating the fragment identifier, which leaves ambiguity = as to whether fragment identifiers are supported or not. The corrected = text shows the syntax of CoAP URIs _before_ separating the fragment = identifier, which makes clear that fragment identifiers are supported. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC7252 (draft-ietf-core-coap-18) > -------------------------------------- > Title : The Constrained Application Protocol (CoAP) > Publication Date : June 2014 > Author(s) : Z. Shelby, K. Hartke, C. Bormann > Category : PROPOSED STANDARD > Source : Constrained RESTful Environments APP > Area : Applications > Stream : IETF > Verifying Party : IESG >=20 From nobody Thu Mar 16 01:03:53 2017 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 6ECEA126FB3 for ; Thu, 16 Mar 2017 01:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHmiykyoh2lO for ; Thu, 16 Mar 2017 01:03:48 -0700 (PDT) Received: from lb2-smtp-cloud6.xs4all.net (lb2-smtp-cloud6.xs4all.net [194.109.24.28]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D44A1250B8 for ; Thu, 16 Mar 2017 01:03:48 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.199]) by smtp-cloud6.xs4all.net with ESMTP id wY3m1u00L4Hiz6i01Y3mYq; Thu, 16 Mar 2017 09:03:46 +0100 Received: from 2001:983:a264:1:80c6:88cd:9ce7:ee22 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 16 Mar 2017 09:03:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 16 Mar 2017 09:03:46 +0100 From: peter van der Stok To: Carsten Bormann Cc: "core@ietf.org WG" Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <7980F62B-A1B5-45C2-871B-B428BEF339BC@tzi.org> References: <7980F62B-A1B5-45C2-871B-B428BEF339BC@tzi.org> Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Subject: Re: [core] CoRE@IETF98 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 08:03:51 -0000 Hi Carsten, I will be happy to present ietf-comi-00 draft; It needs some discussion on the content-format for the PATCH and FETCH methods. I like to hear the opinion of the WG For the hartke-core-pending draft I should like a 2 min elevator pitch at the start of the Friday meeting, followed by a 2 minute request for interest. Greetings, peter Carsten Bormann schreef op 2017-03-15 20:50: > We have uploaded a 0.1 draft of the CoRE agenda for Chicago at: > > https://datatracker.ietf.org/meeting/98/agenda/core/ > > As usual, this is based on the documents we have on the plate. > > If you have a document, please check the above agenda that you have > adequate time at this meeting to drive your work forward. Please tell > us who will be managing the slot. > (And start making slides… We’ll want them on Saturday, March 25.) > > Anything else that should be on the agenda? > > (Note that we are a bit constrained with allocating time, as we asked > for 180 minutes total only for CoRE. So there is no flextime this > time, just a little bit of buffer on Friday for spillover from > Tuesday.) > > Grüße, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Thu Mar 16 02:22:38 2017 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 B073B12704B for ; Thu, 16 Mar 2017 02:22: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] 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 Bf3iM77RnsSV for ; Thu, 16 Mar 2017 02:22:35 -0700 (PDT) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B816126DED for ; Thu, 16 Mar 2017 02:22:34 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 20C06468DF; Thu, 16 Mar 2017 10:22:32 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id C9C6B7A; Thu, 16 Mar 2017 10:22:30 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 6F60410D; Thu, 16 Mar 2017 10:22:30 +0100 (CET) Received: (nullmailer pid 11394 invoked by uid 1000); Thu, 16 Mar 2017 09:22:29 -0000 Date: Thu, 16 Mar 2017 10:22:29 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Jim Schaad Cc: =?iso-8859-1?Q?'G=F6ran?= Selander' , 'Francesca Palombini' , core@ietf.org Message-ID: <20170316092229.ezsejhhenjckrl76@hephaistos.amsuess.com> References: <20170303173229.uj7av3xia4prxku3@hephaistos.amsuess.com> <20170306150622.mxhuggsfaojso4xv@hephaistos.amsuess.com> <20170312130458.qwq5vykp3iil4kum@hephaistos.amsuess.com> <0b7601d29bca$2d3087e0$879197a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="j5o4gon2b25otvsu" Content-Disposition: inline In-Reply-To: <0b7601d29bca$2d3087e0$879197a0$@augustcellars.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [core] pre-draft: Request-Tag X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 09:22:38 -0000 --j5o4gon2b25otvsu Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Jim, On Mon, Mar 13, 2017 at 12:19:35AM -0700, Jim Schaad wrote: > 2. There is a different endpoint problem which needs to be solved for > OSCOAP because of the removal of all URI-Path elements from the query whi= ch > means that endpoints collapse in a way that they do not with DTLS only > solutions. For the purpose of setting the goals on what we protect in blockwise, I'd set aside the issue of outer blockwise requests hitting the same endpoint. My original proposal for a solution happens to cover that too, but first I'd know what we're trying so solve. > 1. I still don't understand what exactly your problem is, but I think th= at > if one expects things to be changed together, then that would be an > application problem rather than a CoAP problem. I think that I agree with > Olaf and Matthias on that point. My problem (or actually, our problem, as this developed from the protection of the complete message in a blockwise transfer you asked about) is that when a user sends inner-blockwise requests, neither can the server nor the client be sure that they belong to the same request. If that's something where we decide not to offer protection, that's fine with me (but then blockwise needs stronger cautionary wording in OSCOAP), but I opine that we can provide that. (The draft I've proposed might easily not even be the best way to go about that; first, we should set a goal). > 3. I think that there needs to be a solution for dealing with ensuring th= at > the correct content has been acquired after doing a series of bitwise > transactions. This could be done either at the CoAP layer or at the > application layer. Both are probably equally doable. The only thing that > might needs to be done in CoAP is the signaling of how to get the secure > content checking structure. > > 4. My understanding of REST is that the idea of dividing a content across > multiple messages would not occur to them. [...] Protection of full messags on application level is completely doable without protected blockwise. (G=F6ran suggested checksum resources, it'd just depend on what exactly the application is). Then again, so would have been blockwising in the first place; we could have (instead of the blockwise we have now) defined a more application-level, more RESTful blockwise [2], but what we have is a little less RESTful (by referring to "further blocks from the same endpoint"), but much slimmer and more efficient. I think we can protect these slim blocks without making things too complicated. As for me not having made my problem statement fully clear, please allow me to try again, and to serve an enhanced example: Problem statement =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D An application can not gain the same security it has about the integrity of its messages and the correlation between request and response that it gets from OSCOAP in non-blocked or outer-blockwise mode in inner-blockwise mode. In particular, the integrity of the body of a Block1 request is not guaranteed. Example =3D=3D=3D=3D=3D=3D=3D My previous example[1] only showed how the server can be tricked into processing a wrongly assembled request and act upon it; this new example creates a request/response mismatch and gives the client a wrong answer: Client: POST /judge, payload "Homeless stole apples. Wh"... Evil proxy intercepts and stores the request. Client times out. Client: POST /judge, payload "Hitman killed someone. Wh"... Evil proxy passes on the request Server: 2.31 continue (Note that were this request to pass, it would respond "Hang him.") Evil proxy, before passing on the response, inserts: POST /judge, payload "Homeless stole apples. Wh"... Server: 2.31 continue (by the rules of blockwise, the previous transaction is aborted) Evil proxy swallows the new response, and sends back the first 2.31. Evil proxy now innocently passes on what ensues: Client: POST /judge, payload ..."at shall we do with him?" Server: 2.05 "Set him free." Client sets the hitman free. Best regards, and see you later Christian [1]: http://www.ietf.org/mail-archive/web/core/current/msg08412.html [2]: along the lines of POSTing to a /block resource, retrieving a transaction Location, PUTting the request blocks in there, GETting response blocks out of it and DELETEing it in the end) --=20 The detailed semantics of CoAP methods are "almost, but not entirely unlike" [HHGTTG] those of HTTP methods. [HHGTTG]: Adams, D., "The Hitchhiker's Guide to the Galaxy", October 1979. -- Shelby, et al., Internet-Draft Constrained Application Protocol (CoAP) --j5o4gon2b25otvsu Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAljKWU8ACgkQOY0REtOk veEeGhAAvimae2wovjZ7bQiI6TbEgw/e+7T0Q/k1Zmhqen7zO9JW2Dp87ZaXk+Yp 8AEwyXaysClulFTPyu/DqWMzLVYjIOwJ8NlLq+KOvy5uLtVTO+SO4SfgOt99bIfb h0y1jzMKYcbLKnUTto6tyBemAGVbNGYBp5B18FfNu48sjBN/PV1JlXYfmfkyo9+P Eff0Hqylws3XmoJP/YwMsGmNIyVGBsh3NyueoKQ7xXYkHUw02UWlNQFGzHSdE8wL 3qw4C5B0PMZd82hv4jc7bpJK659CTa6oa2VQ569zdx4/exQOMsAfVLyuShw/xsGM Ofen6HlCD9qYvnW3Kw9DHgKp0dkzm23Ab42ZWzm8Yxvf3KUzgZDCC85gcQrIIcDZ wJn0zhloV25c5KC0jcbCQ1KN7qET9z4OS1OD4HdwihYBTkU2v2ErVM2FddtvgtKt U13j4GibMyBRPzbHHPE+20jowE8HEtyB/laVNxMLYmbPBVntlRhRN8XOmDJCRdth UG3qyW99zo5cGwgs0IB+92NQvFOcmaAoBjrI3HfHuxj4H3WQRgHsit0RPQ08z4S7 Bd7+voqUyN64sd1bgFJO89vvwrsfAoZXjS8XKLNQ4MECYnFdRcYQSydtSwQxFYG5 1I2eYUWtJncIuTnSSJFxkBSdrOlcCZjci8TwsbstTKld/vdpmjY= =3CGJ -----END PGP SIGNATURE----- --j5o4gon2b25otvsu-- From nobody Thu Mar 16 04:47:49 2017 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 8E2A3129413 for ; Thu, 16 Mar 2017 04:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eG0l6tTMjVNu for ; Thu, 16 Mar 2017 04:47:46 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DFC2129420 for ; Thu, 16 Mar 2017 04:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v2GBlNrf016707; Thu, 16 Mar 2017 12:47:23 +0100 (CET) Received: from [10.0.1.13] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vkRXq461SzDJJS; Thu, 16 Mar 2017 12:47:23 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: <0b7601d29bca$2d3087e0$879197a0$@augustcellars.com> Date: Thu, 16 Mar 2017 12:47:22 +0100 Cc: =?utf-8?Q?Christian_Ams=C3=BCss?= , =?utf-8?Q?G=C3=B6ran_Selander?= , Francesca Palombini , core@ietf.org X-Mao-Original-Outgoing-Id: 511357642.566685-be339abcce7bd47645ab928493cceab0 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170303173229.uj7av3xia4prxku3@hephaistos.amsuess.com> <20170306150622.mxhuggsfaojso4xv@hephaistos.amsuess.com> <20170312130458.qwq5vykp3iil4kum@hephaistos.amsuess.com> <0b7601d29bca$2d3087e0$879197a0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [core] pre-draft: Request-Tag X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 11:47:48 -0000 On 13 Mar 2017, at 08:19, Jim Schaad wrote: >=20 >=20 > 4. My understanding of REST is that the idea of dividing a content = across > multiple messages would not occur to them. =20 It is orthogonal to REST. > One can obtain the entire HTTP > content over a TLS/DTLS connection in a "single" transaction and thus = the > entire message content would be adequately protected. =20 But that=E2=80=99s not how it works. The message is broken up into = packets and then reassembled on the receiver by TCP; independent of = this, swathes of content are made into TLS records, each of which is = properly protected by the transport layer security. All this cannot be ignored when it is necessary to discuss the security = properties of content while it is transferred. For instance, TCP = connections can easily broken by an attacker, so the receiver of partial = content (e.g., for streaming) needs to be able to resume the transfer if = that attack isn=E2=80=99t supposed to be a fatal threat. Please also be aware of application layer protocols such as HTTP = streaming that do the equivalent of block-wise on top of REST, for many = of the same reasons. > The fact that CoAP > breaks up the entire message content into multiple messages means that = this > feature has been lost. I think that is probably too bad. It never was a feature, just a (rather leaky) abstraction that allowed = us to ignore more if the inner workings. The difference between CoAP and HTTP is that HTTP creates state in the = form of the TCP connection (and the TLS connection bound to that), so it = can bind all of the messages that build one body together (sequence = preservation also helps with that). We have a weak form of that binding = in CoAP for Block2 (ETag), but not for Block1, where we assumed only = having one transaction in flight for each resource would be good enough. = Now that all the secure CoAP transactions of one endpoint are funneled = through what looks like one resource at the surface, we may have to go = beyond that. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Mar 16 08:05:37 2017 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 C1E1E129566 for ; Thu, 16 Mar 2017 08:05:32 -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] 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 PPZVgY6DK1Ky for ; Thu, 16 Mar 2017 08:05:30 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89118129577 for ; Thu, 16 Mar 2017 08:05:04 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id B0902468DF for ; Thu, 16 Mar 2017 16:05:02 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id AA05C7A for ; Thu, 16 Mar 2017 16:05:01 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 81F323DB for ; Thu, 16 Mar 2017 16:05:01 +0100 (CET) Received: (nullmailer pid 18675 invoked by uid 1000); Thu, 16 Mar 2017 15:05:00 -0000 Date: Thu, 16 Mar 2017 16:05:00 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: "core@ietf.org" Message-ID: <20170316150500.cgmnqqgavothnze6@hephaistos.amsuess.com> References: <20170303173229.uj7av3xia4prxku3@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="zbvpnotubemwasdn" Content-Disposition: inline In-Reply-To: <20170303173229.uj7av3xia4prxku3@hephaistos.amsuess.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [core] pre-draft: Request-Tag X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 15:05:33 -0000 --zbvpnotubemwasdn Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello working group, to sum up things after a pleasent call with Jim, Francesca and G=F6ran (thanks to all involved): I'll update the draft with an enhanced problem statement and discussion of the various block scenarios as Request-Tag at [1], moving torwards the "tag the request body" rather than the "discriminate the connection" terminology. Consideration will be given to not increasing message sizes, but later when the individual block transfer scenarios are understood better. Discussion on details will move to the draft's issue tracker, while we'll come back to the list when in need for guidance on RESTfullness and usability for other purposes. Best regards Christian [1]: https://github.com/chrysn/request-tag --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --zbvpnotubemwasdn Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAljKqZgACgkQOY0REtOk veGLqA/+J90imPrwCkkL20HkjgkTUMx1q7xW7bWz00cxsEnYbj8dtkuf4wHcCxV/ AS51vpGbf1K036jQVhtqi777ZvqmWR8ZNY7MamAtYtTQ61dmtPJbnZ3CwixLv+mB WWlATMOI9cE977w/aYfOEGWzq+tabwT1tEmbhzmFm2bdZAOexaQ96C0LLXHrtll7 WYyYY/KaB1LBhOB0UK5CIOSUrbY+/6GVpWDRnQHEPhJ9bxSY6eTpV6/X7tRuvQGf Wlu6HCZfOPpG2KNT8iROdAdFr9Sxojy/+Dvdhbd1dD8qjJCu5FFUU6366nFc8Mkb OJGw7ZENfTdXcvWtiUgrOa6adZU4kRTHk6xXIh3Tm417wAve9/rIzBGIfATvw5C0 1Txlo5UBSb++jOAxnjYGnLAif7r0rlqCtYeZSXzVhac4pA7Gullw69fKywLsklnX Nqz/87PVnjRQl47DFTSz4zMxMDq6DzcefOJGxzdSwrX21YPqZb0H/CuWP8pfYWRv G15HMhJ3qFqHUQGgX5r8WZJREAkaIfT5MtSmwuYnI/TLyL92qheoiivMUK6BOSTP 7f7Ii7KdKDQ3bEaXpPrcaoQz6q0xySO3O3+H7eEIa/U0H9H/M9O81k5psSoEIJsw RdsnydQN7fsQ9fow5Qcn7x0/YGh9fQQZ6tie4b/tF0ppP2tqOMU= =NQzP -----END PGP SIGNATURE----- --zbvpnotubemwasdn-- From nobody Thu Mar 16 09:43:38 2017 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 8E0201296B5 for ; Thu, 16 Mar 2017 09:43:36 -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] 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 fdCv67EpnoTP for ; Thu, 16 Mar 2017 09:43:34 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75E9D1296B6 for ; Thu, 16 Mar 2017 09:43:34 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id A3B6B468F7; Thu, 16 Mar 2017 17:43:32 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 6BC67AB; Thu, 16 Mar 2017 17:43:31 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 3C82E3DB; Thu, 16 Mar 2017 17:43:31 +0100 (CET) Received: (nullmailer pid 29459 invoked by uid 1000); Thu, 16 Mar 2017 16:43:30 -0000 Date: Thu, 16 Mar 2017 17:43:30 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: consultancy@vanderstok.org Cc: Core Message-ID: <20170316164330.nhic2gcec2xa7ntu@hephaistos.amsuess.com> References: <148943530454.20323.16258961043320992542@ietfa.amsl.com> <26bbb4e46e92a4b07076248c7612b173@xs4all.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4ywsflljtbdmun2o" Content-Disposition: inline In-Reply-To: <26bbb4e46e92a4b07076248c7612b173@xs4all.nl> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [core] Fwd: I-D Action: draft-ietf-core-resource-directory-10.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 16:43:36 -0000 --4ywsflljtbdmun2o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Peter, On Tue, Mar 14, 2017 at 08:37:38AM +0100, peter van der Stok wrote: > And other mistakes and ambiguities removed. among those, I just happened to note that instead of (say) being advertised as rt=3Dcore.rd-lookup (which would then have triggered string-appending "/ep" to it), the individual records are now advertised. Much appreciated; this makes implementation of resource trees smoother! (Actually I found an inconsistency of my implementation of -09, and looking it up, it was fixed in this version I had not read before). It does add one easily fixed quirx, however: In the lookup URI template, there's now /{+rd-looup-base}/{lookup-type}. Is that distinction still needed? The base can't be discovered now any more, so I'd say this now should be | URI Template: /{+type-lookup}{?d,...} |=20 | type-lookup :=3D RD lookup location (mandatory). Discovered for a given | type in .well-known/core by its resource type, where it SHOULD be | listed. The recommended value for this variable is: | "/rd-lookup/{type}". Mandatory to be present for types "ep" and | "res", optional for "d" and "gp". (Or maybe you they can stay "base URIs", but be many; that's only terminology then). I've gone through the rest of the document; "is used to discover the base URI for RD Lookup operations" would need to speak of "URIs". > Con(text) query parameter better defined Sounds good now. > Simple discovery text improved The term "Simple directory discovery" was dropped from the descriptions but survived in 5.3.3; it should probably say "simple registration" there. Other notes (some on nitpicking level, but if we're at WGLC level I suppose that's OK): * 5.2 mentions '"core.gp" is used to discover the base URI for RD group operations'. Shouldn't this be "core.rd-group"? (Unsure as not yet really familiar with all the groupcom things). * 5.2 lists HTTP support but no HTTP response codes * 5.2 first request/response example: needless quotes about a ct * 5.3 example: The HTTP requester will probably want to set a con=3D too unless it actually sends the HTTP request from its port 80. * 7. 'The domain lookup returns every lookup domain with a base RD resource value (e.g. "/rd") encapsulated within angle brackets.' (and similarly the following group paragraph): This sounds contradictory to the example given later (which returns '<>;d=3D"domain1"'), where nothing is encapsulated in the angle brackets. * 9.3 "con" entry: Since the latest changes this should include "path" too. * 10.1.2: In the requests from the CT, the domain parameter is given per-resource in the payload. Isn't that exclusively used as a query parameter in registration? Later in the group setup POST, the semicolons after the <> are missing in the payload, and the colon in 'coap//' in the con parameter, which has abundant quotation marks. * 10.2: "./well-known/core" -> "/." I haven't updated my implementation yet, but don't see any trouble on that road. Looks good to me, all things considered. Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --4ywsflljtbdmun2o Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAljKwLIACgkQOY0REtOk veHo/Q/9F/Or5BXujXTvasWVM/mPtsOVN56wQ3Kvzou2W/iiSCRf7CtBgByRejR9 JH06KrhW6CqVUY7sbBsPs+J3aM5TC4/n+EnBz6eaacqyETkfPzlpAY269sHDTTdT 9sMHjMF0QcoFTaex8x1sFgL/7KMHQ6EHVGGfDLBQQA8wRajtiMzsn4io8Hh1+0hO 4m5Q/9M0Wk9D0bybi+re8rb0/r7Jz2+ae8TfcOhG+aoAKvXOFhL4feSu/jwrrDxU /4vep6A0JWSiwm6zspaqe2ggMjugg5AvX6bdOAgYYqhZbRydKYTGEpxuLCEGQoys J5JvwAjhghduSGdZMWUhr4CK1Ts0r3LR8iGu3NUOwUiKemN7kfJtIV/FnLRKMxcO XjbPtdJJcGa3lYMlmS9Akldb8VKPrDlAW6t0LESZwRruR3O5UHAXMR23H9o74XIS nR5pLx9RcS1aIuo2z5zyp48DqPE4IFjAAcUCGVv82YrCvZTiDtFmgYIpdracJMxR leXu/siNF6/UPzDOXPGV0SL4GL3s5YMXNoRQPTmxgTcu0thL/GJ9eGpXUvIipqqP XcUOMSi9LDQPkNzpw2s5JXGiq+/C+1K3k0R7yzzPecWQi7LEs1pujMwuBz+UH7jf HZvUdYxjVs5D7tm0w3q5i/IzFquldvjEgj1HgDnLYfME62ep1l0= =haEy -----END PGP SIGNATURE----- --4ywsflljtbdmun2o-- From nobody Fri Mar 17 07:27:55 2017 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 26ED6129450 for ; Fri, 17 Mar 2017 07:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NP8ocd721VzN for ; Fri, 17 Mar 2017 07:27:52 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (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 7509F12944F for ; Fri, 17 Mar 2017 07:27:52 -0700 (PDT) Received: from us70uumx3.dmz.alcatel-lucent.com (unknown [135.245.18.15]) by Websense Email Security Gateway with ESMTPS id 8EE61426A069F for ; Fri, 17 Mar 2017 14:27:48 +0000 (GMT) Received: from us70uusmtp3.zam.alcatel-lucent.com (us70uusmtp3.zam.alcatel-lucent.com [135.5.2.65]) by us70uumx3.dmz.alcatel-lucent.com (GMO) with ESMTP id v2HERo3I027501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 17 Mar 2017 14:27:50 GMT Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id v2HERR9t013866 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 17 Mar 2017 14:27:50 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.74]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0301.000; Fri, 17 Mar 2017 10:26:06 -0400 From: "Carey, Timothy (Nokia - US)" To: core Thread-Topic: draft-becker-core-coap-sms-gprs-06: Identifying CoAP PDUs Thread-Index: AdKfKF6ML8bvf5XRR0G4XD2y6EQ6pQ== Date: Fri, 17 Mar 2017 14:26:06 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A8B2BF7@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77012A8B2BF7US70UWXCHMBA0_" MIME-Version: 1.0 Archived-At: Subject: [core] draft-becker-core-coap-sms-gprs-06: Identifying CoAP PDUs X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 14:27:54 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77012A8B2BF7US70UWXCHMBA0_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, How does a device determine from the received SMS PDU that this PDU is a Co= AP message and to which CoAP endpoint the CoAP message should be sent? Looking at the draft - I can decode the SMS using the TP-DATA-Coding-Scheme but how do I know it's= a CoAP message vs some other PDU. Likewise once I know it's a CoAP message how do I determine the CoAP endpoi= nt if the device supports multiple CoAP endpoints (maybe that is out of sco= pe). Thanks in advance, Tim --_000_9966516C6EB5FC4381E05BF80AA55F77012A8B2BF7US70UWXCHMBA0_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

How does a device determine from the received SMS PD= U that this PDU is a CoAP message and to which CoAP endpoint

the CoAP message should be sent?

 

Looking at the draft –

I can decode the SMS using the TP-DATA-Coding-Scheme= but how do I know it’s a CoAP message vs some other PDU.<= /p>

Likewise once I know it’s a CoAP message how d= o I determine the CoAP endpoint if the device supports multiple CoAP endpoi= nts (maybe that is out of scope).

 

Thanks in advance,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F77012A8B2BF7US70UWXCHMBA0_-- From nobody Fri Mar 17 08:20:36 2017 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 CB66A129479 for ; Fri, 17 Mar 2017 08:20:34 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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 p01JXLKJU9z2 for ; Fri, 17 Mar 2017 08:20:33 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 D620912949B for ; Fri, 17 Mar 2017 08:20:32 -0700 (PDT) Received: from [192.168.91.179] ([80.92.121.218]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MdrK9-1caE2M3vMz-00Phhs; Fri, 17 Mar 2017 16:20:24 +0100 To: Carsten Bormann , "core@ietf.org WG" References: From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <69131dc7-5e9d-b49e-db55-94b68065c498@gmx.net> Date: Fri, 17 Mar 2017 16:20:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="4ttl0hkbtWUFH9gf4Xh3JDHw3hf4sIMFm" X-Provags-ID: V03:K0:mKBve7LyUabhfCzdbGOHHsMlYJT4Fzm2FT8JHSXlNKhA9OeACIe 1HnTlg4n3X86jCtHPQUQ/oxf1dgFwBN/JobK4qdLyACAbkvl+d5hZaZghnKGlHofGHAn0t2 KIf5+qJBAquxPoXQz+dtA5nNju412u8Gdhc3ss2bsSM+PWth2IWXdlT4mDtjeh+pCzew7KT AU2/1jRze5mAOJGm1lbZA== X-UI-Out-Filterresults: notjunk:1;V01:K0:v4/X+QTYDZI=:sD3U8sJXmwyFBQXoTNVfcg OCGCYS69l5Pe2y8E07EEe9kcmikPvHW8GZQB17AcPh9ZXGLATz3rdGhC45xZquoUh0UN4/eXj rEQqR+hsBQKrCyewIunTQpWRDItfspy1NGZEMofHduSwzAJ3vMMa3LNzdIbQgPaJ6JqRtrzjS qVOKgDR4VZU7dSzhqXu52+oOtES6P1zAnRK2W3lqbjmST0N+L9UdcoOOogMlieZQN/N/LTlBp W9xOtTXTUtzqPS9OX1p6MHmZxRCptFu34XSjzxXRJhcSW2Pklf9JEBQxnaCAt/ZC+6PzImKZC n5ZyixMDqNmsdLjvpYEDNwksxyItHjGcWORODEVuBz4Je1+HxU2aFq09onJK6tWrjYIQ2IsL5 kHU5KK3iHjMOiSfpqokSEQ9EY8x5XaFyLKXP6X67mFh39oBZVFYFASHKZbzd0/H6lvjkBkk/E 29QDWsUunOtL6y2RGVI+HeN1jkWpKryRv6E0WVWUPM6LMcKQNdJvzLpKXpl5XpcapScu6nvuY 3Q/Xrsl6EY+Lnpw7GhxeRQMvfH88FkHzdLmW2pzmIoreNgZjqb+U+DLDoihsbfI6oNZJn/h1d 2kVoE6qSnxu1ExN9puHkq/eDj0SrQWtJsDScL4C2gKpc9L4DsgOkayVOXWCQxYDAPLFNZzmoN WtjH5nHYP8SRNdama50wVqxFmPDeibh1mTgnHuQ9OUOCLYFUCGuKeP6J+2E681sGORJajYD1n xrO6S2+B5oV7H8iTy7+EI0N530bOuTFti2dZ/1Z/nUr0nv1awF1sCz2vsEg= Archived-At: Subject: Re: [core] Interop event for coap over tcp/tls/websockets? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 15:20:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4ttl0hkbtWUFH9gf4Xh3JDHw3hf4sIMFm Content-Type: multipart/mixed; boundary="jbETomaqlQdgpH5ogOEtEG14viIfEo2jT"; protected-headers="v1" From: Hannes Tschofenig To: Carsten Bormann , "core@ietf.org WG" Message-ID: <69131dc7-5e9d-b49e-db55-94b68065c498@gmx.net> Subject: Re: [core] Interop event for coap over tcp/tls/websockets? References: In-Reply-To: --jbETomaqlQdgpH5ogOEtEG14viIfEo2jT Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Carsten, this is a great idea. For the IETF meeting Chicago it is a bit too short notice for me since I have committed myself to do other things at the Hackathon already. I think we should prepare ourselves to a have such an interop event for the Prague IETF meeting. Maybe it is possible to combine it with other CORE related specifications. Ciao Hannes On 03/15/2017 10:59 AM, Carsten Bormann wrote: > In the process of producing the writeup for the submission of coap-tcp-= tls to IESG, we noticed that we never asked about implementations. >=20 > It is well known that IoTivity has one (needing to be updated to a newe= r version). >=20 > Who else has an implementation that we could report in the writeup? >=20 > Apart from the writeup, should we stage an interop event? > The first opportunity would be at the Hackathon in Chicago. > But maybe we should do a more widely announced one in April. > In any case, this would be open to remote participation, just like the = recent OSCOAP interop. >=20 > Who wants to join? >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 --jbETomaqlQdgpH5ogOEtEG14viIfEo2jT-- --4ttl0hkbtWUFH9gf4Xh3JDHw3hf4sIMFm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJYy/63AAoJEGhJURNOOiAtgloH/0c/4OjulYxpXaD8e6Y3VhAR m58ZFcdTeN/Mw/xywu8luts0bFK8RW6ZtuQbcoLE6VKT9kkb0QDDSjeyHBsi5JQL jwqeVgIqMAJ6ZNTRlESUwbLTy51/cBpuHJftOofqnmVc65FMc0fupm5bw5ysoI6/ mQZgVnUXRirPqIxYaTNwoq6tH9pJ02OR+PTfASZ1iDWDMD0qAxkUem+mDpJ8koSo GHerU17gaGpnDBu7gY6aJJnrdvxVItxcbpkD7c5ZJsr96A/uPaI4wcfiSRUVPn2Y qu0SqOz54NX3LeeFxaInUf6mYMChJRPWPDXQYgEdQ2Il2lpq9BWhi1K9smWL+g4= =BjjQ -----END PGP SIGNATURE----- --4ttl0hkbtWUFH9gf4Xh3JDHw3hf4sIMFm-- From nobody Sun Mar 19 10:55:58 2017 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 021D2128BB6 for ; Sun, 19 Mar 2017 10:55:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148994615700.21337.15411359498621970998.idtracker@ietfa.amsl.com> Date: Sun, 19 Mar 2017 10:55:57 -0700 From: IETF Secretariat Archived-At: Subject: [core] Milestones changed for core WG X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Mar 2017 17:55:57 -0000 Changed milestone "WG adoption for Management over CoAP", resolved as "Done", added draft-ietf-core-comi to milestone. URL: https://datatracker.ietf.org/wg/core/about/ From nobody Sun Mar 19 10:57:48 2017 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 77D97128B37 for ; Sun, 19 Mar 2017 10:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WoRrWFnHjlG4 for ; Sun, 19 Mar 2017 10:57:44 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F38241289B0 for ; Sun, 19 Mar 2017 10:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v2JHvfVH023620 for ; Sun, 19 Mar 2017 18:57:41 +0100 (CET) Received: from [192.168.217.124] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vmRch54wZzDHhj; Sun, 19 Mar 2017 18:57:40 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: <148994615700.21337.15411359498621970998.idtracker@ietfa.amsl.com> Date: Sun, 19 Mar 2017 18:57:39 +0100 X-Mao-Original-Outgoing-Id: 511639059.662823-6664314bb41011af96d29ea050a3fa97 Content-Transfer-Encoding: quoted-printable Message-Id: <00CC3EF0-1BBB-464C-B424-4BCD98602FE6@tzi.org> References: <148994615700.21337.15411359498621970998.idtracker@ietfa.amsl.com> To: "core@ietf.org WG" X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [core] Milestones changed for core WG X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Mar 2017 17:57:46 -0000 (Just in case you wonder: This happened in January already; we just = forget to update the milestone as =E2=80=9CDone=E2=80=9D.) Gr=C3=BC=C3=9Fe, Carsten > On 19 Mar 2017, at 18:55, IETF Secretariat = wrote: >=20 > Changed milestone "WG adoption for Management over CoAP", resolved as > "Done", added draft-ietf-core-comi to milestone. >=20 > URL: https://datatracker.ietf.org/wg/core/about/ >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 From nobody Mon Mar 20 00:21:11 2017 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 CB672127071 for ; Mon, 20 Mar 2017 00:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.697 X-Spam-Level: X-Spam-Status: No, score=-4.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_HELO_PASS=-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=armh.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 IqqbFlmRBovK for ; Mon, 20 Mar 2017 00:21:08 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0054.outbound.protection.outlook.com [104.47.2.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C47BA1296B7 for ; Mon, 20 Mar 2017 00:21:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=uesEfw0+3OD2n4Q/HP5s2FGD26L2XsIvhPgFOcFIwho=; b=iH14ZdxmKbrs4c+U2k6pQ5ASrek2/IKz0KDj5i2gfQM4rsKFzfoDHiuxHPnkBb7I8pzsqof206FF8SoOSE8JBN3j19RwC4gmGUMwn2AzIHJv/vgwv1DPL8D9zG/8kwxHMaP1QBcFJLUhTZrmH1rnjZ4SpXgnbFzeFXG6NbROR1c= Received: from DB6PR0802MB2374.eurprd08.prod.outlook.com (10.172.228.141) by DB6PR0802MB2373.eurprd08.prod.outlook.com (10.172.228.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.17; Mon, 20 Mar 2017 07:21:05 +0000 Received: from DB6PR0802MB2374.eurprd08.prod.outlook.com ([10.172.228.141]) by DB6PR0802MB2374.eurprd08.prod.outlook.com ([10.172.228.141]) with mapi id 15.01.0961.018; Mon, 20 Mar 2017 07:21:05 +0000 From: Lauri Piikivi To: core Thread-Topic: [core] draft-becker-core-coap-sms-gprs-06: Identifying CoAP PDUs Thread-Index: AdKfKF6ML8bvf5XRR0G4XD2y6EQ6pQCIiogA Date: Mon, 20 Mar 2017 07:21:05 +0000 Message-ID: <69305B9C-184F-4063-8B86-1929749241DF@arm.com> References: <9966516C6EB5FC4381E05BF80AA55F77012A8B2BF7@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A8B2BF7@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [217.140.96.140] x-ms-office365-filtering-correlation-id: 463f1518-b33d-4c43-02de-08d46f61abf5 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:DB6PR0802MB2373; x-microsoft-exchange-diagnostics: 1; DB6PR0802MB2373; 7:v0I/tNMMNGZC9xjapMWSRar5aZJqyl+I6NkX2RgAW31r7BTwBQpavyK69SJX6PIrCozNMO4qQSKblI7sPj7qeOLAK3jQqnay7z1mPzY868O22wUk8Fx4UzMUUfXnmHpiaBukrwzXBdn+CUUTB1aOHGM6yAs8bQ3WN55ZiWVao+KCKf6+lV+/f0Gy3l4N/yoAm8+hH42jeYFuS+U58o+ABv7DPFfQMst8GofNaTK7R/tE9ZZsvnhtYG8NsuV+3jQNi5xmMuZaks2hkYEOLxPkxkrIaMSzr7CuQTg/MVemv29gXvnImTL+aN4Mvt3TG/WTn8bCY2l/EHv5778wKCu3EA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(82608151540597); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123560025)(20161123558025)(20161123562025)(20161123564025)(6072148); SRVR:DB6PR0802MB2373; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0802MB2373; x-forefront-prvs: 02524402D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39840400002)(39450400003)(39850400002)(39410400002)(24454002)(51874003)(40434004)(77096006)(38730400002)(66066001)(3280700002)(53936002)(236005)(83716003)(2950100002)(6512007)(8676002)(8936002)(6436002)(81166006)(86362001)(6246003)(966004)(82746002)(7906003)(25786008)(7736002)(50986999)(6506006)(606005)(76176999)(230783001)(54896002)(54356999)(6306002)(6486002)(122556002)(3660700001)(110136004)(229853002)(2900100001)(6916009)(5660300001)(99286003)(36756003)(5890100001)(189998001)(33656002)(3846002)(102836003)(2906002)(6116002)(53546008)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR0802MB2373; H:DB6PR0802MB2374.eurprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_69305B9C184F40638B861929749241DFarmcom_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2017 07:21:05.2413 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0802MB2373 Archived-At: Subject: Re: [core] draft-becker-core-coap-sms-gprs-06: Identifying CoAP PDUs X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 07:21:11 -0000 --_000_69305B9C184F40638B861929749241DFarmcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIFNNUyBiZWFyZXIgd2FzIHN1cHBvcnRlZCBieSBXQVAsIHdheSBiYWNrIOKAlCBoZXNpdGF0 ZSB0byBhZG1pdCB0aGF0IEkgd29ya2VkIG9uIGl0IDopICBUaGVyZSB0aGUgYXNzdW1wdGlvbiB3 YXMgdG8gdXNlIHRoZSBVc2VyLURhdGEtSGVhZGVyIGZvciBwb3J0cyBpbmZvcm1hdGlvbiwgYW5k IHRoZSBhc3N1bXB0aW9uIHdhcyB0aGF0IDgtYml0IFNNUyBpcyBjb21tb25wbGFjZS4NCg0KQ291 bGQgdGhlIHNwZWMgcmVmZXIgdG8gV0FQIGRpcmVjdGx5PyBodHRwOi8vd3d3Lm9wZW5tb2JpbGVh bGxpYW5jZS5vcmcvdGVjaC9hZmZpbGlhdGVzL3dhcC93YXAtMjU5LXdkcC0yMDAxMDYxNC1hLnBk Zg0KDQotIExhdXJpDQoNCg0KT24gMTcgTWFyIDIwMTcsIGF0IDE2OjI2LCBDYXJleSwgVGltb3Ro eSAoTm9raWEgLSBVUykgPHRpbW90aHkuY2FyZXlAbm9raWEuY29tPG1haWx0bzp0aW1vdGh5LmNh cmV5QG5va2lhLmNvbT4+IHdyb3RlOg0KDQpIZWxsbywNCg0KSG93IGRvZXMgYSBkZXZpY2UgZGV0 ZXJtaW5lIGZyb20gdGhlIHJlY2VpdmVkIFNNUyBQRFUgdGhhdCB0aGlzIFBEVSBpcyBhIENvQVAg bWVzc2FnZSBhbmQgdG8gd2hpY2ggQ29BUCBlbmRwb2ludA0KdGhlIENvQVAgbWVzc2FnZSBzaG91 bGQgYmUgc2VudD8NCg0KTG9va2luZyBhdCB0aGUgZHJhZnQg4oCTDQpJIGNhbiBkZWNvZGUgdGhl IFNNUyB1c2luZyB0aGUgVFAtREFUQS1Db2RpbmctU2NoZW1lIGJ1dCBob3cgZG8gSSBrbm93IGl0 4oCZcyBhIENvQVAgbWVzc2FnZSB2cyBzb21lIG90aGVyIFBEVS4NCkxpa2V3aXNlIG9uY2UgSSBr bm93IGl04oCZcyBhIENvQVAgbWVzc2FnZSBob3cgZG8gSSBkZXRlcm1pbmUgdGhlIENvQVAgZW5k cG9pbnQgaWYgdGhlIGRldmljZSBzdXBwb3J0cyBtdWx0aXBsZSBDb0FQIGVuZHBvaW50cyAobWF5 YmUgdGhhdCBpcyBvdXQgb2Ygc2NvcGUpLg0KDQpUaGFua3MgaW4gYWR2YW5jZSwNClRpbQ0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmNvcmUgbWFpbGlu ZyBsaXN0DQpjb3JlQGlldGYub3JnPG1haWx0bzpjb3JlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQoNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBj b250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlh bCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVk IHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBu b3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3Ig YW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRp dW0uIFRoYW5rIHlvdS4NCg== --_000_69305B9C184F40638B861929749241DFarmcom_ Content-Type: text/html; charset="utf-8" Content-ID: <5D7AE1B0ECC69946AEBB697B490E1933@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5UaGUgU01T IGJlYXJlciB3YXMgc3VwcG9ydGVkIGJ5IFdBUCwgd2F5IGJhY2sg4oCUIGhlc2l0YXRlIHRvIGFk bWl0IHRoYXQgSSB3b3JrZWQgb24gaXQgOikgJm5ic3A7VGhlcmUgdGhlIGFzc3VtcHRpb24gd2Fz IHRvIHVzZSB0aGUgVXNlci1EYXRhLUhlYWRlciBmb3IgcG9ydHMgaW5mb3JtYXRpb24sIGFuZCB0 aGUgYXNzdW1wdGlvbiB3YXMgdGhhdCA4LWJpdCBTTVMgaXMgY29tbW9ucGxhY2UuJm5ic3A7PC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5D b3VsZCB0aGUgc3BlYyByZWZlciB0byBXQVAgZGlyZWN0bHk/Jm5ic3A7PGEgaHJlZj0iaHR0cDov L3d3dy5vcGVubW9iaWxlYWxsaWFuY2Uub3JnL3RlY2gvYWZmaWxpYXRlcy93YXAvd2FwLTI1OS13 ZHAtMjAwMTA2MTQtYS5wZGYiIGNsYXNzPSIiPmh0dHA6Ly93d3cub3Blbm1vYmlsZWFsbGlhbmNl Lm9yZy90ZWNoL2FmZmlsaWF0ZXMvd2FwL3dhcC0yNTktd2RwLTIwMDEwNjE0LWEucGRmPC9hPjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ LSBMYXVyaTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxiciBj bGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+T24gMTcgTWFyIDIwMTcsIGF0IDE2OjI2LCBDYXJleSwgVGltb3RoeSAoTm9raWEg LSBVUykgJmx0OzxhIGhyZWY9Im1haWx0bzp0aW1vdGh5LmNhcmV5QG5va2lhLmNvbSIgY2xhc3M9 IiI+dGltb3RoeS5jYXJleUBub2tpYS5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFz cz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIiBzdHlsZT0icGFnZTogV29yZFNlY3Rpb24xOyBmb250LWZhbWlseTog SGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp YW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v cm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KSGVsbG8sPG86cCBjbGFz cz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNz PSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KSG93IGRvZXMgYSBkZXZpY2UgZGV0ZXJtaW5lIGZy b20gdGhlIHJlY2VpdmVkIFNNUyBQRFUgdGhhdCB0aGlzIFBEVSBpcyBhIENvQVAgbWVzc2FnZSBh bmQgdG8gd2hpY2ggQ29BUCBlbmRwb2ludDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCnRoZSBDb0FQIG1lc3NhZ2Ug c2hvdWxkIGJlIHNlbnQ/PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAx MXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KTG9va2lu ZyBhdCB0aGUgZHJhZnQg4oCTPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCkkgY2FuIGRlY29kZSB0aGUgU01TIHVzaW5nIHRoZSBU UC1EQVRBLUNvZGluZy1TY2hlbWUgYnV0IGhvdyBkbyBJIGtub3cgaXTigJlzIGEgQ29BUCBtZXNz YWdlIHZzIHNvbWUgb3RoZXIgUERVLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCkxpa2V3aXNlIG9uY2UgSSBrbm93 IGl04oCZcyBhIENvQVAgbWVzc2FnZSBob3cgZG8gSSBkZXRlcm1pbmUgdGhlIENvQVAgZW5kcG9p bnQgaWYgdGhlIGRldmljZSBzdXBwb3J0cyBtdWx0aXBsZSBDb0FQIGVuZHBvaW50cyAobWF5YmUg dGhhdCBpcyBvdXQgb2Ygc2NvcGUpLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7 PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4N ClRoYW5rcyBpbiBhZHZhbmNlLDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NClRpbTxvOnAgY2xhc3M9IiI+PC9vOnA+ PC9kaXY+DQo8L2Rpdj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczog YXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5 OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZl dGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1j YXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7 IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0 LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3Jk LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+ DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBm b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0 OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBv cnRhbnQ7IiBjbGFzcz0iIj5jb3JlDQogbWFpbGluZyBsaXN0PC9zcGFuPjxiciBzdHlsZT0iZm9u dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7 IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lk b3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4OyIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9yZyIgc3R5bGU9ImNv bG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyBmb250LWZhbWlseTogSGVs dmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50 LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdv cmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0i Ij5jb3JlQGlldGYub3JnPC9hPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9u dC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6 IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6 IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUiIHN0eWxlPSJjb2xv cjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsgZm9udC1mYW1pbHk6IEhlbHZl dGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1j YXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7 IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0 LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3Jk LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlPC9hPjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQpJTVBPUlRBTlQgTk9USUNFOiBUaGUg Y29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRp YWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl ZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8g bm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9y IGFueSBwdXJwb3NlLA0KIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBt ZWRpdW0uIFRoYW5rIHlvdS4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_69305B9C184F40638B861929749241DFarmcom_-- From nobody Mon Mar 20 01:02:04 2017 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 C10B71296BD for ; Mon, 20 Mar 2017 01:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vU62AYe5Wz_E for ; Mon, 20 Mar 2017 01:02:01 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 440311296B6 for ; Mon, 20 Mar 2017 01:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v2K81tAJ006967; Mon, 20 Mar 2017 09:01:55 +0100 (CET) Received: from [IPv6:2002:8666:da7b::bcd8:992e:3d79:f24a] (unknown [IPv6:2002:8666:da7b:0:bcd8:992e:3d79:f24a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vmpLq5tTwzDHsC; Mon, 20 Mar 2017 09:01:55 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: <69305B9C-184F-4063-8B86-1929749241DF@arm.com> Date: Mon, 20 Mar 2017 09:01:55 +0100 Cc: core X-Mao-Original-Outgoing-Id: 511689715.205659-b1ba8679a2697533991a3adb64ebe6e9 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9966516C6EB5FC4381E05BF80AA55F77012A8B2BF7@US70UWXCHMBA05.zam.alcatel-lucent.com> <69305B9C-184F-4063-8B86-1929749241DF@arm.com> To: Lauri Piikivi X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [core] draft-becker-core-coap-sms-gprs-06: Identifying CoAP PDUs X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 08:02:04 -0000 On 20 Mar 2017, at 08:21, Lauri Piikivi wrote: >=20 > The SMS bearer was supported by WAP, way back =E2=80=94 hesitate to = admit that I worked on it :) There the assumption was to use the = User-Data-Header for ports information, and the assumption was that = 8-bit SMS is commonplace.=20 One of the things that came up during development of this draft is that = 8-bit SMS actually is slightly less common than we assumed. Hence the = discussion of 7-bit mappings. > Could the spec refer to WAP directly? = http://www.openmobilealliance.org/tech/affiliates/wap/wap-259-wdp-20010614= -a.pdf If we can avoid that=E2=80=A6 I don=E2=80=99t think implementations right now have a multiplexing = point here. That would be nice to have to make CoAP over SMS usable with devices = such as smartphones. I=E2=80=99m just not sure how to do this in a way that accommodates = existing implementations. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Mar 20 05:52:47 2017 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 A03E413145A for ; Mon, 20 Mar 2017 05:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsTSPTz34flu for ; Mon, 20 Mar 2017 05:52:43 -0700 (PDT) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94936126FB3 for ; Mon, 20 Mar 2017 05:52:43 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.206]) by smtp-cloud6.xs4all.net with ESMTP id yCsh1u0084SmhUa01CshBh; Mon, 20 Mar 2017 13:52:41 +0100 Received: from 2001:983:a264:1:940:a8bd:e05c:3765 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 20 Mar 2017 13:52:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 20 Mar 2017 13:52:41 +0100 From: peter van der Stok To: =?UTF-8?Q?Christian_Ams=C3=BCss?= Cc: consultancy@vanderstok.org, Core Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <20170316164330.nhic2gcec2xa7ntu@hephaistos.amsuess.com> References: <148943530454.20323.16258961043320992542@ietfa.amsl.com> <26bbb4e46e92a4b07076248c7612b173@xs4all.nl> <20170316164330.nhic2gcec2xa7ntu@hephaistos.amsuess.com> Message-ID: <741d548f2be443debf557e3334e3c241@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Subject: Re: [core] Fwd: I-D Action: draft-ietf-core-resource-directory-10.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 12:52:46 -0000 Hi Christian, Thank for the feedback; see below. Christian Amsüss schreef op 2017-03-16 17:43: > Hello Peter, > > On Tue, Mar 14, 2017 at 08:37:38AM +0100, peter van der Stok wrote: >> And other mistakes and ambiguities removed. > > among those, I just happened to note that instead of (say) > being advertised as rt=core.rd-lookup (which would then have triggered > string-appending "/ep" to it), the individual records are now > advertised. > > Much appreciated; this makes implementation of resource trees smoother! Good to read. > (Actually I found an inconsistency of my implementation of -09, and > looking it up, it was fixed in this version I had not read before). > > > It does add one easily fixed quirx, however: > > In the lookup URI template, there's now > /{+rd-looup-base}/{lookup-type}. > Is that distinction still needed? The base can't be discovered now any > more, so I'd say this now should be > > | URI Template: /{+type-lookup}{?d,...} > | > | type-lookup := RD lookup location (mandatory). Discovered for a given > | type in .well-known/core by its resource type, where it SHOULD be > | listed. The recommended value for this variable is: > | "/rd-lookup/{type}". Mandatory to be present for types "ep" and > | "res", optional for "d" and "gp". > > (Or maybe you they can stay "base URIs", but be many; that's only > terminology then). URIs it will be; rd-lookup-base is also used later; and is an understandable concept. > > I've gone through the rest of the document; "is used to discover the > base URI for RD Lookup operations" would need to speak of "URIs". > > >> Con(text) query parameter better defined > > Sounds good now. > >> Simple discovery text improved > > The term "Simple directory discovery" was dropped from the descriptions > but survived in 5.3.3; it should probably say "simple registration" > there. agreed. > > > Other notes (some on nitpicking level, but if we're at WGLC level I > suppose that's OK): not yet. > > * 5.2 mentions '"core.gp" is used to discover the base URI for RD group > operations'. Shouldn't this be "core.rd-group"? (Unsure as not yet > really familiar with all the groupcom things). No opinion. see what the co-authors think. > > * 5.2 lists HTTP support but no HTTP response codes Correct; > > * 5.2 first request/response example: needless quotes about a ct correct, again. > > * 5.3 example: The HTTP requester will probably want to set a con= too > unless it actually sends the HTTP request from its port 80. good suggestions > > * 7. 'The domain lookup returns every lookup domain with a base RD > resource value (e.g. "/rd") encapsulated within angle brackets.' (and > similarly the following group paragraph): This sounds contradictory > to > the example given later (which returns '<>;d="domain1"'), where > nothing is encapsulated in the angle brackets. Yep, have to solve that one way or the other. > > * 9.3 "con" entry: Since the latest changes this should include "path" > too. mistakes come and go, in spite of github > > * 10.1.2: In the requests from the CT, the domain parameter is given > per-resource in the payload. Isn't that exclusively used as a query > parameter in registration? change it, thanks for looking at it. > > Later in the group setup POST, the semicolons after the <> are > missing in the payload, and the colon in 'coap//' in the con > parameter, which has abundant quotation marks. thanks again. > > * 10.2: "./well-known/core" -> "/." there is also another instance; also here mistakes come and go. > > > I haven't updated my implementation yet, but don't see any trouble on > that road. Looks good to me, all things considered. Many thanks, peter > > Best regards > Christian From nobody Mon Mar 20 11:40:02 2017 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 ECC69128DF6; Mon, 20 Mar 2017 11:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-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=nokia.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 pn4mrEaOekul; Mon, 20 Mar 2017 11:39:57 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0133.outbound.protection.outlook.com [104.47.0.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2091F1294B5; Mon, 20 Mar 2017 11:39:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=I4JQumvJG20i1Pz3EzqnwP23lGir8td18xe8DYk1WDU=; b=Hge9uZlhRX+W3PZxYsbW3pCrxd43l4Fl+t5JTyCEu0IE9AeS3M0GKoRZI4EX5BSv1cpP6ETFhMQJVtdaizDZk4m7pbnoovIB0388xWLWaehHchVYa862kZgX4pztmmoki3GkeSerFNrCTsY77WrYxwsuq6knBkOPZCQunMejvvo= Received: from VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) by VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Mon, 20 Mar 2017 18:39:49 +0000 Received: from VI1PR07MB1102.eurprd07.prod.outlook.com ([10.163.168.26]) by VI1PR07MB1102.eurprd07.prod.outlook.com ([10.163.168.26]) with mapi id 15.01.0991.011; Mon, 20 Mar 2017 18:39:49 +0000 From: "Fossati, Thomas (Nokia - GB)" To: "draft-becker-core-coap-sms-gprs@ietf.org" CC: "Fossati, Thomas (Nokia - GB)" , "core@ietf.org" Thread-Topic: Review of draft-becker-core-coap-sms-gprs-06 Thread-Index: AQHSoala56Z3xhAfE0y/2zRBx7lvtA== Date: Mon, 20 Mar 2017 18:39:49 +0000 Message-ID: <3B156DF2-EC3C-4135-94C1-9D1A4ED686B8@on.nokia.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [92.24.230.135] x-microsoft-exchange-diagnostics: 1; VI1PR07MB1102; 7:4UjJSZ11ObJ8PpkK3FLfnKMaPyq67K5g6YSLsL9NLCVB5jcLh6IUOw2SU8LEDaGHx7fYdd7nHkRTf1mNzQNnp8WKkTnq2e1FI0cBxDAjmUtMEO7Vm0cRPamwrSnNb470DNqatgxV0zzQEUW2Z3Jfd4CroNN0H7bdImr2KYELzyy+0rlobuagMaNVh9y70vwhDccwOVeipfXZooVvJ7HBbdK5MvwVBydx323gFcLJzGH8ZEqIiEj/YjCgMd88+Ld4afQE+eEkOKI3o+3I/maIof+nSncstvO0QtugCdzgNqrWfdiY5JhYjWyswCkfo6AGlAiTf7y32HRh//9KzUEz4Q== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39450400003)(39860400002)(39840400002)(39850400002)(57704003)(305945005)(77096006)(6486002)(33656002)(2906002)(83506001)(82746002)(66066001)(50986999)(6506006)(3280700002)(83716003)(6436002)(54906002)(5640700003)(6512007)(6306002)(53936002)(25786008)(81166006)(99286003)(102836003)(8936002)(2501003)(3846002)(8676002)(6116002)(122556002)(6916009)(3660700001)(54356999)(450100002)(110136004)(189998001)(4326008)(38730400002)(4001350100001)(230783001)(2351001)(5660300001)(2900100001)(7736002)(86362001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1102; H:VI1PR07MB1102.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: 793f6650-9d9d-4f1a-2485-08d46fc07d52 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:VI1PR07MB1102; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123560025)(20161123558025)(20161123555025)(20161123562025)(6072148); SRVR:VI1PR07MB1102; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1102; x-forefront-prvs: 02524402D6 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2017 18:39:49.1928 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1102 Archived-At: Subject: [core] Review of draft-becker-core-coap-sms-gprs-06 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 18:40:00 -0000 RGVhciBhdXRob3JzLA0KDQpUaGFua3MgdmVyeSBtdWNoIGZvciBrZWVwaW5nIHRoZSBiYWxsIHJv bGxpbmcuDQoNCkkndmUganVzdCBmaW5pc2hlZCByZWFkaW5nIC0wNiBhbmQgaGF2ZSBmZXcgY29t bWVudHMuICBTZWUgYmVsb3cuDQoNCkNoZWVycywgdGhhbmtzLA0KdA0KDQo9PSBTMy4xID09DQpM YXN0IHBhcmE6IHRoZSB0ZXh0IGNhbiBiZSBhIGJpdCBtaXNsZWFkaW5nOg0K4oCcWy4uLl0gSWYg dGhlIENvQVAgQ2xpZW50IGhhcyBzZW50IGEgY29uZmlybWFibGUgbWVzc2FnZSwgdGhlIENvQVAg U2VydmVyIE1VU1QgdXNlIGEgc2VwYXJhdGUgU01TIG1lc3NhZ2UgdG8gdHJhbnNtaXQgdGhlIEFD Sy7igJ0NClRoZSBBQ0sgKmNhbiogYmUgcGlnZ3liYWNrZWQgdG8gdGhlIHJlc3BvbnNlLiBUaGUg TVVTVCBpcyBmb3IgdGhlIHNlbmRlciB0byBub3QgdHJhZGUgYW4gU01TLVNUQVRVUy1SRVBPUlQg Zm9yIGFuIGFwcGxpY2F0aW9uIGxheWVyIEFDSy4gIE1pZ2h0IGJlIHdvcnRoIHJlLXBocmFzaW5n Pw0KDQo9PSBTNCA9PQ0KRmlyc3QgcGFyYToNCuKAnFsuLi5dIHRoZSB0d28gb3RoZXIgZW5jb2Rp bmdzIGFyZSBkZXBlbmRlbnQgb24gdGhlIGxhbmd1YWdlIHRoYXQgbmVlZHMgdG8gYmUgZW5jb2Rl ZCBbLi4uXeKAnQ0KOC1iaXQgZGF0YSBpcyBub3QgZGVwZW5kZW50IG9uIGxhbmd1YWdlIChpbiBm YWN0IGl0J3Mgbm90IGludGVuZGVkIGZvciB0ZXh0IG1lc3NhZ2VzKS4NCg0KU2Vjb25kIHBhcmE6 DQrigJxbLi4uXSBTaW5jZSBub3QgYWxsIE1TcyBzdXBwb3J0IDggYml0IHNob3J0IG1lc3NhZ2Ug ZW5jb2RpbmcsIHRoZSBwcmVmZXJyZWQgZW5jb2Rpbmcgc2NoZW1lIGZvciBDb0FQIG1lc3NhZ2Vz IG92ZXIgU01TIGlzIHRoZXJlZm9yZSA3IGJpdCwgW+KApl3igJ0NCkknbSBub3Qgc3VyZSB3ZSBz aG91bGQgcHJlZmVyIDctYml0IG92ZXIgYmluYXJ5LiAgTWF5YmUgYSBiZXR0ZXIgc3RyYXRlZ3kg d291bGQgYmUgdG8gc3RhcnQgb3B0aW1pc3RpYyAoOC1iaXQgZGF0YSkgYW5kIGZhbGwgYmFjayB0 byBvbmUgb2YgdGhlIDctYml0IEFTQ0lJIGVuY29kaW5nIHZhcmlhbnRzIGlmIHRoYXQgZG9lc24n dCB3b3JrLiAgVGhlIHJlYXNvbmluZyBpcyB0aGF0IGhhdmluZyAxMC0yMCBieXRlcyBtb3JlIGhl cmUgY2FuIG1ha2UgYSByZWFsIGRpZmZlcmVuY2UuDQoNCldoZW4gdW5wYWNraW5nLCBob3cgaXMg dGhlIHJlY2VpdmVyIHN1cHBvc2VkIHRvIGtub3cgd2hpY2ggb2YgdGhlIHRocmVlIGRpZmZlcmVu dCBlbmNvZGluZ3MgKGI2NCwgYjg1IGFuZCBBU0NJSS1vcHRpbWl6ZWQpIGhhcyBiZWVuIHVzZWQg YnkgdGhlIHNlbmRlcj8NCg0KPT0gUzYgPT0NCknigJltIGhhdmluZyBhIGJpdCBvZiB0cm91Ymxl IHdpdGggdGhlIGxhc3QgcGFyYToNCuKAnFRvIGFsbG93IHRoZSBDb0FQIGNsaWVudCB0byBkZXRl Y3QgdGhhdCB0aGUgc2hvcnQgbWVzc2FnZSBjb250YWlucyBhIENvQVAgbWVzc2FnZSwgdGhlIFRQ LURBVEEtQ29kaW5nLVNjaGVtZSBTSE9VTEQgYmUgaW5jbHVkZWQu4oCdDQpUUC1EQ1MgaXMgYSBt YW5kYXRvcnkgZmllbGQgaW4gYm90aCBTTVMtU1VCTUlUIGFuZCBTTVMtREVMSVZFUiBtZXNzYWdl cywgaG93IGNhbiB0aGlzIGJlIGEgU0hPVUxEPyAgQW5kOiBob3cgRENTIGlzIHN1cHBvc2VkIHRv IGFjdCBhcyBhbiB1cHBlciBsYXllciBwcm90b2NvbCBpZGVudGlmaWVyPw0KDQo9PSBTNy4xID09 DQpTaW5jZSB0aGUgc2NvcGUgaXMgZ2VuZXJpYyAiYWx0ZXJuYXRpdmUgdHJhbnNwb3J0cyIsIGl0 J2Qgc2VlbSB3aXNlIHRvIGFsc28gaGF2ZSBhIFJlc3BvbnNlLVRvLVVyaS1TY2hlbWUgb3B0aW9u IGFzIHdlbGw/DQoNCiJUaGUgb3B0aW9ucyBTSE9VTEQgTk9UIGJlIHVzZWQgaW4gdGhlIHJlc3Bv bnNlLiINCldoeSBpcyB0aGlzIG5vdCBhIE1VU1QgTk9UPyAgSS5lLiwgd2hlbiBpcyBpdCBPSyB0 byB1c2UgdGhlc2Ugb3B0aW9ucyBpbiBhIHJlc3BvbnNlPw0KDQo9PSBTOCA9PQ0KRG8gd2UgbmVl ZCBtdXhpbmc/ICBJZiBzbywgaG93IGNhbiB0aGlzIGJlIGFjaGlldmVkIChlLmcuLCBodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzkyNSNhcHBlbmRpeC1BLjMpPw0KDQo9PSBTOSA9PQ0K cy9SRVNQT05TRV9USU1FT1VUL0FDS19USU1FT1VUPw0KDQpUaGUgdGV4dCBpcyBzdGlsbCBhIHRh ZCBoYW5kLXdhdnk7IEknZCBsaWtlIHVzIHRvIHByb3ZpZGUgc29tZSBndWlkYW5jZSBhdCBsZWFz dC4gIEV4dHJlbWUgUlRUIHZhcmlhbmNlIGlzIHRoZSBraWxsZXIgaGVyZSwgYnV0IHlvdSBjYW4g dXN1YWxseSBnZXQgYXJvdW5kIHRoYXQgd2l0aCBhIFNMQS4NCihBIGJpdCB0YW5nZW50LCBidXQg YW5vdGhlciB0aGluZyB0aGF0IG1pZ2h0IGJlIHdvcnRoIHRha2luZyBpbnRvIGNvbnNpZGVyYXRp b24gaW4gdGhlIGRyYWZ0IGlzIHRocm91Z2hwdXQgZ3VhcmFudGVlcy9yZXF1aXJlbWVudHMuKQ0K DQo9PSBTMTEgPT0NCkl0IG1pZ2h0IGJlIHdvcnRoIGFkZGluZyBzb21lIHRleHQgcmU6DQotIFNw b29maW5nIFRQLU9BIChub3QgcGFydGljdWxhcmx5IGVhc3ksIGJ1dCBjZXJ0YWlubHkgcG9zc2li bGUpOw0KLSBBZGRpbmcgYSByZXBseS1hZGRyZXNzIFVESCB3aGljaCBpcyBkaWZmZXJlbnQgZnJv bSBUUC1PQTsNCi0gVXNpbmcgRFRMUyBvbiB0b3Agb2YgdGhlIHRyYW5zcG9ydCAoc2VlIFJGQyA3 OTI1KS4NCg0K From nobody Mon Mar 20 12:25:03 2017 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 7FB10129513; Mon, 20 Mar 2017 12:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHNjHmbfDW-O; Mon, 20 Mar 2017 12:24:59 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E5A2128CB9; Mon, 20 Mar 2017 12:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v2KJOuc0028958; Mon, 20 Mar 2017 20:24:56 +0100 (CET) Received: from [192.168.217.124] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vn5Vw1Xy6zDJD9; Mon, 20 Mar 2017 20:24:56 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: <3B156DF2-EC3C-4135-94C1-9D1A4ED686B8@on.nokia.com> Date: Mon, 20 Mar 2017 20:24:55 +0100 Cc: "draft-becker-core-coap-sms-gprs@ietf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 511730695.339808-2032789885733461fc2f81a459eb9764 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3B156DF2-EC3C-4135-94C1-9D1A4ED686B8@on.nokia.com> To: "Fossati, Thomas (Nokia - GB)" X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [core] Review of draft-becker-core-coap-sms-gprs-06 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 19:25:02 -0000 Hi Thomas, Good points. Picking two up them: > On 20 Mar 2017, at 19:39, Fossati, Thomas (Nokia - GB) = wrote: >=20 > =E2=80=9C[...] Since not all MSs support 8 bit short message encoding, = the preferred encoding scheme for CoAP messages over SMS is therefore 7 = bit, [=E2=80=A6]=E2=80=9D > I'm not sure we should prefer 7-bit over binary. Maybe a better = strategy would be to start optimistic (8-bit data) and fall back to one = of the 7-bit ASCII encoding variants if that doesn't work. The = reasoning is that having 10-20 bytes more here can make a real = difference. One of the 7-bit variants (ASCII-optimized) may actually use less space = than the 8-bit variants, depending on the data, so that may not be as = clear-cut. In any case, a device offering an SMS URI needs to be able to express = whether it can accept 8-bit SMS. We currently don=E2=80=99t have a good = way to express this in an SMS URI, which would provide a client to hint = to go with. > When unpacking, how is the receiver supposed to know which of the = three different encodings (b64, b85 and ASCII-optimized) has been used = by the sender? I think the WG should decide that in the standard. (I=E2=80=99m obviously biased to ASCII-optimized, as it wins on almost = all characteristics.) > =3D=3D S6 =3D=3D > I=E2=80=99m having a bit of trouble with the last para: > =E2=80=9CTo allow the CoAP client to detect that the short message = contains a CoAP message, the TP-DATA-Coding-Scheme SHOULD be = included.=E2=80=9D > TP-DCS is a mandatory field in both SMS-SUBMIT and SMS-DELIVER = messages, how can this be a SHOULD? And: how DCS is supposed to act as = an upper layer protocol identifier? DCS will tell you whether the SMS was 7-bit or 8-bit. The big issue is how a device finds out that this was a CoAP SMS in the = first place; I=E2=80=99m not sure we have a very good multiplexing point = for this. Some heuristics may be required. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Mar 21 01:41:58 2017 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 0119C1296A3 for ; Tue, 21 Mar 2017 01:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgwBipuDFzAG for ; Tue, 21 Mar 2017 01:41:55 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53F58129693 for ; Tue, 21 Mar 2017 01:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v2L8fqJE015469; Tue, 21 Mar 2017 09:41:52 +0100 (CET) Received: from client-0165.vpn.uni-bremen.de (client-0165.vpn.uni-bremen.de [134.102.107.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vnRBS0rXWzDGph; Tue, 21 Mar 2017 09:41:52 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: <69131dc7-5e9d-b49e-db55-94b68065c498@gmx.net> Date: Tue, 21 Mar 2017 09:41:51 +0100 Cc: "core@ietf.org WG" X-Mao-Original-Outgoing-Id: 511778511.45503-e964d2311198b9cfff6ac8a338d41c9e Content-Transfer-Encoding: quoted-printable Message-Id: References: <69131dc7-5e9d-b49e-db55-94b68065c498@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [core] Interop event for coap over tcp/tls/websockets? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 08:41:57 -0000 On 17 Mar 2017, at 16:20, Hannes Tschofenig = wrote: >=20 > Hi Carsten, >=20 > this is a great idea. For the IETF meeting Chicago it is a bit too = short > notice for me since I have committed myself to do other things at the > Hackathon already. I think we should prepare ourselves to a have such = an > interop event for the Prague IETF meeting. Maybe it is possible to > combine it with other CORE related specifications. Right. We are already planning to have a OSCOAP interop there, so = coap-tcp-tls, as well as fetch-patch, could be added to that. I=E2=80=99m= wondering whether we should try to get ETSI=E2=80=99s help. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Mar 21 05:24:28 2017 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 2B49D129857; Tue, 21 Mar 2017 05:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.697 X-Spam-Level: X-Spam-Status: No, score=-4.697 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=-2.796, SPF_HELO_PASS=-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=nokia.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 moZO-S17I-hu; Tue, 21 Mar 2017 05:24:25 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0094.outbound.protection.outlook.com [104.47.2.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E011112984B; Tue, 21 Mar 2017 05:24:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=D6aZsPRsxB4yiocQVQVTo07XI/cr2VZwHavxGThzI5s=; b=Epkt0FeFKnC4YXoTMdkNjNE/WwXf8BGKbgmCCma5+1HQzSUwl0kwHbPHrceOVXa4sTe+wGkGMbPt+DT8fhUCTFJX0TBRPa4MYvYESMjXku/kFUducKvbkL9eTUyqczwT7G0FPlXnP27UN+WBjA5pOqrgeOeyjVH5hhW6zwNfi7c= Received: from VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) by VI1PR07MB1104.eurprd07.prod.outlook.com (10.163.168.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Tue, 21 Mar 2017 12:24:21 +0000 Received: from VI1PR07MB1102.eurprd07.prod.outlook.com ([10.163.168.26]) by VI1PR07MB1102.eurprd07.prod.outlook.com ([10.163.168.26]) with mapi id 15.01.0991.013; Tue, 21 Mar 2017 12:24:20 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" To: Carsten Bormann CC: "draft-becker-core-coap-sms-gprs@ietf.org" , "core@ietf.org" , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Thread-Topic: [core] Review of draft-becker-core-coap-sms-gprs-06 Thread-Index: AQHSoala56Z3xhAfE0y/2zRBx7lvtKGeG/yAgAEc0gA= Date: Tue, 21 Mar 2017 12:24:20 +0000 Message-ID: <79C355A0-79FE-4D90-9907-11F1A65BB5CD@on.nokia.com> References: <3B156DF2-EC3C-4135-94C1-9D1A4ED686B8@on.nokia.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=nokia.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [81.134.152.4] x-microsoft-exchange-diagnostics: 1; VI1PR07MB1104; 7:vEwi9g2EQxNxGkFW+7QZ4DU3GrmsnKP6pM2o7euxajbYbZxYigR5xAN8Qf8qnyuSR9FiWKBr2RDq2WrSzOGDttzaLN7uRZJgF8wGRBrYVwO/cDxj0rwdWR+4nr7Nc4S2z8Z09SoTUsJ0eCAH4tpzgXiEF2ZYJrrK5RILrcyfpEaB68u6D9Ae9T/ezrRlJ4NPtUda8VH0fTQ9bCWcfJq8PQUa8Vj8pglG8D1izF5l+F0pHxH/PrsCDUEQ8fvafIlFWieYmD8MjouUhIgA/MXiaCjW8CxNDsrWZxxcYqJamG12IPsfooVI8ZtYvAZYsgPWcZy/iFNas4B/1x75ZfBUrA== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39410400002)(39840400002)(39450400003)(39860400002)(24454002)(54906002)(6436002)(99286003)(6512007)(77096006)(6506006)(6486002)(53936002)(25786008)(83716003)(2950100002)(6246003)(66066001)(110136004)(6916009)(107886003)(5660300001)(2900100001)(38730400002)(102836003)(6116002)(3846002)(83506001)(82746002)(229853002)(4326008)(8936002)(81166006)(8676002)(122556002)(189998001)(54356999)(4001350100001)(76176999)(50986999)(305945005)(86362001)(2906002)(7736002)(230783001)(3660700001)(3280700002)(53546009)(33656002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1104; H:VI1PR07MB1102.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: a09968f7-3b28-4cae-0b54-08d4705533c5 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:VI1PR07MB1104; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(20558992708506)(82608151540597); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123558025)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(6072148); SRVR:VI1PR07MB1104; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1104; x-forefront-prvs: 02530BD3AA spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <33973B6EA59E564C99AC0F90CD019DEC@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2017 12:24:20.8184 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1104 Archived-At: Subject: Re: [core] Review of draft-becker-core-coap-sms-gprs-06 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 12:24:27 -0000 SGkgQ2Fyc3RlbiwNCg0KPiBPbiAyMC8wMy8yMDE3IDE5OjI0LCAiQ2Fyc3RlbiBCb3JtYW5uIiA8 Y2Fib0B0emkub3JnPiB3cm90ZToNCj4gPiBPbiAyMCBNYXIgMjAxNywgYXQgMTk6MzksIEZvc3Nh dGksIFRob21hcyAoTm9raWEgLSBHQikgPHRob21hcy5mb3NzYXRpQG5va2lhLmNvbT4gd3JvdGU6 DQo+ID4gDQo+ID4g4oCcWy4uLl0gU2luY2Ugbm90IGFsbCBNU3Mgc3VwcG9ydCA4IGJpdCBzaG9y dCBtZXNzYWdlIGVuY29kaW5nLCB0aGUgcHJlZmVycmVkIGVuY29kaW5nIHNjaGVtZSBmb3IgQ29B UCBtZXNzYWdlcyBvdmVyIFNNUyBpcyB0aGVyZWZvcmUgNyBiaXQsIFvigKZd4oCdDQo+ID4gSSdt IG5vdCBzdXJlIHdlIHNob3VsZCBwcmVmZXIgNy1iaXQgb3ZlciBiaW5hcnkuICBNYXliZSBhIGJl dHRlciBzdHJhdGVneSB3b3VsZCBiZSB0byBzdGFydCBvcHRpbWlzdGljICg4LWJpdCBkYXRhKSBh bmQgZmFsbCBiYWNrIHRvIG9uZSBvZiB0aGUgNy1iaXQgQVNDSUkgZW5jb2RpbmcgdmFyaWFudHMg aWYgdGhhdCBkb2Vzbid0IHdvcmsuICBUaGUgcmVhc29uaW5nIGlzIHRoYXQgaGF2aW5nIDEwLTIw IGJ5dGVzIG1vcmUgaGVyZSBjYW4gbWFrZSBhIHJlYWwgZGlmZmVyZW5jZS4NCj4gDQo+IE9uZSBv ZiB0aGUgNy1iaXQgdmFyaWFudHMgKEFTQ0lJLW9wdGltaXplZCkgbWF5IGFjdHVhbGx5IHVzZSBs ZXNzIHNwYWNlIHRoYW4gdGhlIDgtYml0IHZhcmlhbnRzLCBkZXBlbmRpbmcgb24gdGhlIGRhdGEs IHNvIHRoYXQgbWF5IG5vdCBiZSBhcyBjbGVhci1jdXQuDQoNCkZvciBjaXBoZXItdGV4dCBQRFVz IC0tIGUuZy4sIGlmIHVzaW5nIERUTFMgb3IgT1NDT0FQIC0tIGJpbmFyeSB3b3VsZCBwcm9iYWJs eSBtYWtlIG1vcmUgc2Vuc2UuDQoNCj4gSW4gYW55IGNhc2UsIGEgZGV2aWNlIG9mZmVyaW5nIGFu IFNNUyBVUkkgbmVlZHMgdG8gYmUgYWJsZSB0byBleHByZXNzIHdoZXRoZXIgaXQgY2FuIGFjY2Vw dCA4LWJpdCBTTVMuICBXZSBjdXJyZW50bHkgZG9u4oCZdCBoYXZlIGEgZ29vZCB3YXkgdG8gZXhw cmVzcyB0aGlzIGluIGFuIFNNUyBVUkksIHdoaWNoIHdvdWxkIHByb3ZpZGUgYSBjbGllbnQgdG8g aGludCB0byBnbyB3aXRoLg0KDQpJIGFncmVlIHdpdGggeW91IHRoYXQgZW5jb2Rpbmcgc2hvdWxk IGJlIG1hZGUgdmlzaWJsZSB1cGZyb250IC0tIFJEIC8gbGluay1mb3JtYXQgbG9va2luZyBsaWtl IG9idmlvdXMgY2FuZGlkYXRlcy4gIFRoaXMgaXMgcHJvYmFibHkgcGFydCBvZiB0aGUgd2lkZXIg c3RvcnkgYWJvdXQgZGlzY292ZXJ5LCB3aGljaCBsaWtlbHkgaW5jbHVkZXMgb3RoZXIgZGltZW5z aW9ucywgZS5nLiwgZGUtbXV4aW5nLg0KDQpJZiBub3QgYXZhaWxhYmxlIHVwZnJvbnQsIGEgZGVm YXVsdCBlbmNvZGluZyArIGZhbGxiYWNrIHN0cmF0ZWd5IHNlZW1zIGxpa2UgYW4gYWNjZXB0YWJs ZSBjb21wcm9taXNlIHRvIG1lLiAgKFdlIG5lZWQgdG8gY2hlY2sgd2hldGhlciBTVUJNSVQgJiBT VEFUVVMgcmVwb3J0cyBoYXZlIGFsbCB0aGUgaW5mb3JtYXRpb24gbmVlZGVkIHRvIHRha2UgYW4g aW5mb3JtZWQgZGVjaXNpb24uKQ0KDQo+ID4gV2hlbiB1bnBhY2tpbmcsIGhvdyBpcyB0aGUgcmVj ZWl2ZXIgc3VwcG9zZWQgdG8ga25vdyB3aGljaCBvZiB0aGUgdGhyZWUgZGlmZmVyZW50IGVuY29k aW5ncyAoYjY0LCBiODUgYW5kIEFTQ0lJLW9wdGltaXplZCkgaGFzIGJlZW4gdXNlZCBieSB0aGUg c2VuZGVyPw0KPiANCj4gSSB0aGluayB0aGUgV0cgc2hvdWxkIGRlY2lkZSB0aGF0IGluIHRoZSBz dGFuZGFyZC4NCj4gKEnigJltIG9idmlvdXNseSBiaWFzZWQgdG8gQVNDSUktb3B0aW1pemVkLCBh cyBpdCB3aW5zIG9uIGFsbW9zdCBhbGwgY2hhcmFjdGVyaXN0aWNzLikNCg0KSGFwcHkgdG8gZ28g d2l0aCB0aGF0LiAgKEl0J2QgYmUgbmljZSB0byBjb21wYXJlIHRoZSBlbmNvZGVycyBvbiBhIHJl cHJlc2VudGF0aXZlIENvQVAgY29ycHVzLikNCg0KPiA+ID09IFM2ID09DQo+ID4gSeKAmW0gaGF2 aW5nIGEgYml0IG9mIHRyb3VibGUgd2l0aCB0aGUgbGFzdCBwYXJhOg0KPiA+IOKAnFRvIGFsbG93 IHRoZSBDb0FQIGNsaWVudCB0byBkZXRlY3QgdGhhdCB0aGUgc2hvcnQgbWVzc2FnZSBjb250YWlu cyBhIENvQVAgbWVzc2FnZSwgdGhlIFRQLURBVEEtQ29kaW5nLVNjaGVtZSBTSE9VTEQgYmUgaW5j bHVkZWQu4oCdDQo+ID4gVFAtRENTIGlzIGEgbWFuZGF0b3J5IGZpZWxkIGluIGJvdGggU01TLVNV Qk1JVCBhbmQgU01TLURFTElWRVIgbWVzc2FnZXMsIGhvdyBjYW4gdGhpcyBiZSBhIFNIT1VMRD8g IEFuZDogaG93IERDUyBpcyBzdXBwb3NlZCB0byBhY3QgYXMgYW4gdXBwZXIgbGF5ZXIgcHJvdG9j b2wgaWRlbnRpZmllcj8NCj4gDQo+IERDUyB3aWxsIHRlbGwgeW91IHdoZXRoZXIgdGhlIFNNUyB3 YXMgNy1iaXQgb3IgOC1iaXQuDQoNClN1cmUsIGJ1dCB0aGlzIGlzIGEgYml0IHRvbyBjb2Fyc2Ug Z3JhaW5lZCB0byBhY3QgYXMgYW4gYXBwbGljYXRpb24gcHJvdG9jb2wgaWQuDQoNCj4gVGhlIGJp ZyBpc3N1ZSBpcyBob3cgYSBkZXZpY2UgZmluZHMgb3V0IHRoYXQgdGhpcyB3YXMgYSBDb0FQIFNN UyBpbiB0aGUgZmlyc3QgcGxhY2U7IEnigJltIG5vdCBzdXJlIHdlIGhhdmUgYSB2ZXJ5IGdvb2Qg bXVsdGlwbGV4aW5nIHBvaW50IGZvciB0aGlzLiAgU29tZSBoZXVyaXN0aWNzIG1heSBiZSByZXF1 aXJlZC4NCg0KTXkgcHJlZmVyZW5jZSB3b3VsZCBiZSBleHBsaWNpdCBtdXggc2lnbmFscyBvdmVy IGltcGxpY2l0L2hldXJpc3RpY3MsIGV2ZW4gaWYgdGhhdCBjb3N0cyBhIGZldyBieXRlcy4NCg0K Q2hlZXJzLCB0aGFua3MsDQp0DQoNCg0KDQo= From nobody Tue Mar 21 07:16:15 2017 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 D684712426E for ; Tue, 21 Mar 2017 07:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 rdprTOlU2R7g for ; Tue, 21 Mar 2017 07:16:10 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE229127078 for ; Tue, 21 Mar 2017 07:16:09 -0700 (PDT) X-AuditID: c1b4fb2d-25fff70000005be8-0c-58d135a71cbd Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by (Symantec Mail Security) with SMTP id 55.9E.23528.7A531D85; Tue, 21 Mar 2017 15:16:08 +0100 (CET) Received: from ESESSMB107.ericsson.se ([169.254.7.125]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0319.002; Tue, 21 Mar 2017 15:16:06 +0100 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= To: "core@ietf.org WG" Thread-Topic: [core] CoRE@IETF98 Thread-Index: AQHSncVsG5Atka0aWEGr7GMyT5etwKGfTwyA Date: Tue, 21 Mar 2017 14:16:06 +0000 Message-ID: <578C9D42-3E53-41E3-9345-97104265D326@ericsson.com> References: <7980F62B-A1B5-45C2-871B-B428BEF339BC@tzi.org> In-Reply-To: <7980F62B-A1B5-45C2-871B-B428BEF339BC@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_578C9D423E5341E3934597104265D326ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsUyM2K7qO4K04sRBpN3clocmXKX1WLf2/XM DkweS5b8ZPKYtigzgCmKyyYlNSezLLVI3y6BK6P/80PmgoctTBVnGjaxNTB++svYxcjBISFg IvF1RU0XIxeHkMA6Rom/C2YyQThLGCU2zHsI5HBysAk4S3x61sgOYosIqEm0TnrFBmIzCyhJ HLi2hRlkkLCAvMT124wQJQoS02ZdhSo3kph+ajGYzSKgKtH8rxtsL6+AvcSBB9IgYSEBK4mz 5yBKOAWsJW5fPw+2lVFATOL7qTVMEJvEJW49mQ9mSwgISCzZc54ZwhaVePn4HyuErSSxYvsl Roj6ZInJ+8+zgNi8AoISJ2c+YZnAKDILyahZSMpmISmbBXQds4CmxPpd+hAlihJTuh+yQ9ga Eq1z5kLZ1hLXZr5mR1azgJFjFaNocWpxcW66kbFealFmcnFxfp5eXmrJJkZgrB3c8lt3B+Pq 146HGAU4GJV4eAvenY8QYk0sK67MPcQowcGsJMLr2nchQog3JbGyKrUoP76oNCe1+BCjNAeL kjivwz6glEB6YklqdmpqQWoRTJaJg1OqgZG5w+dizIpM9+STKQ+OB/L5Wc21Y6hc1Ce5pja0 v7pgjdmT+LCm0se8a9SkfxRuEWsyWeoe56J1rPNf9uH17WbOwpesvjonWQvzzmResD9OUnPP /dCFur/Kpx/PruNlj1fPsWzJytb49lTnn012gNqTy5NzTK7u/51YGKrELRDoe2/n3+r9SizF GYmGWsxFxYkAMw+hrbECAAA= Archived-At: Subject: Re: [core] CoRE@IETF98 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 14:16:13 -0000 --_000_578C9D423E5341E3934597104265D326ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpqdXN0IGEgZ2VudGxlIHJlbWluZGVyIHRvIHRoZSBkb2N1bWVudCBhdXRob3Jz IGFib3V0IHRoZSBJRVRGIDk4IGFnZW5kYS4NCg0KSWYgeW91IGhhdmUgbm90IGFscmVhZHksIHBs ZWFzZSBsZXQgdGhlIGNoYWlycyBrbm93IGlmIHlvdSBjYW4gcHJlc2VudCB0aGUgZHJhZnQgdXBk YXRlcyBpbiB0aGUgYWxsb2NhdGVkIHNsb3Qgb3Igbm90LCBzbyB0aGF0IHdlIGNhbiByZXNjaGVk dWxlLg0KDQpUaG9zZSBzdGlsbCBtaXNzaW5nLCB3aWxsIHJlY2VpdmUgYW4gaW5kaXZpZHVhbCBy ZW1pbmRlciBiZWZvcmUgdGhlIGVuZCBvZiB0aGUgd2VlayAgIDopDQoNClRoYW5rcyENCg0KLS0t LS0tLS0tLS0tLS0tICA4PCAtLS0tLS0tLS0tLS0tLS0tLS0NClBSRUxJTUlOQVJZIEFHRU5EQSBJ RVRGIDk4DQoNClRVRVNEQVksIE1hcmNoIDI4LCAyMDE3DQoxMzAw4oCTMTQzMCBBZnRlcm5vb24g U2Vzc2lvbiBJOiBadXJpY2ggQw0KDQpJbnRybyAoMTApDQoNCiAgKiAgIEFnZW5kYSBiYXNoaW5n LCBXRyBzdGF0dXMNCiAgKiAgIE1lbnRpb24gUkZDIDgwNzUsIGRyYWZ0LWlldGYtY29yZS1ldGNo PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNvcmUtZXRjaD4NCg0KUG9z dC1XR0xDICgxNSkNCg0KICAqICAgKGJyaWVmIHVwZGF0ZSkgZHJhZnQtaWV0Zi1jb3JlLWNvYXAt dGNwLXRsczxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3JlLWNvYXAt dGNwLXRscz4g4oCTMDcgMjAxN+KAkzAz4oCTMDYNCiAgKiAgIChyZXN1bHRzIG9mIDJuZCBXR0xD KSBkcmFmdC1pZXRmLWNvcmUtbGlua3MtanNvbjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1jb3JlLWxpbmtzLWpzb24+IOKAkzA3IDIwMTfigJMwM+KAkzEzDQoNCk1heWJl IFdHTEMgKDE1KQ0KDQogICogICAobmV3IGFwcGVuZGl4LCBXR0xDIG5vdz8pIGRyYWZ0LWlldGYt Y29yZS1jb2NvYTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3JlLWNv Y29hPiDigJMwMSAyMDE34oCTMDPigJMxMw0KICAqICAgKGNhbGwgZm9yIHJldmlldykgZHJhZnQt aWV0Zi1jb3JlLXJlc291cmNlLWRpcmVjdG9yeTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1jb3JlLXJlc291cmNlLWRpcmVjdG9yeT4g4oCTMTAgMjAxN+KAkzAz4oCTMTMN Cg0KY29taSAoMjApDQoNCiAgKiAgIERpc2N1c3MgcmVzdWx0cyBmcm9tIE1vbmRheeKAmXMgMTU6 MjAgdG8gMTY6NTAgc2VtaS1mb3JtYWwgQ09NSSBtZWV0aW5nDQoNCk9iamVjdGl2ZTogV2hpY2gg b2YgdGhlc2UgY2FuIHdlIFdHTEMgbm93PyBXaGVyZSBhcmUgd2Ugd2l0aCBpbnN0YWxsaW5nIGEg U0lEIHByb2Nlc3Mgd2l0aCBJQU5BIGFuZCBvdGhlciBhY3RvcnMgbmVlZGVkPyBbU0lEXSBDaGVj ayBzdGF0dXMgb2YgSUFOQSBwcm9jZXNzZXMgKHJlZ2lzdGVyIFNJRHMsIGxvb2t1cCBTSURzKS4N Cg0KICAqICAgZHJhZnQtaWV0Zi1jb3JlLXlhbmctY2JvcjxodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1jb3JlLXlhbmctY2Jvcj4g4oCTMDQgMjAxN+KAkzAy4oCTMDcNCiAg KiAgIGRyYWZ0LWlldGYtY29yZS1jb21pPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLWNvcmUtY29taT4g4oCTMDAgMjAxN+KAkzAx4oCTMjYNCiAgKiAgIGRyYWZ0LWlldGYt Y29yZS1zaWQ8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS1zaWQ+ IOKAkzAwIDIwMTbigJMxMOKAkzI2DQoNCk9iamVjdGl2ZTogd2hhdCBhcmUgdGhlIG5leHQgc3Rl cHM/IChCYXNlZCBvbiByZXN1bHRzIGZyb20gTW9uZGF5OikNCg0KICAqICAgZHJhZnQtdmVpbGxl dHRlLWNvcmUteWFuZy1saWJyYXJ5PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC12 ZWlsbGV0dGUtY29yZS15YW5nLWxpYnJhcnk+IOKAkzAwIDIwMTfigJMwMeKAkzMxDQoNCm9iamVj dCBzZWN1cml0eSAoMzApDQoNCiAgKiAgIFJlcG9ydCBvZiB0aGUgSW50ZXJvcCAoU3VtbWFyeSkN CiAgKiAgIFVwZGF0ZXMgb24gdGhlIGJpZ2dlciBjaGFuZ2VzIG9uIHYg4oCTMDINCiAgKiAgIENv bmZpcm0gcmVzdWx0cyBvZiBpbm5lci1ibG9ja3dpc2UgZGlzY3Vzc2lvbiwgY2YuIGh0dHAtZW5j cnlwdGlvbg0KICAqICAgT2JqZWN0aXZlOiDinpQgbW9yZSBpbnRlcm9wcyArIFdHTEMgYmVmb3Jl IG9yIHJpZ2h0IGFmdGVyIFByYWd1ZS4NCiAgKiAgIGRyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2Vj dXJpdHk8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS1vYmplY3Qt c2VjdXJpdHk+IOKAkzAyIDIwMTfigJMwM+KAkzEzDQoNCldoYXQgZG9lcyB0aGUgV0cgd2FudCB0 byBkbyB3aXRoICh0aGUgc3ViamVjdHMgb2YpIHRoZXNlIGRvY3VtZW50czoNCg0KICAqICAgZHJh ZnQtaGFydGtlLWNvcmUtZTJlLXNlY3VyaXR5LXJlcXM8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWhhcnRrZS1jb3JlLWUyZS1zZWN1cml0eS1yZXFzPiDigJMwMiAyMDE34oCTMDHi gJMwNg0KICAqICAgZHJhZnQtbWF0dHNzb24tY29yZS1zZWN1cml0eS1vdmVyaGVhZDxodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWF0dHNzb24tY29yZS1zZWN1cml0eS1vdmVyaGVh ZD4g4oCTMDAgMjAxN+KAkzAz4oCTMTMNCiAgKiAgIGRyYWZ0LXRpbG9jYS1jb3JlLW11bHRpY2Fz dC1vc2NvYXA8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRpbG9jYS1jb3JlLW11 bHRpY2FzdC1vc2NvYXA+IOKAkzAxIDIwMTfigJMwM+KAkzEzDQoNCs6jIDkwDQoNCg0KDQpGUklE QVksIE1hcmNoIDMxLCAyMDE3DQoxMTUw4oCTMTMyMCBBZnRlcm5vb24gU2Vzc2lvbiBJOiBadXJp Y2ggQw0KSW50cm8gKDUpDQpzcGlsbG92ZXIgZnJvbSBUdWVzZGF5ICgyMCkNCmRhdGEgZm9ybWF0 cyAoMjApDQpPYmplY3RpdmU6IGlzIHRoaXMgbm93IGZpbmFsbHkgcmVhZHkgZm9yIFdHTEM/DQoN CiAgKiAgIGRyYWZ0LWlldGYtY29yZS1zZW5tbDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1jb3JlLXNlbm1sPiDigJMwNSAyMDE34oCTMDPigJMxMw0KDQpPYmplY3RpdmU6 IFNob3VsZCB0aGVzZSBiZSB3b3JrZWQgb24gYnkgdGhlIENvUkUgV0c/DQoNCiAgKiAgIGRyYWZ0 LWdyb3Zlcy1jb3JlLXNlbm1sLWJ0bzxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt Z3JvdmVzLWNvcmUtc2VubWwtYnRvPiDigJMwMCAyMDE24oCTMTDigJMxNw0KICAqICAgZHJhZnQt Z3JvdmVzLWNvcmUtc2VubWwtb3B0aW9uczxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtZ3JvdmVzLWNvcmUtc2VubWwtb3B0aW9ucz4g4oCTMDAgMjAxN+KAkzAz4oCTMTANCg0KV29y a2luZyBvbiBpdCAoMTUpDQoNCiAgKiAgIChqdXN0IGNhbGwgZm9yIHJldmlldykgZHJhZnQtaWV0 Zi1jb3JlLWNvYXAtcHVic3ViPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LWNvcmUtY29hcC1wdWJzdWI+IOKAkzAxIDIwMTfigJMwM+KAkzEzDQogICogICBkcmFmdC1pZXRm LWNvcmUtaW50ZXJmYWNlczxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1j b3JlLWludGVyZmFjZXM+IOKAkzA5IDIwMTfigJMwM+KAkzEzDQogICogICBkcmFmdC1pZXRmLWNv cmUtZHlubGluazxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3JlLWR5 bmxpbms+IOKAkzAzIDIwMTfigJMwM+KAkzEzDQoNClRyYW5zcG9ydHM6IGNhbmRpZGF0ZXMgZm9y IFdHIHdvcmsgKDEwKQ0KDQogICogICAoZ2V0IHJldmlld3MpIGRyYWZ0LWJlY2tlci1jb3JlLWNv YXAtc21zLWdwcnM8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJlY2tlci1jb3Jl LWNvYXAtc21zLWdwcnM+IOKAkzA2IDIwMTfigJMwMuKAkzIwDQoNCk9iamVjdGl2ZTogZGlzY3Vz cyB0aGlzIGluIHRoZSBjb250ZXh0IG9mIHRoZSBub3cgY29tcGxldGVkIGNvYXAtdGNwDQoNCiAg KiAgIGRyYWZ0LXNpbHZlcmFqYW4tY29yZS1jb2FwLXByb3RvY29sLW5lZ290aWF0aW9uPGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zaWx2ZXJhamFuLWNvcmUtY29hcC1wcm90b2Nv bC1uZWdvdGlhdGlvbj4g4oCTMDQgMjAxNuKAkzEw4oCTMzENCg0KTW9yZSBvcGVuIGRpc2N1c3Np b246ICgyMCkNCihHb25nIHNob3cpDQoNCiAgKiAgIGRyYWZ0LWNhby1jb3JlLWRlbGVnYXRlZC1v YnNlcnZlPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jYW8tY29yZS1kZWxlZ2F0 ZWQtb2JzZXJ2ZT4g4oCTMDAgMjAxNuKAkzEw4oCTMjcNCiAgKiAgIGRyYWZ0LWdyb3Zlcy1jb3Jl LW9ic2F0dHI8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdyb3Zlcy1jb3JlLW9i c2F0dHI+IOKAkzAwIDIwMTfigJMwMuKAkzIxDQogICogICBkcmFmdC1ncm92ZXMtY29yZS1iYXM8 aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdyb3Zlcy1jb3JlLWJhcz4g4oCTMDEg MjAxN+KAkzAz4oCTMTMNCiAgKiAgIGRyYWZ0LWdyb3Zlcy1jb3JlLXJmYzY2OTB1cDxodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ3JvdmVzLWNvcmUtcmZjNjY5MHVwPiDigJMwMCAy MDE24oCTMTDigJMxNw0KICAqICAgZHJhZnQtaGFydGtlLWNvcmUtcGVuZGluZzxodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGFydGtlLWNvcmUtcGVuZGluZz4g4oCTMDAgMjAxN+KA kzAy4oCTMjcNCg0KzqMgOTANCg0KDQoNCkNpYW8hDQotIC0gSmFpbWUgSmltw6luZXoNCg0KT24g MTUgTWFyIDIwMTcsIGF0IDIxLjUwLCBDYXJzdGVuIEJvcm1hbm4gPGNhYm9AdHppLm9yZzxtYWls dG86Y2Fib0B0emkub3JnPj4gd3JvdGU6DQoNCldlIGhhdmUgdXBsb2FkZWQgYSAwLjEgZHJhZnQg b2YgdGhlIENvUkUgYWdlbmRhIGZvciBDaGljYWdvIGF0Og0KDQpodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL21lZXRpbmcvOTgvYWdlbmRhL2NvcmUvDQoNCkFzIHVzdWFsLCB0aGlzIGlzIGJh c2VkIG9uIHRoZSBkb2N1bWVudHMgd2UgaGF2ZSBvbiB0aGUgcGxhdGUuDQoNCklmIHlvdSBoYXZl IGEgZG9jdW1lbnQsIHBsZWFzZSBjaGVjayB0aGUgYWJvdmUgYWdlbmRhIHRoYXQgeW91IGhhdmUg YWRlcXVhdGUgdGltZSBhdCB0aGlzIG1lZXRpbmcgdG8gZHJpdmUgeW91ciB3b3JrIGZvcndhcmQu ICBQbGVhc2UgdGVsbCB1cyB3aG8gd2lsbCBiZSBtYW5hZ2luZyB0aGUgc2xvdC4NCihBbmQgc3Rh cnQgbWFraW5nIHNsaWRlc+KApiAgV2XigJlsbCB3YW50IHRoZW0gb24gU2F0dXJkYXksIE1hcmNo IDI1LikNCg0KQW55dGhpbmcgZWxzZSB0aGF0IHNob3VsZCBiZSBvbiB0aGUgYWdlbmRhPw0KDQoo Tm90ZSB0aGF0IHdlIGFyZSBhIGJpdCBjb25zdHJhaW5lZCB3aXRoIGFsbG9jYXRpbmcgdGltZSwg YXMgd2UgYXNrZWQgZm9yIDE4MCBtaW51dGVzIHRvdGFsIG9ubHkgZm9yIENvUkUuICBTbyB0aGVy ZSBpcyBubyBmbGV4dGltZSB0aGlzIHRpbWUsIGp1c3QgYSBsaXR0bGUgYml0IG9mIGJ1ZmZlciBv biBGcmlkYXkgZm9yIHNwaWxsb3ZlciBmcm9tIFR1ZXNkYXkuKQ0KDQpHcsO8w59lLCBDYXJzdGVu DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpjb3Jl IG1haWxpbmcgbGlzdA0KY29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9jb3JlDQoNCg== --_000_578C9D423E5341E3934597104265D326ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGkgYWxsLA0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+anVzdCBhIGdlbnRsZSByZW1p bmRlciB0byB0aGUgZG9jdW1lbnQgYXV0aG9ycyBhYm91dCB0aGUgSUVURiA5OCBhZ2VuZGEuJm5i c3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5JZiB5b3UgaGF2ZSBub3QgYWxyZWFkeSwgcGxlYXNlIGxldCB0aGUgY2hhaXJzIGtub3cg aWYgeW91IGNhbiBwcmVzZW50IHRoZSBkcmFmdCB1cGRhdGVzIGluIHRoZSBhbGxvY2F0ZWQgc2xv dCBvciBub3QsIHNvIHRoYXQgd2UgY2FuIHJlc2NoZWR1bGUuPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaG9zZSBzdGlsbCBtaXNzaW5n LCB3aWxsIHJlY2VpdmUgYW4gaW5kaXZpZHVhbCByZW1pbmRlciBiZWZvcmUgdGhlIGVuZCBvZiB0 aGUgd2VlayAmbmJzcDsgOikgJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGFua3MhPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4tLS0tLS0tLS0tLS0tLS0gJm5ic3A7 OCZsdDsgLS0tLS0tLS0tLS0tLS0tLS0tPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiIGNsYXNzPSIi PlBSRUxJTUlOQVJZIEFHRU5EQSBJRVRGIDk4PC9iPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBw eDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgY29sb3I6IHJnYigxNywgMTcsIDE3KTsiIGNsYXNzPSIi PjxzcGFuIHN0eWxlPSItd2Via2l0LWZvbnQta2VybmluZzogbm9uZTsiIGNsYXNzPSIiPjxiIGNs YXNzPSIiPlRVRVNEQVksIE1hcmNoIDI4LCAyMDE3PC9iPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBjb2xvcjogcmdiKDE3LCAxNywg MTcpOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQta2VybmluZzogbm9uZSIgY2xhc3M9IiI+ MTMwMOKAkzE0MzAgQWZ0ZXJub29uIFNlc3Npb24gSTogWnVyaWNoIEM8L3NwYW4+PC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgY29sb3I6IHJnYigx NywgMTcsIDE3KTsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWtlcm5pbmc6IG5vbmUiIGNs YXNzPSIiPjxiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvYj48L3NwYW4+PC9kaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgY29sb3I6IHJnYigxNywg MTcsIDE3KTsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWtlcm5pbmc6IG5vbmUiIGNsYXNz PSIiPjxiIGNsYXNzPSIiPkludHJvICgxMCk8L2I+PC9zcGFuPjwvZGl2Pg0KPHVsIGNsYXNzPSIi Pg0KPGxpIHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgY29sb3I6IHJn YigxNywgMTcsIDE3KTsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWtlcm5pbmc6IG5vbmUi IGNsYXNzPSIiPkFnZW5kYSBiYXNoaW5nLCBXRyBzdGF0dXM8L3NwYW4+DQo8L2xpPjxsaSBzdHls ZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGNvbG9yOiByZ2IoMTcsIDE3LCAx Nyk7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1rZXJuaW5nOiBub25lIiBjbGFzcz0iIj5N ZW50aW9uIFJGQyA4MDc1LA0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtY29yZS1ldGNoIiBjbGFzcz0iIj48c3BhbiBzdHlsZT0ibGluZS1oZWlnaHQ6IG5v cm1hbDsgLXdlYmtpdC1mb250LWtlcm5pbmc6IG5vbmU7IGNvbG9yOiByZ2IoMTMsIDExMCwgMTYx KTsiIGNsYXNzPSIiPmRyYWZ0LWlldGYtY29yZS1ldGNoPC9zcGFuPjwvYT48L3NwYW4+DQo8L2xp PjwvdWw+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgY29s b3I6IHJnYigxNywgMTcsIDE3KTsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWtlcm5pbmc6 IG5vbmUiIGNsYXNzPSIiPjxiIGNsYXNzPSIiPlBvc3QtV0dMQyAoMTUpPC9iPjwvc3Bhbj48L2Rp dj4NCjx1bCBjbGFzcz0iIj4NCjxsaSBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBu b3JtYWw7IGNvbG9yOiByZ2IoMTcsIDE3LCAxNyk7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9u dC1rZXJuaW5nOiBub25lIiBjbGFzcz0iIj4oYnJpZWYgdXBkYXRlKQ0KPGEgaHJlZj0iaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS1jb2FwLXRjcC10bHMiIGNsYXNz PSIiPjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDogbm9ybWFsOyAtd2Via2l0LWZvbnQta2Vybmlu Zzogbm9uZTsgY29sb3I6IHJnYigxMywgMTEwLCAxNjEpOyIgY2xhc3M9IiI+ZHJhZnQtaWV0Zi1j b3JlLWNvYXAtdGNwLXRsczwvc3Bhbj48L2E+IOKAkzA3IDIwMTfigJMwM+KAkzA2PC9zcGFuPg0K PC9saT48bGkgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBjb2xvcjog cmdiKDE3LCAxNywgMTcpOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQta2VybmluZzogbm9u ZSIgY2xhc3M9IiI+KHJlc3VsdHMgb2YgMm5kIFdHTEMpDQo8YSBocmVmPSJodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3JlLWxpbmtzLWpzb24iIGNsYXNzPSIiPjxzcGFu IHN0eWxlPSJsaW5lLWhlaWdodDogbm9ybWFsOyAtd2Via2l0LWZvbnQta2VybmluZzogbm9uZTsg Y29sb3I6IHJnYigxMywgMTEwLCAxNjEpOyIgY2xhc3M9IiI+ZHJhZnQtaWV0Zi1jb3JlLWxpbmtz LWpzb248L3NwYW4+PC9hPiDigJMwNyAyMDE34oCTMDPigJMxMzwvc3Bhbj4NCjwvbGk+PC91bD4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBjb2xvcjogcmdi KDE3LCAxNywgMTcpOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQta2VybmluZzogbm9uZSIg Y2xhc3M9IiI+PGIgY2xhc3M9IiI+TWF5YmUgV0dMQyAoMTUpPC9iPjwvc3Bhbj48L2Rpdj4NCjx1 bCBjbGFzcz0iIj4NCjxsaSBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7 IGNvbG9yOiByZ2IoMTcsIDE3LCAxNyk7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1rZXJu aW5nOiBub25lIiBjbGFzcz0iIj4obmV3IGFwcGVuZGl4LCBXR0xDIG5vdz8pDQo8YSBocmVmPSJo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3JlLWNvY29hIiBjbGFzcz0i Ij48c3BhbiBzdHlsZT0ibGluZS1oZWlnaHQ6IG5vcm1hbDsgLXdlYmtpdC1mb250LWtlcm5pbmc6 IG5vbmU7IGNvbG9yOiByZ2IoMTMsIDExMCwgMTYxKTsiIGNsYXNzPSIiPmRyYWZ0LWlldGYtY29y ZS1jb2NvYTwvc3Bhbj48L2E+IOKAkzAxIDIwMTfigJMwM+KAkzEzPC9zcGFuPg0KPC9saT48bGkg c3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBjb2xvcjogcmdiKDE3LCAx NywgMTcpOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQta2VybmluZzogbm9uZSIgY2xhc3M9 IiI+KGNhbGwgZm9yIHJldmlldykNCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLWNvcmUtcmVzb3VyY2UtZGlyZWN0b3J5IiBjbGFzcz0iIj4NCjxzcGFuIHN0 eWxlPSJsaW5lLWhlaWdodDogbm9ybWFsOyAtd2Via2l0LWZvbnQta2VybmluZzogbm9uZTsgY29s b3I6IHJnYigxMywgMTEwLCAxNjEpOyIgY2xhc3M9IiI+ZHJhZnQtaWV0Zi1jb3JlLXJlc291cmNl LWRpcmVjdG9yeTwvc3Bhbj48L2E+IOKAkzEwIDIwMTfigJMwM+KAkzEzPC9zcGFuPg0KPC9saT48 L3VsPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGNvbG9y OiByZ2IoMTcsIDE3LCAxNyk7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1rZXJuaW5nOiBu b25lIiBjbGFzcz0iIj48YiBjbGFzcz0iIj5jb21pICgyMCk8L2I+PC9zcGFuPjwvZGl2Pg0KPHVs IGNsYXNzPSIiPg0KPGxpIHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsg Y29sb3I6IHJnYigxNywgMTcsIDE3KTsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWtlcm5p bmc6IG5vbmUiIGNsYXNzPSIiPkRpc2N1c3MgcmVzdWx0cyBmcm9tIE1vbmRheeKAmXMgMTU6MjAg dG8gMTY6NTAgc2VtaS1mb3JtYWwgQ09NSSBtZWV0aW5nPC9zcGFuPg0KPC9saT48L3VsPg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGNvbG9yOiByZ2IoMTcs IDE3LCAxNyk7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1rZXJuaW5nOiBub25lIiBjbGFz cz0iIj5PYmplY3RpdmU6IFdoaWNoIG9mIHRoZXNlIGNhbiB3ZSBXR0xDIG5vdz8gV2hlcmUgYXJl IHdlIHdpdGggaW5zdGFsbGluZyBhIFNJRCBwcm9jZXNzIHdpdGggSUFOQSBhbmQgb3RoZXIgYWN0 b3JzIG5lZWRlZD8gW1NJRF0gQ2hlY2sgc3RhdHVzDQogb2YgSUFOQSBwcm9jZXNzZXMgKHJlZ2lz dGVyIFNJRHMsIGxvb2t1cCBTSURzKS48L3NwYW4+PC9kaXY+DQo8dWwgY2xhc3M9IiI+DQo8bGkg c3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBjb2xvcjogcmdiKDEzLCAx MTAsIDE2MSk7IiBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLWNvcmUteWFuZy1jYm9yIiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1r ZXJuaW5nOiBub25lIiBjbGFzcz0iIj5kcmFmdC1pZXRmLWNvcmUteWFuZy1jYm9yPC9zcGFuPjwv YT48c3BhbiBzdHlsZT0iZm9udC1rZXJuaW5nOiBub25lOyBjb2xvcjogIzExMTExMSIgY2xhc3M9 IiI+IOKAkzA0IDIwMTfigJMwMuKAkzA3PC9zcGFuPg0KPC9saT48bGkgc3R5bGU9Im1hcmdpbjog MHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBjb2xvcjogcmdiKDEzLCAxMTAsIDE2MSk7IiBjbGFz cz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNv cmUtY29taSIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQta2VybmluZzogbm9uZSIgY2xhc3M9 IiI+ZHJhZnQtaWV0Zi1jb3JlLWNvbWk8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LWtlcm5p bmc6IG5vbmU7IGNvbG9yOiAjMTExMTExIiBjbGFzcz0iIj4g4oCTMDAgMjAxN+KAkzAx4oCTMjY8 L3NwYW4+DQo8L2xpPjxsaSBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7 IGNvbG9yOiByZ2IoMTMsIDExMCwgMTYxKTsiIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS1zaWQiIGNsYXNzPSIiPjxzcGFuIHN0 eWxlPSJmb250LWtlcm5pbmc6IG5vbmUiIGNsYXNzPSIiPmRyYWZ0LWlldGYtY29yZS1zaWQ8L3Nw YW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LWtlcm5pbmc6IG5vbmU7IGNvbG9yOiAjMTExMTExIiBj bGFzcz0iIj4g4oCTMDAgMjAxNuKAkzEw4oCTMjY8L3NwYW4+DQo8L2xpPjwvdWw+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgY29sb3I6IHJnYigxNywgMTcs IDE3KTsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWtlcm5pbmc6IG5vbmUiIGNsYXNzPSIi Pk9iamVjdGl2ZTogd2hhdCBhcmUgdGhlIG5leHQgc3RlcHM/IChCYXNlZCBvbiByZXN1bHRzIGZy b20gTW9uZGF5Oik8L3NwYW4+PC9kaXY+DQo8dWwgY2xhc3M9IiI+DQo8bGkgc3R5bGU9Im1hcmdp bjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBjb2xvcjogcmdiKDEzLCAxMTAsIDE2MSk7IiBj bGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC12ZWls bGV0dGUtY29yZS15YW5nLWxpYnJhcnkiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWtlcm5p bmc6IG5vbmUiIGNsYXNzPSIiPmRyYWZ0LXZlaWxsZXR0ZS1jb3JlLXlhbmctbGlicmFyeTwvc3Bh bj48L2E+PHNwYW4gc3R5bGU9ImZvbnQta2VybmluZzogbm9uZTsgY29sb3I6ICMxMTExMTEiIGNs YXNzPSIiPiDigJMwMCAyMDE34oCTMDHigJMzMTwvc3Bhbj4NCjwvbGk+PC91bD4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBjb2xvcjogcmdiKDE3LCAxNywg MTcpOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQta2VybmluZzogbm9uZSIgY2xhc3M9IiI+ PGIgY2xhc3M9IiI+b2JqZWN0IHNlY3VyaXR5ICgzMCk8L2I+PC9zcGFuPjwvZGl2Pg0KPHVsIGNs YXNzPSIiPg0KPGxpIHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgY29s b3I6IHJnYigxNywgMTcsIDE3KTsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWtlcm5pbmc6 IG5vbmUiIGNsYXNzPSIiPlJlcG9ydCBvZiB0aGUgSW50ZXJvcCAoU3VtbWFyeSk8L3NwYW4+DQo8 L2xpPjxsaSBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGNvbG9yOiBy Z2IoMTcsIDE3LCAxNyk7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1rZXJuaW5nOiBub25l IiBjbGFzcz0iIj5VcGRhdGVzIG9uIHRoZSBiaWdnZXIgY2hhbmdlcyBvbiB2IOKAkzAyPC9zcGFu Pg0KPC9saT48bGkgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBjb2xv cjogcmdiKDE3LCAxNywgMTcpOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQta2VybmluZzog bm9uZSIgY2xhc3M9IiI+Q29uZmlybSByZXN1bHRzIG9mIGlubmVyLWJsb2Nrd2lzZSBkaXNjdXNz aW9uLCBjZi4gaHR0cC1lbmNyeXB0aW9uPC9zcGFuPg0KPC9saT48bGkgc3R5bGU9Im1hcmdpbjog MHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBjb2xvcjogcmdiKDE3LCAxNywgMTcpOyIgY2xhc3M9 IiI+PHNwYW4gc3R5bGU9ImZvbnQta2VybmluZzogbm9uZSIgY2xhc3M9IiI+T2JqZWN0aXZlOg0K PC9zcGFuPjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDogbm9ybWFsOyAtd2Via2l0LWZvbnQta2Vy bmluZzogbm9uZTsiIGNsYXNzPSIiPuKelDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1rZXJuaW5n OiBub25lIiBjbGFzcz0iIj4gbW9yZSBpbnRlcm9wcyAmIzQzOyBXR0xDIGJlZm9yZSBvciByaWdo dCBhZnRlciBQcmFndWUuPC9zcGFuPg0KPC9saT48bGkgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5l LWhlaWdodDogbm9ybWFsOyBjb2xvcjogcmdiKDEzLCAxMTAsIDE2MSk7IiBjbGFzcz0iIj4NCjxh IGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNvcmUtb2JqZWN0 LXNlY3VyaXR5IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1rZXJuaW5nOiBub25lIiBjbGFz cz0iIj5kcmFmdC1pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5PC9zcGFuPjwvYT48c3BhbiBzdHls ZT0iZm9udC1rZXJuaW5nOiBub25lOyBjb2xvcjogIzExMTExMSIgY2xhc3M9IiI+IOKAkzAyIDIw MTfigJMwM+KAkzEzPC9zcGFuPg0KPC9saT48L3VsPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7 IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGNvbG9yOiByZ2IoMTcsIDE3LCAxNyk7IiBjbGFzcz0iIj48 c3BhbiBzdHlsZT0iZm9udC1rZXJuaW5nOiBub25lIiBjbGFzcz0iIj5XaGF0IGRvZXMgdGhlIFdH IHdhbnQgdG8gZG8gd2l0aCAodGhlIHN1YmplY3RzIG9mKSB0aGVzZSBkb2N1bWVudHM6PC9zcGFu PjwvZGl2Pg0KPHVsIGNsYXNzPSIiPg0KPGxpIHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWln aHQ6IG5vcm1hbDsgY29sb3I6IHJnYigxMywgMTEwLCAxNjEpOyIgY2xhc3M9IiI+DQo8YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGFydGtlLWNvcmUtZTJlLXNlY3Vy aXR5LXJlcXMiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWtlcm5pbmc6IG5vbmUiIGNsYXNz PSIiPmRyYWZ0LWhhcnRrZS1jb3JlLWUyZS1zZWN1cml0eS1yZXFzPC9zcGFuPjwvYT48c3BhbiBz dHlsZT0iZm9udC1rZXJuaW5nOiBub25lOyBjb2xvcjogIzExMTExMSIgY2xhc3M9IiI+IOKAkzAy IDIwMTfigJMwMeKAkzA2PC9zcGFuPg0KPC9saT48bGkgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5l LWhlaWdodDogbm9ybWFsOyBjb2xvcjogcmdiKDEzLCAxMTAsIDE2MSk7IiBjbGFzcz0iIj4NCjxh IGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tYXR0c3Nvbi1jb3JlLXNl Y3VyaXR5LW92ZXJoZWFkIiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1rZXJuaW5nOiBub25l IiBjbGFzcz0iIj5kcmFmdC1tYXR0c3Nvbi1jb3JlLXNlY3VyaXR5LW92ZXJoZWFkPC9zcGFuPjwv YT48c3BhbiBzdHlsZT0iZm9udC1rZXJuaW5nOiBub25lOyBjb2xvcjogIzExMTExMSIgY2xhc3M9 IiI+IOKAkzAwIDIwMTfigJMwM+KAkzEzPC9zcGFuPg0KPC9saT48bGkgc3R5bGU9Im1hcmdpbjog MHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBjb2xvcjogcmdiKDEzLCAxMTAsIDE2MSk7IiBjbGFz cz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10aWxvY2Et Y29yZS1tdWx0aWNhc3Qtb3Njb2FwIiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1rZXJuaW5n OiBub25lIiBjbGFzcz0iIj5kcmFmdC10aWxvY2EtY29yZS1tdWx0aWNhc3Qtb3Njb2FwPC9zcGFu PjwvYT48c3BhbiBzdHlsZT0iZm9udC1rZXJuaW5nOiBub25lOyBjb2xvcjogIzExMTExMSIgY2xh c3M9IiI+IOKAkzAxIDIwMTfigJMwM+KAkzEzPC9zcGFuPg0KPC9saT48L3VsPg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGNvbG9yOiByZ2IoMTcsIDE3LCAx Nyk7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1rZXJuaW5nOiBub25lIiBjbGFzcz0iIj7O oyA5MDwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDog bm9ybWFsOyBjb2xvcjogcmdiKDE3LCAxNywgMTcpOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZv bnQta2VybmluZzogbm9uZSIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9zcGFuPjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGNvbG9yOiByZ2Io MTcsIDE3LCAxNyk7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1rZXJuaW5nOiBub25lIiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgY29sb3I6IHJnYigxNywgMTcsIDE3KTsiIGNsYXNz PSIiPjxzcGFuIHN0eWxlPSJmb250LWtlcm5pbmc6IG5vbmUiIGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDog bm9ybWFsOyBjb2xvcjogcmdiKDE3LCAxNywgMTcpOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZv bnQta2VybmluZzogbm9uZSIgY2xhc3M9IiI+PGIgY2xhc3M9IiI+RlJJREFZLCBNYXJjaCAzMSwg MjAxNzwvYj48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWln aHQ6IG5vcm1hbDsgY29sb3I6IHJnYigxNywgMTcsIDE3KTsiIGNsYXNzPSIiPjxzcGFuIHN0eWxl PSJmb250LWtlcm5pbmc6IG5vbmUiIGNsYXNzPSIiPjExNTDigJMxMzIwIEFmdGVybm9vbiBTZXNz aW9uIEk6IFp1cmljaCBDPC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGxp bmUtaGVpZ2h0OiBub3JtYWw7IGNvbG9yOiByZ2IoMTcsIDE3LCAxNyk7IiBjbGFzcz0iIj48c3Bh biBzdHlsZT0iZm9udC1rZXJuaW5nOiBub25lIiBjbGFzcz0iIj48YiBjbGFzcz0iIj5JbnRybyAo NSk8L2I+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0 OiBub3JtYWw7IGNvbG9yOiByZ2IoMTcsIDE3LCAxNyk7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0i Zm9udC1rZXJuaW5nOiBub25lIiBjbGFzcz0iIj48YiBjbGFzcz0iIj5zcGlsbG92ZXIgZnJvbSBU dWVzZGF5ICgyMCk8L2I+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGxp bmUtaGVpZ2h0OiBub3JtYWw7IGNvbG9yOiByZ2IoMTcsIDE3LCAxNyk7IiBjbGFzcz0iIj48c3Bh biBzdHlsZT0iZm9udC1rZXJuaW5nOiBub25lIiBjbGFzcz0iIj48YiBjbGFzcz0iIj5kYXRhIGZv cm1hdHMgKDIwKTwvYj48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgbGlu ZS1oZWlnaHQ6IG5vcm1hbDsgY29sb3I6IHJnYigxNywgMTcsIDE3KTsiIGNsYXNzPSIiPjxzcGFu IHN0eWxlPSJmb250LWtlcm5pbmc6IG5vbmUiIGNsYXNzPSIiPk9iamVjdGl2ZTogaXMgdGhpcyBu b3cgZmluYWxseSByZWFkeSBmb3IgV0dMQz88L3NwYW4+PC9kaXY+DQo8dWwgY2xhc3M9IiI+DQo8 bGkgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBjb2xvcjogcmdiKDEz LCAxMTAsIDE2MSk7IiBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLWNvcmUtc2VubWwiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWtl cm5pbmc6IG5vbmUiIGNsYXNzPSIiPmRyYWZ0LWlldGYtY29yZS1zZW5tbDwvc3Bhbj48L2E+PHNw YW4gc3R5bGU9ImZvbnQta2VybmluZzogbm9uZTsgY29sb3I6ICMxMTExMTEiIGNsYXNzPSIiPiDi gJMwNSAyMDE34oCTMDPigJMxMzwvc3Bhbj4NCjwvbGk+PC91bD4NCjxkaXYgc3R5bGU9Im1hcmdp bjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBjb2xvcjogcmdiKDE3LCAxNywgMTcpOyIgY2xh c3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQta2VybmluZzogbm9uZSIgY2xhc3M9IiI+T2JqZWN0aXZl OiBTaG91bGQgdGhlc2UgYmUgd29ya2VkIG9uIGJ5IHRoZSBDb1JFIFdHPzwvc3Bhbj48L2Rpdj4N Cjx1bCBjbGFzcz0iIj4NCjxsaSBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3Jt YWw7IGNvbG9yOiByZ2IoMTMsIDExMCwgMTYxKTsiIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdyb3Zlcy1jb3JlLXNlbm1sLWJ0byIgY2xhc3M9 IiI+PHNwYW4gc3R5bGU9ImZvbnQta2VybmluZzogbm9uZSIgY2xhc3M9IiI+ZHJhZnQtZ3JvdmVz LWNvcmUtc2VubWwtYnRvPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1rZXJuaW5nOiBub25l OyBjb2xvcjogIzExMTExMSIgY2xhc3M9IiI+IOKAkzAwIDIwMTbigJMxMOKAkzE3PC9zcGFuPg0K PC9saT48bGkgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBjb2xvcjog cmdiKDEzLCAxMTAsIDE2MSk7IiBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1ncm92ZXMtY29yZS1zZW5tbC1vcHRpb25zIiBjbGFzcz0iIj48c3Bh biBzdHlsZT0iZm9udC1rZXJuaW5nOiBub25lIiBjbGFzcz0iIj5kcmFmdC1ncm92ZXMtY29yZS1z ZW5tbC1vcHRpb25zPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1rZXJuaW5nOiBub25lOyBj b2xvcjogIzExMTExMSIgY2xhc3M9IiI+IOKAkzAwIDIwMTfigJMwM+KAkzEwPC9zcGFuPg0KPC9s aT48L3VsPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGNv bG9yOiByZ2IoMTcsIDE3LCAxNyk7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1rZXJuaW5n OiBub25lIiBjbGFzcz0iIj48YiBjbGFzcz0iIj5Xb3JraW5nIG9uIGl0ICgxNSk8L2I+PC9zcGFu PjwvZGl2Pg0KPHVsIGNsYXNzPSIiPg0KPGxpIHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWln aHQ6IG5vcm1hbDsgY29sb3I6IHJnYigxNywgMTcsIDE3KTsiIGNsYXNzPSIiPjxzcGFuIHN0eWxl PSJmb250LWtlcm5pbmc6IG5vbmUiIGNsYXNzPSIiPihqdXN0IGNhbGwgZm9yIHJldmlldykNCjxh IGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNvcmUtY29hcC1w dWJzdWIiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDogbm9ybWFsOyAtd2Via2l0 LWZvbnQta2VybmluZzogbm9uZTsgY29sb3I6IHJnYigxMywgMTEwLCAxNjEpOyIgY2xhc3M9IiI+ ZHJhZnQtaWV0Zi1jb3JlLWNvYXAtcHVic3ViPC9zcGFuPjwvYT4g4oCTMDEgMjAxN+KAkzAz4oCT MTM8L3NwYW4+DQo8L2xpPjxsaSBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3Jt YWw7IGNvbG9yOiByZ2IoMTMsIDExMCwgMTYxKTsiIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS1pbnRlcmZhY2VzIiBjbGFzcz0i Ij48c3BhbiBzdHlsZT0iZm9udC1rZXJuaW5nOiBub25lIiBjbGFzcz0iIj5kcmFmdC1pZXRmLWNv cmUtaW50ZXJmYWNlczwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQta2VybmluZzogbm9uZTsg Y29sb3I6ICMxMTExMTEiIGNsYXNzPSIiPiDigJMwOSAyMDE34oCTMDPigJMxMzwvc3Bhbj4NCjwv bGk+PGxpIHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgY29sb3I6IHJn YigxMywgMTEwLCAxNjEpOyIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3JlLWR5bmxpbmsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJm b250LWtlcm5pbmc6IG5vbmUiIGNsYXNzPSIiPmRyYWZ0LWlldGYtY29yZS1keW5saW5rPC9zcGFu PjwvYT48c3BhbiBzdHlsZT0iZm9udC1rZXJuaW5nOiBub25lOyBjb2xvcjogIzExMTExMSIgY2xh c3M9IiI+IOKAkzAzIDIwMTfigJMwM+KAkzEzPC9zcGFuPg0KPC9saT48L3VsPg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGNvbG9yOiByZ2IoMTcsIDE3LCAx Nyk7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1rZXJuaW5nOiBub25lIiBjbGFzcz0iIj48 YiBjbGFzcz0iIj5UcmFuc3BvcnRzOiBjYW5kaWRhdGVzIGZvciBXRyB3b3JrICgxMCk8L2I+PC9z cGFuPjwvZGl2Pg0KPHVsIGNsYXNzPSIiPg0KPGxpIHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1o ZWlnaHQ6IG5vcm1hbDsgY29sb3I6IHJnYigxNywgMTcsIDE3KTsiIGNsYXNzPSIiPjxzcGFuIHN0 eWxlPSJmb250LWtlcm5pbmc6IG5vbmUiIGNsYXNzPSIiPihnZXQgcmV2aWV3cykNCjxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iZWNrZXItY29yZS1jb2FwLXNtcy1n cHJzIiBjbGFzcz0iIj48c3BhbiBzdHlsZT0ibGluZS1oZWlnaHQ6IG5vcm1hbDsgLXdlYmtpdC1m b250LWtlcm5pbmc6IG5vbmU7IGNvbG9yOiByZ2IoMTMsIDExMCwgMTYxKTsiIGNsYXNzPSIiPmRy YWZ0LWJlY2tlci1jb3JlLWNvYXAtc21zLWdwcnM8L3NwYW4+PC9hPiDigJMwNiAyMDE34oCTMDLi gJMyMDwvc3Bhbj4NCjwvbGk+PC91bD4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhl aWdodDogbm9ybWFsOyBjb2xvcjogcmdiKDE3LCAxNywgMTcpOyIgY2xhc3M9IiI+PHNwYW4gc3R5 bGU9ImZvbnQta2VybmluZzogbm9uZSIgY2xhc3M9IiI+T2JqZWN0aXZlOiBkaXNjdXNzIHRoaXMg aW4gdGhlIGNvbnRleHQgb2YgdGhlIG5vdyBjb21wbGV0ZWQgY29hcC10Y3A8L3NwYW4+PC9kaXY+ DQo8dWwgY2xhc3M9IiI+DQo8bGkgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9y bWFsOyBjb2xvcjogcmdiKDEzLCAxMTAsIDE2MSk7IiBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zaWx2ZXJhamFuLWNvcmUtY29hcC1wcm90b2Nv bC1uZWdvdGlhdGlvbiIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQta2VybmluZzogbm9uZSIg Y2xhc3M9IiI+ZHJhZnQtc2lsdmVyYWphbi1jb3JlLWNvYXAtcHJvdG9jb2wtbmVnb3RpYXRpb248 L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LWtlcm5pbmc6IG5vbmU7IGNvbG9yOiAjMTExMTEx IiBjbGFzcz0iIj4g4oCTMDQNCiAyMDE24oCTMTDigJMzMTwvc3Bhbj4gPC9saT48L3VsPg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGNvbG9yOiByZ2IoMTcs IDE3LCAxNyk7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1rZXJuaW5nOiBub25lIiBjbGFz cz0iIj48YiBjbGFzcz0iIj5Nb3JlIG9wZW4gZGlzY3Vzc2lvbjogKDIwKTwvYj48L3NwYW4+PC9k aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgY29sb3I6 IHJnYigxNywgMTcsIDE3KTsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWtlcm5pbmc6IG5v bmUiIGNsYXNzPSIiPihHb25nIHNob3cpPC9zcGFuPjwvZGl2Pg0KPHVsIGNsYXNzPSIiPg0KPGxp IHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgY29sb3I6IHJnYigxMywg MTEwLCAxNjEpOyIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtY2FvLWNvcmUtZGVsZWdhdGVkLW9ic2VydmUiIGNsYXNzPSIiPjxzcGFuIHN0eWxl PSJmb250LWtlcm5pbmc6IG5vbmUiIGNsYXNzPSIiPmRyYWZ0LWNhby1jb3JlLWRlbGVnYXRlZC1v YnNlcnZlPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1rZXJuaW5nOiBub25lOyBjb2xvcjog IzExMTExMSIgY2xhc3M9IiI+IOKAkzAwIDIwMTbigJMxMOKAkzI3PC9zcGFuPg0KPC9saT48bGkg c3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBjb2xvcjogcmdiKDEzLCAx MTAsIDE2MSk7IiBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1ncm92ZXMtY29yZS1vYnNhdHRyIiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1r ZXJuaW5nOiBub25lIiBjbGFzcz0iIj5kcmFmdC1ncm92ZXMtY29yZS1vYnNhdHRyPC9zcGFuPjwv YT48c3BhbiBzdHlsZT0iZm9udC1rZXJuaW5nOiBub25lOyBjb2xvcjogIzExMTExMSIgY2xhc3M9 IiI+IOKAkzAwIDIwMTfigJMwMuKAkzIxPC9zcGFuPg0KPC9saT48bGkgc3R5bGU9Im1hcmdpbjog MHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBjb2xvcjogcmdiKDEzLCAxMTAsIDE2MSk7IiBjbGFz cz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ncm92ZXMt Y29yZS1iYXMiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWtlcm5pbmc6IG5vbmUiIGNsYXNz PSIiPmRyYWZ0LWdyb3Zlcy1jb3JlLWJhczwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQta2Vy bmluZzogbm9uZTsgY29sb3I6ICMxMTExMTEiIGNsYXNzPSIiPiDigJMwMSAyMDE34oCTMDPigJMx Mzwvc3Bhbj4NCjwvbGk+PGxpIHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1h bDsgY29sb3I6IHJnYigxMywgMTEwLCAxNjEpOyIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ3JvdmVzLWNvcmUtcmZjNjY5MHVwIiBjbGFzcz0i Ij48c3BhbiBzdHlsZT0iZm9udC1rZXJuaW5nOiBub25lIiBjbGFzcz0iIj5kcmFmdC1ncm92ZXMt Y29yZS1yZmM2NjkwdXA8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LWtlcm5pbmc6IG5vbmU7 IGNvbG9yOiAjMTExMTExIiBjbGFzcz0iIj4g4oCTMDAgMjAxNuKAkzEw4oCTMTc8L3NwYW4+DQo8 L2xpPjxsaSBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGNvbG9yOiBy Z2IoMTMsIDExMCwgMTYxKTsiIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWhhcnRrZS1jb3JlLXBlbmRpbmciIGNsYXNzPSIiPjxzcGFuIHN0eWxl PSJmb250LWtlcm5pbmc6IG5vbmUiIGNsYXNzPSIiPmRyYWZ0LWhhcnRrZS1jb3JlLXBlbmRpbmc8 L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LWtlcm5pbmc6IG5vbmU7IGNvbG9yOiAjMTExMTEx IiBjbGFzcz0iIj4g4oCTMDAgMjAxN+KAkzAy4oCTMjc8L3NwYW4+DQo8L2xpPjwvdWw+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgY29sb3I6IHJnYigxNywg MTcsIDE3KTsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSItd2Via2l0LWZvbnQta2VybmluZzogbm9u ZTsiIGNsYXNzPSIiPs6jIDkwPC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxz cGFuIHN0eWxlPSJmb250LWtlcm5pbmc6IG5vbmUiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv c3Bhbj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5DaWFvITwvZGl2Pg0K PGRpdiBjbGFzcz0iIj4tIC0gSmFpbWUgSmltw6luZXo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPk9uIDE1IE1hciAyMDE3LCBhdCAyMS41MCwgQ2Fyc3RlbiBCb3JtYW5uICZsdDs8YSBocmVm PSJtYWlsdG86Y2Fib0B0emkub3JnIiBjbGFzcz0iIj5jYWJvQHR6aS5vcmc8L2E+Jmd0OyB3cm90 ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5XZSBoYXZlIHVwbG9hZGVkIGEgMC4xIGRyYWZ0IG9mIHRo ZSBDb1JFIGFnZW5kYSBmb3IgQ2hpY2FnbyBhdDo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvOTgvYWdlbmRh L2NvcmUvIiBjbGFzcz0iIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvOTgv YWdlbmRhL2NvcmUvPC9hPjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkFzIHVzdWFsLCB0 aGlzIGlzIGJhc2VkIG9uIHRoZSBkb2N1bWVudHMgd2UgaGF2ZSBvbiB0aGUgcGxhdGUuPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSWYgeW91IGhhdmUgYSBkb2N1bWVudCwgcGxlYXNlIGNo ZWNrIHRoZSBhYm92ZSBhZ2VuZGEgdGhhdCB5b3UgaGF2ZSBhZGVxdWF0ZSB0aW1lIGF0IHRoaXMg bWVldGluZyB0byBkcml2ZSB5b3VyIHdvcmsgZm9yd2FyZC4gJm5ic3A7UGxlYXNlIHRlbGwgdXMg d2hvIHdpbGwgYmUgbWFuYWdpbmcgdGhlIHNsb3QuPGJyIGNsYXNzPSIiPg0KKEFuZCBzdGFydCBt YWtpbmcgc2xpZGVz4oCmICZuYnNwO1dl4oCZbGwgd2FudCB0aGVtIG9uIFNhdHVyZGF5LCBNYXJj aCAyNS4pPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQW55dGhpbmcgZWxzZSB0aGF0IHNo b3VsZCBiZSBvbiB0aGUgYWdlbmRhPzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCihOb3Rl IHRoYXQgd2UgYXJlIGEgYml0IGNvbnN0cmFpbmVkIHdpdGggYWxsb2NhdGluZyB0aW1lLCBhcyB3 ZSBhc2tlZCBmb3IgMTgwIG1pbnV0ZXMgdG90YWwgb25seSBmb3IgQ29SRS4gJm5ic3A7U28gdGhl cmUgaXMgbm8gZmxleHRpbWUgdGhpcyB0aW1lLCBqdXN0IGEgbGl0dGxlIGJpdCBvZiBidWZmZXIg b24gRnJpZGF5IGZvciBzcGlsbG92ZXIgZnJvbSBUdWVzZGF5Lik8YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpHcsO8w59lLCBDYXJzdGVuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9 IiI+DQpjb3JlIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCmNvcmVAaWV0Zi5vcmc8YnIgY2xh c3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmU8YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_578C9D423E5341E3934597104265D326ericssoncom_-- From nobody Tue Mar 21 10:28:24 2017 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 838BF1294F0; Tue, 21 Mar 2017 10:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MiqF3kk2XwJZ; Tue, 21 Mar 2017 10:28:20 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4464129B88; Tue, 21 Mar 2017 10:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v2LHSGpB016533; Tue, 21 Mar 2017 18:28:16 +0100 (CET) Received: from [10.0.1.13] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vnfsr52J5zDH6W; Tue, 21 Mar 2017 18:28:16 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: <79C355A0-79FE-4D90-9907-11F1A65BB5CD@on.nokia.com> Date: Tue, 21 Mar 2017 18:28:16 +0100 Cc: "draft-becker-core-coap-sms-gprs@ietf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 511810096.147315-d0fac2ec0b406b74ccfa273377290f74 Content-Transfer-Encoding: quoted-printable Message-Id: <1F568F3E-1195-42E5-B953-81C9713C741B@tzi.org> References: <3B156DF2-EC3C-4135-94C1-9D1A4ED686B8@on.nokia.com> <79C355A0-79FE-4D90-9907-11F1A65BB5CD@on.nokia.com> To: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [core] Review of draft-becker-core-coap-sms-gprs-06 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 17:28:22 -0000 Hi Thomas, >> On 20/03/2017 19:24, "Carsten Bormann" wrote: >>> On 20 Mar 2017, at 19:39, Fossati, Thomas (Nokia - GB) = wrote: >>>=20 >>> =E2=80=9C[...] Since not all MSs support 8 bit short message = encoding, the preferred encoding scheme for CoAP messages over SMS is = therefore 7 bit, [=E2=80=A6]=E2=80=9D >>> I'm not sure we should prefer 7-bit over binary. Maybe a better = strategy would be to start optimistic (8-bit data) and fall back to one = of the 7-bit ASCII encoding variants if that doesn't work. The = reasoning is that having 10-20 bytes more here can make a real = difference. >>=20 >> One of the 7-bit variants (ASCII-optimized) may actually use less = space than the 8-bit variants, depending on the data, so that may not be = as clear-cut. >=20 > For cipher-text PDUs -- e.g., if using DTLS or OSCOAP -- binary would = probably make more sense. Yes. (If your platform can do it. Somewhat surprising [to me =E2=80=94 = we used binary SMS in the 1990s already] feedback from implementers = about this was the original reason to do ASCII-optimized.) >> In any case, a device offering an SMS URI needs to be able to express = whether it can accept 8-bit SMS. We currently don=E2=80=99t have a good = way to express this in an SMS URI, which would provide a client to hint = to go with. >=20 > I agree with you that encoding should be made visible upfront -- RD / = link-format looking like obvious candidates. This is probably part of = the wider story about discovery, which likely includes other dimensions, = e.g., de-muxing. >=20 > If not available upfront, a default encoding + fallback strategy seems = like an acceptable compromise to me. (We need to check whether SUBMIT & = STATUS reports have all the information needed to take an informed = decision.) >=20 >>> When unpacking, how is the receiver supposed to know which of the = three different encodings (b64, b85 and ASCII-optimized) has been used = by the sender? >>=20 >> I think the WG should decide that in the standard. >> (I=E2=80=99m obviously biased to ASCII-optimized, as it wins on = almost all characteristics.) >=20 > Happy to go with that. (It'd be nice to compare the encoders on a = representative CoAP corpus.) That would be the right way to make a decision. But note that = ASCII-optimized in its worst case is as good as b64, so you can discard = that if space efficiency is your major concern. B85 is a bit more = likely to occasionally beat ASCII-optimized. Where do we get a good corpus of CoAP messages? >>> =3D=3D S6 =3D=3D >>> I=E2=80=99m having a bit of trouble with the last para: >>> =E2=80=9CTo allow the CoAP client to detect that the short message = contains a CoAP message, the TP-DATA-Coding-Scheme SHOULD be = included.=E2=80=9D >>> TP-DCS is a mandatory field in both SMS-SUBMIT and SMS-DELIVER = messages, how can this be a SHOULD? And: how DCS is supposed to act as = an upper layer protocol identifier? >>=20 >> DCS will tell you whether the SMS was 7-bit or 8-bit. >=20 > Sure, but this is a bit too coarse grained to act as an application = protocol id. Right. >> The big issue is how a device finds out that this was a CoAP SMS in = the first place; I=E2=80=99m not sure we have a very good multiplexing = point for this. Some heuristics may be required. >=20 > My preference would be explicit mux signals over implicit/heuristics, = even if that costs a few bytes. Well, it seems there is no mux point that can be employed here. We = could define magic numbers/signatures (which is a heuristic, but can be = pretty good if done right). Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Mar 21 12:41:58 2017 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 A7B0A128990 for ; Tue, 21 Mar 2017 12:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 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_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-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=zgrp.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 PpQBJTWrhO3m for ; Tue, 21 Mar 2017 12:41:53 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0125.outbound.protection.outlook.com [104.47.0.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CCA512894A for ; Tue, 21 Mar 2017 12:41:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zgrp.onmicrosoft.com; s=selector1-tridonic-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=y53zJjNrMV99alIatjE2uyCipD0d9kN3WwdexIx08pI=; b=JNXMv+ekxdc3FrC3tfulVM12Ts4VYmf4ozBsLoEkCIy3EK3FDlNUIndFgx0OuVCUMZ5hx8qIFxKrBdg6R68nBd4eYDQcrjn2LPqDL5N4M/HPMYPuk4beARp4tXKzgRW2P77ZAvUWqtrR0C46eO4BS6Mbqc6HElSgDU1UljRMtnM= Received: from VI1PR0602MB2830.eurprd06.prod.outlook.com (10.175.22.21) by VI1PR0602MB2829.eurprd06.prod.outlook.com (10.175.22.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Tue, 21 Mar 2017 19:41:48 +0000 Received: from VI1PR0602MB2830.eurprd06.prod.outlook.com ([10.175.22.21]) by VI1PR0602MB2830.eurprd06.prod.outlook.com ([10.175.22.21]) with mapi id 15.01.0947.020; Tue, 21 Mar 2017 19:41:48 +0000 From: Becker Markus To: Carsten Bormann , Lauri Piikivi CC: core Thread-Topic: [core] draft-becker-core-coap-sms-gprs-06: Identifying CoAP PDUs Thread-Index: AdKfKF6McJeHcrn2QxqzT5xlDmZ9AgCIiq6AAAFtFYAASllX0A== Date: Tue, 21 Mar 2017 19:41:47 +0000 Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F77012A8B2BF7@US70UWXCHMBA05.zam.alcatel-lucent.com> <69305B9C-184F-4063-8B86-1929749241DF@arm.com> In-Reply-To: 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=tridonic.com; x-originating-ip: [93.184.187.211] x-ms-office365-filtering-correlation-id: 47dde5f0-6187-4fba-af5b-08d47092506a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:VI1PR0602MB2829; x-microsoft-exchange-diagnostics: 1; VI1PR0602MB2829; 7:/Tu3iRWSVhXGApZtnofRVzJy5bNJptG7c2ORpWDjwcFJP5ykXtJIiEkAnoeIrQFt+Wgg5ThLnWTFJHLgnLzWGUWfR9G0sdVhhUd3JewL9iOs99xjURT9pQ4meTbeTj/36EqLMAF02rvr1gN0LGYO73ow/fDpW+n/Risf1NHzBJEtdBiTAcVnv6uZhAPH23H3nHJHs4f5jaNvPucj0uwqTEs9+5Xux7gdVw8biJny5zV7nN69eY8oF0zsd3RawMW8eXS2s0JVam7CWUpYpsbjPLhDhkG3d2GV35ckft2SJTxQRmpWdFMKgYwyITLg4b2TJiRNqXEgRy6rn3LkjWeMug== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(262304522455115); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123558025)(20161123555025)(20161123560025)(20161123564025)(6072148); SRVR:VI1PR0602MB2829; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0602MB2829; x-forefront-prvs: 02530BD3AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39860400002)(39840400002)(39450400003)(39410400002)(2950100002)(33656002)(86362001)(53936002)(1720100001)(55016002)(99286003)(5660300001)(7696004)(2906002)(74316002)(7736002)(3660700001)(5890100001)(305945005)(25786009)(66066001)(3280700002)(77096006)(6506006)(230783001)(6436002)(122556002)(189998001)(4326008)(53376002)(38730400002)(50986999)(54356999)(76176999)(6306002)(9686003)(102836003)(6116002)(3846002)(8676002)(81166006)(8936002)(229853002)(2900100001)(966004); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0602MB2829; H:VI1PR0602MB2830.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: tridonic.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2017 19:41:47.9775 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8b206608-a593-4ace-a4b6-ef1fc83c9169 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0602MB2829 Archived-At: Subject: Re: [core] draft-becker-core-coap-sms-gprs-06: Identifying CoAP PDUs X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 19:41:56 -0000 SGkuDQoNCj4gPiBUaGUgU01TIGJlYXJlciB3YXMgc3VwcG9ydGVkIGJ5IFdBUCwgd2F5IGJhY2sg 4oCUIGhlc2l0YXRlIHRvIGFkbWl0IHRoYXQNCj4gSSB3b3JrZWQgb24gaXQgOikgIFRoZXJlIHRo ZSBhc3N1bXB0aW9uIHdhcyB0byB1c2UgdGhlIFVzZXItRGF0YS1IZWFkZXIgZm9yDQo+IHBvcnRz IGluZm9ybWF0aW9uLCBhbmQgdGhlIGFzc3VtcHRpb24gd2FzIHRoYXQgOC1iaXQgU01TIGlzIGNv bW1vbnBsYWNlLg0KPg0KPiBPbmUgb2YgdGhlIHRoaW5ncyB0aGF0IGNhbWUgdXAgZHVyaW5nIGRl dmVsb3BtZW50IG9mIHRoaXMgZHJhZnQgaXMgdGhhdCA4LWJpdA0KPiBTTVMgYWN0dWFsbHkgaXMg c2xpZ2h0bHkgbGVzcyBjb21tb24gdGhhbiB3ZSBhc3N1bWVkLiAgSGVuY2UgdGhlIGRpc2N1c3Np b24NCj4gb2YgNy1iaXQgbWFwcGluZ3MuDQoNCkF0IGxlYXN0IGJhY2sgaW4gMjAxNC8xNSB3ZSBo YWQgdHJvdWJsZXMgZG9pbmcgOGJpdCBTTVMgd2l0aCBBbmRyb2lkLiBJdCBzZWVtcyBub3dhZGF5 cyBpdCBzaG91bGQgYmUgcG9zc2libGU6DQoNCmh0dHA6Ly9jb2RldGhlb3J5LmluL2FuZHJvaWQt c21zLw0KDQpodHRwczovL2RldmVsb3Blci5hbmRyb2lkLmNvbS9yZWZlcmVuY2UvYW5kcm9pZC90 ZWxlcGhvbnkvU21zTWFuYWdlci5odG1sI3NlbmREYXRhTWVzc2FnZShqYXZhLmxhbmcuU3RyaW5n LCBqYXZhLmxhbmcuU3RyaW5nLCBzaG9ydCwgYnl0ZVtdLCBhbmRyb2lkLmFwcC5QZW5kaW5nSW50 ZW50LCBhbmRyb2lkLmFwcC5QZW5kaW5nSW50ZW50KQ0KDQpUaGUgQW5kcm9pZCBBUEkgc2VlbXMg dG8gZ2l2ZSBhY2Nlc3MgdG8gdGhlIHBvcnQgKD09cHJvdG9jb2wgaWRlbnRpZmllcj8pOg0Kdm9p ZCBzZW5kRGF0YU1lc3NhZ2UgKFN0cmluZyBkZXN0aW5hdGlvbkFkZHJlc3MsDQogICAgICAgICAg ICAgICAgU3RyaW5nIHNjQWRkcmVzcywNCiAgICAgICAgICAgICAgICBzaG9ydCBkZXN0aW5hdGlv blBvcnQsDQogICAgICAgICAgICAgICAgYnl0ZVtdIGRhdGEsDQogICAgICAgICAgICAgICAgUGVu ZGluZ0ludGVudCBzZW50SW50ZW50LA0KICAgICAgICAgICAgICAgIFBlbmRpbmdJbnRlbnQgZGVs aXZlcnlJbnRlbnQpDQoNCj4gPiBDb3VsZCB0aGUgc3BlYyByZWZlciB0byBXQVAgZGlyZWN0bHk/ DQo+IGh0dHA6Ly93d3cub3Blbm1vYmlsZWFsbGlhbmNlLm9yZy90ZWNoL2FmZmlsaWF0ZXMvd2Fw L3dhcC0yNTktd2RwLQ0KPiAyMDAxMDYxNC1hLnBkZg0KPg0KPiBJZiB3ZSBjYW4gYXZvaWQgdGhh dOKApg0KPg0KPiBJIGRvbuKAmXQgdGhpbmsgaW1wbGVtZW50YXRpb25zIHJpZ2h0IG5vdyBoYXZl IGEgbXVsdGlwbGV4aW5nIHBvaW50IGhlcmUuDQo+IFRoYXQgd291bGQgYmUgbmljZSB0byBoYXZl IHRvIG1ha2UgQ29BUCBvdmVyIFNNUyB1c2FibGUgd2l0aCBkZXZpY2VzIHN1Y2gNCj4gYXMgc21h cnRwaG9uZXMuDQo+IEnigJltIGp1c3Qgbm90IHN1cmUgaG93IHRvIGRvIHRoaXMgaW4gYSB3YXkg dGhhdCBhY2NvbW1vZGF0ZXMgZXhpc3RpbmcNCj4gaW1wbGVtZW50YXRpb25zLg0KPg0KPiBHcsO8 w59lLCBDYXJzdGVuDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IGNvcmUgbWFpbGluZyBsaXN0DQo+IGNvcmVAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBUaGUgY29udGVudHMgb2YgdGhp cyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRl bmRlZCByZWNpcGllbnQuIFRoZXkgbWF5IG5vdCBiZSBkaXNjbG9zZWQgdG8gb3IgdXNlZCBieSBv ciBjb3BpZWQgaW4gYW55IHdheSBieSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVj aXBpZW50LiBJZiB0aGlzIGUtbWFpbCBpcyByZWNlaXZlZCBpbiBlcnJvciwgcGxlYXNlIGltbWVk aWF0ZWx5IG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhlIGUtbWFpbCBhbmQgYXR0YWNo ZWQgZG9jdW1lbnRzLiBQbGVhc2Ugbm90ZSB0aGF0IG5laXRoZXIgdGhlIHNlbmRlciBub3IgdGhl IHNlbmRlcidzIGNvbXBhbnkgYWNjZXB0IGFueSByZXNwb25zaWJpbGl0eSBmb3IgdmlydXNlcyBh bmQgaXQgaXMgeW91ciByZXNwb25zaWJpbGl0eSB0byBzY2FuIG9yIG90aGVyd2lzZSBjaGVjayB0 aGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzLg0K From nobody Tue Mar 21 12:46:22 2017 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 6108B12894A for ; Tue, 21 Mar 2017 12:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-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=zgrp.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 dpMv0lgACaMt for ; Tue, 21 Mar 2017 12:46:18 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0125.outbound.protection.outlook.com [104.47.2.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DB0E128BBB for ; Tue, 21 Mar 2017 12:46:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zgrp.onmicrosoft.com; s=selector1-tridonic-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8Gy2IS0qaUD0wsV2VCQE1cOs8AO1TYiLTSrfN6Mv1tc=; b=VtHjeXjzAXxXpOitqqZ66Ruy6TZBRrBEn0jvR+STilsX56h1Y2KcekhWd48RPvbnAB+lK8mK0HR+GQBtiZln3ZzFY+93ihN2Wdm81QrxEW1AIuVu5GxrdxuDMr7NNzWP28om3zb8xZsuxWxg3mWvDwxS+thl4U7yoNr8mEsKLCY= Received: from VI1PR0602MB2830.eurprd06.prod.outlook.com (10.175.22.21) by VI1PR0602MB2830.eurprd06.prod.outlook.com (10.175.22.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Tue, 21 Mar 2017 19:46:13 +0000 Received: from VI1PR0602MB2830.eurprd06.prod.outlook.com ([10.175.22.21]) by VI1PR0602MB2830.eurprd06.prod.outlook.com ([10.175.22.21]) with mapi id 15.01.0947.020; Tue, 21 Mar 2017 19:46:13 +0000 From: Becker Markus To: "Carey, Timothy (Nokia - US)" , core Thread-Topic: draft-becker-core-coap-sms-gprs-06: Identifying CoAP PDUs Thread-Index: AdKfKF6McJeHcrn2QxqzT5xlDmZ9AgDU0z7A Date: Tue, 21 Mar 2017 19:46:13 +0000 Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F77012A8B2BF7@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A8B2BF7@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=tridonic.com; x-originating-ip: [93.184.187.211] x-ms-office365-filtering-correlation-id: d06f63db-e0b6-455c-9a14-08d47092ee8f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:VI1PR0602MB2830; x-microsoft-exchange-diagnostics: 1; VI1PR0602MB2830; 7:IHs9OX1t2oBiRvWK67iVwOd3KWjAdC8e1yHjRZMtNa0I4XYPnzu6HL7NniHHtwVHIV9EeSkFVCBygfYdjJuQkJj0D4hGdrXYx914kbw0vQCpUY/yLD+at7g4G7twA/GJoE+N55gpeWcteatqLOipT9PplWvqMgLcavXbrszeXuzXZoCMuc+ViBSu6zZ2XRL7jjaGT5ePaBrLy3nbo1QVpqpi3WRDEijWJ4qMzBaZ1cKPnES1KJ2KgMQBpIjVRmjGXZDWc1cpdI6pOO1bB44WEGXMOYP7YeMcMBy31DK+gvSg6FfhGSEuFzGNqOrugEyP9NSa74ni8gXw2MO+z96v1Q== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123555025)(20161123558025)(20161123562025)(20161123564025)(6072148); SRVR:VI1PR0602MB2830; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0602MB2830; x-forefront-prvs: 02530BD3AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39840400002)(39450400003)(39850400002)(39410400002)(51874003)(3660700001)(54896002)(122556002)(50986999)(99286003)(8676002)(66066001)(76176999)(54356999)(9686003)(33656002)(77096006)(6306002)(2900100001)(8936002)(2906002)(7736002)(230783001)(7696004)(5890100001)(189998001)(53936002)(53546009)(3280700002)(6506006)(81166006)(74316002)(790700001)(3846002)(86362001)(102836003)(229853002)(38730400002)(2950100002)(6436002)(6116002)(55016002)(5660300001)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0602MB2830; H:VI1PR0602MB2830.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0602MB283050CC1D7F49E20B2285A5903D0VI1PR0602MB2830_" MIME-Version: 1.0 X-OriginatorOrg: tridonic.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2017 19:46:13.4636 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8b206608-a593-4ace-a4b6-ef1fc83c9169 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0602MB2830 Archived-At: Subject: Re: [core] draft-becker-core-coap-sms-gprs-06: Identifying CoAP PDUs X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 19:46:20 -0000 --_000_VI1PR0602MB283050CC1D7F49E20B2285A5903D0VI1PR0602MB2830_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Timothy. From: core [mailto:core-bounces@ietf.org] On Behalf Of Carey, Timothy (Noki= a - US) Sent: Freitag, 17. M=E4rz 2017 15:26 To: core Subject: [core] draft-becker-core-coap-sms-gprs-06: Identifying CoAP PDUs Hello, How does a device determine from the received SMS PDU that this PDU is a Co= AP message and to which CoAP endpoint the CoAP message should be sent? How about using TP-PID (TP-Protocol-Identifier) for that? Looking at the draft - I can decode the SMS using the TP-DATA-Coding-Scheme but how do I know it's= a CoAP message vs some other PDU. Likewise once I know it's a CoAP message how do I determine the CoAP endpoi= nt if the device supports multiple CoAP endpoints (maybe that is out of sco= pe). Thanks in advance, Tim ________________________________________________________ The contents of th= is e-mail and any attachments are confidential to the intended recipient. T= hey may not be disclosed to or used by or copied in any way by anyone other= than the intended recipient. If this e-mail is received in error, please i= mmediately notify the sender and delete the e-mail and attached documents. = Please note that neither the sender nor the sender's company accept any res= ponsibility for viruses and it is your responsibility to scan or otherwise = check this e-mail and any attachments. --_000_VI1PR0602MB283050CC1D7F49E20B2285A5903D0VI1PR0602MB2830_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Timothy.=

 

From: core [mailto:core-bounces@ietf.org] On Behalf Of Carey, Timothy (Nokia - US)
Sent: Freitag, 17. M=E4rz 2017 15:26
To: core <core@ietf.org>
Subject: [core] draft-becker-core-coap-sms-gprs-06: Identifying CoAP= PDUs

 

Hello,

 

How does a device determine fro= m the received SMS PDU that this PDU is a CoAP message and to which CoAP en= dpoint

the CoAP message should be sent= ?

&n= bsp;

How abo= ut using TP-PID (TP-Protocol-Identifier) for that?

&n= bsp;

Looking at the draft –

I can decode the SMS using the = TP-DATA-Coding-Scheme but how do I know it’s a CoAP message vs some o= ther PDU.

Likewise once I know it’s= a CoAP message how do I determine the CoAP endpoint if the device supports= multiple CoAP endpoints (maybe that is out of scope).

 

Thanks in advance,

Tim

________________________________________________________ The contents of th= is e-mail and any attachments are confidential to the intended recipient. T= hey may not be disclosed to or used by or copied in any way by anyone other= than the intended recipient. If this e-mail is received in error, please immediately notify the sender and= delete the e-mail and attached documents. Please note that neither the sen= der nor the sender's company accept any responsibility for viruses and it i= s your responsibility to scan or otherwise check this e-mail and any attachments. --_000_VI1PR0602MB283050CC1D7F49E20B2285A5903D0VI1PR0602MB2830_-- From nobody Tue Mar 21 12:56:32 2017 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 9819E128D69; Tue, 21 Mar 2017 12:56: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, 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 j13YDz2RJQEY; Tue, 21 Mar 2017 12:56:29 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42740128E19; Tue, 21 Mar 2017 12:56:28 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 0FDC34697C; Tue, 21 Mar 2017 20:56:27 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 144201CF; Tue, 21 Mar 2017 20:56:26 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id CCBC5406; Tue, 21 Mar 2017 20:56:25 +0100 (CET) Received: (nullmailer pid 17242 invoked by uid 1000); Tue, 21 Mar 2017 19:56:24 -0000 Date: Tue, 21 Mar 2017 20:56:24 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: draft-ietf-core-object-security@ietf.org Cc: core@ietf.org Message-ID: <20170321195624.evktq3olnpfugaw7@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="x4xwcuklzcv2a5us" Content-Disposition: inline User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: [core] OSCOAP -02: sequence number reuse? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 19:56:31 -0000 --x4xwcuklzcv2a5us Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello OSCOAP authors, implementing OSCOAP -02, I'm worried about possible reuse of sequence numbers. To make sure I understand things right, I'd like to outline first my understanding of IVs currently specified: * Assume the server has sender ID 01, and the client has sender ID 02. * The server's Sender IV is derived from 01, let's say it is 00010000000000; in analogy, the client's Sender IV is then 00020000000000. * The server's Recipient IV is then 00020000000000, the clients' Recipient IV is 00010000000000. (If I'm completely off by here, please let me know and skip the rest). When the client sends a request with seqno 1, the partial IV it sends is 01, and it uses IV 00020000000001. In the response, the server uses the same sequence number but as a response, and according to 7.3 #3, it uses the IV 80020000000001 (its recipient IV, first bit flipped and request seqno applied). In that process, the server never touches its sequence number counter. When then, much later, the client starts an observation, it might send a request with seqno 257 and IV 00020000000101. The server would, in its response, fall into the second case of 7.3 #3, have its sequence number at 1 and produce 80020000000001 (its recipient IV, first bit flipped, and its own sequence number), which is the very IV we've had before. (Again, if I'm completely off by here, ...). I suppose the whole idea behind using the top-most bit on responses is to partition the available IVs into a half that is self-determined and one that is peer-determined. The idea is valid IMO, provided we stick with "only one sender and one recipient" scenarios. Its execution would need modification, though, unless I got the above wrong. I'd suggest: * The first bit is flipped iff the sequence number of the request gets used (in which case neither server nor client do any checking of the sequence number, as it is as unique as the request's). Whenever a message is sent that carries its own sequence number (either because it is a request or because it is an observe response), its sender uses up a sequence number, its recipient checks the number, and the first bit stays as it is. Furthermore, the use of one's Recipient IV for sending a message worries me: This means that two different base IVs are used with the same key (as long as the server acts as a server, it uses x002000000nnnn, but when it asks back, it uses 0001000000nnnn). That means that the 10000000001(hex)st message the server uses in its role as a client IV-collides with the 1st it uses in an observation. IMO, everyone should still use their Sender IV for sending, and let the first-bit flipping do the partitioning. Hoping you didn't have to skip here from the first "If" Christian --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --x4xwcuklzcv2a5us Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAljRhWUACgkQOY0REtOk veFqvhAAuAeK0LjPZN32S+zSEYm94wOQtV/DdbjBInMnAzw1KaZuM58E75UXj+sG XpTFK+0HVB+/GdP/+5nRYR7W/S/dICFDgRnMx2LCVjYdkIaaRwE2F1Q70qEYFw1W Kv6+uLdF1z9Wa/uiwEh3IkmGSEJRv2MunTYdtkfZK6qh6tJPSWjlGSCRlJNaPbGc U3RTcxqqgEb8DaJO7/kRSoZ/2VfIwpDvt6P4ic89IjaPW31L+pk8byKegJF9ZeTw +LaX3wYIs+k6Ewl5nFdV9ln7Y2IeMgQBKoFHSiUErOzoHEMf3CEg+edPVuoABVxw vThXSmEsLcE59BoVAoemSBYtsZsIUSuTUShXw8QBi1G5LN1eV8G8rLiVnndVhlqM SaL0UXbT5v7G2qFAPcVPf+Sx/G96w6J6WtHcE/ZpvI5RHVPEAW4mkI0C7CjH7pg5 E/edonWawg7Rif583HKYTWv02Aw0GWEdWdeIeBGSMe0gIfd8saGeTlw1hdEpqH// F2nf54wdmx/Is4jmGLEksg8gzQMGVdeUJsN/tXHSTuYBl69uBYgYpfLfIZuGyQ+/ x/4xRv2stJ6bXfQV7A31l9DWoBsjf7HbKlvw3Ucd6vl5x6/ITH2vvQRRyfiIMWLJ EJXbJYohy6tQxrnmggZ1uZtVocKXTivkxLKPuDoIHzlys7mI2N8= =Jquk -----END PGP SIGNATURE----- --x4xwcuklzcv2a5us-- From nobody Wed Mar 22 03:17:10 2017 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 C765F1316C0; Wed, 22 Mar 2017 03:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 UtM8wunCYF-t; Wed, 22 Mar 2017 03:17:06 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47CC11316BB; Wed, 22 Mar 2017 03:17:06 -0700 (PDT) X-AuditID: c1b4fb25-0b71498000002d78-e3-58d24f20ecf4 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by (Symantec Mail Security) with SMTP id DD.BD.11640.02F42D85; Wed, 22 Mar 2017 11:17:04 +0100 (CET) Received: from ESESSMB107.ericsson.se ([169.254.7.125]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0319.002; Wed, 22 Mar 2017 11:17:02 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= , "draft-ietf-core-object-security@ietf.org" CC: "core@ietf.org" Thread-Topic: OSCOAP -02: sequence number reuse? Thread-Index: AQHSon0+sxlfoAOlY0egTMMno4AmbKGgpeuA Date: Wed, 22 Mar 2017 10:17:02 +0000 Message-ID: References: <20170321195624.evktq3olnpfugaw7@hephaistos.amsuess.com> In-Reply-To: <20170321195624.evktq3olnpfugaw7@hephaistos.amsuess.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="utf-8" Content-ID: <34B67E486CDAF34A9C662A71B7831FF7@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsUyM2K7k66C/6UIg53fNC2WX3jOYrHv7Xpm i2n/zrA4MHts3X+XyWPJkp9MAUxRXDYpqTmZZalF+nYJXBn7Dt5gKlikXfHsegdjA+MUrS5G Tg4JAROJ1UdeMHYxcnEICaxjlJi7ZA47hLOEUeJh9z5WkCo2AReJBw2PmEASIgKLGSWeHV3D BJJgFlCWOD77MFiRsIC+xIP125lBbBEBA4m7t1YyQdhGEgefLgKyOThYBFQlJq/mBAnzClhI rJ1+FKxcCGj+y2uLGUFsTgFXicN9m8FsRgExie+nYFaJS9x6Mp8J4moBiSV7zjND2KISLx// AztBVEBPYvnzNVBxRYmdZ9uZQdYyC2hKrN+lDzHGWmL+7GksELaixJTuh+wQ5whKnJz5hGUC o/gsJNtmIXTPQtI9C0n3LCTdCxhZVzGKFqcWJ+WmGxnrpRZlJhcX5+fp5aWWbGIExt3BLb9V dzBefuN4iFGAg1GJh/eD/cUIIdbEsuLK3EOMEhzMSiK80/SBQrwpiZVVqUX58UWlOanFhxil OViUxHkd912IEBJITyxJzU5NLUgtgskycXBKNTCqFH+UPFg98/NpjpthApFL737lND1gqeDy 7dlmFSe260csJP+J2BdknXff5Ghb6izgMm22IGdboDTbUZaZG15vn2xqktSvt61BxPMbj80e WeFdJatPRr3ZN1/bI1f5dIbpA8aJT7fqZLaK+Z3un3Mp6vvWntZkDnsmPrG1orybnWvTJ5p9 ElJiKc5INNRiLipOBADYJ6PEtwIAAA== Archived-At: Subject: Re: [core] OSCOAP -02: sequence number reuse? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 10:17:09 -0000 SGkgQ2hyaXN0aWFuLA0KDQpFeGNlbGxlbnQsIHRoYW5rcyBmb3IgcmVhZGluZyBjYXJlZnVsbHkh IFRoZXJlIGFyZSBpbmRlZWQgdHdvIGVycm9ycyBpbg0KdGhlIHRleHQ6DQoNCi0gQ2xlYXJseSBT ZW5kZXIgSVYgc2hvdWxkIGJlIHVzZWQgd2l0aCBTZW5kZXIga2V5IGluIDcuMyAjMw0KLSBUaGUg cG9pbnQgd2l0aCBmbGlwcGluZyB0aGUgYml0IGlzIHRvIGVuZm9yY2UgZGlzam9pbnQgc2VxdWVu Y2UgbnVtYmVyDQpyYW5nZXMgd2hlbiB1c2luZyB0aGUgc2FtZSBJVi4gVGhlIGludGVuZGVkIGNv bnN0cnVjdGlvbiB3YXMgdGhhdCB0aGUNCnNlcXVlbmNlIG51bWJlciB1c2VkIGJ5IHRoZSBzZW5k ZXIgd291bGQgbm90IGhhdmUgdGhlIGZsaXBwZWQgYml0Lg0KDQpKdWRnaW5nIGJ5IHlvdXIgcHJv cG9zYWwgeW91IGdvdCB0aGUgcG9pbnQgZGVzcGl0ZSB0aGVzZSBlcnJvcnMuIEnigJl2ZQ0KdXBk YXRlZCB0aGUgZHJhZnQsIHBsZWFzZSBjaGVjayBpZiBJIGdvdCBpdCByaWdodDoNCg0KaHR0cHM6 Ly9naXRodWIuY29tL2NvcmUtd2cvb3Njb2FwL2NvbW1pdC9mMzc1ZjRjNjJjYmM4NzM3ZjRhYjkx NjNhODE1OTEyZDdhDQozNjRjYjMNCg0KDQpBcyBhbiBleGVyY2lzZSwgdmVyaWZ5IHRoYXQgdGhp cyBjb25zdHJ1Y3Rpb24gd29ya3MgZXZlbiBpZiBjbGllbnQgYW5kDQpzZXJ2ZXIgY2hhbmdlIHJv bGVzLiBBbmQgYWxzbyB3aXRoIE9ic2VydmUgaW4gdGhhdCBjYXNlLg0KDQoNCkfDtnJhbg0KDQoN Cg0KDQpPbiAyMDE3LTAzLTIxIDIwOjU2LCAiQ2hyaXN0aWFuIEFtc8O8c3MiIDxjLmFtc3Vlc3NA ZW5lcmd5aGFydmVzdGluZy5hdD4NCndyb3RlOg0KDQo+SGVsbG8gT1NDT0FQIGF1dGhvcnMsDQo+ DQo+aW1wbGVtZW50aW5nIE9TQ09BUCAtMDIsIEknbSB3b3JyaWVkIGFib3V0IHBvc3NpYmxlIHJl dXNlIG9mIHNlcXVlbmNlDQo+bnVtYmVycy4gVG8gbWFrZSBzdXJlIEkgdW5kZXJzdGFuZCB0aGlu Z3MgcmlnaHQsIEknZCBsaWtlIHRvIG91dGxpbmUNCj5maXJzdCBteSB1bmRlcnN0YW5kaW5nIG9m IElWcyBjdXJyZW50bHkgc3BlY2lmaWVkOg0KPg0KPiogQXNzdW1lIHRoZSBzZXJ2ZXIgaGFzIHNl bmRlciBJRCAwMSwgYW5kIHRoZSBjbGllbnQgaGFzIHNlbmRlciBJRCAwMi4NCj4qIFRoZSBzZXJ2 ZXIncyBTZW5kZXIgSVYgaXMgZGVyaXZlZCBmcm9tIDAxLCBsZXQncyBzYXkgaXQgaXMNCj4gIDAw MDEwMDAwMDAwMDAwOyBpbiBhbmFsb2d5LCB0aGUgY2xpZW50J3MgU2VuZGVyIElWIGlzIHRoZW4N Cj4gIDAwMDIwMDAwMDAwMDAwLg0KPiogVGhlIHNlcnZlcidzIFJlY2lwaWVudCBJViBpcyB0aGVu IDAwMDIwMDAwMDAwMDAwLCB0aGUgY2xpZW50cycNCj4gIFJlY2lwaWVudCBJViBpcyAwMDAxMDAw MDAwMDAwMC4NCj4NCj4oSWYgSSdtIGNvbXBsZXRlbHkgb2ZmIGJ5IGhlcmUsIHBsZWFzZSBsZXQg bWUga25vdyBhbmQgc2tpcCB0aGUgcmVzdCkuDQo+DQo+V2hlbiB0aGUgY2xpZW50IHNlbmRzIGEg cmVxdWVzdCB3aXRoIHNlcW5vIDEsIHRoZSBwYXJ0aWFsIElWIGl0IHNlbmRzIGlzDQo+MDEsIGFu ZCBpdCB1c2VzIElWIDAwMDIwMDAwMDAwMDAxLiBJbiB0aGUgcmVzcG9uc2UsIHRoZSBzZXJ2ZXIg dXNlcyB0aGUNCj5zYW1lIHNlcXVlbmNlIG51bWJlciBidXQgYXMgYSByZXNwb25zZSwgYW5kIGFj Y29yZGluZyB0byA3LjMgIzMsIGl0IHVzZXMNCj50aGUgSVYgODAwMjAwMDAwMDAwMDEgKGl0cyBy ZWNpcGllbnQgSVYsIGZpcnN0IGJpdCBmbGlwcGVkIGFuZCByZXF1ZXN0DQo+c2Vxbm8gYXBwbGll ZCkuIEluIHRoYXQgcHJvY2VzcywgdGhlIHNlcnZlciBuZXZlciB0b3VjaGVzIGl0cyBzZXF1ZW5j ZQ0KPm51bWJlciBjb3VudGVyLg0KPg0KPldoZW4gdGhlbiwgbXVjaCBsYXRlciwgdGhlIGNsaWVu dCBzdGFydHMgYW4gb2JzZXJ2YXRpb24sIGl0IG1pZ2h0IHNlbmQgYQ0KPnJlcXVlc3Qgd2l0aCBz ZXFubyAyNTcgYW5kIElWIDAwMDIwMDAwMDAwMTAxLiBUaGUgc2VydmVyIHdvdWxkLCBpbiBpdHMN Cj5yZXNwb25zZSwgZmFsbCBpbnRvIHRoZSBzZWNvbmQgY2FzZSBvZiA3LjMgIzMsIGhhdmUgaXRz IHNlcXVlbmNlIG51bWJlcg0KPmF0IDEgYW5kIHByb2R1Y2UgODAwMjAwMDAwMDAwMDEgKGl0cyBy ZWNpcGllbnQgSVYsIGZpcnN0IGJpdCBmbGlwcGVkLA0KPmFuZCBpdHMgb3duIHNlcXVlbmNlIG51 bWJlciksIHdoaWNoIGlzIHRoZSB2ZXJ5IElWIHdlJ3ZlIGhhZCBiZWZvcmUuDQo+DQo+KEFnYWlu LCBpZiBJJ20gY29tcGxldGVseSBvZmYgYnkgaGVyZSwgLi4uKS4NCj4NCj5JIHN1cHBvc2UgdGhl IHdob2xlIGlkZWEgYmVoaW5kIHVzaW5nIHRoZSB0b3AtbW9zdCBiaXQgb24gcmVzcG9uc2VzIGlz DQo+dG8gcGFydGl0aW9uIHRoZSBhdmFpbGFibGUgSVZzIGludG8gYSBoYWxmIHRoYXQgaXMgc2Vs Zi1kZXRlcm1pbmVkIGFuZA0KPm9uZSB0aGF0IGlzIHBlZXItZGV0ZXJtaW5lZC4gVGhlIGlkZWEg aXMgdmFsaWQgSU1PLCBwcm92aWRlZCB3ZSBzdGljaw0KPndpdGggIm9ubHkgb25lIHNlbmRlciBh bmQgb25lIHJlY2lwaWVudCIgc2NlbmFyaW9zLiBJdHMgZXhlY3V0aW9uIHdvdWxkDQo+bmVlZCBt b2RpZmljYXRpb24sIHRob3VnaCwgdW5sZXNzIEkgZ290IHRoZSBhYm92ZSB3cm9uZy4gSSdkIHN1 Z2dlc3Q6DQo+DQo+KiBUaGUgZmlyc3QgYml0IGlzIGZsaXBwZWQgaWZmIHRoZSBzZXF1ZW5jZSBu dW1iZXIgb2YgdGhlIHJlcXVlc3QgZ2V0cw0KPiAgdXNlZCAoaW4gd2hpY2ggY2FzZSBuZWl0aGVy IHNlcnZlciBub3IgY2xpZW50IGRvIGFueSBjaGVja2luZyBvZiB0aGUNCj4gIHNlcXVlbmNlIG51 bWJlciwgYXMgaXQgaXMgYXMgdW5pcXVlIGFzIHRoZSByZXF1ZXN0J3MpLg0KPg0KPiAgV2hlbmV2 ZXIgYSBtZXNzYWdlIGlzIHNlbnQgdGhhdCBjYXJyaWVzIGl0cyBvd24gc2VxdWVuY2UgbnVtYmVy DQo+ICAoZWl0aGVyIGJlY2F1c2UgaXQgaXMgYSByZXF1ZXN0IG9yIGJlY2F1c2UgaXQgaXMgYW4g b2JzZXJ2ZSByZXNwb25zZSksDQo+ICBpdHMgc2VuZGVyIHVzZXMgdXAgYSBzZXF1ZW5jZSBudW1i ZXIsIGl0cyByZWNpcGllbnQgY2hlY2tzIHRoZSBudW1iZXIsDQo+ICBhbmQgdGhlIGZpcnN0IGJp dCBzdGF5cyBhcyBpdCBpcy4NCj4NCj5GdXJ0aGVybW9yZSwgdGhlIHVzZSBvZiBvbmUncyBSZWNp cGllbnQgSVYgZm9yIHNlbmRpbmcgYSBtZXNzYWdlIHdvcnJpZXMNCj5tZTogVGhpcyBtZWFucyB0 aGF0IHR3byBkaWZmZXJlbnQgYmFzZSBJVnMgYXJlIHVzZWQgd2l0aCB0aGUgc2FtZSBrZXkNCj4o YXMgbG9uZyBhcyB0aGUgc2VydmVyIGFjdHMgYXMgYSBzZXJ2ZXIsIGl0IHVzZXMgeDAwMjAwMDAw MG5ubm4sIGJ1dA0KPndoZW4gaXQgYXNrcyBiYWNrLCBpdCB1c2VzIDAwMDEwMDAwMDBubm5uKS4g VGhhdCBtZWFucyB0aGF0IHRoZQ0KPjEwMDAwMDAwMDAxKGhleClzdCBtZXNzYWdlIHRoZSBzZXJ2 ZXIgdXNlcyBpbiBpdHMgcm9sZSBhcyBhIGNsaWVudA0KPklWLWNvbGxpZGVzIHdpdGggdGhlIDFz dCBpdCB1c2VzIGluIGFuIG9ic2VydmF0aW9uLg0KPg0KPklNTywgZXZlcnlvbmUgc2hvdWxkIHN0 aWxsIHVzZSB0aGVpciBTZW5kZXIgSVYgZm9yIHNlbmRpbmcsIGFuZCBsZXQgdGhlDQo+Zmlyc3Qt Yml0IGZsaXBwaW5nIGRvIHRoZSBwYXJ0aXRpb25pbmcuDQo+DQo+DQo+SG9waW5nIHlvdSBkaWRu J3QgaGF2ZSB0byBza2lwIGhlcmUgZnJvbSB0aGUgZmlyc3QgIklmIg0KPkNocmlzdGlhbg0KPg0K Pi0tIA0KPkNocmlzdGlhbiBBbXPDvHNzICAgICAgICAgICAgICAgICAgICAgIHwgRW5lcmd5IEhh cnZlc3RpbmcgU29sdXRpb25zIEdtYkgNCj5mb3VuZGVyLCBzeXN0ZW0gYXJjaGl0ZWN0ICAgICAg ICAgICAgIHwgaGVhZHF1YXJ0ZXI6DQo+bWFpbHRvOmMuYW1zdWVzc0BlbmVyZ3loYXJ2ZXN0aW5n LmF0ICB8IEFyYmVpdGVyZ2Fzc2UgMTUsIEEtNDQwMCBTdGV5cg0KPnRlbDorNDMtNjY0LTk3LTkw LTYtMzkgICAgICAgICAgICAgICAgfCBodHRwOi8vd3d3LmVuZXJneWhhcnZlc3RpbmcuYXQvDQo+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IEFUVTY4NDc2NjE0DQoNCg== From nobody Wed Mar 22 05:44:25 2017 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 87A18129713; Wed, 22 Mar 2017 05:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.698 X-Spam-Level: X-Spam-Status: No, score=-4.698 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=-2.796, SPF_HELO_PASS=-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=nokia.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 8AmVLEq7Uw4D; Wed, 22 Mar 2017 05:44:22 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30108.outbound.protection.outlook.com [40.107.3.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 794B81296D8; Wed, 22 Mar 2017 05:44:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=DMZheohIFkGqdM5rKQLIqUZw30B5z/rm1wd/Ro+dCrA=; b=Npo43DZQh2lwdBEBc7L5yrBolliKblkEHaOGEBcVFAp9yU++raQrK9DbYhjWZ9wo/ZQV8YGzEoECG6gocVZspy1nmiQfeDfR1TfgfEMOyF1FBrZK5Dcv6FgcMUpAICtlt4K//yoxld8qkj3RkVQfBIlPTWsBEWKEM86bL21IlRg= Received: from VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) by VI1PR07MB1104.eurprd07.prod.outlook.com (10.163.168.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Wed, 22 Mar 2017 12:44:18 +0000 Received: from VI1PR07MB1102.eurprd07.prod.outlook.com ([10.163.168.26]) by VI1PR07MB1102.eurprd07.prod.outlook.com ([10.163.168.26]) with mapi id 15.01.0991.013; Wed, 22 Mar 2017 12:44:18 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" To: Carsten Bormann CC: "draft-becker-core-coap-sms-gprs@ietf.org" , "core@ietf.org" , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Thread-Topic: [core] Review of draft-becker-core-coap-sms-gprs-06 Thread-Index: AQHSoala56Z3xhAfE0y/2zRBx7lvtKGeG/yAgAEc0gCAAFTrAIABQv2A Date: Wed, 22 Mar 2017 12:44:18 +0000 Message-ID: References: <3B156DF2-EC3C-4135-94C1-9D1A4ED686B8@on.nokia.com> <79C355A0-79FE-4D90-9907-11F1A65BB5CD@on.nokia.com> <1F568F3E-1195-42E5-B953-81C9713C741B@tzi.org> In-Reply-To: <1F568F3E-1195-42E5-B953-81C9713C741B@tzi.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=nokia.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [81.134.152.4] x-microsoft-exchange-diagnostics: 1; VI1PR07MB1104; 7:8YZCbt8aa4VfoYpz3W60XH5z/0aCzf27yTdOGg6eCnTvz0RSErh9yBcdV6oQHT/o/j4UnOF0CnpIBYDmtfbgIyAryZ8EHoiSzHlLoCLlb5pAFyFIF+9EzDgWM99FgneF+iYtZxT2Kaxcmp5ar1mfPoIYJSu85k5Cy87wQlvq3FhAErIOkkaYPoV0Ko6pRQ6RwbWLp2Q5+DPb9jK+N4IHo0kXTstrTfncosb4pqRCB4DnfsGmzBTDIyEbjrQ3EgtosNrMRNjijIVa9/2JJyG9cgUW+3/N2jWnOp+5cdMFb/JFhBpKGDQ8yA686Y7Xw/GCcvLqKZyZmBH+SmgoX7NfcQ== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39450400003)(39840400002)(39850400002)(39410400002)(24454002)(4001350100001)(50986999)(54356999)(76176999)(305945005)(3660700001)(81166006)(8676002)(189998001)(8936002)(122556002)(93886004)(53546009)(230783001)(3280700002)(2906002)(33656002)(86362001)(7736002)(6246003)(2950100002)(66066001)(6512007)(77096006)(53936002)(6506006)(6486002)(6436002)(83716003)(99286003)(82746002)(4326008)(3846002)(83506001)(6116002)(25786009)(229853002)(102836003)(110136004)(107886003)(38730400002)(6916009)(2900100001)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1104; H:VI1PR07MB1102.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: 218e9a4c-4fd7-4c53-cb2d-08d4712127f5 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:VI1PR07MB1104; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123558025)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(6072148); SRVR:VI1PR07MB1104; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1104; x-forefront-prvs: 02543CD7CD spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <6EA731DBA100F844ABD5B69FC4892886@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2017 12:44:18.2730 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1104 Archived-At: Subject: Re: [core] Review of draft-becker-core-coap-sms-gprs-06 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 12:44:23 -0000 SGkgQ2Fyc3RlbiwNCg0KT24gMjEvMDMvMjAxNyAxNzoyOCwgIkNhcnN0ZW4gQm9ybWFubiIgPGNh Ym9AdHppLm9yZz4gd3JvdGU6DQo+IFdoZXJlIGRvIHdlIGdldCBhIGdvb2QgY29ycHVzIG9mIENv QVAgbWVzc2FnZXM/DQoNClRoYXQncyBhIHZlcnkgZ29vZCBxdWVzdGlvbi4NCkkgd2FzIHRoaW5r aW5nIHRoYXQgbWF5YmUgd2UgY291bGQgc3RhcnQgZnJvbSBwY2FwIGNhcHR1cmVzIHRha2VuIGF0 IEVUU0kgaW50ZXJvcCBldmVudHMuDQpEbyB5b3UgdGhpbmsgaXTigJlkIGJlIGEgcHJvYmxlbSBm cm9tIGEgbGVnYWwgdmlld3BvaW50PyAgT3IgdGhhdCB0aGV5IG1pZ2h0IGJlIG5vdCByZXByZXNl bnRhdGl2ZSBlbm91Z2g/DQoNCkNoZWVycywgdA0KDQo= From nobody Wed Mar 22 05:49:25 2017 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 661ED1297C1; Wed, 22 Mar 2017 05:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MULkLzqe_He2; Wed, 22 Mar 2017 05:49:22 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50B8B1297BC; Wed, 22 Mar 2017 05:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v2MCnHNp003084; Wed, 22 Mar 2017 13:49:17 +0100 (CET) Received: from [192.168.217.124] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vp8dT1M9qzDHRQ; Wed, 22 Mar 2017 13:49:17 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: Date: Wed, 22 Mar 2017 13:49:16 +0100 Cc: "draft-becker-core-coap-sms-gprs@ietf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 511879756.183711-d489ad79ffbd5372e329cbbab2921ee6 Content-Transfer-Encoding: quoted-printable Message-Id: <4FC5F3D6-DE9E-48ED-A509-DCCEC809CF0E@tzi.org> References: <3B156DF2-EC3C-4135-94C1-9D1A4ED686B8@on.nokia.com> <79C355A0-79FE-4D90-9907-11F1A65BB5CD@on.nokia.com> <1F568F3E-1195-42E5-B953-81C9713C741B@tzi.org> To: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [core] Review of draft-becker-core-coap-sms-gprs-06 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 12:49:24 -0000 > On 22 Mar 2017, at 13:44, Fossati, Thomas (Nokia - GB/Cambridge, UK) = wrote: >=20 > Hi Carsten, >=20 > On 21/03/2017 17:28, "Carsten Bormann" wrote: >> Where do we get a good corpus of CoAP messages? >=20 > That's a very good question. > I was thinking that maybe we could start from pcap captures taken at = ETSI interop events. Those would be a faithful mirror of what we wrote in the test = descriptions. (I=E2=80=99m also not aware of anyone keeping a sizable collection of = these.) A better =E2=80=9Ccorpus=E2=80=9D could be had from dreaming up a few = use cases that are likely to use SMS, design exchanges for those, and = capture those on a platform such as coap.me. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Mar 22 08:49:33 2017 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 255DC1299C4; Wed, 22 Mar 2017 08:49:32 -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] 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 pDOOXv5-KlXx; Wed, 22 Mar 2017 08:49:30 -0700 (PDT) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A5E71299D7; Wed, 22 Mar 2017 08:49:29 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 8CE9646988; Wed, 22 Mar 2017 16:49:27 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id AE8EE2A; Wed, 22 Mar 2017 16:49:26 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 77BAF3BE; Wed, 22 Mar 2017 16:49:26 +0100 (CET) Received: (nullmailer pid 24161 invoked by uid 1000); Wed, 22 Mar 2017 15:49:26 -0000 Date: Wed, 22 Mar 2017 16:49:26 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: =?iso-8859-1?Q?G=F6ran?= Selander Cc: "draft-ietf-core-object-security@ietf.org" , draft-tiloca-core-multicast-oscoap@ietf.org, "core@ietf.org" Message-ID: <20170322154925.a2d737yteqfpa5du@hephaistos.amsuess.com> References: <20170321195624.evktq3olnpfugaw7@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="taackkpzdvlphsm2" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [core] OSCOAP -02: sequence number reuse? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 15:49:32 -0000 --taackkpzdvlphsm2 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 22, 2017 at 10:17:02AM +0000, G=C3=B6ran Selander wrote: > Judging by your proposal you got the point despite these errors. I=E2=80= =99ve > updated the draft, please check if I got it right: > > As an exercise, verify that this construction works even if client and > server change roles. And also with Observe in that case. As I read it now, it should work. (Without observe and role reversal, it works in my implementation, the rest is pending but requires some more streamlining in the API). Where I do see trouble coming up is when the multicast proposals get warmed up again. For then, I can envision at least two solutions[1], so I suppose we're good. Best regards Christian [1]: (Diverting this into a footnote so it's on record, even though it's not relevant for this thread itself, but might spin off a new one for multicast:) * Approach A: Unless only one node that is allowed to do requests, all responses must bear a sequence number of their own instead of mirroring. This adds back the sequence numbers to the message length. (As the multicast responses probably need the KID as well, this just means that the compressed responses take the [partIV, kid, ciphertext] form. * Approach B: Allocate not 1 but n "mirror spaces". This would take ceil(log2(n_participants)) bits off the sequence number range, but the responders would then only need to send their KID (sender ID) and the ciphertext. (Basically they'd encode the peer number in reverse bit sequence in the partial IV, where 0 is used for sequence numbers the device has dealt itself, 1 is for sequence numbers out of the list of the first partner (or the unicast partner), and 2 etc is for sequence numbers of other people's pools. --=20 Christian Ams=C3=BCss | Energy Harvesting Solutions Gm= bH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --taackkpzdvlphsm2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAljSnQAACgkQOY0REtOk veGD6Q//YFqeKJiC8mejPwJuVjaP6pFyuRtpceAJCeMb2GPzIi+NU6U50wBVo8fP kBP19i/UWRAMhrpiex65q7nH9fMzgmzVoCQJIde5Sh/vfUMj9+lCC25y1vnexPZM FgEJbI07D0luRjPD8gCaZRALZmGeeqW+UueAdbOpBkDr42sArxOzY0IgtGYUWJtv TZbvI3QS8/GhV43/l4BOJHd8ZryKOKWgzWWy8qkLAMUIZLzbpHLF75zwxuNRXe6K 25RhlfntUGbLKnFP9byb1vs8IU1HFeAFTxKBNq3A7R8vtCXZ48aasuqygB0C6UjW 7BBJCU2haavOMFEL6IWpYpUGxzNzthVeNQzYUq17fwTCF8rShWIio9n1L4jwkQfn c23y3zHV16vq6q+PucRudd7CMZKvEGCbhTDlk1RpjzAc2NQyAgapaLNvf62URE0M 8jbn4LgfGZAiS5nsGpEM9J1NDjvoiy91Wi3tMeEJVGtwZFllU3s5798Atx5zWgiv MYEXhzqk++Rssocxnv/wj7tbf2u3w5ycb5gYLPoVk40ba5C/3d+Ln189cY28/i39 NitdbheqvG2Of7BDcAEe/nGQGtfyIzu1u/cndQ8zkOfa7Gm/m7n0J6or1v6MCTeA doLDBxc51MTXtAzehxYPbV4bPS2jyZSAnKtcUPLRLatZPkKglU8= =v5as -----END PGP SIGNATURE----- --taackkpzdvlphsm2-- From nobody Wed Mar 22 11:47:18 2017 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 579B0129BF3 for ; Wed, 22 Mar 2017 11:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.697 X-Spam-Level: X-Spam-Status: No, score=-4.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, 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 efOXNePqmulo for ; Wed, 22 Mar 2017 11:47:15 -0700 (PDT) Received: from smtp101.iad3a.emailsrvr.com (smtp101.iad3a.emailsrvr.com [173.203.187.101]) (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 1BEEF1294FD for ; Wed, 22 Mar 2017 11:47:15 -0700 (PDT) Received: from smtp29.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp29.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 2110D24F93; Wed, 22 Mar 2017 14:47:14 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp29.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id CD0CA25119; Wed, 22 Mar 2017 14:47:13 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.61] (S01065475d0f7dcd1.cg.shawcable.net [70.75.17.123]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Wed, 22 Mar 2017 14:47:14 -0400 From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 22 Mar 2017 12:47:12 -0600 Message-Id: <0A3A3346-9B5D-48B7-BB52-6DEE39A91200@iii.ca> To: core X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [core] RSSI in SenML X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 18:47:16 -0000 I got a request to add RSSI to the table in 12.1 of of SenML Symbol: RSSI Description: Received signal strength indication Type: float Any comments on this ? From nobody Wed Mar 22 11:50:41 2017 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 D87661294C7 for ; Wed, 22 Mar 2017 11:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=filament-com.20150623.gappssmtp.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 Sy4lXYdW1PHB for ; Wed, 22 Mar 2017 11:50:14 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCB2B1294FD for ; Wed, 22 Mar 2017 11:50:14 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id f84so70077086ioj.0 for ; Wed, 22 Mar 2017 11:50:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=filament-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=N+9JP3JXs707tuZDVexhzqWcxb90x+Er913Ex5gjJg4=; b=bG26B6kcEr+GsbWt3gVOXW7fDDbhbjA2o32TERYSJAJTpi+GY8jDr/i+gaQoU86luU 28m9P0j+fTwQQN+j9NC/ddnMoLYqnbF7pnSjBlh8DQdqVBTvB4JIAK4Bmy+cu4UUKBAG mwL1aOugiKgcUWEsGVRiKfSBPAsshL/EKMTdcLHEz3IQZdHvrKa3BrrJfzC8KEL04t8z opcqNDkm6+D4LEmRKcWMnf1+YHhsi2ysC0s/4Rh2sfeeBEcl4Zvhk31cjTIko2viTGGV V2qouvACQgzvcxYFsjAxmD4SfSFkcHenVZcDo/FBux2brdGGH7qHOXtS2+h70WATCp8q Pl3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=N+9JP3JXs707tuZDVexhzqWcxb90x+Er913Ex5gjJg4=; b=XfNTsEhpDRhb+EmEQo+Iq7rc1D/OsGfY2hoz0zJTsfgdtqnJCw5dREOxEJyoYMaw4J S+Qz/uAecQEofjO/Kyv78+yaWo0cXawOPIijJdVNT3CWvD8Z1wR0wHY75fmibrU/v4vc jHb27l3U7G7FY0o+IBOdBIGCjJBvQL29zEUtQwmieq+BT+XkR0dHMVNJwGPvjQMrjUCf b+Y8AVTLPCsUtQD6P3m5a5Dqc0glaAx/9hBNQ4Yg4u7h9E73LZRjY6bZSry5kzJ1CAKz EmITND9j7XENh/M8oaCB92zmstA5FVkYRNymIWqHNYzQVHc/jB0hIrzvVlFsSGTsj8zK t6bg== X-Gm-Message-State: AFeK/H24ipJ9yzOaOVfsLX03zrSJGANAxpfIZyL/bD9SPJfzOTjlRMErTK4Xvra2TbGj1w== X-Received: by 10.107.131.156 with SMTP id n28mr46241003ioi.39.1490208614149; Wed, 22 Mar 2017 11:50:14 -0700 (PDT) Received: from aither.local (c-98-245-40-52.hsd1.co.comcast.net. [98.245.40.52]) by smtp.gmail.com with ESMTPSA id l5sm521944ita.13.2017.03.22.11.50.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Mar 2017 11:50:13 -0700 (PDT) To: core@ietf.org References: <0A3A3346-9B5D-48B7-BB52-6DEE39A91200@iii.ca> From: Peter Saint-Andre - Filament Message-ID: <0d37d080-9e22-18ca-8468-a1d6b6772e17@filament.com> Date: Wed, 22 Mar 2017 12:50:12 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <0A3A3346-9B5D-48B7-BB52-6DEE39A91200@iii.ca> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [core] RSSI in SenML X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 18:50:22 -0000 On 3/22/17 12:47 PM, Cullen Jennings wrote: > > I got a request to add RSSI to the table in 12.1 of of SenML > > Symbol: RSSI > > Description: Received signal strength indication > > Type: float > > > Any comments on this ? +1, definitely of interest. Peter From nobody Wed Mar 22 11:52:21 2017 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 2C264129B7E for ; Wed, 22 Mar 2017 11:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bc5gh4U9lUzH for ; Wed, 22 Mar 2017 11:52:19 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C94F01294C7 for ; Wed, 22 Mar 2017 11:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v2MIqF8O011152; Wed, 22 Mar 2017 19:52:15 +0100 (CET) Received: from [192.168.217.124] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vpJhH1kDszDHd2; Wed, 22 Mar 2017 19:52:15 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: <0A3A3346-9B5D-48B7-BB52-6DEE39A91200@iii.ca> Date: Wed, 22 Mar 2017 19:52:14 +0100 Cc: core X-Mao-Original-Outgoing-Id: 511901534.48828-4617760abbf218b13ad64691d29fc99d Content-Transfer-Encoding: quoted-printable Message-Id: <41989F03-35A9-4C76-9626-696FE123AFBC@tzi.org> References: <0A3A3346-9B5D-48B7-BB52-6DEE39A91200@iii.ca> To: Cullen Jennings X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [core] RSSI in SenML X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 18:52:20 -0000 > On 22 Mar 2017, at 19:47, Cullen Jennings wrote: >=20 >=20 > I got a request to add RSSI to the table in 12.1 of of SenML=20 >=20 > Symbol: RSSI=20 >=20 > Description: Received signal strength indication >=20 > Type: float=20 RSSI is a quantity (an ill defined one). Table 12.1 is about units. Is there a unit that RSSI tends to use? (For certain Cisco devices, that would be =E2=80=9Cpercent=E2=80=9D. Other devices try to express their signal strength indications in dBm = (typically a negative value approximately from -30 to -120). But I don=E2=80=99t think there is any industry-wide way to do this.) Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Mar 22 11:54:25 2017 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 2FA4912871F for ; Wed, 22 Mar 2017 11:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=filament-com.20150623.gappssmtp.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 xG00PQwgtR2Z for ; Wed, 22 Mar 2017 11:54:21 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (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 DD353127ABE for ; Wed, 22 Mar 2017 11:54:16 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id l7so70104813ioe.3 for ; Wed, 22 Mar 2017 11:54:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=filament-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=lZmT7gNE/EfdBB79WTt1CXK0w+ZjLE1v+M0flw72JSs=; b=rmQGtl8Z6DgrtVl5h3NoiAaeYefp492i+TorpVg3qaNada5/rk5tszK/Ws9qplXDFB qp3cSsBNrBresz+6XvNm816N551y5bSGZoRql/6PMSxHI8EiQctnAi3OC//YL0PessD4 6g6HwBvz41dhiM6MVsGyCGZVzZ5aP6FHjC5SEbQ0lIUAy0H20C1Nfe9SGKyjHcKlAYoQ nBr2SNZLDkZL3lQDoElXaxz1dJibM4TELRL0cP1NBGRPDtlGuWh2I5Qwcl+i9kzAUaLE xAX8diCpMm53SVMRZlO5jUF253mvkjnGQC7rzu/1X8vZexAp0WzHEhefY1JNl3sR0hTk aZBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=lZmT7gNE/EfdBB79WTt1CXK0w+ZjLE1v+M0flw72JSs=; b=aCAWqc4PHeT31ta7tCBrjVxs8FeicKf6U46W7cQ2oASU/B9izCGiV32jMGhvMvFFv4 AHFFCKIFBmlDU6ONpCQA+x3wg0VHNDRX6MEzTIxF2mzq/BhCtYFoXUpqJmF1M4uii4AG AGQTXhw4AvjU+lgujR3cBItKDEXwlieVQD5+nj9kGkD04UcwRdWK83HXosQsQvdaUwxh yd7K7ITgF5lYtlBufLeMUQb5be3w2gixSF3HKeiHwaDOcR4k9Q8u/O1VzynJGsm8NKtA CccLqyfbKldvpHE94GMBuIRyXWdXws5xmT/6am054cWFUMl7dGQqb4GO+ZYRwwyecb97 pmlA== X-Gm-Message-State: AFeK/H20CmAPBQCmdjHpFmhJDPmKX5tLTtBeKjf2pZFjJ4ZgEW/tGIkiXD9t0wg3BiISbA== X-Received: by 10.107.59.86 with SMTP id i83mr36498094ioa.197.1490208856274; Wed, 22 Mar 2017 11:54:16 -0700 (PDT) Received: from aither.local (c-98-245-40-52.hsd1.co.comcast.net. [98.245.40.52]) by smtp.gmail.com with ESMTPSA id y42sm521894ita.26.2017.03.22.11.54.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Mar 2017 11:54:15 -0700 (PDT) To: Carsten Bormann , Cullen Jennings References: <0A3A3346-9B5D-48B7-BB52-6DEE39A91200@iii.ca> <41989F03-35A9-4C76-9626-696FE123AFBC@tzi.org> Cc: core From: Peter Saint-Andre - Filament Message-ID: Date: Wed, 22 Mar 2017 12:54:14 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <41989F03-35A9-4C76-9626-696FE123AFBC@tzi.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [core] RSSI in SenML X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 18:54:23 -0000 On 3/22/17 12:52 PM, Carsten Bormann wrote: > >> On 22 Mar 2017, at 19:47, Cullen Jennings wrote: >> >> >> I got a request to add RSSI to the table in 12.1 of of SenML >> >> Symbol: RSSI >> >> Description: Received signal strength indication >> >> Type: float > > RSSI is a quantity (an ill defined one). > > Table 12.1 is about units. > > Is there a unit that RSSI tends to use? > > (For certain Cisco devices, that would be “percent”. Other devices > try to express their signal strength indications in dBm (typically a > negative value approximately from -30 to -120). dBM is what I've seen. > But I don’t think > there is any industry-wide way to do this.) If you know what device you're getting it from, does it matter that we don't have an industry standard? Peter From nobody Wed Mar 22 11:59:36 2017 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 833EA127BA3 for ; Wed, 22 Mar 2017 11:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ld83uFi28GRC for ; Wed, 22 Mar 2017 11:59:33 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18A211270A3 for ; Wed, 22 Mar 2017 11:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v2MIxTKt016977; Wed, 22 Mar 2017 19:59:29 +0100 (CET) Received: from [192.168.217.124] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vpJrd0kXszDHd6; Wed, 22 Mar 2017 19:59:29 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: Date: Wed, 22 Mar 2017 19:59:28 +0100 Cc: Cullen Jennings , core X-Mao-Original-Outgoing-Id: 511901968.411375-f62acb757ec5d7f06eb9834bdf3bc5f9 Content-Transfer-Encoding: quoted-printable Message-Id: <531986DD-A870-4698-8EF1-D7129F931172@tzi.org> References: <0A3A3346-9B5D-48B7-BB52-6DEE39A91200@iii.ca> <41989F03-35A9-4C76-9626-696FE123AFBC@tzi.org> To: Peter Saint-Andre - Filament X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [core] RSSI in SenML X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 18:59:35 -0000 >=20 > dBM is what I've seen. >=20 >> But I don=E2=80=99t think >> there is any industry-wide way to do this.) >=20 > If you know what device you're getting it from, does it matter that we > don't have an industry standard? As long as you know that you don=E2=80=99t know... Maybe having a unit name for =E2=80=9Cdevice specific RSSI units=E2=80=9D = is fine. Maybe adding dBm ("dB relative to 1 mW") would also not be a bad idea.=20= (We already have dB, but that is a measure of power ratio, not of = power.) Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Mar 22 12:57:16 2017 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 1ED95128BA2 for ; Wed, 22 Mar 2017 12:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xzu9lEFvZSJW for ; Wed, 22 Mar 2017 12:57:12 -0700 (PDT) Received: from smtp117.ord1c.emailsrvr.com (smtp117.ord1c.emailsrvr.com [108.166.43.117]) (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 CC14A1270A0 for ; Wed, 22 Mar 2017 12:57:12 -0700 (PDT) Received: from smtp23.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp23.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 3DE094053E; Wed, 22 Mar 2017 15:57:12 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp23.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id C9CA4404F0; Wed, 22 Mar 2017 15:57:11 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.61] (S01065475d0f7dcd1.cg.shawcable.net [70.75.17.123]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Wed, 22 Mar 2017 15:57:12 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: <41989F03-35A9-4C76-9626-696FE123AFBC@tzi.org> Date: Wed, 22 Mar 2017 13:57:10 -0600 Cc: core Content-Transfer-Encoding: quoted-printable Message-Id: References: <0A3A3346-9B5D-48B7-BB52-6DEE39A91200@iii.ca> <41989F03-35A9-4C76-9626-696FE123AFBC@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [core] RSSI in SenML X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 19:57:14 -0000 > On Mar 22, 2017, at 12:52 PM, Carsten Bormann wrote: >=20 >=20 >> On 22 Mar 2017, at 19:47, Cullen Jennings wrote: >>=20 >>=20 >> I got a request to add RSSI to the table in 12.1 of of SenML=20 >>=20 >> Symbol: RSSI=20 >>=20 >> Description: Received signal strength indication >>=20 >> Type: float=20 >=20 > RSSI is a quantity (an ill defined one). >=20 > Table 12.1 is about units. >=20 > Is there a unit that RSSI tends to use? >=20 > (For certain Cisco devices, that would be =E2=80=9Cpercent=E2=80=9D. Oh, despite what wikipedia claims, Cisco has different systems that = implement pretty much every variant of this you can imagine :-) When you = get down to it RSSI is really more or less defined by device and = software that is loaded on it. I've seen, uh, grade inflation on RSSI on = some devices because a competitors device reported better RSSI in same = conditions. But it is still one of the primary metrics to understand = what is going on with radios.=20 > Other devices try to express their signal strength indications in dBm = (typically a negative value approximately from -30 to -120). > But I don=E2=80=99t think there is any industry-wide way to do this.) >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 From nobody Wed Mar 22 13:05:49 2017 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 44464128DF6 for ; Wed, 22 Mar 2017 13:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=filament-com.20150623.gappssmtp.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 2oqWxahZXq0E for ; Wed, 22 Mar 2017 13:05:46 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (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 880D61277BB for ; Wed, 22 Mar 2017 13:05:46 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id l7so71035702ioe.3 for ; Wed, 22 Mar 2017 13:05:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=filament-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=f6sS117HX6Lw/iK/9WLcTKUvdaFlaMHS4yIP5lcRoGg=; b=wSPrdT+j6hFI+WLYK0XgCMi851uw7bH5jJOyUtGgYfL5hQN0rzbzy84SBelyUbuN1k sgANI/PU0iecXYJ8c++Tsg6XpO2WVuskWhuk138dtTzcp13V3SLd6M1ChFzQ62yamlCP hHB/PliCsvkwUkWwwINGTo4lpQ8oygewsvYonQw7bSk9nopNqhDf0yEvhg7eU1FYcuBP lmyZo/ZM8V3uk6IrEt5g5xYw2UPF7zOASOmPdhd2wV1b+EzJnEpX6XZyxsyaJnUzeIsv l0+ZPvemsEUZk5rz+AsL+5Ool8w2LWGvl9NseoAR8rTjOta7uS8mX+aB0KXj7UPn/Ume +NfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=f6sS117HX6Lw/iK/9WLcTKUvdaFlaMHS4yIP5lcRoGg=; b=DFs7ky6kYMQomio6kBxSe6KjVIAbeubDrnYM3ttRF/hqoc4Dlnwq8XG78RN1kmwBkV 8cIcEhd+jsCguIrRjFAEbXEiD79j5bJ2lyB+7foO+z9krBY+s6UuAsTmTqBZ2dgjp0n3 e8HqoM8cRzaLn7KWWwuUr4NDDjNdor/PaRQ4aBxqsxJec4iGyDTsXBSgnDzFhiZE01YG D9F0qSzvxuhkjiqby4CUihbnxIKiiIh66zYHmaawCuo/mJl86Rvnixwhi/6r2T82Acxg mtYYn+Myzh8OAv2AXpUJTWqMDDpl58k7aJY2AmiKaUKKXYlqIdX3ucX2Ak05ICdNFr0i lxjg== X-Gm-Message-State: AFeK/H1Iq8YH0D3IwcStIDt1bB6oeIukjBnrqPiNbrpcZc8g6AZVUvdPpGfbVgy7PupWPw== X-Received: by 10.107.32.83 with SMTP id g80mr37086121iog.234.1490213145851; Wed, 22 Mar 2017 13:05:45 -0700 (PDT) Received: from aither.local (c-98-245-40-52.hsd1.co.comcast.net. [98.245.40.52]) by smtp.gmail.com with ESMTPSA id l33sm1289586iod.8.2017.03.22.13.05.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Mar 2017 13:05:45 -0700 (PDT) To: Carsten Bormann References: <0A3A3346-9B5D-48B7-BB52-6DEE39A91200@iii.ca> <41989F03-35A9-4C76-9626-696FE123AFBC@tzi.org> <531986DD-A870-4698-8EF1-D7129F931172@tzi.org> Cc: Cullen Jennings , core From: Peter Saint-Andre - Filament Message-ID: <0089bebc-0c11-155b-5a3e-4a9e99acb9bc@filament.com> Date: Wed, 22 Mar 2017 14:05:44 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <531986DD-A870-4698-8EF1-D7129F931172@tzi.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [core] RSSI in SenML X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 20:05:49 -0000 On 3/22/17 12:59 PM, Carsten Bormann wrote: >> >> dBM is what I've seen. >> >>> But I don’t think >>> there is any industry-wide way to do this.) >> >> If you know what device you're getting it from, does it matter that we >> don't have an industry standard? > > As long as you know that you don’t know... Exactly. > Maybe having a unit name for “device specific RSSI units” is fine. > > Maybe adding dBm ("dB relative to 1 mW") would also not be a bad idea. WFM. Peter From nobody Wed Mar 22 13:15:56 2017 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 D536E129AA2 for ; Wed, 22 Mar 2017 13:15:54 -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] 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 d24E0jFOAnUw for ; Wed, 22 Mar 2017 13:15:51 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE1521292D3 for ; Wed, 22 Mar 2017 13:15:51 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id A820A46988; Wed, 22 Mar 2017 21:15:49 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id E7C191CB; Wed, 22 Mar 2017 21:15:48 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id C0C71406; Wed, 22 Mar 2017 21:15:48 +0100 (CET) Received: (nullmailer pid 11599 invoked by uid 1000); Wed, 22 Mar 2017 20:15:47 -0000 Date: Wed, 22 Mar 2017 21:15:47 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Cullen Jennings Cc: core@ietf.org Message-ID: <20170322201547.wsglwbeodagbotvq@hephaistos.amsuess.com> References: <0A3A3346-9B5D-48B7-BB52-6DEE39A91200@iii.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xw3iv2isk2kfus44" Content-Disposition: inline In-Reply-To: <0A3A3346-9B5D-48B7-BB52-6DEE39A91200@iii.ca> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [core] RSSI in SenML X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 20:15:55 -0000 --xw3iv2isk2kfus44 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 22, 2017 at 12:47:12PM -0600, Cullen Jennings wrote: > I got a request to add RSSI to the table in 12.1 of of SenML=20 >=20 > Symbol: RSSI=20 >=20 > Description: Received signal strength indication >=20 > Type: float=20 I've been using signal strengths for some time in SenML, and they were in those applications provided in dBm, which I converted according to what the spec says (or rather said back then, this has been operational since 2014) about falling back to UCUM as UCUM:B[W]. The recommendations w/rt UCUM have been demoted since then, but it is still common in the other units there to be specific and comparable (dB being the exception). RSSI with any real unit would not have any meaning outside of that device's receptor, and could just as well be represented without any unit. I'd support adding something that has the semantic meaning of received signal strength (dBm would be more common than the by-the-letters-of-UCUM B[W] unit), but a plain RSSI would IMO lead to confusion in any inhomogenous setup. Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --xw3iv2isk2kfus44 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAljS228ACgkQOY0REtOk veF4rxAAv/EhI2kAA3n73Y0S/94LrgmygpAyLJwcf+U9XLnpSkGv/6qtkCnWbh0H 5STitDgvf/IqvqpGfxQbqjB+I7D1giwPFZ6tzAR0za0SHQJg6fRUSnAfmMvIHsD8 yqHKwcNInxjcL7d/FWutDL+89iDXSuhzn+/x7AUu8JrakYQURk6BgOqv0FPwAMLu uZJv7EaT71Ar6L3tn4wysGadWoARcpJGw/mEJUoQhrnpBPQIN3N4XIQ4w7/MbVP5 ueQ08Z7Hpehri0vUAl23JQ4tpiWM8fdj2AM1gf5/okUCsRUAyU31gm0yw35hAgps wTv9AO4vkN16au/atklMU6MKTn+hP3FkHLdW672lj5OuaHU/x2nXohrB6ca0sf5C kIIUEzWVfCdqisW1tV9++Dn3Fwq4yXZ3NaF67laTIin4kP2EfpYgpoGuTPiSbX2i 97CkRT76ioaZfj6NlEbaKDKkPmamWtIbgdNeZLdsuFhmg3uUzS9gRbbHYnU/bIMm d7N7czMxuKCHLAn8zEHa2mfr0gFhiW9r1d2DKCL6krQWl6c6YxIYDPPMRqmSV4Ae /sU7Kw1ChMBIdIgWX/Bj2EhPH6bPHpEmU91GzRkao5WQlauy8Q+RKjDX0NI3ggNh OwafHejibhLjh1p1FblHLicx4Fvf8i7kkeMqptKxF60enK2/DoM= =pLw7 -----END PGP SIGNATURE----- --xw3iv2isk2kfus44-- From nobody Wed Mar 22 13:30:04 2017 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 8E6AC128BB6 for ; Wed, 22 Mar 2017 13:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mydevices.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 7UHvKFwiuiOU for ; Wed, 22 Mar 2017 13:30:01 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::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 1B9A3128B38 for ; Wed, 22 Mar 2017 13:30:01 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id i34so161145027qtc.0 for ; Wed, 22 Mar 2017 13:30:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mydevices.com; s=mydevices; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=wUYwleTXVq1sYleKtcoil27U4aQFrjAAuWUeqpTnlWQ=; b=VpPPYMGtMnLctFFiXEmW4ODpTSSNcFPhQ0DE6kGniIeWzDEpxIQGYiBkKtaNhMl1i0 adNejzqdy/uYKZhH05f7CJMgpw0I2jNlfSbRv4FvzdXMjLDb+tTf6mWeV4LEdPuFCzTE yybmaBxyzM+x/Y05aWQob/0+ul569ACMxJ7Gs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=wUYwleTXVq1sYleKtcoil27U4aQFrjAAuWUeqpTnlWQ=; b=CPjcXEd7Fn3jaa+CatlDc+3XMZNC3IMvLelMvudPjV8dtmF8zMylPhv0ayJPnMu8SP s4mO1/PjhdHxEv3cvTBhsvCpdElXiysD2KBdnnbAU8FGtZ2aay96xshzpjwnq1QfTDCL ovsbcwOVuNvB+cAhe9tSCjXAa1Z8j+CmGY2N51cefc7Zd0Mro4oBSFmhjqhYMZdD40ql b5GdH+Y6W+LZkrZl08Ojtfmws1+U00OAmBT5OyM4prULbQwdENKEBJ/42uK8b4II3S8E UTA6/Oh3wnymxT1qwnyaa6GG7CwXDB98OrGalRSqIHWCYAvVsPvNL5moFuGrFzRrZ4AY 7+yA== X-Gm-Message-State: AFeK/H1I2Kg5CahKbNEtIzIzIoyxt8oUOqgc8R+2uGo8GrMFwiwOdpmmN9lVlKTpqzMcZutXgNIploYT//J/KheG X-Received: by 10.200.47.75 with SMTP id k11mr42001039qta.153.1490214599885; Wed, 22 Mar 2017 13:29:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.103.235 with HTTP; Wed, 22 Mar 2017 13:29:59 -0700 (PDT) In-Reply-To: <20170322201547.wsglwbeodagbotvq@hephaistos.amsuess.com> References: <0A3A3346-9B5D-48B7-BB52-6DEE39A91200@iii.ca> <20170322201547.wsglwbeodagbotvq@hephaistos.amsuess.com> From: Eric Ptak Date: Wed, 22 Mar 2017 21:29:59 +0100 Message-ID: To: core@ietf.org Content-Type: multipart/alternative; boundary=001a11467050ddc121054b579fdd Archived-At: Subject: Re: [core] RSSI in SenML X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 20:30:04 -0000 --001a11467050ddc121054b579fdd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Giving a meaning (good, medium, bad reception) to a RSSI value really depends on the radio frequency and modulation used, say the protocol= . Zigbee, Bluetooth, WiFi, GSM, LoRa ... all have different range where the signal is good or bad. It also depends on the internal hardware design. dBm looks to be the standard unit for a RSSI value. Up to the application layer to provide or not a meaning that depends on the device and the use case. Finally Signal quality also depends on the SNR, Signal-to-Noise ratio. Best, Eric. On Wed, Mar 22, 2017 at 9:15 PM, Christian Ams=C3=BCss < c.amsuess@energyharvesting.at> wrote: > On Wed, Mar 22, 2017 at 12:47:12PM -0600, Cullen Jennings wrote: > > I got a request to add RSSI to the table in 12.1 of of SenML > > > > Symbol: RSSI > > > > Description: Received signal strength indication > > > > Type: float > > I've been using signal strengths for some time in SenML, and they were > in those applications provided in dBm, which I converted according to > what the spec says (or rather said back then, this has been operational > since 2014) about falling back to UCUM as UCUM:B[W]. > > The recommendations w/rt UCUM have been demoted since then, but it is > still common in the other units there to be specific and comparable (dB > being the exception). RSSI with any real unit would not have any meaning > outside of that device's receptor, and could just as well be represented > without any unit. I'd support adding something that has the semantic > meaning of received signal strength (dBm would be more common than the > by-the-letters-of-UCUM B[W] unit), but a plain RSSI would IMO lead to > confusion in any inhomogenous setup. > > Best regards > Christian > > -- > To use raw power is to make yourself infinitely vulnerable to greater > powers. > -- Bene Gesserit axiom > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > --001a11467050ddc121054b579fdd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,
Giving a meaning (good, medium, bad receptio= n) to a RSSI value
really depends on the radio frequency and modulation= used, say the protocol.
Zigbee, Bluetooth, WiFi, GSM, LoRa ... all hav= e different range where the signal is good or bad.
It also de= pends on the internal hardware design. dBm looks to be the standard unit fo= r a RSSI value.

Up to the application layer to pro= vide or not a meaning that depends on the device and the use case.
Finally Signal quality also depends on the SNR, Signal-to-Noise ratio= .

Best,
Eric.

On Wed, Mar 22, 2017 at 9:15 PM, Christian A= ms=C3=BCss <c.amsuess@energyharvesting.at> wrote= :
On Wed, Mar 22, 2017 a= t 12:47:12PM -0600, Cullen Jennings wrote:
> I got a request to add RSSI to the table in 12.1 of=C2=A0 of SenML
>
> Symbol: RSSI
>
> Description: Received signal strength indication
>
> Type: float

I've been using signal strengths for some time in SenML, and the= y were
in those applications provided in dBm, which I converted according to
what the spec says (or rather said back then, this has been operational
since 2014) about falling back to UCUM as UCUM:B[W].

The recommendations w/rt UCUM have been demoted since then, but it is
still common in the other units there to be specific and comparable (dB
being the exception). RSSI with any real unit would not have any meaning outside of that device's receptor, and could just as well be represente= d
without any unit. I'd support adding something that has the semantic meaning of received signal strength (dBm would be more common than the
by-the-letters-of-UCUM B[W] unit), but a plain RSSI would IMO lead to
confusion in any inhomogenous setup.

Best regards
Christian

--
To use raw power is to make yourself infinitely vulnerable to greater power= s.
=C2=A0 -- Bene Gesserit axiom

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



--001a11467050ddc121054b579fdd-- From nobody Wed Mar 22 13:30:56 2017 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 2EE4B12894A for ; Wed, 22 Mar 2017 13:30: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] 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 i8Yy4PIJ0eo2 for ; Wed, 22 Mar 2017 13:30:52 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD2CD128B38 for ; Wed, 22 Mar 2017 13:30:52 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 5209B46988; Wed, 22 Mar 2017 21:30:51 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id AADAC1CB; Wed, 22 Mar 2017 21:30:50 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 80D98406; Wed, 22 Mar 2017 21:30:50 +0100 (CET) Received: (nullmailer pid 11995 invoked by uid 1000); Wed, 22 Mar 2017 20:30:49 -0000 Date: Wed, 22 Mar 2017 21:30:49 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Carsten Bormann Cc: Cullen Jennings , core Message-ID: <20170322203049.eswrtgjsatc67bw6@hephaistos.amsuess.com> References: <0A3A3346-9B5D-48B7-BB52-6DEE39A91200@iii.ca> <41989F03-35A9-4C76-9626-696FE123AFBC@tzi.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="33amv5bc5buggaac" Content-Disposition: inline In-Reply-To: <41989F03-35A9-4C76-9626-696FE123AFBC@tzi.org> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [core] RSSI in SenML X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 20:30:55 -0000 --33amv5bc5buggaac Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 22, 2017 at 07:52:14PM +0100, Carsten Bormann wrote: > RSSI is a quantity (an ill defined one). >=20 > Table 12.1 is about units. By the name, but not by the use. The review guide after the table (esp. point 2) indicate that what is called unit in the document is what SI calls quantities, and the presence of Hz, 1/s and Bq shows that as well. Maybe that should be clarified in the registry introduction; straw man text: "The definitions given here are called units based on common language use. In the terminology of the International System of Units, they are special unit names, and not only indicate the unit but also the described quantity." Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --33amv5bc5buggaac Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAljS3vUACgkQOY0REtOk veEfUhAAhwfThVmfRbuUS7yTCylCY/zAWTjQdUwFAZi1MBBnmus1+QHz8iwplker bLln5fJPPKvw3KKZ9E+DYgMkDQeoT1SIGQj+8c0pF13uecrky1J7cPxlj+pSRVOT dlRArBmWY5B3ZrrzAfQsMaC5jqOet1KPY0GaLY2vYmsbzHVOczZwtdAGNQYw2yQ7 iKn+5wY5wPTRespfDNyLjT/YaSRnPf+wDGpxLUmRLZGydz5VoqCu/oR4JdEVQ8PR kXsMunTbO7AMz6BsujClx+8vbmcrl76rIVFEYxpqBfR1WqvQ7Fv69p1vksFHfO3I /H2gdhmhbWpOQW3BBGYAVpVxC7RRaxk0kszHo/gJjF2Fml2suaRT3lriQB5JsS3v 6o8pPHzbairt/quetwpPIQnGmCz3yzVp8UFXMIYh7uUiMRms7bexrRmMbngdd1zt uOMXF/Is3lpqyIKm85cyAzASJXaFJUjUmK0aP9xyKQXcdQhFxfo1aH/BRCz0Amvp MDjBA3j/RHaaU/znu6KeIHqMxokV7y7MlA4ib2XWFvLc2jB/KPrliMkR70tHUdCp suvXy27WuQrt+uVO2oIKt8lbjvQFDP5rk6Q1Wsb5uGN/cN7E92Bf4J1H5Krhww9W Px+K1HJVhX2TD7lANj+kuhPNgls4UEJHi4XAgxXGaQ2Fq4L7Wyo= =JadA -----END PGP SIGNATURE----- --33amv5bc5buggaac-- From nobody Wed Mar 22 14:55:11 2017 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 2C09F129511 for ; Wed, 22 Mar 2017 14:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byplSlPHYfRm for ; Wed, 22 Mar 2017 14:55:08 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA2B81289B0 for ; Wed, 22 Mar 2017 14:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v2MLsxRp005296; Wed, 22 Mar 2017 22:54:59 +0100 (CET) Received: from [192.168.217.124] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vpNl754fqzDHfg; Wed, 22 Mar 2017 22:54:59 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: <20170322203049.eswrtgjsatc67bw6@hephaistos.amsuess.com> Date: Wed, 22 Mar 2017 22:54:58 +0100 Cc: Cullen Jennings , core X-Mao-Original-Outgoing-Id: 511912498.802806-a4a06dee8ca98bc35f6eabcb4033eeda Content-Transfer-Encoding: quoted-printable Message-Id: <37D02847-3B85-4C19-94E1-EDCEDF8A95C6@tzi.org> References: <0A3A3346-9B5D-48B7-BB52-6DEE39A91200@iii.ca> <41989F03-35A9-4C76-9626-696FE123AFBC@tzi.org> <20170322203049.eswrtgjsatc67bw6@hephaistos.amsuess.com> To: =?utf-8?Q?Christian_Ams=C3=BCss?= X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [core] RSSI in SenML X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 21:55:10 -0000 > On 22 Mar 2017, at 21:30, Christian Ams=C3=BCss = wrote: >=20 > On Wed, Mar 22, 2017 at 07:52:14PM +0100, Carsten Bormann wrote: >> RSSI is a quantity (an ill defined one). >>=20 >> Table 12.1 is about units. >=20 > By the name, but not by the use. The review guide after the table = (esp. > point 2) indicate that what is called unit in the document is what SI > calls quantities, and the presence of Hz, 1/s and Bq shows that as = well. Hz, 1/s, Bq are units. Quantities that can be expressed in these units are, for instance, frequency, rotational frequency, activity, respectively. The principles are in ISO80000-1. (Most of us got our degrees before = 2009; I just wish students today would work more with these = fundamentals=E2=80=A6) Look up the units and quantities given above in ISO80000-3 for Hz and = 1/s (3-15.1 and 3-15.2 in the quantities table, 3-15.a and 3-15.b in the = units table there). I=E2=80=99m too lazy to look up Bq in ISO80000-10, oh well, it=E2=80=99s = 10-29.a in the units table there. > Maybe that should be clarified in the registry introduction; straw man > text: "The definitions given here are called units based on common > language use. In the terminology of the International System of Units, > they are special unit names, and not only indicate the unit but also = the > described quantity.=E2=80=9D That would most definitely not be true with most entries of the current = table. Almost all are units in the SI or ISQ. (Yes, there are some entries that are more on the quantity side of the = spectrum.) Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Mar 22 23:58:38 2017 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 C84AC129434 for ; Wed, 22 Mar 2017 23:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.462 X-Spam-Level: X-Spam-Status: No, score=-1.462 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, 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 ezkqJquvMMHG for ; Wed, 22 Mar 2017 23:58:33 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id D52B5127843 for ; Wed, 22 Mar 2017 23:58:31 -0700 (PDT) Received: from WeiGengyuPC (unknown [114.255.40.36]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id A551B19F3F9; Thu, 23 Mar 2017 14:58:28 +0800 (HKT) Message-ID: <505B2B60A1B34322A1E2A081291110D4@WeiGengyuPC> From: "weigengyu" To: "Carsten Bormann" , "Fossati, Thomas \(Nokia - GB/Cambridge, UK\)" Cc: , References: <3B156DF2-EC3C-4135-94C1-9D1A4ED686B8@on.nokia.com> <79C355A0-79FE-4D90-9907-11F1A65BB5CD@on.nokia.com> <1F568F3E-1195-42E5-B953-81C9713C741B@tzi.org> <4FC5F3D6-DE9E-48ED-A509-DCCEC809CF0E@tzi.org> In-Reply-To: <4FC5F3D6-DE9E-48ED-A509-DCCEC809CF0E@tzi.org> Date: Thu, 23 Mar 2017 14:58:40 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [core] Review of draft-becker-core-coap-sms-gprs-06 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 06:58:37 -0000 Hi Carsten and all, About CoAP/SMS or CoAP/DTLS/SMS, we may do some contributions. The following is the abstract of my master course student's thesis, just completed this month. Research and Development of Secure SMS for M2M and CoAP ABSTRACT The technology of Internet of Things is changing fast, and the new application is built on the network environment that based on the limited network and Internet integration. The Internet Engineering Task Force (IETF) CoRE defines a restricted application protocol (CoAP) for a large number of nodes and networks in the Internet of Things that rely heavily on battery-powered, processor-capable, and communication-constrained capabilities. The Open Mobile Alliance (OMA) proposed a new lightweight machine-to-machine (LWM2M) communication protocol standard, which clearly defined the protocol stack based on mobile short message to support the application of Internet of Things for CoAP / SMS (SMS) or CoAP / DTLS / SMS protocol. Datagram Transport Layer Security Protocol (DTLS) has become an important measure to construct "secure short message". In this paper , the DTLS protocol based on "secure short message" , the communication framework and application of CoAP / SMS and CoAP / DTLS / SMS using short message are studied and developed. The main contributions of this paper are studying and developing the secure short message based on DTLS, and a practical application built on it, which are of great significance to the study of Internet of Things based on secure short message. KEY WORDS: iot、m2m、coap、dtls、sms The implementations did by extending Californium (Cf) core and tested on Andoird. Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: Carsten Bormann Sent: Wednesday, March 22, 2017 8:49 PM To: Fossati, Thomas (Nokia - GB/Cambridge, UK) Cc: draft-becker-core-coap-sms-gprs@ietf.org ; core@ietf.org Subject: Re: [core] Review of draft-becker-core-coap-sms-gprs-06 > On 22 Mar 2017, at 13:44, Fossati, Thomas (Nokia - GB/Cambridge, UK) > wrote: > > Hi Carsten, > > On 21/03/2017 17:28, "Carsten Bormann" wrote: >> Where do we get a good corpus of CoAP messages? > > That's a very good question. > I was thinking that maybe we could start from pcap captures taken at ETSI > interop events. Those would be a faithful mirror of what we wrote in the test descriptions. (I’m also not aware of anyone keeping a sizable collection of these.) A better “corpus” could be had from dreaming up a few use cases that are likely to use SMS, design exchanges for those, and capture those on a platform such as coap.me. Grüße, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Thu Mar 23 00:30:23 2017 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 8C3D6129C6F; Thu, 23 Mar 2017 00:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 sRLDViC-1R-x; Thu, 23 Mar 2017 00:30:19 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1033E129C6C; Thu, 23 Mar 2017 00:30:18 -0700 (PDT) X-AuditID: c1b4fb25-0b71498000002d78-cd-58d37988d538 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by (Symantec Mail Security) with SMTP id 6B.8B.11640.88973D85; Thu, 23 Mar 2017 08:30:17 +0100 (CET) Received: from ESESSMB107.ericsson.se ([169.254.7.125]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0319.002; Thu, 23 Mar 2017 08:30:16 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= CC: "draft-ietf-core-object-security@ietf.org" , "draft-tiloca-core-multicast-oscoap@ietf.org" , "core@ietf.org" Thread-Topic: Secure CoAP multicast overhead (was: [core] OSCOAP -02: sequence number reuse?) Thread-Index: AQHSo6dQCKn2J+dYo0GoWNIgyoRO5g== Date: Thu, 23 Mar 2017 07:30:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-ID: <7A9924CA54D1E448AA527526FCD9E591@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM2J7uG5n5eUIg0PLeS2WX3jOYrHv7Xpm i2n/zrBYbG+5zurA4rF1/10mjyVLfjIFMEVx2aSk5mSWpRbp2yVwZfycMIe14I1ixYL5Z1ga GP8odDFyckgImEicn7iHvYuRi0NIYB2jxJpT7WwQzhJGiaYNv9hBqtgEXCQeNDxiArFFBDwk Ji79AtbBLHCfUeLT7OlgCWGBKIkH585DFcVLTNz0GMrWk1j/bzNLFyMHB4uAqsTVBxUgYV4B C4lJRxaAlTAKiEl8P7UGzGYWEJe49WQ+E8R1AhJL9pxnhrBFJV4+/scKYosCjVz+fA1UXEli xfZLjCDjmQU0Jdbv0ocYYy1x6+4JZghbUWJK90N2iLWCEidnPmGZwCg6C8m2WQjds5B0z0LS PQtJ9wJG1lWMosWpxUm56UbGeqlFmcnFxfl5enmpJZsYgRF1cMtv1R2Ml984HmIU4GBU4uEt mHgpQog1say4MvcQowQHs5IIr283UIg3JbGyKrUoP76oNCe1+BCjNAeLkjiv474LEUIC6Ykl qdmpqQWpRTBZJg5OqQbGznA2rekLLE5MUjFcdubBIlOL9V/frg1fvt92W5JLfegC66Z1B+/d qWsrV7vqxdL7/lt17N+5KZo/pnfdPbuIuSvFeXFYuajOysT7ZerF/219by58dOFgjQbD54ps lxCJ0uMyYlY++TuWVZl7brrwvb3I4yiDlpPTx9tvbkd2KQZO47mv80FTiaU4I9FQi7moOBEA onuduKQCAAA= Archived-At: Subject: [core] Secure CoAP multicast overhead (was: OSCOAP -02: sequence number reuse?) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 07:30:22 -0000 SGkgQ2hyaXN0aWFuLA0KDQooY29udGludWluZyB0aGUgZGlzY3Vzc2lvbiBpbiBhIG5ldyB0aHJl YWQpDQoNCk9uIDIwMTctMDMtMjIgMTY6NDksICJDaHJpc3RpYW4gQW1zw7xzcyIgPGMuYW1zdWVz c0BlbmVyZ3loYXJ2ZXN0aW5nLmF0Pg0Kd3JvdGU6DQoNCj5PbiBXZWQsIE1hciAyMiwgMjAxNyBh dCAxMDoxNzowMkFNICswMDAwLCBHw7ZyYW4gU2VsYW5kZXIgd3JvdGU6DQo+PiBKdWRnaW5nIGJ5 IHlvdXIgcHJvcG9zYWwgeW91IGdvdCB0aGUgcG9pbnQgZGVzcGl0ZSB0aGVzZSBlcnJvcnMuIEni gJl2ZQ0KPj4gdXBkYXRlZCB0aGUgZHJhZnQsIHBsZWFzZSBjaGVjayBpZiBJIGdvdCBpdCByaWdo dDoNCj4+DQo+PiBBcyBhbiBleGVyY2lzZSwgdmVyaWZ5IHRoYXQgdGhpcyBjb25zdHJ1Y3Rpb24g d29ya3MgZXZlbiBpZiBjbGllbnQgYW5kDQo+PiBzZXJ2ZXIgY2hhbmdlIHJvbGVzLiBBbmQgYWxz byB3aXRoIE9ic2VydmUgaW4gdGhhdCBjYXNlLg0KPg0KPkFzIEkgcmVhZCBpdCBub3csIGl0IHNo b3VsZCB3b3JrLiAoV2l0aG91dCBvYnNlcnZlIGFuZCByb2xlIHJldmVyc2FsLCBpdA0KPndvcmtz IGluIG15IGltcGxlbWVudGF0aW9uLCB0aGUgcmVzdCBpcyBwZW5kaW5nIGJ1dCByZXF1aXJlcyBz b21lIG1vcmUNCj5zdHJlYW1saW5pbmcgaW4gdGhlIEFQSSkuDQo+DQo+V2hlcmUgSSBkbyBzZWUg dHJvdWJsZSBjb21pbmcgdXAgaXMgd2hlbiB0aGUgbXVsdGljYXN0IHByb3Bvc2FscyBnZXQNCj53 YXJtZWQgdXAgYWdhaW4uDQoNClRoZXkgYWxyZWFkeSBhcmUgOi0pIFNlZSBiZWxvdy4NCg0KPiBG b3IgdGhlbiwgSSBjYW4gZW52aXNpb24gYXQgbGVhc3QgdHdvIHNvbHV0aW9uc1sxXSwgc28NCj5J IHN1cHBvc2Ugd2UncmUgZ29vZC4NCj4NCj5CZXN0IHJlZ2FyZHMNCj5DaHJpc3RpYW4NCj4NCj4N Cj5bMV06IChEaXZlcnRpbmcgdGhpcyBpbnRvIGEgZm9vdG5vdGUgc28gaXQncyBvbiByZWNvcmQs IGV2ZW4gdGhvdWdoIGl0J3MNCj5ub3QgcmVsZXZhbnQgZm9yIHRoaXMgdGhyZWFkIGl0c2VsZiwg YnV0IG1pZ2h0IHNwaW4gb2ZmIGEgbmV3IG9uZSBmb3INCj5tdWx0aWNhc3Q6KQ0KPg0KPiogQXBw cm9hY2ggQTogVW5sZXNzIG9ubHkgb25lIG5vZGUgdGhhdCBpcyBhbGxvd2VkIHRvIGRvIHJlcXVl c3RzLCBhbGwNCj4gIHJlc3BvbnNlcyBtdXN0IGJlYXIgYSBzZXF1ZW5jZSBudW1iZXIgb2YgdGhl aXIgb3duIGluc3RlYWQgb2YNCj4gIG1pcnJvcmluZy4NCj4NCj4gIFRoaXMgYWRkcyBiYWNrIHRo ZSBzZXF1ZW5jZSBudW1iZXJzIHRvIHRoZSBtZXNzYWdlIGxlbmd0aC4gKEFzIHRoZQ0KPiAgbXVs dGljYXN0IHJlc3BvbnNlcyBwcm9iYWJseSBuZWVkIHRoZSBLSUQgYXMgd2VsbCwgdGhpcyBqdXN0 IG1lYW5zDQo+ICB0aGF0IHRoZSBjb21wcmVzc2VkIHJlc3BvbnNlcyB0YWtlIHRoZSBbcGFydElW LCBraWQsIGNpcGhlcnRleHRdIGZvcm0uDQoNCkNvcnJlY3QsIGFuZCB0aGlzIGlzIGVzc2VudGlh bGx5IGhvdyBpdCBpcyBzcGVjaWZpZWQgaW4gc2VjdGlvbiA1IG9mOg0KDQpodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtdGlsb2NhLWNvcmUtbXVsdGljYXN0LW9zY29hcC0wMQ0KDQpU aGUgb25seSBhZGRpdGlvbmFsIG1lc3NhZ2UgZmllbGQgaXMgYSBncm91cC9jb250ZXh0IGlkZW50 aWZpZXIgdG8gYWxsb3cNCm5vZGVzIHRvIGJlIHBhcnQgb2YgbXVsdGlwbGUgZ3JvdXBzLiAoQW5k IGEgY291bnRlcnNpZ25hdHVyZSB0byBhZGRyZXNzDQp1c2UgY2FzZXMgd2hlcmUgc291cmNlIGF1 dGhlbnRpY2F0aW9uIGlzIGltcG9ydGFudC4pDQoNCj4NCj4qIEFwcHJvYWNoIEI6IEFsbG9jYXRl IG5vdCAxIGJ1dCBuICJtaXJyb3Igc3BhY2VzIi4gVGhpcyB3b3VsZCB0YWtlDQo+ICBjZWlsKGxv ZzIobl9wYXJ0aWNpcGFudHMpKSBiaXRzIG9mZiB0aGUgc2VxdWVuY2UgbnVtYmVyIHJhbmdlLCBi dXQgdGhlDQo+ICByZXNwb25kZXJzIHdvdWxkIHRoZW4gb25seSBuZWVkIHRvIHNlbmQgdGhlaXIg S0lEIChzZW5kZXIgSUQpIGFuZCB0aGUNCj4gIGNpcGhlcnRleHQuDQo+DQo+ICAoQmFzaWNhbGx5 IHRoZXknZCBlbmNvZGUgdGhlIHBlZXIgbnVtYmVyIGluIHJldmVyc2UgYml0IHNlcXVlbmNlIGlu DQo+ICB0aGUgcGFydGlhbCBJViwgd2hlcmUgMCBpcyB1c2VkIGZvciBzZXF1ZW5jZSBudW1iZXJz IHRoZSBkZXZpY2UgaGFzDQo+ICBkZWFsdCBpdHNlbGYsIDEgaXMgZm9yIHNlcXVlbmNlIG51bWJl cnMgb3V0IG9mIHRoZSBsaXN0IG9mIHRoZSBmaXJzdA0KPiAgcGFydG5lciAob3IgdGhlIHVuaWNh c3QgcGFydG5lciksIGFuZCAyIGV0YyBpcyBmb3Igc2VxdWVuY2UgbnVtYmVycyBvZg0KPiAgb3Ro ZXIgcGVvcGxlJ3MgcG9vbHMuDQoNCkludGVyZXN0aW5nIGFsdGVybmF0aXZlLiBBcyBpdCBpcyBj dXJyZW50bHkgZGVzaWduZWQsIE9TQ09BUCBpcyBvcHRpbWl6ZWQNCmZvciBDb0FQIChSRkM3MjUy KSwgd2hpY2ggZ2l2ZXMgYSB2ZXJ5IGxvdyBvdmVyaGVhZCBbMl0uIFdoZW4gT1NDT0FQIGlzDQpl eHRlbmRlZCB0byBvdGhlciBzZXR0aW5ncywgbGlrZSBlLmcuIHNlY3VyZSBtdWx0aWNhc3Qgd2l0 aCB1bmljYXN0DQpyZXNwb25zZXMsIHRoZXJlIGFyZSBhIGZldyBhZGRpdGlvbmFsIG1lc3NhZ2Ug ZmllbGRzLiBCdXQsIGFzIHlvdSBwb2ludA0Kb3V0LCBhbHNvIGluIHRoYXQgY2FzZSBpdCBpcyBw b3NzaWJsZSB0byBtYWtlIGZ1cnRoZXIgb3B0aW1pc2F0aW9ucy4NCg0KR8O2cmFuDQoNCg0KWzJd IA0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1tYXR0c3Nvbi1j b3JlLXNlY3VyaXR5LW92ZXJoZWFkDQoNCg0KPg0KPi0tIA0KPkNocmlzdGlhbiBBbXPDvHNzICAg ICAgICAgICAgICAgICAgICAgIHwgRW5lcmd5IEhhcnZlc3RpbmcgU29sdXRpb25zIEdtYkgNCj5m b3VuZGVyLCBzeXN0ZW0gYXJjaGl0ZWN0ICAgICAgICAgICAgIHwgaGVhZHF1YXJ0ZXI6DQo+bWFp bHRvOmMuYW1zdWVzc0BlbmVyZ3loYXJ2ZXN0aW5nLmF0ICB8IEFyYmVpdGVyZ2Fzc2UgMTUsIEEt NDQwMCBTdGV5cg0KPnRlbDorNDMtNjY0LTk3LTkwLTYtMzkgICAgICAgICAgICAgICAgfCBodHRw Oi8vd3d3LmVuZXJneWhhcnZlc3RpbmcuYXQvDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8IEFUVTY4NDc2NjE0DQoNCg== From nobody Thu Mar 23 12:44:45 2017 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 1AD3A1294F4; Thu, 23 Mar 2017 12:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.455 X-Spam-Level: X-Spam-Status: No, score=-0.455 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alibaba-inc.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 cofbKFhFBHzO; Thu, 23 Mar 2017 12:44:42 -0700 (PDT) Received: from out0-144.mail.aliyun.com (out0-144.mail.aliyun.com [140.205.0.144]) by ietfa.amsl.com (Postfix) with ESMTP id 646C81294C7; Thu, 23 Mar 2017 12:44:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1490298278; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=zK9/DqXXQBsGR4VXYPk9cxm87CXwFIfZjgc9dgPT1Gk=; b=JbcKUF4/WoX1i0EgZAzLvPdCmQSlIVeNZPfUYmeddSZY5vC52MbFCcYivNagWogBVNnXB+Q901BBF6u1VpDT4FPvQrAJYKWGkAxNu3Mgvi41uNTby0Zb/aKw7Whg4yoOLSOt0vlGJCAXdDebxKOXydVEbut9y74Yr85wy1Xnhj0= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R101e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03302; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=5; SR=0; TI=SMTPD_---.7qUEbaA_1490298263; Received: from 30.39.23.22(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.207) by smtp.aliyun-inc.com(127.0.0.1); Fri, 24 Mar 2017 03:44:32 +0800 User-Agent: Microsoft-MacOutlook/14.6.8.160830 Date: Thu, 23 Mar 2017 20:44:19 +0800 From: "Kepeng Li" To: weigengyu , Carsten Bormann , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" CC: , Message-ID: Thread-Topic: [core] Review of draft-becker-core-coap-sms-gprs-06 References: <3B156DF2-EC3C-4135-94C1-9D1A4ED686B8@on.nokia.com> <79C355A0-79FE-4D90-9907-11F1A65BB5CD@on.nokia.com> <1F568F3E-1195-42E5-B953-81C9713C741B@tzi.org> <4FC5F3D6-DE9E-48ED-A509-DCCEC809CF0E@tzi.org> <505B2B60A1B34322A1E2A081291110D4@WeiGengyuPC> In-Reply-To: <505B2B60A1B34322A1E2A081291110D4@WeiGengyuPC> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [core] Review of draft-becker-core-coap-sms-gprs-06 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 19:44:44 -0000 Good to hear about that. About the thesis, is it in Chinese or English? If it is published already, can you send us the link? I would be interested to read the thesis, and get some ideas. Also welcome to contribute to the coap-sms draft. Thanks, Kind Regards Kepeng =E5=9C=A8 23/03/2017, 2:58 PM=EF=BC=8C "weigengyu" =E5=86=99=E5=85=A5: >Hi Carsten and all, > >About CoAP/SMS or CoAP/DTLS/SMS, we may do some contributions. > >The following is the abstract of my master course student's thesis, just >completed this month. > >Research and Development of Secure SMS for M2M and CoAP >ABSTRACT >The technology of Internet of Things is changing fast, and the new >application is built on the network environment that based on the limited >network and Internet integration. The Internet Engineering Task Force >(IETF)=20 >CoRE defines a restricted application protocol (CoAP) for a large number >of=20 >nodes and networks in the Internet of Things that rely heavily on >battery-powered, processor-capable, and communication-constrained >capabilities. The Open Mobile Alliance (OMA) proposed a new lightweight >machine-to-machine (LWM2M) communication protocol standard, which clearly >defined the protocol stack based on mobile short message to support the >application of Internet of Things for CoAP / SMS (SMS) or CoAP / DTLS / >SMS=20 >protocol. Datagram Transport Layer Security Protocol (DTLS) has become an >important measure to construct "secure short message". >In this paper , the DTLS protocol based on "secure short message" , the >communication framework and application of CoAP / SMS and CoAP / DTLS / >SMS=20 >using short message are studied and developed. The main contributions of >this paper are studying and developing the secure short message based on >DTLS, and a practical application built on it, which are of great >significance to the study of Internet of Things based on secure short >message. >KEY WORDS: iot=E3=80=81m2m=E3=80=81coap=E3=80=81dtls=E3=80=81sms > >The implementations did by extending Californium (Cf) core and tested on >Andoird. > >Regards, > >Gengyu WEI >Network Technology Center >School of Computer >Beijing University of Posts and Telecommunications >-----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6-----=20 >From: Carsten Bormann >Sent: Wednesday, March 22, 2017 8:49 PM >To: Fossati, Thomas (Nokia - GB/Cambridge, UK) >Cc: draft-becker-core-coap-sms-gprs@ietf.org ; core@ietf.org >Subject: Re: [core] Review of draft-becker-core-coap-sms-gprs-06 > > >> On 22 Mar 2017, at 13:44, Fossati, Thomas (Nokia - GB/Cambridge, UK) >> wrote: >> >> Hi Carsten, >> >> On 21/03/2017 17:28, "Carsten Bormann" wrote: >>> Where do we get a good corpus of CoAP messages? >> >> That's a very good question. >> I was thinking that maybe we could start from pcap captures taken at >>ETSI=20 >> interop events. > >Those would be a faithful mirror of what we wrote in the test >descriptions. >(I=E2=80=99m also not aware of anyone keeping a sizable collection of these.) > >A better =E2=80=9Ccorpus=E2=80=9D could be had from dreaming up a few use cases that a= re >likely to use SMS, design exchanges for those, and capture those on a >platform such as coap.me. > >Gr=C3=BC=C3=9Fe, Carsten > >_______________________________________________ >core mailing list >core@ietf.org >https://www.ietf.org/mailman/listinfo/core=20 From nobody Fri Mar 24 04:31:59 2017 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 2D8691296A6; Fri, 24 Mar 2017 04:31: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] 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 p2QcL5u0Nii2; Fri, 24 Mar 2017 04:31:55 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80F4212969C; Fri, 24 Mar 2017 04:31:54 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id DA166469D8; Fri, 24 Mar 2017 12:31:52 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id B381A11B; Fri, 24 Mar 2017 12:31:51 +0100 (CET) Received: from hephaistos.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 84E7E10D; Fri, 24 Mar 2017 12:31:51 +0100 (CET) Received: (nullmailer pid 317 invoked by uid 1000); Fri, 24 Mar 2017 11:31:50 -0000 Date: Fri, 24 Mar 2017 12:31:50 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: draft-ietf-core-senml@ietf.org, core@ietf.org, draft-ietf-core-interfaces@ietf.org Message-ID: <20170324113150.hrxznr44n5zdivud@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hy7rwhszyv65flhg" Content-Disposition: inline User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: [core] SenML and its use in core-interfaces (follow-up on bn/n URI clarification) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 11:31:58 -0000 --hy7rwhszyv65flhg Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello SenML authors, and hello CoRE Interfaces authors, I'd like to follow up on the IETF96 (Berlin) discussion on using URIs with SenML after reviewing the mails on the topic and the discussion footage. The point of the URI concatenation discussion back then was to allow CoRE Interfaces to do what they are currently doing, being GET /l/ [{"n": "/s/light", "v": 123, "u": "lx"}, {"n:" "/s/temp", "v": 27.2, "u": "degC"}] which is supposed to mean the /s/light and /s/temp resources on the origin server, and not /l//s/light etc. as it will by the SenML spec. In the Berlin discussion, there was a rough agreement on taking a route where URI users could use a different attribute to denote their anchor/href; this would avoid the pitfalls of doing URI concatenation wrong for people who don't use URIs there anyway. This has not been fleshed out or at least explored since then AFAICT, and I'd like to at least see that there is a route of extensions CoRE interfaces can use if we publish SenML as it is now. Two questions need answering IMO: * Do we want to be able to share documents between "URI users" and "non-URI users"? In many cases this will be possible; for example, batches (as opposed to linked batches as above) would just work with the current name building, and thus be usable by non-URI-aware clients as well. * If we want to keep them apart, how would we deal with the requirement of having mandatory uniquely identifying names? A linked batch would certainly not want to repeat names once in "n" and once in "h" notation. For a strawman proposal, I'd assume the answers are "we want to allow mixed usership", and "the unique name requirement stays". Then we could construct an extension like this: Resolved records have, in addition to their name, a URI name ("href"), which is optional to use but can be mandated to use in certain applications (eg. CoRE interfaces). The URI name is formed by doing RFC3986 relative URI resolution of the "h" property relative to the "bh" base attribute relative to the requested URI. If the "h" property is absent on a record, its "n" property provides a default value. If the "bh" property is absent on the first record, the "bn" property provides a default value. This scheme has the properties that + Batches (or generally, collections that worked so far) work equally well for non-URI and URI users. + Representations stay as compact as they are. + The CoRE interfaces can refer to the records' URI names and thus be sure that users must take the necessary steps to resolve relativities correctly, while simpler SenML users arrive at resolved names by concatenating. ~ Evaluating the name of, say, linked batch resources still gives a unique name. It might or might not be a valid URI, and might or might not be dereferncable, but since it's agreed on that a name is not necessarily a URI, that's OK. For example, the linked batch of the first example would give resolved "n":"coap://host/l//s/light" (or even, for other examples, "n":"coap://host/l/http://remote/resource"), but that would still be a unique name. - It doesn't survive representation as Resolved Records. (But are they intended to be serialized again at all? How do other extensions cope with Resolved Records?) - It defines properties that would, in actual use, barely (if at all) show up. In particular, the CoRE Interfaces examples could stay as they are and never use "h"/"bh". If we just dropped the arguments and only defined a URI property, we're even worse again in the next point: - This has a smell of applications defining how to interpret the name, which is what Cullen has already argued against in the July thread. If we can live with the above downsides or those of another form of URI extension (which might have fewer or others), then I think we can procede with SenML as it is, otherwise we should either come up with a better URI story, or need SenML to accomodate such uses. What do you think? Best regards Christian --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --hy7rwhszyv65flhg Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAljVA6MACgkQOY0REtOk veE1txAAhaB9Wyp5c77dnCh+9qY09jYaLsRvIkvE+COw3c+/03QzrMtC25IhhjCv fTe8w/Fvz2qUOcJg7/4mBcTQOYe91HgZ58hIC9GicOFr8ApE2PBlqL8ZegBRLyEj 3ds205thdIq1QPjRf2txm1DTGA822pp3ufQSXOTr1DxY+5yCfJOxkuxhcXWtuSOW PIaJYxyhFyDP+RcqYxMM8tmC0sgUhGJZ3/aDC4QN4ptRSaa6A8601AxbuHehrbau 1KLVvUsk9Bp4rheB5Qegu091WP3zhfbz6DDd+Wa36KW81L/6iuu8gi+On+djcuec +2MrVz0Q6QkOoM72eSLxPZkHsha7KnzdCnm6ndM3X0Pe4D1II4q+tXHpvMz27DfR NvOrLKy7QXKd9vl64uLMA7uZRUgWPf8JopFyHKKAGpU34pSRoUIzkbuGfxmZleYg SjI3BTL6YL9n7uXCV6I+dnoL+sP+hMQOjw6FZM0vuu4Nq/6294Knqk66rUbTR5AC 1WMzBiSy/yE8WZZ7ZEIeYVGzUnXYHzxunbMAFlU4cTS3VTxdl8i8W0nt6REV5ucS lsFsTVUdnWP3Yp7myS1hwRaHu63+M8gGrA9bkMDjAKVMszSdPoIzCaVKfQ0slq2w Wk/M5pT9ibKZoZym7EwLlQjz26kpFoPygGBVm5TrLPHsCbtLlpA= =ZjpJ -----END PGP SIGNATURE----- --hy7rwhszyv65flhg-- From nobody Fri Mar 24 06:12:03 2017 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 978621296C0 for ; Fri, 24 Mar 2017 06:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-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=nokia.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 0tcSK4bNR2ih for ; Fri, 24 Mar 2017 06:12:00 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0127.outbound.protection.outlook.com [104.47.1.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C095E12943F for ; Fri, 24 Mar 2017 06:11:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=J8BaLQvX0GD22UBatmXtD0jhuZXZ8sLj0U0KDIVW764=; b=cP3KZuNdUwy4m7i1AvqOIYmHBkqpaR8uiJ+YFT/yXw0XbaRVfjqyw8L1BLSP/18ycJNluaQtmHeWPHESG59Hy0gLjANSaPCXhObJctPtgdV9Pg114U/zb/y5OLH02CR7bvo2sJ+PXa/59L1CsSMSKb1bV2SI4aTdRpRYiLydECs= Received: from AM5PR0701MB2644.eurprd07.prod.outlook.com (10.173.92.151) by AM5PR0701MB2641.eurprd07.prod.outlook.com (10.173.92.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Fri, 24 Mar 2017 13:11:57 +0000 Received: from AM5PR0701MB2644.eurprd07.prod.outlook.com ([10.173.92.151]) by AM5PR0701MB2644.eurprd07.prod.outlook.com ([10.173.92.151]) with mapi id 15.01.0991.018; Fri, 24 Mar 2017 13:11:57 +0000 From: "Carey, Timothy (Nokia - US)" To: Becker Markus , Carsten Bormann , Lauri Piikivi CC: core Thread-Topic: [core] draft-becker-core-coap-sms-gprs-06: Identifying CoAP PDUs Thread-Index: AdKfKF6ML8bvf5XRR0G4XD2y6EQ6paGj+YYg Date: Fri, 24 Mar 2017 13:11:57 +0000 Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F77012A8B2BF7@US70UWXCHMBA05.zam.alcatel-lucent.com> <69305B9C-184F-4063-8B86-1929749241DF@arm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tridonic.com; dkim=none (message not signed) header.d=none;tridonic.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [208.184.163.30] x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2641; 7:sDfYeAsFtLrut1sAeSjq2eHwXQ2wS4RqqWqxrLDupNbDHY+p111QBJpvLrD6eeeEH/jE2VdeTRkKVAeckKGy3PNGgLg/jATqhTc7IhOImA8ON6o2xpgua4OaDaU20AycVOzfcjcwgJ8hQmh13FGyQPO6YviANecZ3ZBnkw6bk+tixTHmgXxMRq27/6lbLMhE4gM+vmhuKmHqKZDoo/Ak6+t+pFiuOuHPd8R2iCaPyoBNZs++Uyxm1W6fktdbXZF3IPdyHXdGzalX7SlNumHAvS+ekoy0CgJvGzz6gly09VOFRaZ0srcTV6c24oA0HR5/1hvwtkBrHIQRYHr+O2OEEQ== x-ms-office365-filtering-correlation-id: 4bb5f4da-0d13-45e7-2ad9-08d472b75990 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:AM5PR0701MB2641; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(180628864354917)(262304522455115); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123558025)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(6072148); SRVR:AM5PR0701MB2641; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2641; x-forefront-prvs: 0256C18696 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39860400002)(39840400002)(39450400003)(39410400002)(377454003)(8676002)(81166006)(8936002)(76176999)(50986999)(54356999)(33656002)(5890100001)(3660700001)(86362001)(230783001)(93886004)(1720100001)(122556002)(2900100001)(3280700002)(4326008)(6306002)(9686003)(55016002)(99286003)(6436002)(7736002)(74316002)(305945005)(53376002)(38730400002)(6246003)(53936002)(189998001)(6506006)(77096006)(229853002)(966004)(66066001)(7696004)(5660300001)(2950100002)(25786009)(3846002)(102836003)(6116002)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2641; H:AM5PR0701MB2644.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Mar 2017 13:11:57.2323 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2641 Archived-At: Subject: Re: [core] draft-becker-core-coap-sms-gprs-06: Identifying CoAP PDUs X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 13:12:02 -0000 TWFya3VzLA0KDQpJIGtub3cgdGhhdCB0aGUgV0FQIChVREgpIGlzIGJlaW5nIHVzZWQgZm9yIFNN UyBpbiB2YXJpb3VzIGFwcGxpY2F0aW9ucy4gSSB0aGluayBpdCdzIHRoZSBzYW1lIGFzIHdoYXQg dGhhdCBpcyBpbiBSRkM3OTI1L0EuMy4NCklmIHBvc3NpYmxlIHdlIHdvdWxkIGxpa2UgdG8gc2Vl IHRoaXMgb3B0aW9uIGluIHRoZSBkcmFmdCB0byBoYW5kbGUgZXhpc3RpbmcgYXBwbGljYXRpb25z Lg0KDQpCUiwNClRpbQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQmVja2Vy IE1hcmt1cyBbbWFpbHRvOk1hcmt1cy5CZWNrZXJAdHJpZG9uaWMuY29tXSANClNlbnQ6IFR1ZXNk YXksIE1hcmNoIDIxLCAyMDE3IDI6NDIgUE0NClRvOiBDYXJzdGVuIEJvcm1hbm4gPGNhYm9AdHpp Lm9yZz47IExhdXJpIFBpaWtpdmkgPExhdXJpLlBpaWtpdmlAYXJtLmNvbT4NCkNjOiBjb3JlIDxj b3JlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtjb3JlXSBkcmFmdC1iZWNrZXItY29yZS1jb2Fw LXNtcy1ncHJzLTA2OiBJZGVudGlmeWluZyBDb0FQIFBEVXMNCg0KSGkuDQoNCj4gPiBUaGUgU01T IGJlYXJlciB3YXMgc3VwcG9ydGVkIGJ5IFdBUCwgd2F5IGJhY2sg4oCUIGhlc2l0YXRlIHRvIGFk bWl0IA0KPiA+IHRoYXQNCj4gSSB3b3JrZWQgb24gaXQgOikgIFRoZXJlIHRoZSBhc3N1bXB0aW9u IHdhcyB0byB1c2UgdGhlIA0KPiBVc2VyLURhdGEtSGVhZGVyIGZvciBwb3J0cyBpbmZvcm1hdGlv biwgYW5kIHRoZSBhc3N1bXB0aW9uIHdhcyB0aGF0IDgtYml0IFNNUyBpcyBjb21tb25wbGFjZS4N Cj4NCj4gT25lIG9mIHRoZSB0aGluZ3MgdGhhdCBjYW1lIHVwIGR1cmluZyBkZXZlbG9wbWVudCBv ZiB0aGlzIGRyYWZ0IGlzIA0KPiB0aGF0IDgtYml0IFNNUyBhY3R1YWxseSBpcyBzbGlnaHRseSBs ZXNzIGNvbW1vbiB0aGFuIHdlIGFzc3VtZWQuICANCj4gSGVuY2UgdGhlIGRpc2N1c3Npb24gb2Yg Ny1iaXQgbWFwcGluZ3MuDQoNCkF0IGxlYXN0IGJhY2sgaW4gMjAxNC8xNSB3ZSBoYWQgdHJvdWJs ZXMgZG9pbmcgOGJpdCBTTVMgd2l0aCBBbmRyb2lkLiBJdCBzZWVtcyBub3dhZGF5cyBpdCBzaG91 bGQgYmUgcG9zc2libGU6DQoNCmh0dHA6Ly9jb2RldGhlb3J5LmluL2FuZHJvaWQtc21zLw0KDQpo dHRwczovL2RldmVsb3Blci5hbmRyb2lkLmNvbS9yZWZlcmVuY2UvYW5kcm9pZC90ZWxlcGhvbnkv U21zTWFuYWdlci5odG1sI3NlbmREYXRhTWVzc2FnZShqYXZhLmxhbmcuU3RyaW5nLCBqYXZhLmxh bmcuU3RyaW5nLCBzaG9ydCwgYnl0ZVtdLCBhbmRyb2lkLmFwcC5QZW5kaW5nSW50ZW50LCBhbmRy b2lkLmFwcC5QZW5kaW5nSW50ZW50KQ0KDQpUaGUgQW5kcm9pZCBBUEkgc2VlbXMgdG8gZ2l2ZSBh Y2Nlc3MgdG8gdGhlIHBvcnQgKD09cHJvdG9jb2wgaWRlbnRpZmllcj8pOg0Kdm9pZCBzZW5kRGF0 YU1lc3NhZ2UgKFN0cmluZyBkZXN0aW5hdGlvbkFkZHJlc3MsDQogICAgICAgICAgICAgICAgU3Ry aW5nIHNjQWRkcmVzcywNCiAgICAgICAgICAgICAgICBzaG9ydCBkZXN0aW5hdGlvblBvcnQsDQog ICAgICAgICAgICAgICAgYnl0ZVtdIGRhdGEsDQogICAgICAgICAgICAgICAgUGVuZGluZ0ludGVu dCBzZW50SW50ZW50LA0KICAgICAgICAgICAgICAgIFBlbmRpbmdJbnRlbnQgZGVsaXZlcnlJbnRl bnQpDQoNCj4gPiBDb3VsZCB0aGUgc3BlYyByZWZlciB0byBXQVAgZGlyZWN0bHk/DQo+IGh0dHA6 Ly93d3cub3Blbm1vYmlsZWFsbGlhbmNlLm9yZy90ZWNoL2FmZmlsaWF0ZXMvd2FwL3dhcC0yNTkt d2RwLQ0KPiAyMDAxMDYxNC1hLnBkZg0KPg0KPiBJZiB3ZSBjYW4gYXZvaWQgdGhhdOKApg0KPg0K PiBJIGRvbuKAmXQgdGhpbmsgaW1wbGVtZW50YXRpb25zIHJpZ2h0IG5vdyBoYXZlIGEgbXVsdGlw bGV4aW5nIHBvaW50IGhlcmUuDQo+IFRoYXQgd291bGQgYmUgbmljZSB0byBoYXZlIHRvIG1ha2Ug Q29BUCBvdmVyIFNNUyB1c2FibGUgd2l0aCBkZXZpY2VzIA0KPiBzdWNoIGFzIHNtYXJ0cGhvbmVz Lg0KPiBJ4oCZbSBqdXN0IG5vdCBzdXJlIGhvdyB0byBkbyB0aGlzIGluIGEgd2F5IHRoYXQgYWNj b21tb2RhdGVzIGV4aXN0aW5nIA0KPiBpbXBsZW1lbnRhdGlvbnMuDQo+DQo+IEdyw7zDn2UsIENh cnN0ZW4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gY29yZSBtYWlsaW5nIGxpc3QNCj4gY29yZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIFRoZSBjb250ZW50cyBvZiB0aGlzIGUtbWFp bCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkIHJl Y2lwaWVudC4gVGhleSBtYXkgbm90IGJlIGRpc2Nsb3NlZCB0byBvciB1c2VkIGJ5IG9yIGNvcGll ZCBpbiBhbnkgd2F5IGJ5IGFueW9uZSBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQu IElmIHRoaXMgZS1tYWlsIGlzIHJlY2VpdmVkIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkg bm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGUgZS1tYWlsIGFuZCBhdHRhY2hlZCBkb2N1 bWVudHMuIFBsZWFzZSBub3RlIHRoYXQgbmVpdGhlciB0aGUgc2VuZGVyIG5vciB0aGUgc2VuZGVy J3MgY29tcGFueSBhY2NlcHQgYW55IHJlc3BvbnNpYmlsaXR5IGZvciB2aXJ1c2VzIGFuZCBpdCBp cyB5b3VyIHJlc3BvbnNpYmlsaXR5IHRvIHNjYW4gb3Igb3RoZXJ3aXNlIGNoZWNrIHRoaXMgZS1t YWlsIGFuZCBhbnkgYXR0YWNobWVudHMuDQo= From nobody Fri Mar 24 07:45:02 2017 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 9B2DD131513 for ; Fri, 24 Mar 2017 07:45: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] 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 KLueDvLubS3t for ; Fri, 24 Mar 2017 07:44:58 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73EE213150D for ; Fri, 24 Mar 2017 07:44:57 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 3559F469DD; Fri, 24 Mar 2017 15:44:55 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 71BE411B; Fri, 24 Mar 2017 15:44:54 +0100 (CET) Received: from hephaistos.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 3EE4610D; Fri, 24 Mar 2017 15:44:54 +0100 (CET) Received: (nullmailer pid 11970 invoked by uid 1000); Fri, 24 Mar 2017 14:44:53 -0000 Date: Fri, 24 Mar 2017 15:44:53 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Carsten Bormann Cc: core Message-ID: <20170324144453.4dhqnclhnsr2g5hq@hephaistos.amsuess.com> References: <0A3A3346-9B5D-48B7-BB52-6DEE39A91200@iii.ca> <41989F03-35A9-4C76-9626-696FE123AFBC@tzi.org> <20170322203049.eswrtgjsatc67bw6@hephaistos.amsuess.com> <37D02847-3B85-4C19-94E1-EDCEDF8A95C6@tzi.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gu2hh7xqycnvzf5d" Content-Disposition: inline In-Reply-To: <37D02847-3B85-4C19-94E1-EDCEDF8A95C6@tzi.org> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [core] RSSI in SenML X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 14:45:01 -0000 --gu2hh7xqycnvzf5d Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 22, 2017 at 10:54:58PM +0100, Carsten Bormann wrote: > > By the name, but not by the use. The review guide after the table (esp. > > point 2) indicate that what is called unit in the document is what SI > > calls quantities, and the presence of Hz, 1/s and Bq shows that as well. >=20 > Hz, 1/s, Bq are units. >=20 > Quantities that can be expressed in these units are [...] Yes, they are units (I was inexact here where I shouldn't have been), but by they are also (in SI terminology) units that have a name, and with that indicate a (ISO) kind of quantity, sometimes even given explicitly in the table. It seems to me that ISO calls "unit" what SI calls "unit with special names", in that ISO unit definition contains the kind of quantity, but I might be interpreting too much into that the SI brochure 8 sec. 2.2.2. > The principles are in ISO80000-1. (Most of us got our degrees before > 2009; I just wish students today would work more with these > fundamentals=E2=80=A6) Thanks for the pointer; this is much more explicit than the SI brochure that was my main reference on this topic so far. > > Maybe that should be clarified in the registry introduction; straw man > > text: "The definitions given here are called units based on common > > language use. In the terminology of the International System of Units, > > they are special unit names, and not only indicate the unit but also the > > described quantity.=E2=80=9D >=20 > That would most definitely not be true with most entries of the current t= able. > Almost all are units in the SI or ISQ. > (Yes, there are some entries that are more on the quantity side of the sp= ectrum.) I still think that the text should be more explicit in that a SenML registered unit implies a kind of quantity (probably all of them, not only the second half; maybe make it into a dedicated column?), but can't really come up with something certainly-correct-yet-concise, and with the ISO definitions in background, that's less important given their definition implies a kind for every unit. Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --gu2hh7xqycnvzf5d Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAljVMOIACgkQOY0REtOk veHRFA/+N6OJIaEiBco839RcTYfYVYuRDMMAx0PzhMH3vGrIgoWVSVzPAk7ZW/wr GCWToveNQzc6F/gAkokGEFy1dPqzdt01VtPhmb7wcpi6igp2y3QKKhq4YlIliLl2 PvR0Fq9RNlMxdyuITe8HTmBONfXMPLW6Hr4tDZdUd3FzQaSPXxfHd4e25CdxYjSJ M2dVVLZGMDbcodOlnyAkNCAK3YJwACRTQGq3bYHazA6iqbZW+/dSS5uI9lHN4ore 3cRfLLqjRd9QGq6FYLgo4qkPru3fUCjvCraXsZ3UUaiZ1bEigtUn3Feg3rrW/NI1 JAwjFxslEndvDFTwuGUNA4HBH8e/2IGLGHFQ8RONf8BCEcWt+3RAwIArgwH0kt4+ 4TQVXEntXpa+qLqwVABrQexN4ZcJqHMuDVBTr5O04WUe7vbIyPywO8+vNtactYDi VqFzlpRnsnASVeuchKkeGXv8yH9VADqFXuiJPneNCxO8jstn4sc24p4IZ8lW/uMF itdD/l+I8GDpmTobT0Mkd1Y0fKuNmjnwNbYrnZFJ1PR0g2btrPWA8J+ODBS+hU+x OWia2qqxS3a3vU9Fm5SGbV9L8CNATNjJvZrhmJn5mW/RJSVxcBvGlxCGtBlqC+xI 13uFHIvGkWfPUrvD54xwAxR1awA7+ZpP51hYOZManXFzXkOaRGw= =3MN5 -----END PGP SIGNATURE----- --gu2hh7xqycnvzf5d-- From nobody Sat Mar 25 11:28:45 2017 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 924821294C8 for ; Sat, 25 Mar 2017 11:28:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149046652359.11947.11559692494952160833.idtracker@ietfa.amsl.com> Date: Sat, 25 Mar 2017 11:28:43 -0700 From: IETF Secretariat Archived-At: Subject: [core] Milestones changed for core WG X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Mar 2017 18:28:44 -0000 Changed milestone "CoAP over TCP, TLS, and WebSockets submitted to IESG for PS", resolved as "Done", added draft-ietf-core-coap-tcp-tls to milestone. URL: https://datatracker.ietf.org/wg/core/about/ From nobody Sun Mar 26 08:04:11 2017 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 EF783129451 for ; Sun, 26 Mar 2017 08:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9b-GSeBhMsM for ; Sun, 26 Mar 2017 08:04:08 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id B87BF129447 for ; Sun, 26 Mar 2017 08:04:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1490540647; d=isode.com; s=june2016; i=@isode.com; bh=KQmbZTGGDSzOKSdoaKT9vn+eNU06I7JeGUqSYZfJlRM=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=iTDJskZstQNiteetvc5RnQgI89/RIEK3kyuUDtjKiRbIaJgcp7WqSkbnixbN5DGMwrFSH6 Pv/awrrEUXF+sJftQnksOc9ppRV+Ks1xlRCPNXUf8Tu0DbCAicJR3WIzcvKjOhBZHRfAjm RX/n3TMlGkNC534qpvWjQJ6S44g4nLE=; Received: from [31.133.134.249] (dhcp-86f9.meeting.ietf.org [31.133.134.249]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 26 Mar 2017 16:04:07 +0100 To: "core@ietf.org WG" From: Alexey Melnikov Message-ID: <58D7D87F.3060900@isode.com> Date: Sun, 26 Mar 2017 16:04:31 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [core] Status of AD review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 15:04:10 -0000 Hi, I have reviewed the document and have a small list of minor issues/nits. I will post them to the mailing list later this week. As none of them are blocking, I will start IETF LC now. Best Regards, Alexey, as AD. From nobody Sun Mar 26 09:19:18 2017 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 B32821270AC; Sun, 26 Mar 2017 09:19:11 -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: 6.48.1 Auto-Submitted: auto-generated Precedence: bulk CC: jaime.jimenez@ericsson.com, core-chairs@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org, Jaime Jimenez , core@ietf.org, alexey.melnikov@isode.com Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <149054515169.11890.6781200443199376096.idtracker@ietfa.amsl.com> Date: Sun, 26 Mar 2017 09:19:11 -0700 Archived-At: Subject: [core] Last Call: (CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets) to Proposed Standard X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 16:19:12 -0000 The IESG has received a request from the Constrained RESTful Environments WG (core) to consider the following document: - 'CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-04-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of the CoAP over UDP protocol includes support for reliable delivery, simple congestion control, and flow control. Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or TLS. This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. It also formally updates [RFC7641] for use with these transports. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Mar 27 00:17:26 2017 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 26A39129411; Mon, 27 Mar 2017 00:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Sp3IUgdhnzW; Mon, 27 Mar 2017 00:17:09 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1E4C12943E; Mon, 27 Mar 2017 00:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v2R7H5CC000363; Mon, 27 Mar 2017 09:17:05 +0200 (CEST) Received: from client-0161.vpn.uni-bremen.de (client-0161.vpn.uni-bremen.de [134.102.107.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vs51r3qGczDHZS; Mon, 27 Mar 2017 09:17:04 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann Date: Mon, 27 Mar 2017 02:17:02 -0500 Cc: lo <6lo@ietf.org>, core , ace@ietf.org X-Mao-Original-Outgoing-Id: 512291822.346343-47e2969abfd4b61dad48cd9e4a28d700 Reply-To: t2trg@irtf.org Content-Transfer-Encoding: quoted-printable Message-Id: <003A0EEA-EAC8-4C64-AFC1-174E8360AB63@tzi.org> References: <149059838707.8031.8688478547594865185.idtracker@ietfa.amsl.com> To: t2trg@irtf.org X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [core] SWORN: Secure Wake on Radio Nudging X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 07:17:12 -0000 I just submitted draft-bormann-t2trg-sworn-00.txt, which describes a = secure way for applications to wake sleepy nodes. For 6lo, it may be of interest as a way to expose a MAC layer feature to = the application layer in a secure way. For CoRE, it shows an unusual way to use the CoAP protocol. For ACE, it is an example of properly authorizing network functions. =20 (It is also an example of using COSE =E2=80=94 it could even use CWT, = but I didn=E2=80=99t specify that part.) (I probably could add other WGs, but the IETF mail server will only = allow so many destination addresses.) I=E2=80=99m looking forward to discussion about this little note, and = what kinds of standards possibly could be derived from it. Gr=C3=BC=C3=9Fe, Carsten > Htmlized: = https://tools.ietf.org/html/draft-bormann-t2trg-sworn-00 >=20 >=20 > Abstract: > Normally off devices (RFC7228) would need to expend considerable > energy resources to be reachable at all times. Instead, MAC layer > mechanisms are often employed that allow the last hop router of the > device to "wake" the device via radio when needed. Activating these > devices even for a short time still does expend energy and thus > should be available to authorized correspondents only. > Traditionally, this has been achieved by heavy firewalling, allowing > only authorized hosts to reach the device at all. This may be too > inflexible for an Internet of Things. >=20 > The present report describes how to use a combination of currently > standardized (or in progress) technologies to securely effect this > authorization. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Mar 27 21:26:40 2017 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 3056A1297E6 for ; Mon, 27 Mar 2017 21:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.463 X-Spam-Level: X-Spam-Status: No, score=-1.463 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 2N_4OzZFBknt for ; Mon, 27 Mar 2017 21:26:36 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFB5129451 for ; Mon, 27 Mar 2017 21:26:35 -0700 (PDT) Received: from WeiGengyuPC (unknown [114.255.40.36]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 76D6B19F394; Tue, 28 Mar 2017 12:26:34 +0800 (HKT) Message-ID: <264053EA5CBF4FDF95FED47F1E283514@WeiGengyuPC> From: "weigengyu" To: "Kepeng Li" , "Carsten Bormann" , "Fossati, Thomas \(Nokia - GB/Cambridge, UK\)" Cc: , References: <3B156DF2-EC3C-4135-94C1-9D1A4ED686B8@on.nokia.com> <79C355A0-79FE-4D90-9907-11F1A65BB5CD@on.nokia.com> <1F568F3E-1195-42E5-B953-81C9713C741B@tzi.org> <4FC5F3D6-DE9E-48ED-A509-DCCEC809CF0E@tzi.org> <505B2B60A1B34322A1E2A081291110D4@WeiGengyuPC> In-Reply-To: Date: Tue, 28 Mar 2017 12:26:48 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [core] Review of draft-becker-core-coap-sms-gprs-06 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 04:26:38 -0000 Hi Kepeng, It is in Chinese. It will be accessed in the Lab of BUPT. I will send you a PDF copy in another email. Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: Kepeng Li Sent: Thursday, March 23, 2017 8:44 PM To: weigengyu ; Carsten Bormann ; Fossati, Thomas (Nokia - GB/Cambridge, UK) Cc: draft-becker-core-coap-sms-gprs@ietf.org ; core@ietf.org Subject: Re: [core] Review of draft-becker-core-coap-sms-gprs-06 Good to hear about that. About the thesis, is it in Chinese or English? If it is published already, can you send us the link? I would be interested to read the thesis, and get some ideas. Also welcome to contribute to the coap-sms draft. Thanks, Kind Regards Kepeng 在 23/03/2017, 2:58 PM， "weigengyu" 写入: >Hi Carsten and all, > >About CoAP/SMS or CoAP/DTLS/SMS, we may do some contributions. > >The following is the abstract of my master course student's thesis, just >completed this month. > >Research and Development of Secure SMS for M2M and CoAP >ABSTRACT >The technology of Internet of Things is changing fast, and the new >application is built on the network environment that based on the limited >network and Internet integration. The Internet Engineering Task Force >(IETF) >CoRE defines a restricted application protocol (CoAP) for a large number >of >nodes and networks in the Internet of Things that rely heavily on >battery-powered, processor-capable, and communication-constrained >capabilities. The Open Mobile Alliance (OMA) proposed a new lightweight >machine-to-machine (LWM2M) communication protocol standard, which clearly >defined the protocol stack based on mobile short message to support the >application of Internet of Things for CoAP / SMS (SMS) or CoAP / DTLS / >SMS >protocol. Datagram Transport Layer Security Protocol (DTLS) has become an >important measure to construct "secure short message". >In this paper , the DTLS protocol based on "secure short message" , the >communication framework and application of CoAP / SMS and CoAP / DTLS / >SMS >using short message are studied and developed. The main contributions of >this paper are studying and developing the secure short message based on >DTLS, and a practical application built on it, which are of great >significance to the study of Internet of Things based on secure short >message. >KEY WORDS: iot、m2m、coap、dtls、sms > >The implementations did by extending Californium (Cf) core and tested on >Andoird. > >Regards, > >Gengyu WEI >Network Technology Center >School of Computer >Beijing University of Posts and Telecommunications >-----原始邮件----- >From: Carsten Bormann >Sent: Wednesday, March 22, 2017 8:49 PM >To: Fossati, Thomas (Nokia - GB/Cambridge, UK) >Cc: draft-becker-core-coap-sms-gprs@ietf.org ; core@ietf.org >Subject: Re: [core] Review of draft-becker-core-coap-sms-gprs-06 > > >> On 22 Mar 2017, at 13:44, Fossati, Thomas (Nokia - GB/Cambridge, UK) >> wrote: >> >> Hi Carsten, >> >> On 21/03/2017 17:28, "Carsten Bormann" wrote: >>> Where do we get a good corpus of CoAP messages? >> >> That's a very good question. >> I was thinking that maybe we could start from pcap captures taken at >>ETSI >> interop events. > >Those would be a faithful mirror of what we wrote in the test >descriptions. >(I’m also not aware of anyone keeping a sizable collection of these.) > >A better “corpus” could be had from dreaming up a few use cases that are >likely to use SMS, design exchanges for those, and capture those on a >platform such as coap.me. > >Grüße, Carsten > >_______________________________________________ >core mailing list >core@ietf.org >https://www.ietf.org/mailman/listinfo/core From nobody Tue Mar 28 09:08:55 2017 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 EB06C120724 for ; Tue, 28 Mar 2017 09:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOWumwWuJkXX for ; Tue, 28 Mar 2017 09:08:51 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80B35127978 for ; Tue, 28 Mar 2017 09:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v2SG8ivF023853 for ; Tue, 28 Mar 2017 18:08:44 +0200 (CEST) Received: from dhcp-8858.meeting.ietf.org (dhcp-8858.meeting.ietf.org [31.133.136.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vswmr10hVzDGss; Tue, 28 Mar 2017 18:08:44 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: <7980F62B-A1B5-45C2-871B-B428BEF339BC@tzi.org> Date: Tue, 28 Mar 2017 11:08:41 -0500 X-Mao-Original-Outgoing-Id: 512410121.470642-64f7ed49990721a7dffb7dff19cc737c Content-Transfer-Encoding: quoted-printable Message-Id: <1FD810EE-546E-491A-82F3-79D445D4649B@tzi.org> References: <7980F62B-A1B5-45C2-871B-B428BEF339BC@tzi.org> To: "core@ietf.org WG" X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [core] CoRE@IETF98 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 16:08:54 -0000 A consolidated slide deck is now available at https://datatracker.ietf.org/doc/slides-98-core-consolidated-slide-set/ Slot leaders: Please check your slides are in (in the newest version you = sent me). See you 6600 seconds... Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Mar 28 11:26:50 2017 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 8BA0F1270A3 for ; Tue, 28 Mar 2017 11:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 PFWLotc1wl8g for ; Tue, 28 Mar 2017 11:26:47 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B4FA1297ED for ; Tue, 28 Mar 2017 11:26:45 -0700 (PDT) X-AuditID: c1b4fb2d-64c6598000005be8-e4-58daaae4b78a Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by (Symantec Mail Security) with SMTP id 3B.0A.23528.4EAAAD85; Tue, 28 Mar 2017 20:26:44 +0200 (CEST) Received: from ESESSMB107.ericsson.se ([169.254.7.125]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0339.000; Tue, 28 Mar 2017 20:26:34 +0200 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= To: "core@ietf.org WG" CC: Alexey Melnikov , Brian Raymor Thread-Topic: CSM for version negotiation Thread-Index: AQHSp/DUEJ7js57bWkGppvXL146aqQ== Date: Tue, 28 Mar 2017 18:26:34 +0000 Message-ID: <03C2B6EE-1A47-47BD-8E19-75EC9FCD0CF5@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/signed; boundary="Apple-Mail=_402CC89E-E07E-4FAA-9449-AD382F44AC64"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKIsWRmVeSWpSXmKPExsUyM2K7me6TVbciDK6cV7LY//4Qk8X9eY+Y LPa9Xc/swOyx89QBNo8lS34yebTu+MsewBzFZZOSmpNZllqkb5fAlXFvwRzWgibbipdXHjE2 MLZYdTFyckgImEhsmribsYuRi0NIYD2jxKump8wQzhJGiRd7+5lBqtgEnCU+PWtkB7FFBNQk Wie9YgOxmQUiJfZeOsEKYgsLqEhM/fGbCaJGU2LS/EusELaexOzZX8DiLAKqEscuzAWbyStg L9E67TIjiM0oICbx/dQaJoiZ4hK3nsxngrhOROLhxdNsELaoxMvH/1ghbCWJRbc/M4Ecyiww hVHi6MqPjBBDBSVOznzCMoFRaBaSWbOQ1c1CUgdRlCTRunkKK4StLbFs4WtmCFtTYn/3chZM cQ2Jzm8ToepNJV4fhZjJLGAtMePXQTYIW1FiSvdD9gWM3KsYRYtTi4tz042M9VKLMpOLi/Pz 9PJSSzYxAiP04JbfujsYV792PMQowMGoxMO7YMmtCCHWxLLiytxDjCpAcx5tWH2BUYolLz8v VUmE99ccoDRvSmJlVWpRfnxRaU5q8SFGaQ4WJXFeh30XIoQE0hNLUrNTUwtSi2CyTBycUg2M nsb1LlZJnjv/Oqq3v3L+dvCvVMa0GdU8U6fe2mecEvtt1o9bhWHfEqYcdH9oL8WetsFrV8TN 15ees2/qvRvLcv2u/xHT+a5C1p8W3FVdZdASXM8lHz6l9dKNS1GHn8yTWrz/oGv3ihlH6xV1 PWSFTP/pVKpdeh3kE8fXrXVTlfPtsi+6MYuClFiKMxINtZiLihMB6lc3RtgCAAA= Archived-At: Subject: [core] CSM for version negotiation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 18:26:48 -0000 --Apple-Mail=_402CC89E-E07E-4FAA-9449-AD382F44AC64 Content-Type: multipart/alternative; boundary="Apple-Mail=_9D3A69B4-EB54-481C-A0EA-F1CAF58F3C31" --Apple-Mail=_9D3A69B4-EB54-481C-A0EA-F1CAF58F3C31 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, This is the github issue about Capability and Settings message for = version negotiation https://github.com/core-wg/coap-tcp-tls/issues/20 = =20 Ciao, - - Jaime Jim=C3=A9nez --Apple-Mail=_9D3A69B4-EB54-481C-A0EA-F1CAF58F3C31 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

This = is the github issue about Capability and Settings message for version = negotiation
https://github.com/core-wg/coap-tcp-tls/issues/20 

Ciao,
- - Jaime Jim=C3=A9nez

= --Apple-Mail=_9D3A69B4-EB54-481C-A0EA-F1CAF58F3C31-- --Apple-Mail=_402CC89E-E07E-4FAA-9449-AD382F44AC64 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMrTCCBe8w ggPXoAMCAQICEGjDnK4TEsyfW0+Qr43kvSowDQYJKoZIhvcNAQEFBQAwOjERMA8GA1UECgwIRXJp Y3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjIwHhcNMTQxMjA5MTMy MzExWhcNMTcxMjA5MTMyMzEwWjBpMREwDwYDVQQKDAhFcmljc3NvbjEXMBUGA1UEAwwOSmFpbWUg Smltw6luZXoxKTAnBgkqhkiG9w0BCQEWGmphaW1lLmppbWVuZXpAZXJpY3Nzb24uY29tMRAwDgYD VQQFEwdlamFqaW1uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz9DiTCOChb1bYXyr VSnjxfVxZ+NGqajFezGGSWAWycgkTkiVdHu7Ek89luoUCU9D8KukeSlzeIFu+TdcANzelWOUqm53 Dh64KfoutxkI1g1FOk8+o45tjBFqw7xknXyEUhZ9/XLqaXuRdw7sCvO91Z05R37hwGhscO7M0fgv lRtWBxaqbC/Ikvjo+PPqt5zpx+GFaqsJ0+4ZQWjrb6I+8e8EAxCpLqB9HmCAztI+zog/tzaSDQdd gQVjLDAndvnKRziQvOrYc5kvJHkXzLcWITDYmi5pZrgNRBJL2poiwSopQPlF5bGjaRYu2WBytXe2 SDEj1viuqpae1vxy7+AdUwIDAQABo4IBwDCCAbwwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2Ny bC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUH AQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUF BzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFs Y2F2Mi5jZXIwJQYDVR0RBB4wHIEaamFpbWUuamltZW5lekBlcmljc3Nvbi5jb20wVQYDVR0gBE4w TDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0 LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1Ud DgQWBBQ58oLpEh/5VlA3MqHd3ggGy2cPpzAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9L NzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBABcJc9IVKYtDtvxGDcoFbAFvNeiH +bRaEu1d9BWRhjtb8ZAU586LmsSwblH+2rbFRtisroKUwq7tZyjQtCrL7Rma0yM74p5PNZ7sGfmz yNZT33hfTZEDo7bjKdaUg0ELBzQvttjIIr7tBVf9cpdOAyOkGn3oqGEomPizRDiKrXBD3V8oMibX nQDb90hg8TJmLb9mqyaRnu1ztxV2585qJUXXPAt1v6qUy23V+tmOE7JzMxrQwa5UupoS/muaQSsR 7Evde7pXBg8jERM7o4VZJIA7LI55ogyb37O7W2zhITXzbHgjQzLoS6MonjIPegCv3pLgdLx0zXhp SUT19qg2LmX1sXTxLJBSJp5eev+x8B7H14taM8FpsAVGLccstjPuxOabdmNNaEvfSBL7GPtQ5Sil DTMdbxhtuFPlP+1p4tPC6A/85YQozqTKCgk28emo8UupTt28DZgfP5b7xpBbnrsA/2aRYpmV2Ay8 BOd8g4O+ZP0WZD9/vPddUDBYPpJiSulKe6uj15vsiiBY4D272VS0dMpwXOvmkKKS/ZAmarywk0hy bl2mb+GW456+N8CESWD4JIHABoXxVAaa0GdGEyL1lSEmw7jOU2h5UAhlhHqPudpSoaLJgqateP2C hWYGv/DwkR9bVpuO8k1ohfjJA4n0qgxfOkWU23sZgo6495KjMIIGtjCCBJ6gAwIBAgIRAKAMy8yb mZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNV BAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIx WjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXs MmGSWShc6A5IEyFboXMZW3lFHso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHf Ozlwk7uwojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FA cLiIEeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgA mInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenI UwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP 5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLxBiA1 41dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wjNnAA6Mqe aTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCBigYIKwYB BQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20w SwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxp YXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYB BAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNv bmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNv bmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYD VR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9 kEKyYZtxJn9cv7S2dUxuUiegmAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg 36XYkNS7Ot0A1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiX g5HMTdOl6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ 6fEAOLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+k XDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5 tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6 n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz9uHr ZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYICljCCApIC AQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVh bCBDQSB2MgIQaMOcrhMSzJ9bT5CvjeS9KjAJBgUrDgMCGgUAoIIBHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAzMjgxODI2MzNaMCMGCSqGSIb3DQEJBDEWBBT4 /IhtMyjTFA7AjKkPKS2vk56IOjBdBgkrBgEEAYI3EAQxUDBOMDoxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhBow5yuExLMn1tPkK+N5L0q MF8GCyqGSIb3DQEJEAILMVCgTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nz b24gTkwgSW5kaXZpZHVhbCBDQSB2MgIQaMOcrhMSzJ9bT5CvjeS9KjANBgkqhkiG9w0BAQEFAASC AQAnvSnt1NFHZG6WqJV2+a89jXDQ8mraKqV+3talcQS6xjoM4HtGvVTnePGbBS/raf5Fs/urmqr/ Qpife6SDdJfkjMAy5QhSi/x85yy4jOdqePP5SjpAxIsPB9zyxx12Xu2rPTrUXOxNz+q1y5mZJZ9z b/dCRmQv96vjc45ueQLii0R/KeJ0XhFBBCw+wg78uBUXJjkc2WH725H8OSE/zlFsQV90+UEbiFTV CBWumNV4sQt9ceJ0Bkl2mKPIA9zbvh45RRFGBV8V0npraEeLtimSRolwwVwncaIRt/SBlpPrvYrn H/Vy1KNurZdN/z603nJpzBF+FP48BqipyqXMBAOIAAAAAAAA --Apple-Mail=_402CC89E-E07E-4FAA-9449-AD382F44AC64-- From nobody Tue Mar 28 11:44:42 2017 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 913BD1270FC for ; Tue, 28 Mar 2017 11:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_HELO_PASS=-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=microsoft.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 hbvEjXqemM7H for ; Tue, 28 Mar 2017 11:44:38 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0135.outbound.protection.outlook.com [104.47.38.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37241124BFA for ; Tue, 28 Mar 2017 11:44:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QzkBClSh11RzFmXRF8FwbcEh3BBlOOXYnoklKp00Iuw=; b=nzHfJkBHS1kE4lhkD8wBtQtAgUznSgQ9eFcPmfBmhtKZa21tZ5m39G1x+sUgimLIRmA+bolpKDbkL485sqQdCQ4O9uUuarSIfCI0kEbZ0NnhyrqE2aXgcKxQXuklG5+jY9/9pxbwWY78wjCAg1O179k7wV1cyPGJvBSXL6Z5NWg= Received: from DM2PR21MB0107.namprd21.prod.outlook.com (10.161.141.143) by DM2PR21MB0105.namprd21.prod.outlook.com (10.161.141.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.0; Tue, 28 Mar 2017 18:44:36 +0000 Received: from DM2PR21MB0107.namprd21.prod.outlook.com ([10.161.141.143]) by DM2PR21MB0107.namprd21.prod.outlook.com ([10.161.141.143]) with mapi id 15.01.1019.005; Tue, 28 Mar 2017 18:44:36 +0000 From: Brian Raymor To: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= , "core@ietf.org WG" CC: Alexey Melnikov Thread-Topic: CSM for version negotiation Thread-Index: AQHSp/DUEJ7js57bWkGppvXL146aqaGqleGQ Date: Tue, 28 Mar 2017 18:44:35 +0000 Message-ID: References: <03C2B6EE-1A47-47BD-8E19-75EC9FCD0CF5@ericsson.com> In-Reply-To: <03C2B6EE-1A47-47BD-8E19-75EC9FCD0CF5@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ericsson.com; dkim=none (message not signed) header.d=none; ericsson.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [31.133.130.69] x-microsoft-exchange-diagnostics: 1; DM2PR21MB0105; 7:U/64vyBgAmZDrxZke/rbaNGcdBrcEMR/vhys1ZvkN3sTYeNRNMHlWq50U04laK4AQj8iK29LJO8C1dUx6IYxUzd0tGStW25ibP4FMnc2wRIx19eHGf+gKawC/lygPZHe0ySP2ZY3x6t8tc8Zyq4a/rtZZKudLnbPfw/VSPW38M0NDcKq/XplYX7BI604G7d0lZ2Kgxb2IO1nPEm1wuBgO8vmhnWh+Ny8tWEjqneXPnI8lhqrrkzXw8YQYjXDJ00r662gopKuT4u1JgyHtQsigMzexG2re6NTRkqUINmIvISS9pES73D5gSxfl88TFEc9zEn5FSzET/cQX4yDyOIQtH73jM6K8LwmPT00VfdlL20= x-ms-office365-filtering-correlation-id: d7ebc9df-07e0-4eb9-d073-08d4760a7bc8 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423064)(201703031133070); SRVR:DM2PR21MB0105; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(166708455590820)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040439)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006026)(93001026)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123558025)(201703131423064)(201702281528064)(201703011903064)(201703061421064)(20161123560025)(20161123564025)(20161123555025)(6072148); SRVR:DM2PR21MB0105; BCL:0; PCL:0; RULEID:; SRVR:DM2PR21MB0105; x-forefront-prvs: 0260457E99 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400002)(39400400002)(39410400002)(39860400002)(39450400003)(39840400002)(377454003)(6436002)(4326008)(2906002)(606005)(19609705001)(25786009)(6506006)(77096006)(54356999)(81166006)(33656002)(76176999)(8676002)(5660300001)(50986999)(53546009)(3480700004)(9686003)(53936002)(54896002)(6306002)(55016002)(99286003)(7906003)(236005)(6246003)(2900100001)(38730400002)(8666007)(74316002)(7696004)(2950100002)(189998001)(7736002)(229853002)(3280700002)(3660700001)(66066001)(10290500002)(8990500004)(86362001)(10090500001)(8936002)(122556002)(3846002)(102836003)(6116002)(790700001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR21MB0105; H:DM2PR21MB0107.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR21MB0107F390128FF7E009EA2B3A83320DM2PR21MB0107namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2017 18:44:35.8796 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR21MB0105 Archived-At: Subject: Re: [core] CSM for version negotiation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 18:44:40 -0000 --_000_DM2PR21MB0107F390128FF7E009EA2B3A83320DM2PR21MB0107namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlcmXigJlzIGFsc28gYSByZWxhdGVkIGlzc3VlIGZvciB2ZXJzaW9uaW5nIHRoZSBBTFBOIGlk ZW50aWZpZXIgKENvQVArVExTKSAgLSBodHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9jb2FwLXRj cC10bHMvaXNzdWVzLzQuDQoNCg0KRnJvbTogSmFpbWUgSmltw6luZXogW21haWx0bzpqYWltZS5q aW1lbmV6QGVyaWNzc29uLmNvbV0NClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDI4LCAyMDE3IDE6Mjcg UE0NClRvOiBjb3JlQGlldGYub3JnIFdHIDxjb3JlQGlldGYub3JnPg0KQ2M6IEFsZXhleSBNZWxu aWtvdiA8YWFtZWxuaWtvdkBmYXN0bWFpbC5mbT47IEJyaWFuIFJheW1vciA8QnJpYW4uUmF5bW9y QG1pY3Jvc29mdC5jb20+DQpTdWJqZWN0OiBDU00gZm9yIHZlcnNpb24gbmVnb3RpYXRpb24NCg0K SGksDQoNClRoaXMgaXMgdGhlIGdpdGh1YiBpc3N1ZSBhYm91dCBDYXBhYmlsaXR5IGFuZCBTZXR0 aW5ncyBtZXNzYWdlIGZvciB2ZXJzaW9uIG5lZ290aWF0aW9uDQpodHRwczovL2dpdGh1Yi5jb20v Y29yZS13Zy9jb2FwLXRjcC10bHMvaXNzdWVzLzIwDQoNCkNpYW8sDQotIC0gSmFpbWUgSmltw6lu ZXoNCg0K --_000_DM2PR21MB0107F390128FF7E009EA2B3A83320DM2PR21MB0107namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+VGhlcmXigJlzIGFsc28gYSByZWxhdGVkIGlzc3VlIGZvciB2ZXJzaW9uaW5nIHRoZSBB TFBOIGlkZW50aWZpZXIgKENvQVAmIzQzO1RMUykgJm5ic3A7LQ0KPGEgaHJlZj0iaHR0cHM6Ly9n aXRodWIuY29tL2NvcmUtd2cvY29hcC10Y3AtdGxzL2lzc3Vlcy80Ij5odHRwczovL2dpdGh1Yi5j b20vY29yZS13Zy9jb2FwLXRjcC10bHMvaXNzdWVzLzQ8L2E+LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21w b3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8 c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEphaW1lIEppbcOp bmV6IFttYWlsdG86amFpbWUuamltZW5lekBlcmljc3Nvbi5jb21dDQo8YnI+DQo8Yj5TZW50Ojwv Yj4gVHVlc2RheSwgTWFyY2ggMjgsIDIwMTcgMToyNyBQTTxicj4NCjxiPlRvOjwvYj4gY29yZUBp ZXRmLm9yZyBXRyAmbHQ7Y29yZUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5DYzo8L2I+IEFsZXhleSBN ZWxuaWtvdiAmbHQ7YWFtZWxuaWtvdkBmYXN0bWFpbC5mbSZndDs7IEJyaWFuIFJheW1vciAmbHQ7 QnJpYW4uUmF5bW9yQG1pY3Jvc29mdC5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IENTTSBm b3IgdmVyc2lvbiBuZWdvdGlhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkhpLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhpcyBpcyB0aGUgZ2l0aHViIGlzc3VlIGFib3V0IENhcGFiaWxpdHkgYW5kIFNldHRp bmdzIG1lc3NhZ2UgZm9yIHZlcnNpb24gbmVnb3RpYXRpb248bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vY29yZS13 Zy9jb2FwLXRjcC10bHMvaXNzdWVzLzIwIj5odHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9jb2Fw LXRjcC10bHMvaXNzdWVzLzIwPC9hPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaWFvLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4tIC0gSmFpbWUgSmltw6luZXo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DM2PR21MB0107F390128FF7E009EA2B3A83320DM2PR21MB0107namp_-- From nobody Thu Mar 30 02:40:39 2017 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 1A59E1241FC for ; Thu, 30 Mar 2017 02:40:38 -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] 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 uqnjP0SjNfDn for ; Thu, 30 Mar 2017 02:40:35 -0700 (PDT) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6A35126C89 for ; Thu, 30 Mar 2017 02:40:35 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id C057846A5E for ; Thu, 30 Mar 2017 11:40:32 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 4C19974 for ; Thu, 30 Mar 2017 11:40:31 +0200 (CEST) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 33FE83BE for ; Thu, 30 Mar 2017 11:40:31 +0200 (CEST) Received: (nullmailer pid 13310 invoked by uid 1000); Thu, 30 Mar 2017 09:40:29 -0000 Date: Thu, 30 Mar 2017 11:40:29 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: core@ietf.org Message-ID: <20170330094029.a777jxax76e6c6rz@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xuhpctcfvl6z32qa" Content-Disposition: inline User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: [core] Request-Tag follow-up from WG meeting X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 09:40:38 -0000 --xuhpctcfvl6z32qa Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello working group, this is a follow-up on the Request-Tag draft[1] that G=F6ran presented in the core WG meeting on Tuesday (thanks for standing in, and sorry for the trouble). I'd like to clarify two things that came up in the questions afterwards: a. This is option would only be used in where Block1 option is set by the client. b. Yes, the window of attack *is* very small, and the examples are contrived, but nevertheless, that keeps OSCOAP from claiming security for bodies. c. Like ETag, this is only secure as long as the chosen tag is unique within the (security context, URI) pair. Questions I'd like to ask the working group are: 1. Do you have any better idea on how to protect Block1 bodies? 2. Request-Tag technically allows distinguishing simultaneous legitimate Block1 operations. Do you see reasons not to allow that? (It would greatly help proxies, especially those forwarding OSCOAP, because without, they have to either spool request bodies or deny forwarding to other clients while waiting for data). 3. DTLS users, would you use that? Would DTLS provide any guarantees on old packages not being acceptable any more after some other package has been sent or acknowledged, epochs maybe? (Short of that, the option would incur 1 + ceil(log256(number of Block1 operations done)) bytes of options overhead; that approximation resets to 0 whenever the client is sure the server won't accept old messages any more.) 4. Is this something that can become a WG document? Should the "how to use this to protect bodies" (currently "For inclusion in OSCOAP") part be in object-security or here? Please give feedback. Thanks Christian [1]: https://tools.ietf.org/html/draft-amsuess-core-request-tag-00 --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --xuhpctcfvl6z32qa Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAljc0ogACgkQOY0REtOk veGyoBAAsCVRrp2wpZ0jTyf+Ff38FZ6vwVRnBuchadLTy6kh5+Hy43P+MhcE5z6r /jpa14W1T4SiH0lijMj7h31iHxqvsDAsRwV7SfnSXeU9eQmHCvrvZMrcTMAZ3sr4 X7fGmsIwzMpII3i8gLKTai52WLT5Z/Kix172Ps+C032LOx+D5keOtMD9GCI8tibR 9aAouqIEUCoQcPysxtVI+K8TaRbYsShvas2xVWu3rIhQQjTfNgscArbhQbuG5MCb JOw4O9Y28LIr50KRoLlPCzwV1GBInFPJ3dEUemdL9DyK/V4lOvnu91vgtElCh7d/ 6tjmNsAbuFLn2Npmq68v33IusMM8CY69KewDK4nBRspTQyvmFRY8XPmKghM26qWr wQseZ0mbGYxo0/CuegLBvMzUI4HnsrL04h1t2BKin06VEysxVIKB/F4K8yabr0DF HinsdIrKBk41zioVpPIwhL9lyArQ8D8eZbkpbHXijGtJDf5RijsGDsz1J8JdX/AV kRVp6Kedz77uJ8VCPrUdyR6hwO7SPjLK80gspx2nCW+HgtyfIGZkdOm72lYddvqT vtZ504yVom/MtwxBbXTtT3qxxYX3LIOfKKSzM+DnmPvxsKK4fhuVLo0WT9AYh0EA qTzzguu/x1q1NJ15JlCQvvBdQtCXeLEdncC5IiKaxhuZNMdFumA= =QurX -----END PGP SIGNATURE----- --xuhpctcfvl6z32qa-- From nobody Thu Mar 30 14:15:13 2017 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 8EE10129483; Thu, 30 Mar 2017 14:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 PzL3VSf7qfr7; Thu, 30 Mar 2017 14:15:08 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EA911295EA; Thu, 30 Mar 2017 14:14:36 -0700 (PDT) X-AuditID: c1b4fb3a-4d72198000003958-9c-58dd753a8d1b Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by (Symantec Mail Security) with SMTP id C2.BD.14680.A357DD85; Thu, 30 Mar 2017 23:14:34 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.242]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0339.000; Thu, 30 Mar 2017 23:14:32 +0200 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: Christian Groves , core CC: "draft-ietf-core-senml@ietf.org" Thread-Topic: SenML: mandatory to understand extensions Thread-Index: AQHSqZqfzmx6clkGJkmb76JGWY9hIA== Date: Thu, 30 Mar 2017 21:14:32 +0000 Message-ID: <9B32F09A-B523-4111-8906-A33FC9C0233B@ericsson.com> References: <148912314641.5730.14064447847116030290.idtracker@ietfa.amsl.com> <853bbfad-debb-f40c-344c-cff8bd9a89cd@gmail.com> In-Reply-To: <853bbfad-debb-f40c-344c-cff8bd9a89cd@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <473698CD58AEC54288EAFD8BC75AFCB3@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBIsWRmVeSWpSXmKPExsUyM2K7uq5V6d0Ig2ut0hbXmoMs9r1dz2zx 890SZgdmj52z7rJ7LFnykymAKYrLJiU1J7MstUjfLoErY+KaA8wFp2UqVk6wbWC8K9bFyMkh IWAi0XpwL1sXIxeHkMB6RolzZ7cxQjhLGCX6Xp5nAqliE7CXmLzmIyOILSLgLDHj5gZ2EJtZ wFXi99qbYHFhASOJIx8PskLUmEusbNsL1MsBZOtJ7DsTCxJmEVCV+LbzMFgJL9DIzeeOsUPs amCUuNt4BWwOp4CtxIqpr1lAbEYBMYnvp9YwQewSl7j1ZD4TxNUCEkv2nGeGsEUlXj7+xwph K0msPbydBaJeT+LG1ClsELa1RPuK2VBxbYllC18zQxwhKHFy5hOWCYxis5CsmIWkfRaS9llI 2mchaV/AyLqKUbQ4tbg4N93ISC+1KDO5uDg/Ty8vtWQTIzC+Dm75bbWD8eBzx0OMAhyMSjy8 C9zvRgixJpYVV+YeYpTgYFYS4e2wBgrxpiRWVqUW5ccXleakFh9ilOZgURLnddh3IUJIID2x JDU7NbUgtQgmy8TBKdXAqMt1bpnFyT1iN5YvXHr1ne42lnDF5Z/EVlhL1pRJpIZdmyiQmbrK Oa6uqbCymN8hLnfX00Xc8d7ebzr9G85ebig6MpFpYQjfPrVoR6+7Hl8+sVuvqDZ4tf9BuFyz D3+6sE5qjb2BemblibzADfKeWxfv/njSobqbTTRFLOvcpdktmSemhp9TYinOSDTUYi4qTgQA DK4/f6sCAAA= Archived-At: Subject: [core] SenML: mandatory to understand extensions X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 21:15:10 -0000 Hi all, I've been discussing this issue with mandatory to understand extensions (ne= w attributes) for SenML at the IETF meeting with bunch of people, and seems= that the preference would be to not use media-type parameters for this, bu= t indicate in the SenML Pack, in attribute names, if there are extensions t= hat can't be ignored (i.e., second option discussed in the draft [1]). Apparently the media type parameters are in generally currently ignored so = they would not actually provide this capability reliably. Also, media type = extension would only help in cases where the media types are available, but= not in cases where a SenML is distributed in a file or dumped to database = (without the media-type information). Therefore, we'd suggest to pick a character that is safe for attribute name= s (e.g., "z") and use that in the beginning of the name, or after "b" for b= ase attributes, to indicate an attribute is mandatory to understand. Altern= atively we could pick special character like "+" or "_" but some concerns w= ere raised that e.g., some database systems may not like using these in key= s. We're planning to discuss this tomorrow at the CoRE session, but please com= ment already here on the list if you have any concerns / questions on this. Thanks, Ari [1] https://tools.ietf.org/html/draft-groves-core-senml-options-00#section-= 3.2 > On 09 Mar 2017, at 23:55, Christian Groves wrote= : >=20 > Hello all, >=20 > FYI I've submitted a draft to discuss the problem of the behaviour of end= points if they encounter an unknown SenML attribute such as BTO. This was r= aised at the Seoul meeting. >=20 > Regards, Christian >=20 >=20 >=20 > -------- Forwarded Message -------- > Subject: New Version Notification for draft-groves-core-senml-options-00= .txt > Date: Thu, 9 Mar 2017 21:19:06 -0800 > From: internet-drafts@ietf.org > To: Weiwei Yang , Christian Groves , Christian Groves >=20 >=20 >=20 > A new version of I-D, draft-groves-core-senml-options-00.txt > has been successfully submitted by Christian Groves and posted to the > IETF repository. >=20 > Name: draft-groves-core-senml-options > Revision: 00 > Title: SenML Options > Document date: 2017-03-10 > Group: Individual Submission > Pages: 13 > URL: https://www.ietf.org/internet-drafts/draft-groves-core-se= nml-options-00.txt > Status: https://datatracker.ietf.org/doc/draft-groves-core-senml-= options/ > Htmlized: https://tools.ietf.org/html/draft-groves-core-senml-optio= ns-00 >=20 >=20 > Abstract: > SenML [I-D.ietf-core-senml] defines an initial set of base and > regular attributes which are tied to a particular version of SenML. > SenML also allows the definition of additional attributes by > extending the syntax with a new label. Allowing the extension of > attributes brings the problem of how do endpoints negotiate whether > the new attribute can be used or not? This document discusses the > issue and proposes some potential solutions to this issue. >=20 > = =20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 > . >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Fri Mar 31 01:07:36 2017 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 7B34E1294B1 for ; Fri, 31 Mar 2017 01:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.396 X-Spam-Level: X-Spam-Status: No, score=-5.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796] 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 jbMaAUj7VaNl for ; Fri, 31 Mar 2017 01:07:32 -0700 (PDT) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EA38129504 for ; Fri, 31 Mar 2017 01:07:31 -0700 (PDT) Received: from mfilter25-d.gandi.net (mfilter25-d.gandi.net [217.70.178.153]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id B2FF741C0BB for ; Fri, 31 Mar 2017 10:07:29 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter25-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter25-d.gandi.net (mfilter25-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id szld_M7TKr5K for ; Fri, 31 Mar 2017 10:07:28 +0200 (CEST) X-Originating-IP: 199.72.36.3 Received: from [10.59.15.57] (unknown [199.72.36.3]) (Authenticated sender: alex@ackl.io) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 0FD8941C07E for ; Fri, 31 Mar 2017 10:07:27 +0200 (CEST) From: Alexander Pelov Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: <5303DD60-AA48-402C-85BC-710A6000B6CD@ackl.io> Date: Fri, 31 Mar 2017 03:07:25 -0500 To: Core X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [core] Slot request for SID discussion X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 08:07:35 -0000 Dear Chairs, dear all, During this very productive IETF week we=E2=80=99ve had the opportunity = to discuss the SID draft and its use on several occasions. First, we=E2=80=99ve had a meeting with participants of the NETMOD WG = (thanks to Andy), with a huge interest - 17 people. The topic was - = binary Encoding for YANG, which boiled down to YANG-CBOR and SID.=20 After the rich discussions, we went to IANA to see some of the = modifications that came up earlier and during this meeting. The main = point is simplifying the SID allocation procedure and the naming. We now = have blocks of MegaSIDs (1MegaSID =3D 1 000 000 SIDs) which are = subdivided into smaller ranges of SIDs. We=E2=80=99d like to request a slot of 5-10 min on today=E2=80=99s = meeting to present these advancements and to see if the WG agrees on = some of the proposed changes. Michel and Alexander From nobody Fri Mar 31 07:43:40 2017 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 5E2A0129645 for ; Fri, 31 Mar 2017 07:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1LDsCbpuCFh for ; Fri, 31 Mar 2017 07:43:37 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F014012995B for ; Fri, 31 Mar 2017 07:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v2VEhVFt020675 for ; Fri, 31 Mar 2017 16:43:31 +0200 (CEST) Received: from dhcp-8858.meeting.ietf.org (dhcp-8858.meeting.ietf.org [31.133.136.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vvkl64slGzDHMP; Fri, 31 Mar 2017 16:43:30 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: <1FD810EE-546E-491A-82F3-79D445D4649B@tzi.org> Date: Fri, 31 Mar 2017 09:43:28 -0500 X-Mao-Original-Outgoing-Id: 512664208.78968-ec174ceb0429e26e9c67eb3e501e53ad Content-Transfer-Encoding: quoted-printable Message-Id: References: <7980F62B-A1B5-45C2-871B-B428BEF339BC@tzi.org> <1FD810EE-546E-491A-82F3-79D445D4649B@tzi.org> To: "core@ietf.org WG" X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [core] CoRE@IETF98 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 14:43:39 -0000 On 28 Mar 2017, at 11:08, Carsten Bormann wrote: >=20 > A consolidated slide deck is now available at >=20 > = https://datatracker.ietf.org/doc/slides-98-core-consolidated-slide-set/ Updated now for today=E2=80=99s meeting. (Slot leaders: Please check.) (We're still waiting for the SID/IANA slides.) Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Mar 31 13:28:08 2017 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 44BA5129968 for ; Fri, 31 Mar 2017 13:28:06 -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] 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 gvw-BuLWzf7o for ; Fri, 31 Mar 2017 13:28:04 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 594E212947B for ; Fri, 31 Mar 2017 13:28:04 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id E44D646A86; Fri, 31 Mar 2017 22:28:01 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 2689674; Fri, 31 Mar 2017 22:28:01 +0200 (CEST) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id F0019406; Fri, 31 Mar 2017 22:28:00 +0200 (CEST) Received: (nullmailer pid 2635 invoked by uid 1000); Fri, 31 Mar 2017 20:27:59 -0000 Date: Fri, 31 Mar 2017 22:27:59 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Carsten Bormann Cc: core@ietf.org Message-ID: <20170331202759.dfhqgplc5novmwty@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5zxlb2eodq4gc5xh" Content-Disposition: inline User-Agent: NeoMutt/20170306 (1.8.0) Archived-At: Subject: [core] Firmware upload: rolling MACs X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 20:28:06 -0000 --5zxlb2eodq4gc5xh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Carsten, in today's WG meeting, you mentioned a bar BoF about a rolling MAC mechanism that could be employed in firmware uploads to make them actionable as data comes in. Could you elaborate in a few words? In my understanding, inner blockwise transfers (with either the draft-01 block chaining or a Request-Tag equivalent) already provide that -- that's why I care so much about inner-blockwise. Thanks Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --5zxlb2eodq4gc5xh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAljeu8MACgkQOY0REtOk veFm1A/9Ey2Eu03yl8+6foYmQXJoyO2TW7mjVPhAYTbyFvCo2Vu5r6plf7GMx9C6 Ro/nd5yv+QYDv5WO9WEcT8o5eMrfDuCHcHQurpyrrThJpqyUHhjbmSKvBRUPAjZR NQRWedZgDa/sQ/gBY0fmJIcnZ+uDYsWRFvN9k7syeUWai+604xQ/KXSOI4CreFJ4 K0o2691jIOV2U4hJ1LOV1FDgEuaC+3mzyeO+LxfQBZYwLSEtdJ7L65tO74Nyd+/r o4oTFd/5q95qCbNumPA8oKQoek8214gnzqPTLxKlk5tJj1C7vVbURpeVByVSWCV/ O2ZRJ8p5RhPb5gS/98/UKxXtirE5zwdAwErWaPhQBjgjsUc7ysNFcUG0T5K1sLs8 u40y2XszHfvHuxR7FrO0J/m6fyUabnOekQySEjNk9pEJ5v1OeWy6FVMuPlJvdh1B fpjfn4eACFxIaHM8NPzn2DcjZcuuN6aEfT3ieTyjeTXo8Dvt+nob9CCUmdVUQ2Ls PZ94dXbWplwuEkJSH0ktLJJd9J4pIvT+u/kTbdWYSLqHTtvERO71TQ1SYQgFv1kZ LhYRMIfN3u7EOo4tnqdEzFmy+QXO4j6XeHibME+5kyzgffBboHVZ5wO35vZsSKsd HOQFBOF2s9egZFlUnlJyd5mG98IH2l0wpqfnPW84Be/w0xEHwnk= =yy0k -----END PGP SIGNATURE----- --5zxlb2eodq4gc5xh--