From peter.van.der.stok@philips.com Mon Apr 2 02:02:48 2012 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 A9E4621F88E6 for ; Mon, 2 Apr 2012 02:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.686 X-Spam-Level: X-Spam-Status: No, score=-5.686 tagged_above=-999 required=5 tests=[AWL=0.912, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePVy79ik8Nmq for ; Mon, 2 Apr 2012 02:02:46 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id 306CD21F88E2 for ; Mon, 2 Apr 2012 02:02:40 -0700 (PDT) Received: from mail67-tx2-R.bigfish.com (10.9.14.249) by TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id 14.1.225.23; Mon, 2 Apr 2012 09:02:40 +0000 Received: from mail67-tx2 (localhost [127.0.0.1]) by mail67-tx2-R.bigfish.com (Postfix) with ESMTP id 0DAA24009F; Mon, 2 Apr 2012 09:02:40 +0000 (UTC) X-SpamScore: -13 X-BigFish: VPS-13(zz217bL15d6O9251Jc85fhzz1202hzz8275bhz2dh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI Received: from mail67-tx2 (localhost.localdomain [127.0.0.1]) by mail67-tx2 (MessageSwitch) id 1333357357946992_15650; Mon, 2 Apr 2012 09:02:37 +0000 (UTC) Received: from TX2EHSMHS042.bigfish.com (unknown [10.9.14.253]) by mail67-tx2.bigfish.com (Postfix) with ESMTP id D6CF12040A; Mon, 2 Apr 2012 09:02:37 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by TX2EHSMHS042.bigfish.com (10.9.99.142) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 2 Apr 2012 09:02:36 +0000 Received: from 011-DB3MMR1-012.MGDPHG.emi.philips.com (10.128.28.96) by 011-DB3MMR1-009.MGDPHG.emi.philips.com (10.128.28.48) with Microsoft SMTP Server (TLS) id 14.1.355.3; Mon, 2 Apr 2012 10:04:31 +0100 Received: from 011-DB3MPN1-061.MGDPHG.emi.philips.com ([169.254.1.48]) by 011-DB3MMR1-012.MGDPHG.emi.philips.com ([10.128.28.96]) with mapi id 14.01.0355.003; Mon, 2 Apr 2012 10:02:04 +0100 From: "Stok, Peter van der" To: core WG , Carsten Bormann Thread-Topic: roadmap draft Thread-Index: Ac0Qr0eWvp/jsXYIRVuZxyBc1Qnrcw== Date: Mon, 2 Apr 2012 09:04:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [82.95.140.48] Content-Type: multipart/alternative; boundary="_000_A31CB84F6F0BFC449C6807DF752A715B049A4D011DB3MPN1061MGDP_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: [core] roadmap draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 02 Apr 2012 09:02:48 -0000 --_000_A31CB84F6F0BFC449C6807DF752A715B049A4D011DB3MPN1061MGDP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear wg and chairs, The roadmap draft is a very welcome document that tries to put some order i= n the possibly inconsistent set of documents produced by the wg members. A = danger exists that this document will be the means by which the members wil= l learn the probability that a document will go to wg or rfc status. A poss= ibly good guard is to give the draft writers fair access to the contents of= the roadmap draft. One of the things that makes it difficult to judge the validity of a draft = is the large number of application areas and network architectures that coa= p addresses. Just to name a few obvious ones: * Stand alone lowpan without edge router * Stand alone lowpan without edge router * Connected lowpan with edge router Within these three possible network architectures there is the distinction = between managed network (e.g. office infra structure) and unmanaged network= (e.g. residential). I think it would be good to characterize drafts to see= which architecture they aim at. These categories are also necessary in my= opinion to come to security solutions which are lean but adequate for the = environment for which they are intended. My suggestion is to make the roadmap draft a document that describes attrib= utes of each draft with a table that can be provided by the authors of the = draft, and that authors also have access to the text describing their draft= s but within well defined space limits. One of the topics of this descripti= on should be a description how the draft extends other core drafts or propo= ses a different solution to the same problem without discussion of the why = and how. Peter van der Stok mailto: Peter.van.der.Stok@philips.com ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_A31CB84F6F0BFC449C6807DF752A715B049A4D011DB3MPN1061MGDP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear wg and chairs,

 

The roadmap draft is a very welcome document that tr= ies to put some order in the possibly inconsistent set of documents produce= d by the wg members. A danger exists that this document will be the means b= y which the members will learn the probability that a document will go to wg or rfc status. A possibly good g= uard is to give the draft writers fair access to the contents of the roadma= p draft.

One of the things that makes it difficult to judge t= he validity of a draft is the large number of application areas and network= architectures that coap addresses. Just to name a few obvious ones:

·       = ;  Stand alone lowpan without edge router

·      &nbs= p;  Stand alone lowpan without edge router

·       =   Connected lowpan with edge router

Within these three possible network architectures th= ere is the distinction between managed network (e.g. office infra structure= ) and unmanaged network (e.g. residential). I think it would be good to cha= racterize drafts to see which architecture they aim at.  These categories are also necessary in my opinion to co= me to security solutions which are lean but adequate for the environment fo= r which they are intended.

My suggestion is to make the roadmap draft a documen= t that describes attributes of each draft with a table that can be provided= by the authors of the draft, and that authors also have access to the text= describing their drafts but within well defined space limits. One of the topics of this description should be= a description how the draft extends other core drafts or proposes a differ= ent solution to the same problem without discussion of the why and how.

 

 

Peter van der Stok

mailto: Peter.van.der.Stok@philips.com

 



The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
--_000_A31CB84F6F0BFC449C6807DF752A715B049A4D011DB3MPN1061MGDP_-- From matthieu.vial@non.schneider-electric.com Mon Apr 2 03:21:11 2012 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 EC64221F8911 for ; Mon, 2 Apr 2012 03:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PB+tgGi7L7gh for ; Mon, 2 Apr 2012 03:21:11 -0700 (PDT) Received: from mailX01.eud.schneider-electric.com (mailx01.eud.schneider-electric.com [205.167.7.35]) by ietfa.amsl.com (Postfix) with ESMTP id EBD1421F86AD for ; Mon, 2 Apr 2012 03:21:10 -0700 (PDT) Received: from ATEUI01.schneider-electric.com ([10.198.14.9]) by mailX01.eud.schneider-electric.com with ESMTP id 2012040212144315-190177 ; Mon, 2 Apr 2012 12:14:43 +0200 To: Carsten Bormann MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 From: matthieu.vial@non.schneider-electric.com Message-ID: Date: Mon, 2 Apr 2012 12:21:06 +0200 X-MIMETrack: Serialize by Router on ATEUI01.Schneider-Electric.com/T/SVR/Schneider at 02/04/2012 12:22:09, Serialize complete at 02/04/2012 12:22:09, Itemize by SMTP Server on AXEU1OUT.schneider-electric.com/X/SVR/SEIxtra at 02/04/2012 12:14:43, Serialize by Router on AXEU1OUT.schneider-electric.com/X/SVR/SEIxtra at 02/04/2012 12:14:45, Serialize complete at 02/04/2012 12:14:45 Content-Type: text/plain; charset="US-ASCII" Cc: 'core' Subject: [core] mirroring as observe X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 02 Apr 2012 10:21:12 -0000 Hi Carsten, I'm reading your mirroring proposition with interest. Your approach is close to the Publish option in the sense that you're mirroring on a per-resource basis. But I like it better because the caching model is preserved and no new option is required. This way I understand how Observe can work for sleepy devices because the creation of the observation relationship is actually controlled by the sleepy with a POST request. I still don't understand Zach's point that the bare Observe option can work for sleepy devices, as is. For me the Observe relationship is just too fragile with a sleepy server. The client can only recreate the observation relationship at very specific and undefined points in time since the device is sleeping most of the time. The mirror proxy draft is mirroring on a per-device basis. I'm very concerned with resource discovery of mirrored resources. IMO a separate explicit registration makes life easier for that. Also I think it is less efficient to mirror resources with static content (manufacturer, model) using observe because the sleepy needs to send notifications to each static resource just to keep the relationships alive. With a top entry for the registration, you can keep all mirrored sub-resources alive with a single update request. By the way I need to find a new name for the mirror proxy because it's not a real proxy. Just a short poll. What folks think of - Mirror server - Mirroring Point - Mail Box - new idea? When modelling mirroring as observe, the proxy and sleepy behave more like a typical proxy and server. Yet the proxy only supports GET requests through observe. So we're still working on a REST corner case where not all methods are applicable. Matthieu From pthubert@cisco.com Mon Apr 2 04:00:49 2012 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 227BE21F881C for ; Mon, 2 Apr 2012 04:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.669 X-Spam-Level: X-Spam-Status: No, score=-6.669 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GX7bdBPUKVwK for ; Mon, 2 Apr 2012 04:00:48 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id E6DD921F881A for ; Mon, 2 Apr 2012 04:00:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=26513; q=dns/txt; s=iport; t=1333364447; x=1334574047; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=wkm4gWJHtHBO6qCD7jSJKWxtgHf1idYqDYTVJTI/MhM=; b=Vtm1vvXCzDx6GJhe2QsiLt0NU/QOZbQ7RLGKu6Q3v84aysBSNJ3Rbz2Q oi569+FQitaq+Hs44TpMsBjutZXQvIsgR27bE6WQvw5DiGQTxK45itt6i gRWMwsbOzJyt3HJZmpNIb6NmNNFXdbasEEgksk0uxDtci89N8daLdSsnS k=; X-Files: image003.gif, image004.png : 87, 6279 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAJuGeU+Q/khR/2dsb2JhbABEgkaCK1aySH+BB4IKAQEEBQEGBgEJBwIIAQI0IwICAQYCHQEBAQIGFwECAgIBARUEAgkgEQEBBBIBCBqHZwubI40IkT8EiweEeTVjBIxtgx6GZ402gWiCaYFT X-IronPort-AV: E=Sophos;i="4.75,355,1330905600"; d="gif'147?png'147,150?scan'147,150,208,217,147,150";a="69895021" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 02 Apr 2012 11:00:32 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q32B0Wqn007797 for ; Mon, 2 Apr 2012 11:00:32 GMT Received: from xmb-ams-108.cisco.com ([144.254.74.83]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Apr 2012 13:00:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CD10BF.D2CFD371" Date: Mon, 2 Apr 2012 12:59:27 +0200 Message-ID: In-Reply-To: <201203290941.34933.mab@comnets.uni-bremen.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] draft-ietf-core-coap-09: retransmission window Thread-Index: Ac0Nf2wMlyLq4HaGSjKp6jyzNoP4XgDPm2gg References: <201203290941.34933.mab@comnets.uni-bremen.de> From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 02 Apr 2012 11:00:32.0687 (UTC) FILETIME=[D2E89BF0:01CD10BF] Subject: Re: [core] draft-ietf-core-coap-09: retransmission window X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 02 Apr 2012 11:00:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD10BF.D2CFD371 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear WG: A gentle reminder about retransmission window calculation from one year ago. It is probably a good practice that CoAP is TCP friendly and adaptive to the environment changes. ISA100.11a found that RFC 2988 was a fair method for achieving both objectives.=20 ISA100.11a also checked for a good respect of recommendation is RFC 5405. Is there any reason why CoAP goes for a different approach?=20 Do we have a clear idea how a large set of CoAP devices will share a common network with TCP applications, as well as UDP applications that would comply with the above RFCs? Cheers, Pascal ------_=_NextPart_001_01CD10BF.D2CFD371 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_002_01CBEBD3.E3A41800" Subject: retransmission timer in CoAP Date: Sat, 26 Mar 2011 18:36:16 +0200 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: retransmission timer in CoAP Thread-Index: Acvr0+0dq38ODwYpQsyjeL1xf+lMbQ== From: "Pascal Thubert (pthubert)" To: "core WG" This is a multi-part message in MIME format. ------_=_NextPart_002_01CBEBD3.E3A41800 Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01CBEBD3.E3A41800" ------_=_NextPart_003_01CBEBD3.E3A41800 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 RHVyaW5nIGEgZGlzY3Vzc2lvbiBhcm91bmQgQ09OL0FDSywgdGhlIG1ldGhvZCBmb3IgY29tcHV0 aW5nIHRoZSByZXRyYW5zbWlzc2lvbiB0aW1lcnMgY2FtZSB1cC4NCg0KIA0KDQpGb3IgaW5mb3Jt YXRpb24sIElTQTEwMC4xMWEgc2V0dGxlZCBmb3IgZm9sbG93aW5nIFJGQyAyOTg4LiBUaGUgbWFp biBkaXNjdXNzaW9uLCBpbiBmYWN0LCBpcyB3aGF0IHRoZSBpbml0aWFsIHZhbHVlIHNob3VsZCBi ZS4NCg0KIA0KDQpUaGUgcG9pbnQgaXMgdGhhdCBpbiBhIGxhcmdlIGRlcGxveW1lbnQsIHRoZSBs YXRlbmN5IGNhbiBncm93IHZlcnkgaGlnaCBhbmQgaWYgdGhlIGRlZmF1bHQgaXMgc21hbGwsIHRo YXQgbWVhbnMgdGhhdCBtYW55IGRldmljZXMgaGF2ZSB0byBiZSByZWNvbmZpZ3VyZWQuDQoNCiAN Cg0KT1RPSCwgaW4gYSBzbWFsbCBkZXBsb3ltZW50LCBhIHRvbyBsYXJnZSBkZWZhdWx0IGNhbiAg bW9yZSBlYXNpbHkgYmUgZml4ZWQgYmVjYXVzZSB0aGF0IHJlcHJlc2VudHMgZmV3IGRldmljZXMu DQoNCiANCg0KSSB1bmRlcnN0YW5kIHRoYXQgdGhpcyBjb21lcyBmcm9tIGV4cGVyaWVuY2UsIHRo YXQgdGhlIHJlY29tbWVuZGF0aW9uIGlzIHRvIGJlIGNvbnNlcnZhdGl2ZTsgYW5kIHRoYXQgYSBm ZXcgc2Vjb25kcyBpcyBpbiBmYWN0LCB2ZXJ5IG9wdGltaXN0aWMuDQoNCiANCg0KV2hhdCBkbyB5 b3UgdGhpbms/DQoNCiANCg0KDQoJDQoNClBhc2NhbCBUaHViZXJ0DQpJUHY2IEVuZ2luZWVyaW5n DQpQcm9kdWN0IERldmVsb3BtZW50DQogPG1haWx0bzpwdGh1YmVydEBjaXNjby5jb20+IHB0aHVi ZXJ0QGNpc2NvLmNvbQ0KUGhvbmU6ICszMyA0IDk3MjMgMjYzNA0KTW9iaWxlOiArMzMgNiAxOTk4 IDI5ODUNCg0KDQoNCkNpc2NvIFN5c3RlbXMgRnJhbmNlDQpWaWxsYWdlIGQnRW50cmVwcmlzZXMg R3JlZW4gU2lkZQ0KNDAwIEF2ZW51ZSBkZSBSb3VtYW5pbGxlIA0KQmF0aW1lbnQgVCAzIA0KMDY0 MTAgDQpCSU9UIC0gU09QSElBIEFOVElQT0xJUw0KRnJhbmNlDQogPGh0dHA6Ly93d3cuY2lzY28u Y29tL2dsb2JhbC9GUi8+IENpc2NvLmNvbQ0KDQogDQoNCiANCg0KDQpEZXNjcmlwdGlvbjogVGhp bmsgYmVmb3JlIHlvdSBwcmludC5UaGluayBiZWZvcmUgeW91IHByaW50Lg0KDQpDaXNjbyBTeXN0 ZW1zIEZyYW5jZSwgU29jacOpdMOpIMOgIHJlc3BvbnNhYmlpdMOpIGxpbWl0w6llLCBSdWUgQ2Ft aWxsZSBEZXNtb3VsaW5zIOKAkyBJbW0gQXRsYW50aXMgWmFjIEZvcnVtIFNlaW5lIElsb3QgNyA5 MjEzMCBJc3N5IGxlcyBNb3VsaW5lYXV4LCBBdSBjYXBpdGFsIGRlIDkxLjQ3MCDigqwsIDM0OSAx NjYgNTYxIFJDUyBOYW50ZXJyZSwgRGlyZWN0ZXVyIGRlIGxhIHB1YmxpY2F0aW9uOiBKZWFuLUx1 YyBNaWNoZWwgR2l2b25lLCBGb3IgY29ycG9yYXRlIGxlZ2FsIGluZm9ybWF0aW9uIGdvIHRvOg0K IDxodHRwOi8vd3d3LmNpc2NvLmNvbS93ZWIvYWJvdXQvZG9pbmdfYnVzaW5lc3MvbGVnYWwvY3Jp L2luZGV4Lmh0bWw+IGh0dHA6Ly93d3cuY2lzY28uY29tL3dlYi9hYm91dC9kb2luZ19idXNpbmVz cy9sZWdhbC9jcmkvaW5kZXguaHRtbA0KDQogDQoNCiANCg0K ------_=_NextPart_003_01CBEBD3.E3A41800 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj48aGVhZD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQt VHlwZSIgQ09OVEVOVD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9R2Vu ZXJhdG9yIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj48IS0t W2lmICFtc29dPjxzdHlsZT52XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoq IHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1 bHQjVk1MKTt9DQouc2hhcGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+ PCFbZW5kaWZdLS0+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYg NCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxp Lk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0 YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1 cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48 L2hlYWQ+PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9 V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD5EdXJpbmcgYSBkaXNjdXNzaW9uIGFyb3Vu ZCBDT04vQUNLLCB0aGUgbWV0aG9kIGZvciBjb21wdXRpbmcgdGhlIHJldHJhbnNtaXNzaW9uIHRp bWVycyBjYW1lIHVwLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNw OzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+Rm9yIGluZm9ybWF0aW9uLCBJU0ExMDAuMTFh IHNldHRsZWQgZm9yIGZvbGxvd2luZyBSRkMgMjk4OC4gVGhlIG1haW4gZGlzY3Vzc2lvbiwgaW4g ZmFjdCwgaXMgd2hhdCB0aGUgaW5pdGlhbCB2YWx1ZSBzaG91bGQgYmUuPG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD5UaGUgcG9pbnQgaXMgdGhhdCBpbiBhIGxhcmdlIGRlcGxveW1lbnQsIHRoZSBsYXRlbmN5IGNh biBncm93IHZlcnkgaGlnaCBhbmQgaWYgdGhlIGRlZmF1bHQgaXMgc21hbGwsIHRoYXQgbWVhbnMg dGhhdCBtYW55IGRldmljZXMgaGF2ZSB0byBiZSByZWNvbmZpZ3VyZWQuPG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD5PVE9ILCBpbiBhIHNtYWxsIGRlcGxveW1lbnQsIGEgdG9vIGxhcmdlIGRlZmF1bHQgY2FuIMKg bW9yZSBlYXNpbHkgYmUgZml4ZWQgYmVjYXVzZSB0aGF0IHJlcHJlc2VudHMgZmV3IGRldmljZXMu PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD5JIHVuZGVyc3RhbmQgdGhhdCB0aGlzIGNvbWVzIGZyb20gZXhwZXJp ZW5jZSwgdGhhdCB0aGUgcmVjb21tZW5kYXRpb24gaXMgdG8gYmUgY29uc2VydmF0aXZlOyBhbmQg dGhhdCBhIGZldyBzZWNvbmRzIGlzIGluIGZhY3QsIHZlcnkgb3B0aW1pc3RpYy48bzpwPjwvbzpw PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPldoYXQgZG8geW91IHRoaW5rPzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48bzpwPiZuYnNwOzwvbzpwPjwvcD48dGFibGUgY2xhc3M9VGFibGVhdU5vcm1hbCBib3JkZXI9 MCBjZWxsc3BhY2luZz0wIGNlbGxwYWRkaW5nPTAgd2lkdGg9NTQzIHN0eWxlPSd3aWR0aDo0MDcu MjVwdCc+PHRyPjx0ZCBzdHlsZT0ncGFkZGluZzowY20gMGNtIDBjbSAwY20nPjx0YWJsZSBjbGFz cz1UYWJsZWF1Tm9ybWFsIGJvcmRlcj0wIGNlbGxzcGFjaW5nPTAgY2VsbHBhZGRpbmc9MCB3aWR0 aD02MDAgc3R5bGU9J3dpZHRoOjQ1MC4wNXB0Jz48dHI+PHRkIGNvbHNwYW49MyBzdHlsZT0ncGFk ZGluZzowY20gMGNtIDBjbSAwY20nPjwvdGQ+PC90cj48dHIgc3R5bGU9J2hlaWdodDo5NC4wNXB0 Jz48dGQgbm93cmFwIHZhbGlnbj10b3Agc3R5bGU9J3BhZGRpbmc6MGNtIDBjbSAxMS4yNXB0IDE4 LjBwdDtoZWlnaHQ6OTQuMDVwdCc+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCc+PGI+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZTo4LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojNjY2NjY2 Jz5QYXNjYWwgVGh1YmVydDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdDtm b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojNjY2NjY2Jz48YnI+PGI+SVB2 NiBFbmdpbmVlcmluZzwvYj48YnI+PGI+UHJvZHVjdCBEZXZlbG9wbWVudDwvYj48YnI+PGEgaHJl Zj0ibWFpbHRvOnB0aHViZXJ0QGNpc2NvLmNvbSI+PHNwYW4gc3R5bGU9J2NvbG9yOiM2NjY2NjYn PnB0aHViZXJ0QGNpc2NvLmNvbTwvc3Bhbj48L2E+PGJyPlBob25lOiA8Yj4rMzMgNCA5NzIzIDI2 MzQ8L2I+PGJyPk1vYmlsZTogPGI+KzMzIDYgMTk5OCAyOTg1PC9iPjxicj48YnI+PG86cD48L286 cD48L3NwYW4+PC9wPjwvdGQ+PHRkIG5vd3JhcCB2YWxpZ249dG9wIHN0eWxlPSdwYWRkaW5nOjBj bSAwY20gNy41cHQgMTUuMHB0O2hlaWdodDo5NC4wNXB0Jz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Jz48Yj48c3Bh biBsYW5nPUZSIHN0eWxlPSdmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzY2NjY2Nic+Q2lzY28gU3lzdGVtcyBGcmFuY2U8L3NwYW4+PC9iPjxz cGFuIGxhbmc9RlIgc3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJz YW5zLXNlcmlmIjtjb2xvcjojNjY2NjY2Jz48YnI+VmlsbGFnZSBkJ0VudHJlcHJpc2VzIEdyZWVu IFNpZGU8YnI+NDAwIEF2ZW51ZSBkZSBSb3VtYW5pbGxlIDxicj5CYXRpbWVudCBUIDMgPGJyPjA2 NDEwIDxicj5CSU9UIC0gU09QSElBIEFOVElQT0xJUzxicj5GcmFuY2U8YnI+PC9zcGFuPjxzcGFu IHN0eWxlPSdmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzY2NjY2Nic+PGEgaHJlZj0iaHR0cDovL3d3dy5jaXNjby5jb20vZ2xvYmFsL0ZSLyI+ PHNwYW4gbGFuZz1GUiBzdHlsZT0nY29sb3I6IzY2NjY2Nic+Q2lzY28uY29tPC9zcGFuPjwvYT48 L3NwYW4+PHNwYW4gbGFuZz1GUiBzdHlsZT0nZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiJB cmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiM2NjY2NjYnPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L3RkPjx0ZCB3aWR0aD0xODYgc3R5bGU9J3dpZHRoOjEzOS43NXB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gMGNtO2hlaWdodDo5NC4wNXB0Jz48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1GUiBz dHlsZT0nZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2Vy aWYiJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIic+PGltZyBib3JkZXI9MCB3aWR0aD0xNjQgaGVp Z2h0PTEwOCBpZD0iSW1hZ2VfeDAwMjBfMSIgc3JjPSJjaWQ6aW1hZ2UwMDQucG5nQDAxQ0JFQkRD LjRGN0YzM0UwIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC90ZD48L3RyPjwvdGFibGU+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7ZGlzcGxheTpub25lJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PHRhYmxlIGNsYXNzPVRhYmxlYXVOb3JtYWwgYm9yZGVyPTAgY2VsbHNwYWNpbmc9 MCBjZWxscGFkZGluZz0wIHdpZHRoPTcxOSBzdHlsZT0nd2lkdGg6NTM5LjE1cHQnPjx0ciBzdHls ZT0naGVpZ2h0OjkwLjhwdCc+PHRkIHdpZHRoPTcxOSBzdHlsZT0nd2lkdGg6NTM5LjE1cHQ7cGFk ZGluZzowY20gMTguMHB0IDBjbSAxOC4wcHQ7aGVpZ2h0OjkwLjhwdCc+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzAwOTkwMCc+PGltZyBib3JkZXI9MCB3aWR0aD0xOCBoZWlnaHQ9MTkg aWQ9IkltYWdlX3gwMDIwXzIiIHNyYz0iY2lkOmltYWdlMDAzLmdpZkAwMUNCRUJEQi41QkQyMTE5 MCIgYWx0PSJEZXNjcmlwdGlvbjogVGhpbmsgYmVmb3JlIHlvdSBwcmludC4iPjwvc3Bhbj48c3Bh biBsYW5nPUZSIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzAwOTkwMCc+VGhpbmsgYmVmb3JlIHlvdSBwcmludC48YnI+PGJyPjwv c3Bhbj48c3BhbiBsYW5nPUZSIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFy aWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6Izk5OTk5OSc+Q2lzY28gU3lzdGVtcyBGcmFuY2UsIFNv Y2nDqXTDqSDDoCByZXNwb25zYWJpaXTDqSBsaW1pdMOpZSwgUnVlIENhbWlsbGUgRGVzbW91bGlu cyDigJMgSW1tIEF0bGFudGlzIFphYyBGb3J1bSBTZWluZSBJbG90IDcgOTIxMzAgSXNzeSBsZXMg TW91bGluZWF1eCwgQXUgY2FwaXRhbCBkZSA5MS40NzAg4oKsLCAzNDkgMTY2IDU2MSBSQ1MgTmFu dGVycmUsIERpcmVjdGV1ciBkZSBsYSBwdWJsaWNhdGlvbjogSmVhbi1MdWMgTWljaGVsIEdpdm9u ZSwgRm9yIGNvcnBvcmF0ZSBsZWdhbCBpbmZvcm1hdGlvbiBnbyB0bzo8YnI+PC9zcGFuPjxzcGFu IHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7 Y29sb3I6Izk5OTk5OSc+PGEgaHJlZj0iaHR0cDovL3d3dy5jaXNjby5jb20vd2ViL2Fib3V0L2Rv aW5nX2J1c2luZXNzL2xlZ2FsL2NyaS9pbmRleC5odG1sIj48c3BhbiBsYW5nPUZSIHN0eWxlPSdj b2xvcjpibHVlJz5odHRwOi8vd3d3LmNpc2NvLmNvbS93ZWIvYWJvdXQvZG9pbmdfYnVzaW5lc3Mv bGVnYWwvY3JpL2luZGV4Lmh0bWw8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPUZSIHN0eWxl PSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzAwOTkwMCc+PG86cD48L286cD48L3NwYW4+PC9wPjwvdGQ+PC90cj48L3RhYmxlPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBsYW5nPUZSPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L3RkPjwvdHI+ PC90YWJsZT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1GUj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RlI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjwvZGl2PjwvYm9keT48L2h0bWw+ ------_=_NextPart_003_01CBEBD3.E3A41800-- ------_=_NextPart_002_01CBEBD3.E3A41800 Content-Type: image/gif; name="image003.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image003.gif Content-Location: image003.gif R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 ------_=_NextPart_002_01CBEBD3.E3A41800 Content-Type: image/png; name="image004.png" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image004.png Content-Location: image004.png iVBORw0KGgoAAAANSUhEUgAAAKQAAABsCAYAAADkDhmYAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAABgHSURBVHja 7Z0HfJRF+sdV7Gc5xbuzoVLEBqKnByignHd6KDaw0FWK54mKQgBDB2kiCEhI7yQBEgKppIcQ0kgo 6YWQkN573WRTfv/nGXbTG5D83ZV5Pp8hIdmdd/ad7zx15s0NkCJFM+SnTZs23XCDvA9SJJBSpEgg pUggpUiRQEqRQEqRIoGUIoGUIkUCKUUCKUWKBFKKBFICKUUCKUWKBFKKBFKKFAmkFAmkFCkSSCkS SClSJJBSJJBSpEggpUiRQEqRQP6/S2NTE5qam7Vy7M00bh6/BPIPInXKBqTlFyG7qBRNWjaxvIhy isuQllcERb1SAqntolAqEZ+RCzu/0zh66hwyCkrQ0NCoFWNvaGxEVmEpnILOw8Y3DLFp2aitq5dA arOwdrHyDsGCnVb4Zp8d3MKiUV5VoxVjr6xRwCM8Ft/pHcT8Xyxh7hEkAJVAarGcu5COb36zwz8W b8GEJT/jpwNuSM8v1oqxZxN8W22PY+L3O/Dy11vw1R4bhCdckkBqsxwPj8HkZTsxbO4qDKU2Y7Mx olOztGLsCeRqzNlqiqFzVonxT/phB5yCIyWQ2ixHTp3Fi1/9hMfn6OLRmSvxH909OHMhTSvGHkUL Z+rq3/DojJUEpS6e/3Ij7PxPSyC1WY4GnxfmjrXjY7N/xDs0weeS07Vi7DGXsvH+Wj0MmfWj0JC8 sA4FREggtVmOEZD/WLy1Bcipa/ZpFZAfrNuPx1RA/v1/m3FYAimBlEBKIHsVrrk096HycrVANg9w Vacv/V8tkNy1lhaltBfIovIqFJZW9FoOvBog65WNyC0pR3l17YCMvaKmFrnF5airb+h3IPl2FJZV iqalTGoXkFzTzS+pgPeZOBwPi0FmYQmUjY39BiRXdhIz8uBE7wuKSUZZVU2/1cC5G4Y8JO6iqL7E p+f0WA68UiC5spNdVCaS6Z7UcovLtLEGrl1AVtQo4HM2HitNHLHUwB7OIZEorqjqNyAzCoph6RUs kumbbdwQkZgmauH9IfUNjeLaW+3csZj6N/U4JWrU/QVkSWU13MOioWPogOVGDgRlDC0A7ahKaS2Q 6fkl2H7QA//U2YVJP/yCNRZOpNFy+w1I1opcEXnlu+14d/U+mHsEo7yqf0x3Za0CB3xCRSpn/Hfb sHCXNQIik/oNyOSsfGy0dsHrS3fi9WU7xYJKzS2UQA6kRF7MxMzNJhjx2WoMn7ca7xJgJ6Mu9BuQ vInh1SXbRd9PfbFOaGH2J/tDCssrhWZ/ev46Mf6x32yFuWdwvwEZHJuCaev1MYLGPpz6/3ijIWl4 rSs1agaQ7KX1xd8JjU/BG8t3YcislXicABv37Va4n47pNyD1nE4QiGsFAFwhmbvdDBnkp/YmfRk7 gz1/p6WoGA2ft0pAucvBp9+AZFdmwvc/i/vCn/W1pb/QYk3qdVy8Ja9Zc8JyzQCStUdGfjFFnspe gfzXil9pkhhIXWH6jvcjkPudTwgNNoy0zBACZ97P5iJw6kkqKWpmX7C3qDyPgFywy0osJobxyc/X YNeR/gVy4g87WoBks90bkOwf85a8grIKCaRYnbQy2RnnqPmQfzgSMnJ6DCLCElLx5srd4qY/MUdX mFeOKvsLSH2XADy7YL0w2QzC5zssegSyWlGHcDKLtmTqebFUKRQ9ArnoV2sxDgaSNfFuR99+A9L3 XILQinxfuHbPfnZgdPfuDAdZSZl5OHwiAp4RsSii4FADdtX/vkByFOgQeEYEEnO2mWELRaA97cbR JCAbyNQFkP/KfuHsraYiuvU7nwBlNxuANQ1ITjv9fMgDc+m+/3f3ARw8ES6Uw3UN5CUydexXXZ6g dXh58RYc8A3VCiA5h7jZ1l28/un5a/E0AbbO0rlbLalpQHJf477dhpE0jhHz1gh/OSkr7/oGMjmr AB9u0MdfP1oqfLZh5Owbup3UCiBrCMgVpB0f+kSH+l6JBz/Wwff7D4lKjDYAaUERPvuxj8xcQfd/ Gaau3oe4tOzrG8iUnELM2moighSGYNSiDTD3DNIKIGsJyLWkERkWBoz3LLL55nyjNgDJKa4x/90k lABf4+NNhmJT8HUP5IwtxqQdVwgInl24HmYep7p9fWh8amuUPWfgouzhfYiyGcjVFk4CRAbsCep/ ufGRHoHsGGX/OiBRti59Vt1eo2xO0o/+ciOGEpD8WadvNBAH4q5rIC9mF+LTzUZ4dMYKcdOfWbAO psd7AlJz8pAM5CrzY2Icw4WWWQkdI4dugRzoPKS3Kg/Jn3NIH/KQ1t6hwiINnXt5N/00cp040Lmu geQcGJ8GHEnagrUSH2iyP3mm29efv5gpzsWIagS1qf1cqTngEybKhqJS8/la/KDffaWG01MM1Jgv N4nXj164AdsOeohUUFdyuVJzhIKfdaKSwpUaM4+gfgMyOPYiPlyvL8bC/X+00VCkpLoT3kDC542G f7YKT362RkTaKTkF1zeQvDHC0PUkpujuFSDwpoMwMsvdCdeyt9l5iBvJ8K42d+rR77lSIE/FJIuJ 4bGwk292PAhl3dSyeXeNa0gUZm4xEdHqJ5uMcCzoPOq7yaOy5rT2DsF7a/QwjlwNPpp7IjKx34C8 kJWPDVYueO2HX4R25BOWqTnd17LPJKVjCQVh7Ie/tXIPWQd/FJT+7gny3xfI2vp6hJAZ5nTJ4r12 sPYJ6fHsMVdDvCLisNzoCEW0hwVwRRWV/QYkH5Hl889f77HFJmtXcey0u0Q9l9sSMvKw96gvvtpt g18dvBGXnt3t0zE4Ec0HzHjTw/+of2P3QFzqYfPD1ez2cQ2NwlLS6ssM7Mm3jhbb57oT3pNp6xcm djatoYV9KuYCahS/+4MINKNSE0C+Du8RvJCV12OlhmvGHBx4EpRuodHC5Pe0H5JPHb7Q5tThW72c OuTcYkJ6Lo6dOodT0b3vh2TzzIA7Bp5FRFIaqmq7r9QwwPyQgqDYZPEUjbhenkTBpw7fEacOV4jA aXQvpw6VqidduIfFwIP8an5IQkNj9zX2+oYG8uHz4RwcCf/zicJaNTVd55UatZTSRPGGUr5JvYpq V3RBH3aMu4ZFkaO/Q2hIhpIjyaiUzB7fwyaXJ7Osj9vOagjKnKJSVHXjO3al5XOKynqt23OA8elP RhS96woNOf7b7XAkkHtb4AUtO8Z7h4urSrzAS3//Co1mAanWIH1/bd9ez/4oP4aE8218HFbX9Gif 9gheaU13IF6fQf4ym1IeNwdO87abIyjmYp/u45XdS4067PDHPnXIO8ANXAJEZP7FDgs4UASvAfXa Pgm7C6wRF9CCYk25j4KOS7lFf9Spuj6ArK6rw1ny8YzcTooIN5l8pvp+OpIw0MLm9CJFyTY+oSIT Ed6LjyqB1AJhc8S+HW9rSyEYlQ3aAWMLlBSopOYUCH+S00YaZl4lkFc9sQRiQ6N2PBeyozRSpFyv ZQtJAilFAilFigRSigRSk6VRoUBDTQ0aKZoW31dXo3kAfUW+jvp6Ddd4vSalUry/sbZWNP6+qf7K S3fiveox0VdlVRWatdfn1D4gxZFZmriqrCxk+/sjzcUFGcePI93NjZo7iiIjxcQ0d1VT5j+xQRNX X14ORXGxaPw9w9zcw1HWpoZGVOflIefkydbrubsj3dUVBWfPor6yCk19BLOJYFGUlCAvNEyMOcPD Q7Q0+j4vOFiMqS9A8fWqc3ORzWOicYgxieaBoqgo8ZkkkAOtEZUNKE5JxQUnZ4Ru+gmes2bB+bXX cGzcOBwbOxYu/5mCwKVLkerkBEVhYTsQ1RqVJ/C0ri48P/wQHtRCdXSQ4eWF+oqud7oo6OcZQcEI 37kLXnPntVzPiZrrW2/B/+vFiLG0QnHihR61JadsKnPzkObnh7O7d8NnwUK4vjMVzm++JRqP3W/h IsSbmqE0IZGAa+p2QXI/OcEhiDE0gt+XX8F58mQa03g4UT/HP5mBkNVrkEoLp+zSJTRqyV+d0Dog 60jrpZ8IQNCKlThKN9562HCY3HMP9tPwf1M1/RtvhPXwEQj4bglKEhI6AamsrES8mRnsR4/Gbnr9 r9QOjhiBqD17UFPQeS9gFU184mF7eM37HDbPjoLJn++DHr1nr+p6fG2j++6Hw6sTkHTYAQ3d1Kcb yDznx8Ti7N59cJs+HbbPPgfT+wfD4OabRX/c9tPYzR98CO7TP0KKiyu5BJ1r44xo0YVkRO7Xhw8t jiMEocVDj0Cf3r9PNR6Te/4Mm5FPwW3KFISuW4+MgJPic0sg+0mYJQXd0BRvb3jOmwfze++FAU2e EQ3bQNUMVV95Ygxvuw2un3yK/PPnO/XFE5NobY1j48eLyWMQHMaMQYy+PmqK2pfl6qqqkezsAud3 3oXJ3XeLa3Dj6xoPGgRjgsn4llugd9NNMKeFEfXbPiiVyi60uhI5ZNYD16yD7egxMKT3GbYZs/r7 /ar/HyTIYqwPQNnhQVGsfQtj4xC6eQsOvfQyjG+7XYyl7WfXb9OnMd0ji4cehve8z5BOLkF9hVZA qflA1pGzn+LtA4+ZM0mr3C8mTr8NjKYEixVpS8vHHhcTxL9znjYNeefOddaQ5PAn2djAacKElkl0 fOklxBoaorYDkKyJgtaug+XfHhTg6qtgtBk2DMf+/SacyNxys3l+jNB4cabmncws+3m55NMG/Pgj rEeMhD6B3HbsxrffDotHH4P10OEwvvNO8Tvbv7+EaAtLGmtrzZ1HX5aWhpCVP8LqiSdgSAuhbT8t C3PQzZ0ANX/gAXiTNs0MPCVcHgnkNUrJxRSc0FkBs8EPCBgNVTeatZM9aQrf/36F0J+2CHi82Kec 8jYCdVehSG2y2zxStq9AcuCR6ucPtxm0CEgTCRjpejYjRyJo1SqkenmTL+iPSz5+iLWwwvl9+5EX foYCo/alPQUFTGf26cH6uVHtFpLRLbfC9pln4TFnLoLIrPL4fRd9Cdd334M3fU1mk93mOK2Cxp14 1AkOBOtvbfshLXjgiaFweeMN+M2aDW/6/EdemQBzWrhqzcuLyfLhRxBOmrUiPUMCeS3CqZFU9+M4 MvE1GJBpVJtMI9ImjuS3RRqbIC86BhXZ2SglBz737DmkeHoi3f8EqvMLrhrIhrp6MteucCZA1ECy NrOfNAmxVtaoKSkVpliMkSCsJ22mrK1tF6kLE0t+o9dnn8PojjtbTf6tt+EgLaSQrduQERKKMoKk PDML+fQ50vz9keLhiaK4eDS28UcL4+Lg/+0SAZbaJDPUB0kzn9JdjUtkkktjY5F/+jSizS3gSn6o Ofm2hgQsj9301ltx/P33ke7pJYG8FqnIyUbE9p9hRc6+WjuaEJiOr7+OKIpGqygQUR8ZEOkggoDB YECaujBPfdaQ1GeGrx+8Pv0U5ipTakTXtSDz5zV7LmJt7JAVFobKnJxujyzUlpUh0f4Ijk6c2M7X tR01SsBYlJzcLgjifpSckqIxNjDcqkXE/3LEfHjUaOy/+ZbL/uENN8LmmecQsmEjWYJE8Zl50TU1 KFFdWIT4g4fg/Pbbwp1RX9fmqacRbWDYY3pLAtmLcGR64tvvYH7X3QJIbqZkOoPJl6rIu/ITcj0B 2TGoKSVggnWWw4Sut7dN8GH5wF9gP3Yc3D/4QKSYEg4dRllm513orLUjdu8hLfZsa8B14w3wJDcg 93xkn8dcT9o61sQU1oMHC3NtIBblIFoYc5AV3vUZG9a4ETt3wvbJJ1vMu8l9g4XZbtbsTSaaDWQ2 mWAf8hHN775H3Fj2h8zIdMbpG1xVf1cCZD1pnWRHRxybMBEm5L8atgkUWib5rrvg8NrrCN+2HcXx CcL3VEtZejpC6ecHRoxoeY8RARmioyMS6X2V2vIKRO3Xx4EHLwdX6kUZtnoNqgq73rCrVNQh2c0N jq+80hqQ3XkXTq9fL4EcCCDjjY0HHEg2lTWFhUhxdYXfd0vIRD4jzHbHyNaAfELbxx/HGXItyrOy OwOp0lLqKD10xYouc4w9Aqm3v2sgCwq7B5LG7Th+fCuQf/qTBPJaJZ+c+YAl37c32eSgR2zahNrS kivu70qAbHlPfT25DjGItbREII3F48NpOESQGauA1FN9dX3vfVyiyLtZVRmpIP/yzN7fcPC551pN NjW/z78QmYO+Sl2tQlRkrEhLqyNsk0GD4P/FfBRGRXX5norcPETs2QO7kU+1LAbje+/FabpvEshr kPKsLIRTAGD10MMtiWNOSru9/wGZJHfUdfFXBjj3xxFwi/PeZpf11QDZVjiIygkNQ/iGDbAdNlxU WgxV6ZfD5FfGmFuKTReXNVu58C8dOaih36s1qsPYsSI7UJnX+dF3fPiLxy5Mv7rcSZ8n2fEoDnHq iK6nTvc4vPgionbvbs0mqIRdjYvuHhRpT4fZvX9uua4FafGze/ZKIK9F6gm4RHsHHJk4SVQ4DFRm j9Mf3gsWihQJBw+KsnIBVHlaOvIjo1AQHYM6inIvz3JTn9I+7YDkiJV34/BOnA47cBiY7KBguHzw IYxVUSyP6eALLyKSNFl99eWENteQswhezjUak6+pTlmZEiROU99F7AEblKSkorakFApqFWTuC+MS kHvuPAUlme38Uf5MnG+1+NvfWqs7t92KY6++igRbO5RnZKCOTDu/jytavl8vhtUjjwhwxSKme+f4 zzeQRGBr+DEIzQaSE82cywv45htYUpSpNnt8oy0ffhgu//43gsmXOkcgnKHVH7RmLU3GNwjbsg0l SUmtGvIK85CsXRn0jJOBSDrqhBRPb2SdOYOcyEgBRxxFvfb0Pi5TqgFhIKOMTaGsbq2wVOXn48yO HbB96qmWKJ2b2X33w3HyP3FyxUqcJf/wrJ6+2CziTy5BAP2MF5pI5ahEQYsryc4OR154ocVFEPnF O+7A0VcnULS/jKLq3QhetwFu06bD+rHHxD1SlyTN//pXBFK/BfEJmgyj5gMptGRFBVIo2nX9zxQY UUCzv0NQYfHgQ6LcZjNqNCyGDIEJOf/ONCm5ERHtNN6VAClKfgRgyPqNcJ76HpzJb/ReuEg0X/Ld nCh6NSWt0+Kfcf2cNGbKcc92GlX0ExIC/0WLRAlPr40vyUlrMx47lx7HvADLJ4bClDSg3bjxIsfK +cg2HwDlyckI+v57mD7wQKfyKZtm6+FPwnLI4zCmIEu/DbQm99wLt+kf4ZKnF+prNP4PKWnHbp/q vHzSPiYiIW56Z2vVQ7+rzRUErevHnyDvXPebK46OG9e6ueL558Xmio6J8azAQPjyZg6O8G8aJPKR 6mbcRtsZ33IrDr34d5zdvUfk/zr+5UveJMG7d47PmAmzRx6lvm5qGW+nzRX0O7ux4xFjZd1pcwWb 8PRTQcJVseSdQjQmwy7q2QZtyopcbnWlxcRuT01xiaZPs/YAyVJBkx1vYwsvilJtnn9BlOP0VNuu 9rXZgmZ02+3wnL+A/LH4zkCSto03N4f9mDHYQ6/lLWgHKWKO2rtXpHhaFWozMkmzecyeLSZ3l2rL WdumpzKFTlPewentO8i1iBMbebuS2tJSpJKGCli+EodemQDTwX9pN3ZuPB49gszhX28i0fGYKF92 lDoy41nkvwYtXwH71ydTP4MFyOo+1Gkhzo8eevll+H71NS4cc0ZtcbE2TLF2ASkmlnypzJBQnDc0 xgly3F0nT4YzmV+XSZPgTNEsm2KfWbMFuFWkVTsKb/fPOXUKERQl+8yYAW9qp1etQqavL+o77Bks TU8XWtlj6lQRPPA11I2v40raOkhHBxecXVBM5rRR2fOzepS1CuSRPxx7wBZBuqvgTibeiYI1Fxo3 t6PUp/u0j0QkXECv664kydAXJSYh/rA9Apctg9sbb7TcA9EXjctv/nxEk9nPDo+Aolxj/gbNHw9I ob1oohpJe1RR0JETEIBMDw9kEVCZFF1meHqiOCrqci24myMMInrmsycEIDf+nn/W0dTy+9mM5wUF iSMGfA114+vw8YlKim7ZlPY1cG1WpXUUpDHzw8NFP1k+PqLxNfLDwsTvejsOIer21E91To44VtH2 HmR6efV8DySQAycMAx9L4EBCHPSqq+v3azS3vYa60XWaetGIvQ++qX2/fK7nKnKEne4B50G19wkX 8hisFAmkFCkSSCkSSClSJJBSJJBSpEggpUggpUiRQEqRQEqRIoGUIkUCKUUCKUWKBFKKBFKKFAmk FAmkFCkSSCkSSClSJJBSJJBSpPyOsl0CKUUjgdwmm2wa0N4UQPI/ssmmKe3/AK1EJLq9bcSBAAAA AElFTkSuQmCC ------_=_NextPart_002_01CBEBD3.E3A41800-- ------_=_NextPart_001_01CD10BF.D2CFD371-- From gilger@umic.rwth-aachen.de Mon Apr 2 04:17:23 2012 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 E87EF21F8926 for ; Mon, 2 Apr 2012 04:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FUZZY_VLIUM=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEoWZrncnyis for ; Mon, 2 Apr 2012 04:17:23 -0700 (PDT) Received: from avalon.gnuzifer.de (avalon.gnuzifer.de [IPv6:2a01:4f8:121:43c1::a2:1]) by ietfa.amsl.com (Postfix) with ESMTP id 37EBF21F8918 for ; Mon, 2 Apr 2012 04:17:23 -0700 (PDT) Received: from [137.226.161.159] (port=44625 helo=localhost) by avalon.gnuzifer.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1SEfGD-0003dC-Fa for core@ietf.org; Mon, 02 Apr 2012 13:17:21 +0200 Date: Mon, 2 Apr 2012 13:17:24 +0200 From: Johannes Gilger To: IETF CoRE Message-ID: <20120402111724.GA29105@blackbox> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: 137.226.161.159 X-SA-Exim-Mail-From: gilger@umic.rwth-aachen.de Subject: [core] Impact of the Smart Object Security Workshop? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 02 Apr 2012 11:17:24 -0000 Hey guys, I very much enjoyed the Smart Object Security Workshop right before the IETF 83. As I was not able to attend the IETF meeting in Paris and have no personal backchannels, I was wondering about the impact (if any) the Workshop had on discussions in the WGs (CoRE as well as others). I listened to some of the CoRE discussion slots, but was not able to observe any on-the-record conversation which mentioned the workshop. Something came up in the workshop and may have direct IETF relevance was the question of an authorization/access control policy protocol. OAuth was mentioned (which is IETF territory) and at least one other possible solution was presented. Is anyone working on this? Any thoughts in particular? Regards, Jojo P.S.: Maybe I'm just impatient and everyone just returned from a hard week in Paris, in which case I apologize. -- Dipl.-Inform. Johannes Gilger Research Group IT-Security UMIC Research Centre RWTH Aachen University Mies-van-der-Rohe-Straße 15 52074 Aachen Office: 211 Phone: +49 241 80 20781 Fax: +49 241 80 22731 http://itsec.rwth-aachen.de From Berta.Carballido@cit.ie Mon Apr 2 04:49:23 2012 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 CA2F121F8964 for ; Mon, 2 Apr 2012 04:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AT30dhAfmpQg for ; Mon, 2 Apr 2012 04:49:21 -0700 (PDT) Received: from mx-1.cit.ie (mx-1.cit.ie [157.190.3.45]) by ietfa.amsl.com (Postfix) with ESMTP id 96DCC21F8963 for ; Mon, 2 Apr 2012 04:49:20 -0700 (PDT) X-ASG-Debug-ID: 1333367355-019f2807ee44340001-aa7cYp Received: from CITMAIL.cit.ie ([157.190.22.71]) by mx-1.cit.ie with ESMTP id B5pm34rvfZbF44Ik for ; Mon, 02 Apr 2012 12:49:15 +0100 (IST) X-Barracuda-Envelope-From: Berta.Carballido@cit.ie X-Barracuda-Apparent-Source-IP: 157.190.22.71 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD10C6.A11250FF" Date: Mon, 2 Apr 2012 12:49:15 +0100 X-ASG-Orig-Subj: Sleepy devices + observer model Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Sleepy devices + observer model Thread-Index: Ac0QxE7rpzs4fY/bToSRYwjf9ZElpgAAkpqg From: "Berta Carballido" To: X-Barracuda-Connect: UNKNOWN[157.190.22.71] X-Barracuda-Start-Time: 1333367355 X-Barracuda-URL: http://157.190.3.45:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at cit.ie X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.92965 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Subject: [core] Sleepy devices + observer model X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 02 Apr 2012 11:49:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD10C6.A11250FF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, Just to add some more information on my comment last Friday where I mentioned that observe model works for sleepy sensors (as requested by Mr. Bormann). 1. First of all, remind that the MAC layer or radio can store packets waiting to be sent. Some radios for instance can store ten packets, others one, etc. MAC layer buffer size depends on implementation. =20 Since internet stack is memory consuming I would expect to have type 1 type 2 device with enough memory to store several packets (but at least there will be always space for one). Also take into account the tradeoff cost of proxy device vs. cost of radio with large buffer.=20 2. Second of all, there are some MAC protocols that synchronize in time (TDMA based) and some others that can be asynchronous (i.e. CSMA based). In any case, they will always figure out when they must transmit to reach a neighbour. Thus, if a device "a" wants to subscribe (observe) to a device "b" that is sleeping. The device "a" APP layer will generate a request packet that will go down the stack till the buffer. Then the "a" MAC will wait until "b" radio wakes up and then deliver the packet to "b". "b" will read the packet, process the request and act accordingly. Thus the observe model works for sleeping devices even if a request has to go through several intermediary sleeping nodes. One could wonder how to establish the timeout value in such cases where sleeping devices have to be traversed. One way of doing it can be using cross-layer info, a possible example using a CSMA like MAC could be (note that I just invented this example, it may be missing something): Timeout=3D 2 * RPL_hop_count_metric * IEEE802.15.4_duty_cycle * Probability_rtx * Mean_time_gain_access [note that it is a common practise in the WSN domain to use cross-layer info to optimise protocol/algorithm performance]. Moreover, if a proxy is required in the vicinity of every sleeping device (and think here about proxy monetary costs as well), only star like topologies make sense (with a proxy backbone possibly using a different phy layer). For instance, in the scheme below the sleepy device "a" is connected in a star like fashion to the proxy "pa" (same for "b" and "pb"). And the proxies communicate directly (or multihop) to each other and to the border router ("br") . a -- pa -- br -- pb -- b If this scheme of sleepy star-leafs plus proxy backbone is not used, whenever a node wants to perform a request, it will have to traverse sleeping devices to reach a proxy, where delays will be introduced. For instance, in the diagram below "a" would have to traverse the sleeping device "s" to reach the proxy "pb" of "b". Thus, if proxies are used to facilitate fast access to information, multihop topologies of sleeping devices with proxies in between do not make sense.=20 a -- s -- pb -- b=20 However, one of the advantages of battery powered sensors is their freedom of placement! Imagine a vineyard where you want to monitor the soil humidity, would it make sense to have a line powered proxy every "x" meters, or would it make more sense to have a multihop topology of sleeping devices? Thus my conclusions are: a) Server and observer models are appropriate for sleeping devices=20 b) A proxy may be useful for some applications (for instance when the sleeping device wants to remain always sleeping unless some event that needs to be reported happens) c) Proxies make sense only for star-like/star backbone topologies Regards, Berta. =20 ------_=_NextPart_001_01CD10C6.A11250FF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello = all,

Just to add some more = information on my comment last Friday where I mentioned that observe = model works for sleepy sensors (as requested by Mr. = Bormann).

1.       = First of all, remind that the MAC layer or radio = can store packets waiting to be sent. Some radios for instance can store = ten packets, others one, etc. MAC layer buffer size depends on = implementation. 

Since internet stack is memory = consuming I would expect to have type 1 type 2 device with enough memory = to store several packets (but at least there will be always space for = one).  Also take into account the tradeoff cost of proxy device vs. = cost of radio with large buffer.

2.       = Second of all, there are some MAC protocols that = synchronize in time (TDMA based) and some others that can be = asynchronous (i.e. CSMA based). In any case, they will always = figure out when they must transmit to reach a = neighbour.

Thus, if a device = “a” wants to subscribe (observe) to a device “b” = that is sleeping. The device “a” APP layer will generate a = request packet that will go down the stack till the buffer. Then the = “a” MAC will wait until “b” radio wakes up and = then deliver the packet to “b”. “b” will read = the packet, process the request and act accordingly. Thus the observe = model works for sleeping devices even if a request has to go through = several intermediary sleeping nodes.

One could wonder how to establish the timeout value in = such cases where sleeping devices have to be traversed.  One way of = doing it can be using cross-layer info, a possible example using a CSMA = like MAC could be (note that I just invented this example, it may be = missing something): Timeout=3D 2 * RPL_hop_count_metric  * = IEEE802.15.4_duty_cycle * Probability_rtx * Mean_time_gain_access [note = that it is a common practise in the WSN domain to use cross-layer info = to optimise protocol/algorithm performance].

Moreover, if a proxy is required in the vicinity of = every sleeping device (and think here about proxy monetary costs as = well), only star like topologies make sense (with a proxy backbone = possibly using a different phy layer).  For instance, in the scheme = below the sleepy device “a” is connected in a star like = fashion to the proxy “pa” (same for “b” and = “pb”).  And the proxies communicate directly (or = multihop) to each other and to the border router (“br”) = .

a -- pa -- br -- pb -- = b

If this scheme of sleepy star-leafs = plus proxy backbone is not used, whenever a node wants to perform a = request, it will have to traverse sleeping devices to reach a proxy, = where delays will be introduced. For instance, in the diagram below = “a” would have to traverse the sleeping device = “s” to reach the proxy “pb” of “b”. = Thus, if proxies are used to facilitate fast access to information, = multihop topologies of sleeping devices with proxies in between do not = make sense.

a -- s -- pb -- b =

However, one of the advantages of = battery powered sensors is their freedom of placement! Imagine a = vineyard where you want to monitor the soil humidity, would it make = sense to have a line powered proxy every “x” meters, or = would it make more sense to have a multihop topology of sleeping = devices?

Thus my conclusions = are:

a)      = Server and observer models are appropriate for = sleeping devices

b)      = A proxy may be useful for some applications (for = instance when the sleeping device wants to remain always sleeping unless = some event that needs to be reported happens)

c)       = Proxies make sense only for star-like/star = backbone topologies

Regards,

Berta.

 

------_=_NextPart_001_01CD10C6.A11250FF-- From hannes.tschofenig@gmx.net Mon Apr 2 05:18:56 2012 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 5C5F821F86A2 for ; Mon, 2 Apr 2012 05:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.98 X-Spam-Level: X-Spam-Status: No, score=-101.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6ePYqOTjbJW for ; Mon, 2 Apr 2012 05:18:55 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 5814A21F86E5 for ; Mon, 2 Apr 2012 05:18:55 -0700 (PDT) Received: (qmail invoked by alias); 02 Apr 2012 12:18:53 -0000 Received: from unknown (EHLO [10.255.132.174]) [192.100.123.77] by mail.gmx.net (mp019) with SMTP; 02 Apr 2012 14:18:53 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19zaw0UsIBzb7DIQCFtDpkFq+TN6AFRkY7sLhu9kj sGKwH2tLUTOJcn Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Hannes Tschofenig In-Reply-To: <20120402111724.GA29105@blackbox> Date: Mon, 2 Apr 2012 15:18:47 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120402111724.GA29105@blackbox> To: Johannes Gilger X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: IETF CoRE Subject: Re: [core] Impact of the Smart Object Security Workshop? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 02 Apr 2012 12:18:56 -0000 Hi Johannes,=20 I was not able to attend all sessions related to smart objects last week = (because of other obligations) but Jari and myself summarized some of = the workshop discussions in the LWIG and the SAAG meeting. The slides = can be found here:=20 http://www.ietf.org/proceedings/83/slides/slides-83-saag-3.ppt http://www.ietf.org/proceedings/83/slides/slides-83-lwig-7.pdf I also gave a presentation about the TLS raw public key support in the = TLS working group and the document will enter WGLC soon. Regarding OAuth: There is deployment happening already and I will try to = find some pointers.=20 Ciao Hannes On Apr 2, 2012, at 2:17 PM, Johannes Gilger wrote: > Hey guys, >=20 > I very much enjoyed the Smart Object Security Workshop right before = the > IETF 83. As I was not able to attend the IETF meeting in Paris and = have > no personal backchannels, I was wondering about the impact (if any) = the > Workshop had on discussions in the WGs (CoRE as well as others). I > listened to some of the CoRE discussion slots, but was not able to > observe any on-the-record conversation which mentioned the workshop. >=20 > Something came up in the workshop and may have direct IETF relevance = was > the question of an authorization/access control policy protocol. OAuth > was mentioned (which is IETF territory) and at least one other = possible > solution was presented. Is anyone working on this? Any thoughts in > particular? >=20 > Regards, > Jojo >=20 > P.S.: Maybe I'm just impatient and everyone just returned from a hard > week in Paris, in which case I apologize. >=20 > --=20 > Dipl.-Inform. Johannes Gilger > Research Group IT-Security > UMIC Research Centre > RWTH Aachen University > Mies-van-der-Rohe-Stra=DFe 15 > 52074 Aachen >=20 > Office: 211 > Phone: +49 241 80 20781 > Fax: +49 241 80 22731 >=20 > http://itsec.rwth-aachen.de > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From salvatore.loreto@ericsson.com Mon Apr 2 06:18:13 2012 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 DA81E21F84FF for ; Mon, 2 Apr 2012 06:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0co1AB9LA-N for ; Mon, 2 Apr 2012 06:18:13 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1FF21F84F1 for ; Mon, 2 Apr 2012 06:18:12 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-49-4f79a71341ee Authentication-Results: mailgw2.ericsson.se x-tls.subject="/CN=esessmw0256"; auth=fail (cipher=AES128-SHA) Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0256", Issuer "esessmw0256" (not verified)) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 8A.4C.03534.317A97F4; Mon, 2 Apr 2012 15:18:12 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Apr 2012 15:18:12 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 3B18B2323 for ; Mon, 2 Apr 2012 16:18:11 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 53CD75265D for ; Mon, 2 Apr 2012 16:18:11 +0300 (EEST) Received: from n106.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 048B151EA8 for ; Mon, 2 Apr 2012 16:18:10 +0300 (EEST) Message-ID: <4F79A712.9040102@ericsson.com> Date: Mon, 2 Apr 2012 16:18:10 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "core@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: [core] sleepy nodes: about resource delegation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 02 Apr 2012 13:18:14 -0000 (on behalf of Thomas that is experiencing some trouble with the mail) Dear all, following up the discussion interrupted during the friday session, I'd like to express my main concern about the resource delegation issue in CoAP. First of all, I fear it's a little more complex than just observing a sleepy resource... In fact, we have to take care of (at least) the following aspects of the delegated resource: - resource identification - resource data (possibly including multiple representations) - resource metadata (1:1 to link format) - access control, i.e. - read-only or read-write at the bare minimum - credentials in case resource lives in the coaps scheme, or its access needs to be authorized in some way Now, it happens that unfortunately we don't have a precedent in HTTP, mostly because the "sleepy resource" is a new concept in the TCP/IP suite. So, as we are attacking a new problem here, we should do that without fear of adding new semantics to the base protocol, if this is really needed. In this perspective, the need for a new protocol primitive (e.g. Publish) would not seem like the outcome of some bizarre ramblings, but rather as one concrete proposal to provide a thorough and native solution to one (important) topic in our Charter. (And let me tell you, the observe model is nowhere like a comprehensive solution to this also because: a) it requires state on the sleepy client side, which should instead be avoided as possible b) in case state is lost on the sleepy client, it needs the proxy entity to poll for an unbounded time in order to re-boostrap the observe relationship. And BTW, the claim in the slides stating "already in CoAP-09" is actually wrong since observe is defined out of draft-ietf-core-coap.) -- Salvatore Loreto, PhD www.sloreto.com From angelo.castellani@gmail.com Wed Apr 4 00:15:55 2012 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 2333E11E8072 for ; Wed, 4 Apr 2012 00:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-dh+lgaxn64 for ; Wed, 4 Apr 2012 00:15:54 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id EE17411E8093 for ; Wed, 4 Apr 2012 00:15:53 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so314153wgb.13 for ; Wed, 04 Apr 2012 00:15:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=OvEXgo+xIcEjSAdXqvslHKTunJoBk/9KA6mdfam6fvU=; b=lmKsn2vudH7aL2aqnn1BhNxpqRCPnFLx1lbg1LvIMS7HJwNTf76rlkqiEihTtHn+W5 uZvjNGxrN+eqkfm9w9NX13YjEuA/4XGLAEEYOvslBsAtqZpZG44YR4Lo72DoqgawtnBT 74F5ckVMbzsBlEnuVKdZzf0+otwkAaw/JSPHQxPiPz+ocMh5H6Fovfc4mhfboRxwNXKv rm3b4bsuVofCBLjnor2uxN3winrFpDRi+szj7xkvua5XSVYIbxnRdSnWoRlgArQJmITt 65QRUFZ7nYV5ILE0wEd8hWQeIL1oDPTqNZoBG1SHM4RYspwYonE4r0yl4KvKDpLfqVkQ y6jg== Received: by 10.180.24.7 with SMTP id q7mr2567726wif.11.1333523753072; Wed, 04 Apr 2012 00:15:53 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.214.20 with HTTP; Wed, 4 Apr 2012 00:15:12 -0700 (PDT) In-Reply-To: References: From: "Angelo P. Castellani" Date: Wed, 4 Apr 2012 09:15:12 +0200 X-Google-Sender-Auth: Fd3RmkA5uCJbUYOiIRYb41aAN50 Message-ID: To: Berta Carballido Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: core@ietf.org Subject: Re: [core] Sleepy devices + observer model X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 04 Apr 2012 07:15:55 -0000 Using only L2 techniques, with a multihop network, what is the minumum duty cycle you can achieve? 1%? 0.1%? I think that the focus here is about duty cycling <<0.1%, these optimization will be for sure paired with L2 RDC techniques as well. I share your opinion of avoiding proxies, as much as possible, for this reason our take on the topic is by using an Alive message between the endpoints. You can find it here: http://tools.ietf.org/html/draft-castellani-core-alive Best, Angelo On Mon, Apr 2, 2012 at 13:49, Berta Carballido wr= ote: > Hello all, > > Just to add some more information on my comment last Friday where I > mentioned that observe model works for sleepy sensors (as requested by Mr= . > Bormann). > > 1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 First of all, remind that the MAC = layer or radio can store packets > waiting to be sent. Some radios for instance can store ten packets, other= s > one, etc. MAC layer buffer size depends on implementation. > > Since internet stack is memory consuming I would expect to have type 1 ty= pe > 2 device with enough memory to store several packets (but at least there > will be always space for one).=C2=A0 Also take into account the tradeoff = cost of > proxy device vs. cost of radio with large buffer. > > 2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Second of all, there are some MAC = protocols that synchronize in > time (TDMA based) and some others that can be asynchronous (i.e. CSMA > based). In any case, they will always figure out when they must transmit = to > reach a neighbour. > > Thus, if a device =E2=80=9Ca=E2=80=9D wants to subscribe (observe) to a d= evice =E2=80=9Cb=E2=80=9D that is > sleeping. The device =E2=80=9Ca=E2=80=9D APP layer will generate a reques= t packet that will > go down the stack till the buffer. Then the =E2=80=9Ca=E2=80=9D MAC will = wait until =E2=80=9Cb=E2=80=9D > radio wakes up and then deliver the packet to =E2=80=9Cb=E2=80=9D. =E2=80= =9Cb=E2=80=9D will read the packet, > process the request and act accordingly. Thus the observe model works for > sleeping devices even if a request has to go through several intermediary > sleeping nodes. > > One could wonder how to establish the timeout value in such cases where > sleeping devices have to be traversed.=C2=A0 One way of doing it can be u= sing > cross-layer info, a possible example using a CSMA like MAC could be (note > that I just invented this example, it may be missing something): Timeout= =3D 2 > * RPL_hop_count_metric=C2=A0 * IEEE802.15.4_duty_cycle * Probability_rtx = * > Mean_time_gain_access [note that it is a common practise in the WSN domai= n > to use cross-layer info to optimise protocol/algorithm performance]. > > Moreover, if a proxy is required in the vicinity of every sleeping device > (and think here about proxy monetary costs as well), only star like > topologies make sense (with a proxy backbone possibly using a different p= hy > layer).=C2=A0 For instance, in the scheme below the sleepy device =E2=80= =9Ca=E2=80=9D is > connected in a star like fashion to the proxy =E2=80=9Cpa=E2=80=9D (same = for =E2=80=9Cb=E2=80=9D and =E2=80=9Cpb=E2=80=9D). > And the proxies communicate directly (or multihop) to each other and to t= he > border router (=E2=80=9Cbr=E2=80=9D) . > > a -- pa -- br -- pb -- b > > If this scheme of sleepy star-leafs plus proxy backbone is not used, > whenever a node wants to perform a request, it will have to traverse > sleeping devices to reach a proxy, where delays will be introduced. For > instance, in the diagram below =E2=80=9Ca=E2=80=9D would have to traverse= the sleeping > device =E2=80=9Cs=E2=80=9D to reach the proxy =E2=80=9Cpb=E2=80=9D of =E2= =80=9Cb=E2=80=9D. Thus, if proxies are used to > facilitate fast access to information, multihop topologies of sleeping > devices with proxies in between do not make sense. > > a -- s -- pb -- b > > However, one of the advantages of battery powered sensors is their freedo= m > of placement! Imagine a vineyard where you want to monitor the soil > humidity, would it make sense to have a line powered proxy every =E2=80= =9Cx=E2=80=9D meters, > or would it make more sense to have a multihop topology of sleeping devic= es? > > Thus my conclusions are: > > a)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Server and observer models are appropria= te for sleeping devices > > b)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A proxy may be useful for some applicati= ons (for instance when the > sleeping device wants to remain always sleeping unless some event that ne= eds > to be reported happens) > > c)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Proxies make sense only for star-l= ike/star backbone topologies > > Regards, > > Berta. > > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From matthieu.vial@non.schneider-electric.com Wed Apr 4 01:20:46 2012 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 7D92C21F869A; Wed, 4 Apr 2012 01:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muq6J40B+1XE; Wed, 4 Apr 2012 01:20:46 -0700 (PDT) Received: from mailX04.eud.schneider-electric.com (mailx04.eud.schneider-electric.com [205.167.7.39]) by ietfa.amsl.com (Postfix) with ESMTP id EE26021F8699; Wed, 4 Apr 2012 01:20:45 -0700 (PDT) Received: from ATEUI01.schneider-electric.com ([10.198.14.9]) by mailX04.eud.schneider-electric.com with ESMTP id 2012040410155257-142716 ; Wed, 4 Apr 2012 10:15:52 +0200 In-Reply-To: To: "Angelo P. Castellani" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 From: matthieu.vial@non.schneider-electric.com Message-ID: Date: Wed, 4 Apr 2012 10:20:36 +0200 X-MIMETrack: Serialize by Router on ATEUI01.Schneider-Electric.com/T/SVR/Schneider at 04/04/2012 10:21:38, Serialize complete at 04/04/2012 10:21:38, Itemize by SMTP Server on AXEU4OUT.schneider-electric.com/X/SVR/SEIxtra at 04/04/2012 10:15:52, Serialize by Router on AXEU4OUT.schneider-electric.com/X/SVR/SEIxtra at 04/04/2012 10:16:01, Serialize complete at 04/04/2012 10:16:01 Content-Type: text/plain; charset="US-ASCII" Cc: core-bounces@ietf.org, core@ietf.org Subject: Re: [core] Sleepy devices + observer model X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 04 Apr 2012 08:20:46 -0000 Hi Angelo, Few comments inline. >I think that the focus here is about duty cycling <<0.1%, these >optimization will be for sure paired with L2 RDC techniques as well. Agreed >I share your opinion of avoiding proxies, as much as possible, for >this reason our take on the topic is by using an Alive message between >the endpoints. Without a cache intermediary you will probably suffer from high latency. > http://tools.ietf.org/html/draft-castellani-core-alive Why do you need something at the message layer when Carsten's proposition can trigger an "I'm alive" indication with a simple POST request? Best regards, Matthieu From Berta.Carballido@cit.ie Wed Apr 4 01:21:32 2012 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 E956421F84A2 for ; Wed, 4 Apr 2012 01:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.651, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bb4yAug8Rp15 for ; Wed, 4 Apr 2012 01:21:32 -0700 (PDT) Received: from mx-1.cit.ie (mx-1.cit.ie [157.190.3.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA7621F848B for ; Wed, 4 Apr 2012 01:21:31 -0700 (PDT) X-ASG-Debug-ID: 1333527682-019f2807eeb2f20001-aa7cYp Received: from CITMAIL.cit.ie ([157.190.22.71]) by mx-1.cit.ie with ESMTP id xTmzvdIR9e6NpOEn; Wed, 04 Apr 2012 09:21:22 +0100 (IST) X-Barracuda-Envelope-From: Berta.Carballido@cit.ie X-Barracuda-Apparent-Source-IP: 157.190.22.71 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 4 Apr 2012 09:21:21 +0100 X-ASG-Orig-Subj: RE: [core] Sleepy devices + observer model Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Sleepy devices + observer model Thread-Index: Ac0SMsZMAYXRI3/lTrOsstMfdxkz3gABXHYw References: From: "Berta Carballido" To: "Angelo P. Castellani" X-Barracuda-Connect: UNKNOWN[157.190.22.71] X-Barracuda-Start-Time: 1333527682 X-Barracuda-URL: http://157.190.3.45:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at cit.ie X-Barracuda-Spam-Score: 0.12 X-Barracuda-Spam-Status: No, SCORE=0.12 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=CN_BODY_332 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.93145 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.12 CN_BODY_332 BODY: CN_BODY_332 Cc: core@ietf.org Subject: Re: [core] Sleepy devices + observer model X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 04 Apr 2012 08:21:33 -0000 RGVhciBBbmdlbG8sDQoNClRoZXJlIGlzIG5vIGxpbWl0IHBlciBzZSBvbiB0aGUgZHV0eSBjeWNs ZS4gVGhpcyBjYW4gZGVwZW5kIGZvciBpbnN0YW5jZSBvbiB5b3VyIG9mZmVyZWQgbG9hZCAoaS5l LiBpZiBtYW55IGV2ZW50cyBuZWVkIHRvIGJlIHJlcG9ydGVkIHRoZSByYWRpbyBuZWVkcyB0byBi ZSBhd2FrZSBmb3IgbG9uZ2VyIGFuZCB2aWNlIHZlcnNhKS4gW0Fsc28sIGFzIGEgcmVtYXJrIHdp dGggcmVnYXJkcyB0byBoYXJkd2FyZSAmIHNtYWxsIGR1dHkgY3ljbGVzLCBzb21lIGV4aXN0aW5n IGltcGxlbWVudGF0aW9ucyBvZiBJRUVFIDgwMi4xNS40IGV4cGVyaWVuY2UgbG9zcyBvZiBzeW5j aHJvbmlzYXRpb24gZHVlIHRvIGNsb2NrIGRyaWZ0cyB3aGVuIGhhdmluZyBzbWFsbCBkdXR5IGN5 Y2xlcyAoc2VlIDMuMi4yLiBpbiBodHRwOi8vd3d3Mi50a24udHUtYmVybGluLmRlL3B1YmxpY2F0 aW9ucy9wYXBlcnMvVEtOMTU0LnBkZildDQoNClJlZ2FyZHMsDQpCZXJ0YS4NCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGFuZ2Vsby5jYXN0ZWxsYW5pQGdtYWlsLmNvbSBbbWFp bHRvOmFuZ2Vsby5jYXN0ZWxsYW5pQGdtYWlsLmNvbV0gT24gQmVoYWxmIE9mIEFuZ2VsbyBQLiBD YXN0ZWxsYW5pDQpTZW50OiAwNCBBcHJpbCAyMDEyIDA4OjE1DQpUbzogQmVydGEgQ2FyYmFsbGlk bw0KQ2M6IGNvcmVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbY29yZV0gU2xlZXB5IGRldmljZXMg KyBvYnNlcnZlciBtb2RlbA0KDQpVc2luZyBvbmx5IEwyIHRlY2huaXF1ZXMsIHdpdGggYSBtdWx0 aWhvcCBuZXR3b3JrLCB3aGF0IGlzIHRoZSBtaW51bXVtIGR1dHkgY3ljbGUgeW91IGNhbiBhY2hp ZXZlPyAxJT8gMC4xJT8NCg0KSSB0aGluayB0aGF0IHRoZSBmb2N1cyBoZXJlIGlzIGFib3V0IGR1 dHkgY3ljbGluZyA8PDAuMSUsIHRoZXNlIG9wdGltaXphdGlvbiB3aWxsIGJlIGZvciBzdXJlIHBh aXJlZCB3aXRoIEwyIFJEQyB0ZWNobmlxdWVzIGFzIHdlbGwuDQoNCkkgc2hhcmUgeW91ciBvcGlu aW9uIG9mIGF2b2lkaW5nIHByb3hpZXMsIGFzIG11Y2ggYXMgcG9zc2libGUsIGZvciB0aGlzIHJl YXNvbiBvdXIgdGFrZSBvbiB0aGUgdG9waWMgaXMgYnkgdXNpbmcgYW4gQWxpdmUgbWVzc2FnZSBi ZXR3ZWVuIHRoZSBlbmRwb2ludHMuDQoNCllvdSBjYW4gZmluZCBpdCBoZXJlOg0KaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2FzdGVsbGFuaS1jb3JlLWFsaXZlDQoNCkJlc3QsDQpB bmdlbG8NCg0KT24gTW9uLCBBcHIgMiwgMjAxMiBhdCAxMzo0OSwgQmVydGEgQ2FyYmFsbGlkbyA8 QmVydGEuQ2FyYmFsbGlkb0BjaXQuaWU+IHdyb3RlOg0KPiBIZWxsbyBhbGwsDQo+DQo+IEp1c3Qg dG8gYWRkIHNvbWUgbW9yZSBpbmZvcm1hdGlvbiBvbiBteSBjb21tZW50IGxhc3QgRnJpZGF5IHdo ZXJlIEkgDQo+IG1lbnRpb25lZCB0aGF0IG9ic2VydmUgbW9kZWwgd29ya3MgZm9yIHNsZWVweSBz ZW5zb3JzIChhcyByZXF1ZXN0ZWQgYnkgTXIuDQo+IEJvcm1hbm4pLg0KPg0KPiAxLsKgwqDCoMKg wqDCoCBGaXJzdCBvZiBhbGwsIHJlbWluZCB0aGF0IHRoZSBNQUMgbGF5ZXIgb3IgcmFkaW8gY2Fu IHN0b3JlIA0KPiBwYWNrZXRzIHdhaXRpbmcgdG8gYmUgc2VudC4gU29tZSByYWRpb3MgZm9yIGlu c3RhbmNlIGNhbiBzdG9yZSB0ZW4gDQo+IHBhY2tldHMsIG90aGVycyBvbmUsIGV0Yy4gTUFDIGxh eWVyIGJ1ZmZlciBzaXplIGRlcGVuZHMgb24gaW1wbGVtZW50YXRpb24uDQo+DQo+IFNpbmNlIGlu dGVybmV0IHN0YWNrIGlzIG1lbW9yeSBjb25zdW1pbmcgSSB3b3VsZCBleHBlY3QgdG8gaGF2ZSB0 eXBlIDEgDQo+IHR5cGUNCj4gMiBkZXZpY2Ugd2l0aCBlbm91Z2ggbWVtb3J5IHRvIHN0b3JlIHNl dmVyYWwgcGFja2V0cyAoYnV0IGF0IGxlYXN0IA0KPiB0aGVyZSB3aWxsIGJlIGFsd2F5cyBzcGFj ZSBmb3Igb25lKS7CoCBBbHNvIHRha2UgaW50byBhY2NvdW50IHRoZSANCj4gdHJhZGVvZmYgY29z dCBvZiBwcm94eSBkZXZpY2UgdnMuIGNvc3Qgb2YgcmFkaW8gd2l0aCBsYXJnZSBidWZmZXIuDQo+ DQo+IDIuwqDCoMKgwqDCoMKgIFNlY29uZCBvZiBhbGwsIHRoZXJlIGFyZSBzb21lIE1BQyBwcm90 b2NvbHMgdGhhdCBzeW5jaHJvbml6ZSANCj4gaW4gdGltZSAoVERNQSBiYXNlZCkgYW5kIHNvbWUg b3RoZXJzIHRoYXQgY2FuIGJlIGFzeW5jaHJvbm91cyAoaS5lLiANCj4gQ1NNQSBiYXNlZCkuIElu IGFueSBjYXNlLCB0aGV5IHdpbGwgYWx3YXlzIGZpZ3VyZSBvdXQgd2hlbiB0aGV5IG11c3QgDQo+ IHRyYW5zbWl0IHRvIHJlYWNoIGEgbmVpZ2hib3VyLg0KPg0KPiBUaHVzLCBpZiBhIGRldmljZSDi gJxh4oCdIHdhbnRzIHRvIHN1YnNjcmliZSAob2JzZXJ2ZSkgdG8gYSBkZXZpY2Ug4oCcYuKAnSAN Cj4gdGhhdCBpcyBzbGVlcGluZy4gVGhlIGRldmljZSDigJxh4oCdIEFQUCBsYXllciB3aWxsIGdl bmVyYXRlIGEgcmVxdWVzdCANCj4gcGFja2V0IHRoYXQgd2lsbCBnbyBkb3duIHRoZSBzdGFjayB0 aWxsIHRoZSBidWZmZXIuIFRoZW4gdGhlIOKAnGHigJ0gTUFDIHdpbGwgd2FpdCB1bnRpbCDigJxi 4oCdDQo+IHJhZGlvIHdha2VzIHVwIGFuZCB0aGVuIGRlbGl2ZXIgdGhlIHBhY2tldCB0byDigJxi 4oCdLiDigJxi4oCdIHdpbGwgcmVhZCB0aGUgDQo+IHBhY2tldCwgcHJvY2VzcyB0aGUgcmVxdWVz dCBhbmQgYWN0IGFjY29yZGluZ2x5LiBUaHVzIHRoZSBvYnNlcnZlIA0KPiBtb2RlbCB3b3JrcyBm b3Igc2xlZXBpbmcgZGV2aWNlcyBldmVuIGlmIGEgcmVxdWVzdCBoYXMgdG8gZ28gdGhyb3VnaCAN Cj4gc2V2ZXJhbCBpbnRlcm1lZGlhcnkgc2xlZXBpbmcgbm9kZXMuDQo+DQo+IE9uZSBjb3VsZCB3 b25kZXIgaG93IHRvIGVzdGFibGlzaCB0aGUgdGltZW91dCB2YWx1ZSBpbiBzdWNoIGNhc2VzIA0K PiB3aGVyZSBzbGVlcGluZyBkZXZpY2VzIGhhdmUgdG8gYmUgdHJhdmVyc2VkLsKgIE9uZSB3YXkg b2YgZG9pbmcgaXQgY2FuIA0KPiBiZSB1c2luZyBjcm9zcy1sYXllciBpbmZvLCBhIHBvc3NpYmxl IGV4YW1wbGUgdXNpbmcgYSBDU01BIGxpa2UgTUFDIA0KPiBjb3VsZCBiZSAobm90ZSB0aGF0IEkg anVzdCBpbnZlbnRlZCB0aGlzIGV4YW1wbGUsIGl0IG1heSBiZSBtaXNzaW5nIA0KPiBzb21ldGhp bmcpOiBUaW1lb3V0PSAyDQo+ICogUlBMX2hvcF9jb3VudF9tZXRyaWPCoCAqIElFRUU4MDIuMTUu NF9kdXR5X2N5Y2xlICogUHJvYmFiaWxpdHlfcnR4ICogDQo+IE1lYW5fdGltZV9nYWluX2FjY2Vz cyBbbm90ZSB0aGF0IGl0IGlzIGEgY29tbW9uIHByYWN0aXNlIGluIHRoZSBXU04gDQo+IGRvbWFp biB0byB1c2UgY3Jvc3MtbGF5ZXIgaW5mbyB0byBvcHRpbWlzZSBwcm90b2NvbC9hbGdvcml0aG0g cGVyZm9ybWFuY2VdLg0KPg0KPiBNb3Jlb3ZlciwgaWYgYSBwcm94eSBpcyByZXF1aXJlZCBpbiB0 aGUgdmljaW5pdHkgb2YgZXZlcnkgc2xlZXBpbmcgDQo+IGRldmljZSAoYW5kIHRoaW5rIGhlcmUg YWJvdXQgcHJveHkgbW9uZXRhcnkgY29zdHMgYXMgd2VsbCksIG9ubHkgc3RhciANCj4gbGlrZSB0 b3BvbG9naWVzIG1ha2Ugc2Vuc2UgKHdpdGggYSBwcm94eSBiYWNrYm9uZSBwb3NzaWJseSB1c2lu ZyBhIA0KPiBkaWZmZXJlbnQgcGh5IGxheWVyKS7CoCBGb3IgaW5zdGFuY2UsIGluIHRoZSBzY2hl bWUgYmVsb3cgdGhlIHNsZWVweSANCj4gZGV2aWNlIOKAnGHigJ0gaXMgY29ubmVjdGVkIGluIGEg c3RhciBsaWtlIGZhc2hpb24gdG8gdGhlIHByb3h5IOKAnHBh4oCdIChzYW1lIGZvciDigJxi4oCd IGFuZCDigJxwYuKAnSkuDQo+IEFuZCB0aGUgcHJveGllcyBjb21tdW5pY2F0ZSBkaXJlY3RseSAo b3IgbXVsdGlob3ApIHRvIGVhY2ggb3RoZXIgYW5kIA0KPiB0byB0aGUgYm9yZGVyIHJvdXRlciAo 4oCcYnLigJ0pIC4NCj4NCj4gYSAtLSBwYSAtLSBiciAtLSBwYiAtLSBiDQo+DQo+IElmIHRoaXMg c2NoZW1lIG9mIHNsZWVweSBzdGFyLWxlYWZzIHBsdXMgcHJveHkgYmFja2JvbmUgaXMgbm90IHVz ZWQsIA0KPiB3aGVuZXZlciBhIG5vZGUgd2FudHMgdG8gcGVyZm9ybSBhIHJlcXVlc3QsIGl0IHdp bGwgaGF2ZSB0byB0cmF2ZXJzZSANCj4gc2xlZXBpbmcgZGV2aWNlcyB0byByZWFjaCBhIHByb3h5 LCB3aGVyZSBkZWxheXMgd2lsbCBiZSBpbnRyb2R1Y2VkLiANCj4gRm9yIGluc3RhbmNlLCBpbiB0 aGUgZGlhZ3JhbSBiZWxvdyDigJxh4oCdIHdvdWxkIGhhdmUgdG8gdHJhdmVyc2UgdGhlIA0KPiBz bGVlcGluZyBkZXZpY2Ug4oCcc+KAnSB0byByZWFjaCB0aGUgcHJveHkg4oCccGLigJ0gb2Yg4oCc YuKAnS4gVGh1cywgaWYgcHJveGllcyANCj4gYXJlIHVzZWQgdG8gZmFjaWxpdGF0ZSBmYXN0IGFj Y2VzcyB0byBpbmZvcm1hdGlvbiwgbXVsdGlob3AgdG9wb2xvZ2llcyANCj4gb2Ygc2xlZXBpbmcg ZGV2aWNlcyB3aXRoIHByb3hpZXMgaW4gYmV0d2VlbiBkbyBub3QgbWFrZSBzZW5zZS4NCj4NCj4g YSAtLSBzIC0tIHBiIC0tIGINCj4NCj4gSG93ZXZlciwgb25lIG9mIHRoZSBhZHZhbnRhZ2VzIG9m IGJhdHRlcnkgcG93ZXJlZCBzZW5zb3JzIGlzIHRoZWlyIA0KPiBmcmVlZG9tIG9mIHBsYWNlbWVu dCEgSW1hZ2luZSBhIHZpbmV5YXJkIHdoZXJlIHlvdSB3YW50IHRvIG1vbml0b3IgdGhlIA0KPiBz b2lsIGh1bWlkaXR5LCB3b3VsZCBpdCBtYWtlIHNlbnNlIHRvIGhhdmUgYSBsaW5lIHBvd2VyZWQg cHJveHkgZXZlcnkgDQo+IOKAnHjigJ0gbWV0ZXJzLCBvciB3b3VsZCBpdCBtYWtlIG1vcmUgc2Vu c2UgdG8gaGF2ZSBhIG11bHRpaG9wIHRvcG9sb2d5IG9mIHNsZWVwaW5nIGRldmljZXM/DQo+DQo+ IFRodXMgbXkgY29uY2x1c2lvbnMgYXJlOg0KPg0KPiBhKcKgwqDCoMKgwqAgU2VydmVyIGFuZCBv YnNlcnZlciBtb2RlbHMgYXJlIGFwcHJvcHJpYXRlIGZvciBzbGVlcGluZyANCj4gZGV2aWNlcw0K Pg0KPiBiKcKgwqDCoMKgwqAgQSBwcm94eSBtYXkgYmUgdXNlZnVsIGZvciBzb21lIGFwcGxpY2F0 aW9ucyAoZm9yIGluc3RhbmNlIHdoZW4gDQo+IHRoZSBzbGVlcGluZyBkZXZpY2Ugd2FudHMgdG8g cmVtYWluIGFsd2F5cyBzbGVlcGluZyB1bmxlc3Mgc29tZSBldmVudCANCj4gdGhhdCBuZWVkcyB0 byBiZSByZXBvcnRlZCBoYXBwZW5zKQ0KPg0KPiBjKcKgwqDCoMKgwqDCoCBQcm94aWVzIG1ha2Ug c2Vuc2Ugb25seSBmb3Igc3Rhci1saWtlL3N0YXIgYmFja2JvbmUgDQo+IHRvcG9sb2dpZXMNCj4N Cj4gUmVnYXJkcywNCj4NCj4gQmVydGEuDQo+DQo+DQo+DQo+DQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGNvcmUgbWFpbGluZyBsaXN0DQo+IGNv cmVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3Jl DQo+DQo= From angelo.castellani@gmail.com Wed Apr 4 01:27:45 2012 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 75A3821F8738 for ; Wed, 4 Apr 2012 01:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgyHuIC19w-S for ; Wed, 4 Apr 2012 01:27:44 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id BB22C21F84B2 for ; Wed, 4 Apr 2012 01:27:43 -0700 (PDT) Received: by werb10 with SMTP id b10so10925wer.31 for ; Wed, 04 Apr 2012 01:27:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=FGQIrysEgv1BSi71hwqNPjXfMupmoNhc6JCyd9Ol6Vo=; b=gDvVb74fajfEEnFAbOZWRWUGx8vtr8K6kkyquTDMF+rAF4yuVb8dbKF5hQDZe+GisN jvmGgnlbxOwYnb3HC7OFurd/MEIRe9Qmaj6OK45P2gpw7nGl9IR8e37Pjucxibt7VJxe koJ7UFbpLqAGkJUFKFMhXT56UqVQMtanFdFpFjEghhAagpgoK0BjnRDSi3czp7uisjHU 64+l9EnuvZ+v+YpWlgMqsFfLtjOuURETbY3SZyyWbzVuWG9RCk+IVDSvH5kyBeIx5+BV 7KB/eaJqcGcjXrcUyZsUh8aWJvmu25Ku7rb3jCwjErWS2ppaQPZjihSawnb2QqcR+zw/ V52A== Received: by 10.180.107.104 with SMTP id hb8mr3093686wib.8.1333528062896; Wed, 04 Apr 2012 01:27:42 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.214.20 with HTTP; Wed, 4 Apr 2012 01:27:02 -0700 (PDT) In-Reply-To: References: From: "Angelo P. Castellani" Date: Wed, 4 Apr 2012 10:27:02 +0200 X-Google-Sender-Auth: ZwhrXmEibzKS-8wMK41MXEvnD4w Message-ID: To: Berta Carballido Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: core@ietf.org Subject: Re: [core] Sleepy devices + observer model X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 04 Apr 2012 08:27:45 -0000 Yes but both CSMA and TDMA have real limitations when your duty cycling goes lower some threshold. Imagine some CSMA based technique where the node is awake 20ms every 5-15 minutes. Do you think that this can work? I think that the whole thing is not usable at application layer, even in single-hop topology... Multihop would be even harder. Best, Angelo On Wed, Apr 4, 2012 at 10:21, Berta Carballido wr= ote: > Dear Angelo, > > There is no limit per se on the duty cycle. This can depend for instance = on your offered load (i.e. if many events need to be reported the radio nee= ds to be awake for longer and vice versa). [Also, as a remark with regards = to hardware & small duty cycles, some existing implementations of IEEE 802.= 15.4 experience loss of synchronisation due to clock drifts when having sma= ll duty cycles (see 3.2.2. in http://www2.tkn.tu-berlin.de/publications/pap= ers/TKN154.pdf)] > > Regards, > Berta. > > -----Original Message----- > From: angelo.castellani@gmail.com [mailto:angelo.castellani@gmail.com] On= Behalf Of Angelo P. Castellani > Sent: 04 April 2012 08:15 > To: Berta Carballido > Cc: core@ietf.org > Subject: Re: [core] Sleepy devices + observer model > > Using only L2 techniques, with a multihop network, what is the minumum du= ty cycle you can achieve? 1%? 0.1%? > > I think that the focus here is about duty cycling <<0.1%, these optimizat= ion will be for sure paired with L2 RDC techniques as well. > > I share your opinion of avoiding proxies, as much as possible, for this r= eason our take on the topic is by using an Alive message between the endpoi= nts. > > You can find it here: > http://tools.ietf.org/html/draft-castellani-core-alive > > Best, > Angelo > > On Mon, Apr 2, 2012 at 13:49, Berta Carballido = wrote: >> Hello all, >> >> Just to add some more information on my comment last Friday where I >> mentioned that observe model works for sleepy sensors (as requested by M= r. >> Bormann). >> >> 1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 First of all, remind that the MAC= layer or radio can store >> packets waiting to be sent. Some radios for instance can store ten >> packets, others one, etc. MAC layer buffer size depends on implementatio= n. >> >> Since internet stack is memory consuming I would expect to have type 1 >> type >> 2 device with enough memory to store several packets (but at least >> there will be always space for one).=C2=A0 Also take into account the >> tradeoff cost of proxy device vs. cost of radio with large buffer. >> >> 2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Second of all, there are some MAC= protocols that synchronize >> in time (TDMA based) and some others that can be asynchronous (i.e. >> CSMA based). In any case, they will always figure out when they must >> transmit to reach a neighbour. >> >> Thus, if a device =E2=80=9Ca=E2=80=9D wants to subscribe (observe) to a = device =E2=80=9Cb=E2=80=9D >> that is sleeping. The device =E2=80=9Ca=E2=80=9D APP layer will generate= a request >> packet that will go down the stack till the buffer. Then the =E2=80=9Ca= =E2=80=9D MAC will wait until =E2=80=9Cb=E2=80=9D >> radio wakes up and then deliver the packet to =E2=80=9Cb=E2=80=9D. =E2= =80=9Cb=E2=80=9D will read the >> packet, process the request and act accordingly. Thus the observe >> model works for sleeping devices even if a request has to go through >> several intermediary sleeping nodes. >> >> One could wonder how to establish the timeout value in such cases >> where sleeping devices have to be traversed.=C2=A0 One way of doing it c= an >> be using cross-layer info, a possible example using a CSMA like MAC >> could be (note that I just invented this example, it may be missing >> something): Timeout=3D 2 >> * RPL_hop_count_metric=C2=A0 * IEEE802.15.4_duty_cycle * Probability_rtx= * >> Mean_time_gain_access [note that it is a common practise in the WSN >> domain to use cross-layer info to optimise protocol/algorithm performanc= e]. >> >> Moreover, if a proxy is required in the vicinity of every sleeping >> device (and think here about proxy monetary costs as well), only star >> like topologies make sense (with a proxy backbone possibly using a >> different phy layer).=C2=A0 For instance, in the scheme below the sleepy >> device =E2=80=9Ca=E2=80=9D is connected in a star like fashion to the pr= oxy =E2=80=9Cpa=E2=80=9D (same for =E2=80=9Cb=E2=80=9D and =E2=80=9Cpb=E2= =80=9D). >> And the proxies communicate directly (or multihop) to each other and >> to the border router (=E2=80=9Cbr=E2=80=9D) . >> >> a -- pa -- br -- pb -- b >> >> If this scheme of sleepy star-leafs plus proxy backbone is not used, >> whenever a node wants to perform a request, it will have to traverse >> sleeping devices to reach a proxy, where delays will be introduced. >> For instance, in the diagram below =E2=80=9Ca=E2=80=9D would have to tra= verse the >> sleeping device =E2=80=9Cs=E2=80=9D to reach the proxy =E2=80=9Cpb=E2=80= =9D of =E2=80=9Cb=E2=80=9D. Thus, if proxies >> are used to facilitate fast access to information, multihop topologies >> of sleeping devices with proxies in between do not make sense. >> >> a -- s -- pb -- b >> >> However, one of the advantages of battery powered sensors is their >> freedom of placement! Imagine a vineyard where you want to monitor the >> soil humidity, would it make sense to have a line powered proxy every >> =E2=80=9Cx=E2=80=9D meters, or would it make more sense to have a multih= op topology of sleeping devices? >> >> Thus my conclusions are: >> >> a)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Server and observer models are appropri= ate for sleeping >> devices >> >> b)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A proxy may be useful for some applicat= ions (for instance when >> the sleeping device wants to remain always sleeping unless some event >> that needs to be reported happens) >> >> c)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Proxies make sense only for star-= like/star backbone >> topologies >> >> Regards, >> >> Berta. >> >> >> >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> From angelo.castellani@gmail.com Wed Apr 4 01:36:27 2012 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 E331421F849C; Wed, 4 Apr 2012 01:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.327 X-Spam-Level: X-Spam-Status: No, score=-2.327 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJpwRC4JE7Z7; Wed, 4 Apr 2012 01:36:27 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 14DD721F8498; Wed, 4 Apr 2012 01:36:26 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so14652wgb.13 for ; Wed, 04 Apr 2012 01:36:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=R8SyFEKrjZXUC6YAoDuf8hT9oCQmzz26PoqQ8Z14THE=; b=jZncfeq4vNC1PMKzMprKAv/xWoXWfiQ3HxZoyqy/97cXxYybDJ5LLAdp+xlSOAzGFQ hz+z6p1IgmtUVdQ5OsoiQDBL0wrfFbeodoghZqZXIK/Bw/iKg/B/UELBiJyMF2EUdxtN 0wVz1VJXNcpRh1c1LyuqT8Ei0ft+KnjZqjuNMQhCsEdDP1momzPiX1ffyTlrRWaLvTk3 02YNc7WSUKfkEC/ITT/kB4ICFUmSACFfEIA25pWBWXh+ZbTlkRWLAz1do5IdaNmY4oWx rJ6BmVYbCshFDtx0e0N+UTsTWyuifMtmiHg2B823fa//IxtkJlRtjMRQ+EJmpTuN8ZHB +Xng== Received: by 10.180.73.143 with SMTP id l15mr3143474wiv.11.1333528585778; Wed, 04 Apr 2012 01:36:25 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.214.20 with HTTP; Wed, 4 Apr 2012 01:35:45 -0700 (PDT) In-Reply-To: References: From: "Angelo P. Castellani" Date: Wed, 4 Apr 2012 10:35:45 +0200 X-Google-Sender-Auth: 0CbooNbvX26hXu5csnqs2p0Rp6Y Message-ID: To: matthieu.vial@non.schneider-electric.com Content-Type: text/plain; charset=UTF-8 Cc: core-bounces@ietf.org, core@ietf.org Subject: Re: [core] Sleepy devices + observer model X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 04 Apr 2012 08:36:28 -0000 On Wed, Apr 4, 2012 at 10:20, wrote: > Without a cache intermediary you will probably suffer from high latency. The requirement for an intermediary to enable sleepy sensors to work it is quite tight I think. The proxy is not a simple entity, it requires at least a class-2 device but probably something more. Don't you think? Do we want to enable sleepy sensors only when that intermediary is available? > Why do you need something at the message layer when Carsten's proposition > can trigger an "I'm alive" indication with a simple POST request? Of course at application layer you can get this done with some ad-hoc application pattern, but I think that for the sake of interperability this should be done in a standard way. Moreover in Carsten's example, you need 1 mid-sized by the sleepy node and 1 tiny message from each interested listener, then 1 message for each interested listener (imagine problems when multicast is involved). Using CoAP Alive, the ALV message is a very tiny one, and thanks to its special, standard semantics it is an useful and optimizated for the common case of a node that wakes up. You need only the ALV message, the "magic" that Carsten was thinking about in its slides is worked out by the alive message. :) Best, Angelo From Berta.Carballido@cit.ie Wed Apr 4 01:55:24 2012 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 A4F2E21F86DD for ; Wed, 4 Apr 2012 01:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sD3XUjbruXl0 for ; Wed, 4 Apr 2012 01:55:23 -0700 (PDT) Received: from mx-1.cit.ie (mx-1.cit.ie [157.190.3.45]) by ietfa.amsl.com (Postfix) with ESMTP id 230EC21F86AB for ; Wed, 4 Apr 2012 01:55:23 -0700 (PDT) X-ASG-Debug-ID: 1333529717-019f2807eeb4750001-aa7cYp Received: from CITMAIL.cit.ie ([157.190.22.71]) by mx-1.cit.ie with ESMTP id 4C6CjuddzzHPB4CZ; Wed, 04 Apr 2012 09:55:17 +0100 (IST) X-Barracuda-Envelope-From: Berta.Carballido@cit.ie X-Barracuda-Apparent-Source-IP: 157.190.22.71 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 4 Apr 2012 09:55:17 +0100 X-ASG-Orig-Subj: RE: [core] Sleepy devices + observer model Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Sleepy devices + observer model Thread-Index: Ac0SPM/AwR+Nj4kbTRCvJuLpTCOUlAAAK2pA References: From: "Berta Carballido" To: "Angelo P. Castellani" X-Barracuda-Connect: UNKNOWN[157.190.22.71] X-Barracuda-Start-Time: 1333529717 X-Barracuda-URL: http://157.190.3.45:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at cit.ie X-Barracuda-Spam-Score: 0.12 X-Barracuda-Spam-Status: No, SCORE=0.12 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=CN_BODY_332 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.93147 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.12 CN_BODY_332 BODY: CN_BODY_332 Cc: core@ietf.org Subject: Re: [core] Sleepy devices + observer model X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 04 Apr 2012 08:55:24 -0000 SGVsbG8sDQoNCiJZZXMgYnV0IGJvdGggQ1NNQSBhbmQgVERNQSBoYXZlIHJlYWwgbGltaXRhdGlv bnMgd2hlbiB5b3VyIGR1dHkgY3ljbGluZyBnb2VzIGxvd2VyIHNvbWUgdGhyZXNob2xkLiINCg0K V2hlbiB0aGUgc2xlZXAgdGltZSBnb2VzIGFib3ZlIHNvbWUgdGhyZXNob2xkIHRoZXJlIGNhbiBi ZSBwcm9ibGVtcyB3aXRoIHRoZSBoYXJkd2FyZSB5ZXMsIGl0IGlzIG5vdCBhIHByb2JsZW0gb2Yg dGhlIE1BQyBwcm90b2NvbCAobm90ZSB0aGF0IHlvdSBjYW4gaGF2ZSBhIHNtYWxsIGR1dHkgY3lj bGUgZXZlbiBpZiB5b3UgZG8gbm90IHNsZWVwIGxvbmcpDQoNCiJJbWFnaW5lIHNvbWUgQ1NNQSBi YXNlZCB0ZWNobmlxdWUgd2hlcmUgdGhlIG5vZGUgaXMgYXdha2UgMjBtcyBldmVyeQ0KNS0xNSBt aW51dGVzLiBEbyB5b3UgdGhpbmsgdGhhdCB0aGlzIGNhbiB3b3JrPw0KDQpJIHRoaW5rIHRoYXQg dGhlIHdob2xlIHRoaW5nIGlzIG5vdCB1c2FibGUgYXQgYXBwbGljYXRpb24gbGF5ZXIsIGV2ZW4g aW4gc2luZ2xlLWhvcCB0b3BvbG9neS4uLiBNdWx0aWhvcCB3b3VsZCBiZSBldmVuIGhhcmRlci4i DQoNClNvcnJ5IGlmIHRoaXMgd2FzIG1lbnRpb25lZCBiZWZvcmUsIEkgY2Fubm90IGZpbmQgdGhp cyBpbmZvcm1hdGlvbiAuLi4gV2hhdCBraW5kIG9mIGFwcGxpY2F0aW9ucyBhcmUgYmVpbmcgY29u c2lkZXJlZD8gV2h5IGFyZSB5b3UgY29uc2lkZXJpbmcgYW4gYXJ0aWZpY2lhbCBsaW1pdCBvZiA8 PDAuMSU/IElzIHRoaXMgdGhlIHJlcXVpcmVtZW50IG9mIHNvbWUgc3BlY2lmaWMgYXBwbGljYXRp b24gb3IgdGhlIHJlcXVpcmVtZW50IG9mIHRoZSBpbnN0YWxsZXI/IEJlY2F1c2Ugc29tZSBtYXkg c2F5IHRoYXQgYSBkdXR5IGN5Y2xlIG9mIDw8MC4xJSBpcyByZXF1aXJlZCB0byBleHBhbmQgbGlm ZXRpbWUgb2YgZGV2aWNlcywgYnV0IHRoZW4gYW4gYXBwbGljYXRpb24gbWF5IG5lZWQgdG8gdHJh bnNtaXQgcGFja2V0cyBtb3JlIG9mdGVuIHRoYXQgd2hhdCBpcyBlc3RhYmxpc2hlZCBieSB0aGF0 IGxpbWl0Li4uDQoNClJlZ2FyZHMsDQpCZXJ0YS4NCg0KT24gV2VkLCBBcHIgNCwgMjAxMiBhdCAx MDoyMSwgQmVydGEgQ2FyYmFsbGlkbyA8QmVydGEuQ2FyYmFsbGlkb0BjaXQuaWU+IHdyb3RlOg0K PiBEZWFyIEFuZ2VsbywNCj4NCj4gVGhlcmUgaXMgbm8gbGltaXQgcGVyIHNlIG9uIHRoZSBkdXR5 IGN5Y2xlLiBUaGlzIGNhbiBkZXBlbmQgZm9yIA0KPiBpbnN0YW5jZSBvbiB5b3VyIG9mZmVyZWQg bG9hZCAoaS5lLiBpZiBtYW55IGV2ZW50cyBuZWVkIHRvIGJlIHJlcG9ydGVkIA0KPiB0aGUgcmFk aW8gbmVlZHMgdG8gYmUgYXdha2UgZm9yIGxvbmdlciBhbmQgdmljZSB2ZXJzYSkuIFtBbHNvLCBh cyBhIA0KPiByZW1hcmsgd2l0aCByZWdhcmRzIHRvIGhhcmR3YXJlICYgc21hbGwgZHV0eSBjeWNs ZXMsIHNvbWUgZXhpc3RpbmcgDQo+IGltcGxlbWVudGF0aW9ucyBvZiBJRUVFIDgwMi4xNS40IGV4 cGVyaWVuY2UgbG9zcyBvZiBzeW5jaHJvbmlzYXRpb24gDQo+IGR1ZSB0byBjbG9jayBkcmlmdHMg d2hlbiBoYXZpbmcgc21hbGwgZHV0eSBjeWNsZXMgKHNlZSAzLjIuMi4gaW4gDQo+IGh0dHA6Ly93 d3cyLnRrbi50dS1iZXJsaW4uZGUvcHVibGljYXRpb25zL3BhcGVycy9US04xNTQucGRmKV0NCj4N Cj4gUmVnYXJkcywNCj4gQmVydGEuDQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IGFuZ2Vsby5jYXN0ZWxsYW5pQGdtYWlsLmNvbSBbbWFpbHRvOmFuZ2Vsby5jYXN0ZWxs YW5pQGdtYWlsLmNvbV0gDQo+IE9uIEJlaGFsZiBPZiBBbmdlbG8gUC4gQ2FzdGVsbGFuaQ0KPiBT ZW50OiAwNCBBcHJpbCAyMDEyIDA4OjE1DQo+IFRvOiBCZXJ0YSBDYXJiYWxsaWRvDQo+IENjOiBj b3JlQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbY29yZV0gU2xlZXB5IGRldmljZXMgKyBvYnNl cnZlciBtb2RlbA0KPg0KPiBVc2luZyBvbmx5IEwyIHRlY2huaXF1ZXMsIHdpdGggYSBtdWx0aWhv cCBuZXR3b3JrLCB3aGF0IGlzIHRoZSBtaW51bXVtIGR1dHkgY3ljbGUgeW91IGNhbiBhY2hpZXZl PyAxJT8gMC4xJT8NCj4NCj4gSSB0aGluayB0aGF0IHRoZSBmb2N1cyBoZXJlIGlzIGFib3V0IGR1 dHkgY3ljbGluZyA8PDAuMSUsIHRoZXNlIG9wdGltaXphdGlvbiB3aWxsIGJlIGZvciBzdXJlIHBh aXJlZCB3aXRoIEwyIFJEQyB0ZWNobmlxdWVzIGFzIHdlbGwuDQo+DQo+IEkgc2hhcmUgeW91ciBv cGluaW9uIG9mIGF2b2lkaW5nIHByb3hpZXMsIGFzIG11Y2ggYXMgcG9zc2libGUsIGZvciB0aGlz IHJlYXNvbiBvdXIgdGFrZSBvbiB0aGUgdG9waWMgaXMgYnkgdXNpbmcgYW4gQWxpdmUgbWVzc2Fn ZSBiZXR3ZWVuIHRoZSBlbmRwb2ludHMuDQo+DQo+IFlvdSBjYW4gZmluZCBpdCBoZXJlOg0KPiBo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jYXN0ZWxsYW5pLWNvcmUtYWxpdmUNCj4N Cj4gQmVzdCwNCj4gQW5nZWxvDQo+DQo+IE9uIE1vbiwgQXByIDIsIDIwMTIgYXQgMTM6NDksIEJl cnRhIENhcmJhbGxpZG8gPEJlcnRhLkNhcmJhbGxpZG9AY2l0LmllPiB3cm90ZToNCj4+IEhlbGxv IGFsbCwNCj4+DQo+PiBKdXN0IHRvIGFkZCBzb21lIG1vcmUgaW5mb3JtYXRpb24gb24gbXkgY29t bWVudCBsYXN0IEZyaWRheSB3aGVyZSBJIA0KPj4gbWVudGlvbmVkIHRoYXQgb2JzZXJ2ZSBtb2Rl bCB3b3JrcyBmb3Igc2xlZXB5IHNlbnNvcnMgKGFzIHJlcXVlc3RlZCBieSBNci4NCj4+IEJvcm1h bm4pLg0KPj4NCj4+IDEuwqDCoMKgwqDCoMKgIEZpcnN0IG9mIGFsbCwgcmVtaW5kIHRoYXQgdGhl IE1BQyBsYXllciBvciByYWRpbyBjYW4gc3RvcmUgDQo+PiBwYWNrZXRzIHdhaXRpbmcgdG8gYmUg c2VudC4gU29tZSByYWRpb3MgZm9yIGluc3RhbmNlIGNhbiBzdG9yZSB0ZW4gDQo+PiBwYWNrZXRz LCBvdGhlcnMgb25lLCBldGMuIE1BQyBsYXllciBidWZmZXIgc2l6ZSBkZXBlbmRzIG9uIGltcGxl bWVudGF0aW9uLg0KPj4NCj4+IFNpbmNlIGludGVybmV0IHN0YWNrIGlzIG1lbW9yeSBjb25zdW1p bmcgSSB3b3VsZCBleHBlY3QgdG8gaGF2ZSB0eXBlIA0KPj4gMSB0eXBlDQo+PiAyIGRldmljZSB3 aXRoIGVub3VnaCBtZW1vcnkgdG8gc3RvcmUgc2V2ZXJhbCBwYWNrZXRzIChidXQgYXQgbGVhc3Qg DQo+PiB0aGVyZSB3aWxsIGJlIGFsd2F5cyBzcGFjZSBmb3Igb25lKS7CoCBBbHNvIHRha2UgaW50 byBhY2NvdW50IHRoZSANCj4+IHRyYWRlb2ZmIGNvc3Qgb2YgcHJveHkgZGV2aWNlIHZzLiBjb3N0 IG9mIHJhZGlvIHdpdGggbGFyZ2UgYnVmZmVyLg0KPj4NCj4+IDIuwqDCoMKgwqDCoMKgIFNlY29u ZCBvZiBhbGwsIHRoZXJlIGFyZSBzb21lIE1BQyBwcm90b2NvbHMgdGhhdCBzeW5jaHJvbml6ZSAN Cj4+IGluIHRpbWUgKFRETUEgYmFzZWQpIGFuZCBzb21lIG90aGVycyB0aGF0IGNhbiBiZSBhc3lu Y2hyb25vdXMgKGkuZS4NCj4+IENTTUEgYmFzZWQpLiBJbiBhbnkgY2FzZSwgdGhleSB3aWxsIGFs d2F5cyBmaWd1cmUgb3V0IHdoZW4gdGhleSBtdXN0IA0KPj4gdHJhbnNtaXQgdG8gcmVhY2ggYSBu ZWlnaGJvdXIuDQo+Pg0KPj4gVGh1cywgaWYgYSBkZXZpY2Ug4oCcYeKAnSB3YW50cyB0byBzdWJz Y3JpYmUgKG9ic2VydmUpIHRvIGEgZGV2aWNlIOKAnGLigJ0NCj4+IHRoYXQgaXMgc2xlZXBpbmcu IFRoZSBkZXZpY2Ug4oCcYeKAnSBBUFAgbGF5ZXIgd2lsbCBnZW5lcmF0ZSBhIHJlcXVlc3QgDQo+ PiBwYWNrZXQgdGhhdCB3aWxsIGdvIGRvd24gdGhlIHN0YWNrIHRpbGwgdGhlIGJ1ZmZlci4gVGhl biB0aGUg4oCcYeKAnSBNQUMgd2lsbCB3YWl0IHVudGlsIOKAnGLigJ0NCj4+IHJhZGlvIHdha2Vz IHVwIGFuZCB0aGVuIGRlbGl2ZXIgdGhlIHBhY2tldCB0byDigJxi4oCdLiDigJxi4oCdIHdpbGwg cmVhZCB0aGUgDQo+PiBwYWNrZXQsIHByb2Nlc3MgdGhlIHJlcXVlc3QgYW5kIGFjdCBhY2NvcmRp bmdseS4gVGh1cyB0aGUgb2JzZXJ2ZSANCj4+IG1vZGVsIHdvcmtzIGZvciBzbGVlcGluZyBkZXZp Y2VzIGV2ZW4gaWYgYSByZXF1ZXN0IGhhcyB0byBnbyB0aHJvdWdoIA0KPj4gc2V2ZXJhbCBpbnRl cm1lZGlhcnkgc2xlZXBpbmcgbm9kZXMuDQo+Pg0KPj4gT25lIGNvdWxkIHdvbmRlciBob3cgdG8g ZXN0YWJsaXNoIHRoZSB0aW1lb3V0IHZhbHVlIGluIHN1Y2ggY2FzZXMgDQo+PiB3aGVyZSBzbGVl cGluZyBkZXZpY2VzIGhhdmUgdG8gYmUgdHJhdmVyc2VkLsKgIE9uZSB3YXkgb2YgZG9pbmcgaXQg Y2FuIA0KPj4gYmUgdXNpbmcgY3Jvc3MtbGF5ZXIgaW5mbywgYSBwb3NzaWJsZSBleGFtcGxlIHVz aW5nIGEgQ1NNQSBsaWtlIE1BQyANCj4+IGNvdWxkIGJlIChub3RlIHRoYXQgSSBqdXN0IGludmVu dGVkIHRoaXMgZXhhbXBsZSwgaXQgbWF5IGJlIG1pc3NpbmcNCj4+IHNvbWV0aGluZyk6IFRpbWVv dXQ9IDINCj4+ICogUlBMX2hvcF9jb3VudF9tZXRyaWPCoCAqIElFRUU4MDIuMTUuNF9kdXR5X2N5 Y2xlICogUHJvYmFiaWxpdHlfcnR4ICogDQo+PiBNZWFuX3RpbWVfZ2Fpbl9hY2Nlc3MgW25vdGUg dGhhdCBpdCBpcyBhIGNvbW1vbiBwcmFjdGlzZSBpbiB0aGUgV1NOIA0KPj4gZG9tYWluIHRvIHVz ZSBjcm9zcy1sYXllciBpbmZvIHRvIG9wdGltaXNlIHByb3RvY29sL2FsZ29yaXRobSBwZXJmb3Jt YW5jZV0uDQo+Pg0KPj4gTW9yZW92ZXIsIGlmIGEgcHJveHkgaXMgcmVxdWlyZWQgaW4gdGhlIHZp Y2luaXR5IG9mIGV2ZXJ5IHNsZWVwaW5nIA0KPj4gZGV2aWNlIChhbmQgdGhpbmsgaGVyZSBhYm91 dCBwcm94eSBtb25ldGFyeSBjb3N0cyBhcyB3ZWxsKSwgb25seSBzdGFyIA0KPj4gbGlrZSB0b3Bv bG9naWVzIG1ha2Ugc2Vuc2UgKHdpdGggYSBwcm94eSBiYWNrYm9uZSBwb3NzaWJseSB1c2luZyBh IA0KPj4gZGlmZmVyZW50IHBoeSBsYXllcikuwqAgRm9yIGluc3RhbmNlLCBpbiB0aGUgc2NoZW1l IGJlbG93IHRoZSBzbGVlcHkgDQo+PiBkZXZpY2Ug4oCcYeKAnSBpcyBjb25uZWN0ZWQgaW4gYSBz dGFyIGxpa2UgZmFzaGlvbiB0byB0aGUgcHJveHkg4oCccGHigJ0gKHNhbWUgZm9yIOKAnGLigJ0g YW5kIOKAnHBi4oCdKS4NCj4+IEFuZCB0aGUgcHJveGllcyBjb21tdW5pY2F0ZSBkaXJlY3RseSAo b3IgbXVsdGlob3ApIHRvIGVhY2ggb3RoZXIgYW5kIA0KPj4gdG8gdGhlIGJvcmRlciByb3V0ZXIg KOKAnGJy4oCdKSAuDQo+Pg0KPj4gYSAtLSBwYSAtLSBiciAtLSBwYiAtLSBiDQo+Pg0KPj4gSWYg dGhpcyBzY2hlbWUgb2Ygc2xlZXB5IHN0YXItbGVhZnMgcGx1cyBwcm94eSBiYWNrYm9uZSBpcyBu b3QgdXNlZCwgDQo+PiB3aGVuZXZlciBhIG5vZGUgd2FudHMgdG8gcGVyZm9ybSBhIHJlcXVlc3Qs IGl0IHdpbGwgaGF2ZSB0byB0cmF2ZXJzZSANCj4+IHNsZWVwaW5nIGRldmljZXMgdG8gcmVhY2gg YSBwcm94eSwgd2hlcmUgZGVsYXlzIHdpbGwgYmUgaW50cm9kdWNlZC4NCj4+IEZvciBpbnN0YW5j ZSwgaW4gdGhlIGRpYWdyYW0gYmVsb3cg4oCcYeKAnSB3b3VsZCBoYXZlIHRvIHRyYXZlcnNlIHRo ZSANCj4+IHNsZWVwaW5nIGRldmljZSDigJxz4oCdIHRvIHJlYWNoIHRoZSBwcm94eSDigJxwYuKA nSBvZiDigJxi4oCdLiBUaHVzLCBpZiBwcm94aWVzIA0KPj4gYXJlIHVzZWQgdG8gZmFjaWxpdGF0 ZSBmYXN0IGFjY2VzcyB0byBpbmZvcm1hdGlvbiwgbXVsdGlob3AgDQo+PiB0b3BvbG9naWVzIG9m IHNsZWVwaW5nIGRldmljZXMgd2l0aCBwcm94aWVzIGluIGJldHdlZW4gZG8gbm90IG1ha2Ugc2Vu c2UuDQo+Pg0KPj4gYSAtLSBzIC0tIHBiIC0tIGINCj4+DQo+PiBIb3dldmVyLCBvbmUgb2YgdGhl IGFkdmFudGFnZXMgb2YgYmF0dGVyeSBwb3dlcmVkIHNlbnNvcnMgaXMgdGhlaXIgDQo+PiBmcmVl ZG9tIG9mIHBsYWNlbWVudCEgSW1hZ2luZSBhIHZpbmV5YXJkIHdoZXJlIHlvdSB3YW50IHRvIG1v bml0b3IgDQo+PiB0aGUgc29pbCBodW1pZGl0eSwgd291bGQgaXQgbWFrZSBzZW5zZSB0byBoYXZl IGEgbGluZSBwb3dlcmVkIHByb3h5IA0KPj4gZXZlcnkg4oCceOKAnSBtZXRlcnMsIG9yIHdvdWxk IGl0IG1ha2UgbW9yZSBzZW5zZSB0byBoYXZlIGEgbXVsdGlob3AgdG9wb2xvZ3kgb2Ygc2xlZXBp bmcgZGV2aWNlcz8NCj4+DQo+PiBUaHVzIG15IGNvbmNsdXNpb25zIGFyZToNCj4+DQo+PiBhKcKg wqDCoMKgwqAgU2VydmVyIGFuZCBvYnNlcnZlciBtb2RlbHMgYXJlIGFwcHJvcHJpYXRlIGZvciBz bGVlcGluZyANCj4+IGRldmljZXMNCj4+DQo+PiBiKcKgwqDCoMKgwqAgQSBwcm94eSBtYXkgYmUg dXNlZnVsIGZvciBzb21lIGFwcGxpY2F0aW9ucyAoZm9yIGluc3RhbmNlIA0KPj4gd2hlbiB0aGUg c2xlZXBpbmcgZGV2aWNlIHdhbnRzIHRvIHJlbWFpbiBhbHdheXMgc2xlZXBpbmcgdW5sZXNzIHNv bWUgDQo+PiBldmVudCB0aGF0IG5lZWRzIHRvIGJlIHJlcG9ydGVkIGhhcHBlbnMpDQo+Pg0KPj4g YynCoMKgwqDCoMKgwqAgUHJveGllcyBtYWtlIHNlbnNlIG9ubHkgZm9yIHN0YXItbGlrZS9zdGFy IGJhY2tib25lIA0KPj4gdG9wb2xvZ2llcw0KPj4NCj4+IFJlZ2FyZHMsDQo+Pg0KPj4gQmVydGEu DQo+Pg0KPj4NCj4+DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+IGNvcmUgbWFpbGluZyBsaXN0DQo+PiBjb3JlQGlldGYub3JnDQo+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCj4+DQo= From angelo.castellani@gmail.com Wed Apr 4 02:06:16 2012 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 5175D21F870B for ; Wed, 4 Apr 2012 02:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gN8DB-yo1dLb for ; Wed, 4 Apr 2012 02:06:15 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id E489921F869F for ; Wed, 4 Apr 2012 02:06:09 -0700 (PDT) Received: by werb10 with SMTP id b10so36518wer.31 for ; Wed, 04 Apr 2012 02:06:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=53AsjfGfPAiS8TibCYL3rXuo8VeCYI3ljh8Qg6u11KE=; b=NfvHi1Tg9dza9ii9jqylxVAtdlu6Y4Q1W4Hm6D42mMWN8opQiM7CHo7oG9RCTJUSBk +NdpsWy8l38HtYTFbeQM8Z0m/ppI+l8MLlTsHY+t5L0dqO414YMYHN8aiiUyhbXgz0zf oL5fqSdZfch/4pxOkQJa6pWlCqnRw6BAeixgSGAGtsjwTlxiKei8x6AyuG1mEZCg1VYO +KKbaknUZXMk3yqm44VRYPCY4sQS2jJIcBpG1ah9wvPxx4SBa7S2W812TfdSdDLlDXHe g2lJZMe0Q28Qb7xqKk2UZLOEOoje5jvRUa1wKX7Usd/tdgddDOlx3Ps0aqQRkIJiS9Xl ts1g== Received: by 10.180.107.104 with SMTP id hb8mr3375501wib.8.1333530368985; Wed, 04 Apr 2012 02:06:08 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.214.20 with HTTP; Wed, 4 Apr 2012 02:05:28 -0700 (PDT) In-Reply-To: References: From: "Angelo P. Castellani" Date: Wed, 4 Apr 2012 11:05:28 +0200 X-Google-Sender-Auth: nehrQzkiE9P1ulKjzcxz6fhiLbA Message-ID: To: Berta Carballido Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: core@ietf.org Subject: Re: [core] Sleepy devices + observer model X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 04 Apr 2012 09:06:16 -0000 On Wed, Apr 4, 2012 at 10:55, Berta Carballido wr= ote: > Sorry if this was mentioned before, I cannot find this information ... Wh= at kind of applications are being considered? Why are you considering an ar= tificial limit of <<0.1%? Is this the requirement of some specific applicat= ion or the requirement of the installer? Because some may say that a duty c= ycle of <<0.1% is required to expand lifetime of devices, but then an appli= cation may need to transmit packets more often that what is established by = that limit... For example, enviromental monitoring traffic may live well with those duty cycles. Best, Angelo From tho@anche.no Wed Apr 4 04:28:27 2012 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 3F24221F86C8 for ; Wed, 4 Apr 2012 04:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgSv6iAFl5rA for ; Wed, 4 Apr 2012 04:28:26 -0700 (PDT) Received: from latitanza.investici.org (latitanza.investici.org [82.94.249.234]) by ietfa.amsl.com (Postfix) with ESMTP id B252B21F8693 for ; Wed, 4 Apr 2012 04:28:25 -0700 (PDT) Received: from [82.94.249.234] (latitanza [82.94.249.234]) (Authenticated sender: tho@anche.no) by localhost (Postfix) with ESMTPSA id 4A02898542; Wed, 4 Apr 2012 11:28:24 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Thomas Fossati In-Reply-To: Date: Wed, 4 Apr 2012 13:28:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5B8E186A-AA67-4421-A8D2-34056E1D325D@anche.no> References: To: "Angelo P. Castellani" , Berta Carballido X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Wed, 04 Apr 2012 05:31:35 -0700 Cc: core WG Subject: Re: [core] Sleepy devices + observer model X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 04 Apr 2012 11:46:41 -0000 On Apr 4, 2012, at 11:05 AM, Angelo P. Castellani wrote: > On Wed, Apr 4, 2012 at 10:55, Berta Carballido = wrote: >> Sorry if this was mentioned before, I cannot find this information = ... What kind of applications are being considered? Why are you = considering an artificial limit of <<0.1%? Is this the requirement of = some specific application or the requirement of the installer? Because = some may say that a duty cycle of <<0.1% is required to expand lifetime = of devices, but then an application may need to transmit packets more = often that what is established by that limit... >=20 > For example, enviromental monitoring traffic may live well with those > duty cycles. Another example: something which is wirelessly controlled by a = self-powered switch. This kind of switches generate their own operational energy by means of = harvesting =96 e.g. electro-mechanically through the user action of = pressing or releasing the button.=20 Hence they can access the radio link only for a very short time span, = with *non predictable* timing. Hence the Publish option :-)= From isaidyep@gmail.com Wed Apr 4 06:11:42 2012 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 3C4AD21F84F5 for ; Wed, 4 Apr 2012 06:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4bKpLZ64j+5 for ; Wed, 4 Apr 2012 06:11:41 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 15DB621F84DE for ; Wed, 4 Apr 2012 06:11:40 -0700 (PDT) Received: by wibhr17 with SMTP id hr17so473392wib.1 for ; Wed, 04 Apr 2012 06:11:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=S4Hh0i7Nf0TgJxtH9c3DU8B4XjS2ulbksAzf/FCKPFY=; b=KLG+VXFdkeUQcuOyKLwCGcMvHk5bIYcLW3XLumUvmUL0jSNNofRaHlhyr/uSnyHftU fULCbxAS4U1pD6dWjo+mCIoAfu2t6mW50gdCy1ZZ8VPna8LIMMxZeVM05NKroSzQpIFs H5qlxMniG3fI0wrMim1Caxz1DxTi9jx8bTjDG6+tZT5mjqWJsANIzw81RWYhjW0WAN7b /GvfknvfhafxeopP1cAxrKTgVZC8bSTtuAJOj1EeD1JEpuwgGXi8B2naktJ54Dv/X5gv sU4r848HGbkqzMmWjzwdJ+2PqFsad48JCa7dxh2w9Bjr2sQG36o9qPYPHrPZXoZGLsFP yOZA== MIME-Version: 1.0 Received: by 10.180.104.231 with SMTP id gh7mr5217236wib.10.1333545099550; Wed, 04 Apr 2012 06:11:39 -0700 (PDT) Received: by 10.180.82.233 with HTTP; Wed, 4 Apr 2012 06:11:39 -0700 (PDT) In-Reply-To: <5B8E186A-AA67-4421-A8D2-34056E1D325D@anche.no> References: <5B8E186A-AA67-4421-A8D2-34056E1D325D@anche.no> Date: Wed, 4 Apr 2012 15:11:39 +0200 Message-ID: From: Mirko Rossini To: Thomas Fossati Content-Type: multipart/alternative; boundary=f46d044288bcf360aa04bcda292d Cc: core WG Subject: Re: [core] Sleepy devices + observer model X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 04 Apr 2012 13:11:42 -0000 --f46d044288bcf360aa04bcda292d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 2012/4/4 Thomas Fossati > On Apr 4, 2012, at 11:05 AM, Angelo P. Castellani wrote: > > On Wed, Apr 4, 2012 at 10:55, Berta Carballido > wrote: > >> Sorry if this was mentioned before, I cannot find this information ... > What kind of applications are being considered? > > For example, enviromental monitoring traffic may live well with those > > duty cycles. > > Another example: something which is wirelessly controlled by a > self-powered switch. > > This kind of switches generate their own operational energy by means of > harvesting =96 e.g. electro-mechanically through the user action of press= ing > or releasing the button. > > Hence they can access the radio link only for a very short time span, wit= h > *non predictable* timing. Hence the Publish option :-) > This is also the case of M2M only interactions, e.g. a sensor that activates its radio only when it changes state and/or reaches a trigger value. --f46d044288bcf360aa04bcda292d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 2012/4/4 Thomas Fossati <tho@anche.no>
On Apr 4, 2012, at 11:05 AM, Angelo P. Castellani wrote:<= br> > On Wed, Apr 4, 2012 at 10:55, Berta Carballido <Berta.Carballido@cit.ie> wrote:
>> Sorry if this was mentioned before, I cannot find this information= ... What kind of applications are being considered?=A0
> For example, enviromental monitoring traffic may live well with those<= br> > duty cycles.

Another example: something which is wirelessly controlled by a self-p= owered switch.

This kind of switches generate their own operational energy by means of har= vesting =96 e.g. electro-mechanically through the user action of pressing o= r releasing the button.

Hence they can access the radio link only for a very short time span, with = *non predictable* timing. =A0Hence the Publish option :-)
<= div>
This is also the case of M2M only interactions, e.g. a s= ensor that activates its radio only when it changes state and/or reaches a = trigger value.=A0
--f46d044288bcf360aa04bcda292d-- From matthieu.vial@non.schneider-electric.com Wed Apr 4 08:14:53 2012 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 7B29721F8831; Wed, 4 Apr 2012 08:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.949 X-Spam-Level: X-Spam-Status: No, score=-4.949 tagged_above=-999 required=5 tests=[AWL=1.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rP+83rNS15V; Wed, 4 Apr 2012 08:14:52 -0700 (PDT) Received: from mailX03.eud.schneider-electric.com (mailx03.eud.schneider-electric.com [205.167.7.41]) by ietfa.amsl.com (Postfix) with ESMTP id E4A2121F8828; Wed, 4 Apr 2012 08:14:51 -0700 (PDT) Received: from ATEUI01.schneider-electric.com ([10.198.14.9]) by mailX03.eud.schneider-electric.com with ESMTP id 2012040417100605-205067 ; Wed, 4 Apr 2012 17:10:06 +0200 In-Reply-To: To: "Angelo P. Castellani" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 From: matthieu.vial@non.schneider-electric.com Message-ID: Date: Wed, 4 Apr 2012 17:14:49 +0200 X-MIMETrack: Serialize by Router on ATEUI01.Schneider-Electric.com/T/SVR/Schneider at 04/04/2012 17:15:51, Serialize complete at 04/04/2012 17:15:51, Itemize by SMTP Server on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 04/04/2012 17:10:06, Serialize by Router on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 04/04/2012 17:10:07, Serialize complete at 04/04/2012 17:10:07 Content-Type: text/plain; charset="US-ASCII" Cc: angelo.castellani@gmail.com, core-bounces@ietf.org, core@ietf.org Subject: Re: [core] Sleepy devices + observer model X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 04 Apr 2012 15:14:53 -0000 Angelo, see my comments >Of course at application layer you can get this done with some ad-hoc >application pattern, but I think that for the sake of interperability >this should be done in a standard way. IMO it's easier to standardize a Function Set in a profile than a low-level message type in an already full header field. >Moreover in Carsten's example, you need 1 mid-sized by the sleepy node >and 1 tiny message from each interested listener, then 1 message for >each interested listener (imagine problems when multicast is >involved). For me the number of messages is the same. C1 C2 C3 S | | | . server is sleeping | | | . | | | . | | | . | | | . server wakes up | | | . NON |<--|<--|<----| POST coap://[ff02::1]/alive | | | | | | | | CON MID=0x1234 |------------>| GET /a | | | | | | | | ACK MID=0x1234 |<------------| 2.05 "A" | | | . | | | . server goes sleeping again | | | . | | | . | | | . >Using CoAP Alive, the ALV message is a very tiny one, and thanks to >its special, standard semantics it is an useful and optimizated for >the common case of a node that wakes up. Does this working group really want to override the NON message type semantics when we can do the same with a simple CoAP request? I'm personally not in favor of adding new message types. >You need only the ALV >message, the "magic" that Carsten was thinking about in its slides is >worked out by the alive message. :) The magic is about reusing the token from the POST in the observe relationship, thus avoiding the initial GET request to create the subscription. We just need a short explanatory text, nothing more. In your draft, the example is still using an explicit observe subscription so no magic here. Best regards, Matthieu From angelo.castellani@gmail.com Wed Apr 4 08:33:23 2012 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 77DAE21F85A2; Wed, 4 Apr 2012 08:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+MkucPEJGOH; Wed, 4 Apr 2012 08:33:22 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id C6DD021F879E; Wed, 4 Apr 2012 08:33:20 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so267609wgb.13 for ; Wed, 04 Apr 2012 08:33:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=oV4bZQ0cEFQzftPWsjt+iZQqUfEjSu9JXsn1d5s4mr8=; b=mm4c6ZclI+Tzno37y3aIiiONo18kgPeJnM5ZiOR8E0JXZaWI6TwLJN+rlU2+b6i8YH kDerQVtcFM/YS/NoZ61t7XTEeiP5h80j7BfkuiGhQ4B+5oHaUsmrpYrB+SXI4+WgV9To SNusZFUSTx8o8evxLxDy3J+6TQJO2rWRFIwMYJ++ix7SvHIQSZgJnEcxJ6s78fgM8iKp dbpWF6rEKzkXd4XeDdDLIpm+vojO0OuR0xuBEzTP7zrhfJpRpqP57MjnghEoSCDukfOl D6h2warM7Fnp9Zs4lhcATYj+P7yg156v8T+0j6a8SV0TyW083CO1JLlzU2Vah4LI4TfM cPLw== Received: by 10.180.107.104 with SMTP id hb8mr6315309wib.8.1333553599799; Wed, 04 Apr 2012 08:33:19 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.214.20 with HTTP; Wed, 4 Apr 2012 08:32:38 -0700 (PDT) In-Reply-To: References: From: "Angelo P. Castellani" Date: Wed, 4 Apr 2012 17:32:38 +0200 X-Google-Sender-Auth: P-Ry80RWnxCPOVxHEBDEXkO0-vU Message-ID: To: matthieu.vial@non.schneider-electric.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: core-bounces@ietf.org, core@ietf.org Subject: Re: [core] Sleepy devices + observer model X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 04 Apr 2012 15:33:23 -0000 On Wed, Apr 4, 2012 at 17:14, w= rote: > =C2=A0 |<--|<--|<----| POST coap://[ff02::1]/alive Do you want to reserve the "alive" URI-Path Option value to provide this semantics? > Does this working group really want to override the NON message type > semantics when we can do the same with a simple CoAP request? You don't override the NON message type, an empty NON simply does not exist. (you can find it by looking at the coap-09 spec, in the section where NON is specified). > The magic is about reusing the token from the POST in the observe > relationship, thus avoiding the initial GET request to create the > subscription. > We just need a short explanatory text, nothing more. > In your draft, the example is still using an explicit observe subscriptio= n > so no magic here. It's not explanatory text, the ALV message solicits the message-layer to send messages to a particular peer which is currently available. This feature belongs to the message-layer itself, that could queue messages for a sleeping peer as long as an ALV is received. If you want to recreate this function by reserving a special resource name, you have two problems: 1. the request to the "alive" resource is bigger, as it needs the URI-Path option. 2. the request to the "alive" resource needs to go up to this resource (if available), and this resource will do a cross-layer solicit to messages queued for that destination (the message-layer itself does not have access to the request/response layer). this is not efficient, neither quick... An empty NON message should be already ignored by every implementation, so if you don't support this feature you don't need any exception to handle ignoring messages to the "alive" resource. Moreover I don't think that reserving namespace for low-level communication features is a clean design, anyway I don't know whether this resides in design practice or design taste. Best, Angelo From angelo.castellani@gmail.com Wed Apr 4 08:37:46 2012 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 71EC221F85C5 for ; Wed, 4 Apr 2012 08:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDEG9x7BOLcq for ; Wed, 4 Apr 2012 08:37:45 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 9E61F21F85BB for ; Wed, 4 Apr 2012 08:37:45 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so332627wib.13 for ; Wed, 04 Apr 2012 08:37:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=bnG+4QxmAf541y/h5X1iVMc4SA9F5oflDzV5wnraNxk=; b=lTqGJF5QmrRdIbf67scnQwnFa4iy6bhtFzuY22kbrxQcu+JVoyirfKu7XT+K0a8whC 6qBD5HWEmUMXDwpbG4fsqwpAaxBcqIiKComTKqayjdZ4EcZa7r6nL7bHKvI0zxEY92G+ T1Mcb14EJf4H7jp3F22TyWgzZYu77qBTPo/0kBne9cVZ8KEDOdB1CeZPrFpQLquJAGe3 OOS6/Z5fK8fRoVAnUGecxi/yocCrCJ9XnkICg6Kn4xhS7L07dM2YUdSl5X15PdJj1FAb TJizvqIrTWkvek6OPQyjnjFASZS24MmMrbt775D1DQP6xzC6ALEWUpDzX6uphwS+ECWz hc3Q== Received: by 10.180.107.162 with SMTP id hd2mr6418708wib.8.1333553864883; Wed, 04 Apr 2012 08:37:44 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.214.20 with HTTP; Wed, 4 Apr 2012 08:37:04 -0700 (PDT) From: "Angelo P. Castellani" Date: Wed, 4 Apr 2012 17:37:04 +0200 X-Google-Sender-Auth: FNi7yH2LPX57Yy36_Cl26PTAcUA Message-ID: To: core Content-Type: text/plain; charset=UTF-8 Cc: Cullen Jennings Subject: [core] Feedback request on HTTP mapping document split X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 04 Apr 2012 15:37:46 -0000 Dear WG, as per the direction from the chairs at the Paris IETF, here you can find a public google doc containing our initial selection of document parts that we will keep in http-mapping-04 base draft: https://docs.google.com/document/d/1ynwBBT9Jrp-nlr7vT43qg__YevvVQaEZDIuiavLBdds/edit We highlighted: - in yellow the parts that are "good enough" in the current text, and that we will keep as they are - in orange the parts that need synthetic rewriting, and to be more focused in the document - in white the parts removed and that will be put in a core-advanced-http-mapping-00 draft The document is public, you can read, comment and edit it. Especially if you feel that some sentences need to be clarified, highlight them in orange. In particular "placement and deployment" section in HTTP-CoAP will became after rewriting a focused "reverse proxy" section. Major doubts are about the following sections, about them we made the most conservative choice: - multicast mapping --> advanced - observe mapping --> advanced - coap-http --> base If you feel that those choices need more thought, drop your opinion in this mail thread. We target having a phone conference with WG members interested in this topic, in about 2 weeks from now. Details will be dispatched to the people interested in this work (replying to this thread). Best, Angelo (on behalf of http-mapping co-authors) From abaire@irisa.fr Wed Apr 4 09:05:08 2012 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 8A12021F887D for ; Wed, 4 Apr 2012 09:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.248 X-Spam-Level: X-Spam-Status: No, score=-10.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1DGiI+4Lel0 for ; Wed, 4 Apr 2012 09:05:08 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by ietfa.amsl.com (Postfix) with ESMTP id AA49A21F87E1 for ; Wed, 4 Apr 2012 09:05:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,370,1330902000"; d="scan'208,217";a="152720298" Received: from halfoat.irisa.fr (HELO [131.254.16.11]) ([131.254.16.11]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 04 Apr 2012 18:05:06 +0200 Message-ID: <4F7C7177.6030807@irisa.fr> Date: Wed, 04 Apr 2012 18:06:15 +0200 From: Anthony Baire User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20120320 Icedove/3.0.11 MIME-Version: 1.0 To: core@ietf.org Content-Type: multipart/alternative; boundary="------------080101020805010003020505" Subject: [core] draft-ietf-core-block-08 - clarification on client UDP port number X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 04 Apr 2012 16:05:08 -0000 This is a multi-part message in MIME format. --------------080101020805010003020505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, at the interop in Paris, we noticed one client implementation using a different UDP source port for each request in a blockwise transfer. There is no mentions about UDP port numbers in draft-ietf-core-block-08. While the client port number does not matter most of the time, there are possible problems in case of atomic Block1 transfers. If two clients running on the same host are updating the same resource, then the server cannot distinguish for a certainty between the blocks of the two clients. I would suggest adding one paragraph to Section 2.2: In the blockwise tranfer of a request payload (e.g., a PUT or POST) that the server is processing atomically, the client MUST originate every request from the same UDP source port. The reassembler MUST compare the UDP source port of the request when reassembling the blocks of an atomic operation. If atomic processing is not desired, there is no need to process the UDP source port. Best Regards -- Anthony Baire IRISA / University of Rennes 1 --------------080101020805010003020505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

at the interop in Paris, we noticed one client implementation using a different UDP source port for each request in a blockwise transfer.

There is no mentions about UDP port numbers in draft-ietf-core-block-08.


While the client port number does not matter most of the time, there are possible problems in case of atomic Block1 transfers.

If two clients running on the same host are updating the same resource, then the server cannot distinguish for a certainty between the blocks of the two clients.

I would suggest adding one paragraph to Section 2.2:
In the blockwise tranfer of a request payload (e.g., a PUT or POST) that the server is processing atomically, the client MUST originate every request from the same UDP source port. The reassembler MUST compare the UDP source port of the request when reassembling the blocks of an atomic operation. If atomic processing is not desired, there is no need to process the UDP source port.

Best Regards

--
Anthony Baire
IRISA / University of Rennes 1
--------------080101020805010003020505-- From salvatore.loreto@ericsson.com Wed Apr 4 09:56:44 2012 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 395F021F8625 for ; Wed, 4 Apr 2012 09:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.482 X-Spam-Level: X-Spam-Status: No, score=-105.482 tagged_above=-999 required=5 tests=[AWL=-0.434, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnnJUYmc4qrm for ; Wed, 4 Apr 2012 09:56:43 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id D9AF821F863C for ; Wed, 4 Apr 2012 09:56:42 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-da-4f7c7d492563 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id C3.45.03534.94D7C7F4; Wed, 4 Apr 2012 18:56:42 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.213.0; Wed, 4 Apr 2012 18:56:41 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 5E3FD2326 for ; Wed, 4 Apr 2012 19:56:41 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 77D7852630 for ; Wed, 4 Apr 2012 19:56:41 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 03E3A52611 for ; Wed, 4 Apr 2012 19:56:40 +0300 (EEST) Message-ID: <4F7C7D48.1060007@ericsson.com> Date: Wed, 4 Apr 2012 18:56:40 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: core@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040908060106000504010906" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [core] Sleepy devices + observer model X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 04 Apr 2012 16:56:44 -0000 --------------040908060106000504010906 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit On 4/2/12 1:49 PM, Berta Carballido wrote: > > However, one of the advantages of battery powered sensors is their > freedom of placement! Imagine a vineyard where you want to monitor the > soil humidity, would it make sense to have a line powered proxy every > x meters, or would it make more sense to have a multihop topology of > sleeping devices? > > Thus my conclusions are: > > a)Server and observer models are appropriate for sleeping devices > > b)A proxy may be useful for some applications (for instance when the > sleeping device wants to remain always sleeping unless some event that > needs to be reported happens) > > c)Proxies make sense only for star-like/star backbone topologies > Hi Berta, while I agree with you that a proxy solution make sense only for some applications/scenarios I fully disagree that the Observer models, at least as it is specified at moment with all its limitations, is appropriate for sleeping devices. I like you precise analysis, however you have forgotten that in CoAP we are in a Restful architecture where the Name, Name authority and Name Integrity etc etc. is the core. So how would you respect the name integrity (of a resource) in your scenario (and especially in a multihop scenario where only adjacent nodes can talk each other) ? cheers Salvatore -- Salvatore Loreto, PhD www.sloreto.com --------------040908060106000504010906 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit On 4/2/12 1:49 PM, Berta Carballido wrote:

However, one of the advantages of battery powered sensors is their freedom of placement! Imagine a vineyard where you want to monitor the soil humidity, would it make sense to have a line powered proxy every x meters, or would it make more sense to have a multihop topology of sleeping devices?

Thus my conclusions are:

a) Server and observer models are appropriate for sleeping devices

b) A proxy may be useful for some applications (for instance when the sleeping device wants to remain always sleeping unless some event that needs to be reported happens)

c) Proxies make sense only for star-like/star backbone topologies


Hi Berta,

while I agree with you that a proxy solution make sense only for some applications/scenarios
I fully disagree that the Observer models, at least as it is specified at moment with all its limitations, is appropriate for sleeping devices.

I like you precise analysis, however you have forgotten that in CoAP we are in a Restful architecture
where the Name, Name authority and Name Integrity etc etc. is the core.

So how would you respect the name integrity (of a resource) in your scenario (and especially in a multihop scenario
where only adjacent nodes can talk each other) ?

cheers
Salvatore
-- 
Salvatore Loreto, PhD
www.sloreto.com
--------------040908060106000504010906-- From robert.cragie@gridmerge.com Wed Apr 4 10:38:49 2012 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 2EE1C11E8072 for ; Wed, 4 Apr 2012 10:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDoIR5NiY686 for ; Wed, 4 Apr 2012 10:38:48 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id CD5D621F8758 for ; Wed, 4 Apr 2012 10:38:47 -0700 (PDT) Received: from client-86-9-231-127.oxfd-bam-1.adsl.virginmedia.com ([86.9.231.127] helo=[192.168.0.2]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) id 1SFUAO-0005QN-9C for core@ietf.org; Wed, 04 Apr 2012 18:38:44 +0100 Message-ID: <4F7C8787.1080408@gridmerge.com> Date: Wed, 04 Apr 2012 18:40:23 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: core@ietf.org References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000500020602060107040104" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [core] Sleepy devices + observer model X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 17:38:49 -0000 This is a cryptographically signed message in MIME format. --------------ms000500020602060107040104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable +1 I am really not in favour of adding more message types to assist=20 esoteric transaction patterns. As Matthieu demonstrates, these can=20 easily be handled by alternative means. Robert On 04/04/2012 4:14 PM, matthieu.vial@non.schneider-electric.com wrote: > Angelo, > > see my comments > >> Of course at application layer you can get this done with some ad-hoc >> application pattern, but I think that for the sake of interperability >> this should be done in a standard way. > IMO it's easier to standardize a Function Set in a profile than a > low-level message type in an already full header field. > > >> Moreover in Carsten's example, you need 1 mid-sized by the sleepy node= >> and 1 tiny message from each interested listener, then 1 message for >> each interested listener (imagine problems when multicast is >> involved). > For me the number of messages is the same. > > C1 C2 C3 S > | | | . server is sleeping > | | | . > | | | . > | | | . > | | | . server wakes up > | | | . NON > |<--|<--|<----| POST coap://[ff02::1]/alive > | | | | > | | | | CON MID=3D0x1234 > |------------>| GET /a > | | | | > | | | | ACK MID=3D0x1234 > |<------------| 2.05 "A" > | | | . > | | | . server goes sleeping again > | | | . > | | | . > | | | . > > >> Using CoAP Alive, the ALV message is a very tiny one, and thanks to >> its special, standard semantics it is an useful and optimizated for >> the common case of a node that wakes up. > Does this working group really want to override the NON message type > semantics when we can do the same with a simple CoAP request? > I'm personally not in favor of adding new message types. > > >> You need only the ALV >> message, the "magic" that Carsten was thinking about in its slides is >> worked out by the alive message. :) > The magic is about reusing the token from the POST in the observe > relationship, thus avoiding the initial GET request to create the > subscription. > We just need a short explanatory text, nothing more. > In your draft, the example is still using an explicit observe subscript= ion > so no magic here. > > Best regards, > Matthieu > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --------------ms000500020602060107040104 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP3jCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi 5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcw FQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VS Rmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBa Fw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NY X2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqi QfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBT bJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YX WEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30i Y9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSd JnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1UdDwEB /wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8E UTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGll bnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUH MAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQw JQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQAD ggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjf y/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T 4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrU yTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lE uJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggYuMIIFFqAD AgECAhBcMVDbxC2oy5hyHl/adO9mMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEb MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMDkwMjAwMDAwMFoXDTE0MDkwMTIzNTk1 OVowggE3MQswCQYDVQQGEwJHQjEQMA4GA1UEERMHV0Y0IDRXQTEXMBUGA1UECBMOV2VzdCBZ b3Jrc2hpcmUxEjAQBgNVBAcTCVdha2VmaWVsZDEUMBIGA1UECRMLR3JhbmdlIE1vb3IxHzAd BgNVBAkTFjg5IEdyZWVuZmllbGQgQ3Jlc2NlbnQxFzAVBgNVBAoTDkdyaWRtZXJnZSBMdGQu MTQwMgYDVQQLEytJc3N1ZWQgdGhyb3VnaCBHcmlkbWVyZ2UgTHRkLiBFLVBLSSBNYW5hZ2Vy MR8wHQYDVQQLExZDb3Jwb3JhdGUgU2VjdXJlIEVtYWlsMRYwFAYDVQQDEw1Sb2JlcnQgQ3Jh Z2llMSowKAYJKoZIhvcNAQkBFhtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtxOGq8t5ZTVDVkmadv7ZRBLA5ApaiTcDUzCTn zYB2/BoBDIEWWI/InSRcmq3A0Ghm+T7dYmvRADllGv4nTHexdWlzFp2iM/Yc3PLWCyAO0gYb yW2hTi+ZfUDwFOU4hRP4+Dyn9tKu7FXS/PQJHyGjaGxHRmLm9T6tAo2ZuC59uRaGVCcwRiOS d6axwtB/DVhnP3S1rrt2g0O6MXLr5fojToemO52AxjHxt2w1LnFUUXC4EDV6o1Ctr7EvOEI5 5f088H/Mrryp02GueLdY9gb0SFK3gPOT7EjP2GPvCtRkhVcNM+xjyptRIFWnCbMjmUIc+DO6 sfU4rtbCCkNKyXmnAgMBAAGjggHVMIIB0TAfBgNVHSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBb vHnFezAdBgNVHQ4EFgQUEI5c0f6UObxT2DLdvdtG+vG8qCswDgYDVR0PAQH/BAQDAgWgMAwG A1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQMFMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEB BHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50 QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMCYGA1UdEQQfMB2BG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdl LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAPpv87QuQ9q+RHhmeirGDQB3szd24Obi7N+uVfh5y CrnoJx3B37dNrLPsTB6PfTChUyZMqQD80pFoJ3TBUz3yx4X+hmNco7ujVIfbuKBGcZJaMKhZ ex3AkZ9ltie9wgiGGzEmgI81t5JHsLQ8AUMqw/fGsnIwcyWMgmyhFtm79+dg3IVaH05d/t9g k4aYoMoCFJptQZ+Fju6a9T139hOqjTZDpjMLt3jM80bVrvkC4dIRyF/oZ0qrJwbfwjnL2OUN ph9eymhLc+VM0Ih5k41s5IxmB+2c0RUqr5JbK0WrIb/z53Cmb9rXYox7HknyIfBpQqP77Y7a sAU2MMOpel4RijGCBAwwggQIAgEBMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0Eg TGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9mMAkGBSsOAwIaBQCgggI4MBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQwNDE3NDAyM1owIwYJKoZI hvcNAQkEMRYEFL/dO1ipxdPEenQ8+f+hQhFgcJvuMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDCBuQYJKwYBBAGCNxAEMYGrMIGoMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD VQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9mMIG7BgsqhkiG 9w0BCRACCzGBq6CBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3 BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0BAQEFAASCAQBQ3utUQ5NmVQYGfIsuD3+o zkLgHDt9BWBQ6MUxs/0xTYOFtQqU5Fcq7Z9JhJTqX0X7ug84ckYoUH/6iJLwxIVOqCfpzqsc oeHKIeUFOI11+bTEQI3BcIxxuDetKovFOEt6gqgqNN4Bx565lgyKx6JmXRjULS71chD1/3pM 7nDd/EJ/U+5HrQ+2T8KGgXXZr4nm7HrKbgHE3iAv69cUnQzf7EJoNmED+SDQa2kvnpaCgoUk tCeuGNaiY2ovQjip9SqlP2diNTCbavIhXOVmffKosjMCVFpwRmIkMKCnHbz7f/yUdT6cjNl4 ZOtcM/QOHVQsSes4FoT3ZY3qTB7XiJSOAAAAAAAA --------------ms000500020602060107040104-- From zach@sensinode.com Wed Apr 4 12:00:28 2012 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 37F3321F8646 for ; Wed, 4 Apr 2012 12:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fjEzMf1VCwD for ; Wed, 4 Apr 2012 12:00:27 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFF321F8650 for ; Wed, 4 Apr 2012 12:00:25 -0700 (PDT) Received: from [192.168.1.101] (188-67-34-254.bb.dnainternet.fi [188.67.34.254]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q34J0G3q021910; Wed, 4 Apr 2012 22:00:16 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <4F7C8787.1080408@gridmerge.com> Date: Wed, 4 Apr 2012 22:00:15 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F7C8787.1080408@gridmerge.com> To: robert.cragie@gridmerge.com X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org Subject: Re: [core] Sleepy devices + observer model X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 04 Apr 2012 19:00:28 -0000 On Apr 4, 2012, at 8:40 PM, Robert Cragie wrote: > +1 >=20 > I am really not in favour of adding more message types to assist = esoteric transaction patterns. As Matthieu demonstrates, these can = easily be handled by alternative means. +1=20 I am also not convinced of a need for new CoAP level mechanisms for = sleepy (the non-reachable sort) end-points. There are surely many ways = we can leverage the notification capability that Observe provides, and = for extreme cases you can always use a client mode where there are many = possible models, the one Matthieu is proposing with a Mirror Server = being just one of them. We really need to explore the low-hanging fruit = before designing new mechanisms into CoAP which is a big step (and the = bar should be high). This whole sleepy node conversation is totally unfocused as well. It = seems like each person is talking about different requirements, goals = and architecture. I do agree that the case of a totally non-reachable = end-point (sleepy of for whatever other reason) would be useful to = solve, I think the people who are interested in this work need to get = together and: 1. Nail down the problem you are trying to solve, keep it simple to = start with 2. First explore how you can use Observe or a client mode and REST to = solve it=20 3. Get some practical experience with those solutions, iterate 4. If all else fails, then start talking about new options etc.=20 Please also keep in mind that we are operating at the application layer, = but enabling battery powered wireless nodes in real systems is a complex = system issue. As we already saw from this discussion there are issues at = almost every layer, from MAC timing, to routing and ND as well as the = system architecture and data flows. Whatever we do here needs to work in = a pretty wide range of such systems, but don't expect to solve the whole = problem in CoRE.=20 Zach >=20 > Robert >=20 > On 04/04/2012 4:14 PM, matthieu.vial@non.schneider-electric.com wrote: >> Angelo, >>=20 >> see my comments >>=20 >>> Of course at application layer you can get this done with some = ad-hoc >>> application pattern, but I think that for the sake of = interperability >>> this should be done in a standard way. >> IMO it's easier to standardize a Function Set in a profile than a >> low-level message type in an already full header field. >>=20 >>=20 >>> Moreover in Carsten's example, you need 1 mid-sized by the sleepy = node >>> and 1 tiny message from each interested listener, then 1 message for >>> each interested listener (imagine problems when multicast is >>> involved). >> For me the number of messages is the same. >>=20 >> C1 C2 C3 S >> | | | . server is sleeping >> | | | . >> | | | . >> | | | . >> | | | . server wakes up >> | | | . NON >> |<--|<--|<----| POST coap://[ff02::1]/alive >> | | | | >> | | | | CON MID=3D0x1234 >> |------------>| GET /a >> | | | | >> | | | | ACK MID=3D0x1234 >> |<------------| 2.05 "A" >> | | | . >> | | | . server goes sleeping again >> | | | . >> | | | . >> | | | . >>=20 >>=20 >>> Using CoAP Alive, the ALV message is a very tiny one, and thanks to >>> its special, standard semantics it is an useful and optimizated for >>> the common case of a node that wakes up. >> Does this working group really want to override the NON message type >> semantics when we can do the same with a simple CoAP request? >> I'm personally not in favor of adding new message types. >>=20 >>=20 >>> You need only the ALV >>> message, the "magic" that Carsten was thinking about in its slides = is >>> worked out by the alive message. :) >> The magic is about reusing the token from the POST in the observe >> relationship, thus avoiding the initial GET request to create the >> subscription. >> We just need a short explanatory text, nothing more. >> In your draft, the example is still using an explicit observe = subscription >> so no magic here. >>=20 >> Best regards, >> Matthieu >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >>=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From jara@um.es Wed Apr 4 12:12:22 2012 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 3F83421F8725 for ; Wed, 4 Apr 2012 12:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylYTLEIro9Xa for ; Wed, 4 Apr 2012 12:12:21 -0700 (PDT) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id E821A21F86AB for ; Wed, 4 Apr 2012 12:12:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 77B844BD3D for ; Wed, 4 Apr 2012 21:12:19 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id iYG1oPOl89nI for ; Wed, 4 Apr 2012 21:12:19 +0200 (CEST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jara) by xenon12.um.es (Postfix) with ESMTPSA id D06E84BD1C for ; Wed, 4 Apr 2012 21:12:17 +0200 (CEST) Received: by lagj5 with SMTP id j5so848123lag.31 for ; Wed, 04 Apr 2012 12:12:16 -0700 (PDT) Received: by 10.152.127.136 with SMTP id ng8mr20105202lab.16.1333566736943; Wed, 04 Apr 2012 12:12:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.45.170 with HTTP; Wed, 4 Apr 2012 12:11:36 -0700 (PDT) In-Reply-To: References: <4F7C8787.1080408@gridmerge.com> From: Antonio Jara Date: Wed, 4 Apr 2012 21:11:36 +0200 Message-ID: To: Zach Shelby Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core@ietf.org Subject: Re: [core] Sleepy devices + observer model X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 04 Apr 2012 19:12:22 -0000 Dear Zach, Berta, Salvatore, and all, +1 It is clear that a multi-hop architecture with multiple several sleeping nodes for this kind of active protocols require a high synchronization or some active router nodes in order to make this multi-hop more reachable. I prefer always to consider from the 6LoWPAN (network layer) and CoAP (application layer) point of view a star topology, where the coordinator is integrated in the Border Router and several end-node (which are able to sleep) are connected directly to this one. Such as aforementioned, it cannot be so restricted star, we could consider some multi-hop but the intermediary nodes should be router with no-sleep mode enabled or a duty cycle higher (i.e. a full one), or in a most common case, just assume that RPL is able to manage it in the link layer in order to make it transparent for us in the network layer. Anyway, regarding solutions, we are considering to include in the next draft of conditional observe "draft-li-core-conditional-observe-01" some additional attributes and types of conditions for the sleeping node, where it is considered the following options: 1- Indication in the replies of an attribute to inform about the "duty cycle" from a sleep nodes, in order to inform to the client about the maximum delay to discover changes, or rate for a periodic observer. 2- In the queries send to sensors connected to sleeping nodes, if can be considered the indication of a flag in order to allow cacheable values replies, i.e. a Live flag in order to distinguish between "live or cacheable value". Thereby, proxies or mirrors are able to know if they should reply with a cached value in a non-authority way or they should wait to the reception of a new reply (fresh value) from the sensor. 3- Finally, regarding to the maximum wait for this answer, it can be also considered in the replies from the proxy on.behalf of the end node in a non-authority way, also to indicate in this live flag as a freshness indicator, which is activate when the maximum TTL for the request in a "periodic observation" or with maximum time between replies has been expired. In definitive, we would like to get some feedback about the opinion of these new options for the sleeping node type for the next draft of the conditional observe. In summary, which options you consider more relevant: 1- be more explicit about the duty cycle in the replies for the registration/observation over a sleeping nodes- 2- be more explicit about the requirement of live values for periodic observations in the queries from the clients. 3- use this live flag in order to be managed for these mirrors / proxies, maybe too much processing for these mirrors? 4- Indicate with a freshness attribute that the reply is non-authoritative from a proxy/mirror in case that this detects that the maximum period between observations parameter has expired and not reply has been carried from the sleeping node due to its low duty cycle etc... Best regards and thanks, Antonio J. Jara On Wed, Apr 4, 2012 at 9:00 PM, Zach Shelby wrote: > > On Apr 4, 2012, at 8:40 PM, Robert Cragie wrote: > >> +1 >> >> I am really not in favour of adding more message types to assist esoteri= c transaction patterns. As Matthieu demonstrates, these can easily be handl= ed by alternative means. > > +1 > > I am also not convinced of a need for new CoAP level mechanisms for sleep= y (the non-reachable sort) end-points. There are surely many ways we can le= verage the notification capability that Observe provides, and for extreme c= ases you can always use a client mode where there are many possible models,= the one Matthieu is proposing with a Mirror Server being just one of them.= We really need to explore the low-hanging fruit before designing new mecha= nisms into CoAP which is a big step (and the bar should be high). > > This whole sleepy node conversation is totally unfocused as well. It seem= s like each person is talking about different requirements, goals and archi= tecture. I do agree that the case of a totally non-reachable end-point (sle= epy of for whatever other reason) would be useful to solve, I think the peo= ple who are interested in this work need to get together and: > > 1. Nail down the problem you are trying to solve, keep it simple to start= with > 2. First explore how you can use Observe or a client mode and REST to sol= ve it > 3. Get some practical experience with those solutions, iterate > 4. If all else fails, then start talking about new options etc. > > Please also keep in mind that we are operating at the application layer, = but enabling battery powered wireless nodes in real systems is a complex sy= stem issue. As we already saw from this discussion there are issues at almo= st every layer, from MAC timing, to routing and ND as well as the system ar= chitecture and data flows. Whatever we do here needs to work in a pretty wi= de range of such systems, but don't expect to solve the whole problem in Co= RE. > > Zach > > >> >> Robert >> >> On 04/04/2012 4:14 PM, matthieu.vial@non.schneider-electric.com wrote: >>> Angelo, >>> >>> see my comments >>> >>>> Of course at application layer you can get this done with some ad-hoc >>>> application pattern, but I think that for the sake of interperability >>>> this should be done in a standard way. >>> IMO it's easier to standardize a Function Set in a profile than a >>> low-level message type in an already full header field. >>> >>> >>>> Moreover in Carsten's example, you need 1 mid-sized by the sleepy node >>>> and 1 tiny message from each interested listener, then 1 message for >>>> each interested listener (imagine problems when multicast is >>>> involved). >>> For me the number of messages is the same. >>> >>> C1 =A0C2 =A0C3 =A0 =A0S >>> =A0 =A0| =A0 | =A0 | =A0 =A0 . server is sleeping >>> =A0 =A0| =A0 | =A0 | =A0 =A0 . >>> =A0 =A0| =A0 | =A0 | =A0 =A0 . >>> =A0 =A0| =A0 | =A0 | =A0 =A0 . >>> =A0 =A0| =A0 | =A0 | =A0 =A0 . server wakes up >>> =A0 =A0| =A0 | =A0 | =A0 =A0 . NON >>> =A0 =A0|<--|<--|<----| POST coap://[ff02::1]/alive >>> =A0 =A0| =A0 | =A0 | =A0 =A0 | >>> =A0 =A0| =A0 | =A0 | =A0 =A0 | CON MID=3D0x1234 >>> =A0 =A0|------------>| GET /a >>> =A0 =A0| =A0 | =A0 | =A0 =A0 | >>> =A0 =A0| =A0 | =A0 | =A0 =A0 | ACK MID=3D0x1234 >>> =A0 =A0|<------------| 2.05 "A" >>> =A0 =A0| =A0 | =A0 | =A0 =A0 . >>> =A0 =A0| =A0 | =A0 | =A0 =A0 . server goes sleeping again >>> =A0 =A0| =A0 | =A0 | =A0 =A0 . >>> =A0 =A0| =A0 | =A0 | =A0 =A0 . >>> =A0 =A0| =A0 | =A0 | =A0 =A0 . >>> >>> >>>> Using CoAP Alive, the ALV message is a very tiny one, and thanks to >>>> its special, standard semantics it is an useful and optimizated for >>>> the common case of a node that wakes up. >>> Does this working group really want to override the NON message type >>> semantics when we can do the same with a simple CoAP request? >>> I'm personally not in favor of adding new message types. >>> >>> >>>> You need only the ALV >>>> message, the "magic" that Carsten was thinking about in its slides is >>>> worked out by the alive message. :) >>> The magic is about reusing the token from the POST in the observe >>> relationship, thus avoiding the initial GET request to create the >>> subscription. >>> We just need a short explanatory text, nothing more. >>> In your draft, the example is still using an explicit observe subscript= ion >>> so no magic here. >>> >>> Best regards, >>> Matthieu >>> >>> _______________________________________________ >>> 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 > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://www.sensinode.com > http://zachshelby.org =A0- My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From trac+core@trac.tools.ietf.org Wed Apr 4 12:31:51 2012 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 7030D21F8551 for ; Wed, 4 Apr 2012 12:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSE2kQwa8oNg for ; Wed, 4 Apr 2012 12:31:50 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 9A90821F84A6 for ; Wed, 4 Apr 2012 12:31:49 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SFVvZ-0004BV-Eq; Wed, 04 Apr 2012 15:31:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-core-block@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Wed, 04 Apr 2012 19:31:32 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/206 Message-ID: <051.965a95dc46e1afb12f7d1a12aed61bdf@trac.tools.ietf.org> X-Trac-Ticket-ID: 206 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-block@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120404193150.9A90821F84A6@ietfa.amsl.com> Resent-Date: Wed, 4 Apr 2012 12:31:49 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #206: Clarify that atomic Block1 transfers match per token *and* endpoint X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.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: Wed, 04 Apr 2012 19:31:51 -0000 #206: Clarify that atomic Block1 transfers match per token *and* endpoint Anthony Blaire notes: at the interop in Paris, we noticed one client implementation using a different UDP source port for each request in a blockwise transfer. There is no mentions about UDP port numbers in draft-ietf-core- block-08. While the client port number does not matter most of the time, there are possible problems in case of atomic Block1 transfers. If two clients running on the same host are updating the same resource, then the server cannot distinguish for a certainty between the blocks of the two clients. I would suggest adding one paragraph to Section 2.2: In the blockwise tranfer of a request payload (e.g., a PUT or POST) that the server is processing atomically, the client MUST originate every request from the same UDP source port. The reassembler MUST compare the UDP source port of the request when reassembling the blocks of an atomic operation. If atomic processing is not desired, there is no need to process the UDP source port. Since the UDP port is not the only parameter that could vary (DTLS connection or IPv6 source address come to mind), the two paragraphs at the end of section 2.2 (page 12) probably should be rephrased to clarify that the combination of endpoint and token is what is used to perform the matching, with a reference to the matching rules in 5.3 in core-coap. -- -----------------------------+------------------------------------- Reporter: cabo@… | Owner: draft-ietf-core-block@… Type: editorial | Status: new Priority: major | Milestone: post-WGLC-1 Component: block | Version: Severity: In WG Last Call | Keywords: -----------------------------+------------------------------------- Ticket URL: core From cabo@tzi.org Wed Apr 4 12:32:21 2012 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 7F1ED11E80E5 for ; Wed, 4 Apr 2012 12:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXlxwY+r7zik for ; Wed, 4 Apr 2012 12:32:21 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id BD88511E80BE for ; Wed, 4 Apr 2012 12:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q34JWAFU007414; Wed, 4 Apr 2012 21:32:10 +0200 (CEST) Received: from [192.168.217.105] (p5489B67C.dip.t-dialin.net [84.137.182.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9A8CB34C; Wed, 4 Apr 2012 21:32:10 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <4F7C7177.6030807@irisa.fr> Date: Wed, 4 Apr 2012 21:32:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0AED2A21-CF12-46AC-BDB7-840C00A8DEDB@tzi.org> References: <4F7C7177.6030807@irisa.fr> To: Anthony Baire X-Mailer: Apple Mail (2.1257) Cc: core@ietf.org Subject: Re: [core] draft-ietf-core-block-08 - clarification on client UDP port number X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 04 Apr 2012 19:32:21 -0000 Now ticket #206. Gr=FC=DFe, Carsten From jeroen.hoebeke@intec.ugent.be Wed Apr 4 12:33:42 2012 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 8551911E80E2 for ; Wed, 4 Apr 2012 12:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QK9X0j2Eae54 for ; Wed, 4 Apr 2012 12:33:41 -0700 (PDT) Received: from smtp2.ugent.be (smtp2.ugent.be [157.193.49.126]) by ietfa.amsl.com (Postfix) with ESMTP id 989A111E80BE for ; Wed, 4 Apr 2012 12:33:41 -0700 (PDT) Received: from localhost (mcheck5.ugent.be [157.193.49.247]) by smtp2.ugent.be (Postfix) with ESMTP id 52B1C12C237; Wed, 4 Apr 2012 21:33:40 +0200 (CEST) X-Virus-Scanned: by UGent DICT Received: from smtp2.ugent.be ([157.193.49.126]) by localhost (mcheck5.UGent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id qCTVosgHtaBR; Wed, 4 Apr 2012 21:33:39 +0200 (CEST) Received: from [192.168.123.5] (78-21-4-198.access.telenet.be [78.21.4.198]) (Authenticated sender: jjhoebek) by smtp2.ugent.be (Postfix) with ESMTPSA id 9C95312C221; Wed, 4 Apr 2012 21:33:39 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_52E1E166-1B1B-4419-8172-81407663B732" From: Jeroen Hoebeke In-Reply-To: Date: Wed, 4 Apr 2012 21:33:38 +0200 Message-Id: <8F576996-9FB9-47C6-9C2B-86489EEADD0A@intec.ugent.be> References: To: Angelo P. Castellani X-Mailer: Apple Mail (2.1257) X-Miltered: at mcheck3 with ID 4F7CA213.000 by Joe's j-chkmail (http://helpdesk.ugent.be/email/)! X-j-chkmail-Enveloppe: 4F7CA213.000/78.21.4.198/78-21-4-198.access.telenet.be/[192.168.123.5]/ X-j-chkmail-Score: MSGID : 4F7CA213.000 on smtp2.ugent.be : j-chkmail score : . : R=. U=. O=# B=0.000 -> S=0.083 X-j-chkmail-Status: Ham Cc: core WG Subject: Re: [core] comments on draft-li-core-conditional-observe-01 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 04 Apr 2012 19:33:42 -0000 --Apple-Mail=_52E1E166-1B1B-4419-8172-81407663B732 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Angelo, Thank you for your feedback, we will take it into account. We will = continue to further explore this concept, tackle open issues and gain = some experience with it (based on an implementation we are working on).=20= Kind regards, Jeroen On 30 Mar 2012, at 10:09, Angelo P. Castellani wrote: > I think that the concept of conditional observe is interesting, and I = personally like to see that this work being explored here. >=20 > I had a look at the document, and I have two technical comments. >=20 > 1) The following formats seem to be wrong: >=20 > 0 > 0 1 2 3 4 5 6 7 8 9 > +-+-+-+-+-+-+-+-+-+-+ > | TYPE | M | VAL | > +-+-+-+-+-+-+-+-+-+-+ >=20 > 0 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | TYPE | M | VAL | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > 0 1 2 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | TYPE | M | VAL | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > The first one is 1 byte + 2 bits, the second one 2 bytes + 2 bits, and = the third one is 3 bytes + 2 bits. >=20 > You should probably reduce the VAL field by 2 bits in each case. >=20 > 2) You should include the Condition option in the notification as well = (at least in the first), to make the client aware of the fact that you = accepted a Condition (for each condition you accepted). >=20 > Best, > Angelo > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --Apple-Mail=_52E1E166-1B1B-4419-8172-81407663B732 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Angelo,

Thank you for your feedback, we will take it = into account. We will continue to further explore this concept, tackle = open issues and gain some experience with it (based on an implementation = we are working on). 

Kind = regards,
Jeroen

On 30 Mar 2012, at = 10:09, Angelo P. Castellani wrote:

I think = that the concept of conditional observe is interesting, and I personally = like to see that this work being explored here.

I had a look at = the document, and I have two technical comments.

1) The following = formats seem to be wrong:

              0
              0 1 2 3 4 5 6 7 8 9
             +-+-+-+-+-+-+-+-+-+-+
             | TYPE  | M | VAL   |
             +-+-+-+-+-+-+-+-+-+-+

              0                   1
              0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             | TYPE  | M |          VAL          |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              0                   1                   2
              0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             | TYPE  | M |          VAL                          |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The first one is 1 byte + 2 bits, the second = one 2 bytes + 2 bits, and the third one is 3 bytes + 2 = bits.

You should probably reduce the VAL field = by 2 bits in each case.

2) You should include the Condition option in the = notification as well (at least in the first), to make the client aware = of the fact that you accepted a Condition (for each condition you = accepted).

Best,
Angelo
_______________________________________________
core mailing = list
core@ietf.org
https://www.ietf.org/ma= ilman/listinfo/core


= --Apple-Mail=_52E1E166-1B1B-4419-8172-81407663B732-- From trac+core@trac.tools.ietf.org Wed Apr 4 12:44:34 2012 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 1E45B21F8611 for ; Wed, 4 Apr 2012 12:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1nY3E0wBozk for ; Wed, 4 Apr 2012 12:44:33 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 9546121F8610 for ; Wed, 4 Apr 2012 12:44:33 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SFW7v-0006w0-A0; Wed, 04 Apr 2012 15:44:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-core-observe@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Wed, 04 Apr 2012 19:44:19 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/204#comment:1 Message-ID: <066.a52a01c1dc069cc2b1d31a7a8dc96d68@trac.tools.ietf.org> References: <051.7d477dcf63d5a27be6104f253d5fe611@trac.tools.ietf.org> X-Trac-Ticket-ID: 204 In-Reply-To: <051.7d477dcf63d5a27be6104f253d5fe611@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-observe@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120404194433.9546121F8610@ietfa.amsl.com> Resent-Date: Wed, 4 Apr 2012 12:44:33 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #204: Introduce a minimal version of Pledge X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.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: Wed, 04 Apr 2012 19:44:34 -0000 #204: Introduce a minimal version of Pledge Comment (by cabo@…): When we briefly discussed this again during the Friday meeting, the sense of the room went towards: -- the basic mechanism (i.e., in the draft now) works for some, not all, applications -- any potential extensions should be done in a separate draft (The sense of the room is not a final WG decision of course, but a good indication of direction.) If we stay with this direction, we should review the text to make sure: -- it is clear about the way this works with non-cacheable resources -- the way max-age is used now can be made into a default behavior for the potential future options we have started to discuss -- ----------------------------------+---------------------------------------- Reporter: cabo@… | Owner: draft-ietf-core-observe@… Type: protocol enhancement | Status: new Priority: major | Milestone: Component: observe | Version: Severity: In WG Last Call | Resolution: Keywords: | ----------------------------------+---------------------------------------- Ticket URL: core From salvatore.loreto@ericsson.com Wed Apr 4 13:15:42 2012 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 D41AC11E80FA for ; Wed, 4 Apr 2012 13:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.974 X-Spam-Level: X-Spam-Status: No, score=-105.974 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZ+9nHwrlMre for ; Wed, 4 Apr 2012 13:15:42 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id E975911E8099 for ; Wed, 4 Apr 2012 13:15:41 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-65-4f7cabecfd36 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 9E.04.25560.CEBAC7F4; Wed, 4 Apr 2012 22:15:40 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.213.0; Wed, 4 Apr 2012 22:15:39 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 4FB5F2326; Wed, 4 Apr 2012 23:15:39 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 486B152630; Wed, 4 Apr 2012 23:15:39 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id B209A52611; Wed, 4 Apr 2012 23:15:38 +0300 (EEST) Message-ID: <4F7CABE9.1060904@ericsson.com> Date: Wed, 4 Apr 2012 22:15:37 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: core@ietf.org References: <051.7d477dcf63d5a27be6104f253d5fe611@trac.tools.ietf.org> <066.a52a01c1dc069cc2b1d31a7a8dc96d68@trac.tools.ietf.org> In-Reply-To: <066.a52a01c1dc069cc2b1d31a7a8dc96d68@trac.tools.ietf.org> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Cc: Cullen Jennings Subject: Re: [core] #204: Introduce a minimal version of Pledge X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 04 Apr 2012 20:15:43 -0000 On 4/4/12 9:44 PM, core issue tracker wrote: > #204: Introduce a minimal version of Pledge > > > Comment (by cabo@…): > > When we briefly discussed this again during the Friday meeting, the sense > of the room went towards: > > -- the basic mechanism (i.e., in the draft now) works for some, not all, > applications > -- any potential extensions should be done in a separate draft > > (The sense of the room is not a final WG decision of course, but a good > indication of direction.) the chairs have started a WG last call for the Observer draft try to insert extensions (or make any significant technical changes) in a document in last call is a *bad* thing at least IMO as any technical change requires some time to be discussed, understood etc. etc. > If we stay with this direction, we should review the text to make sure: are you talking of text in Observer draft (that is in WG Last Call =-O ) or in some other draft? > -- it is clear about the way this works with non-cacheable resources > -- the way max-age is used now can be made into a default behavior for the > potential future options we have started to discuss > From cabo@tzi.org Wed Apr 4 13:35:59 2012 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 0785711E810B for ; Wed, 4 Apr 2012 13:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8h9C4uurhMxP for ; Wed, 4 Apr 2012 13:35:58 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF2811E8099 for ; Wed, 4 Apr 2012 13:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q34KZkKA001154; Wed, 4 Apr 2012 22:35:46 +0200 (CEST) Received: from [192.168.217.105] (p5489B67C.dip.t-dialin.net [84.137.182.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6C59136D; Wed, 4 Apr 2012 22:35:46 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <4F7CABE9.1060904@ericsson.com> Date: Wed, 4 Apr 2012 22:35:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <14CC11D8-097C-4F38-8BD0-D7607129AD4E@tzi.org> References: <051.7d477dcf63d5a27be6104f253d5fe611@trac.tools.ietf.org> <066.a52a01c1dc069cc2b1d31a7a8dc96d68@trac.tools.ietf.org> <4F7CABE9.1060904@ericsson.com> To: Salvatore Loreto X-Mailer: Apple Mail (2.1257) Cc: Cullen Jennings , core@ietf.org Subject: Re: [core] #204: Introduce a minimal version of Pledge X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 04 Apr 2012 20:35:59 -0000 On Apr 4, 2012, at 22:15, Salvatore Loreto wrote: > try to insert extensions (or make any significant technical changes) = in a document > in last call is a *bad* thing at least IMO Yes, I think in this case that was also the sense of the room, and I = tried to document this direction in the ticket comment. Any such extension would come later, on top of what we agree to do as = the base mechanism now. Sorry if I didn't make myself clear enough. > as any technical change requires some time to be discussed, understood = etc. etc. Right. So we decided*) to keep -observe as is, but make sure we can extend it = later. *) ...with the usual qualifications on how things are decided in the = IETF. >> If we stay with this direction, we should review the text to make = sure: >=20 > are you talking of text in Observer draft (that is in WG Last Call =3D-O= )=20 Yes. I wanted to make sure we capture in the ticket the specific need for = looking at these two points. Apologies if my summary was too brief. Gr=FC=DFe, Carsten From salvatore.loreto@ericsson.com Wed Apr 4 13:46:04 2012 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 DB96121F86A8 for ; Wed, 4 Apr 2012 13:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.029 X-Spam-Level: X-Spam-Status: No, score=-106.029 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7I-OjYPYTH3z for ; Wed, 4 Apr 2012 13:46:04 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1B57921F86A6 for ; Wed, 4 Apr 2012 13:46:03 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-a3-4f7cb30aa592 Authentication-Results: mailgw1.ericsson.se x-tls.subject="/CN=esessmw0197"; auth=fail (cipher=AES128-SHA) Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0197", Issuer "esessmw0197" (not verified)) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 34.46.25560.A03BC7F4; Wed, 4 Apr 2012 22:46:03 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.213.0; Wed, 4 Apr 2012 22:46:02 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 48CB22326; Wed, 4 Apr 2012 23:46:02 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 649AA52630; Wed, 4 Apr 2012 23:46:02 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id B2B8C52611; Wed, 4 Apr 2012 23:46:01 +0300 (EEST) Message-ID: <4F7CB308.20706@ericsson.com> Date: Wed, 4 Apr 2012 22:46:00 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Carsten Bormann References: <051.7d477dcf63d5a27be6104f253d5fe611@trac.tools.ietf.org> <066.a52a01c1dc069cc2b1d31a7a8dc96d68@trac.tools.ietf.org> <4F7CABE9.1060904@ericsson.com> <14CC11D8-097C-4F38-8BD0-D7607129AD4E@tzi.org> In-Reply-To: <14CC11D8-097C-4F38-8BD0-D7607129AD4E@tzi.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Cc: Cullen Jennings , "core@ietf.org" Subject: Re: [core] #204: Introduce a minimal version of Pledge X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 04 Apr 2012 20:46:05 -0000 On 4/4/12 10:35 PM, Carsten Bormann wrote: > On Apr 4, 2012, at 22:15, Salvatore Loreto wrote: > >> try to insert extensions (or make any significant technical changes) in a document >> in last call is a *bad* thing at least IMO > Yes, I think in this case that was also the sense of the room, and I tried to document this direction in the ticket comment. > Any such extension would come later, on top of what we agree to do as the base mechanism now. > Sorry if I didn't make myself clear enough. > >> as any technical change requires some time to be discussed, understood etc. etc. > Right. > So we decided*) to keep -observe as is, but make sure we can extend it later. > *) ...with the usual qualifications on how things are decided in the IETF. that is "rough consensus and running code" as the IETF83 t-shirt reminds us > >>> If we stay with this direction, we should review the text to make sure: >> are you talking of text in Observer draft (that is in WG Last Call =-O ) > Yes. > I wanted to make sure we capture in the ticket the specific need for looking at these two points. > Apologies if my summary was too brief. this two points are quite important if not crucial as they (can) change somehow the mechanism ! are you thinking to include them in the draft version following up the WGLC ? /Sal From cabo@tzi.org Wed Apr 4 14:23:42 2012 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 B75F321F85F4 for ; Wed, 4 Apr 2012 14:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ws2lPm8pnPAz for ; Wed, 4 Apr 2012 14:23:42 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 0071721F85F2 for ; Wed, 4 Apr 2012 14:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q34LNVMI019713; Wed, 4 Apr 2012 23:23:31 +0200 (CEST) Received: from [192.168.217.105] (p5489B67C.dip.t-dialin.net [84.137.182.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 1D3F037B; Wed, 4 Apr 2012 23:23:31 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <4F7CB308.20706@ericsson.com> Date: Wed, 4 Apr 2012 23:23:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <051.7d477dcf63d5a27be6104f253d5fe611@trac.tools.ietf.org> <066.a52a01c1dc069cc2b1d31a7a8dc96d68@trac.tools.ietf.org> <4F7CABE9.1060904@ericsson.com> <14CC11D8-097C-4F38-8BD0-D7607129AD4E@tzi.org> <4F7CB308.20706@ericsson.com> To: Salvatore Loreto X-Mailer: Apple Mail (2.1257) Cc: Cullen Jennings , "core@ietf.org" Subject: Re: [core] #204: Introduce a minimal version of Pledge X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 04 Apr 2012 21:23:42 -0000 On Apr 4, 2012, at 22:46, Salvatore Loreto wrote: > are you thinking to include them in the draft version following up the = WGLC ? I haven't done the review yet, so I don't know whether this will result = in changes, editorial or even technical. I just wanted to capture the points in the ticket, because they came up = in the meeting and I wasn't sure they were discussed yet. Gr=FC=DFe, Carsten From jeroen.hoebeke@intec.ugent.be Thu Apr 5 01:01:02 2012 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 6266C21F860E for ; Thu, 5 Apr 2012 01:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mi6X2kVg0CzR for ; Thu, 5 Apr 2012 01:01:01 -0700 (PDT) Received: from smtp2.ugent.be (smtp2.ugent.be [157.193.49.126]) by ietfa.amsl.com (Postfix) with ESMTP id 974F721F8609 for ; Thu, 5 Apr 2012 01:01:01 -0700 (PDT) Received: from localhost (mcheck5.ugent.be [157.193.49.247]) by smtp2.ugent.be (Postfix) with ESMTP id 98D7912C39B; Thu, 5 Apr 2012 10:01:00 +0200 (CEST) X-Virus-Scanned: by UGent DICT Received: from smtp2.ugent.be ([157.193.49.126]) by localhost (mcheck5.UGent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id WVlDK1THbRoK; Thu, 5 Apr 2012 10:01:00 +0200 (CEST) Received: from koeck.intec.ugent.be (koeck.intec.ugent.be [157.193.214.150]) (Authenticated sender: jjhoebek) by smtp2.ugent.be (Postfix) with ESMTPSA id 3FAF512C394; Thu, 5 Apr 2012 10:01:00 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Jeroen Hoebeke In-Reply-To: <4F7CABE9.1060904@ericsson.com> Date: Thu, 5 Apr 2012 10:00:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7CF8D1E5-366B-48E1-869D-21E04031633A@intec.ugent.be> References: <051.7d477dcf63d5a27be6104f253d5fe611@trac.tools.ietf.org> <066.a52a01c1dc069cc2b1d31a7a8dc96d68@trac.tools.ietf.org> <4F7CABE9.1060904@ericsson.com> To: Salvatore Loreto X-Mailer: Apple Mail (2.1257) X-Miltered: at mcheck5 with ID 4F7D513C.007 by Joe's j-chkmail (http://helpdesk.ugent.be/email/)! X-j-chkmail-Enveloppe: 4F7D513C.007 from koeck.intec.ugent.be/koeck.intec.ugent.be/157.193.214.150/koeck.intec.ugent.be/ X-j-chkmail-Score: MSGID : 4F7D513C.007 on smtp2.ugent.be : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Cc: Cullen Jennings , core@ietf.org Subject: Re: [core] #204: Introduce a minimal version of Pledge X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 05 Apr 2012 08:01:02 -0000 Hi Salvatore, >=20 > the chairs have started a WG last call for the Observer draft > try to insert extensions (or make any significant technical changes) = in a document > in last call is a *bad* thing at least IMO I understand your concern. Extensions can be avoided and can go in a = separate draft. Only thing is that IMHO the draft needs to be clear = about the meaning of sentences like "It will send a notification whenever the resource changes, or at latest when the age of the last notification becomes greater than its Max-Age" in case max-age =3D 0. This would imply that a non-cacheable resource = should send notifications at maximum frequency, i.e. every second? This = is now the case in our implementation, but seems to us as undesired = behavior in a constrained network. Not clarifying these points would not be good for the final document. I = hope ticket 204 can deal with this. Kind regards, Jeroen From angelo.castellani@gmail.com Thu Apr 5 01:15:52 2012 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 4DF5421F87EE for ; Thu, 5 Apr 2012 01:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0m-A1oNzGkL8 for ; Thu, 5 Apr 2012 01:15:51 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 5068F21F87ED for ; Thu, 5 Apr 2012 01:15:51 -0700 (PDT) Received: by wibhr17 with SMTP id hr17so1159236wib.1 for ; Thu, 05 Apr 2012 01:15:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=cng4N3wPEr5fNM45U/pjXLW6olggAWYGoj13hIuO6+Y=; b=jvdDoeUKAbRJ5vmKPgpDCTdXR1g7kf04BHl+G0GrDTB9M93HU5nHbG3F6dn0nKKcLI 8AW3+e0OufSgivNHmotwFcGuqdGgjr8Yw/NMuZ4gtIAOltet6I0F+X9tIhbEG69Nf0jK Vs9ORGpA/7wMhbjPtxtID+U8lg+tshB+FzeLsZ7tbNfBhuMTbAUfs+gd3xUuHKw3IRAM cTKMxEUkctd3n9lLwDoY0lCl/BxdCVcycm3iZfqaHL+e3PsiCtz8sVdkQua8tD1fpRUz Izsnwaulse8EAuun9DuA78fsNVJW7hyjtmEoPevL5ZmIqHja2lHKSPPOmFqZgFDYYBzI Ogfg== Received: by 10.180.83.198 with SMTP id s6mr2493946wiy.8.1333613750297; Thu, 05 Apr 2012 01:15:50 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.214.20 with HTTP; Thu, 5 Apr 2012 01:15:10 -0700 (PDT) In-Reply-To: <7CF8D1E5-366B-48E1-869D-21E04031633A@intec.ugent.be> References: <051.7d477dcf63d5a27be6104f253d5fe611@trac.tools.ietf.org> <066.a52a01c1dc069cc2b1d31a7a8dc96d68@trac.tools.ietf.org> <4F7CABE9.1060904@ericsson.com> <7CF8D1E5-366B-48E1-869D-21E04031633A@intec.ugent.be> From: "Angelo P. Castellani" Date: Thu, 5 Apr 2012 10:15:10 +0200 X-Google-Sender-Auth: K2XHxU71_c4uLF2M--TZ4xQIEnk Message-ID: To: Jeroen Hoebeke Content-Type: text/plain; charset=UTF-8 Cc: Cullen Jennings , core@ietf.org Subject: Re: [core] #204: Introduce a minimal version of Pledge X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 05 Apr 2012 08:15:53 -0000 On Thu, Apr 5, 2012 at 10:00, Jeroen Hoebeke wrote: > in case max-age = 0. This would imply that a non-cacheable resource should send notifications at maximum frequency, i.e. every second? This is now the case in our implementation, but seems to us as undesired behavior in a constrained network. This problem is more related to the rate control of the observation itself. I like your draft conditional that provides a way to both avoid too frequent updates, and also because it provides an upper bound to notifications. I think that those two features are really important, and maybe a variation of that features should be included in the Observe itself. A solution to this could be to use the observe option in the observation request to store two pseudo-FP containing minimum and maximum time between observations. The former helps avoiding too frequent updates, the latter to deal with servers losing their state, so that the client is guaranteed that at some time it will receive a notification anyway and react consequently if this does not happen. Best, Angelo From peter.van.der.stok@philips.com Thu Apr 5 03:05:27 2012 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 6806F21F871C for ; Thu, 5 Apr 2012 03:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.988 X-Spam-Level: X-Spam-Status: No, score=-3.988 tagged_above=-999 required=5 tests=[AWL=-0.989, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCsHlEf-cJOa for ; Thu, 5 Apr 2012 03:05:26 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCF321F871D for ; Thu, 5 Apr 2012 03:05:25 -0700 (PDT) Received: from mail89-am1-R.bigfish.com (10.3.201.233) by AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id 14.1.225.23; Thu, 5 Apr 2012 10:05:24 +0000 Received: from mail89-am1 (localhost [127.0.0.1]) by mail89-am1-R.bigfish.com (Postfix) with ESMTP id 67E36C02E1; Thu, 5 Apr 2012 10:05:24 +0000 (UTC) X-SpamScore: -59 X-BigFish: VPS-59(zzbb2dI217bL15d6O9371I9251J146fK542M1432N1418M98dK1506Jzz1202hzz8275ch1033IL8275bh8275dhz2dh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI Received: from mail89-am1 (localhost.localdomain [127.0.0.1]) by mail89-am1 (MessageSwitch) id 1333620322597769_31182; Thu, 5 Apr 2012 10:05:22 +0000 (UTC) Received: from AM1EHSMHS003.bigfish.com (unknown [10.3.201.238]) by mail89-am1.bigfish.com (Postfix) with ESMTP id 8D884340230; Thu, 5 Apr 2012 10:05:22 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by AM1EHSMHS003.bigfish.com (10.3.207.103) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 5 Apr 2012 10:05:19 +0000 Received: from 011-DB3MMR1-015.MGDPHG.emi.philips.com (10.128.28.99) by 011-DB3MMR1-004.MGDPHG.emi.philips.com (10.128.28.54) with Microsoft SMTP Server (TLS) id 14.1.355.3; Thu, 5 Apr 2012 11:05:18 +0100 Received: from 011-DB3MPN1-061.MGDPHG.emi.philips.com ([169.254.1.48]) by 011-DB3MMR1-015.MGDPHG.emi.philips.com ([10.128.28.99]) with mapi id 14.01.0355.003; Thu, 5 Apr 2012 11:05:07 +0100 From: "Stok, Peter van der" To: Antonio Jara , Zach Shelby Thread-Topic: [core] Sleepy devices + observer model Thread-Index: Ac0QxE7rpzs4fY/bToSRYwjf9ZElpgAAkpqgAFjsawAAAki5AAAAh3SAAA3v74AABRV3gAACyhGAAABlegAAIL/CMA== Date: Thu, 5 Apr 2012 10:07:36 +0000 Message-ID: References: <4F7C8787.1080408@gridmerge.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [82.95.140.48] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "core@ietf.org" Subject: Re: [core] Sleepy devices + observer model X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 05 Apr 2012 10:05:27 -0000 Dear working group, I am in favor of the star topology as suggested below. Although I like the vineyard example, I know of my friends in the potato fi= elds that they use 868MHz with a much larger range than 2.4 GHz. They also use star topology without using IP. The multi-hop protocol may well be a completely different protocol from the= protocols and use cases that most people think of in connection to sleep(y= )(ing) nodes. The multi-hop may need clock synchronization and a completely different inf= rastructure than we consider here. Concerning the options. I think the suggestions are valid, but I prefer not to include them in the = protocol. Another approach is to use resources with predefined names informing the cl= ient after discovery of the protocol attributes. Using resources makes the protocol less sensitive to additional wishes in t= he future. During initialization an entry can be stored in "for example" the managing = star where all resource values are available for use by destinations (obser= vers of the sleeping node). Greetings, Peter van der Stok -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Ant= onio Jara Sent: Wednesday 4 April 2012 21:12 To: Zach Shelby Cc: core@ietf.org Subject: Re: [core] Sleepy devices + observer model Dear Zach, Berta, Salvatore, and all, +1 It is clear that a multi-hop architecture with multiple several sleeping nodes for this kind of active protocols require a high synchronization or some active router nodes in order to make this multi-hop more reachable. I prefer always to consider from the 6LoWPAN (network layer) and CoAP (application layer) point of view a star topology, where the coordinator is integrated in the Border Router and several end-node (which are able to sleep) are connected directly to this one. Such as aforementioned, it cannot be so restricted star, we could consider some multi-hop but the intermediary nodes should be router with no-sleep mode enabled or a duty cycle higher (i.e. a full one), or in a most common case, just assume that RPL is able to manage it in the link layer in order to make it transparent for us in the network layer. Anyway, regarding solutions, we are considering to include in the next draft of conditional observe "draft-li-core-conditional-observe-01" some additional attributes and types of conditions for the sleeping node, where it is considered the following options: 1- Indication in the replies of an attribute to inform about the "duty cycle" from a sleep nodes, in order to inform to the client about the maximum delay to discover changes, or rate for a periodic observer. 2- In the queries send to sensors connected to sleeping nodes, if can be considered the indication of a flag in order to allow cacheable values replies, i.e. a Live flag in order to distinguish between "live or cacheable value". Thereby, proxies or mirrors are able to know if they should reply with a cached value in a non-authority way or they should wait to the reception of a new reply (fresh value) from the sensor. 3- Finally, regarding to the maximum wait for this answer, it can be also considered in the replies from the proxy on.behalf of the end node in a non-authority way, also to indicate in this live flag as a freshness indicator, which is activate when the maximum TTL for the request in a "periodic observation" or with maximum time between replies has been expired. In definitive, we would like to get some feedback about the opinion of these new options for the sleeping node type for the next draft of the conditional observe. In summary, which options you consider more relevant: 1- be more explicit about the duty cycle in the replies for the registration/observation over a sleeping nodes- 2- be more explicit about the requirement of live values for periodic observations in the queries from the clients. 3- use this live flag in order to be managed for these mirrors / proxies, maybe too much processing for these mirrors? 4- Indicate with a freshness attribute that the reply is non-authoritative from a proxy/mirror in case that this detects that the maximum period between observations parameter has expired and not reply has been carried from the sleeping node due to its low duty cycle etc... Best regards and thanks, Antonio J. Jara On Wed, Apr 4, 2012 at 9:00 PM, Zach Shelby wrote: > > On Apr 4, 2012, at 8:40 PM, Robert Cragie wrote: > >> +1 >> >> I am really not in favour of adding more message types to assist esoteri= c transaction patterns. As Matthieu demonstrates, these can easily be handl= ed by alternative means. > > +1 > > I am also not convinced of a need for new CoAP level mechanisms for sleep= y (the non-reachable sort) end-points. There are surely many ways we can le= verage the notification capability that Observe provides, and for extreme c= ases you can always use a client mode where there are many possible models,= the one Matthieu is proposing with a Mirror Server being just one of them.= We really need to explore the low-hanging fruit before designing new mecha= nisms into CoAP which is a big step (and the bar should be high). > > This whole sleepy node conversation is totally unfocused as well. It seem= s like each person is talking about different requirements, goals and archi= tecture. I do agree that the case of a totally non-reachable end-point (sle= epy of for whatever other reason) would be useful to solve, I think the peo= ple who are interested in this work need to get together and: > > 1. Nail down the problem you are trying to solve, keep it simple to start= with > 2. First explore how you can use Observe or a client mode and REST to sol= ve it > 3. Get some practical experience with those solutions, iterate > 4. If all else fails, then start talking about new options etc. > > Please also keep in mind that we are operating at the application layer, = but enabling battery powered wireless nodes in real systems is a complex sy= stem issue. As we already saw from this discussion there are issues at almo= st every layer, from MAC timing, to routing and ND as well as the system ar= chitecture and data flows. Whatever we do here needs to work in a pretty wi= de range of such systems, but don't expect to solve the whole problem in Co= RE. > > Zach > > >> >> Robert >> >> On 04/04/2012 4:14 PM, matthieu.vial@non.schneider-electric.com wrote: >>> Angelo, >>> >>> see my comments >>> >>>> Of course at application layer you can get this done with some ad-hoc >>>> application pattern, but I think that for the sake of interperability >>>> this should be done in a standard way. >>> IMO it's easier to standardize a Function Set in a profile than a >>> low-level message type in an already full header field. >>> >>> >>>> Moreover in Carsten's example, you need 1 mid-sized by the sleepy node >>>> and 1 tiny message from each interested listener, then 1 message for >>>> each interested listener (imagine problems when multicast is >>>> involved). >>> For me the number of messages is the same. >>> >>> C1 C2 C3 S >>> | | | . server is sleeping >>> | | | . >>> | | | . >>> | | | . >>> | | | . server wakes up >>> | | | . NON >>> |<--|<--|<----| POST coap://[ff02::1]/alive >>> | | | | >>> | | | | CON MID=3D0x1234 >>> |------------>| GET /a >>> | | | | >>> | | | | ACK MID=3D0x1234 >>> |<------------| 2.05 "A" >>> | | | . >>> | | | . server goes sleeping again >>> | | | . >>> | | | . >>> | | | . >>> >>> >>>> Using CoAP Alive, the ALV message is a very tiny one, and thanks to >>>> its special, standard semantics it is an useful and optimizated for >>>> the common case of a node that wakes up. >>> Does this working group really want to override the NON message type >>> semantics when we can do the same with a simple CoAP request? >>> I'm personally not in favor of adding new message types. >>> >>> >>>> You need only the ALV >>>> message, the "magic" that Carsten was thinking about in its slides is >>>> worked out by the alive message. :) >>> The magic is about reusing the token from the POST in the observe >>> relationship, thus avoiding the initial GET request to create the >>> subscription. >>> We just need a short explanatory text, nothing more. >>> In your draft, the example is still using an explicit observe subscript= ion >>> so no magic here. >>> >>> Best regards, >>> Matthieu >>> >>> _______________________________________________ >>> 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 > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://www.sensinode.com > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 > > _______________________________________________ > 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 ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From alper.yegin@yegin.org Thu Apr 5 04:58:23 2012 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 A6B8821F871B for ; Thu, 5 Apr 2012 04:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vr18ydLyg89T for ; Thu, 5 Apr 2012 04:58:22 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 457B921F86F3 for ; Thu, 5 Apr 2012 04:58:22 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LevDD-1SYeHM17B1-00q0tf; Thu, 05 Apr 2012 07:58:21 -0400 From: Alper Yegin Content-Type: multipart/alternative; boundary="Apple-Mail=_818580A4-DF89-40F4-B368-D1105BCFC2BC" Date: Thu, 5 Apr 2012 14:58:05 +0300 Message-Id: <2EE78B1C-6680-4ED2-974D-6B6550086FF1@yegin.org> To: "core@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-Provags-ID: V02:K0:eN8VXrLSoZNepqEvFwXzCQJIJKFFEWk92yu+EyYusDk KPwPvVD0W3hZGGfwZp2jFg0CkGqEhWCO615voW/WVSPtdvOmUB L7XNbm1g/zngobGCJEsQbkItP4rDJoQkLLR0ZtP9Of2qHE5wS3 scYOX+B5Q/ccBQX7C1gqrAlMncny8fGvOkgYD3R0wgJU/MsC6h MukshEjBYqDuAUR7fYF5acj5rPVloXx0fsajWILTJq7qRnI7sK 9sMROSr8+E79jb3mWMgLhDUJ1VQWusOqT2z8nYzndWZs+hT0DR ftgLMB8flhEKXM+UkpoOzV9hZ7GMZw/kE4iLgvtXdxSJARCjXH rfQuRqwfG7tCShwcJ6mUnHEuFki7iXql4sd1kP1oBPAeiVaZ/W 75BXkIOdQUC2A== Subject: [core] coap-09 review (security) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 05 Apr 2012 11:58:23 -0000 --Apple-Mail=_818580A4-DF89-40F4-B368-D1105BCFC2BC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, Please see below for my review comments on CoAP security. Section 10. NoSec: There is no protocol level security (DTLS is disabled). Alternative techniques to provide lower layer security SHOULD be used when appropriate. The use of IPsec is discussed in Section 10.2. Alper> This "SHOULD when appropriate" is likely to lead to use of = "insufficient" solutions. Without clear guidance, people cannot know if = their alternative is really "appropriate", and they'd most probably be = unreasonably optimistic about it. We need to provide some guidance here. = Otherwise we are leaving a security hole behind. PreSharedKey: DTLS is enabled and there is a list of pre-shared keys and each key includes a list of which nodes it can be used to communicate with as described in Section 10.1.1. At the extreme there may be one key for each node this CoAP node needs to communicate with (1:1 node/key ratio). Alper> Pairwise PSK (1:1) is what we should recommend, if not mandate. = Anything less than that (PSK shared among multiple entities) is weak = security. We should discourage, if not prohibit it. Certificate: DTLS is enabled and the device has an asymmetric key pair with an X.509 [RFC5280] certificate that binds it to its Authority Name and is signed by some common trust root as described in Section 10.1.3. The device also has a list of root trust anchors that can be used for validating a certificate. Alper> For this to interoperate "out-of the box", we need to make sure = the device is provisioned with the public key of Root CA that signed the = other end-point's cert. There needs to be some coordination, as random = selection of root CAs would fail interop. Need to be clear about that, = otherwise people think putting a cert on the device gets them a fully = interoperating solution. Section 10.1.3 When a new connection is formed, the certificate from the remote device needs to be verified. If the CoAP node has a source of absolute time, then the node SHOULD check the validity dates are of Alper> Why not "MUST check"? Unless there is a valid reason to relax = this rule, we'd be opening a potential hole without a good = justification. Section 10.3.3 CoAP also supports the use of multicast IP addresses in requests, an important requirement for M2M. Multicast CoAP requests may be the source of accidental or deliberate denial of service attacks, especially over constrained networks. This specification attempts to reduce the amplification effects of multicast requests by limiting when a response is returned. To limit the possibility of malicious use, CoAP servers SHOULD NOT accept multicast requests that can not be authenticated. =20 Alper> Why not "MUST NOT accept"? Again, unless there is a valid reason = to relax this rule, we'd be opening a potential hole without a good = justification.=20 Section 10.3.4 Due to the lack of a handshake in UDP, a rogue endpoint which is free to read and write messages carried by the constrained network (i.e. NoSec or PreSharedKey deployments with nodes/key ratio > 1:1),=20 Alper> We shall advise against "nodes/key ratio > 1:1:", if not = prohibit... Section 10.3.5 o the attacker sends a message to a CoAP end-point with a fake source address, o the CoAP end-point replies with a message to the given source address, o the victim at the given source address receives a UDP packet that it interprets according to the rules of a different protocol. Alper> Assuming the victim is listening on the src port used by the = attacker, right? And the victim is in server mode ready to accept = asynchronously sent request packets (otherwise, there'd be some state on = the victim which would be harder to match with the reflect packet). Appendix D.1 The RawPublicKey mode was designed to be easily provisioned in M2M deployments. It is assumed that each device has an appropriate asymmetric public key pair installed, and an identity from that public key has been calculated as described in Appendix D.1.1. During provisioning, the identity of each node is collected, for example by reading a barcode on the outside of the device or by obtaining a pre-compiled list of the identities. These identities are then installed in the corresponding end-point, for example an M2M data collection server. The identity is used for two purposes, to associate the end-point with further device information and to perform access control. During provisioning, an access control list of identities the device may start DTLS sessions with SHOULD also be installed. Alper> Either that SHALL happen, or the device SHALL securely learn the = IDs by some other means.=20 We cannot possibly be more specific than that, but we shall force = "secure learning". Appendix D.2.2 In this mode the identity of the public key for a device is used for access control. An end-point SHOULD keep a list of identities that it allows to access its resource, and MAY also support more detailed access control on the method or resource level. When a DTLS session is negotiated, a CoAP server that has an access control list MUST check the identity of the client. This is done by calculating the identity of the client's public key as described in Appendix D.1.1. A client SHOULD also verify the identity of the server if it has been configured with the appropriate access control list. Alper> "MUST also verify". Alper> I'd even say remove "if it has been configured with the = appropriate access control list." What we don't know is how that access control list got on the device -- = pre-provisoning, some other secure means, etc. But we know that we must = use it, otherwise we are not talking about a secure solution. If we are = thinking about some cases where it does not matter who the device is = communicating with, then we can blend in "policy" into the text. For = example, according to such policy, device may not care about the = identity of its peer in certain types of communication (e.g., sending = the temperature reading of a public place). Regards, Alper --Apple-Mail=_818580A4-DF89-40F4-B368-D1105BCFC2BC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii NoSec:  There is no protocol = level security (DTLS is disabled).
      Alternative = techniques to provide lower layer security SHOULD be
      Section 10.2.


   PreSharedKey:  = DTLS is enabled and there is a list of pre-shared keys
      communicate with as = described in Section 10.1.1.  At the extreme
      communicate with (1:1 = node/key ratio).

   Certificate:  DTLS is enabled = and the device has an asymmetric key
      pair with an = X.509 [RFC5280] certificate that binds it to its
      described in Section = 10.1.3.  The device also has a list of root



Section 10.1.3
   When a new connection is formed, the = certificate from the remote
   device needs to be = verified.  If the CoAP node has a source of


Section 10.3.3
   CoAP also supports the use of = multicast IP addresses in requests, an
   important = requirement for M2M. Multicast CoAP requests may be the
   especially over constrained = networks.  This specification attempts to
   when a response is returned.  = To limit the possibility of malicious
   use, CoAP = servers SHOULD NOT accept multicast requests that can not
Alper> Why not "MUST NOT accept"? Again, = unless there is a valid reason to relax this rule, we'd be opening a = potential hole without a good justification. 

Section 10.3.4
   Due to the lack of a handshake in = UDP, a rogue endpoint which is free
   to read and write = messages carried by the constrained network (i.e.



Section = 10.3.5

   o  the attacker sends a message = to a CoAP end-point with a fake
      source = address,

      address,

   o  the victim at = the given source address receives a UDP packet that




Appendix D.1

   The RawPublicKey mode = was designed to be easily provisioned in M2M
   asymmetric public key pair = installed, and an identity from that
   public key has been = calculated as described in Appendix D.1.1.
   During = provisioning, the identity of each node is collected, for
   obtaining a pre-compiled list of the = identities.  These identities
   are then installed in = the corresponding end-point, for example an M2M
   associate the end-point with further = device information and to
   perform access = control.  During provisioning, an access control list
   installed.


We cannot possibly be more specific = than that, but we shall force "secure learning".

Appendix D.2.2

   In this mode the = identity of the public key for a device is used for
   it allows to access its resource, = and MAY also support more detailed
   access control on the = method or resource level.  When a DTLS session
   check the identity of the = client.  This is done by calculating the
Appendix = D.1.1.
   A client SHOULD also verify the = identity of the server if it has been
   configured with = the appropriate access control list.

Alper> I'd even say remove "if = it has been configured with the appropriate access control = list."
What we don't know is how that access control = list got on the device -- pre-provisoning, some other secure means, etc. = But we know that we must use it, otherwise we are not talking about a = secure solution. If we are thinking about some cases where it does not = matter who the device is communicating with, then we can blend in = "policy" into the text. For example, according to such policy, device = may not care about the identity of its peer in certain types of = communication (e.g., sending the temperature reading of a public = place).


Regards,
Alper




Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-Provags-ID: V02:K0:wpA9cw9hEVE2VWtB+OEFsrWibQ1M9yzNT7tCXkCPmEA 6wpN++tihSJ0aZp+oPBbmgkXTXegs/bY+fRE8V4R/zX0r7afF5 Y8erMKuLaY3HbLHrFvLnd+fWEflrwRDyzT4NpmIFClyrTZn+Ec GDv21yRKbXUoTHIsL58TQOMwgIJGxQdP2ZW42BULnznZiUFkKr 7jS6Qx6ydqWX6r2/OLVmFm4MsfqK5xl+/LVDVaApcB0Oq51+WH llaFB8+0lExmSb2ruIaAqYDNF74IGMrHvQuuzUzYfnxYi9JL6a ry9pK1cjfSyyk7voBa7KUQi+8dLt2/Lbnpux8HGQo1t1OhERhJ BcQ5WtHV1Lev+42S2X+F7fQEoPit4uBSX23snrR1UFTGv6mcy+ vg+spBn8QRlzQ== Subject: [core] coap-09 review (vendor-defined options) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 05 Apr 2012 12:11:49 -0000 I recommend we migrate Section 3. Vendor-defined Options of coap-misc = I-D into core-coap I-D. From matthieu.vial@non.schneider-electric.com Thu Apr 5 05:50:11 2012 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 ADEBB21F8763; Thu, 5 Apr 2012 05:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.499 X-Spam-Level: X-Spam-Status: No, score=-5.499 tagged_above=-999 required=5 tests=[AWL=1.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzXPl9KxMGoF; Thu, 5 Apr 2012 05:50:10 -0700 (PDT) Received: from mailX02.eud.schneider-electric.com (mailx02.eud.schneider-electric.com [205.167.7.38]) by ietfa.amsl.com (Postfix) with ESMTP id 3937A21F87FC; Thu, 5 Apr 2012 05:50:10 -0700 (PDT) Received: from ATEUI01.schneider-electric.com ([10.198.14.9]) by mailX02.eud.schneider-electric.com with ESMTP id 2012040514500744-65730 ; Thu, 5 Apr 2012 14:50:07 +0200 In-Reply-To: To: Zach Shelby MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 From: matthieu.vial@non.schneider-electric.com Message-ID: Date: Thu, 5 Apr 2012 14:50:09 +0200 X-MIMETrack: Serialize by Router on ATEUI01.Schneider-Electric.com/T/SVR/Schneider at 05/04/2012 14:51:09, Serialize complete at 05/04/2012 14:51:09, Itemize by SMTP Server on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 05/04/2012 14:50:07, Serialize by Router on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 05/04/2012 14:50:09, Serialize complete at 05/04/2012 14:50:09 Content-Type: text/plain; charset="US-ASCII" Cc: core-bounces@ietf.org, core@ietf.org Subject: Re: [core] Sleepy devices + observer model X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 05 Apr 2012 12:50:11 -0000 Hi all, >1. Nail down the problem you are trying to solve, keep it simple to start with >2. First explore how you can use Observe or a client mode and REST to solve it >3. Get some practical experience with those solutions, iterate >4. If all else fails, then start talking about new options etc. Seems reasonable to me. Do we agree on that? Besst regards, Matthieu From stephen.farrell@cs.tcd.ie Thu Apr 5 13:10:21 2012 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 03FBD21F866B for ; Thu, 5 Apr 2012 13:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+2wUeJv57yl for ; Thu, 5 Apr 2012 13:10:20 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id B5AD321F8663 for ; Thu, 5 Apr 2012 13:10:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 2D538171C02 for ; Thu, 5 Apr 2012 21:10:20 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1333656620; bh=fh7mClla1kKULT0hm2rAAtJh UdystROWWgkKfPmZB9Y=; b=vKzYvCn5dX4KI+ZCGVl8mCIZohroWnh1eEoWDER1 NYcCI541RUa+8eTCnuwRaxtmnRs/p3G05Go00fuSOOVV1UPqciTwyvH0w7iBI16Q 5yobAvqZ9bqLyuONEKjq1oswzsEl/dz5OTz7LfYJga1FJKs3HyS8YA04QEXH3+yd ZVgBEb/xArxYWywZCmnz7B476ME4XDvRTqbC5gwKMyXQZ4IMPL7uy11R3KwHxZAJ i5BGpp0b4PZ/u9nI+JyYv4ozSQWdxr2JiN6eCNAiV/B5cHCdmPG9C0N1UPycG9Ry gQSiNffrqlqO+YiktPbtQocanUP/RpKp2z9Ziprt1ywnWQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id PfkyCHbEmzFU for ; Thu, 5 Apr 2012 21:10:20 +0100 (IST) Received: from [10.87.48.3] (unknown [86.41.2.139]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id E6074171BFD for ; Thu, 5 Apr 2012 21:10:19 +0100 (IST) Message-ID: <4F7DFC2B.80200@cs.tcd.ie> Date: Thu, 05 Apr 2012 21:10:19 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [core] draft-farrell-decade-ni-02 - we think this is done... X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 05 Apr 2012 20:10:21 -0000 ...well, modulo one or two questions still in the document [1] and getting your review:-) This document has been discussed in the decade WG as a way to standardise how to emded hashes into names, which is something that'll likely be needed there but is clearly more general. As if to prove that, at IETF-83 we added a binary form that seems to better fit what the core WG want for doing the same thing in CoAP. We've worked on it a good bit in the time since and so we reckon this is pretty much ready now. Our plan is to try get comments from the decade, core and appsarea lists and if we're looking good to then ask Barry Leiba if he'll AD sponsor this document, so it can be done in time to not slow down CoAP. (Barry's ok with this plan.) So, please take a read if you're interested in naming things with hashes and send your comments. Since this was first discussed on the decade list, I'll suggest using that [2] as a good place to send comments. Any of the above-mentioned lists will work though, since various authors are on each. Probably better to not cross-post to them all though. (I've sent separate mails to each for that reason.) Thanks, Stephen. [1] http://tools.ietf.org/html/draft-farrell-decade-ni [2] https://www.ietf.org/mailman/listinfo/decade From cabo@tzi.org Thu Apr 5 15:13:10 2012 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 B58CD21F85D4 for ; Thu, 5 Apr 2012 15:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.849 X-Spam-Level: X-Spam-Status: No, score=-106.849 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ElacubEhDow for ; Thu, 5 Apr 2012 15:13:10 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id B046321F85AE for ; Thu, 5 Apr 2012 15:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q35MCxKm008501 for ; Fri, 6 Apr 2012 00:13:00 +0200 (CEST) Received: from [192.168.217.117] (p5489AB9F.dip.t-dialin.net [84.137.171.159]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9A9627D1; Fri, 6 Apr 2012 00:12:59 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <4F7DFC2B.80200@cs.tcd.ie> Date: Fri, 6 Apr 2012 00:12:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F7DFC2B.80200@cs.tcd.ie> To: "core@ietf.org WG" X-Mailer: Apple Mail (2.1257) Subject: [core] Please review in the context of core-coap-09 -- Re: draft-farrell-decade-ni-02 - we think this is done... X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 05 Apr 2012 22:13:10 -0000 This is the next version of the draft that was discussed in the WG = meeting in Ari's memorable two-minute "in how many ways can we make the = projector fail" segment. Seriously. this may be a much more consequential document for the future = Web than it appears to be. So please do review this in the context of the core-coap-09 WGLC, for = which it could provide the hash identities only touched in D.1.1. (I already sent a review with not-so-CoRE-related issues to = apps-discuss.) The document currently only discusses the relationship of ni:// to = http:// URIs. Do we need to do anything about ni:// <-> coap://? Gr=FC=DFe, Carsten On Apr 5, 2012, at 22:10, Stephen Farrell wrote: >=20 > ...well, modulo one or two questions still in the document [1] > and getting your review:-) >=20 > This document has been discussed in the decade WG as a way to > standardise how to emded hashes into names, which is something > that'll likely be needed there but is clearly more general. As > if to prove that, at IETF-83 we added a binary form that seems > to better fit what the core WG want for doing the same thing in > CoAP. We've worked on it a good bit in the time since and so > we reckon this is pretty much ready now. >=20 > Our plan is to try get comments from the decade, core and > appsarea lists and if we're looking good to then ask Barry > Leiba if he'll AD sponsor this document, so it can be done in > time to not slow down CoAP. (Barry's ok with this plan.) >=20 > So, please take a read if you're interested in naming things > with hashes and send your comments. >=20 > Since this was first discussed on the decade list, I'll suggest > using that [2] as a good place to send comments. Any of the > above-mentioned lists will work though, since various authors > are on each. Probably better to not cross-post to them all > though. (I've sent separate mails to each for that reason.) >=20 > Thanks, > Stephen. >=20 > [1] http://tools.ietf.org/html/draft-farrell-decade-ni > [2] https://www.ietf.org/mailman/listinfo/decade > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From cabo@tzi.org Thu Apr 5 17:50:10 2012 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 5974F11E8079 for ; Thu, 5 Apr 2012 17:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.774 X-Spam-Level: X-Spam-Status: No, score=-106.774 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPSLZdZG2RWP for ; Thu, 5 Apr 2012 17:50:09 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9C511E8072 for ; Thu, 5 Apr 2012 17:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q360nxG1024105; Fri, 6 Apr 2012 02:49:59 +0200 (CEST) Received: from [192.168.217.117] (p5489AB9F.dip.t-dialin.net [84.137.171.159]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 76F257DC; Fri, 6 Apr 2012 02:49:59 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Fri, 6 Apr 2012 02:49:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7DAE016E-989B-4DA7-A771-F4A967B7C8A9@tzi.org> References: To: "Stok, Peter van der" X-Mailer: Apple Mail (2.1257) Cc: core WG Subject: Re: [core] roadmap draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 06 Apr 2012 00:50:10 -0000 Hi Peter, thank you for having a look at the first version of the draft. I'm very well aware of the dangers of such a draft, but I thought the = upsides are greater. > A possibly good guard is to give the draft writers fair access to the = contents of the roadmap draft. This is certainly what I have in mind. I have to qualify this a bit however: There would have been two ways to do this: -- aim for a WG draft, and use the WG consensus process to move it = forward; -- run this as a personal draft, and be quicker and possibly more candid = in places. (E.g., it is easier for me to say "draft-yegin-coap-security-options-00 = was more of a trial balloon to explore one approach that is not actively pursued." than for the WG = chairs to state WG consensus on this.) This works best if authors are also candid in telling me where to = improve the document... > One of the things that makes it difficult to judge the validity of a = draft is the large number of application areas and network architectures = that coap addresses. Just to name a few obvious ones: > =B7 Stand alone lowpan without edge router > =B7 Stand alone lowpan without edge router > =B7 Connected lowpan with edge router >=20 > Within these three possible network architectures there is the = distinction between managed network (e.g. office infra structure) and = unmanaged network (e.g. residential).=20 Indeed. If you have text that could shed some light on this, I would = love to include this in the roadmap draft. (Or point to it.) > I think it would be good to characterize drafts to see which = architecture they aim at. These categories are also necessary in my = opinion to come to security solutions which are lean but adequate for = the environment for which they are intended. > My suggestion is to make the roadmap draft a document that describes = attributes of each draft with a table that can be provided by the = authors of the draft, Developing such a table/taxonomy would be a worthwhile goal in evolving = this draft. I don't think we have such a taxonomy ready to use right now. (Once we have it, that might spin off as a useful WG document of its = own. But let's try to collect some input first.) > and that authors also have access to the text describing their drafts = but within well defined space limits. One of the topics of this = description should be a description how the draft extends other core = drafts or proposes a different solution to the same problem without = discussion of the why and how. I've tried to capture this for some of the documents, but obviously ran = out of time during the meeting. Draft authors: If you want to help this document along, please do send a = paragraph or two in the spirit of what Peter described! I have submitted a -01 today -- not much changed = (http://tools.ietf.org/rfcdiff?url2=3Ddraft-bormann-core-roadmap-01.txt); = please do send me material for a better -02. Gr=FC=DFe, Carsten From fluffy@iii.ca Fri Apr 6 07:58:52 2012 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 1220A21F8526 for ; Fri, 6 Apr 2012 07:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KWFMdMJ1VOu for ; Fri, 6 Apr 2012 07:58:51 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 982FF21F84D0 for ; Fri, 6 Apr 2012 07:58:51 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQGALcDf0+rRDoG/2dsb2JhbABFgyC1fYEHggkBAQEDARIBCmELCxguVwY1h2cEmlyfeI9tYwSIWpMEiFuBaYMG X-IronPort-AV: E=Sophos;i="4.75,381,1330905600"; d="scan'208";a="36801128" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 06 Apr 2012 14:58:51 +0000 Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q36Ewo0S014114 for ; Fri, 6 Apr 2012 14:58:51 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1084) From: Cullen Jennings In-Reply-To: <4F7CABE9.1060904@ericsson.com> Date: Fri, 6 Apr 2012 08:58:50 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <10F92FD7-413F-410B-B16A-311355BDD273@iii.ca> References: <051.7d477dcf63d5a27be6104f253d5fe611@trac.tools.ietf.org> <066.a52a01c1dc069cc2b1d31a7a8dc96d68@trac.tools.ietf.org> <4F7CABE9.1060904@ericsson.com> To: core WG X-Mailer: Apple Mail (2.1084) Subject: Re: [core] #204: Introduce a minimal version of Pledge X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 06 Apr 2012 14:58:52 -0000 On Apr 4, 2012, at 2:15 PM, Salvatore Loreto wrote: > On 4/4/12 9:44 PM, core issue tracker wrote: > > #204: Introduce a minimal version of Pledge > > > > > > Comment (by cabo@=85): > > > > When we briefly discussed this again during the Friday meeting, = the sense > > of the room went towards: > > > > -- the basic mechanism (i.e., in the draft now) works for some, = not all, > > applications > > -- any potential extensions should be done in a separate draft > > > > (The sense of the room is not a final WG decision of course, but a = good > > indication of direction.) >=20 > the chairs have started a WG last call for the Observer draft > try to insert extensions (or make any significant technical changes) = in > a document > in last call is a *bad* thing at least IMO >=20 > as any technical change requires some time to be discussed, understood > etc. etc. The only thing worse that a big change in WGLC, is not making a cahnge = that should be made. Part of the reasons for starting the WGLC was to = find out if we are pretty much done or not. Many documents at IETF have = a WGLC, then a bunch of work happends, then we have another WGLC. The = pub/sub problem has turned out to be very difficutl in nearly everyon = protcol that has done it so I really want us to make sure we are pretty = happy with howerver do do Observe.=20= From salvatore.loreto@ericsson.com Fri Apr 6 08:15:15 2012 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 306CF21F85B9 for ; Fri, 6 Apr 2012 08:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.766 X-Spam-Level: X-Spam-Status: No, score=-105.766 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFHoW+YKLGYt for ; Fri, 6 Apr 2012 08:15:14 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 65B3421F85B8 for ; Fri, 6 Apr 2012 08:15:14 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-20-4f7f088196a1 Authentication-Results: mailgw2.ericsson.se x-tls.subject="/CN=esessmw0197"; auth=fail (cipher=AES128-SHA) Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0197", Issuer "esessmw0197" (not verified)) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 60.A5.03534.1880F7F4; Fri, 6 Apr 2012 17:15:13 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.213.0; Fri, 6 Apr 2012 17:15:12 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id B5CC42326 for ; Fri, 6 Apr 2012 18:15:12 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id CB7845264E for ; Fri, 6 Apr 2012 18:15:12 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 552A251AF6 for ; Fri, 6 Apr 2012 18:15:12 +0300 (EEST) Message-ID: <4F7F087F.5010802@ericsson.com> Date: Fri, 6 Apr 2012 17:15:11 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: core@ietf.org References: <051.7d477dcf63d5a27be6104f253d5fe611@trac.tools.ietf.org> <066.a52a01c1dc069cc2b1d31a7a8dc96d68@trac.tools.ietf.org> <4F7CABE9.1060904@ericsson.com> <10F92FD7-413F-410B-B16A-311355BDD273@iii.ca> In-Reply-To: <10F92FD7-413F-410B-B16A-311355BDD273@iii.ca> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [core] #204: Introduce a minimal version of Pledge X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 06 Apr 2012 15:15:15 -0000 On 4/6/12 4:58 PM, Cullen Jennings wrote: > On Apr 4, 2012, at 2:15 PM, Salvatore Loreto wrote: > >> On 4/4/12 9:44 PM, core issue tracker wrote: >>> #204: Introduce a minimal version of Pledge >>> >>> >>> Comment (by cabo@): >>> >>> When we briefly discussed this again during the Friday meeting, the sense >>> of the room went towards: >>> >>> -- the basic mechanism (i.e., in the draft now) works for some, not all, >>> applications >>> -- any potential extensions should be done in a separate draft >>> >>> (The sense of the room is not a final WG decision of course, but a good >>> indication of direction.) >> the chairs have started a WG last call for the Observer draft >> try to insert extensions (or make any significant technical changes) in >> a document >> in last call is a *bad* thing at least IMO >> >> as any technical change requires some time to be discussed, understood >> etc. etc. > The only thing worse that a big change in WGLC, is not making a cahnge that should be made. Part of the reasons for starting the WGLC was to find out if we are pretty much done or not. I concur ... > Many documents at IETF have a WGLC, then a bunch of work happends, then we have another WGLC. I was referring to the eventuality to produce a new version of the draft *while* the WGLC is running, not to the fact that as result of WGLC we can need a bunch of work (technical changes) to address all the comments and then another WGLC etc.etc. Sorry not to have been enough clear in expressing my thought. > The pub/sub problem has turned out to be very difficutl in nearly everyon protcol that has done it so I really want us to make sure we are pretty happy with howerver do do Observe. I know very well the difficulty, having participate somehow to the work done in SIP about pub/sub. From cabo@tzi.org Fri Apr 6 09:57:56 2012 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 EDCA721F860B for ; Fri, 6 Apr 2012 09:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.669 X-Spam-Level: X-Spam-Status: No, score=-106.669 tagged_above=-999 required=5 tests=[AWL=-0.420, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iz+KqtfYPBpp for ; Fri, 6 Apr 2012 09:57:56 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id B488D21F84D2 for ; Fri, 6 Apr 2012 09:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q36Gvkdu003917; Fri, 6 Apr 2012 18:57:46 +0200 (CEST) Received: from [192.168.217.105] (p54899D39.dip.t-dialin.net [84.137.157.57]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A1D9F85D; Fri, 6 Apr 2012 18:57:46 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: <4F7F087F.5010802@ericsson.com> Date: Fri, 6 Apr 2012 18:57:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8D4A22B5-2D08-4061-B7EE-05697E9103DE@tzi.org> References: <051.7d477dcf63d5a27be6104f253d5fe611@trac.tools.ietf.org> <066.a52a01c1dc069cc2b1d31a7a8dc96d68@trac.tools.ietf.org> <4F7CABE9.1060904@ericsson.com> <10F92FD7-413F-410B-B16A-311355BDD273@iii.ca> <4F7F087F.5010802@ericsson.com> To: Salvatore Loreto X-Mailer: Apple Mail (2.1257) Cc: core@ietf.org Subject: Re: [core] #204: Introduce a minimal version of Pledge X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 06 Apr 2012 16:57:57 -0000 On Apr 6, 2012, at 17:15, Salvatore Loreto wrote: > I was referring to the eventuality to produce a new version of the = draft *while* the WGLC is running, Ah. Let's not do that. (But we can start collecting replacement text for potential areas of = improvement. The issue tracker can help with that.) Gr=FC=DFe, Carsten From robert.cragie@gridmerge.com Fri Apr 6 11:38:15 2012 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 8F21211E8085; Fri, 6 Apr 2012 11:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExPlC2EIJ+Ek; Fri, 6 Apr 2012 11:38:15 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3F221F8644; Fri, 6 Apr 2012 11:38:14 -0700 (PDT) Received: from client-86-25-27-201.midd-bam-1.adsl.virginmedia.com ([86.25.27.201] helo=[192.168.0.2]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) id 1SGE2w-0007Mw-Ia; Fri, 06 Apr 2012 19:38:09 +0100 Message-ID: <4F7F386F.7050309@gridmerge.com> Date: Fri, 06 Apr 2012 19:39:43 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: matthieu.vial@non.schneider-electric.com References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020404000404080507020908" X-Authenticated-As: robert.cragie@gridmerge.com Cc: core-bounces@ietf.org, core@ietf.org Subject: Re: [core] Sleepy devices + observer model X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 18:38:15 -0000 This is a cryptographically signed message in MIME format. --------------ms020404000404080507020908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Sounds good to me. I think one approach is to consider appropriate=20 design patterns for these. Also, with regard to REST, the assumption=20 seems to be this is one resource. I would say it is a collaboration of=20 distinct resources with some functional logic binding them. For example, consider the sleepy sensor which sends a value=20 periodically. One way to look at this is the sleepy device contains a=20 resource which is updated internally every time the device wakes. This=20 update causes a POST to be sent to another server (the mirror server).=20 This POST creates a new instance of a reading in the mirror server.=20 However, the subsequent processing could take many forms. For example,=20 it could: 1. Overwrite the current value and send a notify to an observing client 2. Overwrite the current value. The client can use etags to determine if = it has been updated 3. Add to a FIFO queue (a la AtomPub) and send a notify to an observing=20 client 4. Add to a FIFO queue. A client will do a subsequent fetch =2E..and so on. In essence, I believe these design pattern need to be developed=20 independently of the CoAP protocol. Many examples of such design=20 patterns exist in the HTTP world, e.g. AtomPub, ZeroMQ, RestMS etc. Robert On 05/04/2012 1:50 PM, matthieu.vial@non.schneider-electric.com wrote: > Hi all, > >> 1. Nail down the problem you are trying to solve, keep it simple to st= art > with >> 2. First explore how you can use Observe or a client mode and REST to > solve it >> 3. Get some practical experience with those solutions, iterate >> 4. If all else fails, then start talking about new options etc. > Seems reasonable to me. Do we agree on that? > > Besst regards, > Matthieu > > --------------ms020404000404080507020908 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP3jCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi 5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcw FQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VS Rmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBa Fw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NY X2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqi QfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBT bJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YX WEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30i Y9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSd JnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1UdDwEB /wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8E UTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGll bnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUH MAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQw JQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQAD ggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjf y/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T 4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrU yTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lE uJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggYuMIIFFqAD AgECAhBcMVDbxC2oy5hyHl/adO9mMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEb MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMDkwMjAwMDAwMFoXDTE0MDkwMTIzNTk1 OVowggE3MQswCQYDVQQGEwJHQjEQMA4GA1UEERMHV0Y0IDRXQTEXMBUGA1UECBMOV2VzdCBZ b3Jrc2hpcmUxEjAQBgNVBAcTCVdha2VmaWVsZDEUMBIGA1UECRMLR3JhbmdlIE1vb3IxHzAd BgNVBAkTFjg5IEdyZWVuZmllbGQgQ3Jlc2NlbnQxFzAVBgNVBAoTDkdyaWRtZXJnZSBMdGQu MTQwMgYDVQQLEytJc3N1ZWQgdGhyb3VnaCBHcmlkbWVyZ2UgTHRkLiBFLVBLSSBNYW5hZ2Vy MR8wHQYDVQQLExZDb3Jwb3JhdGUgU2VjdXJlIEVtYWlsMRYwFAYDVQQDEw1Sb2JlcnQgQ3Jh Z2llMSowKAYJKoZIhvcNAQkBFhtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtxOGq8t5ZTVDVkmadv7ZRBLA5ApaiTcDUzCTn zYB2/BoBDIEWWI/InSRcmq3A0Ghm+T7dYmvRADllGv4nTHexdWlzFp2iM/Yc3PLWCyAO0gYb yW2hTi+ZfUDwFOU4hRP4+Dyn9tKu7FXS/PQJHyGjaGxHRmLm9T6tAo2ZuC59uRaGVCcwRiOS d6axwtB/DVhnP3S1rrt2g0O6MXLr5fojToemO52AxjHxt2w1LnFUUXC4EDV6o1Ctr7EvOEI5 5f088H/Mrryp02GueLdY9gb0SFK3gPOT7EjP2GPvCtRkhVcNM+xjyptRIFWnCbMjmUIc+DO6 sfU4rtbCCkNKyXmnAgMBAAGjggHVMIIB0TAfBgNVHSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBb vHnFezAdBgNVHQ4EFgQUEI5c0f6UObxT2DLdvdtG+vG8qCswDgYDVR0PAQH/BAQDAgWgMAwG A1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQMFMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEB BHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50 QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMCYGA1UdEQQfMB2BG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdl LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAPpv87QuQ9q+RHhmeirGDQB3szd24Obi7N+uVfh5y CrnoJx3B37dNrLPsTB6PfTChUyZMqQD80pFoJ3TBUz3yx4X+hmNco7ujVIfbuKBGcZJaMKhZ ex3AkZ9ltie9wgiGGzEmgI81t5JHsLQ8AUMqw/fGsnIwcyWMgmyhFtm79+dg3IVaH05d/t9g k4aYoMoCFJptQZ+Fju6a9T139hOqjTZDpjMLt3jM80bVrvkC4dIRyF/oZ0qrJwbfwjnL2OUN ph9eymhLc+VM0Ih5k41s5IxmB+2c0RUqr5JbK0WrIb/z53Cmb9rXYox7HknyIfBpQqP77Y7a sAU2MMOpel4RijGCBAwwggQIAgEBMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0Eg TGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9mMAkGBSsOAwIaBQCgggI4MBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQwNjE4Mzk0M1owIwYJKoZI hvcNAQkEMRYEFFYJXQkqlbg7vd51wS1QozGwwrHIMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDCBuQYJKwYBBAGCNxAEMYGrMIGoMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD VQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9mMIG7BgsqhkiG 9w0BCRACCzGBq6CBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3 BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0BAQEFAASCAQBrVbRgkIjqMSclKM94Rpsf XLptoikToXUQXQUeYWpf3Su/OExj1ivnFuBhnYo/AUxVf3/HlJkQFek1iAcW+4rnODj8y3nv ZdHa2I+yjl15c5zt19Np/bS9Xeqq6yWcGGy04KeorOiy2sMiU8VXGhyNREum66KrvRrKHIWi 3G5sVt0TGFvVRNlul0kelKlMvIYthSiRFzI83SXoSOkUlL7GVWpFmhi00ja9SBMgrZ905d+l VL4UKnC3P6h+0p4oLJyXcKIpQQD112SPzBm6SB/LAIkqXv4Xhad3Cd8OebP46XC7N3IeZdXm akxerXbTroUShGlEKUcBQtC9g3MEtIdIAAAAAAAA --------------ms020404000404080507020908-- From Akbar.Rahman@InterDigital.com Sat Apr 7 15:05:03 2012 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 CCC0E21F84E6 for ; Sat, 7 Apr 2012 15:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnuCIDpV-qz5 for ; Sat, 7 Apr 2012 15:05:03 -0700 (PDT) Received: from idcout.InterDigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id D246721F84D9 for ; Sat, 7 Apr 2012 15:04:52 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 7 Apr 2012 18:04:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Sat, 7 Apr 2012 18:04:51 -0400 Message-ID: In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Feedback request on HTTP mapping document split Thread-Index: Ac0SeOKH46B9Z/vzTZG1KR9ZU/FHbwCkWSWQ References: From: "Rahman, Akbar" To: "Angelo P. Castellani" X-OriginalArrivalTime: 07 Apr 2012 22:04:52.0127 (UTC) FILETIME=[750D3AF0:01CD150A] Cc: core Subject: Re: [core] Feedback request on HTTP mapping document split X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 07 Apr 2012 22:05:03 -0000 SGkgQW5nZWxvLA0KDQoNCg0KVGhhbmtzIGZvciB0aGUgd3JpdGUgdXAuICBJIGFtIGZpbmUgd2l0 aCB5b3VyIHByb3Bvc2FsIGFuZCBJIHRoaW5rIGl0IGNvcnJlY3RseSBjYXB0dXJlcyB0aGUgV0cg ZGlzY3Vzc2lvbiBhdCBJRVRGIFBhcmlzLg0KDQoNCg0KDQpBa2Jhcg0KDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBhbmdlbG8uY2FzdGVsbGFuaUBnbWFpbC5jb20gW21haWx0 bzphbmdlbG8uY2FzdGVsbGFuaUBnbWFpbC5jb21dIE9uIEJlaGFsZiBPZiBBbmdlbG8gUC4gQ2Fz dGVsbGFuaQ0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAwNCwgMjAxMiAxMTozNyBBTQ0KVG86IGNv cmUNCkNjOiBDYXJzdGVuIEJvcm1hbm47IEN1bGxlbiBKZW5uaW5nczsgU2FsdmF0b3JlIExvcmV0 bzsgUmFobWFuLCBBa2JhcjsgVGhvbWFzIEZvc3NhdGk7IERpamssIEVza28NClN1YmplY3Q6IEZl ZWRiYWNrIHJlcXVlc3Qgb24gSFRUUCBtYXBwaW5nIGRvY3VtZW50IHNwbGl0DQoNCkRlYXIgV0cs DQoNCmFzIHBlciB0aGUgZGlyZWN0aW9uIGZyb20gdGhlIGNoYWlycyBhdCB0aGUgUGFyaXMgSUVU RiwgaGVyZSB5b3UgY2FuDQpmaW5kIGEgcHVibGljIGdvb2dsZSBkb2MgY29udGFpbmluZyBvdXIg aW5pdGlhbCBzZWxlY3Rpb24gb2YgZG9jdW1lbnQNCnBhcnRzIHRoYXQgd2Ugd2lsbCBrZWVwIGlu IGh0dHAtbWFwcGluZy0wNCBiYXNlIGRyYWZ0Og0KaHR0cHM6Ly9kb2NzLmdvb2dsZS5jb20vZG9j dW1lbnQvZC8xeW53QkJUOUpycC1ubHI3dlQ0M3FnX19ZZXZ2VlFhRVpESXVpYXZMQmRkcy9lZGl0 DQoNCldlIGhpZ2hsaWdodGVkOg0KLSBpbiB5ZWxsb3cgdGhlIHBhcnRzIHRoYXQgYXJlICJnb29k IGVub3VnaCIgaW4gdGhlIGN1cnJlbnQgdGV4dCwgYW5kDQp0aGF0IHdlIHdpbGwga2VlcCBhcyB0 aGV5IGFyZQ0KLSBpbiBvcmFuZ2UgdGhlIHBhcnRzIHRoYXQgbmVlZCBzeW50aGV0aWMgcmV3cml0 aW5nLCBhbmQgdG8gYmUgbW9yZQ0KZm9jdXNlZCBpbiB0aGUgZG9jdW1lbnQNCi0gaW4gd2hpdGUg dGhlIHBhcnRzIHJlbW92ZWQgYW5kIHRoYXQgd2lsbCBiZSBwdXQgaW4gYQ0KY29yZS1hZHZhbmNl ZC1odHRwLW1hcHBpbmctMDAgZHJhZnQNCg0KVGhlIGRvY3VtZW50IGlzIHB1YmxpYywgeW91IGNh biByZWFkLCBjb21tZW50IGFuZCBlZGl0IGl0LiBFc3BlY2lhbGx5DQppZiB5b3UgZmVlbCB0aGF0 IHNvbWUgc2VudGVuY2VzIG5lZWQgdG8gYmUgY2xhcmlmaWVkLCBoaWdobGlnaHQgdGhlbQ0KaW4g b3JhbmdlLg0KDQpJbiBwYXJ0aWN1bGFyICJwbGFjZW1lbnQgYW5kIGRlcGxveW1lbnQiIHNlY3Rp b24gaW4gSFRUUC1Db0FQIHdpbGwNCmJlY2FtZSBhZnRlciByZXdyaXRpbmcgYSBmb2N1c2VkICJy ZXZlcnNlIHByb3h5IiBzZWN0aW9uLg0KDQpNYWpvciBkb3VidHMgYXJlIGFib3V0IHRoZSBmb2xs b3dpbmcgc2VjdGlvbnMsIGFib3V0IHRoZW0gd2UgbWFkZSB0aGUNCm1vc3QgY29uc2VydmF0aXZl IGNob2ljZToNCi0gbXVsdGljYXN0IG1hcHBpbmcgLS0+IGFkdmFuY2VkDQotIG9ic2VydmUgbWFw cGluZyAtLT4gYWR2YW5jZWQNCi0gY29hcC1odHRwIC0tPiBiYXNlDQoNCklmIHlvdSBmZWVsIHRo YXQgdGhvc2UgY2hvaWNlcyBuZWVkIG1vcmUgdGhvdWdodCwgZHJvcCB5b3VyIG9waW5pb24gaW4N CnRoaXMgbWFpbCB0aHJlYWQuDQoNCldlIHRhcmdldCBoYXZpbmcgYSBwaG9uZSBjb25mZXJlbmNl IHdpdGggV0cgbWVtYmVycyBpbnRlcmVzdGVkIGluIHRoaXMNCnRvcGljLCBpbiBhYm91dCAyIHdl ZWtzIGZyb20gbm93LiBEZXRhaWxzIHdpbGwgYmUgZGlzcGF0Y2hlZCB0byB0aGUNCnBlb3BsZSBp bnRlcmVzdGVkIGluIHRoaXMgd29yayAocmVwbHlpbmcgdG8gdGhpcyB0aHJlYWQpLg0KDQpCZXN0 LA0KQW5nZWxvDQoob24gYmVoYWxmIG9mIGh0dHAtbWFwcGluZyBjby1hdXRob3JzKQ0K From tho@koanlogic.com Sun Apr 8 00:55:46 2012 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 0E5EB21F84D0 for ; Sun, 8 Apr 2012 00:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JA0ccoLw2Sj0 for ; Sun, 8 Apr 2012 00:55:45 -0700 (PDT) Received: from gonzo.koanlogic.com (koanlogic.com [64.251.31.111]) by ietfa.amsl.com (Postfix) with ESMTP id A231621F85B9 for ; Sun, 8 Apr 2012 00:55:45 -0700 (PDT) Received: from chello062178222142.13.15.univie.teleweb.at ([62.178.222.142]:53135 helo=[192.168.0.14]) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1SGmyE-0005jo-TA for core@ietf.org; Sun, 08 Apr 2012 03:55:44 -0400 From: Thomas Fossati Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 8 Apr 2012 09:55:31 +0200 Message-Id: <2511DC34-C620-4BC7-8AA8-7A7B0C5B9482@koanlogic.com> To: core WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 62.178.222.142 X-SA-Exim-Mail-From: tho@koanlogic.com X-Spam-DCC: : X-Spam-Pyzor: Reported 0 times. X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on gonzo.koanlogic.com) Subject: [core] multipart ct X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 08 Apr 2012 07:55:46 -0000 Hi all, we're working on an application that makes use of multipart. Since = there is no such media type currently defined in CoAP, I have drafted a = simple encoding format: = http://tools.ietf.org/html/draft-fossati-core-multipart-ct Any feed back is much appreciated. Thanks, Thomas.= From matthieu.vial@non.schneider-electric.com Tue Apr 10 01:09:38 2012 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 0036F21F872B; Tue, 10 Apr 2012 01:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.567 X-Spam-Level: X-Spam-Status: No, score=-4.567 tagged_above=-999 required=5 tests=[AWL=-0.382, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIDr5HtrqH9S; Tue, 10 Apr 2012 01:09:37 -0700 (PDT) Received: from mailX01.eud.schneider-electric.com (mailx01.eud.schneider-electric.com [205.167.7.35]) by ietfa.amsl.com (Postfix) with ESMTP id 68DFD21F8725; Tue, 10 Apr 2012 01:09:37 -0700 (PDT) Received: from ATEUI01.schneider-electric.com ([10.198.14.9]) by mailX01.eud.schneider-electric.com with ESMTP id 2012041010093423-10419 ; Tue, 10 Apr 2012 10:09:34 +0200 In-Reply-To: <4F7F386F.7050309@gridmerge.com> To: robert.cragie@gridmerge.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 From: matthieu.vial@non.schneider-electric.com Message-ID: Date: Tue, 10 Apr 2012 10:09:33 +0200 X-MIMETrack: Serialize by Router on ATEUI01.Schneider-Electric.com/T/SVR/Schneider at 10/04/2012 10:10:38, Serialize complete at 10/04/2012 10:10:38, Itemize by SMTP Server on AXEU1OUT.schneider-electric.com/X/SVR/SEIxtra at 10/04/2012 10:09:34, Serialize by Router on AXEU1OUT.schneider-electric.com/X/SVR/SEIxtra at 10/04/2012 10:09:36, Serialize complete at 10/04/2012 10:09:36 Content-Type: text/plain; charset="US-ASCII" Cc: core-bounces@ietf.org, core@ietf.org Subject: Re: [core] Sleepy devices + observer model X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 10 Apr 2012 08:09:38 -0000 Hi Robert, >In essence, I believe these design pattern need to be developed >independently of the CoAP protocol. Many examples of such design >patterns exist in the HTTP world, e.g. AtomPub, ZeroMQ, RestMS etc. So in your opinion the mirror server specification should leave more flexibility on how to handle data updates. In other words there can't be a generic mirror server function. We can specify registration,update,removal interfaces for a mirror entry and mirrored resources but that's all. The way the mirror server handle a POST request on a mirrored resources is left to the mirror server implementation. For a given deployment we probably need homogeneity in mirror server implementations so this behavior could be part of some profile specification. You ask for flexibility between the mirror server and the client but we may also want more flexibility between the sleepy and the mirror server. For example CoAP doesn't provide a way to act upon multiple resources in a single request. However we can do this with the core batch interface. But it requires the mirror server to understand SenML and the batch interface. It's probably better to require core interfaces support in an application profile than in the base mirror server spec. An environment sensor (temp, hum, co2, light) can make huge benefit of core batch and resource multiplexing for energy efficiency. Matthieu From peter.van.der.stok@philips.com Tue Apr 10 02:03:10 2012 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 3DAF921F8670; Tue, 10 Apr 2012 02:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.189 X-Spam-Level: X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[AWL=-0.590, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZwNqmPvbozN; Tue, 10 Apr 2012 02:03:09 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe004.messaging.microsoft.com [213.199.154.142]) by ietfa.amsl.com (Postfix) with ESMTP id 1754321F855F; Tue, 10 Apr 2012 02:03:09 -0700 (PDT) Received: from mail54-db3-R.bigfish.com (10.3.81.237) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.23; Tue, 10 Apr 2012 09:03:08 +0000 Received: from mail54-db3 (localhost [127.0.0.1]) by mail54-db3-R.bigfish.com (Postfix) with ESMTP id 28FE9160350; Tue, 10 Apr 2012 09:03:08 +0000 (UTC) X-SpamScore: -38 X-BigFish: VPS-38(zz217bL15d6O9251J542Mzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI Received: from mail54-db3 (localhost.localdomain [127.0.0.1]) by mail54-db3 (MessageSwitch) id 1334048585893185_7086; Tue, 10 Apr 2012 09:03:05 +0000 (UTC) Received: from DB3EHSMHS009.bigfish.com (unknown [10.3.81.227]) by mail54-db3.bigfish.com (Postfix) with ESMTP id D6AF51E019A; Tue, 10 Apr 2012 09:03:05 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by DB3EHSMHS009.bigfish.com (10.3.87.109) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 10 Apr 2012 09:03:05 +0000 Received: from 011-DB3MPN1-061.MGDPHG.emi.philips.com ([169.254.1.48]) by 011-DB3MMR1-007.MGDPHG.emi.philips.com ([10.128.28.57]) with mapi id 14.01.0355.003; Tue, 10 Apr 2012 10:03:04 +0100 From: "Stok, Peter van der" To: "matthieu.vial@non.schneider-electric.com" , "robert.cragie@gridmerge.com" Thread-Topic: [core] Sleepy devices + observer model Thread-Index: Ac0QxE7rpzs4fY/bToSRYwjf9ZElpgAAkpqgAFjsawAAAki5AAAAh3SAAA3v74AABRV3gAACyhGAACVdp4AAPn/5gACzKEiAAAObcJA= Date: Tue, 10 Apr 2012 09:05:39 +0000 Message-ID: References: <4F7F386F.7050309@gridmerge.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [82.95.140.48] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "core@ietf.org" , "core-bounces@ietf.org" Subject: Re: [core] Sleepy devices + observer model X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 10 Apr 2012 09:03:10 -0000 Hi Matthieu, I agree with the suggestion by Robert to leave the design patterns outside = coap protocol. I don't know about generic mirror servers, but I could imagine that you def= ine the interfaces between sleepy and mirror and between client and mirror. The conversions between input and output values are left open and a basic c= opy/overwrite function is specified as example and minimum implementation. Your text below remains a bit ambiguous to me >"For example CoAP doesn't provide a way to act upon multiple resources in = a >single request. However we can do this with the core batch interface. But >it requires the mirror server to understand SenML and the batch interface. >It's probably better to require core interfaces support in an application >profile than in the base mirror server spec. An environment sensor (temp, >hum, co2, light) can make huge benefit of core batch and resource >multiplexing for energy efficiency." What is the suggestion? To declare batch as part of coap and specify it for= the mirror, or to leave batch outside coap. I would suggest to delegate the use of batch to the profile specification o= f the profile standard. Greetings, peter -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of mat= thieu.vial@non.schneider-electric.com Sent: Tuesday 10 April 2012 10:10 To: robert.cragie@gridmerge.com Cc: core-bounces@ietf.org; core@ietf.org Subject: Re: [core] Sleepy devices + observer model Hi Robert, >In essence, I believe these design pattern need to be developed >independently of the CoAP protocol. Many examples of such design >patterns exist in the HTTP world, e.g. AtomPub, ZeroMQ, RestMS etc. So in your opinion the mirror server specification should leave more flexibility on how to handle data updates. In other words there can't be a generic mirror server function. We can specify registration,update,removal interfaces for a mirror entry and mirrored resources but that's all. The way the mirror server handle a POST request on a mirrored resources is left to the mirror server implementation. For a given deployment we probably need homogeneity in mirror server implementations so this behavior could be part of some profile specification. You ask for flexibility between the mirror server and the client but we may also want more flexibility between the sleepy and the mirror server. For example CoAP doesn't provide a way to act upon multiple resources in a single request. However we can do this with the core batch interface. But it requires the mirror server to understand SenML and the batch interface. It's probably better to require core interfaces support in an application profile than in the base mirror server spec. An environment sensor (temp, hum, co2, light) can make huge benefit of core batch and resource multiplexing for energy efficiency. Matthieu _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From matthieu.vial@non.schneider-electric.com Tue Apr 10 02:33:15 2012 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 0020221F87DA; Tue, 10 Apr 2012 02:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.698 X-Spam-Level: X-Spam-Status: No, score=-3.698 tagged_above=-999 required=5 tests=[AWL=-1.099, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4azsDlM-VmbJ; Tue, 10 Apr 2012 02:33:14 -0700 (PDT) Received: from mailX04.eud.schneider-electric.com (mailx04.eud.schneider-electric.com [205.167.7.39]) by ietfa.amsl.com (Postfix) with ESMTP id 176B621F87BE; Tue, 10 Apr 2012 02:33:13 -0700 (PDT) Received: from ATEUI01.schneider-electric.com ([10.198.14.9]) by mailX04.eud.schneider-electric.com with ESMTP id 2012041011330791-71326 ; Tue, 10 Apr 2012 11:33:07 +0200 In-Reply-To: To: "Stok, Peter van der" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 From: matthieu.vial@non.schneider-electric.com Message-ID: Date: Tue, 10 Apr 2012 11:33:06 +0200 X-MIMETrack: Serialize by Router on ATEUI01.Schneider-Electric.com/T/SVR/Schneider at 10/04/2012 11:34:10, Serialize complete at 10/04/2012 11:34:10, Itemize by SMTP Server on AXEU4OUT.schneider-electric.com/X/SVR/SEIxtra at 10/04/2012 11:33:07, Serialize by Router on AXEU4OUT.schneider-electric.com/X/SVR/SEIxtra at 10/04/2012 11:33:14, Serialize complete at 10/04/2012 11:33:14 Content-Type: text/plain; charset="US-ASCII" Cc: "core-bounces@ietf.org" , "core@ietf.org" Subject: Re: [core] Sleepy devices + observer model X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 10 Apr 2012 09:33:15 -0000 Hi Peter > What is the suggestion? To declare batch as part of coap and specify it for the mirror, or to leave batch outside coap. core-interfaces will never be included in the base CoAP spec but might be a CoRE working group just like mirror server or any other mirroring propositions. These drafts would be just tools that can be combined to build a constrained RESTful environment. The question is do we want to have core-interfaces support mandatory for a mirror server implementation or do we want to leave this decision to a profile. The same question applies for all the messaging/queuing patterns we can imagine between a mirror server and clients. >I would suggest to delegate the use of batch to the profile specification of the profile standard. I agree core-interfaces is just an optional tool. Matthieu From robert.cragie@gridmerge.com Tue Apr 10 04:37:02 2012 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 3D46C21F8555; Tue, 10 Apr 2012 04:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUyvnv1I7JZg; Tue, 10 Apr 2012 04:37:01 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id F071821F8550; Tue, 10 Apr 2012 04:37:00 -0700 (PDT) Received: from client-86-31-84-145.midd.adsl.virginmedia.com ([86.31.84.145] helo=[192.168.0.2]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) id 1SHZNa-00054z-7V; Tue, 10 Apr 2012 12:36:58 +0100 Message-ID: <4F841BB8.10802@gridmerge.com> Date: Tue, 10 Apr 2012 12:38:32 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: matthieu.vial@non.schneider-electric.com References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060706000803070005020404" X-Authenticated-As: robert.cragie@gridmerge.com Cc: core-bounces@ietf.org, core@ietf.org Subject: Re: [core] Sleepy devices + observer model X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 11:37:02 -0000 This is a cryptographically signed message in MIME format. --------------ms060706000803070005020404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Matthieu, Comments inline. The main point I wanted to make earlier in this thread=20 was that the basic CoAP protocol need not be extended and that it can be = used to represent common function sets as is and I think we are in=20 agreement there. Robert On 10/04/2012 9:09 AM, matthieu.vial@non.schneider-electric.com wrote: > Hi Robert, > >> In essence, I believe these design pattern need to be developed >> independently of the CoAP protocol. Many examples of such design >> patterns exist in the HTTP world, e.g. AtomPub, ZeroMQ, RestMS etc. > So in your opinion the mirror server specification should leave more > flexibility on how to handle data updates. > In other words there can't be a generic mirror server function. > We can specify registration,update,removal interfaces for a mirror entr= y > and mirrored resources but that's all. > The way the mirror server handle a POST request on a mirrored resources= is > left to the mirror server implementation. I think there are a number of applicable design patterns, which=20 having things in common and things which are different, i.e. classical=20 object-oriented design. > > For a given deployment we probably need homogeneity in mirror server > implementations so this behavior could be part of some profile > specification. I agree and I think profile specifications are the best place to=20 put it. It strikes me doing this through layers of abstraction of=20 profiles could simplify the development of specific application=20 profiles. > You ask for flexibility between the mirror server and the client but we= > may also want more flexibility between the sleepy and the mirror server= =2E Absolutely; I was only using the client/mirror server interaction=20 as an example of where there is variation. > For example CoAP doesn't provide a way to act upon multiple resources i= n a > single request. However we can do this with the core batch interface. B= ut > it requires the mirror server to understand SenML and the batch interfa= ce. > It's probably better to require core interfaces support in an applicati= on > profile than in the base mirror server spec. An environment sensor (tem= p, > hum, co2, light) can make huge benefit of core batch and resource > multiplexing for energy efficiency. I think the interfaces document and the concept of function sets=20 and profiles as defined is a good start to embody the concept of "design = pattern". However, the interfaces document represents interfaces to one=20 or more resources in a certain way. It does not seem to describe how=20 resources may need to internally collaborate to provide a specific=20 useful function. The idea of using design patterns in this context is to = generalize patterns which represent collaborating resources in a=20 homogeneous way; a kind of "middleware" which can be used across=20 different applications. So whilst they could be developed solely within=20 an application profile, it is likely that repetition will occur across=20 application profiles where functions are almost the same but developed=20 slightly differently. Hence suggesting using layers of abstraction.= > > Matthieu > --------------ms060706000803070005020404 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP3jCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi 5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcw FQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VS Rmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBa Fw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NY X2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqi QfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBT bJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YX WEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30i Y9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSd JnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1UdDwEB /wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8E UTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGll bnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUH MAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQw JQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQAD ggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjf y/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T 4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrU yTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lE uJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggYuMIIFFqAD AgECAhBcMVDbxC2oy5hyHl/adO9mMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEb MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMDkwMjAwMDAwMFoXDTE0MDkwMTIzNTk1 OVowggE3MQswCQYDVQQGEwJHQjEQMA4GA1UEERMHV0Y0IDRXQTEXMBUGA1UECBMOV2VzdCBZ b3Jrc2hpcmUxEjAQBgNVBAcTCVdha2VmaWVsZDEUMBIGA1UECRMLR3JhbmdlIE1vb3IxHzAd BgNVBAkTFjg5IEdyZWVuZmllbGQgQ3Jlc2NlbnQxFzAVBgNVBAoTDkdyaWRtZXJnZSBMdGQu MTQwMgYDVQQLEytJc3N1ZWQgdGhyb3VnaCBHcmlkbWVyZ2UgTHRkLiBFLVBLSSBNYW5hZ2Vy MR8wHQYDVQQLExZDb3Jwb3JhdGUgU2VjdXJlIEVtYWlsMRYwFAYDVQQDEw1Sb2JlcnQgQ3Jh Z2llMSowKAYJKoZIhvcNAQkBFhtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtxOGq8t5ZTVDVkmadv7ZRBLA5ApaiTcDUzCTn zYB2/BoBDIEWWI/InSRcmq3A0Ghm+T7dYmvRADllGv4nTHexdWlzFp2iM/Yc3PLWCyAO0gYb yW2hTi+ZfUDwFOU4hRP4+Dyn9tKu7FXS/PQJHyGjaGxHRmLm9T6tAo2ZuC59uRaGVCcwRiOS d6axwtB/DVhnP3S1rrt2g0O6MXLr5fojToemO52AxjHxt2w1LnFUUXC4EDV6o1Ctr7EvOEI5 5f088H/Mrryp02GueLdY9gb0SFK3gPOT7EjP2GPvCtRkhVcNM+xjyptRIFWnCbMjmUIc+DO6 sfU4rtbCCkNKyXmnAgMBAAGjggHVMIIB0TAfBgNVHSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBb vHnFezAdBgNVHQ4EFgQUEI5c0f6UObxT2DLdvdtG+vG8qCswDgYDVR0PAQH/BAQDAgWgMAwG A1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQMFMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEB BHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50 QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMCYGA1UdEQQfMB2BG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdl LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAPpv87QuQ9q+RHhmeirGDQB3szd24Obi7N+uVfh5y CrnoJx3B37dNrLPsTB6PfTChUyZMqQD80pFoJ3TBUz3yx4X+hmNco7ujVIfbuKBGcZJaMKhZ ex3AkZ9ltie9wgiGGzEmgI81t5JHsLQ8AUMqw/fGsnIwcyWMgmyhFtm79+dg3IVaH05d/t9g k4aYoMoCFJptQZ+Fju6a9T139hOqjTZDpjMLt3jM80bVrvkC4dIRyF/oZ0qrJwbfwjnL2OUN ph9eymhLc+VM0Ih5k41s5IxmB+2c0RUqr5JbK0WrIb/z53Cmb9rXYox7HknyIfBpQqP77Y7a sAU2MMOpel4RijGCBAwwggQIAgEBMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0Eg TGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9mMAkGBSsOAwIaBQCgggI4MBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQxMDExMzgzMlowIwYJKoZI hvcNAQkEMRYEFCMJHf56eIUHvvnUF3em28EvBgS0MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDCBuQYJKwYBBAGCNxAEMYGrMIGoMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD VQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9mMIG7BgsqhkiG 9w0BCRACCzGBq6CBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3 BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0BAQEFAASCAQB5DmbKeZkaDLXRCy+02Vw2 347Cji+LBK3SWxBD9kImndnoS0V6eLeo4VGiD0WQGsnIP8QffwB6HGsnb6k+wjm8COA1jblu wCrE0rOdsBtHMXDaORQJuCe9tNXIVssdEkbTGU0ZXGmkxTicjNnTHOBVjvjBqcEd4JbYz0NR 0fhXugweMcnwn/3W+Vux4finB7bLSf4fVDSaluoao08Y5TV03Mx0h7OvacG4HFYaa1uoYgBp n1wRESpqiLg5XsZUiA9+KYUrCrt5an7asjlE17/7XeRj6vA6NNvxazct+xUQCcxkQ6gSqNgB lkOXwa8UVliG5bxlRUTcFmaZCDiYOXqeAAAAAAAA --------------ms060706000803070005020404-- From matthieu.vial@non.schneider-electric.com Tue Apr 10 06:09:38 2012 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 9DF7B11E8072; Tue, 10 Apr 2012 06:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.514 X-Spam-Level: X-Spam-Status: No, score=-3.514 tagged_above=-999 required=5 tests=[AWL=-0.915, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJ4-cRFHu5Pn; Tue, 10 Apr 2012 06:09:38 -0700 (PDT) Received: from mailX04.eud.schneider-electric.com (mailx04.eud.schneider-electric.com [205.167.7.39]) by ietfa.amsl.com (Postfix) with ESMTP id 00EB121F85F6; Tue, 10 Apr 2012 06:09:38 -0700 (PDT) Received: from ATEUI01.schneider-electric.com ([10.198.14.9]) by mailX04.eud.schneider-electric.com with ESMTP id 2012041015093568-81519 ; Tue, 10 Apr 2012 15:09:35 +0200 In-Reply-To: <4F841BB8.10802@gridmerge.com> To: robert.cragie@gridmerge.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 From: matthieu.vial@non.schneider-electric.com Message-ID: Date: Tue, 10 Apr 2012 15:09:35 +0200 X-MIMETrack: Serialize by Router on ATEUI01.Schneider-Electric.com/T/SVR/Schneider at 10/04/2012 15:10:39, Serialize complete at 10/04/2012 15:10:39, Itemize by SMTP Server on AXEU4OUT.schneider-electric.com/X/SVR/SEIxtra at 10/04/2012 15:09:35, Serialize by Router on AXEU4OUT.schneider-electric.com/X/SVR/SEIxtra at 10/04/2012 15:09:37, Serialize complete at 10/04/2012 15:09:37 Content-Type: text/plain; charset="US-ASCII" Cc: core-bounces@ietf.org, core@ietf.org Subject: Re: [core] Sleepy devices + observer model X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 10 Apr 2012 13:09:38 -0000 Robert, >the basic CoAP protocol need not be extended and that it can be >used to represent common function sets as is and I think we are in >agreement there Yes we are. >The idea of using design patterns in this context is to >generalize patterns which represent collaborating resources in a >homogeneous way; a kind of "middleware" which can be used across >different applications. So whilst they could be developed solely within >an application profile, it is likely that repetition will occur across >application profiles where functions are almost the same but developed >slightly differently. Hence suggesting using layers of abstraction. If I understand you right, you want to define an abstract relation between 2 resources to create an interaction between those resources. The relation could be named "binding" for example. Then the binding relation could be implemented using Observe or any other relevant messaging pattern. This is definitively something that should be worked out in core-interfaces. Matthieu From hartke@tzi.org Tue Apr 10 21:31:35 2012 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 1F80F11E8096 for ; Tue, 10 Apr 2012 21:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlPgxY74VO-w for ; Tue, 10 Apr 2012 21:31:34 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 8521611E8079 for ; Tue, 10 Apr 2012 21:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3B4VQI5005368 for ; Wed, 11 Apr 2012 06:31:26 +0200 (CEST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E6F7D74 for ; Wed, 11 Apr 2012 06:31:25 +0200 (CEST) Received: by vcbfk13 with SMTP id fk13so409217vcb.31 for ; Tue, 10 Apr 2012 21:31:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.178.98 with SMTP id cx2mr5713249vdc.112.1334118684488; Tue, 10 Apr 2012 21:31:24 -0700 (PDT) Received: by 10.220.37.199 with HTTP; Tue, 10 Apr 2012 21:31:24 -0700 (PDT) Date: Wed, 11 Apr 2012 06:31:24 +0200 Message-ID: From: Klaus Hartke To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [core] draft-ietf-core-block-08 - Response matching rules X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 11 Apr 2012 04:31:35 -0000 The normal rules for matching responses to requests are that the IP address, port, security context and token must match. The Block options extend this, but it's not explicitly stated how. There are numerous cases where the response does not literally echo the Block options in the request, including: - A request without Block2 Option can result in matching response with Block2 Option. - A request with Block2 Option can result in a matching response without Block2 Option. - A request with Block2 Option can result in a matching response with a different Block2 Option. - A request with Block1 and Block2 Option can result in a matching response without Block2 Option. - A request with Block1 Option can result in a matching response with both Block1 and Block2 Option. - ... So, what are the exact rules for matching a response to a request when -block is involved? Related questions: * Is a client required to start an up/download at block number 0? * Does an error response have to include Block options (so it can be matched to its request)? * Does a Block option in descriptive usage in an error response describe the error payload or does it describe the payload that would have been returned if the request was successful? Klaus From hartke@tzi.org Tue Apr 10 21:32:03 2012 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 137A211E8151 for ; Tue, 10 Apr 2012 21:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zoGcTtlIEfCW for ; Tue, 10 Apr 2012 21:32:01 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 189FF11E813E for ; Tue, 10 Apr 2012 21:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3B4VnfB005505 for ; Wed, 11 Apr 2012 06:31:49 +0200 (CEST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id DAC9675 for ; Wed, 11 Apr 2012 06:31:48 +0200 (CEST) Received: by vcbfk13 with SMTP id fk13so409379vcb.31 for ; Tue, 10 Apr 2012 21:31:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.174.211 with SMTP id bu19mr5762694vdc.95.1334118707652; Tue, 10 Apr 2012 21:31:47 -0700 (PDT) Received: by 10.220.37.199 with HTTP; Tue, 10 Apr 2012 21:31:47 -0700 (PDT) Date: Wed, 11 Apr 2012 06:31:47 +0200 Message-ID: From: Klaus Hartke To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [core] draft-ietf-core-block-08 - Tokens in requests X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 11 Apr 2012 04:32:03 -0000 Does the client need to use the same token in each request when up- or downloading a representation in multiple parts? Most if not all implementations with support for Block1 at the Plugtest seemed to assume this. However, the only statements in the draft regarding tokens are that (a) the client MAY use non-empty tokens and (b) if the client does multiple unrelated uploads at the same time, it SHOULD use different tokens. Klaus From hartke@tzi.org Tue Apr 10 22:25:56 2012 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 21B1A21F86E4 for ; Tue, 10 Apr 2012 22:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbGL4W3lObaP for ; Tue, 10 Apr 2012 22:25:55 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 54E1821F85B4 for ; Tue, 10 Apr 2012 22:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3B4Y7kf006186 for ; Wed, 11 Apr 2012 06:34:07 +0200 (CEST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D870379 for ; Wed, 11 Apr 2012 06:34:06 +0200 (CEST) Received: by vbbez10 with SMTP id ez10so409131vbb.31 for ; Tue, 10 Apr 2012 21:34:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.79.134 with SMTP id p6mr6990468vck.51.1334118845657; Tue, 10 Apr 2012 21:34:05 -0700 (PDT) Received: by 10.220.37.199 with HTTP; Tue, 10 Apr 2012 21:34:05 -0700 (PDT) Date: Wed, 11 Apr 2012 06:34:05 +0200 Message-ID: From: Klaus Hartke To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [core] draft-ietf-core-coap-09 - Critical options with default values X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 11 Apr 2012 05:25:56 -0000 Here's a fun question: Take an option that is defined both to be 'critical' and to have a default value. For example, Token, Uri-Host or Block2. How does a recipient that does not recognize the option know the default value if the option is not present in a message? 'Critical' means 'this message makes no sense if you don't recognize this option'. Consequently, if the option is not present, it is critical that the recipient knows and understands the default value, otherwise the message makes no sense. Klaus From hartke@tzi.org Tue Apr 10 22:25:58 2012 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 00E0821F86FC for ; Tue, 10 Apr 2012 22:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJZkVFgGypnH for ; Tue, 10 Apr 2012 22:25:57 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 356D721F86E4 for ; Tue, 10 Apr 2012 22:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3B4W6pD005684 for ; Wed, 11 Apr 2012 06:32:06 +0200 (CEST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 638DA76 for ; Wed, 11 Apr 2012 06:32:06 +0200 (CEST) Received: by vcbfk13 with SMTP id fk13so409515vcb.31 for ; Tue, 10 Apr 2012 21:32:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.27.69 with SMTP id r5mr5715303vdg.129.1334118725178; Tue, 10 Apr 2012 21:32:05 -0700 (PDT) Received: by 10.220.37.199 with HTTP; Tue, 10 Apr 2012 21:32:05 -0700 (PDT) Date: Wed, 11 Apr 2012 06:32:05 +0200 Message-ID: From: Klaus Hartke To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [core] draft-ietf-core-block-08 - Block ordering X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 11 Apr 2012 05:25:58 -0000 Is a client allowed to up/download multiple blocks of the same representation concurrently? Or does it have to wait for the response before it up/downloads the next block? Do blocks have to be up/downloaded with strictly increasing block numbers? If blocks do not need to be uploaded with strictly increasing block numbers, should the client set the M in the request with the highest block number or in the last request it sends? Use case: Step 1. The client uploads the first block to check if the server supports block-wise transfers. Step 2. The client uploads the last block to check if the server is willing to accept a representation of this size. Step 3. The client concurrently uploads all blocks in between, with the M bit unset in the second-to-last block. Klaus From hartke@tzi.org Tue Apr 10 22:25:58 2012 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 E5AD621F86FD for ; Tue, 10 Apr 2012 22:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6so+Fsilcgbd for ; Tue, 10 Apr 2012 22:25:58 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 227AE21F86E4 for ; Tue, 10 Apr 2012 22:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3B4XSsN005984 for ; Wed, 11 Apr 2012 06:33:28 +0200 (CEST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C276978 for ; Wed, 11 Apr 2012 06:33:27 +0200 (CEST) Received: by vcbfk13 with SMTP id fk13so410080vcb.31 for ; Tue, 10 Apr 2012 21:33:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.4.75 with SMTP id 11mr7000948vcq.61.1334118806525; Tue, 10 Apr 2012 21:33:26 -0700 (PDT) Received: by 10.220.37.199 with HTTP; Tue, 10 Apr 2012 21:33:26 -0700 (PDT) Date: Wed, 11 Apr 2012 06:33:26 +0200 Message-ID: From: Klaus Hartke To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [core] draft-ietf-core-block-08 - CoAP Block vs HTTP Range X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 11 Apr 2012 05:25:59 -0000 Just an interesting little detail I noticed: The Block1 and Block2 options change between descriptive usage and control usage depending on whether they appear in a request or a response: * Block1 in a request - descriptive usage (describes the payload of the request) * Block2 in a request - control usage (controls the payload of the response) * Block1 in a response - control usage (controls the payload of the request) * Block2 in a response - descriptive usage (describes the payload of the response) HTTP has something similar to Block2 with the Range/Content-Range header fields: * Range in a request - control usage (controls the payload of the response) * Content-Range in a response - descriptive usage (describes the payload of the response) So a more intuitive alternative to Block1 and Block2 could be a Block and a Content-Block option: * Block in a request - control usage (controls the payload of the response) * Block in a response - control usage (controls the payload of the request) * Content-Block in a request - descriptive usage (describes the payload of the request) * Content-Block in a response - descriptive usage (describes the payload of the response) Klaus From hartke@tzi.org Tue Apr 10 22:26:00 2012 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 0B5E321F8701 for ; Tue, 10 Apr 2012 22:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJfMOwmE3K2w for ; Tue, 10 Apr 2012 22:25:56 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 477B621F85B4 for ; Tue, 10 Apr 2012 22:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3B4Wa01005847 for ; Wed, 11 Apr 2012 06:32:36 +0200 (CEST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A1FB277 for ; Wed, 11 Apr 2012 06:32:36 +0200 (CEST) Received: by vcbfk13 with SMTP id fk13so409712vcb.31 for ; Tue, 10 Apr 2012 21:32:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.178.98 with SMTP id cx2mr5714248vdc.112.1334118755424; Tue, 10 Apr 2012 21:32:35 -0700 (PDT) Received: by 10.220.37.199 with HTTP; Tue, 10 Apr 2012 21:32:35 -0700 (PDT) Date: Wed, 11 Apr 2012 06:32:35 +0200 Message-ID: From: Klaus Hartke To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [core] draft-ietf-core-block-08 - Caching X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 11 Apr 2012 05:26:00 -0000 A few questions related to caching: * Can blocks be individually cached or is it expected that a cache obtains the complete representation before it serves parts of it? * What are the rules for using a cached block to satisfy a request that is presented to a cache? * Can different blocks have different Max-Age values? What happens when blocks overlap? Does a response with a block update the freshness of the complete representation? * Can individual blocks be validated? Does validating a single block validate the complete representation? * Does a response with Block1 Option in control usage with the M bit set invalidate cached responses for the target URI? Klaus From cabo@tzi.org Tue Apr 10 22:52:35 2012 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 9E91521F84FB for ; Tue, 10 Apr 2012 22:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7Jx1H6BdJBU for ; Tue, 10 Apr 2012 22:52:35 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id CF3B421F84FA for ; Tue, 10 Apr 2012 22:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3B5qRNG001570 for ; Wed, 11 Apr 2012 07:52:27 +0200 (CEST) Received: from [192.168.217.105] (p5489A66F.dip.t-dialin.net [84.137.166.111]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E1B1799; Wed, 11 Apr 2012 07:52:26 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Wed, 11 Apr 2012 07:52:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <54E1D092-70BF-46CC-8CCE-F53F3F6B5CB3@tzi.org> References: To: Klaus Hartke X-Mailer: Apple Mail (2.1257) Cc: core@ietf.org Subject: Re: [core] draft-ietf-core-coap-09 - Critical options with default values X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 11 Apr 2012 05:52:35 -0000 On Apr 11, 2012, at 06:34, Klaus Hartke wrote: > Here's a fun question: >=20 > Take an option that is defined both to be 'critical' and to have a > default value. For example, Token, Uri-Host or Block2. >=20 > How does a recipient that does not recognize the option know the > default value if the option is not present in a message? When defining a critical option with a default value, the default value = has to be chosen such that this situation works right. > 'Critical' means 'this message makes no sense if you don't recognize > this option'. Consequently, if the option is not present, it is > critical that the recipient knows and understands the default value, > otherwise the message makes no sense. Exactly. So the default value needs to be chosen such that an endpoint that does = not implement the option does the right thing. This requirement on new critical options with default values seems = rather obvious to me. Do you think that we need to expend additional text? Gr=FC=DFe, Carsten From cabo@tzi.org Wed Apr 11 03:30:07 2012 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 B813C11E8096 for ; Wed, 11 Apr 2012 03:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HmAdbZzTn+k for ; Wed, 11 Apr 2012 03:30:07 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id D5D2B11E8086 for ; Wed, 11 Apr 2012 03:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3BATuvG020193 for ; Wed, 11 Apr 2012 12:29:56 +0200 (CEST) Received: from dynamic-218-h.informatik.uni-bremen.de (dynamic-218-h.informatik.uni-bremen.de [134.102.218.207]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41CA6284; Wed, 11 Apr 2012 12:29:56 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Wed, 11 Apr 2012 10:36:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4687320A-8864-47A9-BB10-B640F95A1306@tzi.org> References: To: Klaus Hartke X-Mailer: Apple Mail (2.1257) Cc: core@ietf.org Subject: Re: [core] draft-ietf-core-block-08 - CoAP Block vs HTTP Range X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 11 Apr 2012 10:30:07 -0000 > HTTP has something similar to Block2 with the Range/Content-Range > header fields: >=20 > * Range in a request - control usage (controls the payload of the = response) > * Content-Range in a response - descriptive usage (describes the > payload of the response) Do we have to discuss this in the -block document or should this go into = the HTTP mapping best practices? (Or is this just an observation that can stay in the mailing list?) > So a more intuitive alternative to Block1 and Block2 could be a Block > and a Content-Block option: >=20 > * Block in a request - control usage (controls the payload of the = response) > * Block in a response - control usage (controls the payload of the = request) > * Content-Block in a request - descriptive usage (describes the > payload of the request) > * Content-Block in a response - descriptive usage (describes the > payload of the response) I think this variation may be more intuitive if you are building a = mapper. The current setup has the advantage that it clearly separates between = the usage for request and response payloads, which are the more likely = granularity of implementing/not implementing something. Gr=FC=DFe, Carsten From cabo@tzi.org Wed Apr 11 03:30:07 2012 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 C420F11E8086 for ; Wed, 11 Apr 2012 03:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ii05OZzyD9d for ; Wed, 11 Apr 2012 03:30:07 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id D5A5411E808E for ; Wed, 11 Apr 2012 03:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3BATuCi020197 for ; Wed, 11 Apr 2012 12:29:56 +0200 (CEST) Received: from dynamic-218-h.informatik.uni-bremen.de (dynamic-218-h.informatik.uni-bremen.de [134.102.218.207]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 744A5285; Wed, 11 Apr 2012 12:29:56 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Wed, 11 Apr 2012 11:09:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Klaus Hartke X-Mailer: Apple Mail (2.1257) Cc: core@ietf.org Subject: Re: [core] draft-ietf-core-block-08 - Block ordering X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 11 Apr 2012 10:30:07 -0000 On Apr 11, 2012, at 06:32, Klaus Hartke wrote: > Is a client allowed to up/download multiple blocks of the same > representation concurrently? Or does it have to wait for the response > before it up/downloads the next block? There is nothing in block-08 that would allow out-of-order accesses. There is also nothing in a stateless implementation that would disallow = this. (A stateless server simply has no idea about whether access are = in-order.) But a client can't rely on a server implementation being stateless. > Do blocks have to be up/downloaded with strictly increasing block = numbers? It is not so much that the block numbers have to increase, but the = blocks need to fit together (see examples). > If blocks do not need to be uploaded with strictly increasing block > numbers, should the client set the M in the request with the highest > block number or in the last request it sends? (Clear the M bit, you mean.) That is an interesting question for a future extension we might want to = come up with. > Use case: > Step 1. The client uploads the first block to check if the server > supports block-wise transfers. Yes. > Step 2. The client uploads the last block to check if the server is > willing to accept a representation of this size. Well, we have the size option for that, now. > Step 3. The client concurrently uploads all blocks in between, with > the M bit unset in the second-to-last block. Makes a lot of sense. In particular, you could use the shared state between all the block = transfers to do better congestion control than lock-step. So, for me the question is: 1 Should we require servers to support this out-of-order behavior? No. 2 Should we require servers to actively detect and thwart this behavior? = Certainly not. 3 Should clients expect this behavior to work? No (since we don't = require it from servers). 4 Should clients expect this behavior to have the intended effect if it = does work (i.e., elicits 2.xx responses)? I think so. 1 to 3 just mean the protocol does not make any promises. 4 may possibly require new text, although to me it is kind of obvious = that, when a server gets a request that it can't process, that it does = not send an affirmative response. Gr=FC=DFe, Carsten From cabo@tzi.org Wed Apr 11 04:04:16 2012 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 D1D5411E8086 for ; Wed, 11 Apr 2012 04:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfgwO1XooWAO for ; Wed, 11 Apr 2012 04:04:16 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 043CC11E8075 for ; Wed, 11 Apr 2012 04:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3BB47oI008037 for ; Wed, 11 Apr 2012 13:04:07 +0200 (CEST) Received: from dynamic-218-h.informatik.uni-bremen.de (dynamic-218-h.informatik.uni-bremen.de [134.102.218.207]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id F1D792CC; Wed, 11 Apr 2012 13:04:06 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Wed, 11 Apr 2012 13:04:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Klaus Hartke X-Mailer: Apple Mail (2.1257) Cc: core@ietf.org Subject: Re: [core] draft-ietf-core-block-08 - Caching X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 11 Apr 2012 11:04:16 -0000 On Apr 11, 2012, at 06:32, Klaus Hartke wrote: > A few questions related to caching: >=20 > * Can blocks be individually cached or is it expected that a cache > obtains the complete representation before it serves parts of it? I'm not sure you would "cache blocks"; you would cache partial = representations. I don't see a reason to wait for the complete representation. So, e.g., a proxy could respond with the first block (say, 128-size) as = soon as it has received the first two blocks (say, 64-size) from the = origin. > * What are the rules for using a cached block to satisfy a request > that is presented to a cache? The same as usual, maybe augmented with "you can't use what you don't = have"? > * Can different blocks have different Max-Age values? Certainly (this is hard to avoid unless all responses are generated at = the same time). The question is what the cache does with the re-combined representation; = see below. > What happens > when blocks overlap? Nothing special, I think. Newer wins. > Does a response with a block update the freshness > of the complete representation? Good question. Clearly, any Etag present pertains to the whole resource. The question would be what it means to obtain a block with a longer = max-age than the other blocks in the cache, but without an Etag. I would assume that servers that serve large resources that change will = provide an Etag. So I think it is OK to optimize for rarely changing resources. = Re-freshening the entire representation to the max-age of the freshest = block should be easy to implement and provide better caching. The danger is, of course, that this re-freshening behavior, in = combination with a server that does serve a changing resource without an = Etag, might perpetuate stale content. > * Can individual blocks be validated? Etags validate the whole resource representation. > Does validating a single block > validate the complete representation? If you are talking about Etags: Yes. > * Does a response with Block1 Option in control usage with the M bit > set invalidate cached responses for the target URI? That sounds prudent to me. Some of this probably should be specified in further detail. Are you able to supply text for a subsection on caching to be added to = section 2 of -block? Gr=FC=DFe, Carsten From cabo@tzi.org Wed Apr 11 04:13:59 2012 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 2DCB311E80D6 for ; Wed, 11 Apr 2012 04:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQ-SqeszhfRA for ; Wed, 11 Apr 2012 04:13:58 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id E57DF11E80A3 for ; Wed, 11 Apr 2012 04:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3BBDpiR013263 for ; Wed, 11 Apr 2012 13:13:51 +0200 (CEST) Received: from dynamic-218-h.informatik.uni-bremen.de (dynamic-218-h.informatik.uni-bremen.de [134.102.218.207]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 0A5782E0; Wed, 11 Apr 2012 13:13:51 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Wed, 11 Apr 2012 13:13:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7AFA68E3-5481-40E9-B541-7524DFA05C60@tzi.org> References: To: Klaus Hartke X-Mailer: Apple Mail (2.1257) Cc: core@ietf.org Subject: Re: [core] draft-ietf-core-block-08 - Tokens in requests X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 11 Apr 2012 11:13:59 -0000 On Apr 11, 2012, at 06:31, Klaus Hartke wrote: > Does the client need to use the same token in each request when up- or > downloading a representation in multiple parts? Downloading (GET with Block2): No. Why? Uploading (PUT, POST with Block1): Yes, if server answers with M=3D1.=20 (Not needed otherwise.) > Most if not all implementations with support for Block1 at the > Plugtest seemed to assume this. I didn't count them. Yes, there were some prominent ones with = interesting assumptions about Tokens, whether wrt Blocks or in some = other ways. > However, the only statements in the draft regarding tokens are that > (a) the client MAY use non-empty tokens and (Which is not new information.) > (b) if the client does multiple unrelated uploads at the same time, it > SHOULD use different tokens. Yes. There is also: In this case, when reassembling the representation from the blocks being exchanged to enable atomic processing, the reassembler MUST compare any Token Options present (and, as usual, taking an absent Token Option to default to the empty Token). If atomic processing is not desired, there is no need to process the Token Option (but it is still returned in the response as usual). (which I think is the juicy bit.) In the preceding If multiple concurrently proceeding block-wise request payload transfer (e.g., PUT or POST) operations are possible, the requester SHOULD use the Token Option to clearly separate the different sequences. =20 I now think that "use the Token Option to" is confusing language. This is not about sending a non-default value. As the Token Option has a default value, there is no way to not "use" = it. What was meant was not that you go ahead and send non-default values = (that isn't even always necessary), but that you use it in a way that = different Block1 sequences between the same endpoint pairs have = different Token option values. This apparently needs to be clarified. Gr=FC=DFe, Carsten From cabo@tzi.org Wed Apr 11 04:28:35 2012 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 B70D221F858D for ; Wed, 11 Apr 2012 04:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gq6309GoT4S7 for ; Wed, 11 Apr 2012 04:28:35 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id BE45621F8584 for ; Wed, 11 Apr 2012 04:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3BBSEai021574 for ; Wed, 11 Apr 2012 13:28:14 +0200 (CEST) Received: from dynamic-218-h.informatik.uni-bremen.de (dynamic-218-h.informatik.uni-bremen.de [134.102.218.207]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id CBD742FC; Wed, 11 Apr 2012 13:28:14 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Wed, 11 Apr 2012 13:28:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Klaus Hartke X-Mailer: Apple Mail (2.1257) Cc: core@ietf.org Subject: Re: [core] draft-ietf-core-block-08 - Response matching rules X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 11 Apr 2012 11:28:35 -0000 Ah, and now the fun part. On Apr 11, 2012, at 06:31, Klaus Hartke wrote: > The normal rules for matching responses to requests are that the IP > address, port, security context and token must match. The Block > options extend this, but it's not explicitly stated how. >=20 > There are numerous cases where the response does not literally echo > the Block options in the request, including: >=20 > - A request without Block2 Option can result in matching response with > Block2 Option. > - A request with Block2 Option can result in a matching response > without Block2 Option. > - A request with Block2 Option can result in a matching response with > a different Block2 Option. > - A request with Block1 and Block2 Option can result in a matching > response without Block2 Option. > - A request with Block1 Option can result in a matching response with > both Block1 and Block2 Option. > - ... >=20 > So, what are the exact rules for matching a response to a request when > -block is involved? This is not spelled out, but needs to be. The Block options have a default value, so I don't think we need to = discuss present and absent separately. I'd say that a response matches a request if the block number/szx = combination points to the same initial byte (this enables going from no = option to an option with block number 0 or from one szx to a different = szx). I'd still be happier if people were only invoking the special = "same-token" magic for those cases in the use of Block1 where this is = needed. (Maybe it was wrong to involve Token in atomic Block1 in the = first place. Hmm.) > Related questions: >=20 > * Is a client required to start an up/download at block number 0? See discussion about order in separate email. > * Does an error response have to include Block options (so it can be > matched to its request)? Now, that is an interesting question indeed. Given that Block is optional, but critical, the answer can't always be = yes (i.e., a "unknown critical option not supported" response shouldn't = have to carry Block1 or Block2 :-). That happens to match an initial blockwise request, but I think it would = be unwise to always rely on that. Some error messages will pertain to the option values given in the = request (e.g., if there were an "unknown Block number" error, that would = only make sense when it can be correlated to the request option). > * Does a Block option in descriptive usage in an error response > describe the error payload or does it describe the payload that would > have been returned if the request was successful? Good catch. We need to spell out more explicitly that Block2 options do not govern = error payloads (4.xx/5.xx). (The text currently talks about what they = mean for 2.xx only, but that is not enough.) Gr=FC=DFe, Carsten From ashwin.ietf@gmail.com Wed Apr 11 08:36:55 2012 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 4A16E21F84CE for ; Wed, 11 Apr 2012 08:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+iuPz0jNZuj for ; Wed, 11 Apr 2012 08:36:54 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A2C9521F84C5 for ; Wed, 11 Apr 2012 08:36:54 -0700 (PDT) Received: by iazz13 with SMTP id z13so1721309iaz.31 for ; Wed, 11 Apr 2012 08:36:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=oYazPaAR+hED26Qj2BmaRaTCLr933aQ+/F8pFHLAkyM=; b=joll2JHaT0XvJ5PyndFVzyPEXhXlcd6uhAL+8ae2yHMSLkjG6rLp2CXFUvuKxR5MOF nfLxau+BLh884y96bfT0+utocgBiY/G2MCUH8uriwylDcXqlEDcjjVFj8Keqadrl+ygt 08pM8gjLht26GwIQAnnEbfl/K+BAZh8ZVefohcXejue4+ZzZv6xNkJjpKlhku/itoYTS Y/xwxm2nhIr+HUY420ZWwLzBDvB4GmN/oP5dcO/Xy6xTcVha7+jl4nevGYfb7KbYJk2a IwRe0SL39KyE+w0+F9XL8YAzDQbMZWmoz0Lr8lEM8P9Sbc3+OcSuvJmzb7blST1sr3XF m2ag== MIME-Version: 1.0 Received: by 10.50.186.166 with SMTP id fl6mr6214608igc.47.1334158614345; Wed, 11 Apr 2012 08:36:54 -0700 (PDT) Received: by 10.64.15.41 with HTTP; Wed, 11 Apr 2012 08:36:54 -0700 (PDT) Date: Wed, 11 Apr 2012 08:36:54 -0700 Message-ID: From: Ashwin Sinha To: core@ietf.org Content-Type: multipart/alternative; boundary=14dae9340db14837b004bd690289 Subject: [core] draft-ietf-core-block-08 - Block Negotiation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 11 Apr 2012 15:43:19 -0000 --14dae9340db14837b004bd690289 Content-Type: text/plain; charset=ISO-8859-1 Hi, With regard to the negotiation mechanism mentioned in the draft, how about the case where initially both sides agree to say 64 bytes, then a couple of exchanges later want to reduce/increase the size. Also this might be an invalid question, the exchange is always a client-server model, there cannot be any proxies in between? If so can they modify this packet size, and how will this be handled. Regards, Ashwin --14dae9340db14837b004bd690289 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

With regard to the negotiation mechanism mentioned i= n the draft, how about the case where initially both sides agree to say 64 = bytes, then a couple of exchanges later want to reduce/increase the size.= =A0

Also this might be an invalid question, the exchange is= always a client-server model, there cannot be any proxies in between? If s= o can they modify this packet size, and how will this be handled.


Regards,
Ashwin
--14dae9340db14837b004bd690289-- From cabo@tzi.org Wed Apr 11 08:54:16 2012 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 DBB0611E8089 for ; Wed, 11 Apr 2012 08:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GatXJz-6zZDv for ; Wed, 11 Apr 2012 08:54:16 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id F11F311E8085 for ; Wed, 11 Apr 2012 08:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3BFs7Q4002041; Wed, 11 Apr 2012 17:54:07 +0200 (CEST) Received: from [10.0.1.3] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C51AE4E3; Wed, 11 Apr 2012 17:54:07 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Wed, 11 Apr 2012 17:54:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <12A89EC7-FD4B-41DE-BA70-D560ECEEDC60@tzi.org> References: To: Ashwin Sinha X-Mailer: Apple Mail (2.1257) Cc: core@ietf.org Subject: Re: [core] draft-ietf-core-block-08 - Block Negotiation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 11 Apr 2012 15:54:17 -0000 > With regard to the negotiation mechanism mentioned in the draft, how = about the case where initially both sides agree to say 64 bytes, then a = couple of exchanges later want to reduce/increase the size.=20 I'm not sure I understand the use case, but the client could e.g. switch = to the next smaller block size by doubling the block number. This is = not explicitly allowed by the protocol right now (so a client might = better be prepared for this to fail), but it is hard to implement the = protocol in such a way that this wouldn't work. > Also this might be an invalid question, the exchange is always a = client-server model, there cannot be any proxies in between? If so can = they modify this packet size, and how will this be handled. An intermediary could map a single client request to multiple requests = to the upstream server or v.v.; this is particularly easy with a caching = proxy. A very simple (stateless) intermediary would simply negotiate = down the block size to a value comfortable to both its client and the = origin server. The protocol only describes the interaction between = client and proxy and the interaction between proxy and origin server; it = is the job of the proxy to make sure the semantics are maintained. Gr=FC=DFe, Carsten From hartke@tzi.org Wed Apr 11 11:26:18 2012 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 6009221F8498 for ; Wed, 11 Apr 2012 11:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPAULJqrHhce for ; Wed, 11 Apr 2012 11:26:15 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id A5D4621F84B3 for ; Wed, 11 Apr 2012 11:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3BIQ0vT008575 for ; Wed, 11 Apr 2012 20:26:00 +0200 (CEST) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5C6EF54A for ; Wed, 11 Apr 2012 20:26:00 +0200 (CEST) Received: by dady13 with SMTP id y13so2151585dad.27 for ; Wed, 11 Apr 2012 11:25:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.73.138 with SMTP id l10mr40147374pbv.22.1334168758120; Wed, 11 Apr 2012 11:25:58 -0700 (PDT) Received: by 10.68.234.199 with HTTP; Wed, 11 Apr 2012 11:25:58 -0700 (PDT) In-Reply-To: <54E1D092-70BF-46CC-8CCE-F53F3F6B5CB3@tzi.org> References: <54E1D092-70BF-46CC-8CCE-F53F3F6B5CB3@tzi.org> Date: Wed, 11 Apr 2012 20:25:58 +0200 Message-ID: From: Klaus Hartke To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] draft-ietf-core-coap-09 - Critical options with default values X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 11 Apr 2012 18:26:18 -0000 On 11 April 2012 07:52, Carsten Bormann wrote: > So the default value needs to be chosen such that an endpoint that does not implement the option does the right thing. > > This requirement on new critical options with default values seems rather obvious to me. > Do you think that we need to expend additional text? Section 11.2 [1] includes guidelines for the review process that applies to future option number requests. If we can give objective guidelines for deciding if a critical option with a default value does "the right thing", we should do it. Klaus [1] http://tools.ietf.org/html/draft-ietf-core-coap-09#section-11.2 From hartke@tzi.org Wed Apr 11 11:27:50 2012 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 7526D11E80BA for ; Wed, 11 Apr 2012 11:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1b0ddtbhb4I for ; Wed, 11 Apr 2012 11:27:50 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 9543411E8098 for ; Wed, 11 Apr 2012 11:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3BIRfZ0009194 for ; Wed, 11 Apr 2012 20:27:41 +0200 (CEST) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A194A54B for ; Wed, 11 Apr 2012 20:27:40 +0200 (CEST) Received: by dady13 with SMTP id y13so2154171dad.27 for ; Wed, 11 Apr 2012 11:27:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.195.163 with SMTP id if3mr40523935pbc.127.1334168858833; Wed, 11 Apr 2012 11:27:38 -0700 (PDT) Received: by 10.68.234.199 with HTTP; Wed, 11 Apr 2012 11:27:38 -0700 (PDT) In-Reply-To: References: Date: Wed, 11 Apr 2012 20:27:38 +0200 Message-ID: From: Klaus Hartke To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] draft-ietf-core-block-08 - Block ordering X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 11 Apr 2012 18:27:50 -0000 On 11 April 2012 11:09, Carsten Bormann wrote: > On Apr 11, 2012, at 06:32, Klaus Hartke wrote: > >> Is a client allowed to up/download multiple blocks of the same >> representation concurrently? Or does it have to wait for the response >> before it up/downloads the next block? > > There is nothing in block-08 that would allow out-of-order accesses. Section 2.1 gives detailed instructions on how to construct requests with Block options. Section 2.2 does not say a lot about what requests that could theoretically be constructed are allowed or not; I'd assume that everything that is syntactically possible is allowed unless it's explicitly forbidden. There does not seem to be any statement in the draft that forbids starting an up/download with a block number other than 0, or that forbids up/downloading blocks out of order. Klaus From hartke@tzi.org Wed Apr 11 11:28:40 2012 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 40ED511E80BA for ; Wed, 11 Apr 2012 11:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-UMb2PpKDju for ; Wed, 11 Apr 2012 11:28:39 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 0993C11E8098 for ; Wed, 11 Apr 2012 11:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3BISWsQ009562 for ; Wed, 11 Apr 2012 20:28:32 +0200 (CEST) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id F1D3854D for ; Wed, 11 Apr 2012 20:28:31 +0200 (CEST) Received: by dady13 with SMTP id y13so2155518dad.27 for ; Wed, 11 Apr 2012 11:28:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.138.170 with SMTP id qr10mr18736063pbb.148.1334168910085; Wed, 11 Apr 2012 11:28:30 -0700 (PDT) Received: by 10.68.234.199 with HTTP; Wed, 11 Apr 2012 11:28:30 -0700 (PDT) In-Reply-To: References: Date: Wed, 11 Apr 2012 20:28:30 +0200 Message-ID: From: Klaus Hartke To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] draft-ietf-core-block-08 - Caching X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 11 Apr 2012 18:28:40 -0000 On 11 April 2012 13:04, Carsten Bormann wrote: > On Apr 11, 2012, at 06:32, Klaus Hartke wrote: > >> * Can blocks be individually cached or is it expected that a cache >> obtains the complete representation before it serves parts of it? > > I'm not sure you would "cache blocks"; you would cache partial representations. > I don't see a reason to wait for the complete representation. > So, e.g., a proxy could respond with the first block (say, 128-size) as soon as it has received the first two blocks (say, 64-size) from the origin. > >> * What are the rules for using a cached block to satisfy a request >> that is presented to a cache? > > The same as usual, maybe augmented with "you can't use what you don't have"? The usual procedure is: - put the response into the cache as-is, i.e. without any reassembling; - use a stored response only if all options in the presented request are equal to the options in the request that caused the response to be stored, with the exception of the Token, Max-Age and ETag options. So currently each response containing a block is cached individually, and a stored response with Block2=0/0/64 that is the result of a request with Block2=0/0/128 cannot be used to satisfy a request with Block2=0/0/64. Klaus From hartke@tzi.org Wed Apr 11 11:29:28 2012 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 1579911E80C6 for ; Wed, 11 Apr 2012 11:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8rWyc7y6fWF for ; Wed, 11 Apr 2012 11:29:27 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 3C68411E80BA for ; Wed, 11 Apr 2012 11:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3BITKB6009903 for ; Wed, 11 Apr 2012 20:29:20 +0200 (CEST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 44D4554E for ; Wed, 11 Apr 2012 20:29:20 +0200 (CEST) Received: by pbbrq13 with SMTP id rq13so1544092pbb.31 for ; Wed, 11 Apr 2012 11:29:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.213.231 with SMTP id nv7mr18955242pbc.106.1334168958421; Wed, 11 Apr 2012 11:29:18 -0700 (PDT) Received: by 10.68.234.199 with HTTP; Wed, 11 Apr 2012 11:29:18 -0700 (PDT) In-Reply-To: <7AFA68E3-5481-40E9-B541-7524DFA05C60@tzi.org> References: <7AFA68E3-5481-40E9-B541-7524DFA05C60@tzi.org> Date: Wed, 11 Apr 2012 20:29:18 +0200 Message-ID: From: Klaus Hartke To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [core] draft-ietf-core-block-08 - Tokens in requests X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 11 Apr 2012 18:29:28 -0000 On 11 April 2012 13:13, Carsten Bormann wrote: > There is also: > > =A0 In this case, when reassembling the representation from > =A0 the blocks being exchanged to enable atomic processing, the > =A0 reassembler MUST compare any Token Options present (and, as usual, > =A0 taking an absent Token Option to default to the empty Token). =A0If > =A0 atomic processing is not desired, there is no need to process the > =A0 Token Option (but it is still returned in the response as usual). > > (which I think is the juicy bit.) The only situation in which the client is the reassembler, is when it downloads a representation in multiple parts. Of course it needs to compare the token in each response to the token it used in the request, otherwise it would not be able to match a response to its request. But there is no statement that requires a client to use a certain token in its requests. Klaus From hartke@tzi.org Wed Apr 11 11:30:48 2012 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 252B311E80BA for ; Wed, 11 Apr 2012 11:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0buvKqHP3+v for ; Wed, 11 Apr 2012 11:30:47 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFE611E8098 for ; Wed, 11 Apr 2012 11:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3BIUeEU011719 for ; Wed, 11 Apr 2012 20:30:40 +0200 (CEST) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 1D98354F for ; Wed, 11 Apr 2012 20:30:39 +0200 (CEST) Received: by dady13 with SMTP id y13so2158850dad.27 for ; Wed, 11 Apr 2012 11:30:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.221.227 with SMTP id qh3mr40042837pbc.43.1334169038279; Wed, 11 Apr 2012 11:30:38 -0700 (PDT) Received: by 10.68.234.199 with HTTP; Wed, 11 Apr 2012 11:30:38 -0700 (PDT) Date: Wed, 11 Apr 2012 20:30:38 +0200 Message-ID: From: Klaus Hartke To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [core] draft-ietf-core-block-08 - Sessions X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 11 Apr 2012 18:30:48 -0000 -block has the concept of a session, i.e. the first request of a blockwise transfer creates a context at the server in which further requests from the client are processed. A server MAY not actually have to implement this if it can satisfy all requests without this context, but it seems that a client MUST assume that a server creates one. What are the rules for matching an incoming request to a session? Can a client have multiple up/download sessions with the same resource at the same time? When does a session end? What happens if a client creates a session but never sends/retrieves the last block? Should the duration for which the server is willing to keep the session open before it times out be communicated to the client? Should the client be able to request a minimum duration for which the server should keep the session open? Use case: the client needs a significant amount of time to process a downloaded block/construct the next block to upload/obtain the next block from a downstream client; it would be bad if the server timed out the session halfway through. Should the client have the ability to cancel a session? Klaus From cabo@tzi.org Wed Apr 11 14:20:35 2012 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 E595721F848C for ; Wed, 11 Apr 2012 14:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.512 X-Spam-Level: X-Spam-Status: No, score=-106.512 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tQEQw5Ozwta for ; Wed, 11 Apr 2012 14:20:33 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 46A7821F848A for ; Wed, 11 Apr 2012 14:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3BLKNcS014799 for ; Wed, 11 Apr 2012 23:20:23 +0200 (CEST) Received: from [192.168.217.105] (p5489ADE7.dip.t-dialin.net [84.137.173.231]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C0E3F5AE; Wed, 11 Apr 2012 23:20:22 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Wed, 11 Apr 2012 23:20:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Klaus Hartke X-Mailer: Apple Mail (2.1257) Cc: core@ietf.org Subject: Re: [core] draft-ietf-core-block-08 - Sessions X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 11 Apr 2012 21:20:35 -0000 On Apr 11, 2012, at 20:30, Klaus Hartke wrote: > -block has the concept of a session, I don't think so. At least, I don't find that word in -block-08. > i.e. the first request of a > blockwise transfer creates a context at the server in which further > requests from the client are processed. A server MAY not actually have > to implement this if it can satisfy all requests without this context, > but it seems that a client MUST assume that a server creates one. There is a concept called atomic processing (for Block1). I think we just discussed that the text for this needs improvement. For Block2, there is text that says: If the ETag Options do not match in a GET transfer, the requester has the option of attempting to retrieve fresh values for the blocks it retrieved first. To minimize the resulting inefficiency, the server MAY cache the current value of a representation for an ongoing sequence of requests. The client MAY facilitate identifying the sequence by using the Token Option with a non-default value. Note well that this specification makes no requirement for the server to establish any state; however, servers that offer quickly changing resources may thereby make it impossible for a client to ever retrieve a consistent set of blocks. I think you are conflating the two mechanisms and calling both session. > What are the rules for matching an incoming request to a session? For atomic processing of Block1, the current text of the rule is: In this case, when reassembling the representation from the blocks being exchanged to enable atomic processing, the reassembler MUST compare any Token Options present (and, as usual, taking an absent Token Option to default to the empty Token). If atomic processing is not desired, there is no need to process the Token Option (but it is still returned in the response as usual). For Block2, any such cache mechanism is indexed by the Token, see above. > Can a client have multiple up/download sessions with the same resource > at the same time? That is the point of the above language for Block1. Maybe it can be questioned whether for Block1 that isn't a bit of a = fringe case. A better rule might be simply not to allow multiple Block1 sequences to = the same resource in parallel. Similarly, a server might simply remember a single cached value for an = endpoint for Block2 access to a rapidly changing resource. For Block1, having multiple atomic PUTs going on in parallel from one = endpoint is not very useful. A point could be made that this is more useful with POST. > When does a session end? What happens if a client creates a session > but never sends/retrieves the last block? The server will have to give up on the state at some point. This is easy for the Block2 cache. =20 For atomic Block1, giving up the assembled state is a bit more = heavyweight.=20 > Should the duration for which the server is willing to keep the > session open before it times out be communicated to the client? Being able to do this is probably a good idea. I think we should = discuss this in the general context of the Patience/Pledge proposals. > Should the client be able to request a minimum duration for which the > server should keep the session open? Use case: the client needs a > significant amount of time to process a downloaded block/construct the > next block to upload/obtain the next block from a downstream client; > it would be bad if the server timed out the session halfway through. Ditto. > Should the client have the ability to cancel a session? Good point. I'm not quite sure of the use case, but it would be "nice" = for a client to be able to indicate to the server that it does not = intend to make any further use of any state assembled (Block1)/cached = (Block2). (However, note that we have no other mechanism in place to = "cancel" any other kind of cache entry.) Closing a DTLS connection = obviously is one such indication, but may be a bit heavyweight (and = doesn't work for NoSec). Gr=FC=DFe, Carsten From cabo@tzi.org Wed Apr 11 14:22:28 2012 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 D826321F848F for ; Wed, 11 Apr 2012 14:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.496 X-Spam-Level: X-Spam-Status: No, score=-106.496 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAvTaO9epsFA for ; Wed, 11 Apr 2012 14:22:27 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id E1C1321F848B for ; Wed, 11 Apr 2012 14:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3BLMGl9015305 for ; Wed, 11 Apr 2012 23:22:16 +0200 (CEST) Received: from [192.168.217.105] (p5489ADE7.dip.t-dialin.net [84.137.173.231]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 8925D5AF; Wed, 11 Apr 2012 23:22:16 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Wed, 11 Apr 2012 23:22:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5AE36B99-3D0D-469F-A987-D593764EADF7@tzi.org> References: <7AFA68E3-5481-40E9-B541-7524DFA05C60@tzi.org> To: Klaus Hartke X-Mailer: Apple Mail (2.1257) Cc: core@ietf.org Subject: Re: [core] draft-ietf-core-block-08 - Tokens in requests X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 11 Apr 2012 21:22:29 -0000 On Apr 11, 2012, at 20:29, Klaus Hartke wrote: > On 11 April 2012 13:13, Carsten Bormann wrote: >> There is also: >>=20 >> In this case, when reassembling the representation from >> the blocks being exchanged to enable atomic processing, the >> reassembler MUST compare any Token Options present (and, as usual, >> taking an absent Token Option to default to the empty Token). If >> atomic processing is not desired, there is no need to process the >> Token Option (but it is still returned in the response as usual). >>=20 >> (which I think is the juicy bit.) >=20 > The only situation in which the client is the reassembler, is when it > downloads a representation in multiple parts. Of course it needs to > compare the token in each response to the token it used in the > request, otherwise it would not be able to match a response to its > request. But there is no statement that requires a client to use a > certain token in its requests. This is in the context of Block1 ("block-wise request payload = transfer"), so the server is the reassembler. Gr=FC=DFe, Carsten From cabo@tzi.org Wed Apr 11 14:25:02 2012 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 40C8021F849A for ; Wed, 11 Apr 2012 14:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.482 X-Spam-Level: X-Spam-Status: No, score=-106.482 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVIds50WEvIo for ; Wed, 11 Apr 2012 14:25:01 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 70B8C21F8499 for ; Wed, 11 Apr 2012 14:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3BLOsKO015857 for ; Wed, 11 Apr 2012 23:24:54 +0200 (CEST) Received: from [192.168.217.105] (p5489ADE7.dip.t-dialin.net [84.137.173.231]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3CC7A5B1; Wed, 11 Apr 2012 23:24:54 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Wed, 11 Apr 2012 23:24:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <61EA96A7-E349-4493-A616-23693B3FB297@tzi.org> References: To: Klaus Hartke X-Mailer: Apple Mail (2.1257) Cc: core@ietf.org Subject: Re: [core] draft-ietf-core-block-08 - Caching X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 11 Apr 2012 21:25:02 -0000 On Apr 11, 2012, at 20:28, Klaus Hartke wrote: > On 11 April 2012 13:04, Carsten Bormann wrote: >> On Apr 11, 2012, at 06:32, Klaus Hartke wrote: >>=20 >>> * Can blocks be individually cached or is it expected that a cache >>> obtains the complete representation before it serves parts of it? >>=20 >> I'm not sure you would "cache blocks"; you would cache partial = representations. >> I don't see a reason to wait for the complete representation. >> So, e.g., a proxy could respond with the first block (say, 128-size) = as soon as it has received the first two blocks (say, 64-size) from the = origin. >>=20 >>> * What are the rules for using a cached block to satisfy a request >>> that is presented to a cache? >>=20 >> The same as usual, maybe augmented with "you can't use what you don't = have"? >=20 > The usual procedure is: >=20 > - put the response into the cache as-is, i.e. without any = reassembling; I don't think that would be a very useful cache. I'm assuming that most intermediaries will implement block and run the = cache on reassembled representations. Do you think we need to spell out = the implementation considerations for this in detail? Gr=FC=DFe, Carsten From cabo@tzi.org Wed Apr 11 14:35:33 2012 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 917F221F84D5 for ; Wed, 11 Apr 2012 14:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.47 X-Spam-Level: X-Spam-Status: No, score=-106.47 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYTEyES0NQJ4 for ; Wed, 11 Apr 2012 14:35:33 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id AD64821F84D3 for ; Wed, 11 Apr 2012 14:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3BLZOkM019788 for ; Wed, 11 Apr 2012 23:35:24 +0200 (CEST) Received: from [192.168.217.105] (p5489ADE7.dip.t-dialin.net [84.137.173.231]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 425CF5B7; Wed, 11 Apr 2012 23:35:24 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Wed, 11 Apr 2012 23:35:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Klaus Hartke X-Mailer: Apple Mail (2.1257) Cc: core@ietf.org Subject: Re: [core] draft-ietf-core-block-08 - Block ordering X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 11 Apr 2012 21:35:33 -0000 On Apr 11, 2012, at 20:27, Klaus Hartke wrote: > On 11 April 2012 11:09, Carsten Bormann wrote: >> On Apr 11, 2012, at 06:32, Klaus Hartke wrote: >>=20 >>> Is a client allowed to up/download multiple blocks of the same >>> representation concurrently? Or does it have to wait for the = response >>> before it up/downloads the next block? >>=20 >> There is nothing in block-08 that would allow out-of-order accesses. >=20 > Section 2.1 gives detailed instructions on how to construct requests > with Block options. Section 2.2 does not say a lot about what requests > that could theoretically be constructed are allowed or not; I'd assume > that everything that is syntactically possible is allowed unless it's > explicitly forbidden. That is probably a fair assumption. It is also a fair assumption that a server will not implement all = conceivable combinations. (This is what I meant by "allow", sorry for being imprecise here.) So a client that wants to maximize interoperability will probably = operate in sequential fashion. But I think it is OK for a client to try out of order access; servers = will need to make sure they only respond with a success code if that = actually is implemented. Note that there is already some license for out of order access in the = text, e.g.,=20 If the ETag Options do not match in a GET transfer, the requester has the option of attempting to retrieve fresh values for the blocks it retrieved first. =20 > There does not seem to be any statement in the draft that forbids > starting an up/download with a block number other than 0, or that > forbids up/downloading blocks out of order. Correct, and it would be a mistake to explicitly forbid this. (It would be an even worse mistake to require servers to check this.) But a server that, say, has to convert line-endings or text encoding on = the fly, may only have reasonable means to support sequential access. So it would also be a mistake to require all servers to allow = out-of-order access. (Again, the word "allow" can have two meanings here: -- not disallow -- require implementation support ) Gr=FC=DFe, Carsten From trac+core@trac.tools.ietf.org Wed Apr 11 15:55:11 2012 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 7302611E80EA for ; Wed, 11 Apr 2012 15:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ul4aDlOcQ0vC for ; Wed, 11 Apr 2012 15:55:10 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id D05F511E80D9 for ; Wed, 11 Apr 2012 15:55:07 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SI6R5-0000mx-FD; Wed, 11 Apr 2012 18:54:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, hartke@tzi.org X-Trac-Project: core Date: Wed, 11 Apr 2012 22:54:46 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/207 Message-ID: <053.d889c7b2b45ce344b85654e528a4b801@trac.tools.ietf.org> X-Trac-Ticket-ID: 207 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120411225510.D05F511E80D9@ietfa.amsl.com> Resent-Date: Wed, 11 Apr 2012 15:55:07 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #207: Add advice on default values for critical options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.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: Wed, 11 Apr 2012 22:55:11 -0000 #207: Add advice on default values for critical options Klaus Hartke points out that the guidelines for registration of new options could include a check for an essential property of any default values for new critical options. in 11.2, a change for the registration information could be: o The default value, if any. -> o The default value, if any. For a critical option with a default value, a discussion how the default value enables processing by implementations not implementing the critical option (Section 5.4.3). In 5.4.3, add at the end: Where a critical option has a default value, this is chosen in such a way that the absence of the option in a message can be processed properly both by implementations unaware of the critical option and by implementations that interpret this absence as the presence of the default value for the option. Some wordsmithing may be required. -- -----------------------------+------------------------------------ Reporter: hartke@… | Owner: draft-ietf-core-coap@… Type: editorial | Status: new Priority: minor | Milestone: post-WGLC-1 Component: coap | Version: Severity: In WG Last Call | Keywords: -----------------------------+------------------------------------ Ticket URL: core From cabo@tzi.org Wed Apr 11 15:55:31 2012 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 03D5B11E8105 for ; Wed, 11 Apr 2012 15:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkeQUv0c3Shw for ; Wed, 11 Apr 2012 15:55:30 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1F41A11E8104 for ; Wed, 11 Apr 2012 15:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3BMtHCb014671 for ; Thu, 12 Apr 2012 00:55:17 +0200 (CEST) Received: from [192.168.217.105] (p5489ADE7.dip.t-dialin.net [84.137.173.231]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 08CC45C1; Thu, 12 Apr 2012 00:55:16 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Thu, 12 Apr 2012 00:55:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3194640F-F3DB-40A2-9258-19DB84AB349E@tzi.org> References: <54E1D092-70BF-46CC-8CCE-F53F3F6B5CB3@tzi.org> To: Klaus Hartke X-Mailer: Apple Mail (2.1257) Cc: core@ietf.org Subject: Re: [core] draft-ietf-core-coap-09 - Critical options with default values X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 11 Apr 2012 22:55:31 -0000 On Apr 11, 2012, at 20:25, Klaus Hartke wrote: > Section 11.2 [1] includes guidelines for the review process that > applies to future option number requests. Yes, but the IANA considerations are rarely a good place to introduce a = concept (here: backwards compatibility of default values for new = critical options). 5.4.3 is not such a great place for this discussion either. Hmm. Still better to capture this. > If we can give objective guidelines for deciding if a critical option > with a default value does "the right thing", we should do it. Yes. Now #207. Gr=FC=DFe, Carsten From Bert.Greevenbosch@huawei.com Wed Apr 11 23:22:46 2012 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 AB46C11E809A for ; Wed, 11 Apr 2012 23:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5ygE1BbdM9X for ; Wed, 11 Apr 2012 23:22:46 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0B71C11E8089 for ; Wed, 11 Apr 2012 23:22:46 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFD73276; Thu, 12 Apr 2012 02:22:45 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 11 Apr 2012 23:19:04 -0700 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 11 Apr 2012 23:19:02 -0700 Received: from SZXEML509-MBS.china.huawei.com ([10.82.67.53]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.003; Thu, 12 Apr 2012 14:18:56 +0800 From: Bert Greevenbosch To: Klaus Hartke , "core@ietf.org" Thread-Topic: [core] draft-ietf-core-block-08 - Tokens in requests Thread-Index: AQHNF5wlLWQDftbULkiltgSxiYLlbJaU8wMAgAB5qwCAAR/ekA== Date: Thu, 12 Apr 2012 06:18:55 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB628F70C2E@szxeml509-mbs> References: <7AFA68E3-5481-40E9-B541-7524DFA05C60@tzi.org> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.109.135] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [core] draft-ietf-core-block-08 - Tokens in requests X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 06:22:46 -0000 The only situation in which the client is the reassembler, is when it downloads a representation in multiple parts. Of course it needs to compare the token in each response to the token it used in the request, otherwise it would not be able to match a response to its request. But there is no statement that requires a client to use a certain token in its requests. This relates to my earlier comment on combined Block1/Block2 in a Put/Post = request. To the last block in a Put/Post request, the server can send multi= ple responses, using the Block2 option. As the client does not send new req= uests, the server has to maintain the same token in those multiple response= s. This may be taken even further, as also for small Put/Post requests, that d= o not require Block1, the server may want to respond with a larger payload = in its response, and thus use Block2. Best regards, Bert -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Kla= us Hartke Sent: 12 April 2012 02:29 To: core@ietf.org Subject: Re: [core] draft-ietf-core-block-08 - Tokens in requests On 11 April 2012 13:13, Carsten Bormann wrote: > There is also: > > =A0 In this case, when reassembling the representation from > =A0 the blocks being exchanged to enable atomic processing, the > =A0 reassembler MUST compare any Token Options present (and, as usual, > =A0 taking an absent Token Option to default to the empty Token). =A0If > =A0 atomic processing is not desired, there is no need to process the > =A0 Token Option (but it is still returned in the response as usual). > > (which I think is the juicy bit.) The only situation in which the client is the reassembler, is when it downloads a representation in multiple parts. Of course it needs to compare the token in each response to the token it used in the request, otherwise it would not be able to match a response to its request. But there is no statement that requires a client to use a certain token in its requests. Klaus _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From esko.dijk@philips.com Thu Apr 12 02:17:51 2012 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 B807C21F8617 for ; Thu, 12 Apr 2012 02:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQ6heF0UCUQK for ; Thu, 12 Apr 2012 02:17:51 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id 5470F21F84DC for ; Thu, 12 Apr 2012 02:17:50 -0700 (PDT) Received: from mail22-am1-R.bigfish.com (10.3.201.225) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.23; Thu, 12 Apr 2012 09:17:49 +0000 Received: from mail22-am1 (localhost [127.0.0.1]) by mail22-am1-R.bigfish.com (Postfix) with ESMTP id D8FB84000E5; Thu, 12 Apr 2012 09:17:48 +0000 (UTC) X-SpamScore: -47 X-BigFish: VPS-47(zz217bL15d6O9251Jc89bh542M1432N98dKzz1202hzz1033IL8275dhz2dh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI Received: from mail22-am1 (localhost.localdomain [127.0.0.1]) by mail22-am1 (MessageSwitch) id 1334222266504036_25761; Thu, 12 Apr 2012 09:17:46 +0000 (UTC) Received: from AM1EHSMHS019.bigfish.com (unknown [10.3.201.227]) by mail22-am1.bigfish.com (Postfix) with ESMTP id 7650EA008F; Thu, 12 Apr 2012 09:17:46 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by AM1EHSMHS019.bigfish.com (10.3.206.22) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 12 Apr 2012 09:17:46 +0000 Received: from 011-DB3MPN1-013.MGDPHG.emi.philips.com ([169.254.3.240]) by 011-DB3MMR1-005.MGDPHG.emi.philips.com ([10.128.28.55]) with mapi id 14.01.0355.003; Thu, 12 Apr 2012 10:20:22 +0100 From: "Dijk, Esko" To: Carsten Bormann , Klaus Hartke Thread-Topic: [core] draft-ietf-core-block-08 - Block ordering Thread-Index: AQHNF6OaclcEg8PWJkmCm3+pauZY4JaVRZWAgACb6wCAADR1gIAA1FlQ Date: Thu, 12 Apr 2012 09:20:23 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618092AD7@011-DB3MPN1-013.MGDPHG.emi.philips.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.101] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "core@ietf.org" Subject: Re: [core] draft-ietf-core-block-08 - Block ordering X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 09:17:51 -0000 Just an editorial note on the block-08 text and the concepts of ordering an= d first/last block: the term "final block" should probably be changed to "last block" to get th= is term consistent throughout. "Last block" is clearly defined in relation = to the More Flag while the term "final block" is not. Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Car= sten Bormann Sent: Wednesday 11 April 2012 23:35 To: Klaus Hartke Cc: core@ietf.org Subject: Re: [core] draft-ietf-core-block-08 - Block ordering On Apr 11, 2012, at 20:27, Klaus Hartke wrote: > On 11 April 2012 11:09, Carsten Bormann wrote: >> On Apr 11, 2012, at 06:32, Klaus Hartke wrote: >> >>> Is a client allowed to up/download multiple blocks of the same >>> representation concurrently? Or does it have to wait for the response >>> before it up/downloads the next block? >> >> There is nothing in block-08 that would allow out-of-order accesses. > > Section 2.1 gives detailed instructions on how to construct requests > with Block options. Section 2.2 does not say a lot about what requests > that could theoretically be constructed are allowed or not; I'd assume > that everything that is syntactically possible is allowed unless it's > explicitly forbidden. That is probably a fair assumption. It is also a fair assumption that a server will not implement all conceivab= le combinations. (This is what I meant by "allow", sorry for being imprecise here.) So a client that wants to maximize interoperability will probably operate i= n sequential fashion. But I think it is OK for a client to try out of order access; servers will = need to make sure they only respond with a success code if that actually is= implemented. Note that there is already some license for out of order access in the text= , e.g., If the ETag Options do not match in a GET transfer, the requester has the option of attempting to retrieve fresh values for the blocks it retrieved first. > There does not seem to be any statement in the draft that forbids > starting an up/download with a block number other than 0, or that > forbids up/downloading blocks out of order. Correct, and it would be a mistake to explicitly forbid this. (It would be an even worse mistake to require servers to check this.) But a server that, say, has to convert line-endings or text encoding on the= fly, may only have reasonable means to support sequential access. So it would also be a mistake to require all servers to allow out-of-order = access. (Again, the word "allow" can have two meanings here: -- not disallow -- require implementation support ) Gr=FC=DFe, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From esko.dijk@philips.com Thu Apr 12 02:33:58 2012 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 6109621F8670 for ; Thu, 12 Apr 2012 02:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XY7RhJdZ0G2 for ; Thu, 12 Apr 2012 02:33:57 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe001.messaging.microsoft.com [213.199.154.139]) by ietfa.amsl.com (Postfix) with ESMTP id 423E321F866C for ; Thu, 12 Apr 2012 02:33:57 -0700 (PDT) Received: from mail62-db3-R.bigfish.com (10.3.81.254) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Thu, 12 Apr 2012 09:33:56 +0000 Received: from mail62-db3 (localhost [127.0.0.1]) by mail62-db3-R.bigfish.com (Postfix) with ESMTP id 4FB404A0563; Thu, 12 Apr 2012 09:33:56 +0000 (UTC) X-SpamScore: -47 X-BigFish: VPS-47(zz217bL15d6O9251Jc89bh542M1432N98dKzz1202hzz1033IL8275dhz2dh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI Received: from mail62-db3 (localhost.localdomain [127.0.0.1]) by mail62-db3 (MessageSwitch) id 1334223233964630_30568; Thu, 12 Apr 2012 09:33:53 +0000 (UTC) Received: from DB3EHSMHS009.bigfish.com (unknown [10.3.81.245]) by mail62-db3.bigfish.com (Postfix) with ESMTP id E8B0F480043; Thu, 12 Apr 2012 09:33:53 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by DB3EHSMHS009.bigfish.com (10.3.87.109) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 12 Apr 2012 09:33:53 +0000 Received: from 011-DB3MMR1-019.MGDPHG.emi.philips.com (10.128.28.106) by 011-DB3MMR1-001.MGDPHG.emi.philips.com (10.128.28.51) with Microsoft SMTP Server (TLS) id 14.1.355.3; Thu, 12 Apr 2012 10:36:30 +0100 Received: from 011-DB3MPN1-013.MGDPHG.emi.philips.com ([169.254.3.240]) by 011-DB3MMR1-019.MGDPHG.emi.philips.com ([10.128.28.106]) with mapi id 14.01.0355.003; Thu, 12 Apr 2012 10:33:52 +0100 From: "Dijk, Esko" To: Carsten Bormann , Klaus Hartke Thread-Topic: [core] draft-ietf-core-block-08 - Block ordering Thread-Index: AQHNF6OaclcEg8PWJkmCm3+pauZY4JaVRZWAgACb6wCAADR1gIAA1X0Q Date: Thu, 12 Apr 2012 09:36:30 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618092AF8@011-DB3MPN1-013.MGDPHG.emi.philips.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.101] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "core@ietf.org" Subject: Re: [core] draft-ietf-core-block-08 - Block ordering X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 09:33:58 -0000 Carsten, > So a client that wants to maximize interoperability will probably operate= in sequential fashion. Ok. If this constitutes the minimum level of interoperability for core-bloc= k, should we mandate it as such? Option 1) e.g. specify a CoAP end-point MUST be prepared to receive block n= umbers in sequential fashion. Option 2) e.g. specify a CoAP end-point MAY use block numbers in sequential= fashion. [this automatically implies an end-point MUST be prepared to = receive sequential block numbers. At least an implementer MUST consider this possibility.] Though, the sequential case is so obvious from the I-D that it is already a= de-facto minimum interoperability (though not formally stated). Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Car= sten Bormann Sent: Wednesday 11 April 2012 23:35 To: Klaus Hartke Cc: core@ietf.org Subject: Re: [core] draft-ietf-core-block-08 - Block ordering On Apr 11, 2012, at 20:27, Klaus Hartke wrote: > On 11 April 2012 11:09, Carsten Bormann wrote: >> On Apr 11, 2012, at 06:32, Klaus Hartke wrote: >> >>> Is a client allowed to up/download multiple blocks of the same >>> representation concurrently? Or does it have to wait for the response >>> before it up/downloads the next block? >> >> There is nothing in block-08 that would allow out-of-order accesses. > > Section 2.1 gives detailed instructions on how to construct requests > with Block options. Section 2.2 does not say a lot about what requests > that could theoretically be constructed are allowed or not; I'd assume > that everything that is syntactically possible is allowed unless it's > explicitly forbidden. That is probably a fair assumption. It is also a fair assumption that a server will not implement all conceivab= le combinations. (This is what I meant by "allow", sorry for being imprecise here.) So a client that wants to maximize interoperability will probably operate i= n sequential fashion. But I think it is OK for a client to try out of order access; servers will = need to make sure they only respond with a success code if that actually is= implemented. Note that there is already some license for out of order access in the text= , e.g., If the ETag Options do not match in a GET transfer, the requester has the option of attempting to retrieve fresh values for the blocks it retrieved first. > There does not seem to be any statement in the draft that forbids > starting an up/download with a block number other than 0, or that > forbids up/downloading blocks out of order. Correct, and it would be a mistake to explicitly forbid this. (It would be an even worse mistake to require servers to check this.) But a server that, say, has to convert line-endings or text encoding on the= fly, may only have reasonable means to support sequential access. So it would also be a mistake to require all servers to allow out-of-order = access. (Again, the word "allow" can have two meanings here: -- not disallow -- require implementation support ) Gr=FC=DFe, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From esko.dijk@philips.com Thu Apr 12 03:02:49 2012 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 16FB421F84D7 for ; Thu, 12 Apr 2012 03:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esQoiAuvGV0s for ; Thu, 12 Apr 2012 03:02:48 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 5E38221F85D1 for ; Thu, 12 Apr 2012 03:02:48 -0700 (PDT) Received: from mail154-tx2-R.bigfish.com (10.9.14.253) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.23; Thu, 12 Apr 2012 10:02:47 +0000 Received: from mail154-tx2 (localhost [127.0.0.1]) by mail154-tx2-R.bigfish.com (Postfix) with ESMTP id CD6552C01F9; Thu, 12 Apr 2012 10:02:47 +0000 (UTC) X-SpamScore: -38 X-BigFish: VPS-38(zz217bL15d6O9251J542Mzz1202hzz1033IL8275dhz2dh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI Received: from mail154-tx2 (localhost.localdomain [127.0.0.1]) by mail154-tx2 (MessageSwitch) id 1334224966534153_15258; Thu, 12 Apr 2012 10:02:46 +0000 (UTC) Received: from TX2EHSMHS021.bigfish.com (unknown [10.9.14.238]) by mail154-tx2.bigfish.com (Postfix) with ESMTP id 7D64E4C0052; Thu, 12 Apr 2012 10:02:46 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by TX2EHSMHS021.bigfish.com (10.9.99.121) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 12 Apr 2012 10:02:44 +0000 Received: from 011-DB3MMR1-015.MGDPHG.emi.philips.com (10.128.28.99) by 011-DB3MMR1-010.MGDPHG.emi.philips.com (10.128.28.49) with Microsoft SMTP Server (TLS) id 14.1.355.3; Thu, 12 Apr 2012 11:02:04 +0100 Received: from 011-DB3MPN1-013.MGDPHG.emi.philips.com ([169.254.3.240]) by 011-DB3MMR1-015.MGDPHG.emi.philips.com ([10.128.28.99]) with mapi id 14.01.0355.003; Thu, 12 Apr 2012 11:02:03 +0100 From: "Dijk, Esko" To: "Pascal Thubert (pthubert)" , "core@ietf.org" Thread-Topic: [core] draft-ietf-core-coap-09: retransmission window Thread-Index: AQHNDMGrPF0yNbTnz0mTKLJSOAaIG5Z/cw6AgAFhZQCABoCdgIAPtxqg Date: Thu, 12 Apr 2012 10:04:41 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618092B71@011-DB3MPN1-013.MGDPHG.emi.philips.com> References: <201203290941.34933.mab@comnets.uni-bremen.de> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.101] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: Re: [core] draft-ietf-core-coap-09: retransmission window X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 10:02:49 -0000 Hi Pascal, did you have a specific proposal in mind for changing the retransmission wi= ndow calculation? Or could we comply to both RFCs already by simply choosing different Sectio= n 9 protocol constants? (I haven't read the mentioned RFCs, but it appears relevant). Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Pas= cal Thubert (pthubert) Sent: Monday 2 April 2012 12:59 To: core@ietf.org Subject: Re: [core] draft-ietf-core-coap-09: retransmission window Dear WG: A gentle reminder about retransmission window calculation from one year ago= . It is probably a good practice that CoAP is TCP friendly and adaptive to th= e environment changes. ISA100.11a found that RFC 2988 was a fair method for achieving both objecti= ves. ISA100.11a also checked for a good respect of recommendation is RFC 5405. Is there any reason why CoAP goes for a different approach? Do we have a clear idea how a large set of CoAP devices will share a common= network with TCP applications, as well as UDP applications that would comp= ly with the above RFCs? Cheers, Pascal ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From pthubert@cisco.com Thu Apr 12 03:15:14 2012 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 E73F321F856C for ; Thu, 12 Apr 2012 03:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.079 X-Spam-Level: X-Spam-Status: No, score=-10.079 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-SkfZUTGqv7 for ; Thu, 12 Apr 2012 03:15:13 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9F20D21F8562 for ; Thu, 12 Apr 2012 03:15:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=2732; q=dns/txt; s=iport; t=1334225713; x=1335435313; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=KLTM+OFfhmqPAXK4CAZvKsW9GEROEGOKOdN/LVQQ8q8=; b=KwKJznnv70hMICoqLe+mLg899O/dlq9bdvCmalxwQ9ykBNV1wUFc77U3 FaMSK7jSYXR3yf5KUSK7vdeOUwQ8/QDcXl5tOgncS5Qo8J00mKLialzdU wv9PGUrPRKAz9qogrr7t9IVsMkH2EMHOZSGc6pE2QiqiZ8JDDWOhYQhiC E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANSphk+Q/khN/2dsb2JhbABEuWiBB4IJAQEBBBIBHQpLBAIBCBEEAQELBhcBBgFFCQgCBAESCBqHbAuaOKAIizOFaGMEln2NPIFpgmmBWg X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="70664845" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 12 Apr 2012 10:15:11 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3CAFBKm022145; Thu, 12 Apr 2012 10:15:11 GMT Received: from xmb-ams-108.cisco.com ([144.254.74.83]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Apr 2012 12:15:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Apr 2012 12:14:09 +0200 Message-ID: In-Reply-To: <031DD135F9160444ABBE3B0C36CED618092B71@011-DB3MPN1-013.MGDPHG.emi.philips.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] draft-ietf-core-coap-09: retransmission window Thread-Index: AQHNDMGrPF0yNbTnz0mTKLJSOAaIG5Z/cw6AgAFhZQCABoCdgIAPtxqggAACBQA= References: <201203290941.34933.mab@comnets.uni-bremen.de> <031DD135F9160444ABBE3B0C36CED618092B71@011-DB3MPN1-013.MGDPHG.emi.philips.com> From: "Pascal Thubert (pthubert)" To: "Dijk, Esko" , X-OriginalArrivalTime: 12 Apr 2012 10:15:11.0780 (UTC) FILETIME=[2540A640:01CD1895] Subject: Re: [core] draft-ietf-core-coap-09: retransmission window X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 10:15:15 -0000 Hello Esko: The whole point is that a constant does not work satisfactorily. In fact it will work even less in a WSN than it does on the broad Internet because of the latencies that we can experience there. You need a smoothed estimate of the round-trip time, and an estimate of its variation to compute your retransmission timeout. The algorithm is quite simple but you really need to read it in section 2 of http://tools.ietf.org/html/rfc6298 . ISA100.11a devices have incorporate that algorithm at app layer. The only question is really what's the initial value. Quote: " The Internet, to a considerable degree, relies on the correct implementation of the RTO algorithm (as well as those described in RFC 5681) in order to preserve network stability and avoid congestion collapse. " Cheers, Pascal -----Original Message----- From: Dijk, Esko [mailto:esko.dijk@philips.com]=20 Sent: jeudi 12 avril 2012 12:05 To: Pascal Thubert (pthubert); core@ietf.org Subject: RE: [core] draft-ietf-core-coap-09: retransmission window Hi Pascal, did you have a specific proposal in mind for changing the retransmission window calculation? Or could we comply to both RFCs already by simply choosing different Section 9 protocol constants? (I haven't read the mentioned RFCs, but it appears relevant). Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert) Sent: Monday 2 April 2012 12:59 To: core@ietf.org Subject: Re: [core] draft-ietf-core-coap-09: retransmission window Dear WG: A gentle reminder about retransmission window calculation from one year ago. It is probably a good practice that CoAP is TCP friendly and adaptive to the environment changes. ISA100.11a found that RFC 2988 was a fair method for achieving both objectives. ISA100.11a also checked for a good respect of recommendation is RFC 5405. Is there any reason why CoAP goes for a different approach? Do we have a clear idea how a large set of CoAP devices will share a common network with TCP applications, as well as UDP applications that would comply with the above RFCs? Cheers, Pascal ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. From cabo@tzi.org Thu Apr 12 03:27:24 2012 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 A065021F84DC for ; Thu, 12 Apr 2012 03:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cck3EyEHStyk for ; Thu, 12 Apr 2012 03:27:23 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE0E21F84DE for ; Thu, 12 Apr 2012 03:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3CARDYN007945; Thu, 12 Apr 2012 12:27:13 +0200 (CEST) Received: from [10.0.1.3] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 8DBEA808; Thu, 12 Apr 2012 12:27:13 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <031DD135F9160444ABBE3B0C36CED618092B71@011-DB3MPN1-013.MGDPHG.emi.philips.com> Date: Thu, 12 Apr 2012 12:27:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201203290941.34933.mab@comnets.uni-bremen.de> <031DD135F9160444ABBE3B0C36CED618092B71@011-DB3MPN1-013.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1257) Cc: "core@ietf.org" Subject: Re: [core] draft-ietf-core-coap-09: retransmission window X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 10:27:24 -0000 On Apr 12, 2012, at 12:04, Dijk, Esko wrote: > comply to both RFCs I don't think we can "comply with" RFC 2988. (Or with RFC 6298, which obsoletes RFC 2988.) RFC 6298 is defined in the context of TCP; we simply don't have the = connection state that we could base the same calculations on. However, a future specification could use RFC 6298 as an inspiration. That could even recommend keeping RFC-6298-style state, e.g., around = DTLS connections, or in conjunction with observation state or cache = entries. Coap-09 certainly is open to other ways of deriving these numbers. I believe any update here should be done based on relevant deployment = experience. ISA100.11a experience may or may not be "relevant", as the communication = patterns in industrial process control may be much more regular than I'd = expect in many CoAP applications. For me the one open question in this thread (see subject) is whether we = should give guidance for a default retransmission window. Most = implementations will probably work well with a default on the order of = 256 s. Should we give that guidance? Gr=FC=DFe, Carsten From cabo@tzi.org Thu Apr 12 03:28:12 2012 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 EF15321F84FB for ; Thu, 12 Apr 2012 03:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9lionNOsUj9 for ; Thu, 12 Apr 2012 03:28:12 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 0417521F84EE for ; Thu, 12 Apr 2012 03:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3CAS4vK008298; Thu, 12 Apr 2012 12:28:04 +0200 (CEST) Received: from [10.0.1.3] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B5F2980A; Thu, 12 Apr 2012 12:28:04 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <031DD135F9160444ABBE3B0C36CED618092AF8@011-DB3MPN1-013.MGDPHG.emi.philips.com> Date: Thu, 12 Apr 2012 12:28:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0EDC43A0-E85B-4E7C-A442-798576178C5A@tzi.org> References: <031DD135F9160444ABBE3B0C36CED618092AF8@011-DB3MPN1-013.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1257) Cc: "core@ietf.org" , Klaus Hartke Subject: Re: [core] draft-ietf-core-block-08 - Block ordering X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 10:28:13 -0000 On Apr 12, 2012, at 11:36, Dijk, Esko wrote: > Carsten, >=20 >> So a client that wants to maximize interoperability will probably = operate in sequential fashion. > Ok. If this constitutes the minimum level of interoperability for = core-block, should we mandate it as such? >=20 > Option 1) e.g. specify a CoAP end-point MUST be prepared to receive = block numbers in sequential fashion. Well, it is hard to say what such a MUST ("be prepared to receive...") = really constrains. A server can still always go belly-up, stop serving a resource, ... I think the point is indeed that there is a larger expectation of = successful completion when a client steps sequentially through the = blocks of a resource. > Option 2) e.g. specify a CoAP end-point MAY use block numbers in = sequential fashion. > [this automatically implies an end-point MUST be prepared = to receive sequential block numbers. At least an implementer MUST > consider this possibility.] But it also MAY use out-of order accesses... just with a slightly lower = level of expectation that the server will be able to successfully = respond. > Though, the sequential case is so obvious from the I-D that it is = already a de-facto minimum interoperability (though not formally = stated). That was indeed my reasoning so far. To me it seems we could make all this more apparent by stating two = things: 1) the protocol does not fundamentally disallow out-of-order access = (and, many servers will be able to provide out-of-order access (e.g., = because they are stateless)) 2) still, there is an expectation that more servers will be able to cope = with sequential access than with out-of-order access. Servers that = implement one of the Block options SHOULD enable sequential access, and = MAY enable out-of-order access. Gr=FC=DFe, Carsten From pthubert@cisco.com Thu Apr 12 04:18:07 2012 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 6CC8621F860E for ; Thu, 12 Apr 2012 04:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.102 X-Spam-Level: X-Spam-Status: No, score=-10.102 tagged_above=-999 required=5 tests=[AWL=0.497, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8L4eIjhApl9 for ; Thu, 12 Apr 2012 04:18:06 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 64C1021F8607 for ; Thu, 12 Apr 2012 04:18:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=2717; q=dns/txt; s=iport; t=1334229486; x=1335439086; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=fQPmdEq7kbE9KoxSH/9Ene+xdXF058RdV5H4flbA3DI=; b=jIpzTNq15IeQjzV/ZwMspkd4T6fgsZCGDBocbWZPc1MqXjTMH+j1bG+D EGffGEwEXcArNR4gds9k0mFcLQQy4pQq/m6Jhw6dEIKpFIFRhiAgpESiY VqO1BQRmuyr3NwnUtVpKsgv3WmweMsoNt3/0T7j62N9V3mJt9OlVOCxaO U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAFW5hk+Q/khN/2dsb2JhbABEuWaBB4IJAQEBAwESAR1JBQsCAQgOFAYYBgFWAQEEGxqHZwWaVKALkRtjBIgnnBKBaYJp X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="70671160" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 12 Apr 2012 11:18:02 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3CBI3MD005926; Thu, 12 Apr 2012 11:18:03 GMT Received: from xmb-ams-108.cisco.com ([144.254.74.83]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Apr 2012 13:18:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Apr 2012 13:16:56 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] draft-ietf-core-coap-09: retransmission window Thread-Index: Ac0YltoOM5OYGujlS4yN/J3EfseexAABI+Jg References: <201203290941.34933.mab@comnets.uni-bremen.de> <031DD135F9160444ABBE3B0C36CED618092B71@011-DB3MPN1-013.MGDPHG.emi.philips.com> From: "Pascal Thubert (pthubert)" To: "Carsten Bormann" , "Dijk, Esko" X-OriginalArrivalTime: 12 Apr 2012 11:18:02.0915 (UTC) FILETIME=[ED062F30:01CD189D] Cc: core@ietf.org Subject: Re: [core] draft-ietf-core-coap-09: retransmission window X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 11:18:07 -0000 Hi Carsten > RFC 6298 is defined in the context of TCP; we simply don't have the = connection state that we could base the same calculations on. [Pascal] there are ways. The question is whether all applications need = to make the effort or not. If CoAP is used over a local/dedicated = network, then it can be kept very simple and some RTO value can be = engineered and hard coded. If CoAP operates over the Internet and = becomes successful (and success here is a LARGE number of devices) then = CoAP applications must be good internet citizens. > However, a future specification could use RFC 6298 as an inspiration. That could even recommend keeping RFC-6298-style state, e.g., around = DTLS connections, or in conjunction with observation state or cache = entries. [Pascal] These are ways...=20 Coap-09 certainly is open to other ways of deriving these numbers. I believe any update here should be done based on relevant deployment = experience. [Pascal] I believe section 3.1 of RFC 5405 derives from such = experience. Section 3.1.2 has: " Similar to the recommendation in [RFC1536], an application SHOULD maintain an estimate of the RTT for any destination with which it communicates. Applications SHOULD implement the algorithm specified in [RFC2988] to compute a smoothed RTT (SRTT) estimate. They SHOULD also detect packet loss and exponentially back-off their retransmission timer when a loss event occurs. " > ISA100.11a experience may or may not be "relevant", as the = communication patterns in industrial process control may be much more = regular than I'd expect in many CoAP applications. [Pascal] I had it the other way around, like are we designing this = protocol in a way that could be used by ISA as a replacement for their = specific ways. That was the sense of the questions I asked when I came = to the mike and so far the answer was satisfactory. Yes, probably ISA100 = could in some future migrate to CoAP. That's still doable as long as = CoAP allows for an RTO computation that can make it Internet friendly. > For me the one open question in this thread (see subject) is whether = we should give guidance for a default retransmission window. Most = implementations will probably work well with a default on the order of = 256 s. Should we give that guidance? [Pascal] I certainly disagree. If CoAP does not play by Internet rules, = it has to stay confined at the edge. Is that what we want? Can we = document how this protocol, though disrespectful of RFC 5405, can still = be innocuous to the Internet at large when the number of devices grows = to the billions? Gr=FC=DFe too, Pascal From cabo@tzi.org Thu Apr 12 05:04:33 2012 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 3B64621F8653 for ; Thu, 12 Apr 2012 05:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7Q7D0hv1aUe for ; Thu, 12 Apr 2012 05:04:32 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 514E421F864A for ; Thu, 12 Apr 2012 05:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3CC4M3k028030; Thu, 12 Apr 2012 14:04:22 +0200 (CEST) Received: from [10.0.1.3] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 71E0B902; Thu, 12 Apr 2012 14:04:22 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Thu, 12 Apr 2012 14:04:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1F768CB8-B0E8-4ADD-919C-55FFA0491CEC@tzi.org> References: <201203290941.34933.mab@comnets.uni-bremen.de> <031DD135F9160444ABBE3B0C36CED618092B71@011-DB3MPN1-013.MGDPHG.emi.philips.com> To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1257) Cc: core@ietf.org Subject: Re: [core] draft-ietf-core-coap-09: retransmission window X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 12:04:33 -0000 Pascal, thanks -- pointing to RFC 5405 out of the last paragraph of section 9 = (or of 4.6?) is certainly a good idea. I still don't think it is a slam-dunk how to apply 6298 (and the more = general considerations of 5405) to the different kinds of CoAP = environments. Sure, for an ISA100.11a type environment, there are = indications that 6298 works as is, but in the more general case, we'd = need to spend some time understanding what that even means in the first = place. > [Pascal] I believe section 3.1 of RFC 5405 derives from such = experience. No, I don't think there is much experience with CoAP-like traffic in the = Internet yet. > Section 3.1.2 has: > " Similar to the > recommendation in [RFC1536], an application SHOULD maintain an > estimate of the RTT for any destination with which it communicates. > Applications SHOULD implement the algorithm specified in [RFC2988] = to > compute a smoothed RTT (SRTT) estimate. They SHOULD also detect > packet loss and exponentially back-off their retransmission timer > when a loss event occurs. > " Yes, but it also says: > Some applications cannot maintain a reliable RTT estimate for a > destination. The first case is that of applications that exchange > too few UDP datagrams with a peer to establish a statistically > accurate RTT estimate. Such applications MAY use a predetermined > transmission interval that is exponentially backed-off when packets > are lost. TCP uses an initial value of 3 seconds [RFC2988], which = is > also RECOMMENDED as an initial value for UDP applications. SIP > [RFC3261] and GIST [GIST] use an interval of 500 ms, and shorter > values are likely problematic in many cases. As in the previous > case, note that the initial timeout is not the maximum possible > timeout. Well, the initial timeout of TCP has since moved down [RFC6298]. Otherwise we are right there already. Gr=FC=DFe, Carsten From esko.dijk@philips.com Thu Apr 12 06:14:42 2012 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 CAC1B21F858A for ; Thu, 12 Apr 2012 06:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PIvXlgjoTF2 for ; Thu, 12 Apr 2012 06:14:42 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id C7C7121F856C for ; Thu, 12 Apr 2012 06:14:41 -0700 (PDT) Received: from mail29-am1-R.bigfish.com (10.3.201.249) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.23; Thu, 12 Apr 2012 13:14:40 +0000 Received: from mail29-am1 (localhost [127.0.0.1]) by mail29-am1-R.bigfish.com (Postfix) with ESMTP id B0C42180411; Thu, 12 Apr 2012 13:14:40 +0000 (UTC) X-SpamScore: -47 X-BigFish: VPS-47(zz217bL15d6O9251Jc89bh542M1432N98dKzz1202hzz1033IL8275dhz2dh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI Received: from mail29-am1 (localhost.localdomain [127.0.0.1]) by mail29-am1 (MessageSwitch) id 1334236478311002_18916; Thu, 12 Apr 2012 13:14:38 +0000 (UTC) Received: from AM1EHSMHS002.bigfish.com (unknown [10.3.201.242]) by mail29-am1.bigfish.com (Postfix) with ESMTP id 3D9492C0053; Thu, 12 Apr 2012 13:14:38 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by AM1EHSMHS002.bigfish.com (10.3.207.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 12 Apr 2012 13:14:36 +0000 Received: from 011-DB3MPN1-013.MGDPHG.emi.philips.com ([169.254.3.240]) by 011-DB3MMR1-002.MGDPHG.emi.philips.com ([10.128.28.52]) with mapi id 14.01.0355.003; Thu, 12 Apr 2012 14:17:14 +0100 From: "Dijk, Esko" To: Carsten Bormann Thread-Topic: [core] draft-ietf-core-block-08 - Block ordering Thread-Index: AQHNF6OaclcEg8PWJkmCm3+pauZY4JaVRZWAgACb6wCAADR1gIAA1X0QgAACZgCAAD7rcA== Date: Thu, 12 Apr 2012 13:17:14 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618092CD3@011-DB3MPN1-013.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED618092AF8@011-DB3MPN1-013.MGDPHG.emi.philips.com> <0EDC43A0-E85B-4E7C-A442-798576178C5A@tzi.org> In-Reply-To: <0EDC43A0-E85B-4E7C-A442-798576178C5A@tzi.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.101] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "core@ietf.org" , Klaus Hartke Subject: Re: [core] draft-ietf-core-block-08 - Block ordering X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 13:14:42 -0000 > To me it seems we could make all this more apparent by stating two things= : > > 1) the protocol does not fundamentally disallow out-of-order access (and,= many servers will be able to provide out-of-order access (e.g., because th= ey > are stateless)) > 2) still, there is an expectation that more servers will be able to cope = with sequential access than with out-of-order access. Servers that impleme= nt > one of the Block options SHOULD enable sequential access, and MAY enable = out-of-order access. That sounds ok for me! thanks Esko -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: Thursday 12 April 2012 12:28 To: Dijk, Esko Cc: Klaus Hartke; core@ietf.org Subject: Re: [core] draft-ietf-core-block-08 - Block ordering On Apr 12, 2012, at 11:36, Dijk, Esko wrote: > Carsten, > >> So a client that wants to maximize interoperability will probably operat= e in sequential fashion. > Ok. If this constitutes the minimum level of interoperability for core-bl= ock, should we mandate it as such? > > Option 1) e.g. specify a CoAP end-point MUST be prepared to receive block= numbers in sequential fashion. Well, it is hard to say what such a MUST ("be prepared to receive...") real= ly constrains. A server can still always go belly-up, stop serving a resource, ... I think the point is indeed that there is a larger expectation of successfu= l completion when a client steps sequentially through the blocks of a resou= rce. > Option 2) e.g. specify a CoAP end-point MAY use block numbers in sequenti= al fashion. > [this automatically implies an end-point MUST be prepared to= receive sequential block numbers. At least an implementer MUST > consider this possibility.] But it also MAY use out-of order accesses... just with a slightly lower lev= el of expectation that the server will be able to successfully respond. > Though, the sequential case is so obvious from the I-D that it is already= a de-facto minimum interoperability (though not formally stated). That was indeed my reasoning so far. To me it seems we could make all this more apparent by stating two things: 1) the protocol does not fundamentally disallow out-of-order access (and, m= any servers will be able to provide out-of-order access (e.g., because they= are stateless)) 2) still, there is an expectation that more servers will be able to cope wi= th sequential access than with out-of-order access. Servers that implement= one of the Block options SHOULD enable sequential access, and MAY enable o= ut-of-order access. Gr=FC=DFe, Carsten ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From esko.dijk@philips.com Thu Apr 12 07:41:45 2012 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 F2B9521F8668 for ; Thu, 12 Apr 2012 07:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.974 X-Spam-Level: X-Spam-Status: No, score=-3.974 tagged_above=-999 required=5 tests=[AWL=-0.376, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5blJ1Jbn2bto for ; Thu, 12 Apr 2012 07:41:41 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB5D21F8661 for ; Thu, 12 Apr 2012 07:41:40 -0700 (PDT) Received: from mail159-va3-R.bigfish.com (10.7.14.239) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.23; Thu, 12 Apr 2012 14:41:39 +0000 Received: from mail159-va3 (localhost [127.0.0.1]) by mail159-va3-R.bigfish.com (Postfix) with ESMTP id E461F4E012B; Thu, 12 Apr 2012 14:41:39 +0000 (UTC) X-SpamScore: -44 X-BigFish: VPS-44(zz217bL15d6O9251Jc85fh1432N1453Mzz1202hzz1033IL8275dhz2dh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI Received: from mail159-va3 (localhost.localdomain [127.0.0.1]) by mail159-va3 (MessageSwitch) id 1334241696447449_12708; Thu, 12 Apr 2012 14:41:36 +0000 (UTC) Received: from VA3EHSMHS036.bigfish.com (unknown [10.7.14.244]) by mail159-va3.bigfish.com (Postfix) with ESMTP id 5D59C2A007F; Thu, 12 Apr 2012 14:41:36 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by VA3EHSMHS036.bigfish.com (10.7.99.46) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 12 Apr 2012 14:41:35 +0000 Received: from 011-DB3MPN1-013.MGDPHG.emi.philips.com ([169.254.3.240]) by 011-DB3MMR1-009.MGDPHG.emi.philips.com ([10.128.28.48]) with mapi id 14.01.0355.003; Thu, 12 Apr 2012 15:44:02 +0100 From: "Dijk, Esko" To: Alper Yegin , "core@ietf.org WG" Thread-Topic: [core] coap-09 review (security) Thread-Index: AQHNEyNqIj9Us1Si6Umc72RwIW8ya5aXSLdQ Date: Thu, 12 Apr 2012 14:44:01 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618092D61@011-DB3MPN1-013.MGDPHG.emi.philips.com> References: <2EE78B1C-6680-4ED2-974D-6B6550086FF1@yegin.org> In-Reply-To: <2EE78B1C-6680-4ED2-974D-6B6550086FF1@yegin.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.101] Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED618092D61011DB3MPN1013MGDP_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: Re: [core] coap-09 review (security) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 14:41:46 -0000 --_000_031DD135F9160444ABBE3B0C36CED618092D61011DB3MPN1013MGDP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alper, > Section 10.3.3 > > CoAP also supports the use of multicast IP addresses in requests, an > important requirement for M2M. Multicast CoAP requests may be the > source of accidental or deliberate denial of service attacks, > especially over constrained networks. This specification attempts to > reduce the amplification effects of multicast requests by limiting > when a response is returned. To limit the possibility of malicious > use, CoAP servers SHOULD NOT accept multicast requests that can not > be authenticated. > > Alper> Why not "MUST NOT accept"? Again, unless there is a valid reason t= o relax this rule, > we'd be opening a potential hole without a good justification. There was a previous discussion on why the "SHOULD NOT" is used here, see e= .g. reasons http://www.ietf.org/mail-archive/web/core/current/msg02477.html I assumed by the way that having L2 security does not mean requests are "au= thenticated" , while Carsten suggested in this thread that having L2 securi= ty does constitute a form of authentication (belonging to a group) if that = level of authentication is sufficient for the application. Using my interpr= etation would mean that banning unauthenticated multicast implies banning m= ulticast alltogether. Esko From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Alp= er Yegin Sent: Thursday 5 April 2012 13:58 To: core@ietf.org WG Subject: [core] coap-09 review (security) Hello, Please see below for my review comments on CoAP security. Section 10. NoSec: There is no protocol level security (DTLS is disabled). Alternative techniques to provide lower layer security SHOULD be used when appropriate. The use of IPsec is discussed in Section 10.2. Alper> This "SHOULD when appropriate" is likely to lead to use of "insuffic= ient" solutions. Without clear guidance, people cannot know if their altern= ative is really "appropriate", and they'd most probably be unreasonably opt= imistic about it. We need to provide some guidance here. Otherwise we are l= eaving a security hole behind. PreSharedKey: DTLS is enabled and there is a list of pre-shared keys and each key includes a list of which nodes it can be used to communicate with as described in Section 10.1.1. At the extreme there may be one key for each node this CoAP node needs to communicate with (1:1 node/key ratio). Alper> Pairwise PSK (1:1) is what we should recommend, if not mandate. Anyt= hing less than that (PSK shared among multiple entities) is weak security. = We should discourage, if not prohibit it. Certificate: DTLS is enabled and the device has an asymmetric key pair with an X.509 [RFC5280] cert= ificate that binds it to its Authority Name and is signed by some common trust root as described in Section 10.1.3. The device also has a list of root trust anchors that can be used for validating a certificate. Alper> For this to interoperate "out-of the box", we need to make sure the = device is provisioned with the public key of Root CA that signed the other = end-point's cert. There needs to be some coordination, as random selection = of root CAs would fail interop. Need to be clear about that, otherwise peop= le think putting a cert on the device gets them a fully interoperating solu= tion. Section 10.1.3 When a new connection is formed, the certificate from the remote device needs to be verified. If the CoAP node has a source of absolute time, then the node SHOULD check the validity dates are of Alper> Why not "MUST check"? Unless there is a valid reason to relax this r= ule, we'd be opening a potential hole without a good justification. Section 10.3.3 CoAP also supports the use of multicast IP addresses in requests, an important requirement for M2M. Multicast CoAP requests may be the source of accidental or deliberate denial of service attacks, especially over constrained networks. This specification attempts to reduce the amplification effects of multicast requests by limiting when a response is returned. To limit the possibility of malicious use, CoAP servers SHOULD NOT accept multicast requests that can not be authenticated. Alper> Why not "MUST NOT accept"? Again, unless there is a valid reason to = relax this rule, we'd be opening a potential hole without a good justificat= ion. Section 10.3.4 Due to the lack of a handshake in UDP, a rogue endpoint which is free to read and write messages carried by the constrained network (i.e. NoSec or PreSharedKey deployments with nodes/key ratio > 1:1), Alper> We shall advise against "nodes/key ratio > 1:1:", if not prohibit... Section 10.3.5 o the attacker sends a message to a CoAP end-point with a fake source address, o the CoAP end-point replies with a message to the given source address, o the victim at the given source address receives a UDP packet that it interprets according to the rules of a different protocol. Alper> Assuming the victim is listening on the src port used by the attacke= r, right? And the victim is in server mode ready to accept asynchronously s= ent request packets (otherwise, there'd be some state on the victim which w= ould be harder to match with the reflect packet). Appendix D.1 The RawPublicKey mode was designed to be easily provisioned in M2M deployments. It is assumed that each device has an appropriate asymmetric public key pair installed, and an identity from that public key has been calculated as described in Appendix D.1.1. During provisioning, the identity of each node is collected, for example by reading a barcode on the outside of the device or by obtaining a pre-compiled list of the identities. These identities are then installed in the corresponding end-point, for example an M2M data collection server. The identity is used for two purposes, to associate the end-point with further device information and to perform access control. During provisioning, an access control list of identities the device may start DTLS sessions with SHOULD also be installed. Alper> Either that SHALL happen, or the device SHALL securely learn the IDs= by some other means. We cannot possibly be more specific than that, but we shall force "secure l= earning". Appendix D.2.2 In this mode the identity of the public key for a device is used for access control. An end-point SHOULD keep a list of identities that it allows to access its resource, and MAY also support more detailed access control on the method or resource level. When a DTLS session is negotiated, a CoAP server that has an access control list MUST check the identity of the client. This is done by calculating the identity of the client's public key as described in Appendix D.1.1. A client SHOULD also verify the identity of the server if it has been configured with the appropriate access control list. Alper> "MUST also verify". Alper> I'd even say remove "if it has been configured with the appropriate = access control list." What we don't know is how that access control list got on the device -- pre= -provisoning, some other secure means, etc. But we know that we must use it= , otherwise we are not talking about a secure solution. If we are thinking = about some cases where it does not matter who the device is communicating w= ith, then we can blend in "policy" into the text. For example, according to= such policy, device may not care about the identity of its peer in certain= types of communication (e.g., sending the temperature reading of a public = place). Regards, Alper ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_031DD135F9160444ABBE3B0C36CED618092D61011DB3MPN1013MGDP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Alper,

 

There was a previous discussion on why the “SH= OULD NOT” is used here, see e.g. reasons

http://www.ietf.org/mail-archive/web/core/current/m= sg02477.html

 

I assumed by the way that having L2 security does no= t mean requests are “authenticated” , while Carsten suggested i= n this thread that having L2 security does constitute a form of authenticat= ion (belonging to a group) if that level of authentication is sufficient for the application. Using my interpretation would mean that= banning unauthenticated multicast implies banning multicast alltogether.

 

Esko

 

From: core-b= ounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Alper Yegin
Sent: Thursday 5 April 2012 13:58
To: core@ietf.org WG
Subject: [core] coap-09 review (security)

 

Hello,

 

Please see below for my review comments on CoAP secu= rity.

 

Section 10.

 

      Section 10.2.

Section 10.1.1.  At the ex= treme

RFC5280] certificat= e that binds it to its

Section 10.1.3.  The devic= e also has a list of root

Appendix D.1.1.

Appendix D.1.1.

The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
--_000_031DD135F9160444ABBE3B0C36CED618092D61011DB3MPN1013MGDP_-- From ashwin.ietf@gmail.com Thu Apr 12 07:47:59 2012 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 5AF6721F864A for ; Thu, 12 Apr 2012 07:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zst449kxjxz for ; Thu, 12 Apr 2012 07:47:58 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id C4BC121F857A for ; Thu, 12 Apr 2012 07:47:58 -0700 (PDT) Received: by yhkk25 with SMTP id k25so1235051yhk.31 for ; Thu, 12 Apr 2012 07:47:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TMoqkL/M8gYBOJDdxKfft4dopi+TUEmusZDNUeKHnQE=; b=AmqErd/a+GzHDEiGTlq4CvgQ3XjAy9ZRAF4xnsgTHTGuPXtE7+SWV5uEnE2UTeOrlt hCT4ebdhqHOKNZvNbeR/Lw7o3sl+DfQpA4Umhj8oqJcqBmySIn5X8AmadIeIUu9kPVB4 dNd+iWHWDR0W5S/v71/oeFDRjRSUdsHAL988EvRJB8k+xA7wT620dbhOzTno1K3sRlUo 9Lzc64DaLXszZgQKQuupI3H7eGSXhTPGNoQKcaDt37+QRf91wAlK4yzLdDLLOu4gCtIX bh85Ej4FrlPbb/wQTt9XntlLvbJpoRj+tSw1tZ1f3DggkCL4dqqcHtK+XB5Ob1vdPd87 la1g== MIME-Version: 1.0 Received: by 10.50.186.166 with SMTP id fl6mr2935438igc.47.1334242078070; Thu, 12 Apr 2012 07:47:58 -0700 (PDT) Received: by 10.64.15.41 with HTTP; Thu, 12 Apr 2012 07:47:58 -0700 (PDT) In-Reply-To: <12A89EC7-FD4B-41DE-BA70-D560ECEEDC60@tzi.org> References: <12A89EC7-FD4B-41DE-BA70-D560ECEEDC60@tzi.org> Date: Thu, 12 Apr 2012 20:17:58 +0530 Message-ID: From: Ashwin Sinha To: Carsten Bormann Content-Type: multipart/alternative; boundary=14dae9340db11b95b604bd7c71d6 Cc: core@ietf.org Subject: Re: [core] draft-ietf-core-block-08 - Block Negotiation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 14:47:59 -0000 --14dae9340db11b95b604bd7c71d6 Content-Type: text/plain; charset=ISO-8859-1 > Also this might be an invalid question, the exchange is always a > client-server model, there cannot be any proxies in between? If so can they > modify this packet size, and how will this be handled. > > >>An intermediary could map a single client request to multiple requests > to the upstream server or v.v.; this is particularly easy with a >>caching > proxy. A very simple (stateless) intermediary would simply negotiate down > the block size to a value comfortable to both its >>client and the origin > server. The protocol only describes the interaction between client and > proxy and the interaction between proxy >>and origin server; it is the job > of the proxy to make sure the semantics are maintained. > I wonder if it would be better to have a mechanism, which lets the proxies know that they cannot go below a certain threshold. Like for instance as a client I dont want my block size to be lesser than 64, and i start initial negotiation with block size as 128, now I dont want any proxy making this size less than 64. Regards Ashwin --14dae9340db11b95b604bd7c71d6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

> Also this might be an invalid question, the exchange= is always a client-server model, there cannot be any proxies in between? I= f so can they modify this packet size, and how will this be handled.

>>An intermediary could map a single client request to mult= iple requests to the upstream server or v.v.; this is particularly easy wit= h a >>caching proxy. =A0A very simple (stateless) intermediary would = simply negotiate down the block size to a value comfortable to both its >= ;>client and the origin server. =A0The protocol only describes the inter= action between client and proxy and the interaction between proxy >>a= nd origin server; it is the job of the proxy to make sure the semantics are= maintained.
=A0
=A0=A0 I wonder if it would be better to have a mechanism, which lets = the proxies know that they cannot go below a certain threshold. Like for=A0= =A0 instance as a client I dont want my block size to be lesser than 64, an= d i start initial negotiation with block size as 128, now I dont want any p= roxy making this size less than 64.
=A0
=A0 Regards
=A0 Ashwin
=A0


=A0

--14dae9340db11b95b604bd7c71d6-- From cabo@tzi.org Thu Apr 12 11:24:44 2012 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 353F721F84EF for ; Thu, 12 Apr 2012 11:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.424 X-Spam-Level: X-Spam-Status: No, score=-104.424 tagged_above=-999 required=5 tests=[AWL=-1.825, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRJLataTvrnk for ; Thu, 12 Apr 2012 11:24:43 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 71B0121F84E6 for ; Thu, 12 Apr 2012 11:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3CIOXPI003052; Thu, 12 Apr 2012 20:24:35 +0200 (CEST) Message-Id: From: Carsten Bormann To: Ashwin Sinha In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 12 Apr 2012 20:24:32 +0200 References: <12A89EC7-FD4B-41DE-BA70-D560ECEEDC60@tzi.org> X-Mailer: Apple Mail (2.936) Cc: core@ietf.org Subject: Re: [core] draft-ietf-core-block-08 - Block Negotiation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 18:24:44 -0000 > I wonder if it would be better to have a mechanism, which lets > the proxies know that they cannot go below a certain threshold. Like > for instance as a client I dont want my block size to be lesser > than 64, and i start initial negotiation with block size as 128, now > I dont want any proxy making this size less than 64. I haven't heard about a usecase where there is a lower bound that one endpoint would want to impose on another one. If the proxy wants to go to 32 and there is a reason why that is a problem for the client, maybe that should use another proxy. (Inversely, if you program a proxy, you shouldn't lower the block size unless there is a reason for that.) But maybe I simply don't know enough about your usecase. Gruesse, Carsten From tho@koanlogic.com Fri Apr 13 01:30:16 2012 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 401FB21F8782 for ; Fri, 13 Apr 2012 01:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dC8vkRWFvRg for ; Fri, 13 Apr 2012 01:30:15 -0700 (PDT) Received: from gonzo.koanlogic.com (koanlogic.com [64.251.31.111]) by ietfa.amsl.com (Postfix) with ESMTP id 8674121F8781 for ; Fri, 13 Apr 2012 01:30:15 -0700 (PDT) Received: from chello084112045229.2.11.vie.surfer.at ([84.112.45.229]:53298 helo=[172.16.101.93]) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1SIbtG-0003MY-Px for core@ietf.org; Fri, 13 Apr 2012 04:30:14 -0400 From: Thomas Fossati Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Apr 2012 10:29:56 +0200 Message-Id: To: core WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 84.112.45.229 X-SA-Exim-Mail-From: tho@koanlogic.com X-Spam-DCC: : X-Spam-Pyzor: Reported 0 times. X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on gonzo.koanlogic.com) Subject: [core] draft-core-coap-09 Uri-Port X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 08:30:16 -0000 Section 5.10.2 says: "The default Uri-Host and Uri-Port options are sufficient for requests = to most servers, and are typically used when an endpoint hosts multiple virtual servers." which is quite confusing since "and ... typically" seems to refer to the = default values while the opposite is meant. I would rephrase that with = something like: "The default values of Uri-Host and Uri-Port options are sufficient for = requests to most servers. Explicit Uri-Host and Uri-Port are typically = used when an endpoint hosts multiple virtual servers." I have also a minor concern about a zero-length Uri-Port: it would = default to UDP port 0, which is reserved. In principle an explicit = Uri-Port should have no strict relation to the underlying protocol port, = thus a 0 value should be fine anyway. [So, this is just a note to check if everyone agrees on this = interpretation.]= From trac+core@trac.tools.ietf.org Fri Apr 13 01:44:39 2012 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 8ABF521F87A1 for ; Fri, 13 Apr 2012 01:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P416V4dtOKTN for ; Fri, 13 Apr 2012 01:44:38 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 89C1621F879F for ; Fri, 13 Apr 2012 01:44:38 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SIc7A-0005Mw-SA; Fri, 13 Apr 2012 04:44:20 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Fri, 13 Apr 2012 08:44:20 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/208 Message-ID: <051.84365211a7b3ff2c11cb254d636ac5ca@trac.tools.ietf.org> X-Trac-Ticket-ID: 208 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120413084438.89C1621F879F@ietfa.amsl.com> Resent-Date: Fri, 13 Apr 2012 01:44:38 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #208: Fix editing error in 5.10.2 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.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: Fri, 13 Apr 2012 08:44:39 -0000 #208: Fix editing error in 5.10.2 Thomas Fossati notes misleading language that was introduced in 5.10.2 in coap-07 re Uri-Host and Uri-Port: "The default Uri-Host and Uri-Port options are sufficient for requests to most servers, and are typically used when an endpoint hosts multiple virtual servers." which is quite confusing since "and ... typically" seems to refer to the default values while the opposite is meant. I would rephrase that with something like: "The default values of Uri-Host and Uri-Port options are sufficient for requests to most servers. Explicit Uri-Host and Uri-Port are typically used when an endpoint hosts multiple virtual servers." -- -----------------------------+------------------------------------ Reporter: cabo@… | Owner: draft-ietf-core-coap@… Type: editorial | Status: new Priority: minor | Milestone: post-WGLC-1 Component: coap | Version: Severity: In WG Last Call | Keywords: -----------------------------+------------------------------------ Ticket URL: core From cabo@tzi.org Fri Apr 13 01:53:15 2012 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 2B33921F846F for ; Fri, 13 Apr 2012 01:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFoKPUG5c8Aw for ; Fri, 13 Apr 2012 01:53:14 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDAB21F847B for ; Fri, 13 Apr 2012 01:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3D8r6Mp001286; Fri, 13 Apr 2012 10:53:06 +0200 (CEST) Received: from [192.168.217.105] (p5B3E629A.dip.t-dialin.net [91.62.98.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 39D69D51; Fri, 13 Apr 2012 10:53:06 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Fri, 13 Apr 2012 10:53:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Thomas Fossati X-Mailer: Apple Mail (2.1257) Cc: core WG Subject: Re: [core] draft-core-coap-09 Uri-Port X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 08:53:15 -0000 On Apr 13, 2012, at 10:29, Thomas Fossati wrote: > Section 5.10.2 says: [...] Yes, this is wrong and clearly needs to be fixed. Now #208. > I have also a minor concern about a zero-length Uri-Port: it would = default to UDP port 0, which is reserved. In principle an explicit = Uri-Port should have no strict relation to the underlying protocol port, = thus a 0 value should be fine anyway. > [So, this is just a note to check if everyone agrees on this = interpretation.] Right. As another data point, RFC 3986 does not go to the trouble of = restricting port numbers either. A more general point (also supporting staying with the current status): = I would prefer to refrain from attempting to express range constraints = on uints by setting up a minimum number of bytes used. You can still = send a 0 value as a 1-byte or 2-byte uint, so taking out the 0-byte form = does not accomplish anything. It just creates the need to add code for = checking the length. No other uint in CoAP needs a minimum length check = at this point, and I would like to keep it that way. Gr=FC=DFe, Carsten From tho@koanlogic.com Fri Apr 13 06:27:25 2012 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 3F4BC21F85DF for ; Fri, 13 Apr 2012 06:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BqSAjXVKXMh for ; Fri, 13 Apr 2012 06:27:24 -0700 (PDT) Received: from gonzo.koanlogic.com (koanlogic.com [64.251.31.111]) by ietfa.amsl.com (Postfix) with ESMTP id A9C3D21F85D4 for ; Fri, 13 Apr 2012 06:27:24 -0700 (PDT) Received: from chello084112045229.2.11.vie.surfer.at ([84.112.45.229]:55590 helo=[172.16.101.93]) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1SIgWu-0004AP-L8; Fri, 13 Apr 2012 09:27:22 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: Date: Fri, 13 Apr 2012 15:27:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Carsten Bormann X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 84.112.45.229 X-SA-Exim-Mail-From: tho@koanlogic.com X-Spam-DCC: : X-Spam-Pyzor: Reported 0 times. X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on gonzo.koanlogic.com) Cc: core WG Subject: Re: [core] draft-core-coap-09 Uri-Port X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 13:27:25 -0000 On Apr 13, 2012, at 10:53 AM, Carsten Bormann wrote: >> I have also a minor concern about a zero-length Uri-Port: it would = default to UDP port 0, which is reserved. In principle an explicit = Uri-Port should have no strict relation to the underlying protocol port, = thus a 0 value should be fine anyway. >> [So, this is just a note to check if everyone agrees on this = interpretation.] >=20 > Right. As another data point, RFC 3986 does not go to the trouble of = restricting port numbers either. Exactly, they are just DIGITs. And, more importantly, it does not bind = in any way an explicit port value in the URI to the port actually used = by the transport protocol to access the service that hosts the resource. = =20 > A more general point (also supporting staying with the current = status): I would prefer to refrain from attempting to express range = constraints on uints by setting up a minimum number of bytes used. You = can still send a 0 value as a 1-byte or 2-byte uint, so taking out the = 0-byte form does not accomplish anything. It just creates the need to = add code for checking the length. No other uint in CoAP needs a minimum = length check at this point, and I would like to keep it that way. Sounds perfectly reasonable to me. I also agree that requiring minimal = length checks is a non-sense unless we decide to force an "use always = the minimum number of bytes" constraint on CoAP uint encoders. Anyway, my point was fairly limited in scope :-) just trying to remove = any ambiguity WRT the "0" value as a valid value for the Uri-Port = option.= From tho@koanlogic.com Fri Apr 13 16:11:46 2012 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 06CE421F8607 for ; Fri, 13 Apr 2012 16:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubz6ASi0lB4J for ; Fri, 13 Apr 2012 16:11:45 -0700 (PDT) Received: from gonzo.koanlogic.com (koanlogic.com [64.251.31.111]) by ietfa.amsl.com (Postfix) with ESMTP id 9531D21F85F6 for ; Fri, 13 Apr 2012 16:11:45 -0700 (PDT) Received: from chello062178222142.13.15.univie.teleweb.at ([62.178.222.142]:60808 helo=[192.168.0.11]) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1SIpeT-0005nN-GA for core@ietf.org; Fri, 13 Apr 2012 19:11:44 -0400 From: Thomas Fossati Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 14 Apr 2012 01:11:35 +0200 Message-Id: <6029ED8C-2341-4199-A439-F0DB02A55DA4@koanlogic.com> To: core WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 62.178.222.142 X-SA-Exim-Mail-From: tho@koanlogic.com X-Spam-DCC: : X-Spam-Pyzor: Reported 0 times. X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on gonzo.koanlogic.com) Subject: [core] draft-ietf-core-link-format-11 - discover virtual hosted resources X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 23:11:46 -0000 We have a couple of points in coap-09 where virtual hosting comes up: = one is the (recommended) support of SNI in order to discriminate vhosts = on a DTLS secured tunnel, the other is about the use of explicit = Uri-Host and Uri-Port to demultiplex different origins on the same = endpoint. So it seems that a CoAP endpoint should be prepared to survive in = environments where resources have non trivial authorities (by "trivial = authority" I mean resources whose host:port can be inferred from the = transport protocol.) Yet, I could not find any text in link-format-11 explaining how virtual = hosted resources can be advertised by the hosting endpoint. At first one could imagine to just use an absolute URI for the target = link, and that would solve all the problems. But then, how should the = querying endpoint interpret an explicit port in the link ? E.g. if the = discovered target URI is , then 123 is to be taken = as the UDP port at which the server must be contacted, or just as the = value to fill the Uri-Port option ? Uri-Port is really nice (if only because it allows virtual hosting with = just 2-3 bytes of overhead), but is it actually usable if it does not = fit into the discovery mechanism ?= From hartke@tzi.org Fri Apr 13 16:43:09 2012 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 1DFBC11E813E for ; Fri, 13 Apr 2012 16:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mLubRaN-YVe for ; Fri, 13 Apr 2012 16:43:08 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id D2E8E11E8138 for ; Fri, 13 Apr 2012 16:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3DNgu5D025265 for ; Sat, 14 Apr 2012 01:42:56 +0200 (CEST) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 696FFB1 for ; Sat, 14 Apr 2012 01:42:56 +0200 (CEST) Received: by dady13 with SMTP id y13so6225893dad.27 for ; Fri, 13 Apr 2012 16:42:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.213.41 with SMTP id np9mr8327152pbc.85.1334360574213; Fri, 13 Apr 2012 16:42:54 -0700 (PDT) Received: by 10.68.23.37 with HTTP; Fri, 13 Apr 2012 16:42:54 -0700 (PDT) In-Reply-To: <6029ED8C-2341-4199-A439-F0DB02A55DA4@koanlogic.com> References: <6029ED8C-2341-4199-A439-F0DB02A55DA4@koanlogic.com> Date: Sat, 14 Apr 2012 01:42:54 +0200 Message-ID: From: Klaus Hartke To: core WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [core] draft-ietf-core-link-format-11 - discover virtual hosted resources X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 23:43:09 -0000 On 14 April 2012 01:11, Thomas Fossati wrote: > how should the querying endpoint interpret an explicit port in the link ?= =A0E.g. if the discovered target URI is , then 123 is= to be taken as the UDP port at which the server must be contacted, or just= as the value to fill the Uri-Port option ? Since it's a coap:// URI, I'd assume that coap-09 Section 6.1 applies: The port subcomponent indicates the UDP port at which the CoAP server is located. The Uri-Port option is mostly useful where a server forwards a request to another node that needs to be able to reconstruct the original request URI. Klaus From tho@koanlogic.com Sat Apr 14 01:25:28 2012 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 A9AD921F85C7 for ; Sat, 14 Apr 2012 01:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFXqnU4cOvFM for ; Sat, 14 Apr 2012 01:25:28 -0700 (PDT) Received: from gonzo.koanlogic.com (koanlogic.com [64.251.31.111]) by ietfa.amsl.com (Postfix) with ESMTP id 1433D21F85C3 for ; Sat, 14 Apr 2012 01:25:27 -0700 (PDT) Received: from chello062178222142.13.15.univie.teleweb.at ([62.178.222.142]:61957 helo=[192.168.0.11]) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1SIyIJ-0006Je-KY; Sat, 14 Apr 2012 04:25:26 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: Date: Sat, 14 Apr 2012 10:25:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <24D06E23-41E2-4EAD-B26F-4A289F3284D5@koanlogic.com> References: <6029ED8C-2341-4199-A439-F0DB02A55DA4@koanlogic.com> To: Klaus Hartke X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 62.178.222.142 X-SA-Exim-Mail-From: tho@koanlogic.com X-Spam-DCC: : X-Spam-Pyzor: Reported 0 times. X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on gonzo.koanlogic.com) Cc: core WG Subject: Re: [core] draft-ietf-core-link-format-11 - discover virtual hosted resources X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 14 Apr 2012 08:25:28 -0000 Hi Klaus, On Apr 14, 2012, at 1:42 AM, Klaus Hartke wrote: > On 14 April 2012 01:11, Thomas Fossati wrote: >> how should the querying endpoint interpret an explicit port in the = link ? E.g. if the discovered target URI is , then = 123 is to be taken as the UDP port at which the server must be = contacted, or just as the value to fill the Uri-Port option ? >=20 > Since it's a coap:// URI, I'd assume that coap-09 Section 6.1 applies: >=20 > The port subcomponent indicates the UDP port at which > the CoAP server is located. ok, that's also my understanding. But then you can't do virtual hosting = based on the Uri-Port value because it is 1:1 with the underlying = transport protocol port, and as such it can always be inferred by the = context. Basically, if your interpretation (which I share) holds, I don't get the = value added by the Uri-Port option. At least related to the vhosting = argument. > The Uri-Port option is mostly useful where a server forwards a request > to another node that needs to be able to reconstruct the original > request URI. Sorry but I don't get it. The Proxy-Uri seem to have all the = information. Could you please give me an example ? Thanks, t.= From cabo@tzi.org Sat Apr 14 04:20:50 2012 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 478C521F862F for ; Sat, 14 Apr 2012 04:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.284 X-Spam-Level: X-Spam-Status: No, score=-104.284 tagged_above=-999 required=5 tests=[AWL=-1.685, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfacRyVQf-cd for ; Sat, 14 Apr 2012 04:20:49 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 7406921F8581 for ; Sat, 14 Apr 2012 04:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3EBKbA4027129; Sat, 14 Apr 2012 13:20:40 +0200 (CEST) Message-Id: <44099349-5522-4DB8-B1A3-A7A90222B0D4@tzi.org> From: Carsten Bormann To: Thomas Fossati In-Reply-To: <24D06E23-41E2-4EAD-B26F-4A289F3284D5@koanlogic.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 14 Apr 2012 13:20:37 +0200 References: <6029ED8C-2341-4199-A439-F0DB02A55DA4@koanlogic.com> <24D06E23-41E2-4EAD-B26F-4A289F3284D5@koanlogic.com> X-Mailer: Apple Mail (2.936) Cc: core WG , Klaus Hartke Subject: Re: [core] draft-ietf-core-link-format-11 - discover virtual hosted resources X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 14 Apr 2012 11:20:50 -0000 On Apr 14 2012, at 10:25, Thomas Fossati wrote: > Sorry but I don't get it. The Proxy-Uri seem to have all the > information. On the leg that uses a Proxy-Uri option, yes. Not all legs for all use cases for intermediaries do. > Could you please give me an example ? Imagine a reverse proxy that distributes queries to origin servers based on some criteria (say, Uri-Path). Towards to origin server, the fully decoded form of options (Uri-*) is used. On the way between the reverse proxy and the origin server, the reverse proxy could use Uri-Port to indicate the port number that was originally used for the request (i.e., towards the reverse proxy). That is a bit of a special use case, but it is good to be able to express Uri-Port in the last leg to the origin server. Now where does the reverse proxy get the configuration that tells it what origin server to use, and at what port number? That is outside the scope here. One assumption is that the link-format is a good source for such configuration information, but we are not completely specifying this case. I think what you are complaining about is that we don't have a good way to express configuration for such a case in the form of a URI. (I think the fact that this becomes visible in link-format is just a reflection on us using URIs in link-format.) The reason the same considerations do not apply to Uri-Host is that we assume to have some form of indirection here (such as DNS) mapping reg- name style host parts to IP addresses, so it is common to have multiple reg-name style host parts map to the same IP address (at least in HTTP land). We don't assume to have that indirection for port numbers, so the main use case for Uri-Host does not apply to Uri-Port. Gruesse, Carsten From tho@koanlogic.com Sat Apr 14 09:44:50 2012 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 E5DCF21F854F for ; Sat, 14 Apr 2012 09:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpnik13sup1M for ; Sat, 14 Apr 2012 09:44:50 -0700 (PDT) Received: from gonzo.koanlogic.com (koanlogic.com [64.251.31.111]) by ietfa.amsl.com (Postfix) with ESMTP id 6264A21F84D2 for ; Sat, 14 Apr 2012 09:44:50 -0700 (PDT) Received: from chello062178222142.13.15.univie.teleweb.at ([62.178.222.142]:64863 helo=[192.168.0.11]) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1SJ65Y-0006tf-VM; Sat, 14 Apr 2012 12:44:48 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: <44099349-5522-4DB8-B1A3-A7A90222B0D4@tzi.org> Date: Sat, 14 Apr 2012 18:44:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <69A23C24-A968-4D47-A6A3-8455E9774008@koanlogic.com> References: <6029ED8C-2341-4199-A439-F0DB02A55DA4@koanlogic.com> <24D06E23-41E2-4EAD-B26F-4A289F3284D5@koanlogic.com> <44099349-5522-4DB8-B1A3-A7A90222B0D4@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 62.178.222.142 X-SA-Exim-Mail-From: tho@koanlogic.com X-Spam-DCC: : X-Spam-Pyzor: Reported 0 times. X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on gonzo.koanlogic.com) Cc: core WG , Klaus Hartke Subject: Re: [core] draft-ietf-core-link-format-11 - discover virtual hosted resources X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 14 Apr 2012 16:44:51 -0000 Hi Carsten,=20 thank you very much for taking the time to provide such detailed = explanation. > Imagine a reverse proxy that distributes queries to origin servers = based on some criteria (say, Uri-Path). > Towards to origin server, the fully decoded form of options (Uri-*) is = used. > On the way between the reverse proxy and the origin server, the = reverse proxy could use Uri-Port to indicate the port number that was = originally used for the request (i.e., towards the reverse proxy). >=20 > That is a bit of a special use case, but it is good to be able to = express Uri-Port in the last leg to the origin server. If I understand correctly, you are saying that the reverse proxy may use = the Uri-Port as a variable to both govern the routing towards the origin = servers, and give these origins a parameter that they can use to select = the final resource that has to be served. Anyway, a reverse proxy "owns" the namespace and can organize it at its = complete will, and also use an URI-mapping ruleset of choice. The same granularity that is obtained in your example using the = Uri-Port, may be easily achieved using an URI-mapping that moves the = port (be it implicit or explicit) from the original URI to e.g. the = first segment of the mapped URI: (UA) -> http://P:255/a/res -> (P) -> coap://A/255/res -> (A) So, strictly speaking, the Uri-Port is not crucial to make this scenario = work, right ? > I think what you are complaining about is that we don't have a good = way to express configuration for such a case in the form of a URI. Basically, what I'm complaining about is that virtual hosting based on = Uri-Port's works only if the client has a complete a-priori knowledge of = the resource it has to access (so that it can contact server S at UDP = port 5683 with Uri-Port 255 -- fantastic: 2 bytes vhosting!). But there is no way for the client to get this information through = discovery, which makes the whole cause for Uri-Port a little fragile. ciao, t.= From cabo@tzi.org Sat Apr 14 10:29:02 2012 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 775B721F84D2 for ; Sat, 14 Apr 2012 10:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.405 X-Spam-Level: X-Spam-Status: No, score=-106.405 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKebScgvoK-L for ; Sat, 14 Apr 2012 10:29:02 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id B5BAB21F84C4 for ; Sat, 14 Apr 2012 10:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3EHSsfD021191; Sat, 14 Apr 2012 19:28:54 +0200 (CEST) Received: from [192.168.217.105] (p5489B1DA.dip.t-dialin.net [84.137.177.218]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 505FE15D; Sat, 14 Apr 2012 19:28:54 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <69A23C24-A968-4D47-A6A3-8455E9774008@koanlogic.com> Date: Sat, 14 Apr 2012 19:28:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6029ED8C-2341-4199-A439-F0DB02A55DA4@koanlogic.com> <24D06E23-41E2-4EAD-B26F-4A289F3284D5@koanlogic.com> <44099349-5522-4DB8-B1A3-A7A90222B0D4@tzi.org> <69A23C24-A968-4D47-A6A3-8455E9774008@koanlogic.com> To: Thomas Fossati X-Mailer: Apple Mail (2.1257) Cc: core WG , Klaus Hartke Subject: Re: [core] draft-ietf-core-link-format-11 - discover virtual hosted resources X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 14 Apr 2012 17:29:02 -0000 On Apr 14, 2012, at 18:44, Thomas Fossati wrote: > So, strictly speaking, the Uri-Port is not crucial to make this = scenario work, right ? Indeed, no. There are many ways to skin a URI. (With that argument, we might decide to get rid of Uri-Query, too... = Well, that would be radical.) So, are you arguing for removing Uri-Port from the specification? YAGNI is a strong argument, but it might be hard to put back Uri-Port = when we do need it if we want to maintain the order of URI elements in = the option sequence. Gr=FC=DFe, Carsten From tho@koanlogic.com Sat Apr 14 11:19:04 2012 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 1B8C421F85B1 for ; Sat, 14 Apr 2012 11:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3ngEXgrpJ-w for ; Sat, 14 Apr 2012 11:19:03 -0700 (PDT) Received: from gonzo.koanlogic.com (koanlogic.com [64.251.31.111]) by ietfa.amsl.com (Postfix) with ESMTP id 84F8F21F85AA for ; Sat, 14 Apr 2012 11:19:03 -0700 (PDT) Received: from chello062178222142.13.15.univie.teleweb.at ([62.178.222.142]:49275 helo=[192.168.0.11]) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1SJ7Yk-00070H-Ng for core@ietf.org; Sat, 14 Apr 2012 14:19:01 -0400 From: Thomas Fossati Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 14 Apr 2012 20:18:51 +0200 Message-Id: <6ECE6686-6624-4B59-8629-00A24B00E0D7@koanlogic.com> To: core WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 62.178.222.142 X-SA-Exim-Mail-From: tho@koanlogic.com X-Spam-DCC: : X-Spam-Pyzor: Reported 0 times. X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on gonzo.koanlogic.com) Subject: [core] draft-ietf-core-coap-09 - Authority Name issues with SNI and X.509 certificate X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 14 Apr 2012 18:19:04 -0000 Section 10.1.3. says: "The Authority Name in the certificate is the name that would be used in = the Authority part of a CoAP URI." So it seems that a 'host [":" port]' syntax is to be assumed as = Authority Name, which gets quickly furry, both WRT the use of it in a = certificate , and in the SNI extension . The Authority Name should go into the subjectAltName in the X.509 = certificate, typically one of 'dNSName' or 'iPAddress' is used when = certificates are bound to hosts. But there is no room for the '[":" = port]' there, so none of them can be used in the general case. One = could then fall back on 'otherName', but then an OID needs to be = registered to allow a minimum degree of interop. The same, or worse, applies to the case where EUI-64 is used. RFC 6066 imposes the following restrictions on the server name format: - "the only server names supported are DNS hostnames" - "Literal IPv4 and IPv6 addresses are not permitted in HostName so, the claim "Devices SHOULD support the Server Name Indication (SNI) = to indicate their Authority Name in the SNI HostName" seems not = completely consistent with RFC 6066. Luckily "other name types may be added in the future (by an RFC that = updates this document)" but then we have to provide this new name format = for use in SNI for CoAP endpoints. As a side note, the text in 10.1.3.: "It is worth noting that this [the authority part of a CoAP URI] would = typically not be either an IP address or DNS name but would instead be a = long term unique identifier for the device such as the EUI-64" is not consistent with the host production in RFC 3986 (i.e. host =3D = IP-literal / IPv4address / reg-name), unless we want to go all the way = to IPvFuture :-) =20= From tho@koanlogic.com Sat Apr 14 11:36:36 2012 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 DD93D21F85A4 for ; Sat, 14 Apr 2012 11:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1zsSLI4REwR for ; Sat, 14 Apr 2012 11:36:36 -0700 (PDT) Received: from gonzo.koanlogic.com (koanlogic.com [64.251.31.111]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2B721F8597 for ; Sat, 14 Apr 2012 11:36:36 -0700 (PDT) Received: from chello062178222142.13.15.univie.teleweb.at ([62.178.222.142]:49406 helo=[192.168.0.11]) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1SJ7pk-00071B-UQ; Sat, 14 Apr 2012 14:36:36 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: Date: Sat, 14 Apr 2012 20:36:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <35F40BFC-EDF9-4102-BE6B-09E20CF927CA@koanlogic.com> References: <6029ED8C-2341-4199-A439-F0DB02A55DA4@koanlogic.com> <24D06E23-41E2-4EAD-B26F-4A289F3284D5@koanlogic.com> <44099349-5522-4DB8-B1A3-A7A90222B0D4@tzi.org> <69A23C24-A968-4D47-A6A3-8455E9774008@koanlogic.com> To: Carsten Bormann X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 62.178.222.142 X-SA-Exim-Mail-From: tho@koanlogic.com X-Spam-DCC: : X-Spam-Pyzor: Reported 0 times. X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on gonzo.koanlogic.com) Cc: core WG , Klaus Hartke Subject: Re: [core] draft-ietf-core-link-format-11 - discover virtual hosted resources X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 14 Apr 2012 18:36:37 -0000 On Apr 14, 2012, at 7:28 PM, Carsten Bormann wrote: > So, are you arguing for removing Uri-Port from the specification? > YAGNI is a strong argument, but it might be hard to put back Uri-Port = when we do need it if we want to maintain the order of URI elements in = the option sequence. I'm not taking any stance at present, my intent is just to clarify = things -- first of all to myself :-) Let's see what others say.= From tho@koanlogic.com Sat Apr 14 13:18:39 2012 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 8498721F8576 for ; Sat, 14 Apr 2012 13:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.505 X-Spam-Level: X-Spam-Status: No, score=-0.505 tagged_above=-999 required=5 tests=[AWL=-1.894, BAYES_00=-2.599, FRT_STOCK2=3.988] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlsIbxBC6mIv for ; Sat, 14 Apr 2012 13:18:39 -0700 (PDT) Received: from gonzo.koanlogic.com (koanlogic.com [64.251.31.111]) by ietfa.amsl.com (Postfix) with ESMTP id 2A28721F8572 for ; Sat, 14 Apr 2012 13:18:39 -0700 (PDT) Received: from chello062178222142.13.15.univie.teleweb.at ([62.178.222.142]:51680 helo=[192.168.0.11]) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1SJ9QV-00079q-GG for core@ietf.org; Sat, 14 Apr 2012 16:18:38 -0400 From: Thomas Fossati Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 14 Apr 2012 22:18:29 +0200 Message-Id: To: core WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 62.178.222.142 X-SA-Exim-Mail-From: tho@koanlogic.com X-Spam-DCC: : X-Spam-Pyzor: Reported 0 times. X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on gonzo.koanlogic.com) Subject: [core] draft-ietf-core-coap-09 - IPsec X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 14 Apr 2012 20:18:39 -0000 Admittedly, the following is just my eye-parser running -pedantic; = anyway here it is. Section 10.2. says: "The use of IPsec between CoAP end-points is transparent to the = application layer and does not require special consideration for a CoAP = implementation." The total transparency of IPsec to the application layer is not = completely true. Though there is no unified IPsec policy management interface, IPsec = implementations tend to provide their own interfaces to allow = applications to play with the SPD on a per socket basis -- usually via = setsockopt. So, perhaps it'd be better making explicit that each CoAP = implementation, depending on the policy management interface offered by = the underlying IPsec stack, may want to dynamically instruct the SPD to = setup a security association for a specific flow. Or something along these lines.= From zach@sensinode.com Sun Apr 15 10:47:47 2012 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 5A03621F882C for ; Sun, 15 Apr 2012 10:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpCe2t-6CWe2 for ; Sun, 15 Apr 2012 10:47:46 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 5406821F8740 for ; Sun, 15 Apr 2012 10:47:45 -0700 (PDT) Received: from [192.168.1.103] (188-67-173-1.bb.dnainternet.fi [188.67.173.1]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q3FHlgqx018881; Sun, 15 Apr 2012 20:47:43 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <6029ED8C-2341-4199-A439-F0DB02A55DA4@koanlogic.com> Date: Sun, 15 Apr 2012 20:47:40 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6029ED8C-2341-4199-A439-F0DB02A55DA4@koanlogic.com> To: Thomas Fossati X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] draft-ietf-core-link-format-11 - discover virtual hosted resources X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 15 Apr 2012 17:47:47 -0000 Thomas, On Apr 14, 2012, at 2:11 AM, Thomas Fossati wrote: > We have a couple of points in coap-09 where virtual hosting comes up: = one is the (recommended) support of SNI in order to discriminate vhosts = on a DTLS secured tunnel, the other is about the use of explicit = Uri-Host and Uri-Port to demultiplex different origins on the same = endpoint. >=20 > So it seems that a CoAP endpoint should be prepared to survive in = environments where resources have non trivial authorities (by "trivial = authority" I mean resources whose host:port can be inferred from the = transport protocol.) >=20 > Yet, I could not find any text in link-format-11 explaining how = virtual hosted resources can be advertised by the hosting endpoint. >=20 > At first one could imagine to just use an absolute URI for the target = link, and that would solve all the problems. But then, how should the = querying endpoint interpret an explicit port in the link ? E.g. if the = discovered target URI is , then 123 is to be taken = as the UDP port at which the server must be contacted, or just as the = value to fill the Uri-Port option ? >=20 > Uri-Port is really nice (if only because it allows virtual hosting = with just 2-3 bytes of overhead), but is it actually usable if it does = not fit into the discovery mechanism ? Actually, as a result of IETF last call, we are actually limiting the = scope of the "hosts" relation so that the context and target must be on = the same host. See ticket = http://trac.tools.ietf.org/wg/core/trac/ticket/193. What this means in practice is that the target for this relation has to = be on the same origin server. The result is that if the target is an = absolute URI, then the host part should be interpreted as a virtual host = name (and thus should be included in the Uri-Host option). The port of = that URI would however be interpreted as an actual port on the origin = server, thus this can't be used for identifying a virtual host in the = way you are thinking. There is no reason your virtual host name = couldn't be really short though and thus just as efficient as using the = Uri-Host field. Thanks for pointing the need for this out, I will be sure to include = clarifying text when closing that ticket.=20 Zach > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From tho@koanlogic.com Sun Apr 15 23:53:57 2012 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 5779421F86EB for ; Sun, 15 Apr 2012 23:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eg3Podvxl7LS for ; Sun, 15 Apr 2012 23:53:56 -0700 (PDT) Received: from gonzo.koanlogic.com (koanlogic.com [64.251.31.111]) by ietfa.amsl.com (Postfix) with ESMTP id D37BA21F8685 for ; Sun, 15 Apr 2012 23:53:56 -0700 (PDT) Received: from chello084112045229.2.11.vie.surfer.at ([84.112.45.229]:65218 helo=[172.16.101.93]) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1SJfoi-00012t-Nz; Mon, 16 Apr 2012 02:53:53 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: Date: Mon, 16 Apr 2012 08:53:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6E59D8B6-9C0F-425B-996A-4953AC94F339@koanlogic.com> References: <6029ED8C-2341-4199-A439-F0DB02A55DA4@koanlogic.com> To: Zach Shelby X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 84.112.45.229 X-SA-Exim-Mail-From: tho@koanlogic.com X-Spam-DCC: : X-Spam-Pyzor: Reported 0 times. X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on gonzo.koanlogic.com) Cc: core WG Subject: Re: [core] draft-ietf-core-link-format-11 - discover virtual hosted resources X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 06:53:57 -0000 > Thanks for pointing the need for this out, I will be sure to include = clarifying text when closing that ticket. Very good. Also, contextually adding an example in section 5 would be = great. Thanks.= From Bert.Greevenbosch@huawei.com Mon Apr 16 01:25:19 2012 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 2CA5321F86D5 for ; Mon, 16 Apr 2012 01:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2IDMPnjWP38 for ; Mon, 16 Apr 2012 01:25:18 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9BAF521F86EB for ; Mon, 16 Apr 2012 01:25:03 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEY30968; Mon, 16 Apr 2012 04:25:03 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 16 Apr 2012 01:22:20 -0700 Received: from SZXEML434-HUB.china.huawei.com (10.72.61.62) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 16 Apr 2012 01:22:19 -0700 Received: from SZXEML509-MBS.china.huawei.com ([10.82.67.53]) by szxeml434-hub.china.huawei.com ([10.72.61.62]) with mapi id 14.01.0323.003; Mon, 16 Apr 2012 16:22:14 +0800 From: Bert Greevenbosch To: "core@ietf.org" , "Dijk, Esko" Thread-Topic: [core] draft-ietf-core-block-08 - Block ordering Thread-Index: AQHNF6OeJdoOky+TUUGUhJgAfDkjEZaU0D2AgACb6wCAADR0gIAAyXsAgAAOaACAAC9EAIAGdQkg Date: Mon, 16 Apr 2012 08:22:13 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB628F74879@szxeml509-mbs> References: <031DD135F9160444ABBE3B0C36CED618092AF8@011-DB3MPN1-013.MGDPHG.emi.philips.com> <0EDC43A0-E85B-4E7C-A442-798576178C5A@tzi.org> <031DD135F9160444ABBE3B0C36CED618092CD3@011-DB3MPN1-013.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED618092CD3@011-DB3MPN1-013.MGDPHG.emi.philips.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.109.135] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [core] draft-ietf-core-block-08 - Block ordering X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 08:25:19 -0000 Hi all, A related issue: if the blocks are not sent in sequential order, how to ens= ure that an attacker cannot send absurd block numbers? For example, an implementation that just appends the total data it has rece= ived until now with zeros until the start of the latest received block, wou= ld create a very large resource when a received block number is very high. = This can be especially nasty as the attacker does not send much data to cre= ate this resource. For example: To setup the block transfer, an attacker first sends PUT with block no. 0, = block size 1024 and the more flag set to 0. The next block he sends has blo= ck number 200000. This corresponds to the block with byte positions 2048000= 00..204801023 in the original resource. The naive implementation could ther= efore create a file of 204801023 bytes, i.e. 195 MB! A topic for the "security considerations" section? Best regards, Bert -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Dij= k, Esko Sent: 12 April 2012 21:17 To: Carsten Bormann Cc: core@ietf.org; Klaus Hartke Subject: Re: [core] draft-ietf-core-block-08 - Block ordering > To me it seems we could make all this more apparent by stating two things= : > > 1) the protocol does not fundamentally disallow out-of-order access (and,= many servers will be able to provide out-of-order access (e.g., because th= ey > are stateless)) > 2) still, there is an expectation that more servers will be able to cope = with sequential access than with out-of-order access. Servers that impleme= nt > one of the Block options SHOULD enable sequential access, and MAY enable = out-of-order access. That sounds ok for me! thanks Esko -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: Thursday 12 April 2012 12:28 To: Dijk, Esko Cc: Klaus Hartke; core@ietf.org Subject: Re: [core] draft-ietf-core-block-08 - Block ordering On Apr 12, 2012, at 11:36, Dijk, Esko wrote: > Carsten, > >> So a client that wants to maximize interoperability will probably operat= e in sequential fashion. > Ok. If this constitutes the minimum level of interoperability for core-bl= ock, should we mandate it as such? > > Option 1) e.g. specify a CoAP end-point MUST be prepared to receive block= numbers in sequential fashion. Well, it is hard to say what such a MUST ("be prepared to receive...") real= ly constrains. A server can still always go belly-up, stop serving a resource, ... I think the point is indeed that there is a larger expectation of successfu= l completion when a client steps sequentially through the blocks of a resou= rce. > Option 2) e.g. specify a CoAP end-point MAY use block numbers in sequenti= al fashion. > [this automatically implies an end-point MUST be prepared to= receive sequential block numbers. At least an implementer MUST > consider this possibility.] But it also MAY use out-of order accesses... just with a slightly lower lev= el of expectation that the server will be able to successfully respond. > Though, the sequential case is so obvious from the I-D that it is already= a de-facto minimum interoperability (though not formally stated). That was indeed my reasoning so far. To me it seems we could make all this more apparent by stating two things: 1) the protocol does not fundamentally disallow out-of-order access (and, m= any servers will be able to provide out-of-order access (e.g., because they= are stateless)) 2) still, there is an expectation that more servers will be able to cope wi= th sequential access than with out-of-order access. Servers that implement= one of the Block options SHOULD enable sequential access, and MAY enable o= ut-of-order access. Gr=FC=DFe, Carsten ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From trac+core@trac.tools.ietf.org Mon Apr 16 01:37:43 2012 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 057B721F869C for ; Mon, 16 Apr 2012 01:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyadDjDLGsbg for ; Mon, 16 Apr 2012 01:37:42 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 7E12521F8650 for ; Mon, 16 Apr 2012 01:37:41 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SJhRD-0007su-8N; Mon, 16 Apr 2012 04:37:31 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-core-block@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Mon, 16 Apr 2012 08:37:30 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/209 Message-ID: <051.51f78e9af0ddc8ee31f86b5cb9ac3c19@trac.tools.ietf.org> X-Trac-Ticket-ID: 209 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-block@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120416083742.7E12521F8650@ietfa.amsl.com> Resent-Date: Mon, 16 Apr 2012 01:37:41 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #209: Add potential attacks to security considerations X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.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, 16 Apr 2012 08:37:43 -0000 #209: Add potential attacks to security considerations Bert Greevenbosch notes that a stateless server might be susceptible to an attack where the adversary sends a Block1 (e.g., PUT) block with a high block number. A naive implementation might exhaust its resources by creating a huge resource representation. -- -----------------------------+------------------------------------- Reporter: cabo@… | Owner: draft-ietf-core-block@… Type: editorial | Status: new Priority: minor | Milestone: post-WGLC-1 Component: block | Version: Severity: In WG Last Call | Keywords: -----------------------------+------------------------------------- Ticket URL: core From cabo@tzi.org Mon Apr 16 01:40:16 2012 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 96DF121F866A for ; Mon, 16 Apr 2012 01:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.474 X-Spam-Level: X-Spam-Status: No, score=-106.474 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOMA3v1NBUjF for ; Mon, 16 Apr 2012 01:40:16 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id D4FB521F8650 for ; Mon, 16 Apr 2012 01:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3G8dxO7029269; Mon, 16 Apr 2012 10:40:01 +0200 (CEST) Received: from [192.168.217.117] (p5489A83E.dip.t-dialin.net [84.137.168.62]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 1E83B478; Mon, 16 Apr 2012 10:39:59 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <46A1DF3F04371240B504290A071B4DB628F74879@szxeml509-mbs> Date: Mon, 16 Apr 2012 10:39:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <031DD135F9160444ABBE3B0C36CED618092AF8@011-DB3MPN1-013.MGDPHG.emi.philips.com> <0EDC43A0-E85B-4E7C-A442-798576178C5A@tzi.org> <031DD135F9160444ABBE3B0C36CED618092CD3@011-DB3MPN1-013.MGDPHG.emi.philips.com> <46A1DF3F04371240B504290A071B4DB628F74879@szxeml509-mbs> To: Bert Greevenbosch X-Mailer: Apple Mail (2.1257) Cc: "core@ietf.org" Subject: Re: [core] draft-ietf-core-block-08 - Block ordering X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 08:40:16 -0000 On Apr 16, 2012, at 10:22, Bert Greevenbosch wrote: > A topic for the "security considerations" section? Definitely worth a mention. Now #209. I'm sure we can find a few more things that might be obvious to = experienced implementers but would still be a good checklist to tick off = while implementing. Gr=FC=DFe, Carsten From trac+core@trac.tools.ietf.org Mon Apr 16 02:01:34 2012 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 57F1321F8737 for ; Mon, 16 Apr 2012 02:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAXkx4BbqV8y for ; Mon, 16 Apr 2012 02:01:33 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 31E4D21F8734 for ; Mon, 16 Apr 2012 02:01:32 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SJhoK-0001nL-Gv; Mon, 16 Apr 2012 05:01:24 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-core-block@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Mon, 16 Apr 2012 09:01:24 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/210 Message-ID: <051.d904ee0bea6c59be24fc5a28e7e8cf18@trac.tools.ietf.org> X-Trac-Ticket-ID: 210 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-block@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120416090133.31E4D21F8734@ietfa.amsl.com> Resent-Date: Mon, 16 Apr 2012 02:01:32 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #210: Disentangle Block and Token X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.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, 16 Apr 2012 09:01:34 -0000 #210: Disentangle Block and Token During the ETSI plugtest, it became clear that the interaction between the Block options (in particular Block1) on one hand and the Token option on the other hand creates problems in implementations. Closer analysis shows that the complex interaction in -block-08 is not really needed. Implicating a mechanism like tokens into the server state that is created for some block-wise transfers would only be needed if multiple concurrent block-wise transfers from one endpoint were required. As we have seen in Paris, this is just way too much complexity for this obscure usecase. Simplify the interaction of Tokens and Block: 1. retain, and do not extend, the exact response matching rules defined in CoAP-09 (this obviates the need to define how Block options influence the response matching: they simply don't). 2. remove the somewhat opaque text about using the Token for the selection of cache state for fast-changing resources (Block2): "The client MAY facilitate identifying the sequence by using the Token Option with a non-default value. " This leaves the client end-point and the URI as the cache selector for fast-changing resources. (#206 will be solved in the process of spelling this out in more detail.) This is exactly all that is needed (unless we want to enable the rather rare use case of concurrent Block2 transfers from one client all to the same URI on one server, but concurrently retrieving different cached versions). 3. similarly, for the state for atomic POST/PUT ("context"): select this per end-point (and URI), too. Remove this text: "If multiple concurrently proceeding block-wise request payload transfer (e.g., PUT or POST) operations are possible, the requester SHOULD use the Token Option to clearly separate the different sequences. In this case, when reassembling the representation from the blocks being exchanged to enable atomic processing, the reassembler MUST compare any Token Options present (and, as usual, taking an absent Token Option to default to the empty Token). If atomic processing is not desired, there is no need to process the Token Option (but it is still returned in the response as usual)." * note that this means a new upload to the same URI (before an old one from the same endpoint was finished) simply overwrites the context. This is probably exactly what one wants. * Future work could define a version of Pledge that informs the client how long the server is willing to keep such a context. 4. There now is never a need to send back Block options in error responses (except for 4.13 negotiation, where it is clear what is meant) -- -----------------------------+------------------------------------- Reporter: cabo@… | Owner: draft-ietf-core-block@… Type: protocol defect | Status: new Priority: major | Milestone: post-WGLC-1 Component: block | Version: Severity: In WG Last Call | Keywords: -----------------------------+------------------------------------- Ticket URL: core From cabo@tzi.org Mon Apr 16 02:11:16 2012 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 E84F821F8749 for ; Mon, 16 Apr 2012 02:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.466 X-Spam-Level: X-Spam-Status: No, score=-106.466 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xqADefSxV9H for ; Mon, 16 Apr 2012 02:11:16 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 0147621F8745 for ; Mon, 16 Apr 2012 02:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3G9B50P019571 for ; Mon, 16 Apr 2012 11:11:05 +0200 (CEST) Received: from [192.168.217.117] (p5489A83E.dip.t-dialin.net [84.137.168.62]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id BF3CF4CB; Mon, 16 Apr 2012 11:11:05 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Apr 2012 11:11:04 +0200 To: "core@ietf.org WG" Message-Id: <234E0A06-C203-4BAA-A612-B0716C757883@tzi.org> Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [core] WGLC draft-ietf-core-block-08: Disentangle Block and Token (#210) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 09:11:17 -0000 I have written up my current thinking on how to simplify the -block = mechanism. Please see #210 (http://trac.tools.ietf.org/wg/core/trac/ticket/210). This proposal is based on what we have seen during the interop testing = in Paris. I have no doubt that what we have now in -block-08 can be made to work, = but with the simplifications outlined in #210 we have practically the = same functionality with a lot less complexity. (Most of that complexity comes from coupling in the implementation that = is suddenly required in surprising places, so the few text deletions are = not quite indicative of how much the implementation complexity goes = down.) I'd love to hear from implementers who experienced difficulties with = -block in Paris whether this is the right direction. Gr=FC=DFe, Carsten From salvatore.loreto@ericsson.com Mon Apr 16 06:10:56 2012 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 B492621F86EE for ; Mon, 16 Apr 2012 06:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[AWL=-0.664, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFTQW4sYUgBg for ; Mon, 16 Apr 2012 06:10:56 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A8B4E21F86F2 for ; Mon, 16 Apr 2012 06:10:55 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-91-4f8c1a5ee404 Authentication-Results: mailgw1.ericsson.se x-tls.subject="/CN=esessmw0256"; auth=fail (cipher=AES128-SHA) Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0256", Issuer "esessmw0256" (not verified)) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 4E.BF.25560.E5A1C8F4; Mon, 16 Apr 2012 15:10:54 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.213.0; Mon, 16 Apr 2012 15:10:54 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 8C493231B for ; Mon, 16 Apr 2012 16:10:53 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 82C5A52683 for ; Mon, 16 Apr 2012 16:10:53 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 10D1552425 for ; Mon, 16 Apr 2012 16:10:52 +0300 (EEST) Message-ID: <4F8C1A5C.10309@ericsson.com> Date: Mon, 16 Apr 2012 15:10:52 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "core@ietf.org" Content-Type: multipart/alternative; boundary="------------020903090908090008020609" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: [core] wglc: coap caching and observe, caching underspecified X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 13:10:56 -0000 --------------020903090908090008020609 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Hi there, while reviewing the coap 09, I have notice that the response to an Observe request can of course be cached however *can not* be used to answer simple GET requests. From Section 5.6 a cache key consists of the request method, target URI and all the options used to obtain the stored response, and then based on the second bullet of Section 5.6 o all options match between those in the presented request and those of the request used to obtain the stored response (which includes the request URI), except that there is no need for a match of the Token, Max-Age, or ETag request option(s), and a *simple GET* does not match the Cache Key for a stored response to an Observe request. I want also suggest to add some text to clarify a little better the cache model, even if I implicitly assume that we are using the same of HTTP where Each cache entry consists of a cache key and one or more HTTP responses corresponding to prior requests that used the same key. cheers Salvatore -- Salvatore Loreto, PhD www.sloreto.com --------------020903090908090008020609 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Hi there,

while reviewing the coap 09,
I have notice that the response to an Observe request can of course be cached
however *can not* be used to answer simple GET requests.

From Section 5.6 a cache key consists of
the request method, target URI and all the options used to obtain the stored response,
and then based on the second bullet of Section 5.6

o all options match between those in the presented request and those
   of the request used to obtain the stored response (which includes
   the request URI), except that there is no need for a match of the Token,
   Max-Age, or ETag request option(s), and

a *simple GET* does not match the Cache Key for a stored response to an Observe request.


I want also suggest to add some text to clarify a little better the cache model,
even if I implicitly assume that we are using the same of HTTP where

  Each cache entry consists of a cache key and one or more HTTP
  responses corresponding to prior requests that used the same key.

cheers
Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com
--------------020903090908090008020609-- From hartke@tzi.org Mon Apr 16 08:06:25 2012 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 30A6711E808E for ; Mon, 16 Apr 2012 08:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bxLlTCzp4n5 for ; Mon, 16 Apr 2012 08:06:24 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 6580411E8072 for ; Mon, 16 Apr 2012 08:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3GF6HwB021851 for ; Mon, 16 Apr 2012 17:06:17 +0200 (CEST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C1927810 for ; Mon, 16 Apr 2012 17:06:16 +0200 (CEST) Received: by pbbrp16 with SMTP id rp16so4411071pbb.31 for ; Mon, 16 Apr 2012 08:06:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.135.226 with SMTP id pv2mr28249263pbb.148.1334588774590; Mon, 16 Apr 2012 08:06:14 -0700 (PDT) Received: by 10.68.23.37 with HTTP; Mon, 16 Apr 2012 08:06:14 -0700 (PDT) In-Reply-To: <4F8C1A5C.10309@ericsson.com> References: <4F8C1A5C.10309@ericsson.com> Date: Mon, 16 Apr 2012 17:06:14 +0200 Message-ID: From: Klaus Hartke To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [core] wglc: coap caching and observe, caching underspecified X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 15:06:25 -0000 Salvatore Loreto wrote: > while reviewing the coap 09, > I have notice that the response to an Observe request can of course be > cached > however *can not* be used to answer simple GET requests. > > From Section 5.6 a cache key consists of > the request method, target URI and all the options used to obtain the sto= red > response, > and then based on the second bullet of Section 5.6 > > o all options match between those in the presented request and those > =A0=A0 of the request used to obtain the stored response (which includes > =A0=A0 the request URI), except that there is no need for a match of the = Token, > =A0=A0 Max-Age, or ETag request option(s), and > > a *simple GET* does not match the Cache Key for a stored response to an > Observe request. I was about to report the same issue, because the same problem arises with the Block options. Proposed change: all options match between those in the presented request and those of the request used to obtain the stored response (which includes the request URI), with the exception of those options that are recognized by the cache and defined to opt out from this rule, and Addition to section 5.10.1. (Token): The Token Option MUST be ignored when deciding if a stored response can be used to satisfy a request presented to a cache. The Max-Age option actually can not occur in a request. The usage of the ETag option in requests should be clear. Some text needs to be added to -block and -observe for the Block1, Block2 and Observe options. Klaus From hartke@tzi.org Mon Apr 16 08:12:09 2012 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 AADD521F866A for ; Mon, 16 Apr 2012 08:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHTFeCnXdqnu for ; Mon, 16 Apr 2012 08:12:09 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id D0C1921F865D for ; Mon, 16 Apr 2012 08:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3GFC14x024776 for ; Mon, 16 Apr 2012 17:12:01 +0200 (CEST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9244381B for ; Mon, 16 Apr 2012 17:12:00 +0200 (CEST) Received: by pbbrp16 with SMTP id rp16so4416765pbb.31 for ; Mon, 16 Apr 2012 08:11:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.229.131 with SMTP id sq3mr15787500pbc.106.1334589118736; Mon, 16 Apr 2012 08:11:58 -0700 (PDT) Received: by 10.68.23.37 with HTTP; Mon, 16 Apr 2012 08:11:58 -0700 (PDT) Date: Mon, 16 Apr 2012 17:11:58 +0200 Message-ID: From: Klaus Hartke To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [core] draft-core-coap-09 - Nits X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 15:12:09 -0000 * Section 5.4.5. (Option Numbers) states that "the numbers 14, 28, 42, ... are reserved for 'fenceposting'". It is actually not necessary to reserve them for this; options with those numbers just need to have a default value that is encoded with zero bytes. The Vendor option in -misc already takes advantage of this. * Section 5.10. (Option Definitions) defines the Uri-Path, Uri-Query, Location-Path and Location-Query options to have a minimum length of 1 byte. This is a remnant of the time when each option could be included only at most once instead of for each path segment/query argument individually. Segments and arguments can have a length of zero characters. * Section 5.10.2. (Uri-Host, Uri-Port, Uri-Path and Uri-Query) states that "the Uri-Path and Uri-Query Option can contain any character sequence." It should define that it must be a string in Net-Unicode form. * Section 5.10.8. (Location-Path and Location-Query) state that the Location-* options describe an "absolute path URI". But if there is only a Location-Query option, there is no path. The section should say that the Location-* options describe a relative URI that consists either of an absolute path, a query string or both, and that is resolved relative to the request target URI. * Section 5.10.8. (Location-Path and Location-Query) should define that "the value of a Location-Path Option MUST NOT be '.' or '..'." * Should there be text on combining the Location-* options into a relative URI, and splitting an URI into Location-* options? Sections 6.4 and 6.5 currently do not apply, and the steps are slightly different. * There's the option of adding redirects to CoAP in the future, e.g. the response codes 96-127 (3.xx) have been reserved for this. Should option numbers be reserved so future Location-Host and Location-Port options would appear before Location-Path and Location-Query options in a message? * In section 5.6.1. (Freshness Model) it should be mentioned that, if a client has fresh stored response and makes a new request, the new response invalidates the old response. Klaus From salvatore.loreto@ericsson.com Mon Apr 16 08:22:45 2012 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 1921D11E8085 for ; Mon, 16 Apr 2012 08:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.857 X-Spam-Level: X-Spam-Status: No, score=-106.857 tagged_above=-999 required=5 tests=[AWL=-0.608, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2ccrCMDvfD4 for ; Mon, 16 Apr 2012 08:22:44 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4DE11E8074 for ; Mon, 16 Apr 2012 08:22:40 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-df-4f8c393f14d4 Authentication-Results: mailgw2.ericsson.se x-tls.subject="/CN=esessmw0191"; auth=fail (cipher=AES128-SHA) Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0191", Issuer "esessmw0191" (not verified)) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id F8.16.03534.F393C8F4; Mon, 16 Apr 2012 17:22:40 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.213.0; Mon, 16 Apr 2012 17:22:39 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 6B94A2323; Mon, 16 Apr 2012 18:22:39 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 887695280C; Mon, 16 Apr 2012 18:22:39 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id DD3AC51BC7; Mon, 16 Apr 2012 18:22:38 +0300 (EEST) Message-ID: <4F8C393E.9090403@ericsson.com> Date: Mon, 16 Apr 2012 17:22:38 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "core@ietf.org" References: <4F8C1A5C.10309@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Cc: Klaus Hartke Subject: Re: [core] wglc: coap caching and observe, caching underspecified X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 15:22:45 -0000 On 4/16/12 5:06 PM, Klaus Hartke wrote: > Salvatore Loreto wrote: >> while reviewing the coap 09, >> I have notice that the response to an Observe request can of course be >> cached >> however *can not* be used to answer simple GET requests. >> >> From Section 5.6 a cache key consists of >> the request method, target URI and all the options used to obtain the stored >> response, >> and then based on the second bullet of Section 5.6 >> >> o all options match between those in the presented request and those >> of the request used to obtain the stored response (which includes >> the request URI), except that there is no need for a match of the Token, >> Max-Age, or ETag request option(s), and >> >> a *simple GET* does not match the Cache Key for a stored response to an >> Observe request. > I was about to report the same issue, because the same problem arises > with the Block options. > > Proposed change: > > all options match between those in the presented request > and those of the request used to obtain the stored response > (which includes the request URI), with the exception of those > options that are recognized by the cache and defined to opt > out from this rule, and Hi Klaus that does not work you are proposing to let the Cache free to decide if and how to respond to a request on behalf of the origin server this would just open a can of warms from the interoperability prospective. I can not yet comment about Block as I have not reviewed it however I can tell you that An Observer request is a different request from a plain GET request and a sensor can decide to answer differently to them. All in all the* Cache behavior definition is not just an editorial issue*, it is a an important technical issue that needs to be solved in the right way. /Sal > > Addition to section 5.10.1. (Token): > > The Token Option MUST be ignored when deciding > if a stored response can be used to satisfy a request > presented to a cache. > > The Max-Age option actually can not occur in a request. > > The usage of the ETag option in requests should be clear. > > Some text needs to be added to -block and -observe for the Block1, > Block2 and Observe options. > > > Klaus > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From hartke@tzi.org Mon Apr 16 08:29:25 2012 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 013EC11E80A4 for ; Mon, 16 Apr 2012 08:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gl+pX7fq-qYU for ; Mon, 16 Apr 2012 08:29:24 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 18D4A11E8085 for ; Mon, 16 Apr 2012 08:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3GFTHs0001519 for ; Mon, 16 Apr 2012 17:29:17 +0200 (CEST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id DF9E7839 for ; Mon, 16 Apr 2012 17:29:16 +0200 (CEST) Received: by pbbrp16 with SMTP id rp16so4435998pbb.31 for ; Mon, 16 Apr 2012 08:29:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.213.41 with SMTP id np9mr28506624pbc.85.1334590155094; Mon, 16 Apr 2012 08:29:15 -0700 (PDT) Received: by 10.68.23.37 with HTTP; Mon, 16 Apr 2012 08:29:15 -0700 (PDT) In-Reply-To: <4F8C393E.9090403@ericsson.com> References: <4F8C1A5C.10309@ericsson.com> <4F8C393E.9090403@ericsson.com> Date: Mon, 16 Apr 2012 17:29:15 +0200 Message-ID: From: Klaus Hartke To: Salvatore Loreto Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "core@ietf.org" Subject: Re: [core] wglc: coap caching and observe, caching underspecified X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 15:29:25 -0000 Salvatore Loreto wrote: > that does not work > you are =A0proposing to let the Cache free to decide if and how to respon= d to > a request > on behalf of the origin server > this would just open a can of warms from the interoperability prospective= . What I mean is: A cache is presented with a request that contains an Observe option (elective). If it - does not recognize the option, it ignores the option; - does recognize the option, -observe overrides the rule that the Observe option is part of the cache key. A cache is presented with a request that contains a Block option. If it - does not recognize the option, it rejects it with a Bad Option response; - does recognize the option, -block overrides the rule that the Block option is part of the cache key. Klaus From hartke@tzi.org Mon Apr 16 08:34:57 2012 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 C9D9B21F86A1 for ; Mon, 16 Apr 2012 08:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AK44IGHQG5bk for ; Mon, 16 Apr 2012 08:34:56 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id DB1F921F86A0 for ; Mon, 16 Apr 2012 08:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3GFYjYB004807 for ; Mon, 16 Apr 2012 17:34:45 +0200 (CEST) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3F346842 for ; Mon, 16 Apr 2012 17:34:45 +0200 (CEST) Received: by dady13 with SMTP id y13so9765653dad.27 for ; Mon, 16 Apr 2012 08:34:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.135.226 with SMTP id pv2mr28419735pbb.148.1334590483321; Mon, 16 Apr 2012 08:34:43 -0700 (PDT) Received: by 10.68.23.37 with HTTP; Mon, 16 Apr 2012 08:34:43 -0700 (PDT) Date: Mon, 16 Apr 2012 17:34:43 +0200 Message-ID: From: Klaus Hartke To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [core] draft-ietf-core-coap-09 - Additional response codes X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 15:34:57 -0000 draft-nottingham-http-new-status [1] defines a few new HTTP status codes. They look useful to have in CoAP as well. - 428 Precondition Required The 428 status code indicates that the origin server requires the request to be conditional. - 429 Too Many Requests The 429 status code indicates that the user has sent too many requests in a given amount of time ("rate limiting"). - 431 Request Header Fields Too Large The 431 status code indicates that the server is unwilling to process the request because its header fields are too large. The request MAY be resubmitted after reducing the size of the request header fields. - 511 Network Authentication Required The 511 status code indicates that the client needs to authenticate to gain network access. I think it would also be useful to have an equivalent of the HTTP 202 status code [2] in CoAP. - 202 Accepted The request has been accepted for processing, but the processing has not been completed. ... The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the server persist until the process is completed. Klaus [1] http://tools.ietf.org/html/draft-nottingham-http-new-status-04 [2] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-19#section-7.2.3 From hartke@tzi.org Mon Apr 16 08:53:28 2012 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 412F111E8099 for ; Mon, 16 Apr 2012 08:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zEapQ01jbSY for ; Mon, 16 Apr 2012 08:53:27 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 243D011E8098 for ; Mon, 16 Apr 2012 08:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3GFrKg2012436 for ; Mon, 16 Apr 2012 17:53:20 +0200 (CEST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D14E885C for ; Mon, 16 Apr 2012 17:53:19 +0200 (CEST) Received: by pbbrp16 with SMTP id rp16so4460573pbb.31 for ; Mon, 16 Apr 2012 08:53:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.225.101 with SMTP id rj5mr9964213pbc.22.1334591597632; Mon, 16 Apr 2012 08:53:17 -0700 (PDT) Received: by 10.68.23.37 with HTTP; Mon, 16 Apr 2012 08:53:16 -0700 (PDT) Date: Mon, 16 Apr 2012 17:53:16 +0200 Message-ID: From: Klaus Hartke To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [core] draft-ietf-core-coap-09 - Conditional requests X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 15:53:28 -0000 Two questions related to conditional requests: * The ETag option in requests was added as a slimmed down version of HTTP's If-None-Match header field. Now that there is a If-None-Match option in CoAP, should the two options be unified? * The If-Match option can occur multiple times and contains either an etag or a special value. The If-None-Match option can occur only once and contains always the special value. What is the reason for not allowing etags in the If-None-Match option? The implementations should be largely the same. And a small editorial issue: * The first time conditional requests appear in the document is in the definition of the If-Match option. That's may be a bit late; I suggest the addition of a "Conditional requests" section before or after section 5.6 (Caching). Klaus From salvatore.loreto@ericsson.com Mon Apr 16 09:01:17 2012 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 1FBFB21F86EC for ; Mon, 16 Apr 2012 09:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.81 X-Spam-Level: X-Spam-Status: No, score=-106.81 tagged_above=-999 required=5 tests=[AWL=-0.562, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAOEiy-A24j6 for ; Mon, 16 Apr 2012 09:01:16 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id E73BF11E8081 for ; Mon, 16 Apr 2012 09:01:15 -0700 (PDT) X-AuditID: c1b4fb30-b7b07ae000006839-9c-4f8c424a5543 Authentication-Results: mailgw7.ericsson.se x-tls.subject="/CN=esessmw0184"; auth=fail (cipher=AES128-SHA) Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0184", Issuer "esessmw0184" (not verified)) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 2B.43.26681.A424C8F4; Mon, 16 Apr 2012 18:01:14 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.213.0; Mon, 16 Apr 2012 18:01:14 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 2A02B2323 for ; Mon, 16 Apr 2012 19:01:14 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 44D985280C for ; Mon, 16 Apr 2012 19:01:14 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C762F51BC7 for ; Mon, 16 Apr 2012 19:01:13 +0300 (EEST) Message-ID: <4F8C4249.7040401@ericsson.com> Date: Mon, 16 Apr 2012 18:01:13 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "core@ietf.org" Content-Type: multipart/alternative; boundary="------------050107000000090600090409" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: [core] wglc: coap-09 reference issue in section 4.5 Multicast X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 16:01:17 -0000 --------------050107000000090600090409 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Hi the first paragraph of 4.5 Multicast refers to "I-D.eggert-core-congestion-control" that is an important draft and contains valuable info and suggestion however it is still an individual and btw expired draft that had only the following aim: "This document motivates the need for additional congestion control mechanisms, and defines some simple strawman proposals. The goal is to encourage experimentation with these and other proposals, in order to determine which mechanisms are feasible to implement on resource- constrained nodes and are effective in real deployments." I am not sure about the opportunity to keep referencing it in the spec. /Sal --------------050107000000090600090409 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Hi

the first paragraph of 4.5 Multicast refers to "I-D.eggert-core-congestion-control"
that is an important draft and contains valuable info and suggestion
however it is still an individual and btw expired draft that had only the following aim:

"This document motivates the need for additional congestion control mechanisms, and defines some simple strawman proposals.
The goal is to encourage experimentation with these and other proposals, in order to determine which mechanisms are feasible
to implement on resource- constrained nodes and are effective in real deployments."

I am not sure about the opportunity to keep referencing it in the spec.

/Sal --------------050107000000090600090409-- From hartke@tzi.org Mon Apr 16 09:07:39 2012 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 1A2C821F86B7 for ; Mon, 16 Apr 2012 09:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQQQdR+rVeWG for ; Mon, 16 Apr 2012 09:07:38 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1A37421F8711 for ; Mon, 16 Apr 2012 09:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3GG7Tia018950 for ; Mon, 16 Apr 2012 18:07:29 +0200 (CEST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 62466879 for ; Mon, 16 Apr 2012 18:07:29 +0200 (CEST) Received: by pbbrp16 with SMTP id rp16so4475241pbb.31 for ; Mon, 16 Apr 2012 09:07:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.225.101 with SMTP id rj5mr10052336pbc.22.1334592447517; Mon, 16 Apr 2012 09:07:27 -0700 (PDT) Received: by 10.68.23.37 with HTTP; Mon, 16 Apr 2012 09:07:27 -0700 (PDT) In-Reply-To: <4F8C393E.9090403@ericsson.com> References: <4F8C1A5C.10309@ericsson.com> <4F8C393E.9090403@ericsson.com> Date: Mon, 16 Apr 2012 18:07:27 +0200 Message-ID: From: Klaus Hartke To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [core] wglc: coap caching and observe, caching underspecified X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 16:07:39 -0000 Second attempt: =A0 =A0all options match between those in the presented request =A0 =A0and those of the request used to obtain the stored response =A0 =A0(which includes the request URI), with the exception of those =A0 =A0options where the option definition says otherwise, and i.e. it's the option definition that decides if an option is part of the cache key or not, not the cache implementation. Klaus On 16 April 2012 17:22, Salvatore Loreto wr= ote: > On 4/16/12 5:06 PM, Klaus Hartke wrote: >> >> Salvatore Loreto wrote: >>> >>> while reviewing the coap 09, >>> I have notice that the response to an Observe request can of course be >>> cached >>> however *can not* be used to answer simple GET requests. >>> >>> =A0From Section 5.6 a cache key consists of >>> the request method, target URI and all the options used to obtain the >>> stored >>> response, >>> and then based on the second bullet of Section 5.6 >>> >>> o all options match between those in the presented request and those >>> =A0 =A0of the request used to obtain the stored response (which include= s >>> =A0 =A0the request URI), except that there is no need for a match of th= e >>> Token, >>> =A0 =A0Max-Age, or ETag request option(s), and >>> >>> a *simple GET* does not match the Cache Key for a stored response to an >>> Observe request. >> >> I was about to report the same issue, because the same problem arises >> with the Block options. >> >> Proposed change: >> >> =A0 =A0all options match between those in the presented request >> =A0 =A0and those of the request used to obtain the stored response >> =A0 =A0(which includes the request URI), with the exception of those >> =A0 =A0options that are recognized by the cache and defined to opt >> =A0 =A0out from this rule, and > > Hi Klaus > > that does not work > you are =A0proposing to let the Cache free to decide if and how to respon= d to > a request > on behalf of the origin server > this would just open a can of warms from the interoperability prospective= . > > I can not yet comment about Block as I have not reviewed it however I can > tell you that > An Observer request is a different request from a plain GET request and a > sensor > can decide to answer differently to them. > > All in all the* Cache behavior definition is not just an editorial issue*= , > it is a an important technical issue that needs to be solved in the right > way. > > /Sal > >> >> Addition to section 5.10.1. (Token): >> >> =A0 =A0The Token Option MUST be ignored when deciding >> =A0 =A0if a stored response can be used to satisfy a request >> =A0 =A0presented to a cache. >> >> The Max-Age option actually can not occur in a request. >> >> The usage of the ETag option in requests should be clear. >> >> Some text needs to be added to -block and -observe for the Block1, >> Block2 and Observe options. >> >> >> Klaus >> _______________________________________________ >> 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 kovatsch@inf.ethz.ch Mon Apr 16 09:11:26 2012 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 4BFFF21F8726 for ; Mon, 16 Apr 2012 09:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBdc6WC6QxXv for ; Mon, 16 Apr 2012 09:11:21 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id 0996D21F8725 for ; Mon, 16 Apr 2012 09:11:21 -0700 (PDT) Received: from CAS11.d.ethz.ch (172.31.38.211) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.2.283.3; Mon, 16 Apr 2012 18:11:20 +0200 Received: from MBX10.d.ethz.ch ([169.254.1.51]) by CAS11.d.ethz.ch ([fe80::ecc9:4e2d:b26b:1614%10]) with mapi id 14.01.0355.002; Mon, 16 Apr 2012 18:11:19 +0200 From: "Kovatsch Matthias" To: Carsten Bormann , Bert Greevenbosch Thread-Topic: [core] draft-ietf-core-block-08 - Block ordering Thread-Index: AQHNF6OcQIWFvlfLpE6Tjbkmi8trQJaVNNKAgACb6wCAADR1gIAAyXoAgAAOaACAAC9EAIAF9uaAgAAE9gCAAJxmQA== Date: Mon, 16 Apr 2012 16:11:19 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B51398C683@MBX10.d.ethz.ch> References: <031DD135F9160444ABBE3B0C36CED618092AF8@011-DB3MPN1-013.MGDPHG.emi.philips.com> <0EDC43A0-E85B-4E7C-A442-798576178C5A@tzi.org> <031DD135F9160444ABBE3B0C36CED618092CD3@011-DB3MPN1-013.MGDPHG.emi.philips.com> <46A1DF3F04371240B504290A071B4DB628F74879@szxeml509-mbs> In-Reply-To: Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.130.253] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "core@ietf.org" Subject: Re: [core] draft-ietf-core-block-08 - Block ordering X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 16:11:26 -0000 Following this discussion I fear that blockwise transfer is becoming someth= ing even more complex than TCP. To me it now sounds like "everything is allowed, do whatever you want." A p= rotocol should, however, give clear rules on how to communicate, shouldn't = it? What happened to the simple stop-and-wait idea? I think we should make this the default and then allow a special use-case f= or Block2 to have this random access (aligned to the block sizes) for resou= rces. This means Block1 MUST always start with block 0 and monotonically go= up to the last block. This massively simplifies the implementations and pr= ovides actual protocol rules. For crazy transfer schemes, people can still use the query option for insta= nce. Ciao Matthias From salvatore.loreto@ericsson.com Mon Apr 16 09:15:17 2012 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 799B321F875A for ; Mon, 16 Apr 2012 09:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.77 X-Spam-Level: X-Spam-Status: No, score=-106.77 tagged_above=-999 required=5 tests=[AWL=-0.521, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+B4cK4Iy7R4 for ; Mon, 16 Apr 2012 09:15:16 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id AF7AE21F8746 for ; Mon, 16 Apr 2012 09:15:15 -0700 (PDT) X-AuditID: c1b4fb30-b7b07ae000006839-00-4f8c45925f0d Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 1A.54.26681.2954C8F4; Mon, 16 Apr 2012 18:15:14 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.213.0; Mon, 16 Apr 2012 18:15:14 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 31AB32323 for ; Mon, 16 Apr 2012 19:15:14 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 2BBC852810 for ; Mon, 16 Apr 2012 19:15:14 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id AA85652672 for ; Mon, 16 Apr 2012 19:15:13 +0300 (EEST) Message-ID: <4F8C4590.3080801@ericsson.com> Date: Mon, 16 Apr 2012 18:15:12 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "core@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: [core] wglc: 4.6. Congestion Control X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 16:15:17 -0000 the section 4.6. Congestion Control needs some editorial work as at moment it talks at the same time of the network congestion control issue and of a mechanism to avoid to overloading a server (suggesting for the latter a similar mechanism to the one used by HTTP). /Sal From kovatsch@inf.ethz.ch Mon Apr 16 09:21:57 2012 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 7307C21F86FA for ; Mon, 16 Apr 2012 09:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqbWZNTuzEUb for ; Mon, 16 Apr 2012 09:21:44 -0700 (PDT) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) by ietfa.amsl.com (Postfix) with ESMTP id D93CA21F86F9 for ; Mon, 16 Apr 2012 09:21:35 -0700 (PDT) Received: from CAS12.d.ethz.ch (172.31.38.212) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.2.283.3; Mon, 16 Apr 2012 18:21:34 +0200 Received: from MBX10.d.ethz.ch ([169.254.1.51]) by CAS12.d.ethz.ch ([fe80::7861:4ecb:7c42:cad4%10]) with mapi id 14.01.0355.002; Mon, 16 Apr 2012 18:21:34 +0200 From: "Kovatsch Matthias" To: Carsten Bormann , "core@ietf.org WG" Thread-Topic: [core] WGLC draft-ietf-core-block-08: Disentangle Block and Token (#210) Thread-Index: AQHNG7Ds31+pWq2nokOmEkmg4LSl8padoNgg Date: Mon, 16 Apr 2012 16:21:33 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B51398C6AD@MBX10.d.ethz.ch> References: <234E0A06-C203-4BAA-A612-B0716C757883@tzi.org> In-Reply-To: <234E0A06-C203-4BAA-A612-B0716C757883@tzi.org> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.130.253] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [core] WGLC draft-ietf-core-block-08: Disentangle Block and Token (#210) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 16:21:57 -0000 +1 (Also see my comment about block ordering, as I think we should have monoto= nically increasing block numbers always starting with zero to keep it simpl= e.) > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of > Carsten Bormann > Sent: Montag, 16. April 2012 11:11 > To: core@ietf.org WG > Subject: [core] WGLC draft-ietf-core-block-08: Disentangle Block and Toke= n > (#210) >=20 > I have written up my current thinking on how to simplify the -block > mechanism. > Please see #210 (http://trac.tools.ietf.org/wg/core/trac/ticket/210). >=20 > This proposal is based on what we have seen during the interop testing in > Paris. > I have no doubt that what we have now in -block-08 can be made to work, > but with the simplifications outlined in #210 we have practically the sam= e > functionality with a lot less complexity. >=20 > (Most of that complexity comes from coupling in the implementation that i= s > suddenly required in surprising places, so the few text deletions are not > quite indicative of how much the implementation complexity goes down.) >=20 > I'd love to hear from implementers who experienced difficulties with -blo= ck > in Paris whether this is the right direction. >=20 > Gr=FC=DFe, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From cabo@tzi.org Mon Apr 16 09:40:51 2012 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 0104511E80BB for ; Mon, 16 Apr 2012 09:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.458 X-Spam-Level: X-Spam-Status: No, score=-106.458 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIFYbKrAyeCV for ; Mon, 16 Apr 2012 09:40:50 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id DCD5E11E80B6 for ; Mon, 16 Apr 2012 09:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3GGeb5M003577; Mon, 16 Apr 2012 18:40:37 +0200 (CEST) Received: from [192.168.217.105] (p5489A168.dip.t-dialin.net [84.137.161.104]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 86BB78B3; Mon, 16 Apr 2012 18:40:37 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <55877B3AFB359744BA0F2140E36F52B51398C683@MBX10.d.ethz.ch> Date: Mon, 16 Apr 2012 18:40:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <031DD135F9160444ABBE3B0C36CED618092AF8@011-DB3MPN1-013.MGDPHG.emi.philips.com> <0EDC43A0-E85B-4E7C-A442-798576178C5A@tzi.org> <031DD135F9160444ABBE3B0C36CED618092CD3@011-DB3MPN1-013.MGDPHG.emi.philips.com> <46A1DF3F04371240B504290A071B4DB628F74879@szxeml509-mbs> <55877B3AFB359744BA0F2140E36F52B51398C683@MBX10.d.ethz.ch> To: "Kovatsch Matthias" X-Mailer: Apple Mail (2.1257) Cc: "core@ietf.org" Subject: Re: [core] draft-ietf-core-block-08 - Block ordering X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 16:40:51 -0000 On Apr 16, 2012, at 18:11, Kovatsch Matthias wrote: > Following this discussion I fear that blockwise transfer is becoming = something even more complex than TCP. Then you haven't implemented TCP yet :-) > To me it now sounds like "everything is allowed, do whatever you = want." A protocol does two things: -- assign meaning to certain sequences of packets ("MAY") -- constrain implementations to actually implement that meaning for = certain sequences ("MUST implement") It is quite OK to have more sequences that have well defined meanings = than sequences that are "MUST implement". > A protocol should, however, give clear rules on how to communicate, = shouldn't it? The MUST implement is clearly sequential, and I don't think anyone = proposes to change that. Please do look at Figure 4 though, why "sequential" may not always be in = terms of block numbers. > What happened to the simple stop-and-wait idea? That is the MUST implement. (Well, if you implement Block at all, that is.) > I think we should make this the default and then allow a special = use-case for Block2 to have this random access (aligned to the block = sizes) for resources. This means Block1 MUST always start with block 0 = and monotonically go up to the last block. This massively simplifies the = implementations and provides actual protocol rules. I don't see a difference between stateless Block2 and stateless Block1. (Clearly, the latter has different use cases.) You cannot *not* implement random access when you run stateless. Oh, and you can't really specify "MUST always go up to the last block" = even for atomic Block1, because the client might lose power in the = middle. You still have to say what happens when it gets power again a = minute later and maybe tries the same sequence of transfers again, = before the state/context has timed out at the server. That's what I = meant by saying "overwrite state/context at the server". Gr=FC=DFe, Carsten From cabo@tzi.org Mon Apr 16 10:13:24 2012 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 00F9E21F8630 for ; Mon, 16 Apr 2012 10:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.452 X-Spam-Level: X-Spam-Status: No, score=-106.452 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAzRlqP5xFmu for ; Mon, 16 Apr 2012 10:13:23 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 9B70621F861F for ; Mon, 16 Apr 2012 10:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3GHDFKp017543 for ; Mon, 16 Apr 2012 19:13:15 +0200 (CEST) Received: from [192.168.217.105] (p5489A168.dip.t-dialin.net [84.137.161.104]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 0DD9B8D9; Mon, 16 Apr 2012 19:13:14 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Mon, 16 Apr 2012 19:13:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8894276E-C77B-48E7-B984-7C16DB3AA9AD@tzi.org> References: To: Klaus Hartke X-Mailer: Apple Mail (2.1257) Cc: core@ietf.org Subject: Re: [core] draft-ietf-core-coap-09 - Additional response codes X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 17:13:24 -0000 On Apr 16, 2012, at 17:34, Klaus Hartke wrote: > - 511 Network Authentication Required >=20 > The 511 status code indicates that the client > needs to authenticate to gain network access. This is the status code informally known as "greedy hotel detected". It is meant to be returned by captive portals that redirect all requests = to a payment site until payment is received. This is a well-understood and widely deployed scenario for HTTP; 511 = solves the problem that is created when captive portals respond with 200 = and cause automatic processes to believe the portal page is indeed the = desired page. I'm not so sure that we'll have exactly the same (or even a comparable) = scenario in CoAP. Gr=FC=DFe, Carsten From tho@koanlogic.com Mon Apr 16 10:45:32 2012 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 0A6F411E80AB for ; Mon, 16 Apr 2012 10:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VaudOAVtKFTO for ; Mon, 16 Apr 2012 10:45:31 -0700 (PDT) Received: from gonzo.koanlogic.com (koanlogic.com [64.251.31.111]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB5611E80A6 for ; Mon, 16 Apr 2012 10:45:31 -0700 (PDT) Received: from chello062178222142.13.15.univie.teleweb.at ([62.178.222.142]:54658 helo=[192.168.0.11]) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1SJpzD-0002dp-Rx; Mon, 16 Apr 2012 13:45:29 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: Date: Mon, 16 Apr 2012 19:45:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <65FED8AA-4B3E-4F57-BE42-982F140D0E07@koanlogic.com> References: <4F8C1A5C.10309@ericsson.com> <4F8C393E.9090403@ericsson.com> To: Klaus Hartke X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 62.178.222.142 X-SA-Exim-Mail-From: tho@koanlogic.com X-Spam-DCC: : X-Spam-Pyzor: Reported 0 times. X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on gonzo.koanlogic.com) Cc: core@ietf.org Subject: Re: [core] wglc: coap caching and observe, caching underspecified X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 17:45:32 -0000 Hi Klaus, On Apr 16, 2012, at 6:07 PM, Klaus Hartke wrote: > Second attempt: >=20 > all options match between those in the presented request > and those of the request used to obtain the stored response > (which includes the request URI), with the exception of those > options where the option definition says otherwise, and >=20 > i.e. it's the option definition that decides if an option is part of > the cache key or not, not the cache implementation. this simply does not scale. Options should be as transparent as possible to caches because otherwise = each hop is forced to understand the end-to-end semantics to enable the = forwarding -- which is clearly not a desirable behavior. The currently defined mechanism is really heavy, and mimics the an HTTP = cache in the hardest scenario, i.e. that with a Vary header with nearly = all the headers in it. What you are proposing would make this already implicit Vary depend on = out of band information (i.e. each RFC describing a new option) :-) Personally, I would like to keep caching as simple as possible:=20 - use the URI as the lookup key (only for GET's) - query the cache and then run through the result set to return the = first match depending on the content negotiation options (i.e. Accept, = ETag, and If-None-Match) Very basic, trivial to implement in most scenarios, and guaranteed to = work in enough use cases to be useful. (Well, we still need to think carefully about the interaction of options = like Observe, which heavily modify the semantics of the method -- BTW, = waka, an HTTP/2.0 proposal by Roy Fielding has an explicit MONITOR = method: see = http://www.ietf.org/proceedings/83/slides/slides-83-httpbis-5.pdf) Anyway, starting from a simple design could help us coming with a = solution that works with less pain. Yes, perhaps it'd be worth to stop and think a little bit more about = CoAP caches design. My two cents.= From kovatsch@inf.ethz.ch Mon Apr 16 10:48:31 2012 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 970BB21F876D for ; Mon, 16 Apr 2012 10:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.599 X-Spam-Level: X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZoDcYOggsD3H for ; Mon, 16 Apr 2012 10:48:30 -0700 (PDT) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) by ietfa.amsl.com (Postfix) with ESMTP id 4F79921F8762 for ; Mon, 16 Apr 2012 10:48:30 -0700 (PDT) Received: from CAS22.d.ethz.ch (172.31.51.112) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.2.283.3; Mon, 16 Apr 2012 19:48:29 +0200 Received: from MBX10.d.ethz.ch ([169.254.1.51]) by CAS22.d.ethz.ch ([fe80::dd0e:466a:b055:c090%10]) with mapi id 14.01.0355.002; Mon, 16 Apr 2012 19:48:29 +0200 From: "Kovatsch Matthias" To: Carsten Bormann Thread-Topic: [core] draft-ietf-core-block-08 - Block ordering Thread-Index: AQHNF6OcQIWFvlfLpE6Tjbkmi8trQJaVNNKAgACb6wCAADR1gIAAyXoAgAAOaACAAC9EAIAF9uaAgAAE9gCAAJxmQP//6eSAgAAkpGA= Date: Mon, 16 Apr 2012 17:48:28 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B51398C81A@MBX10.d.ethz.ch> References: <031DD135F9160444ABBE3B0C36CED618092AF8@011-DB3MPN1-013.MGDPHG.emi.philips.com> <0EDC43A0-E85B-4E7C-A442-798576178C5A@tzi.org> <031DD135F9160444ABBE3B0C36CED618092CD3@011-DB3MPN1-013.MGDPHG.emi.philips.com> <46A1DF3F04371240B504290A071B4DB628F74879@szxeml509-mbs> <55877B3AFB359744BA0F2140E36F52B51398C683@MBX10.d.ethz.ch> In-Reply-To: Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.130.253] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "core@ietf.org" Subject: Re: [core] draft-ietf-core-block-08 - Block ordering X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 17:48:31 -0000 > The MUST implement is clearly sequential, and I don't think anyone propos= es > to change that. Good, but is this actually said anywhere in the draft? I re-read block-08 and could only find implicit statements such as "sequenc= e of blocks" (nothing about the order) and the examples. > I don't see a difference between stateless Block2 and stateless Block1. > (Clearly, the latter has different use cases.) You cannot *not* implement > random access when you run stateless. I thought that with some restrictions for the client, we could minimize the= probability to break resources or make it easier for the server to check i= f the received representation can be valid. But in the end this does not ma= tter, as the client always has to play along to not break the resources. > Oh, and you can't really specify "MUST always go up to the last block" ev= en > for atomic Block1, because the client might lose power in the middle. Yo= u still > have to say what happens when it gets power again a minute later and > maybe tries the same sequence of transfers again, before the state/contex= t > has timed out at the server. That's what I meant by saying "overwrite > state/context at the server". Yes, that was a problematic textual shortcut I took. >=20 > Gr=FC=DFe, Carsten From hartke@tzi.org Mon Apr 16 11:20:39 2012 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 6F24121F86F1 for ; Mon, 16 Apr 2012 11:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyCINQXkjqxW for ; Mon, 16 Apr 2012 11:20:38 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id DB34121F86AB for ; Mon, 16 Apr 2012 11:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3GIKQjx011430 for ; Mon, 16 Apr 2012 20:20:26 +0200 (CEST) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E93E2911 for ; Mon, 16 Apr 2012 20:20:25 +0200 (CEST) Received: by dady13 with SMTP id y13so10020951dad.27 for ; Mon, 16 Apr 2012 11:20:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.229.131 with SMTP id sq3mr16991143pbc.106.1334600423822; Mon, 16 Apr 2012 11:20:23 -0700 (PDT) Received: by 10.68.23.37 with HTTP; Mon, 16 Apr 2012 11:20:23 -0700 (PDT) In-Reply-To: <65FED8AA-4B3E-4F57-BE42-982F140D0E07@koanlogic.com> References: <4F8C1A5C.10309@ericsson.com> <4F8C393E.9090403@ericsson.com> <65FED8AA-4B3E-4F57-BE42-982F140D0E07@koanlogic.com> Date: Mon, 16 Apr 2012 20:20:23 +0200 Message-ID: From: Klaus Hartke To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] wglc: coap caching and observe, caching underspecified X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 18:20:39 -0000 Hi Thomas, On 16 April 2012 19:45, Thomas Fossati wrote: > Options should be as transparent as possible to caches because otherwise each hop is forced to understand the end-to-end semantics to enable the forwarding -- which is clearly not a desirable behavior. That's the current behaviour specified in coap-09. Section 5.4.1. (Critical/Elective) states: o Unrecognized options of class "elective" MUST be silently ignored. o Unrecognized options of class "critical" that occur in a confirmable request MUST cause the return of a 4.02 (Bad Option) response Intermediaries and caches are not exempt from this, i.e. if there is one cache in the path that doesn't recognize an option, either the option is filtered out or the request is failed. This problem has been brought up before, and I agree that it's not a desirable behaviour. But I'm not sure there is a solution to it: A "critical" option in a request means that the sender is not interested in the response if the option is not understood. It is critical that the recipient understands the option in order to understand the full request. If a cache doesn't understand a presented request, how can it satisfy it with a stored response that is the result of a different request it didn't understand? Klaus From tho@koanlogic.com Mon Apr 16 13:31:33 2012 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 2D9D021F865E for ; Mon, 16 Apr 2012 13:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuxBN8ZrOtVX for ; Mon, 16 Apr 2012 13:31:32 -0700 (PDT) Received: from gonzo.koanlogic.com (koanlogic.com [64.251.31.111]) by ietfa.amsl.com (Postfix) with ESMTP id 4737421F865B for ; Mon, 16 Apr 2012 13:31:32 -0700 (PDT) Received: from tho by gonzo.koanlogic.com with local (Exim 4.50) id 1SJsa4-0002x0-4b; Mon, 16 Apr 2012 16:31:30 -0400 Date: Mon, 16 Apr 2012 16:31:24 -0400 To: Klaus Hartke Message-ID: <20120416203124.GA11308@koanlogic.com> References: <4F8C1A5C.10309@ericsson.com> <4F8C393E.9090403@ericsson.com> <65FED8AA-4B3E-4F57-BE42-982F140D0E07@koanlogic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i From: tho@koanlogic.com X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tho@koanlogic.com X-Spam-DCC: : X-Spam-Pyzor: Reported 0 times. X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on gonzo.koanlogic.com) Cc: core@ietf.org Subject: Re: [core] wglc: coap caching and observe, caching underspecified X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 20:31:33 -0000 Hi Klaus, On Mon, Apr 16, 2012 at 08:20:23PM +0200, Klaus Hartke wrote: > This problem has been brought up before, and I agree that it's not a > desirable behaviour. But I'm not sure there is a solution to it: > > A "critical" option in a request means that the sender is not > interested in the response if the option is not understood. It is > critical that the recipient understands the option in order to > understand the full request. If a cache doesn't understand a presented > request, how can it satisfy it with a stored response that is the > result of a different request it didn't understand? there is a significant difference here: a caching proxy is not an endpoint, it's an intermediary. As such it doesn't produce any response, it just try to reply with a matching cached response produced by an origin server: it's just a dumb node :-) Actually, it's conceptually wrong to leave an intermediary the ability to drop traffic just because it does not understand its semantics. Criticalness (?) should be an end-to-end, not an hop-by-hop attribute. Keeping with the "Vary" metaphor, we could add the odd-numbered options automatically to the implicit Vary used by the cache selection algorithm, and leave the even-numbered out. If the proxy finds no match response in cache it just forwards what has been received to the intended endpoint: no drop on the forwarding plane because of unrecognized criticalness. This would play smoothly with critical options, while letting a caching proxy be basically agnostic of the carried semantics. What do you think ? From hartke@tzi.org Mon Apr 16 15:14:11 2012 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 7BFE511E80C1 for ; Mon, 16 Apr 2012 15:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eolc6PYnlBHV for ; Mon, 16 Apr 2012 15:14:11 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id AB87311E80B6 for ; Mon, 16 Apr 2012 15:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3GME2CG000360 for ; Tue, 17 Apr 2012 00:14:02 +0200 (CEST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 8B4B0989 for ; Tue, 17 Apr 2012 00:14:02 +0200 (CEST) Received: by pbbrp16 with SMTP id rp16so4812312pbb.31 for ; Mon, 16 Apr 2012 15:14:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.135.226 with SMTP id pv2mr30936189pbb.148.1334614440468; Mon, 16 Apr 2012 15:14:00 -0700 (PDT) Received: by 10.68.23.37 with HTTP; Mon, 16 Apr 2012 15:14:00 -0700 (PDT) Date: Tue, 17 Apr 2012 00:14:00 +0200 Message-ID: From: Klaus Hartke To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [core] Disentangle Block and Token X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 22:14:11 -0000 On 16 April 2012 11:01, core issue tracker wrote: > =A03. similarly, for the state for atomic POST/PUT ("context"): > =A0 select this per end-point (and URI), too. > > =A0 =A0 * note that this means a new upload to the same URI (before an ol= d > =A0 =A0 one from the same endpoint was finished) simply overwrites the > =A0 =A0 context. =A0This is probably exactly what one wants. Who wins if two clients perform a block-wise atomic POST/PUT with the same URI through the same proxy at the same time? Klaus From cabo@tzi.org Mon Apr 16 15:37:18 2012 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 52C6521F8541 for ; Mon, 16 Apr 2012 15:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.445 X-Spam-Level: X-Spam-Status: No, score=-106.445 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvW86WY8jWxT for ; Mon, 16 Apr 2012 15:37:17 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBBC21F8537 for ; Mon, 16 Apr 2012 15:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3GMb9Qv006829 for ; Tue, 17 Apr 2012 00:37:09 +0200 (CEST) Received: from [192.168.217.105] (p5489A168.dip.t-dialin.net [84.137.161.104]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 8D72898D; Tue, 17 Apr 2012 00:37:09 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Tue, 17 Apr 2012 00:37:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Klaus Hartke X-Mailer: Apple Mail (2.1257) Cc: core@ietf.org Subject: Re: [core] Disentangle Block and Token X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 22:37:18 -0000 On Apr 17, 2012, at 00:14, Klaus Hartke wrote: > Who wins if two clients perform a block-wise atomic POST/PUT with the > same URI through the same proxy at the same time? Who wins if two clients perform a POST/PUT with the same URI through the same proxy at the same time? I think the more interesting question is how the intermediary can avoid = the two concurrent operations to get confused with each other. Right = now, it would need to run its own buffering, or if it wants to "write = through", use some form of locking and allocate separate port numbers in = case of a lock conflict. Not very nice, but is that an important enough = use case to optimize that we want to incur the complexity everywhere = that we have experienced? Gr=FC=DFe, Carsten From hartke@tzi.org Mon Apr 16 15:46:31 2012 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 6D38611E80AF for ; Mon, 16 Apr 2012 15:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hzojzH6TR0k for ; Mon, 16 Apr 2012 15:46:31 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id B029311E807F for ; Mon, 16 Apr 2012 15:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3GMkIop009696 for ; Tue, 17 Apr 2012 00:46:18 +0200 (CEST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A196D990 for ; Tue, 17 Apr 2012 00:46:17 +0200 (CEST) Received: by pbbrp16 with SMTP id rp16so4835652pbb.31 for ; Mon, 16 Apr 2012 15:46:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.221.227 with SMTP id qh3mr31233332pbc.43.1334616375783; Mon, 16 Apr 2012 15:46:15 -0700 (PDT) Received: by 10.68.23.37 with HTTP; Mon, 16 Apr 2012 15:46:15 -0700 (PDT) In-Reply-To: References: Date: Tue, 17 Apr 2012 00:46:15 +0200 Message-ID: From: Klaus Hartke To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [core] Disentangle Block and Token X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 22:46:31 -0000 On 17 April 2012 00:37, Carsten Bormann wrote: > I think the more interesting question is how the intermediary can avoid t= he two concurrent operations to get confused with each other. =A0Right now,= it would need to run its own buffering, or if it wants to "write through",= use some form of locking and allocate separate port numbers in case of a l= ock conflict. =A0Not very nice, but is that an important enough use case to= optimize that we want to incur the complexity everywhere that we have expe= rienced? I'd just add a sentence or two to make sure that the result is not accidentally a resource where some parts come from one client and some parts from the other. Klaus From hartke@tzi.org Mon Apr 16 17:14:38 2012 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 C33B411E80EE for ; Mon, 16 Apr 2012 17:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPDL-WIcTOyx for ; Mon, 16 Apr 2012 17:14:38 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id E599911E807F for ; Mon, 16 Apr 2012 17:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3H0ETwf005648 for ; Tue, 17 Apr 2012 02:14:29 +0200 (CEST) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6D34F996 for ; Tue, 17 Apr 2012 02:14:29 +0200 (CEST) Received: by dady13 with SMTP id y13so10467863dad.27 for ; Mon, 16 Apr 2012 17:14:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.204.9 with SMTP id ku9mr31737947pbc.1.1334621667308; Mon, 16 Apr 2012 17:14:27 -0700 (PDT) Received: by 10.68.23.37 with HTTP; Mon, 16 Apr 2012 17:14:27 -0700 (PDT) Date: Tue, 17 Apr 2012 02:14:27 +0200 Message-ID: From: Klaus Hartke To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [core] draft-ietf-core-observe-05 - "obs" X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 00:14:38 -0000 In the spirit of "In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away" [1]: Do we really need the "obs" link attribute? Some thoughts: * If a client wants to have a fresh representation of a resource over a period of time, it can include the Observe option in its request. If the server does not support -observe, the client can poll the resource to achieve its goal. * If a client for whatever reason only wants to have a fresh representation of a resource over a period of time if the server supports -observe, it can include Observe option in its request and not poll if the if the server does not support -observe. * If a client wants a single snapshot representation of a resource, it can omit the Observe option from its request. Under what circumstances can a client not be sure if it wants to have a fresh representation of a resource over a period of time, so a hint from the server is needed? Klaus [1] http://tools.ietf.org/html/rfc1925 From hartke@tzi.org Mon Apr 16 18:46:06 2012 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 6E67521F85B4 for ; Mon, 16 Apr 2012 18:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPS3EvPb9435 for ; Mon, 16 Apr 2012 18:46:05 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 9496E21F85AF for ; Mon, 16 Apr 2012 18:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3H1jvhl001645 for ; Tue, 17 Apr 2012 03:45:57 +0200 (CEST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 7B0A199B for ; Tue, 17 Apr 2012 03:45:57 +0200 (CEST) Received: by vbbez10 with SMTP id ez10so4482817vbb.31 for ; Mon, 16 Apr 2012 18:45:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.149.130 with SMTP id t2mr1557350vcv.40.1334627156008; Mon, 16 Apr 2012 18:45:56 -0700 (PDT) Received: by 10.220.227.136 with HTTP; Mon, 16 Apr 2012 18:45:55 -0700 (PDT) In-Reply-To: <20120416203124.GA11308@koanlogic.com> References: <4F8C1A5C.10309@ericsson.com> <4F8C393E.9090403@ericsson.com> <65FED8AA-4B3E-4F57-BE42-982F140D0E07@koanlogic.com> <20120416203124.GA11308@koanlogic.com> Date: Tue, 17 Apr 2012 03:45:55 +0200 Message-ID: From: Klaus Hartke To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] wglc: coap caching and observe, caching underspecified X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 01:46:06 -0000 Hi Thomas, On 16 April 2012 22:31, wrote: > Keeping with the "Vary" metaphor, we could add the odd-numbered options > automatically to the implicit Vary used by the cache selection > algorithm, and leave the even-numbered out. > > If the proxy finds no match response in cache it just forwards what has > been received to the intended endpoint: no drop on the forwarding plane > because of unrecognized criticalness. let me rephrase this to make sure I understand it correctly: * Recognized critical option - act according to the option definition. For example, the client's token is not part of the key cache, and an intermediary generates its own token when it makes a request to the server to satisfy the client's request. * Recognized elective option - act according to the option definition. For example, a cache returns a 2.03 Valid response if any of the etags in the request matches the etag of a fresh stored response, and an intermediary includes the etags of its own stored responses rather than those supplied by the client when it makes a request to the server to satisfy the client's request. * Unrecognised critical option - the option value is part of the cache key, and an intermediary includes the option without knowing what it means when it makes a request to the server to satisfy the client's request. * Unrecognised elective option - option value is *not* part of the cache key, and an intermediary includes the option without knowing what it means when it makes a request to the server to satisfy the client's request. So for recognized options it's the same as what I proposed: the option definition decides if an option is part of the cache key (Uri-Host), is not part of the cache key (Token), or has caching-related semantics (ETag). For unrecognised options, your suggestion of simply including the option without knowing what it means breaks at least the ETag, Accept, Size, Token, Observe, Block2 and Block1 options. Two examples: * A proxy with cache does not recognize the critical Block1 option. It is presented with a request that contains a Block1 option. It finds no matching response, so it forwards the request to the server. It's presented with another request that also contains a Block1 option, but comes from a different client. It finds no matching response, so it forwards the request to the server. The server cannot see that the two requests are actually originating from two different clients, and erroneously combines the two unrelated blocks. * A cache does not recognize the elective ETag option. It is presented with a request that contains an ETag option. It finds no matching stored response, so it forwards the request to the server. The cache receives a 2.03 Valid response and stores it. It's presented with another request that contains an ETag option, but with a different value. Because the ETag Option is not part of the cache key, the stored 2.03 matches and is returned, erroneously validating the second etag. Klaus From hartke@tzi.org Mon Apr 16 18:48:06 2012 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 D5F7411E80F5 for ; Mon, 16 Apr 2012 18:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhg0IuitmWla for ; Mon, 16 Apr 2012 18:48:06 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1C36011E80F0 for ; Mon, 16 Apr 2012 18:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3H1lvxK002066 for ; Tue, 17 Apr 2012 03:47:57 +0200 (CEST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id F34DE99C for ; Tue, 17 Apr 2012 03:47:56 +0200 (CEST) Received: by vcbfk13 with SMTP id fk13so4511519vcb.31 for ; Mon, 16 Apr 2012 18:47:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.94.34 with SMTP id cz2mr5746436vdb.100.1334627275620; Mon, 16 Apr 2012 18:47:55 -0700 (PDT) Received: by 10.220.227.136 with HTTP; Mon, 16 Apr 2012 18:47:55 -0700 (PDT) Date: Tue, 17 Apr 2012 03:47:55 +0200 Message-ID: From: Klaus Hartke To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [core] draft-ietf-core-coap-09 - Content-Type critical X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 01:48:06 -0000 Why is the Content-Type Option critical and not elective? Klaus From hartke@tzi.org Mon Apr 16 19:18:42 2012 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 0F7B821F8595 for ; Mon, 16 Apr 2012 19:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+Rprro0tKUo for ; Mon, 16 Apr 2012 19:18:38 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id BDE2521F8594 for ; Mon, 16 Apr 2012 19:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3H2IRej011801 for ; Tue, 17 Apr 2012 04:18:27 +0200 (CEST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B6C1699F for ; Tue, 17 Apr 2012 04:18:26 +0200 (CEST) Received: by vcbfk13 with SMTP id fk13so4524735vcb.31 for ; Mon, 16 Apr 2012 19:18:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.149.79 with SMTP id s15mr7172049vcv.60.1334629105327; Mon, 16 Apr 2012 19:18:25 -0700 (PDT) Received: by 10.220.227.136 with HTTP; Mon, 16 Apr 2012 19:18:25 -0700 (PDT) Date: Tue, 17 Apr 2012 04:18:25 +0200 Message-ID: From: Klaus Hartke To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [core] draft-ietf-core-block-08 - Disentangle Block and Success Response Codes X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 02:18:42 -0000 When a client performs an atomic block-wise POST/PUT, the server returns a 2.01 (Created) or 2.04 (Changed) response for each uploaded block. coap-09 defines the two response codes as follows: * 2.01 (Created) means that a resource was created at the target URI/Location URI and requires that a cache marks any stored response for the created resource as not fresh. * 2.04 (Changed) means that the target resource was changed and requires that a cache marks any stored response for the changed resource as not fresh. The problem is: the target resource is not really created or changed in an atomic block-wise POST/PUT before the last block is uploaded. Invalidating all caches long before the POST/PUT is complete doesn't sound like a good idea. I propose to return a different, new response code that doesn't have an effect on caches and conveys the non-final nature of the response. An equivalent of the HTTP 100 status code [1] would be the best fit: - 100 Continue The client SHOULD continue with its request. This interim response is used to inform the client that the initial part of the request has been received and has not yet been rejected by the server. The client SHOULD continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The server MUST send a final response after the request has been completed. Klaus [1] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-19#section-7.1.1 From esko.dijk@philips.com Mon Apr 16 23:26:12 2012 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 CBB8E21F85D1 for ; Mon, 16 Apr 2012 23:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZ4tbj+aaWkZ for ; Mon, 16 Apr 2012 23:26:09 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfa.amsl.com (Postfix) with ESMTP id CA18D21F85C4 for ; Mon, 16 Apr 2012 23:26:08 -0700 (PDT) Received: from mail44-db3-R.bigfish.com (10.3.81.234) by DB3EHSOBE004.bigfish.com (10.3.84.24) with Microsoft SMTP Server id 14.1.225.23; Tue, 17 Apr 2012 06:26:07 +0000 Received: from mail44-db3 (localhost [127.0.0.1]) by mail44-db3-R.bigfish.com (Postfix) with ESMTP id 7ACDD460676 for ; Tue, 17 Apr 2012 06:26:07 +0000 (UTC) X-SpamScore: -13 X-BigFish: VPS-13(zz217bL15d6O9251Jc85fhzz1202hzzz2dh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI Received: from mail44-db3 (localhost.localdomain [127.0.0.1]) by mail44-db3 (MessageSwitch) id 1334643964745664_13578; Tue, 17 Apr 2012 06:26:04 +0000 (UTC) Received: from DB3EHSMHS017.bigfish.com (unknown [10.3.81.237]) by mail44-db3.bigfish.com (Postfix) with ESMTP id B1E7042004C for ; Tue, 17 Apr 2012 06:26:04 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by DB3EHSMHS017.bigfish.com (10.3.87.117) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 17 Apr 2012 06:26:04 +0000 Received: from 011-DB3MMR1-017.MGDPHG.emi.philips.com (10.128.28.102) by 011-DB3MMR1-002.MGDPHG.emi.philips.com (10.128.28.52) with Microsoft SMTP Server (TLS) id 14.1.355.3; Tue, 17 Apr 2012 07:28:45 +0100 Received: from 011-DB3MPN1-013.MGDPHG.emi.philips.com ([169.254.3.240]) by 011-DB3MMR1-017.MGDPHG.emi.philips.com ([10.128.28.102]) with mapi id 14.01.0355.003; Tue, 17 Apr 2012 07:26:03 +0100 From: "Dijk, Esko" To: "core@ietf.org WG" Thread-Topic: draft-ietf-core-coap-09 - Editorial comments WGLC Thread-Index: Ac0cYq7ATrd+DFlFSw6OeUkE9eudDA== Date: Tue, 17 Apr 2012 06:28:46 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED61809355D@011-DB3MPN1-013.MGDPHG.emi.philips.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [109.38.157.252] Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED61809355D011DB3MPN1013MGDP_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: [core] draft-ietf-core-coap-09 - Editorial comments WGLC X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 06:26:12 -0000 --_000_031DD135F9160444ABBE3B0C36CED61809355D011DB3MPN1013MGDP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Below my editorial comments and questions for core-coap. I'll send some mor= e review comments shortly after the WGLC deadline. * Abstract: "a method/response interaction model" -> "a request/response i= nteraction model" (seems more common terminology. Or is it different on purpose?) * Section 4.1: "The same Message ID MUST NOT be re-used (per Message ID var= iable)" There seems to be a requirement here on the MID variable(s) of an implement= ation instead of requirements on MID (re)use in messages. (Any reason for t= his?) * Section 4.2: "The same rules for generating the Message ID apply." "Same rules" could refer to Section 4.1 for the rules just to be clear. * Section 4.5: "unicast reply to the multicast request" -> "unicast respons= e" ? * Section 5.2 / Figure 10: numbers alignment issue * Section 5.2 "To ensure that this message is not lost, it is again sent as= a confirmable message" This sounds like a separate response is always CON, which is not the case? * Section 5.2 "Responses can be sent in multiple ways" and Section 5.2.3 The subsections suggest 3 major ways. The third (5.2.3) Non-Confirmable as = a separate category is a bit puzzling, since the second (5.2.2) Separate re= sponse also clearly includes Non-Confirmable responses. Or is 5.2.3 only ab= out NON response to a NON request? If so the subsection title should be mor= e descriptive. * Section 5.2.3 "(preceded or followed an empty acknowledgement message)" -= > "followed by" * Section 5.3 "the response SHOULD be rejected with a reset message" Section 4.1 defines "MUST reject it with a reset message". Why different? Section 4.2 defines "it MAY reject the message with a reset message" for NO= N. Should Section 5.3 also distinguish the CON/NON cases? Is Section 5.3 (about matching) the best place to define such rejection con= ditions? (a ref. could be made to a section). * Section 5.6.2 "after updating its freshness with the value of the Max-Age= Option that is included with the response (see Section 5.9.1.3)" This suggests that a Max-Age Option is always included with the response. -> "may be included with the response" ? * Section 5.8.1 "inlcudes" -> "includes" * Section 5.8.2. "If a resource has been created on the server, a 2.01 (Cre= ated) response that includes the URI of the new resource in a sequence of one or more Location-Path and/or Location-Query Options SHOULD be returned." While section 5.10.8 defines this optional: "The two options MAY be include= d in a response to indicate the location of a new resource created with POST." Should 5.8.2. refer to 5.10.8 to define the right behaviour (to avoid doubl= e definitions) ? Btw "the two options MAY" -> this sounds like they have to be included as a= pair, which is not the case. * Section 5.9.1.3 "When a cache receives a 2.03 (Valid) response, it needs to update the stored response with the value of the Max-Age Option included in the response (see Section 5.6.2)." There seems to be a requirement here to update freshness of the stored resp= onse. While Section 5.6.2 does not require an end-point to update its store= d response in case new content arrives ("MAY replace the stored response").= Any reason for this difference? * Section 5.10.3 "An end-point receiving a request with a Proxy-Uri Option that is unable or unwilling to act as a proxy for the request MUST cause the return of a 5.05 (Proxying Not Supported) response." Section 8.1 has a SHOULD requirement on returning 5.05. Any reason for the = difference, SHOULD for CoAP-HTTP proxy and MUST for CoAP proxy? * Section 5.10.8 "If a response with one or more Location-Path and/or Location-Query Options passes through a cache and the implied URI identifies one or more currently stored responses, those entries SHOULD be marked as not fresh." This feels like optimizing for a case that almost never happens (I may be w= rong here). These are only used to indicate a new resource created. Typically a new res= ource would not be cached anywhere, so why do implementations need to expen= d effort to check this? Or can "new resource" in REST terms also include an update of an existing r= esource? * Section 5.10.9 "If any of the ETags given as an option value match the ETag of the selected representation for the target resource" "selected" is not entirely clear. Does this mean "current representation" ? * "If none of the ETags match and," -> "If none of the ETags match OR," ? (comments continued in next email) regards, Esko ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_031DD135F9160444ABBE3B0C36CED61809355D011DB3MPN1013MGDP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Below my editorial comments and questions for core-coap. I’ll send so= me more review comments shortly after the WGLC deadline.

=  

= * Abstract: “a method/response interaction model”  -> &= #8220;a request/response interaction model”

= (seems more common terminology. Or is it different on purpose?)

=  

= * Section 4.1: “The same Message ID MUST NOT be re-used (per Message = ID variable)”

= There seems to be a requirement here on the MID variable(s) of an implement= ation instead of requirements on MID (re)use in messages. (Any reason for t= his?)

=  

= * Section 4.2: “The same rules for generating the Message ID apply.&#= 8221;

= “Same rules” could refer to Section 4.1 for the rules just to b= e clear.

=  

= * Section 4.5: “unicast reply to the multicast request” -> &= #8220;unicast response” ?

=  

= * Section 5.2 / Figure 10: numbers alignment issue

=  

= * Section 5.2 “To ensure that this message is not lost, it is again s= ent as a confirmable message”

= This sounds like a separate response is always CON, which is not the case?<= /span>

=  

= * Section 5.2 “Responses can be sent in multiple ways” and Sect= ion 5.2.3

= The subsections suggest 3 major ways. The third (5.2.3) Non-Confirmable as = a separate category is a bit puzzling, since the second (5.2.2) Separate re= sponse also clearly includes Non-Confirmable responses. Or is 5.2.3 only about NON response to a NON request? If so the subsection= title should be more descriptive.

=  

= * Section 5.2.3 “(preceded or followed an empty acknowledgement messa= ge)” -> “followed by”

=  

= * Section 5.3 “the response SHOULD be rejected with a reset message&#= 8221;

= Section 4.1 defines “MUST reject it with a reset message”. Why = different?

= Section 4.2 defines “it MAY reject the message with a reset message&#= 8221; for NON.

= Should Section 5.3 also distinguish the CON/NON cases?

= Is Section 5.3 (about matching) the best place to define such rejection con= ditions? (a ref. could be made to a section).

=  

= * Section 5.6.2 “after updating its freshness with the value of the M= ax-Age Option

= that is included with the response (see Section 5.9.1.3)”

= This suggests that a Max-Age Option is always included with the response.

= -> “may be included with the response” ?

=  

= * Section 5.8.1 “inlcudes” -> “includes”<= /p>

=  

= * Section 5.8.2. “If a resource has been created on the server, a 2.0= 1 (Created)

=    response that includes the URI of the new resource in a sequen= ce of

=    one or more Location-Path and/or Location-Query Options SHOULD= be

=    returned.”

= While section 5.10.8 defines this optional: “The two options MAY be i= ncluded in a response to indicate the

=    location of a new resource created with POST.”

= Should 5.8.2. refer to 5.10.8 to define the right behaviour (to avoid doubl= e definitions) ?

=  

= Btw “the two options MAY” -> this sounds like they have to b= e included as a pair, which is not the case.

=  

= * Section 5.9.1.3

= “When a cache receives a 2.03 (Valid) response, it needs to update th= e

=    stored response with the value of the Max-Age Option included = in the

=    response (see Section 5.6.2).”

= There seems to be a requirement here to update freshness of the stored resp= onse. While Section 5.6.2 does not require an end-point to update its store= d response in case new content arrives (“MAY replace the stored response”). Any reason for this difference?

=  

= * Section 5.10.3

= “An end-point receiving a request with a Proxy-Uri Option that is

=    unable or unwilling to act as a proxy for the request MUST cau= se the

=    return of a 5.05 (Proxying Not Supported) response.”

= Section 8.1 has a SHOULD requirement on returning 5.05. Any reason for the = difference, SHOULD for CoAP-HTTP proxy and MUST for CoAP proxy?

=  

= * Section 5.10.8

= “If a response with one or more Location-Path and/or Location-Query

=    Options passes through a cache and the implied URI identifies = one or

=    more currently stored responses, those entries SHOULD be marke= d as

=    not fresh.”

= This feels like optimizing for a case that almost never happens (I may be w= rong here).

= These are only used to indicate a new resource created. Typically a new res= ource would not be cached anywhere, so why do implementations need to expen= d effort to check this?

= Or can “new resource” in REST terms also include an update of a= n existing resource?

=  

= * Section 5.10.9

= “If any of the ETags

=    given as an option value match the ETag of the selected=

=    representation for the target resource”

= “selected” is not entirely clear. Does this mean “current= representation” ?

=  

= * “If none of the ETags match and,” -> “If none of the= ETags match OR,” ?

=  

= (comments continued in next email)

=  

= regards,

= Esko

=  



The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
--_000_031DD135F9160444ABBE3B0C36CED61809355D011DB3MPN1013MGDP_-- From tho@koanlogic.com Tue Apr 17 00:19:56 2012 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 DFA1D21F8527 for ; Tue, 17 Apr 2012 00:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMPdpdeVqTbY for ; Tue, 17 Apr 2012 00:19:56 -0700 (PDT) Received: from gonzo.koanlogic.com (koanlogic.com [64.251.31.111]) by ietfa.amsl.com (Postfix) with ESMTP id 6812E21F84FB for ; Tue, 17 Apr 2012 00:19:56 -0700 (PDT) Received: from chello084112045229.2.11.vie.surfer.at ([84.112.45.229]:56337 helo=[172.16.101.93]) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1SK2hX-0003sZ-GB; Tue, 17 Apr 2012 03:19:55 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: Date: Tue, 17 Apr 2012 09:19:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <93B860C2-622D-46D4-817D-AB1C37D717D3@koanlogic.com> References: To: Klaus Hartke X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 84.112.45.229 X-SA-Exim-Mail-From: tho@koanlogic.com X-Spam-DCC: : X-Spam-Pyzor: Reported 0 times. X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on gonzo.koanlogic.com) Cc: core@ietf.org Subject: Re: [core] draft-ietf-core-observe-05 - "obs" X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 07:19:57 -0000 I'm waving the flag for poor 'obs' here. It could provide a useful hint for a HTTP user agent that needs to take = some decision about how to access the resource through a HTTP-CoAP proxy = (e.g. use hanging GET instead of "usual" GET). [ See section 4.3.4.1.1.1. of the HTTP-CoAP mapping I-D -- wow, six = levels of indirection. That's deep nesting indeed :-) ]= From tho@koanlogic.com Tue Apr 17 00:19:57 2012 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 2CF7921F84FB for ; Tue, 17 Apr 2012 00:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kIjoF1ISyR7 for ; Tue, 17 Apr 2012 00:19:56 -0700 (PDT) Received: from gonzo.koanlogic.com (koanlogic.com [64.251.31.111]) by ietfa.amsl.com (Postfix) with ESMTP id A385F21F84FF for ; Tue, 17 Apr 2012 00:19:56 -0700 (PDT) Received: from chello084112045229.2.11.vie.surfer.at ([84.112.45.229]:56186 helo=[172.16.101.93]) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1SK2S9-0003pp-2u; Tue, 17 Apr 2012 03:04:03 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: Date: Tue, 17 Apr 2012 09:03:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <23D2F1F9-9005-4898-BA03-9978C1515D4A@koanlogic.com> References: <4F8C1A5C.10309@ericsson.com> <4F8C393E.9090403@ericsson.com> <65FED8AA-4B3E-4F57-BE42-982F140D0E07@koanlogic.com> <20120416203124.GA11308@koanlogic.com> To: Klaus Hartke X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 84.112.45.229 X-SA-Exim-Mail-From: tho@koanlogic.com X-Spam-DCC: : X-Spam-Pyzor: Reported 0 times. X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on gonzo.koanlogic.com) Cc: core@ietf.org Subject: Re: [core] wglc: coap caching and observe, caching underspecified X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 07:19:57 -0000 Hi Klaus, On Apr 17, 2012, at 3:45 AM, Klaus Hartke wrote: > let me rephrase this to make sure I understand it correctly: > [...] yes, nearly. The missing bit is not there because I was not crystal = clear (I implied a prior email of mine.) A cache can't leave out from the resource selection algorithm the = content negotiation options (ETag, Accept, If-None-Match). So these = attributes need to be understood. Further, my concern is more about future options than those defined in = the base spec since these are likely to be implemented pervasively. > * A proxy with cache does not recognize the critical Block1 option. It > is presented with a request that contains a Block1 option. It finds no > matching response, so it forwards the request to the server. It's > presented with another request that also contains a Block1 option, but > comes from a different client. It finds no matching response, so it > forwards the request to the server. The server cannot see that the two > requests are actually originating from two different clients, and > erroneously combines the two unrelated blocks. This happens because of an optimization in Block, not for the = segmentation logics per se, right ? Wouldn't be better if end-to-end options were designed to be cache = friendly instead of the other way around ? If we don't keep this in = mind I fear CoAP will not scale smoothly.= From matthieu.vial@non.schneider-electric.com Tue Apr 17 00:34:34 2012 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 6159021F8476 for ; Tue, 17 Apr 2012 00:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.084 X-Spam-Level: X-Spam-Status: No, score=-4.084 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObgOs3AqVGc9 for ; Tue, 17 Apr 2012 00:34:33 -0700 (PDT) Received: from mailX03.eud.schneider-electric.com (mailx03.eud.schneider-electric.com [205.167.7.41]) by ietfa.amsl.com (Postfix) with ESMTP id D944521F8484 for ; Tue, 17 Apr 2012 00:34:30 -0700 (PDT) Received: from ATEUI01.schneider-electric.com ([10.198.14.9]) by mailX03.eud.schneider-electric.com with ESMTP id 2012041709342896-151034 ; Tue, 17 Apr 2012 09:34:28 +0200 To: core@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 From: matthieu.vial@non.schneider-electric.com Message-ID: Date: Tue, 17 Apr 2012 09:31:06 +0200 X-MIMETrack: Serialize by Router on ATEUI01.Schneider-Electric.com/T/SVR/Schneider at 17/04/2012 09:35:34, Serialize complete at 17/04/2012 09:35:34, Itemize by SMTP Server on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 17/04/2012 09:34:28, Serialize by Router on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 17/04/2012 09:34:30, Serialize complete at 17/04/2012 09:34:30 Content-Type: text/plain; charset="US-ASCII" Subject: [core] draft-ietf-core-block-08 - multicast X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 07:34:34 -0000 CoAP supports multicast but there is actually no text in core block about multicast. Can we asssume that the stateless nature of core-block is enough to support multicast? Do we need to put guidelines in core-block or group-comm ? The first use case I see for multicast block is resource discovery on /.well-known/core. Regards, Matthieu From salvatore.loreto@ericsson.com Tue Apr 17 00:41:42 2012 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 AE28E21F8570 for ; Tue, 17 Apr 2012 00:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.405 X-Spam-Level: X-Spam-Status: No, score=-106.405 tagged_above=-999 required=5 tests=[AWL=-0.756, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNGJM8icjAiw for ; Tue, 17 Apr 2012 00:41:32 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBA221F856A for ; Tue, 17 Apr 2012 00:41:31 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-bc-4f8d1eaabb7b Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 85.3D.03534.AAE1D8F4; Tue, 17 Apr 2012 09:41:30 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.213.0; Tue, 17 Apr 2012 09:41:30 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 8A9CC2323 for ; Tue, 17 Apr 2012 10:41:29 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A29945285C for ; Tue, 17 Apr 2012 10:41:29 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 2A75552857 for ; Tue, 17 Apr 2012 10:41:29 +0300 (EEST) Message-ID: <4F8D1EA8.6080800@ericsson.com> Date: Tue, 17 Apr 2012 09:41:28 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: core@ietf.org References: <4F8C1A5C.10309@ericsson.com> <4F8C393E.9090403@ericsson.com> <65FED8AA-4B3E-4F57-BE42-982F140D0E07@koanlogic.com> <20120416203124.GA11308@koanlogic.com> <23D2F1F9-9005-4898-BA03-9978C1515D4A@koanlogic.com> In-Reply-To: <23D2F1F9-9005-4898-BA03-9978C1515D4A@koanlogic.com> Content-Type: multipart/alternative; boundary="------------020707070300090708090003" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [core] wglc: coap caching and observe, caching underspecified X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 07:41:43 -0000 --------------020707070300090708090003 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Hi there, I think we should define first in the CoAP draft what is a cache, which type of cache we can have in a CoAP network etc.etc. then decide what is a Cache operation is etc. etc my guess is that at the end it will be something similar to what we have in httpbis-p6 Proper cache operation preserves the semantics of HTTP transfers ([Part2 ]) while eliminating the transfer of information already held in the cache. Although caching is an entirely OPTIONAL feature of HTTP, we assume that reusing the cached response is desirable and that such reuse is the default behavior when no requirement or locally-desired configuration prevents it. Therefore, HTTP cache requirements are focused on preventing a cache from either storing a non-reusable response or reusing a stored response inappropriately. then my problem is with the option that change the semantic of a request like Observe. This is something we have to solve! cheers Salvatore -- Salvatore Loreto, PhD www.sloreto.com On 4/17/12 9:03 AM, Thomas Fossati wrote: > Hi Klaus, > > On Apr 17, 2012, at 3:45 AM, Klaus Hartke wrote: >> let me rephrase this to make sure I understand it correctly: >> [...] > yes, nearly. The missing bit is not there because I was not crystal clear (I implied a prior email of mine.) > > A cache can't leave out from the resource selection algorithm the content negotiation options (ETag, Accept, If-None-Match). So these attributes need to be understood. > > Further, my concern is more about future options than those defined in the base spec since these are likely to be implemented pervasively. > >> * A proxy with cache does not recognize the critical Block1 option. It >> is presented with a request that contains a Block1 option. It finds no >> matching response, so it forwards the request to the server. It's >> presented with another request that also contains a Block1 option, but >> comes from a different client. It finds no matching response, so it >> forwards the request to the server. The server cannot see that the two >> requests are actually originating from two different clients, and >> erroneously combines the two unrelated blocks. > This happens because of an optimization in Block, not for the segmentation logics per se, right ? > > Wouldn't be better if end-to-end options were designed to be cache friendly instead of the other way around ? If we don't keep this in mind I fear CoAP will not scale smoothly. > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --------------020707070300090708090003 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Hi there,

I think we should define first in the CoAP draft what is a cache, which type of cache we can have in a CoAP network etc.etc.
then decide what is a Cache operation is etc. etc

my guess is that at the end it will be something similar to what we have in httpbis-p6

   Proper cache operation preserves the semantics of HTTP transfers
   ([Part2]) while eliminating the transfer of information already held
   in the cache.  Although caching is an entirely OPTIONAL feature of
   HTTP, we assume that reusing the cached response is desirable and
   that such reuse is the default behavior when no requirement or
   locally-desired configuration prevents it.  Therefore, HTTP cache
   requirements are focused on preventing a cache from either storing a
   non-reusable response or reusing a stored response inappropriately.

then my problem is with the option that change the semantic of a request like Observe.
This is something we have to solve!

cheers
Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com


On 4/17/12 9:03 AM, Thomas Fossati wrote:
Hi Klaus,

On Apr 17, 2012, at 3:45 AM, Klaus Hartke wrote:
let me rephrase this to make sure I understand it correctly:
[...]
yes, nearly.  The missing bit is not there because I was not crystal clear (I implied a prior email of mine.)

A cache can't leave out from the resource selection algorithm the content negotiation options (ETag, Accept, If-None-Match).  So these attributes need to be understood.

Further, my concern is more about future options than those defined in the base spec since these are likely to be implemented pervasively.

* A proxy with cache does not recognize the critical Block1 option. It
is presented with a request that contains a Block1 option. It finds no
matching response, so it forwards the request to the server. It's
presented with another request that also contains a Block1 option, but
comes from a different client. It finds no matching response, so it
forwards the request to the server. The server cannot see that the two
requests are actually originating from two different clients, and
erroneously combines the two unrelated blocks.
This happens because of an optimization in Block, not for the segmentation logics per se, right ?

Wouldn't be better if end-to-end options were designed to be cache friendly instead of the other way around ?  If we don't keep this in mind I fear CoAP will not scale smoothly.
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

--------------020707070300090708090003-- From esko.dijk@philips.com Tue Apr 17 02:04:00 2012 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 D9D6E21F858E for ; Tue, 17 Apr 2012 02:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.899 X-Spam-Level: X-Spam-Status: No, score=-3.899 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qabOVRnBihu0 for ; Tue, 17 Apr 2012 02:03:55 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id B44E621F852A for ; Tue, 17 Apr 2012 02:03:55 -0700 (PDT) Received: from mail194-ch1-R.bigfish.com (10.43.68.234) by CH1EHSOBE017.bigfish.com (10.43.70.67) with Microsoft SMTP Server id 14.1.225.23; Tue, 17 Apr 2012 09:03:54 +0000 Received: from mail194-ch1 (localhost [127.0.0.1]) by mail194-ch1-R.bigfish.com (Postfix) with ESMTP id B1BDC3C006A; Tue, 17 Apr 2012 09:03:54 +0000 (UTC) X-SpamScore: -43 X-BigFish: VPS-43(zz217bL15d6O9251J1b0bM542Mzz1202hzz1033IL8275dhz2dh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI Received: from mail194-ch1 (localhost.localdomain [127.0.0.1]) by mail194-ch1 (MessageSwitch) id 1334653432970663_17357; Tue, 17 Apr 2012 09:03:52 +0000 (UTC) Received: from CH1EHSMHS010.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.226]) by mail194-ch1.bigfish.com (Postfix) with ESMTP id DDDF6A00C4; Tue, 17 Apr 2012 09:03:52 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CH1EHSMHS010.bigfish.com (10.43.70.10) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 17 Apr 2012 09:03:52 +0000 Received: from 011-DB3MPN1-013.MGDPHG.emi.philips.com ([169.254.3.240]) by 011-DB3MMR1-005.MGDPHG.emi.philips.com ([10.128.28.55]) with mapi id 14.01.0355.003; Tue, 17 Apr 2012 10:06:11 +0100 From: "Dijk, Esko" To: Klaus Hartke Thread-Topic: [core] draft-ietf-core-block-08 - Disentangle Block and Success Response Codes Thread-Index: AQHNHEDN08KkWvwVLkKAGVQuvdeeVpaet8gw Date: Tue, 17 Apr 2012 09:06:11 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618093612@011-DB3MPN1-013.MGDPHG.emi.philips.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.101] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "core@ietf.org WG" Subject: Re: [core] draft-ietf-core-block-08 - Disentangle Block and Success Response Codes X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 09:04:00 -0000 Hi Klaus, FYI I made another proposal to 'fix' this that slightly modifies the meanin= g of response codes in the -block context: see http://www.ietf.org/mail-arc= hive/web/core/current/msg02372.html (Also the earlier/related thread messages related to this one are relevant = in this discussion.) This interpretation in my view is already present in the current -block spe= c, although not explicitly. Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Kla= us Hartke Sent: Tuesday 17 April 2012 4:18 To: core@ietf.org Subject: [core] draft-ietf-core-block-08 - Disentangle Block and Success Re= sponse Codes When a client performs an atomic block-wise POST/PUT, the server returns a 2.01 (Created) or 2.04 (Changed) response for each uploaded block. coap-09 defines the two response codes as follows: * 2.01 (Created) means that a resource was created at the target URI/Location URI and requires that a cache marks any stored response for the created resource as not fresh. * 2.04 (Changed) means that the target resource was changed and requires that a cache marks any stored response for the changed resource as not fresh. The problem is: the target resource is not really created or changed in an atomic block-wise POST/PUT before the last block is uploaded. Invalidating all caches long before the POST/PUT is complete doesn't sound like a good idea. I propose to return a different, new response code that doesn't have an effect on caches and conveys the non-final nature of the response. An equivalent of the HTTP 100 status code [1] would be the best fit: - 100 Continue The client SHOULD continue with its request. This interim response is used to inform the client that the initial part of the request has been received and has not yet been rejected by the server. The client SHOULD continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The server MUST send a final response after the request has been completed. Klaus [1] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-19#section-7= .1.1 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From esko.dijk@philips.com Tue Apr 17 03:10:54 2012 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 3675421F861A for ; Tue, 17 Apr 2012 03:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.048 X-Spam-Level: X-Spam-Status: No, score=-6.048 tagged_above=-999 required=5 tests=[AWL=1.950, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yd7f8SYSD7t5 for ; Tue, 17 Apr 2012 03:10:51 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 87EA921F85F0 for ; Tue, 17 Apr 2012 03:10:51 -0700 (PDT) Received: from mail137-tx2-R.bigfish.com (10.9.14.237) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.23; Tue, 17 Apr 2012 10:10:50 +0000 Received: from mail137-tx2 (localhost [127.0.0.1]) by mail137-tx2-R.bigfish.com (Postfix) with ESMTP id C59B34004C4 for ; Tue, 17 Apr 2012 10:10:50 +0000 (UTC) X-SpamScore: -23 X-BigFish: VPS-23(zz217bL15d6O9251Jc85fhcaaemb19emzz1202hzz1033IL8275dhz2dh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI Received: from mail137-tx2 (localhost.localdomain [127.0.0.1]) by mail137-tx2 (MessageSwitch) id 133465744847004_12635; Tue, 17 Apr 2012 10:10:48 +0000 (UTC) Received: from TX2EHSMHS012.bigfish.com (unknown [10.9.14.235]) by mail137-tx2.bigfish.com (Postfix) with ESMTP id 051C1220233 for ; Tue, 17 Apr 2012 10:10:48 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by TX2EHSMHS012.bigfish.com (10.9.99.112) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 17 Apr 2012 10:10:46 +0000 Received: from 011-DB3MMR1-020.MGDPHG.emi.philips.com (10.128.28.101) by 011-DB3MMR1-009.MGDPHG.emi.philips.com (10.128.28.48) with Microsoft SMTP Server (TLS) id 14.1.355.3; Tue, 17 Apr 2012 11:10:45 +0100 Received: from 011-DB3MPN1-013.MGDPHG.emi.philips.com ([169.254.3.240]) by 011-DB3MMR1-020.MGDPHG.emi.philips.com ([fe80::65e7:4d4c:4c67:daa9%11]) with mapi id 14.01.0355.003; Tue, 17 Apr 2012 11:10:44 +0100 From: "Dijk, Esko" To: "core@ietf.org WG" Thread-Topic: draft-ietf-core-coap-09 - More editorial comments WGLC Thread-Index: Ac0cglmD+IrZ0Jr4TDmCbE1InpP1DA== Date: Tue, 17 Apr 2012 10:13:27 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618093687@011-DB3MPN1-013.MGDPHG.emi.philips.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.101] Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED618093687011DB3MPN1013MGDP_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: [core] draft-ietf-core-coap-09 - More editorial comments WGLC X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 10:10:54 -0000 --_000_031DD135F9160444ABBE3B0C36CED618093687011DB3MPN1013MGDP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here is part 2 of core-coap editorial comments. * Section 5.2 "Response Codes in the Client Error and Server Error class that are unrecognized by an end-point MUST be treated as being equivalent to the generic Response Code of that class." There's no definition of what are, or can be, the generic Response Codes of= each class. Mention that these are 4.00 and 5.00 (or *.00 ?) Maybe such info could go h= ere, or section 5.9.* or even in section 11.1.2. * Section 6.4 "NOTE: In the usual case where the request's destination IP address is derived from the host part, this ensures that Uri-Host Options are only used for host parts of the form reg-name." To remove potential confusion maybe write without plural form: "this ensures that an Uri-Host Option is only used for a host part of = the form reg-name [RFC3986]." Another potential improvement may be "host part" -> " component" (is = the part the same thing as the component?) * Section 6.5 "the hexadecimal notation in CoAP URIs MUST use uppercase letters" But the last example URI in section 6.3 does not? Or is there a requirement= that lowercase is accepted by parsers but uppercase MUST be generated? * "Otherwise, let /host/ be the IP-literal (making use of the conventions of [RFC5952]) or IP= v4address representing the request's destination IP address." Should this sentence include the reg-name form which may be in /host/ ? * "unreserved set", "sub-delims" set, etc. Should a reference [RFC3986] be indicated in the beginning of section 6.= 5. to cover all these concepts? (This RFC is mentioned but only in a side note about percent encoding - = not for the entire section.) * Section 7.1.1. "actually following the link" Should this be phrased more formally like "actually requesting the conten= t from the link" ? * link-extension ABNF notation: "=3D" -> "=3D/" for 2nd line * ABNF: Just thinking whether quoted content types would be allowed in ligh= t of the title of ticket #198 (http://trac.tools.ietf.org/wg/core/trac/tick= et/198). Or maybe the title of the ticket is a bit too wide in scope? * Section 8.2.2. "Upon success, a 200 (OK) response SHOULD be returned. The payload of the response MUST be a representation of the target CoAP resource, and the Content-Type Option be set accordingly. The response MUST indicate a Max-Age value that is no greater than the remaining time the representation can be considered fresh. If the CoAP entity has an entity tag, the proxy SHOULD include an ETag Option in the response." "Content-Type Option" -> "Content-Type header field" ? "Max-Age value" -> "Expires" header field? (Or maybe "Age" is involved) last sentence -> to correct to "ETag header field" and perhaps refer to "ET= ag Option in the CoAP response" instead of entity tag? * Section 8.2.4. Does this need a sentence about how to handle Location-Query and Location-U= ri CoAP options from the CoAP origin server? E.g. mention "Location" header field SHOULD be returned if any of those pre= sent. * Section 10.1.3 TLS_RSA_PSK_WITH_AES_128_CBC_SHA -> Add RFC ref? "found in a URI type fields" -> typo * Appendix E Typo "method impotence" () regards, Esko ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_031DD135F9160444ABBE3B0C36CED618093687011DB3MPN1013MGDP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here is part 2 of core-coap editorial comments.

 

* Section 5.2

“Response Codes in

   the Client Error and Server Error class that= are unrecognized by an

   end-point MUST be treated as being equivalen= t to the generic Response

   Code of that class.”

There’s no definition of what are, or can be, the g= eneric Response Codes of each class.

Mention that these are 4.00 and 5.00 (or *.00 ?) Maybe= such info could go here, or section 5.9.* or even in section 11.1.2.

 

* Section 6.4

“NOTE: In the usual case where the request's destin= ation IP

       address is derived f= rom the host part, this ensures that Uri-Host

       Options are only use= d for host parts of the form reg-name.”

To remove potential confusion maybe write without plural = form:

     “this ensures that an Uri-= Host Option is only used for a host part of the form reg-name [RFC3986].= 221;

Another potential improvement may be “host partR= 21; -> “<host> component” (is the part the same thing = as the component?)

 

* Section 6.5

“the hexadecimal notation in CoAP URIs MUST use uppercase letter=
s”
But the last example URI in section 6.3 does not? Or is there a requir=
ement that lowercase is accepted  by parsers but uppercase MUST be gen=
erated?
 
* “Otherwise, let /host/ be the IP-literal (making use of the
        conventions of [RFC5952]) or IPv4address represent=
ing the
        request's destination IP ad=
dress.”
Should this sentence include the reg-name form which may be in /host/ =
?
 
* “unreserved set”, “sub-delims” set, etc.
   Should a reference [RFC3986] be indicated in the beginnin=
g of section 6.5. to cover all these concepts?
   (This RFC is mentioned but only in a side note about perc=
ent encoding – not for the entire section.)
 
* Section 7.1.1. “actually following the link”
  Should this be phrased more formally like “actually reque=
sting the content from the link” ?
 
* link-extension ABNF notation: “=3D” -> “=3D/=
221; for 2nd line
 
* ABNF: Just thinking whether quoted content types would be allowed in=
 light of the title of ticket #198 (http://trac.tools.ietf.org/wg/core/trac/ticket/198<=
/a>). Or maybe the title of the ticket is a bit too wide in scope?
 
* Section 8.2.2.
“Upon success, a 200 (OK) response SHOULD be returned.  The=
 payload of
   the response MUST be a representation of the target CoAP =
resource,
   and the Content-Type Option be set accordingly.  The=
 response MUST
   indicate a Max-Age value that is no greater than the rema=
ining time
   the representation can be considered fresh.  If the =
CoAP entity has
   an entity tag, the proxy SHOULD include an ETag Option in=
 the
   response.”
“Content-Type Option” -> “Content-Type header fie=
ld” ?
“Max-Age value” -> “Expires” header field? =
(Or maybe “Age” is involved)
last sentence -> to correct to “ETag header field” and =
perhaps refer to “ETag Option in the CoAP response” instead of =
entity tag?
 
* Section 8.2.4.
Does this need a sentence about how to handle Location-Query and Locat=
ion-Uri CoAP options from the CoAP origin server?
E.g. mention “Location” header field SHOULD be returned if=
 any of those present.
 
* Section 10.1.3
TLS_RSA_PSK_WITH_AES_128_CBC_SHA -> Add RFC ref?
“found in a URI type fields” –> typo
 
* Appendix E
Typo “method impotence” (<joke suppressed>)
 
regards,

Esko



The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
--_000_031DD135F9160444ABBE3B0C36CED618093687011DB3MPN1013MGDP_-- From esko.dijk@philips.com Tue Apr 17 03:25:42 2012 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 89C9B21F859F for ; Tue, 17 Apr 2012 03:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[AWL=0.971, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccyQhrCoZKpl for ; Tue, 17 Apr 2012 03:25:38 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id C13B421F8613 for ; Tue, 17 Apr 2012 03:25:28 -0700 (PDT) Received: from mail183-tx2-R.bigfish.com (10.9.14.237) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.23; Tue, 17 Apr 2012 10:25:28 +0000 Received: from mail183-tx2 (localhost [127.0.0.1]) by mail183-tx2-R.bigfish.com (Postfix) with ESMTP id 0F44720044F for ; Tue, 17 Apr 2012 10:25:28 +0000 (UTC) X-SpamScore: -14 X-BigFish: VPS-14(zz217bL15d6O9251Jc85fh62a3Izz1202hzz8275bhz2dh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI Received: from mail183-tx2 (localhost.localdomain [127.0.0.1]) by mail183-tx2 (MessageSwitch) id 1334658326684592_8952; Tue, 17 Apr 2012 10:25:26 +0000 (UTC) Received: from TX2EHSMHS035.bigfish.com (unknown [10.9.14.246]) by mail183-tx2.bigfish.com (Postfix) with ESMTP id A1F83160073 for ; Tue, 17 Apr 2012 10:25:26 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by TX2EHSMHS035.bigfish.com (10.9.99.135) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 17 Apr 2012 10:25:23 +0000 Received: from 011-DB3MPN1-013.MGDPHG.emi.philips.com ([169.254.3.240]) by 011-DB3MMR1-002.MGDPHG.emi.philips.com ([10.128.28.52]) with mapi id 14.01.0355.003; Tue, 17 Apr 2012 11:27:31 +0100 From: "Dijk, Esko" To: "core@ietf.org WG" Thread-Topic: draft-ietf-core-coap-09 - Multicast NON/RST matching rules Thread-Index: Ac0chFA+CNhWlwhPT8WgvaCzVcNpQA== Date: Tue, 17 Apr 2012 10:27:31 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED6180936A8@011-DB3MPN1-013.MGDPHG.emi.philips.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.101] Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED6180936A8011DB3MPN1013MGDP_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: [core] draft-ietf-core-coap-09 - Multicast NON/RST matching rules X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 10:25:42 -0000 --_000_031DD135F9160444ABBE3B0C36CED6180936A8011DB3MPN1013MGDP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Section 4.3 defines matching based on Message ID for both unicast and multi= cast. Only for unicast, there is additional source/destination matching req= uired. Could/should we require matching of source/destination for multicast as wel= l, in as far as possible? E.g. in NoSec, UDP destination port number of multicast message and unicast= response source port must match. [In case we don't include this on purpose= , why then is this not needed for multicast but is needed for unicast?] Or, e.g. for any tbd-in-the-future secured multicast modes the security con= text MUST match. Esko Dijk Senior scientist, Lighting Control Systems Philips Group Innovation, Research High Tech Campus 34 (room 1.059) 5656 AE Eindhoven, The Netherlands Phone: +31 40 27 47947, E-Mail: esko.dijk@philips.com Mobile: +31 6 12642103 www.research.philips.com ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_031DD135F9160444ABBE3B0C36CED6180936A8011DB3MPN1013MGDP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable


The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
--_000_031DD135F9160444ABBE3B0C36CED6180936A8011DB3MPN1013MGDP_-- From esko.dijk@philips.com Tue Apr 17 04:12:42 2012 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 A9FFB21F84EE for ; Tue, 17 Apr 2012 04:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.248 X-Spam-Level: X-Spam-Status: No, score=-4.248 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzxVQjPASFqE for ; Tue, 17 Apr 2012 04:12:38 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 9745421F84DC for ; Tue, 17 Apr 2012 04:12:38 -0700 (PDT) Received: from mail127-ch1-R.bigfish.com (10.43.68.229) by CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id 14.1.225.23; Tue, 17 Apr 2012 11:12:37 +0000 Received: from mail127-ch1 (localhost [127.0.0.1]) by mail127-ch1-R.bigfish.com (Postfix) with ESMTP id D9D3F260118 for ; Tue, 17 Apr 2012 11:12:37 +0000 (UTC) X-SpamScore: -35 X-BigFish: VPS-35(zz217bL15d6O9251Jc85fh168aJzz1202hzz1033IL8275dhz2dh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI Received: from mail127-ch1 (localhost.localdomain [127.0.0.1]) by mail127-ch1 (MessageSwitch) id 1334661156409903_14290; Tue, 17 Apr 2012 11:12:36 +0000 (UTC) Received: from CH1EHSMHS024.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.250]) by mail127-ch1.bigfish.com (Postfix) with ESMTP id 603E74C006B for ; Tue, 17 Apr 2012 11:12:36 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CH1EHSMHS024.bigfish.com (10.43.70.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 17 Apr 2012 11:12:33 +0000 Received: from 011-DB3MPN1-013.MGDPHG.emi.philips.com ([169.254.3.240]) by 011-DB3MMR1-007.MGDPHG.emi.philips.com ([10.128.28.57]) with mapi id 14.01.0355.003; Tue, 17 Apr 2012 12:14:55 +0100 From: "Dijk, Esko" To: "core@ietf.org WG" Thread-Topic: draft-ietf-core-coap-09 - Proxying of multicast requests Thread-Index: Ac0ciu7lLw120uPlTeKfdF2mdWqI2A== Date: Tue, 17 Apr 2012 11:14:54 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED6180936F2@011-DB3MPN1-013.MGDPHG.emi.philips.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.101] Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED6180936F2011DB3MPN1013MGDP_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: [core] draft-ietf-core-coap-09 - Proxying of multicast requests X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 11:12:42 -0000 --_000_031DD135F9160444ABBE3B0C36CED6180936F2011DB3MPN1013MGDP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In Section 5.7 (Proxying) the possibility of a multicast request in the Pro= xy-Uri is not explicitly considered. Should we mention this possibility? (If yes, do we need to update/adapt our= caching text to include the multicast case?) Current text suggests that only unicast has been considered, e.g. single de= stination and single stored response mentioned: "If the proxy does not employ a cache, then it simply forwards the translated request to the determined destination. Otherwise, if it does employ a cache but does not have a stored response that matches the translated request and is considered fresh, then it needs to refresh its cache according to Section 5.6." "Otherwise, the proxy returns the response to the client." If multicast is supported then this section may have to be updated, OR we c= ould add some sentences only applicable for the multicast case. See also the email thread that ended with this message http://www.ietf.org/= mail-archive/web/core/current/msg02802.html kind of concluding that we do not specify internal processing (filtering, a= ggregation, etc.) by an intermediary for multicast proxying. Though caching= may still be in scope of core-coap. regards, Esko ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_031DD135F9160444ABBE3B0C36CED6180936F2011DB3MPN1013MGDP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In Section 5.7 (Proxying) the possibility of a multi= cast request in the Proxy-Uri  is not explicitly considered.

Should we mention this possibility? (If yes, do we n= eed to update/adapt our caching text to include the multicast case?)

 

Current text suggests that only unicast has been con= sidered, e.g. single destination and single stored response mentioned:

 

“If the proxy does not employ a cache, then it= simply forwards the

   translated request to the determined de= stination. Otherwise, if it

   does employ a cache but does not have a= stored response that matches

   the translated request and is considere= d fresh, then it needs to

   refresh its cache according to Section = 5.6.”

 

“Otherwise, the proxy returns the response to = the client.”

 

If multicast is supported then this section may have= to be updated, OR we could add some sentences only applicable for the mult= icast case.

See also the email thread that ended with this messa= ge http://www.ietf.org/mail-archive/web/core/current/msg02802.html

kind of concluding that we do not specify internal p= rocessing (filtering, aggregation, etc.) by an intermediary for multicast p= roxying. Though caching may still be in scope of core-coap.

 

regards,

Esko

 



The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
--_000_031DD135F9160444ABBE3B0C36CED6180936F2011DB3MPN1013MGDP_-- From esko.dijk@philips.com Tue Apr 17 07:14:02 2012 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 357FD11E8094 for ; Tue, 17 Apr 2012 07:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.177 X-Spam-Level: X-Spam-Status: No, score=-4.177 tagged_above=-999 required=5 tests=[AWL=-0.578, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KgArwcs1psi for ; Tue, 17 Apr 2012 07:13:58 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB7611E8074 for ; Tue, 17 Apr 2012 07:13:58 -0700 (PDT) Received: from mail90-ch1-R.bigfish.com (10.43.68.249) by CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id 14.1.225.23; Tue, 17 Apr 2012 14:13:57 +0000 Received: from mail90-ch1 (localhost [127.0.0.1]) by mail90-ch1-R.bigfish.com (Postfix) with ESMTP id A37FB1E0540; Tue, 17 Apr 2012 14:13:57 +0000 (UTC) X-SpamScore: -40 X-BigFish: VPS-40(zz217bL15d6O9251J168aJ542Mzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI Received: from mail90-ch1 (localhost.localdomain [127.0.0.1]) by mail90-ch1 (MessageSwitch) id 1334672036297246_5985; Tue, 17 Apr 2012 14:13:56 +0000 (UTC) Received: from CH1EHSMHS003.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.252]) by mail90-ch1.bigfish.com (Postfix) with ESMTP id 447CE2E00D5; Tue, 17 Apr 2012 14:13:56 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CH1EHSMHS003.bigfish.com (10.43.70.3) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 17 Apr 2012 14:13:54 +0000 Received: from 011-DB3MPN1-013.MGDPHG.emi.philips.com ([169.254.3.240]) by 011-DB3MMR1-003.MGDPHG.emi.philips.com ([10.128.28.53]) with mapi id 14.01.0355.003; Tue, 17 Apr 2012 15:16:36 +0100 From: "Dijk, Esko" To: "matthieu.vial@non.schneider-electric.com" , "core@ietf.org" Thread-Topic: [core] draft-ietf-core-block-08 - multicast Thread-Index: AQHNHGyQSMM09+CguEqSZiSaRLjQT5afDZ0g Date: Tue, 17 Apr 2012 14:16:35 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED61809380D@011-DB3MPN1-013.MGDPHG.emi.philips.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.101] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: Re: [core] draft-ietf-core-block-08 - multicast X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 14:14:02 -0000 In my view: if core-block intends to support it, that should at the very le= ast be mentioned. If core-block does not aim to support it, that should be shortly mentioned.= (E.g. for the reason that there is not enough implementation experience ye= t with that) A second use case is distributing firmware upgrades to a group of nodes by = PUTting or POSTing blocks of data in multicast. regards, Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of mat= thieu.vial@non.schneider-electric.com Sent: Tuesday 17 April 2012 9:31 To: core@ietf.org Subject: [core] draft-ietf-core-block-08 - multicast CoAP supports multicast but there is actually no text in core block about multicast. Can we asssume that the stateless nature of core-block is enough to support multicast? Do we need to put guidelines in core-block or group-comm ? The first use case I see for multicast block is resource discovery on /.well-known/core. Regards, Matthieu _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From cabo@tzi.org Tue Apr 17 08:08:15 2012 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 4193911E80B2 for ; Tue, 17 Apr 2012 08:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.439 X-Spam-Level: X-Spam-Status: No, score=-106.439 tagged_above=-999 required=5 tests=[AWL=-0.190, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFWEGeasivj7 for ; Tue, 17 Apr 2012 08:08:14 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 67B2911E80AE for ; Tue, 17 Apr 2012 08:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3HF84d2000511; Tue, 17 Apr 2012 17:08:04 +0200 (CEST) Received: from [192.168.217.105] (p54899B15.dip.t-dialin.net [84.137.155.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5A8FCED0; Tue, 17 Apr 2012 17:08:04 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <031DD135F9160444ABBE3B0C36CED61809380D@011-DB3MPN1-013.MGDPHG.emi.philips.com> Date: Tue, 17 Apr 2012 17:08:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <031DD135F9160444ABBE3B0C36CED61809380D@011-DB3MPN1-013.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1257) Cc: "core@ietf.org" Subject: Re: [core] draft-ietf-core-block-08 - multicast X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 15:08:15 -0000 > In my view: if core-block intends to support it, that should at the = very least be mentioned. Well, I'm not so sure. Multicasting happens down at the message layer. -block does not mention, say, DTLS either. Is there something about multicast that requires special support in = -block? I'm not aware of it. Gr=FC=DFe, Carsten From cabo@tzi.org Tue Apr 17 08:40:16 2012 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 075BA11E8088 for ; Tue, 17 Apr 2012 08:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.433 X-Spam-Level: X-Spam-Status: No, score=-106.433 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YO1IlS7KVA9I for ; Tue, 17 Apr 2012 08:40:14 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 8E61B11E8080 for ; Tue, 17 Apr 2012 08:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3HFe5r4016629; Tue, 17 Apr 2012 17:40:05 +0200 (CEST) Received: from [192.168.217.105] (p54899B15.dip.t-dialin.net [84.137.155.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41360EFE; Tue, 17 Apr 2012 17:40:05 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <031DD135F9160444ABBE3B0C36CED6180936F2@011-DB3MPN1-013.MGDPHG.emi.philips.com> Date: Tue, 17 Apr 2012 17:40:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7F92E32D-5F89-4EFF-980C-EA56B4960508@tzi.org> References: <031DD135F9160444ABBE3B0C36CED6180936F2@011-DB3MPN1-013.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1257) Cc: "core@ietf.org WG" Subject: Re: [core] draft-ietf-core-coap-09 - Proxying of multicast requests X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 15:40:16 -0000 Good point. I think the most important thing to understand here is how a multicast = request (there are no multicast responses) uses/modifies our endpoint = abstraction. Say, I do a=20 GET coap://[ff02::1]/.well-known/core I get back responses from a number of endpoints, including, say = [aaaa::4711]. Is that response cacheable in the same way as a response to GET coap://[aaaa::4711]/.well-known/core would be? Does it replace that entry, if I have it? Probably not, because we have some rules that make servers respond = differently when they are addressed by multicast. (In a way, sending a = request via multicast is invoking an implicit critical option.) So what would we cache? (Clearly, the response can't be cached as the response for GET coap://[ff02::1]/.well-known/core first of all, there may be many of these, and the responding set may = change all the time.) So maybe we cache it as a=20 GET coap://[aaaa::4711]/.well-known/core with a special "virtual" critical option "this was a response to = multicast"? Gr=FC=DFe, Carsten From lohse@itm.uni-luebeck.de Tue Apr 17 16:39:49 2012 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 EB48911E80DE for ; Tue, 17 Apr 2012 16:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1k1rkoYIEGNs for ; Tue, 17 Apr 2012 16:39:48 -0700 (PDT) Received: from ip1.rz.uni-luebeck.de (ip1.rz.uni-luebeck.de [141.83.100.71]) by ietfa.amsl.com (Postfix) with ESMTP id 3AEC411E80D7 for ; Tue, 17 Apr 2012 16:39:47 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwJADz+jU+NU0Rk/2dsb2JhbABEgxwbrgeBB4NFNAJMDQgBAYgOmFGhE5BjBJthikSCaQ Received: from itm01.itm.uni-luebeck.de ([141.83.68.100]) by ip1.rz.uni-luebeck.de with ESMTP; 18 Apr 2012 01:39:46 +0200 Received: from [192.168.17.53] (dslc-082-082-140-117.pools.arcor-ip.net [82.82.140.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by itm01.itm.uni-luebeck.de (Postfix) with ESMTPSA id 7B1C883F8E1 for ; Wed, 18 Apr 2012 01:39:45 +0200 (CEST) Message-ID: <4F8DFF3D.50201@itm.uni-luebeck.de> Date: Wed, 18 Apr 2012 01:39:41 +0200 From: Stephan Lohse User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: "core@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [core] End of Options Marker/Use of a delta of 15 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 23:39:49 -0000 Hi, do "unlimited options" and the need for an end-of-options marker mean that deltas of 15 should not be used in that case, or is using a delta of 15 fine as long as the length is not zero? Regards, - Stephan Lohse From fluffy@cisco.com Tue Apr 17 21:57:06 2012 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 BB6C221F8453 for ; Tue, 17 Apr 2012 21:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.76 X-Spam-Level: X-Spam-Status: No, score=-109.76 tagged_above=-999 required=5 tests=[AWL=0.839, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JckY1VqKB26h for ; Tue, 17 Apr 2012 21:57:02 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 84F4421F8575 for ; Tue, 17 Apr 2012 21:57:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=491; q=dns/txt; s=iport; t=1334725022; x=1335934622; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=Auzs5h9vRHna0HWCoSnwdepmv7dvJ0SMbojXFBZnf1c=; b=cbqxxIixJZg74Ggw6eUeUey6SUMmWrQfQPttTg0ChLZ8gS/fiH/Waetf l2A1l2Xsw+vTEE7k/r4UbG6wGags0fZkbBUp3+jVqN8Mwsd8wiUfj7iA9 U+FZp5dSwBvJRzslKwlnDDydfLOTFQwR+GEwTyEHzpk+RFitbrXmlJbNc s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4GAJBIjk+rRDoH/2dsb2JhbABEgxyuKIEHgiIBJ4F9NYdsmFSBKJ95kAVjBIhcjROFcohegWmDBg X-IronPort-AV: E=Sophos;i="4.75,439,1330905600"; d="scan'208";a="40940510" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 18 Apr 2012 04:57:02 +0000 Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3I4v1Ed005964 for ; Wed, 18 Apr 2012 04:57:02 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Apr 2012 22:57:01 -0600 Message-Id: <2BEA1770-D295-4752-BA9C-C6F5ADBF498B@cisco.com> To: core WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] WGLC draft-ietf-core-coap-09 - packet size X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 04:57:06 -0000 Section 3 Packet size - I'm a bit skeptical of a default packet size of = less than 1280. That seems pretty big for when nothing else is known. = Lets say I have an HTTP to COAP proxy sitting on a 1G interface with = jumbo grams enables. And it is going to send a request to a CoAP node = sitting on 802.15 mesh network. Do you really think sending 9k packets = is OK? I think we should set the max packets size to something that has = a open of working on constrained networks.=20 From fluffy@cisco.com Tue Apr 17 21:57:18 2012 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 1BD4221F8471 for ; Tue, 17 Apr 2012 21:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.928 X-Spam-Level: X-Spam-Status: No, score=-109.928 tagged_above=-999 required=5 tests=[AWL=0.671, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQkzNDOxK1QP for ; Tue, 17 Apr 2012 21:57:13 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id E124721F8460 for ; Tue, 17 Apr 2012 21:57:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=750; q=dns/txt; s=iport; t=1334725033; x=1335934633; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=TT71HNc81RDyqZC+DPIpfPWU5B//4juY0baiPtH4zhs=; b=Qo3UjCJX45p5sLtxsilRq9+8zUrcDCTX72KZfDoF4lK3uUA2L4wefZBz eSLcRpelWr4NpCcd0rPIsNJnO98/EjG8A/tQSo0rsqY1OnW0CnMdogLUt rM7mLW7wZ29CbwY9kRuYNLdaslbBUtlSWRqRIT0abFl00RePZUT0aovAm 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4GAJBIjk+rRDoH/2dsb2JhbABEgxyuKIEHgiIBJ4F9NYdsmFSBKJ95kAVjBIhcjROFcohegWmDBoE1Bw X-IronPort-AV: E=Sophos;i="4.75,439,1330905600"; d="scan'208";a="40940527" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 18 Apr 2012 04:57:13 +0000 Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3I4v1Ee005964 for ; Wed, 18 Apr 2012 04:57:13 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Apr 2012 22:57:12 -0600 Message-Id: <9E5F67AC-943D-4A97-B19D-313B7194D9AF@cisco.com> To: core WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] WGLC draft-ietf-core-coap-09 Reuse of MID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 04:57:18 -0000 =20 I don't understand when a MID can be reused. I'm primarily concerned = about use of default MID.=20 Say I am on a network with 5 seconds latency but no packets are lost.=20 A sends Req1 to B. Due to latency, A retransmits Req1 to B. B sends = response 1 to A which A receives. No A decided to immediately send Req2 = to B. In the meantime, B had received the retransmission of Req1 and = resent the response. The response arrives at A after A has send the = second request but because the MID are the same, A mistakenly thinks = that the response is a response to Request2 when really it was a = response to Req1. =20 It seems to me that that once a MID is used, it can't be re-used for = some significant amount of time.=20 From fluffy@cisco.com Tue Apr 17 21:58:17 2012 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 4348821F8458 for ; Tue, 17 Apr 2012 21:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.54 X-Spam-Level: X-Spam-Status: No, score=-107.54 tagged_above=-999 required=5 tests=[AWL=-1.941, BAYES_00=-2.599, GB_SUMOF=5, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2Jb2jTNnZmV for ; Tue, 17 Apr 2012 21:58:05 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1F95E21F8456 for ; Tue, 17 Apr 2012 21:58:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=22525; q=dns/txt; s=iport; t=1334725085; x=1335934685; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=Q41xW+O2+cArV5TQCIQy3/bXP9YbvZotGwb2Aa4LZgw=; b=Yt6aGCtTVF6uYXuvRPs1F8tOaLPUBhQBS5PIO2sI8C12fBHcNU9BQ5F8 1kX6HlCx9FidNIdT+H/tGzgefFzaDwaiCfqdOmVMYv3FMkDPhiDybFbOg BkQfw1CLFAymuQMJxFoQxesR+pg0laTuu+F4dX5Y0sJnybWzuncxUTFup A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMGAJBIjk+rRDoH/2dsb2JhbAA7CRMBAYMHriiBB4IiAQcgMQEKS3YKIgIHh2wMmEiBKJ95imEEglKCTmMEiFyNE4VyiF6BaYMGgTUBBgE X-IronPort-AV: E=Sophos;i="4.75,439,1330905600"; d="scan'208";a="37918510" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 18 Apr 2012 04:58:04 +0000 Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3I4v1Ef005964 for ; Wed, 18 Apr 2012 04:58:04 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Apr 2012 22:58:03 -0600 Message-Id: To: core WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] Comments on draft-ietf-core-coap-09 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 04:58:17 -0000 Multicast Optional or not=09 I can't figure out if imputation need to implement or use multicast. = Some of the discovery stuff implies it is needed.=20 Multicast address I think we should have IANA allocate a v4 and v6 default address to use = for multicast=20 IPSec I'm wondering what parts of text around IPSec really need to be in the = draft? I'm having a hard time finding anywhere where it has any = normative impact.=20 Section 1.2 Definition of reverse proxy I think this definition needs to be re written. It does not make sense Figure in section 2 (before 2.1). I think it would help if this showed = where DTLS fits in to the stack.=20 Proxy terminology. We have two very different types of proxies - one = only speaks COAP and the other type translates between CoAP and HTTP. I = would prefer a different terms for the translating type. Perhaps = "translator" or "translator proxy". I understand people don't want to = use gateway but it is what many people would call a gateway.=20 Why two ways of dealing with number of option codes - Having two ways = to deal with number of option (the OC Option Count and the end of = options maker) just leads to bugs. Is it really worth it to save 1 byte?=20= I find MUST fit in single datagram confusing. If you want to say MUST be = less than 65536 that would be clear but sort of not needed. Section 3 Packet size - I'm a bit skeptical of a default packet size of = less than 1280. That seems pretty big for when nothing else is known. = Lets say I have an HTTP to COAP proxy sitting on a 1G interface with = jumbo grams enables. And it is going to send a request to a CoAP node = sitting on 802.15 mesh network. Do you really think sending 9k packets = is OK? I think we should set the max packets size to something that has = a open of working on constrained networks.=20 section 3.1.1 generating 4.13 "if the payload was truncated" would be = better as "the payload would be truncated" Section 3.2 The text=20 A delta encoding is used between options, with the Option Number for each Option calculated as the sum of its Option Delta field and the Option Number of the preceding Option in the message, if any, or zero otherwise.=20 is very hard to follow. Could you rewrite this.=20 Having the a option delta of 15 mean different things based on if the = Option Count Field is 0 or not just seems it adds complexity and bugs = not worth the small compression gain.=20 Table 5.10 - I think it would be clearer and easier for implementation = with less bugs if No 5,6,8,9, and 15 were moved from type string to type = opaque. Is there any good reasons they need to be string?=20 =20 Section 4 - clarify that the stop and wait is per flow. Or is it per = destination? Given the later suggestion that every transaction could be = on a new port, there is a big difference between the two.=20 Section 4.3 - This section and a few other places uses the term "same = security context". I know what you mean but I think we need to get more = specific about exactly what this is.=20 The first paragraph of section 4.4.1 and 4.4.2 seem pretty redundant to = information provided earlier - I think you could remove them=20 Multicast and DTLS=20 As far as I can tell, the multicast stuff does not work with DTLS. So in = a deployment using DTLS, we need to cover how and when some messages = would not use DTLS and what the implications of this would be. If you = conceder some of the initial use cases for multicast (like discovery and = not having a group of lights "pop on like pop corn"), I think it is = possible to meet the uses cases with reasonable security risks but seems = like more is needed in the draft to address the interaction of DTLS and = multicast.=20 Section 4.5 - it says that the server SHOULD be aware that a request = came in over multicast bug give the later text, it seems that this needs = to be a MUST=20 Section 4.5 - estimation Leisure. I do not see how someone implementing = a COAP stack can figure out S, G, and R. I think we should define a = configurable parameter called LEISURE_TIME and set it to 5 seconds. To = be clear, I don't think the current algorithm is implementable.=20 Section 4.6 - Stop and wait and wait=20 Imagine A sends a CON Get request and gets and ACK but no response. How = long does it wait for a repines? I assume it can not send any new = requests to this destination during this time? I think we need to mandate the upper bound on the number of parallel = connections to a given destination. If we don't vendor A will do 4, then = vendor B will make a "better" product that is faster because it does 10. = And pretty soon we will have no congestion control. And this all needs = to be a MUST not SHOULD.=20 Imagine a broken client sends requests at a high rate to a server. = Should the server send large responses at the same high rate?=20 If a system is receiving multicast requests at a rate of 10 per second, = should it send the responses at a rate of 10 per second regardless of = congestion to that that destination? (Leisure delays these response but = does not change the average rate).=20 Have people implemented the congestion control and what does it look = like under failure.=20 Section 5.2.3=20 Sort of wondering if the SHOULD here should be a a MAY or MUST. Can you = explain when it would reasonable not to do this.=20 Section 5.3 2nd paragraph from end has "An end-point receiving a token". = I think receiving should be changed to something like "that did not = generate".=20 Last sentence in section 5.4.1 - I'm really not sure what this means. = MUST be ignored by recipient is always a bit vague - "treated as unknown = options" is likely better. I don't know what it means for option to have = no meaning.=20 Section=20 5.4.1 Human readable error messages. I have yet to see a human readable = error message in SIP or HTTP that provided any more useful information = than the error code. Sure, I can imagine there might be a case where = this is needed but often it is not. I think the SHOULD in 5.4.1 should = be changed to a MAY with some text saying only do this if it adds real = value.=20 The text says that when you get a confirmable critical message you = reject with RST. This seems wrong in multiple way. The CON / ACK etc = stuff is on lower layer. The option message have to do with the request = / response on upper layer. I think if you get an critical option you = don't understand, you have to seed an error response regardless of if it = is confirmable or not. The transfer of the message works so sending a = RST seems wrong here. The text also contradicts itself in says they MUST = be silently ignored then going on to say MAY send reset. This text also = needs to deal with what happens when the request was multicast - clearly = instantly sending a RST to a multicast message could cause a series = repines implosion failure.=20 Section 5.4.5 has=20 As these option numbers are even, they stand for elective options, and unless assigned a meaning, these MUST be silently ignored. I find the unless assigned a meaning really confusing. They have been = assigned a meaning and it is effectively "No Operation" - I think it = would be better to just phrase it more like that.=20 Caching The interaction of security and machining seems fairly vague. Can data = retrieved over a secret connection be cached. I certainly hope so even = if it is only cached by the client that did the get. On the other hand = it can not be arbitrarily hand to to others. I think a bit more detail = is needed in this space.=20 In section 5.6, is says the caching only depends on reply code not the = method. But this does not seem to actually be the case as we did deeper. = I doubt caching the response to a POST is something we want to do in = most cases.=20 Should the default Max-Age be zero for PUT, POST, and DELETE? Even for = GET, most things will have to set it to zero so it might be a better = overall to have default at zero. Thoughts?=20 The idea that all options have to match is a bit concerning. I'm not = sure I would want to change this but it does worry me that we can't have = options that don't invalidate the cache. Perhaps we want each new option = to define if it is include in cache check algorithm or not.=20 Proxying Need explanation of interaction with DTLS.=20 When I am using a proxy and sending it a COAP URL, I find it totally = lame that I have to send it in a totally different option than if I was = not using a proxy. I think we should change this unless there is some = really good reasons for doing it. Even when using a HTTP URI, I'd rather = just add a scheme than use proxy-URI.=20 In paragraph 3 of section 5.7 - should say how the proxy can "recognized = as identifying the proxy end-point," Last paragraph of section 5.7. I'm worried about slowly extending the = life time of the cache by each step not taking into account the network = latency. So if there is 2 condos of latency on the mesh network and = device A passed something with a Max-Life to 10 seances to Cache B that = later caches to cache B, it could end up living for multiple seconds = longer than it should have.=20 Section 5.8.2 what response code is returned if the PSOT both say = created a new resource and deleted an old one and perhaps changed a = third.=20 5.8.3 make lea that Content-Type option is not required Few places you have "but idempotent" that needs to change to "but is = idempotent" In 5.9.1.1. has text=20 A cache SHOULD mark any stored response for the created resource as not fresh. seems like this should be a MUST=20 The text=20 When a cache receives a 2.03 (Valid) response, it needs to update the stored response with the value of the Max-Age Option included in the response (see Section 5.6.2). should have a MUST in it=20 and in=20 However, a cache SHOULD mark any stored response for the changed resource as not fresh. SHOULD should be a MUST The=20 The representation format is specified by the media type given in the Content-Type Option. seems to be repeated all over the place. Can it be said just once? Caching 4.xx responses.=20 It looks to me like a proxy could cache the "un authorized" error = response. That seems wrong. A different client might be authorized. But = this gets back to lack of clarity of how security will work in the proxy = case.=20 Response codes 4.03 to 4.15. I don't think you can define these by = reference to the HTTP spec. The text there does not make sense for COAP. = I think you need to provide the normative definitions in this spec.=20 Caching something like 5.04 timeout sounds like a bad idea. What would = be the Max-Age of this repines? We have lots of responses that will = happen in overload conditions that probably should not be cached.=20 Section 5.10=20 Trivial detail but rather see this as two tables.=20 Imagine a proxy that does not understand Max-Age. The server sends a = response to proxy with Max-Age of 10 seconds. The proxy does not = understand this so it removes this. Now the client that made the request = to the proxy things the Max-Age in the response is 60 seconds. This = seems broken - am I missing something about how this works? section 5.10.2=20 Very confusing things could happen with URI-Host and NAT. Imagine that = one side is ing 10.0.1/24 space and other side of nat is using 10.0.2/24 = space. Lets say the NAT maps 10.0.1.100 to 10.0.2.200. If the client = includes a URI-Host option, the far sever will think this is for = 10.0.1.100 yet if the client does not include a URI-Host option, the far = side server will think this is for 10.0.2.200. So we could get in a case = where if the server reject things with 10.0.1.100 in the URI-Host. I = think we need some more care to outline how things are supposed to work = and how the code needs to be written to work in the presence of NATs. I = will note most of the V4 to V6 transition mechanism look a lot like NATs = with respect to this sort of problem so we can't just wish this problem = away.=20 Last para of 5.10.2. Suspect mean URi-Query can occur zero or more = times. current text says one not zero.=20 2nd para 5.10.3 - this should ref section 6.2 not RFC 3986 5.10.4 - make clear this is option even when threes is a payload caring = content=20 5.10.5 - make clear order of preference. Is it the first thing in list = that is the most preferred? 5.10.8 Imagine retiring two location paths that both have a differ query = arguments. How does that work?=20 Can the libation URI be included if the resource was just changed but = not created. If it was created do we need it to be a MUST not MAY on = return ?=20 5.10.9=20 Assuming that an empty ETag is a valid ETag, using this as a condition = for existence won't work.The ad-hoc nature of this seems just sort of = wrong. I'd rather see an If-Exists option for this functionality.=20 The 3rd from last paragraph starting with "It none of" seems like it = could be removed and just made otherwise to the condition if the = paragraph above. This will make it easier to keep track of the when 4.12 = happens.=20 The 2nd from last paragraph suggest all other error take precedence over = 4.12. This is very hard to implement in some cases. I would remove this. = Many systems will want to check and reject based on pre-conditions = before doing all the other things that might cause an error.=20 Section 6.1 Max URI Lengths. SIP could nervier agree on a max length for a URI. So = it die not define one. This turned out to be a mistake because when you = write code, you have to assume some limit and everyone assumed different = limits. COAP is meant for small M2M type apps. My belief is we should = set a limit to URI sizes in it - and that limit should be fairly small. = Something in the oder of say 100 bytes. These do not need to be human = readable URLs and 2^(100*8) is a petty big number.=20 Lets ban % encoding in for CoAP URI - I can't imagine any reason we real = need it and it is an endless source of bugs.=20 Allowing %2F in the path elements sounds like another resource of = endless bugs.=20 Where you have "is located at that IP address", given NATs, IP mobility, = LISP, and so on, I think that saying "can be reach at that IP address" = would be more appropriate.=20 What you want to say about if DNS is required or not. Obviously I think = the answer needs to be it is not required but whatever the case is needs = to be made clear.=20 The ABNF for IPv6 addresses is more complicated that some implementers = think. I would like to see a not cautioning them on and pointing it out = in particular.=20 Given the size limitations, we could define ~ to be an abbreviation for = /.wellknown/ and ~c to be an abbreviation for /.wellknown/core There is = going to be a lot of use of this over time.=20 For cases where DNS is used, need to discuss URI host resolution in DNS. = The thing I want here is that SRV is sued as that allows the port, as = well as IP, to be specified in the DNS. There are many parts of HTTP = that would be much easier if we could put the port in DNS. THe move = towards large shared hosting in cloud deployments and v4 address = "completion" make this even more important. Note I think DNS should = optional to implement, but if you do a DNS lookup, it should be a SRV = lookup.=20 Section 6.2. I think it is a super bad idea to not allow caching of = coaps data under any circumstances. Suggesting that proxies only work = with no security is more or less equivalent to saying you can't use them = for lots of deployments.=20 Section 6.4. I find the use /url/ really weird.=20 Section 7.1 - SHOULD is totally wimpy here. I think we need to pick MAY = moor MUST. I will be arguing for MUST.=20 Section 7.2 - I don't think you can mandate that a server MUST lien on = the default port. This means two servers behind a NAT can't really work=20= It says other endpoint can be hosted in the "in the dynamic port space". = I think should be changed to "at other ports". Is OK to use non dynamic = ports for many use cases.=20 I don't care but should there be a default port in the 6LowPan = compressed space so you know where to send discovery requests? I think the DLTS port is also a MUST be supported in same way as non = DTLS port. You need a secret way to do discovery.=20 Section 8 - I tried passing a COAP URL in a HTTP request line of = various libraries, firewalls, and other tools. In theory it might work, = but my observation is that in practice, it does not. I'm not sure how to = fix this. One possible solution is making a way to translate well know = http URL into a coap URL. So for example, the translator proxy that = received an HTTP request like=20 http://www.proxy.com/.wellknonw/core-translate/1.2.3.4_4567/foo/bar?a=3D3 would translate that to coap://1.2.3.4:4567/foo/bar?a=3D3=20 If we did something like this, your standard web libraries running on = things like google app engine could make REST calls to the proxy that = resulted in a request to the CoAP device. Perhaps you think this = approach is the reverse proxy approach but one way or another, I can see = how to get the current solution working very well in practice.=20 Section 8.1.1. in mapping to HTTP ETags, I think the spec needs to deal = with the difference of strong and weak ETags.=20 Section 8.2.4 Lets talk about al this 200, 204, 201 stuff. Do we have concrete uses = cases where we really need to separate all this. I'm trying to decide if = it is just a source o bugs or something useful. =20 The text in 2nd para looks wrong. If a POST just modifies an existing = resource, but that resource has an URI, seems like one could return a = 200.=20 Section 9 has=20 It is recommended that an application environment use consistent values for these parameters. I'm confused on what this means. Does this man one could not deploy = future extensions of this spec that dynamical adjusted the values if = some nodes the network did not do that? In saying that=20 The values for RESPONSE_TIMEOUT, RESPONSE_RANDOM_FACTOR, and MAX_RETRANSMIT may be configured to values specific to the application environment, I think we need to say more to have this be congestion safe. For = example, we could say device MUST NOT be allow values smaller than than = 2 seconds, 1.0 random factor, and 1 retransmit respectively.=20 Section 10.1.3=20 This section confuses me about what is in the Authority part of a capo = URI. Half of it seems to think it is a EUI64 and the other half thinks = it an IP address. How does the discovery process learn that mapping, = securely, on every device? Lets take a new stab at this section assuming = using DLTSL with certificates and dynamically assigned IP addresses.=20 =20 I think the RSA_PSK mode should be MAY not SHOULD=20 My favorite line in the security section is=20 "CoAP servers SHOULD NOT accept multicast requests that can not be authenticated. " Given we don't have any machoism to authenticate multicast requests, = this needs some work.=20 Section 11.2=20 In the IANA registry, I'd explicitly say the fenceposts were all = multiples of 14 instead of 14,28.42 .. I'd reserver a single EXP code point for experimental options I would = add the following text for this code point=20 The value EXP has been made available for the purposes of experimentation. This value is not meant for vendor specific use of any sort and it MUST NOT be used for operational deployments. Section 11.3 All the entries other that application/link-format are inappropriate = for this table. They make sense for rendering to humans in email and = HTTP, but in the context of M2M communications, they are basically = transfer encodings and do not define usable semantics of the data. Using = them will not lead to interoperability but exactly the oppose. We should = make it easy for people to register the actual formats they are using = and not just call everything text/plain. I've pointed this out in the = past - if someone has convincing arguments from the list, glad to read a = pointer to them.=20 Reserving 201 to 255 for private use does not make any sense. I have no = idea what private use is in this context.=20 The 0-200 range should be reserved for "IETF Review" not "Expert = Review". Putting an expert in the position where they had to say "no, I = don't think your future format will be used much so I won't give you a = short code" is not a decision we can reasonable ask an expert review to = do.=20 The example should use an media type that is registered.=20 Section 13.1 I think we need a series pass to move a bunch of this to informational.=20= Appendix B The Code=3D1 or Code=3D69 in figures seems redundant Appendix B 2nd' example - need to say more about where the IP address came from=20 example 4 and 5 seem like a great example of why we should not allow URI = like this.=20 Appendix D=20 Unclear what the status of this section of the spec is. Are devices = supposed to support this? It seems like we need to specify how identity is created from public key = for this to be interoperable. I think we should ref TLS draft for this.=20= I think a pass should be made though the document finding every SHOULD = and doing either changing it to a MAY or MUST or, if it is left a = SHOULD, clearly explaining in what sort of cases one would do and when = one would not and the implications of that. As it stands, it will be = very hard to decide if two devices will interoperate if you don't know = which one did which of the SHOULDs. There is a lot of duplicated normative text. I understand that a bit = happens but take for example the point that=20 The response SHOULD include a human-readable error message. This gets said about five times.=20 From fluffy@cisco.com Tue Apr 17 21:58:23 2012 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 979B921F85AA for ; Tue, 17 Apr 2012 21:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.762 X-Spam-Level: X-Spam-Status: No, score=-109.762 tagged_above=-999 required=5 tests=[AWL=0.837, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMudtAO+eVJD for ; Tue, 17 Apr 2012 21:58:19 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 68FE521F85A2 for ; Tue, 17 Apr 2012 21:58:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2223; q=dns/txt; s=iport; t=1334725099; x=1335934699; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=AimXDEoueeofXTKqlZHOP7XHYA6sGI74CR2f04MDtBU=; b=Dx+meZQL0yFAKOWOxLK8K/KCxp4vu4UcTqQvV7UCSzILD4+PsUYAJ9is 65ghk25cdpI0qRmTMqYYG2EYl/QDH7mdXLmwuM1zXWey1JguRicfThl6m ql789A7nXK/GFkDRmaFXBcAtIQ6bSERGCPYmCArVejyuEU4OMSz09RTAG Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4GAJBIjk+rRDoH/2dsb2JhbABEgxyuKIEHgiIBJ39+NYdsmFSBKJ95imWFIGMEiFyNE4VyiF6BaYMGgTY X-IronPort-AV: E=Sophos;i="4.75,439,1330905600"; d="scan'208";a="41032135" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 18 Apr 2012 04:58:19 +0000 Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3I4v1Eg005964 for ; Wed, 18 Apr 2012 04:58:19 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Apr 2012 22:58:18 -0600 Message-Id: <1DC55BCC-78E1-42A0-BC36-1AB842E34034@cisco.com> To: core WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] WGLC comments on draft-ietf-core-observe-05 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 04:58:23 -0000 Imagine a server that always sends non confirmable requests. Does it = send forever? Even after client crashes and a new device that is not = CoAP aware gets the same IP address?=20 The condition in paragraph 2 of section 3.4 confuses me. Can you just = explain what is going on and what the requirement for "not fresh" is.=20 Section 3.5. I don't think you can remove a client from observer list = based purely on source IP, you need to use source IP and source port. = Without this two different clients behind a NAT would remove each other = when talking to a server outside the NAT. Similar problems with moor = than one coap client on the same host. Same issue in section 4.1 when = adding a lint to lis of observers.=20 Section 4.3 Using Max-Age to indicate when server will send next = notification is just wrong. That's not what max-age means. We need = separate control of how long data is fresh, and how often the client = needs to refresh the subscription. There should be some limit, probably = less than 24 hours, on max lifetime of subscription without a refresh.=20= Last paragraph of section 4.2 says MAY remove but I think this needs to = be a MUST remove. End of section 4.3. Could give a nice example here of an switch that = return two different XML bodies that indicate if it is on or off but map = to a ETAG or 0 and 1 and how that helps reduce bandwidth usage.=20 Section 4.4 - I'm confused about the algorithm here. Does this mandate = that the resource can ever changes more than once per second ? For many = applications I want way faster updates than this. I don't think this = works.=20 Section 4.5, the stuff about stoping the old transmission and caring the = retransmit count over to new transaction is hard to implement in some = cases and often a minor optimization for an edge case. I think this = house be MAY not MUST=20 Section 8 - Nosec mode. Thought I agree with this, this is not clear how = I could implement this. I think we need more detailed advice on what an = implementer needs to do.=20 Instead of _foo_ style, for words that you want to have a specific = defined meaning in the doc, start them with a capital.=20 From fluffy@cisco.com Tue Apr 17 21:58:43 2012 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 CE58421F85A4 for ; Tue, 17 Apr 2012 21:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.867 X-Spam-Level: X-Spam-Status: No, score=-109.867 tagged_above=-999 required=5 tests=[AWL=0.732, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frCitCIa1FYh for ; Tue, 17 Apr 2012 21:58:39 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 8594421F85AA for ; Tue, 17 Apr 2012 21:58:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=3575; q=dns/txt; s=iport; t=1334725119; x=1335934719; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=lSHsHag1oAVvWL+g5cn9ioUxhaNC7P2x4NHlsVFU7TM=; b=VjpRjw/rgDa1W4dQGCfafDkKGsAzkoaDmRxzTPnAFpn7rzbeV5W/rKIZ clFa+Ng7tyObMUQSEsIfdkos9UlzFZ3nTe3YGXGnLzUrU7fZiSVXP7wsL TgARADZBawL/MbG4Bqh02gLhnZ6EyY5cgqmH2SdSUxF6sjtKLX2xHoSzs g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4GALpJjk+rRDoH/2dsb2JhbABEgxyuKYEHgiIBJ4F9CiuHbJhTgSifeZAFYwSIXI0ThXKIXoFpgwY X-IronPort-AV: E=Sophos;i="4.75,439,1330905600"; d="scan'208";a="40940678" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 18 Apr 2012 04:58:39 +0000 Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3I4v1Eh005964 for ; Wed, 18 Apr 2012 04:58:38 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Apr 2012 22:58:38 -0600 Message-Id: <22C5F36C-2649-4660-9A3B-FE7A4F516CC1@cisco.com> To: core WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] WGLC comments on draft-ietf-core-block-08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 04:58:43 -0000 This draft is fairly hard to understand. I suspect that is because the = level complexity in it has evolved over time and I think the terminology = could be re factored to make it clearer.=20 I think we have three different semantic messages. One is a asking for a = given block - Let me call this GetBlock. One is transferring a specific = block, let me call this TransferBlock, and one is acknowledge receipt of = a given block, let me call that AckBlock. Further more, we have these = block transfer protocol going in the direction of the CoAP request, and = the transfer going in the direction of the CoAP Response.=20 I propose we reroute this draft to have 6 instead of 2 options and the = options are called=20 The first three are ReqGetBlock, ReqTransferBlock, ReqAckBlock, and = second three are RespGetBlock, RespTransferBlock, RespAckBlock. Now the = blocks of three might share the same option code in which case the code = is the same as it is today or they might just allocate different option = codes in which case the code is probably simpler. But the key thing here = even if they have just two option codes, is they will make it much = easier to rewrite the spec in a way that is easy to understand. The = draft can talk about when you get a TransferBlock, you send an AckBlock = for without having to try and figure out all the cases that happen for = different method codes. I think we should also define BlockServer being = the thing sending the TransferBlock and BlockClient being the thing = receiving.=20 It makes things clear like the size in a GetBlock is just a request the = other size and the server will set the size it wants in the = TransferBlock.=20 On the size negotiation, I think the GetBlock should have a size which = is the request size. The server is allowed to choose a size smaller than = this but not one larger.=20 I think we need to get more presses about the atomic nature block = transfer semantics. Specifically the requirements around if someone = client A is doing a put on resource while client B is going a get, but = with block transfers. I'm Ok with the idea that a server might know how = to incrementally update a resource in an atopic way but I'm not seeing = how a client would understand some bizarrely fragmented result of a get. = A lot more detail is needed on this.=20 Some people will want to use this for streaming of infinitely long = resources. It seems like the basic machismo will support that with no = changes but probably needs some details explaining how to do that. = Particularly when mapping to HTTP.=20 It's unclear to me how a client discovers the server support blocks. = Does it just put a GetBlock request on every GET it does? Similarly, how = the server know if the client supports it. I assume the idea is since it = is critical, you try and if you get an error on that destination, then = you retry without it. That seems a bit painful. One advantage of = different option codes for the GetBlock from TransferBlock is that = GetBlock could be elective and TransferBlock Critical resulting in much = easier negotiation of support. I'll note that ETAGS are usually = relatively big.=20 I'm not seeing need use the same size block for all the transfers for a = given request as long as the combination of num and sz accurately = indicate where the block fits in the overall resource. This becomes = particularly relevant in not delaying streams.=20 I wonder if the size option should be moved into it's own spec.=20 From angelo.castellani@gmail.com Wed Apr 18 00:11:58 2012 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 3012721F8607 for ; Wed, 18 Apr 2012 00:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.717 X-Spam-Level: X-Spam-Status: No, score=-2.717 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B+amL-Xtruha for ; Wed, 18 Apr 2012 00:11:54 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id C88C521F8606 for ; Wed, 18 Apr 2012 00:11:53 -0700 (PDT) Received: by werb10 with SMTP id b10so5510218wer.31 for ; Wed, 18 Apr 2012 00:11:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=FbUl2UhiKumrzEzBxILjjYCPysp/J6Ms655lZfuzd4Y=; b=k/FZURrUsWC83VRoF0TfEQ39cZlHyhyt2uw+iFwA0EUC5+7ZfU/JIHHcstb6PRTnFG zBmlNTppo5cKzmyKOdz9KWNoZ+gBlbKX3Vr4xcAnTSdQ1jgeiP28mhXMYqpiF3M9Nghz HSGqfSHo2j+A1Re3G6UDs0vnMez6V3sk6vG0nb3LpdwGQ6KaSDUxgGAT+h6rZ2UTMMb+ bhCj/O4txXJTGDKVQPwLCzoLCqvrVV2vYLzMmJvT1SzVret8rmzKsLTApnaOHpt9tzgs gPcIch+Q8Os3eOCEJ+yYXa4JPpLJ2Rb0FgZ0pmQtzwEm5rq/PINhHax2+xIEe+gvQljK ddmQ== Received: by 10.180.89.9 with SMTP id bk9mr3428456wib.11.1334733112644; Wed, 18 Apr 2012 00:11:52 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.214.20 with HTTP; Wed, 18 Apr 2012 00:11:36 -0700 (PDT) In-Reply-To: <9E5F67AC-943D-4A97-B19D-313B7194D9AF@cisco.com> References: <9E5F67AC-943D-4A97-B19D-313B7194D9AF@cisco.com> From: "Angelo P. Castellani" Date: Wed, 18 Apr 2012 09:11:36 +0200 X-Google-Sender-Auth: leOPcnLZKENY35pBbpIe9_YY4DI Message-ID: To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Cc: core WG Subject: Re: [core] WGLC draft-ietf-core-coap-09 Reuse of MID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 07:11:58 -0000 On Wed, Apr 18, 2012 at 06:57, Cullen Jennings wrote: > It seems to me that that once a MID is used, it can't be re-used for some significant amount of time. Yes, this is true in transmission and in reception, and it cannot be re-used during the whole retransmission window (better said the *potential* retransmission window). See also the discussion related to this http://www.ietf.org/mail-archive/web/core/current/msg02875.html Best, Angelo From angelo.castellani@gmail.com Wed Apr 18 00:17:07 2012 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 BA84D21F849B for ; Wed, 18 Apr 2012 00:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.76 X-Spam-Level: X-Spam-Status: No, score=-2.76 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVtk1JtbaMBe for ; Wed, 18 Apr 2012 00:17:07 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0989121F847A for ; Wed, 18 Apr 2012 00:17:06 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so4857980wgb.13 for ; Wed, 18 Apr 2012 00:17:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=eifXz8MeAhLgqjWo0+/K7Za9Im8qv/H0q+ETR1lsTTg=; b=u2NJTWQVJ5qnNKRjBJ38GQPolzYKJ1/xlvixrC5bCcAF2M6qE0JlexQVaD/qCKbaO8 SiQmvHLegoHD3rDDPFcvZK23LNoOHMtXbvJbLMCtUN6ZS1/KZMwwtQOiL4CmceVqpjnu WNeHoJEh0dzXaUXHoexNdwS3j8qJvIvEUa0pVRDTPO0IpAF/yxHdxqWKexLiFeDIR28l cg1BKvwVolyPWWdKof5Q/l0TFarNNHBhhDUopgEoRmPbGxJ3SjBEKIAPY43duu3XmsAS ++J7YnVs61SF4xbU6gEWK034hzJ6za9LuPjSLk+7DTL/JTFZ37QhpjV6e1rrbWMHUaid GFnA== Received: by 10.180.73.143 with SMTP id l15mr3465912wiv.11.1334733426263; Wed, 18 Apr 2012 00:17:06 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.214.20 with HTTP; Wed, 18 Apr 2012 00:16:51 -0700 (PDT) In-Reply-To: References: From: "Angelo P. Castellani" Date: Wed, 18 Apr 2012 09:16:51 +0200 X-Google-Sender-Auth: wdbKspWnHm_1DDl5QFH8aIQZK7Y Message-ID: To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Cc: core Subject: Re: [core] draft-ietf-core-coap-09: retransmission window X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 07:17:07 -0000 On Wed, Mar 28, 2012 at 12:36, Carsten Bormann wrote: >> Question 2: Should be specified that "the recipient MUST be prepared to receive the same confirmable message *within the potential retransmission window*" as well? > > Now ticket #201. What about NON messages? How much time the recipient MUST be prepared to receive the same non-confirmable message? (to eliminate duplication caused by the network) From cabo@tzi.org Wed Apr 18 00:20:47 2012 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 D677F21F84B5 for ; Wed, 18 Apr 2012 00:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.428 X-Spam-Level: X-Spam-Status: No, score=-106.428 tagged_above=-999 required=5 tests=[AWL=-0.179, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBTRzvBUzAOe for ; Wed, 18 Apr 2012 00:20:47 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id D7E1821F854A for ; Wed, 18 Apr 2012 00:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3I7KZWC001484; Wed, 18 Apr 2012 09:20:35 +0200 (CEST) Received: from [192.168.217.105] (p54899B15.dip.t-dialin.net [84.137.155.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 27DC0ED; Wed, 18 Apr 2012 09:20:35 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <9E5F67AC-943D-4A97-B19D-313B7194D9AF@cisco.com> Date: Wed, 18 Apr 2012 09:20:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9E5F67AC-943D-4A97-B19D-313B7194D9AF@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1257) Cc: core WG Subject: Re: [core] WGLC draft-ietf-core-coap-09 Reuse of MID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 07:20:48 -0000 On Apr 18, 2012, at 06:57, Cullen Jennings wrote: >=20 >=20 > I don't understand when a MID can be reused. A MID is to be used again for retransmitting the same message. After completing (re-)transmitting a message, the MID should not be used = for a while. In my implementation, I don't *re*use a MID (i.e., for a different = message) 256 seconds after having used it. > I'm primarily concerned about use of default MID.=20 I don't think anyone implements a default MID. Do you mean a default = token? We had a discussion around the Paris plug test about the way MID and = Token together make sure that there is no confusion. Angelo Castellani has written up some of that in = draft-castellani-lwig-coap-separate-responses-00.txt -- the title is a = bit misleading, this draft collects a number of examples for packet = exchanges. I hope we can develop this into an informational RFC that = explains the finer points of why this works. Note that the complexity of *implementation* is quite limited here; the = discussion in the draft is extensive as it shows a large number of = cases. See also ticket #201. > Say I am on a network with 5 seconds latency but no packets are lost.=20= >=20 > A sends Req1 to B. Due to latency, A retransmits Req1 to B. Both use, say, MID 47, and, for minimal packet size, Token 0 (default = token), > B sends response 1 to A which A receives. If this is piggybacked in an ACK, it will have MID 47, too. > No A decided to immediately send Req2 to B. This would *have* to have a new MID, say, 48. > In the meantime, B had received the retransmission of Req1 and resent = the response. The response arrives at A after A has send the second = request but because the MID are the same, Even if the second request carries the same token 0 (which is allowed as = the token of the first request has been "put back" by the first = response), it still has to have a different MID if it is so close. > A mistakenly thinks that the response is a response to Request2 when = really it was a response to Req1. =20 The important observation here is that the protection against duplicate = packets (which are quite likely to occur because of retransmission and = lost/delayed ACKs) comes from the MID. > It seems to me that that once a MID is used, it can't be re-used for = some significant amount of time.=20 I don't know if 256 s is "significant", but yes, the "2 MSL" argument = applies here. There is no such need for timeout-based blocking for the reuse of token = values. Gr=FC=DFe, Carsten From angelo.castellani@gmail.com Wed Apr 18 00:22:00 2012 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 2EE4621F8568 for ; Wed, 18 Apr 2012 00:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.791 X-Spam-Level: X-Spam-Status: No, score=-2.791 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CmBB-BiNWrmS for ; Wed, 18 Apr 2012 00:21:59 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 780D621F856C for ; Wed, 18 Apr 2012 00:21:59 -0700 (PDT) Received: by werb10 with SMTP id b10so5516703wer.31 for ; Wed, 18 Apr 2012 00:21:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=2EL4H4woVdErXedxYceKet8qRky7T495dvaThyWjieQ=; b=VA+CGQodYUyaQspxSFu7RsAJz89REGJIp3Ap9yviOv3VpM2yF86blGEpuCpTiSH1N3 TBNh6WKgDKnFsPBzmWPlB9j7ybcehZ9l39b+oM2F4hokcfChbVwBkM+omj2PIYkGFGYC wZor6fvHmlLkk5Ny65xQn9q+30ex4zoiNW4IBVL+iPEvlnPFB1WtZKn0wosKDXCP4qVk qviJGM5NzynGuOgrbVacqyZZh227b8abjNQZuoZnYt6UhKTvNGt6m3KnL8Ize3udhRTV GWt95ZWfBQzC5J55mYvA2SLfDpsoW1HUySF4IKELmnmRRcNiTi+f/57EHu2pOLVWjuzy bXmw== Received: by 10.216.131.30 with SMTP id l30mr711166wei.111.1334733718692; Wed, 18 Apr 2012 00:21:58 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.214.20 with HTTP; Wed, 18 Apr 2012 00:21:43 -0700 (PDT) From: "Angelo P. Castellani" Date: Wed, 18 Apr 2012 09:21:43 +0200 X-Google-Sender-Auth: idin8qndlULAqIZsTvuqYJLEi10 Message-ID: To: core Content-Type: text/plain; charset=UTF-8 Subject: [core] WGLC comment for draft-ietf-core-coap-09: Resetting NONs X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 07:22:00 -0000 Dear WG, since Section 4.4.4 specifies that NON messages can be resetted. However the specification gives no hint about how much time the transmitter endpoint MUST be prepared to receive a RST message from the recipient. Should we specify a default value for this timeout? Best, Angelo From cabo@tzi.org Wed Apr 18 00:38:42 2012 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 675B821F8630 for ; Wed, 18 Apr 2012 00:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.423 X-Spam-Level: X-Spam-Status: No, score=-106.423 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmOu-zPk7JW0 for ; Wed, 18 Apr 2012 00:38:42 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 2723F21F8639 for ; Wed, 18 Apr 2012 00:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3I7cVd3009383; Wed, 18 Apr 2012 09:38:31 +0200 (CEST) Received: from [192.168.217.105] (p54899B15.dip.t-dialin.net [84.137.155.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3865F111; Wed, 18 Apr 2012 09:38:31 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Wed, 18 Apr 2012 09:38:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Angelo P. Castellani" X-Mailer: Apple Mail (2.1257) Cc: core Subject: Re: [core] draft-ietf-core-coap-09: retransmission window X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 07:38:42 -0000 On Apr 18, 2012, at 09:16, Angelo P. Castellani wrote: > On Wed, Mar 28, 2012 at 12:36, Carsten Bormann wrote: >>> Question 2: Should be specified that "the recipient MUST be prepared = to receive the same confirmable message *within the potential = retransmission window*" as well? >>=20 >> Now ticket #201. >=20 > What about NON messages? How much time the recipient MUST be prepared > to receive the same non-confirmable message? (to eliminate duplication > caused by the network) Indeed, duplicate detection is not only for confirmable messages. So #201 needs to talk about CON and NON. =20 The main point of #201 is that we clarify the text to use the term = "retransmission window" as much as possible. For NON, there is no retransmission, so the window could be smaller than = for confirmable messages. However, for most implementations, it will be easier to simply have a = single timeout value for both cases. This just needs to be large enough, and "retransmission window" will do = it for NON, too. I added this discussion to #201. Gr=FC=DFe, Carsten From trac+core@trac.tools.ietf.org Wed Apr 18 00:38:58 2012 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 A80A421F862B for ; Wed, 18 Apr 2012 00:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4FLFmpoHL6w for ; Wed, 18 Apr 2012 00:38:54 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 72FCC21F84EF for ; Wed, 18 Apr 2012 00:38:54 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SKPTH-00057s-LN; Wed, 18 Apr 2012 03:38:35 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Wed, 18 Apr 2012 07:38:34 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/201#comment:1 Message-ID: <066.ba5739ed2de094bed159094acd6107d3@trac.tools.ietf.org> References: <051.b90ea2a4caf57d34ab6abdaf3603301a@trac.tools.ietf.org> X-Trac-Ticket-ID: 201 In-Reply-To: <051.b90ea2a4caf57d34ab6abdaf3603301a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120418073854.72FCC21F84EF@ietfa.amsl.com> Resent-Date: Wed, 18 Apr 2012 00:38:54 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #201: Clarify use of retransmission window for duplicate detection X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.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: Wed, 18 Apr 2012 07:38:58 -0000 #201: Clarify use of retransmission window for duplicate detection Comment (by cabo@…): Angelo Castellani notes: What about NON messages? How much time the recipient MUST be prepared to receive the same non-confirmable message? (to eliminate duplication caused by the network) Indeed, duplicate detection is not only for confirmable messages. So #201 needs to talk about CON and NON. The main point of #201 is that we clarify the text to use the term "retransmission window" as much as possible. For NON, there is no retransmission, so the window could be smaller than for confirmable messages. However, for most implementations, it will be easier to simply have a single timeout value for both cases. This just needs to be large enough, and "retransmission window" will do it for NON, too. -- -----------------------------+------------------------------------- Reporter: cabo@… | Owner: draft-ietf-core-coap@… Type: editorial | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: In WG Last Call | Resolution: Keywords: | -----------------------------+------------------------------------- Ticket URL: core From cabo@tzi.org Wed Apr 18 00:42:49 2012 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 9C3F321F85F2 for ; Wed, 18 Apr 2012 00:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.418 X-Spam-Level: X-Spam-Status: No, score=-106.418 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1QgE-JKLg-N for ; Wed, 18 Apr 2012 00:42:49 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id E5B1621F85EF for ; Wed, 18 Apr 2012 00:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3I7gcAL011973; Wed, 18 Apr 2012 09:42:38 +0200 (CEST) Received: from [192.168.217.105] (p54899B15.dip.t-dialin.net [84.137.155.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9C30E11C; Wed, 18 Apr 2012 09:42:38 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Wed, 18 Apr 2012 09:42:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <626A389E-CC7E-4EB5-9B55-7B18723A1BCF@tzi.org> References: To: "Angelo P. Castellani" X-Mailer: Apple Mail (2.1257) Cc: core Subject: Re: [core] WGLC comment for draft-ietf-core-coap-09: Resetting NONs X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 07:42:49 -0000 On Apr 18, 2012, at 09:21, Angelo P. Castellani wrote: > Dear WG, >=20 > since Section 4.4.4 specifies that NON messages can be resetted. (i.e., replied to with a RST.) > However the specification gives no hint about how much time the > transmitter endpoint MUST be prepared to receive a RST message from > the recipient. >=20 > Should we specify a default value for this timeout? Why would we need to specify anything here? If the endpoint cares, it will have the state. If it doesn't, the RST is just discarded. (Note that we don't require endpoint to actually act on RSTs for NONs, = this is strictly optional.) (As a quality of implementation point, yes, this is another point were a = time constant on the order of "2 MSL" ~ retransmission window is = useful.) Gr=FC=DFe, Carsten From angelo.castellani@gmail.com Wed Apr 18 00:50:00 2012 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 7183121F85E7 for ; Wed, 18 Apr 2012 00:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.815 X-Spam-Level: X-Spam-Status: No, score=-2.815 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfIROL+CM-tw for ; Wed, 18 Apr 2012 00:50:00 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id A4E0821F85FC for ; Wed, 18 Apr 2012 00:49:59 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so4875098wgb.13 for ; Wed, 18 Apr 2012 00:49:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=qoL6IIDH6KXSRbrqu/OJkT59Rk7jDEXmOYvgolNgcEM=; b=pNDfhkSsd4+rfi/E4LIpOe342GbO3DZml3BvI/dyDc6/dcxKdI+OCHzRbMqfoLbGLs IHb8ViNqan0rCNxJ4CcKQofljnk0jZ+0KN4te7IqQeO0NEhEVUESg13XeoJWFZeY9cyC pp6ho+sl5kM8rhqdB1ydZCxnSPQz9oF7gibRTugrJxagAkQa1o6c1zXqUyhcZk8roJIm +LCuXPcEQaRmZqBz/4rS2ErouDseJcUgV5tB0Yj4bGx56TjjB5Migr5hoLzib/YXpPUy kEdBubaDmvLoffiaV886i5kbZ1BpuRqLjQ6ZZiumeFtIPAn7NXr06R0/AoBzxqdvAB52 wpmw== Received: by 10.180.83.198 with SMTP id s6mr3723037wiy.8.1334735398858; Wed, 18 Apr 2012 00:49:58 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.214.20 with HTTP; Wed, 18 Apr 2012 00:49:43 -0700 (PDT) In-Reply-To: References: From: "Angelo P. Castellani" Date: Wed, 18 Apr 2012 09:49:43 +0200 X-Google-Sender-Auth: 1Yf71egcvkIfLKcq24KhHj5tfFE Message-ID: To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: core Subject: Re: [core] draft-ietf-core-coap-09: retransmission window X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 07:50:00 -0000 Can we define how much smaller can be the timeout for NONs? On class-I devices, I will have only a very limited set of slots for deduplication, depending upon available resources, and at some point I cannot receive any more messages since the deduplication slots have exhausted... So having a smaller timeout is a real benefit for me. When deduplication cannot be assured anymore, since the deduplication slots in my buffer are all busy, new messages should be ignored? I think that this is probably the best solution. Moreover if the message is a CON I will have another opportunity to receive it on retransmission. I will prefer avoiding sending a RST in this situation. But let's imagine that I have some observation in place, and the servers are sending to me NON notifications at an aggregate rate higher than the maximum one that I can receive. Suppose that my bottleneck is the deduplication buffer, which has N slots. The maximum rate R at which I can receive messages, if the timeout is T will be: R =3D N / T Probably in this case sending some RST will be benificial. Best, Angelo On Wed, Apr 18, 2012 at 09:38, Carsten Bormann wrote: > On Apr 18, 2012, at 09:16, Angelo P. Castellani wrote: > >> On Wed, Mar 28, 2012 at 12:36, Carsten Bormann wrote: >>>> Question 2: Should be specified that "the recipient MUST be prepared t= o receive the same confirmable message *within the potential retransmission= window*" as well? >>> >>> Now ticket #201. >> >> What about NON messages? How much time the recipient MUST be prepared >> to receive the same non-confirmable message? (to eliminate duplication >> caused by the network) > > Indeed, duplicate detection is not only for confirmable messages. > > So #201 needs to talk about CON and NON. > The main point of #201 is that we clarify the text to use the term "retra= nsmission window" as much as possible. > > For NON, there is no retransmission, so the window could be smaller than = for confirmable messages. > However, for most implementations, it will be easier to simply have a sin= gle timeout value for both cases. > This just needs to be large enough, and "retransmission window" will do i= t for NON, too. > > I added this discussion to #201. > > Gr=C3=BC=C3=9Fe, Carsten > From esko.dijk@philips.com Wed Apr 18 00:52:43 2012 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 56F8B21F8606 for ; Wed, 18 Apr 2012 00:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.119 X-Spam-Level: X-Spam-Status: No, score=-4.119 tagged_above=-999 required=5 tests=[AWL=-0.520, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYKZmWZvR0Jb for ; Wed, 18 Apr 2012 00:52:39 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id 43FA321F8670 for ; Wed, 18 Apr 2012 00:52:17 -0700 (PDT) Received: from mail112-db3-R.bigfish.com (10.3.81.251) by DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id 14.1.225.23; Wed, 18 Apr 2012 07:52:16 +0000 Received: from mail112-db3 (localhost [127.0.0.1]) by mail112-db3-R.bigfish.com (Postfix) with ESMTP id 0FA91202A4; Wed, 18 Apr 2012 07:52:16 +0000 (UTC) X-SpamScore: -44 X-BigFish: VPS-44(zz217bL15d6O9251Jc89bh542M1432Nzz1202hzz1033IL8275dhz2dh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI Received: from mail112-db3 (localhost.localdomain [127.0.0.1]) by mail112-db3 (MessageSwitch) id 1334735534814236_23231; Wed, 18 Apr 2012 07:52:14 +0000 (UTC) Received: from DB3EHSMHS004.bigfish.com (unknown [10.3.81.228]) by mail112-db3.bigfish.com (Postfix) with ESMTP id B8CFB1C0073; Wed, 18 Apr 2012 07:52:14 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by DB3EHSMHS004.bigfish.com (10.3.87.104) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 18 Apr 2012 07:52:13 +0000 Received: from 011-DB3MPN1-013.MGDPHG.emi.philips.com ([169.254.3.240]) by 011-DB3MMR1-007.MGDPHG.emi.philips.com ([10.128.28.57]) with mapi id 14.01.0355.003; Wed, 18 Apr 2012 08:54:18 +0100 From: "Dijk, Esko" To: "Kovatsch Matthias" , Carsten Bormann Thread-Topic: [core] draft-ietf-core-block-08 - Block ordering Thread-Index: AQHNF6OaclcEg8PWJkmCm3+pauZY4JaVRZWAgACb6wCAADR1gIAA1X0QgAACZgCAAD7rcIAF5z+AgAAE9QCAAH4bgIAACDCAgAAS9QCAAmd/oA== Date: Wed, 18 Apr 2012 07:54:18 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED61809397A@011-DB3MPN1-013.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED618092AF8@011-DB3MPN1-013.MGDPHG.emi.philips.com> <0EDC43A0-E85B-4E7C-A442-798576178C5A@tzi.org> <031DD135F9160444ABBE3B0C36CED618092CD3@011-DB3MPN1-013.MGDPHG.emi.philips.com> <46A1DF3F04371240B504290A071B4DB628F74879@szxeml509-mbs> <55877B3AFB359744BA0F2140E36F52B51398C683@MBX10.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B51398C81A@MBX10.d.ethz.ch> In-Reply-To: <55877B3AFB359744BA0F2140E36F52B51398C81A@MBX10.d.ethz.ch> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.101] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "core@ietf.org" Subject: Re: [core] draft-ietf-core-block-08 - Block ordering X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 07:52:43 -0000 The assumption of sequential block ordering seems to be present in various = places in the draft. This gives some confusion whether random access and no= n-sequential transfers are truly supported, and if so, to what degree exact= ly. What could help to clarify is 1) A definitions section defining relevant terms (first block, last block,= final block, sequence, sequence of blocks, sequence of requests/transfers,= transfer sequence, ...) 2) A section on the topic of ordering. Some examples where the draft could be more clear on ordering/non-sequentia= l transfer cases: * the general term "sequence" seems used both for (1) the sequence of blocks describing the resource body; and (2) the sequence of blocks in a blockwise transfer. For (1), block 0 is the first block of the sequence and block 'Nmax' is the= last block which has a size between 1-BlockSize. The last block is the one= with the M bit unset according to the definition on page 9. For (2), with non-sequential ordering or random access, the first block in = the sequence could be any block 0...Nmax and the last block could also be a= ny block 0...Nmax. The M bit is *set* on the last block if it's not block N= max. (Would an end-point expect more blocks then since the More bit is 1?) * in other words: there's a concept of "last block" or "final block" which = refers to [page 9 definition] (1) the last block of the body; but seems *also* (2) whether there are one or more blocks available (does this mean in th= e sequence of blocks being transferred?) * " The block size given (SZX) suggests a block size (in the case of block number 0) or repeats the block size of previous blocks received (in the case of block numbers other than 0)." Does this constrain a block transfer sequence/order to always start with bl= ock 0? If not intended that way: Block number 0 here should probably be "th= e first requested block in a transfer sequence"; "Block numbers other than = 0" should be "subsequent blocks in a transfer sequence". * "Note that any reduction in the block size may mean that the second reque= st starts with a block number larger than one," There seems an assumption here that block transfer is linear. * "In a blockwise transfer of a request payload (e.g., a PUT or POST) that is intended to be implemented in an atomic fashion at the server, the actual creation/replacement takes place at the time the final block, i.e. a block with the M bit unset in the Block1 Option, is received." This constrains the last block in a sequence to be the last block of the bo= dy? * "last block" and "final block" -> maybe harmonize terms -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Kov= atsch Matthias Sent: Monday 16 April 2012 19:48 To: Carsten Bormann Cc: core@ietf.org Subject: Re: [core] draft-ietf-core-block-08 - Block ordering > The MUST implement is clearly sequential, and I don't think anyone propos= es > to change that. Good, but is this actually said anywhere in the draft? I re-read block-08 and could only find implicit statements such as "sequenc= e of blocks" (nothing about the order) and the examples. > I don't see a difference between stateless Block2 and stateless Block1. > (Clearly, the latter has different use cases.) You cannot *not* implement > random access when you run stateless. I thought that with some restrictions for the client, we could minimize the= probability to break resources or make it easier for the server to check i= f the received representation can be valid. But in the end this does not ma= tter, as the client always has to play along to not break the resources. > Oh, and you can't really specify "MUST always go up to the last block" ev= en > for atomic Block1, because the client might lose power in the middle. Yo= u still > have to say what happens when it gets power again a minute later and > maybe tries the same sequence of transfers again, before the state/contex= t > has timed out at the server. That's what I meant by saying "overwrite > state/context at the server". Yes, that was a problematic textual shortcut I took. > > Gr=FC=DFe, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From angelo.castellani@gmail.com Wed Apr 18 00:54:42 2012 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 AE4AA21F8427 for ; Wed, 18 Apr 2012 00:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.833 X-Spam-Level: X-Spam-Status: No, score=-2.833 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyEnSUW33iAE for ; Wed, 18 Apr 2012 00:54:42 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id E884921F8473 for ; Wed, 18 Apr 2012 00:54:41 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so4877450wgb.13 for ; Wed, 18 Apr 2012 00:54:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=umUdlFhAN3MnuQFPDkiUUPZvie44jMQXHUagDRdtFw8=; b=VIUuCFaGP5GoZmqQO2ADdcsFjyCg2zqhlcL2sFTRvJV/4H22QZYqs8e0w49pQst/nn rUtg6tYyPPylKvMGJemIWZuzBEPHyEX0dUuFvTzIrEquQQoPeqAVLZhR4zsBBlt9iURE 4BCgCY1SJ1Vk3w42RVpTk6jYFiQzbpqq/72/UAEA0Kdq74oUtcZNRbTA3HOzqiPiB7my DHZ1iGXrEX4HGEDtDc6EZzl45v7RCEacKl5UZSRzrnN4yVRPxDASvT4xK8YM+RhPLVw1 qnr8ztz5hthy9txqJZIpeHS63BN4NPNnP1MzVm8D5ii2hOdUMcMLaA8ZqoJ1MI7nn18K HwbQ== Received: by 10.180.83.198 with SMTP id s6mr3755761wiy.8.1334735681107; Wed, 18 Apr 2012 00:54:41 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.214.20 with HTTP; Wed, 18 Apr 2012 00:54:25 -0700 (PDT) In-Reply-To: <626A389E-CC7E-4EB5-9B55-7B18723A1BCF@tzi.org> References: <626A389E-CC7E-4EB5-9B55-7B18723A1BCF@tzi.org> From: "Angelo P. Castellani" Date: Wed, 18 Apr 2012 09:54:25 +0200 X-Google-Sender-Auth: aZKdZxbmMaaFX_C3owmiBnxv_Ok Message-ID: To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Cc: core Subject: Re: [core] WGLC comment for draft-ietf-core-coap-09: Resetting NONs X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 07:54:42 -0000 On Wed, Apr 18, 2012 at 09:42, Carsten Bormann wrote: > If the endpoint cares, it will have the state. > If it doesn't, the RST is just discarded. > > (Note that we don't require endpoint to actually act on RSTs for NONs, this is strictly optional.) > > (As a quality of implementation point, yes, this is another point were a time constant on the order of "2 MSL" ~ retransmission window is useful.) Assuming that the endpoint cares and wants to act upon RST, I would like to have a default value defined for this. Moreover, as in the related discussion about retransmission window, I would like to have a smaller timeout for this, since in this situation without retransmission the latency will be composed by network delay + processing time, which I hope that we can suppose to be smaller than 256 seconds. Do you think that defining such a default value is not useful? Best, Angelo From matthieu.vial@non.schneider-electric.com Wed Apr 18 01:12:28 2012 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 896C721F8546 for ; Wed, 18 Apr 2012 01:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.373 X-Spam-Level: X-Spam-Status: No, score=-5.373 tagged_above=-999 required=5 tests=[AWL=1.226, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ce6vMa5vCnEx for ; Wed, 18 Apr 2012 01:12:27 -0700 (PDT) Received: from mailX03.eud.schneider-electric.com (mailx03.eud.schneider-electric.com [205.167.7.41]) by ietfa.amsl.com (Postfix) with ESMTP id 8642E21F8526 for ; Wed, 18 Apr 2012 01:12:27 -0700 (PDT) Received: from ATEUI01.schneider-electric.com ([10.198.14.9]) by mailX03.eud.schneider-electric.com with ESMTP id 2012041810122512-199578 ; Wed, 18 Apr 2012 10:12:25 +0200 In-Reply-To: To: Carsten Bormann MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 From: matthieu.vial@non.schneider-electric.com Message-ID: Date: Wed, 18 Apr 2012 10:12:22 +0200 X-MIMETrack: Serialize by Router on ATEUI01.Schneider-Electric.com/T/SVR/Schneider at 18/04/2012 10:13:30, Serialize complete at 18/04/2012 10:13:30, Itemize by SMTP Server on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 18/04/2012 10:12:25, Serialize by Router on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 18/04/2012 10:12:26, Serialize complete at 18/04/2012 10:12:26 Content-Type: text/plain; charset="US-ASCII" Cc: "core@ietf.org" Subject: Re: [core] draft-ietf-core-block-08 - multicast X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 08:12:28 -0000 Hi Carsten >Is there something about multicast that requires special support in -block? >I'm not aware of it. I don't think so but is that clear enough to everybody such that we can just silently ignore the subject? For example I don't expect core-block to be usable for full multicast blockwise transfer on /.well-known/core. The client could just use block to first discover endpoints and make the responses to the multicast request fit a 802.15.4 frame. After that the client can follow with a sequence of unicast blockwise transfers with each discovered endpoint. I admit that this -block usage could be described in group-comm or in a discovery draft rather than in -block. Also we may want a stronger recommendation than coap-09 10.3.3. on -block need for multicast to mitigate amplification attacks. My 2 cents, Matthieu From cabo@tzi.org Wed Apr 18 02:03:07 2012 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 D4AC521F853E for ; Wed, 18 Apr 2012 02:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.409 X-Spam-Level: X-Spam-Status: No, score=-106.409 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35mei6GdrInD for ; Wed, 18 Apr 2012 02:03:07 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id A657621F8437 for ; Wed, 18 Apr 2012 02:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3I92tVx023868; Wed, 18 Apr 2012 11:02:55 +0200 (CEST) Received: from [192.168.217.105] (p54899B15.dip.t-dialin.net [84.137.155.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 10F9A1EA; Wed, 18 Apr 2012 11:02:55 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <22C5F36C-2649-4660-9A3B-FE7A4F516CC1@cisco.com> Date: Wed, 18 Apr 2012 11:02:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <51EC072C-EAF6-468D-B5F1-8A5EC82D6431@tzi.org> References: <22C5F36C-2649-4660-9A3B-FE7A4F516CC1@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1257) Cc: core WG Subject: Re: [core] WGLC comments on draft-ietf-core-block-08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 09:03:07 -0000 > This draft is fairly hard to understand. I suspect that is because the = level complexity in it has evolved over time and I think the terminology = could be re factored to make it clearer.=20 Klaus last week gave me a great set of proposals for further editorial = improvement that I haven't had time to properly act on. I'll combine = them with your editorial points and make a ticket in the next couple of = days. > I think we have three different semantic messages. One is a asking for = a given block - Let me call this GetBlock. One is transferring a = specific block, let me call this TransferBlock, and one is acknowledge = receipt of a given block, let me call that AckBlock. Further more, we = have these block transfer protocol going in the direction of the CoAP = request, and the transfer going in the direction of the CoAP Response.=20= >=20 > I propose we reroute this draft to have 6 instead of 2 options and the = options are called=20 I think it is a great idea to multiply out the existing options and the = kinds of uses (what I called "descriptive" and "control") and give them = explicit names for the exposition in the spec. I think actually giving them different option numbers borders on = gratuitous change at this point. >=20 > The first three are ReqGetBlock, ReqTransferBlock, ReqAckBlock, and = second three are RespGetBlock, RespTransferBlock, RespAckBlock. I don't think there is a "ReqGetBlock"; similarly, RespTransferBlock and = RespAckBlock are the same. > Now the blocks of three might share the same option code in which case = the code is the same as it is today or they might just allocate = different option codes in which case the code is probably simpler. But = the key thing here even if they have just two option codes, is they will = make it much easier to rewrite the spec in a way that is easy to = understand. The draft can talk about when you get a TransferBlock, you = send an AckBlock for without having to try and figure out all the cases = that happen for different method codes. I think we should also define = BlockServer being the thing sending the TransferBlock and BlockClient = being the thing receiving.=20 >=20 > It makes things clear like the size in a GetBlock is just a request = the other size and the server will set the size it wants in the = TransferBlock.=20 >=20 > On the size negotiation, I think the GetBlock should have a size which = is the request size. The server is allowed to choose a size smaller than = this but not one larger.=20 >=20 > I think we need to get more presses about the atomic nature block = transfer semantics. Specifically the requirements around if someone = client A is doing a put on resource while client B is going a get, but = with block transfers. I'm Ok with the idea that a server might know how = to incrementally update a resource in an atopic way but I'm not seeing = how a client would understand some bizarrely fragmented result of a get. = A lot more detail is needed on this.=20 Much of this comes down to the specific application policies that a = resource requires. Block gives you mechanism, but it doesn't replace = thinking about policy. Trying to nail down all that policy would be a mistake. > Some people will want to use this for streaming of infinitely long = resources. It seems like the basic machismo will support that with no = changes but probably needs some details explaining how to do that. = Particularly when mapping to HTTP.=20 One disadvantage Block has here is that it only supports a small number = of rigid block sizes. So if I have a video frame of 563 bytes, this is = hard to cut down into the right number of blocks. > It's unclear to me how a client discovers the server support blocks. It usually doesn't have to. For Block2, just request without it -- the server will switch to = block-wise if needed. For Block1, if the resource to be sent is large, you just don't win with = a server that doesn't to blocks. > Does it just put a GetBlock request on every GET it does? If it needs to influence the block size, that is the only thing it can = do. If it trusts the server to do something sensible, there is not need to = send a Block2. > Similarly, how the server know if the client supports it. Again, it doesn't have normally have to. Even if the client does not send a block option, the server will have = little recourse but to send blocks if the resource is large. The design works best with smart objects the resources of which exhibit = a bimodal distribution, with frequently transferred small resources, and = few much larger ones (that typically are operated on during setup and = management, only). > I assume the idea is since it is critical, you try and if you get an = error on that destination, then you retry without it. That seems a bit = painful. One advantage of different option codes for the GetBlock from = TransferBlock is that GetBlock could be elective and TransferBlock = Critical resulting in much easier negotiation of support. =20 Yes, we considered something like that early in the design, but didn't = think this separation gave you much. Let's face it: Only the most = minimal implementations won't know anything about Block. (Note that only the preferred block size indication field is somewhat = elective; the block number field is critical. The preferred block size = indication field also is not supposed to be ignored once the server does = act on the Block2 option.) So if this is really desirable, we could add a separate elective option = just about preferred block sizes. > I'll note that ETAGS are usually relatively big.=20 (We limited them to 8 bytes, so they are big, but not that big.) Yes, they will inflate the Block2 responses for a changing resource by = maybe 5 to 20 %. With the above assumptions about bimodality, that appears quite = bearable. > I'm not seeing need use the same size block for all the transfers for = a given request as long as the combination of num and sz accurately = indicate where the block fits in the overall resource. This becomes = particularly relevant in not delaying streams.=20 I agree on all points, except for the stream argument -- we didn't make = Block that great for streams (see above). > I wonder if the size option should be moved into it's own spec.=20 Size is mainly useful in conjunction with Block. We also want to alert = Block implementers that it is a good idea to implement Size along with = Block. Together, Block and Size constitute a "module" that you normally = either implement together or don't. Gr=FC=DFe, Carsten From fluffy@iii.ca Wed Apr 18 07:18:46 2012 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 43FE821F858D for ; Wed, 18 Apr 2012 07:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucKHu9BpByUO for ; Wed, 18 Apr 2012 07:18:42 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 3784321F8584 for ; Wed, 18 Apr 2012 07:18:42 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E603B22E25B; Wed, 18 Apr 2012 10:18:34 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Wed, 18 Apr 2012 08:18:33 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <0F5E905B-9933-4F52-8FF7-C88C96E0A780@iii.ca> References: To: matthieu.vial@non.schneider-electric.com X-Mailer: Apple Mail (2.1084) Cc: "core@ietf.org" Subject: Re: [core] draft-ietf-core-block-08 - multicast X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 14:18:46 -0000 What about adding to the draft something like "this version of block was = not designed for use with multicast and the block options SHOULD NOT be = used in a message sent over multicast. Future specification MAY relax = this requirement." And say something about what a node that receives a = block option over multicast does with it.=20 I can imagine using multicast block to do something like upgrade all the = firmware on many devices at once.=20 On Apr 18, 2012, at 2:12 AM, matthieu.vial@non.schneider-electric.com = wrote: > Hi Carsten >=20 >> Is there something about multicast that requires special support in=20= > -block? >> I'm not aware of it. > I don't think so but is that clear enough to everybody such that we = can=20 > just silently ignore the subject? >=20 > For example I don't expect core-block to be usable for full multicast=20= > blockwise transfer on /.well-known/core. > The client could just use block to first discover endpoints and make = the=20 > responses to the multicast request fit a 802.15.4 frame.=20 > After that the client can follow with a sequence of unicast blockwise=20= > transfers with each discovered endpoint. > I admit that this -block usage could be described in group-comm or in = a=20 > discovery draft rather than in -block. >=20 > Also we may want a stronger recommendation than coap-09 10.3.3. on = -block=20 > need for multicast to mitigate amplification attacks. >=20 > My 2 cents, > Matthieu > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From fluffy@cisco.com Wed Apr 18 07:36:40 2012 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 164CC21F85B9 for ; Wed, 18 Apr 2012 07:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.948 X-Spam-Level: X-Spam-Status: No, score=-109.948 tagged_above=-999 required=5 tests=[AWL=0.651, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DApko5RncpD for ; Wed, 18 Apr 2012 07:36:35 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id C0CFA21F8597 for ; Wed, 18 Apr 2012 07:36:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=865; q=dns/txt; s=iport; t=1334759795; x=1335969395; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=a6BiHgK68Q1iQZvLtUNz3EuLZtbuhjGbnXTAZe+vo+0=; b=CiY7PIAzoTWi1nQTpg0d6W07HnVpqscbDY+A716jwOqmbrJzNrBJDvw/ QVlyJobgIEscLtt6q96dVlC+TtDPh7lP6lKr+sqxZtCTF5+LQCvifu6ME HZOFQQxNBMkE+HPCAOnRVF7DBISZ7gd04Y6zCNmLZ/Eaq8riNyQOAoXxa 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmEGALjQjk+rRDoH/2dsb2JhbABEgxyuIYEHgiIBJ4FhHDWHbJlMgSigKJAFYwSIXI0ThXOIXoFpgwaBPQ X-IronPort-AV: E=Sophos;i="4.75,441,1330905600"; d="scan'208";a="37978055" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 18 Apr 2012 14:36:35 +0000 Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3IEaZYs002938 for ; Wed, 18 Apr 2012 14:36:35 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Apr 2012 08:36:36 -0600 Message-Id: To: "core@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] Next Steps X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 14:36:40 -0000 This email with my co-chair hat on ... We need to figure out next steps to move this all forward. I'm up to any = suggestions but here is my straw man suggestion. The authors go thought = the comments received and pick out the ones that they don't understand = or ones the do not think there is general agreement with and form a list = of those. Then we have a few hour phone call to work through them. This = may take a series of phone calls. After that, I hope the authors can = update the draft with all the agreed to changes and form a list of = issues raised that have not been agreed to. If people want to approach this some other way, glad to talk about it as = long as we do something that moves the ball forward. If this sounds = reasonable, I'll start a doodle poll to pick a time for a phone call.=20 Thanks, Cullen From fluffy@cisco.com Wed Apr 18 07:54:11 2012 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 2678021F85C7 for ; Wed, 18 Apr 2012 07:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.013 X-Spam-Level: X-Spam-Status: No, score=-110.013 tagged_above=-999 required=5 tests=[AWL=0.586, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoIh+8pYQyKq for ; Wed, 18 Apr 2012 07:54:06 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id A246C21F85C0 for ; Wed, 18 Apr 2012 07:54:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=11041; q=dns/txt; s=iport; t=1334760846; x=1335970446; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Z+YiD1CFMaBa5q2YY6vsVoQifP4g7QENk1M9mtAK/eg=; b=c6n1aKnSU+QLrIkTv1oe//YX87FA9jv6zRHzjzZ4JSXal3b9VnXib10X 4Jr5rRY9NsSsabrrPgq2AsanHT/9KiceoxL1H0ZbUl6g13cna4MXaN2Ng Es72q0NXCcPUj978hQ3cqQcJjyAcM+ZhtA0YQwKgiXo/zF06IR2iuSjMN U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmMGAGHVjk+rRDoI/2dsb2JhbABEgxyuIYEHggkBAQEDAQEBAQ8BWwIJBQsLDjgnMAYKCR4Eh2gEDJpvoB4EimSFIWMEiFyNE4VziF6BaYMGgTUH X-IronPort-AV: E=Sophos;i="4.75,441,1330905600"; d="scan'208";a="41002418" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 18 Apr 2012 14:54:06 +0000 Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3IEs5uE029402; Wed, 18 Apr 2012 14:54:05 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: <51EC072C-EAF6-468D-B5F1-8A5EC82D6431@tzi.org> Date: Wed, 18 Apr 2012 08:54:06 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <225506ED-404D-4E7C-B02D-1FA658F11357@cisco.com> References: <22C5F36C-2649-4660-9A3B-FE7A4F516CC1@cisco.com> <51EC072C-EAF6-468D-B5F1-8A5EC82D6431@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] WGLC comments on draft-ietf-core-block-08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 14:54:11 -0000 On Apr 18, 2012, at 3:02 AM, Carsten Bormann wrote: >> This draft is fairly hard to understand. I suspect that is because = the level complexity in it has evolved over time and I think the = terminology could be re factored to make it clearer.=20 >=20 > Klaus last week gave me a great set of proposals for further editorial = improvement that I haven't had time to properly act on. I'll combine = them with your editorial points and make a ticket in the next couple of = days. >=20 >> I think we have three different semantic messages. One is a asking = for a given block - Let me call this GetBlock. One is transferring a = specific block, let me call this TransferBlock, and one is acknowledge = receipt of a given block, let me call that AckBlock. Further more, we = have these block transfer protocol going in the direction of the CoAP = request, and the transfer going in the direction of the CoAP Response.=20= >>=20 >> I propose we reroute this draft to have 6 instead of 2 options and = the options are called=20 >=20 > I think it is a great idea to multiply out the existing options and = the kinds of uses (what I called "descriptive" and "control") and give = them explicit names for the exposition in the spec. > I think actually giving them different option numbers borders on = gratuitous change at this point. >=20 >>=20 >> The first three are ReqGetBlock, ReqTransferBlock, ReqAckBlock, and = second three are RespGetBlock, RespTransferBlock, RespAckBlock. >=20 > I don't think there is a "ReqGetBlock"; similarly, RespTransferBlock = and RespAckBlock are the same. perhaps we need to have a WG phone call to sort this out but I think we = are talking past each other. I agree they can reuse the same packet = layout and even code point, but semantically the message with the data = and message with the ack that you got the data are two different = semantic meanings.=20 >=20 >> Now the blocks of three might share the same option code in which = case the code is the same as it is today or they might just allocate = different option codes in which case the code is probably simpler. But = the key thing here even if they have just two option codes, is they will = make it much easier to rewrite the spec in a way that is easy to = understand. The draft can talk about when you get a TransferBlock, you = send an AckBlock for without having to try and figure out all the cases = that happen for different method codes. I think we should also define = BlockServer being the thing sending the TransferBlock and BlockClient = being the thing receiving.=20 >>=20 >> It makes things clear like the size in a GetBlock is just a request = the other size and the server will set the size it wants in the = TransferBlock.=20 >>=20 >> On the size negotiation, I think the GetBlock should have a size = which is the request size. The server is allowed to choose a size = smaller than this but not one larger.=20 >>=20 >> I think we need to get more presses about the atomic nature block = transfer semantics. Specifically the requirements around if someone = client A is doing a put on resource while client B is going a get, but = with block transfers. I'm Ok with the idea that a server might know how = to incrementally update a resource in an atopic way but I'm not seeing = how a client would understand some bizarrely fragmented result of a get. = A lot more detail is needed on this.=20 >=20 > Much of this comes down to the specific application policies that a = resource requires. Block gives you mechanism, but it doesn't replace = thinking about policy. > Trying to nail down all that policy would be a mistake. hmm, here is the problem. The client has to know what the server will = and will not do or you have interoperability problems.=20 >=20 >> Some people will want to use this for streaming of infinitely long = resources. It seems like the basic machismo will support that with no = changes but probably needs some details explaining how to do that. = Particularly when mapping to HTTP.=20 >=20 > One disadvantage Block has here is that it only supports a small = number of rigid block sizes. So if I have a video frame of 563 bytes, = this is hard to cut down into the right number of blocks. >=20 >> It's unclear to me how a client discovers the server support blocks. >=20 > It usually doesn't have to. >=20 > For Block2, just request without it -- the server will switch to = block-wise if needed. and if the the client does not support it?=20 > For Block1, if the resource to be sent is large, you just don't win = with a server that doesn't to blocks. This sounds like everyone has to do it. That's not really what we are = looking for. This needs to be an optional mechanism - blocks trades off = some application complexity of implementing blocks vs the the loss of = reliability that is provided by just using IP level fragmentation.=20 >=20 >> Does it just put a GetBlock request on every GET it does? >=20 > If it needs to influence the block size, that is the only thing it can = do. > If it trusts the server to do something sensible, there is not need to = send a Block2. >=20 >> Similarly, how the server know if the client supports it. >=20 > Again, it doesn't have normally have to. > Even if the client does not send a block option, the server will have = little recourse but to send blocks if the resource is large. again - I disagree. If I am on a network with a MTU of 128 and I need to = send a 300 byte body, both block and non block could work. I think it = would be bad if the server implemented an algorithm like "only use block = if the body is 5 times lager than MTU". That would mean in cases where = the body was only 3 times MTU, and both the client and server supported = block, it would not get used.=20 I think the draft needs to explain when the server should use block and = when it should not.=20 >=20 > The design works best with smart objects the resources of which = exhibit a bimodal distribution, with frequently transferred small = resources, and few much larger ones (that typically are operated on = during setup and management, only). Ok - that may explain some of the disconnect. I want to use this in a = case where all the resources in the system include a public key = signature. This results in them all being larger than one MTU but = smaller than 5 MTU. I think of small as less than one MTU, large as = bigger than you could possible use IP fragmentation, say 10 MTU, and = medium as in between the two.=20 >=20 >> I assume the idea is since it is critical, you try and if you get an = error on that destination, then you retry without it. That seems a bit = painful. One advantage of different option codes for the GetBlock from = TransferBlock is that GetBlock could be elective and TransferBlock = Critical resulting in much easier negotiation of support. =20 >=20 > Yes, we considered something like that early in the design, but didn't = think this separation gave you much. Let's face it: Only the most = minimal implementations won't know anything about Block. right - here again I disagree. I think you are premising this on = everyone will implement this. I think lots of devices will not implement = it for a variety of reasons - I'm not trying to convince you. It's very = hard to predict the future and either of us could be right. However I am = trying to convince you to design a protocol that works for a wide range = of possible futures. I'd call that flexibility. Obviously there is a = trade off between flexibility and simplicity, but in this case I see no = problem with using 6 option codes instead of 2 - particularly if that = greatly simplifies people understanding of this protocol.=20 >=20 > (Note that only the preferred block size indication field is somewhat = elective; the block number field is critical. The preferred block size = indication field also is not supposed to be ignored once the server does = act on the Block2 option.) >=20 > So if this is really desirable, we could add a separate elective = option just about preferred block sizes. I'm thinking that if the GetBlock has a num of 3 and size indicating = 1024, that means the clients wants 1024 bytes of data starting at = location 3*1024. If the server only wants to hand back 512 bytes of = data, it returns a transfer with the num=3D6 and size indicating 512. = The client looks at the 6 and 512 in the transfer and knows that this = data is 512 bytes of data that goes at location 6*512. In the clients = next request it can ask for whatever it wants. Of course the logical = thing to ask for is the next byte it need which would be at location = 7*512. After it gets that, instead of asking for 8*512, it might ask for = 4*1024 again if it was willing to receive that. Something like that = reduces all of the implementation complexity that comes from statements = around what happened on a previous request change what happens in a = future request. It's also very complicated to test code where previous = packets impact how the code path for the current packet.=20 >=20 >> I'll note that ETAGS are usually relatively big.=20 >=20 > (We limited them to 8 bytes, so they are big, but not that big.) Thanks for reminding me - I had forgotten they were limited to 8.=20 > Yes, they will inflate the Block2 responses for a changing resource by = maybe 5 to 20 %. > With the above assumptions about bimodality, that appears quite = bearable. >=20 >> I'm not seeing need use the same size block for all the transfers for = a given request as long as the combination of num and sz accurately = indicate where the block fits in the overall resource. This becomes = particularly relevant in not delaying streams.=20 >=20 > I agree on all points, except for the stream argument -- we didn't = make Block that great for streams (see above). I guess this is what I would ask about stream. Think about it a bit and = see if the current mechanisms can be used for streaming with very little = or no change. If yes, explain how int he draft, if not explain why in = the draft. If stream complicated block in a significant way, I would not = want to add it as a requirement but if it is easy to do, there are many = situations that can take advantage of streams.=20 >=20 >> I wonder if the size option should be moved into it's own spec.=20 >=20 > Size is mainly useful in conjunction with Block. We also want to = alert Block implementers that it is a good idea to implement Size along = with Block. Together, Block and Size constitute a "module" that you = normally either implement together or don't. fair enough - that's fine with me >=20 > Gr=FC=DFe, Carsten >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From fluffy@iii.ca Wed Apr 18 07:57:56 2012 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 DBD9421F84F0 for ; Wed, 18 Apr 2012 07:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtzSXvjnTUgD for ; Wed, 18 Apr 2012 07:57:56 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB6E21F84EA for ; Wed, 18 Apr 2012 07:57:56 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 766EA22E257; Wed, 18 Apr 2012 10:57:49 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <626A389E-CC7E-4EB5-9B55-7B18723A1BCF@tzi.org> Date: Wed, 18 Apr 2012 08:57:48 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <5B365D30-B8F1-4344-A87B-0CE8BF56E401@iii.ca> References: <626A389E-CC7E-4EB5-9B55-7B18723A1BCF@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1084) Cc: core Subject: Re: [core] WGLC comment for draft-ietf-core-coap-09: Resetting NONs X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 14:57:57 -0000 On Apr 18, 2012, at 1:42 AM, Carsten Bormann wrote: > On Apr 18, 2012, at 09:21, Angelo P. Castellani wrote: >=20 >> Dear WG, >>=20 >> since Section 4.4.4 specifies that NON messages can be resetted. >=20 > (i.e., replied to with a RST.) >=20 >> However the specification gives no hint about how much time the >> transmitter endpoint MUST be prepared to receive a RST message from >> the recipient. >>=20 >> Should we specify a default value for this timeout? >=20 > Why would we need to specify anything here? >=20 > If the endpoint cares, it will have the state. > If it doesn't, the RST is just discarded. >=20 > (Note that we don't require endpoint to actually act on RSTs for NONs, = this is strictly optional.) >=20 > (As a quality of implementation point, yes, this is another point were = a time constant on the order of "2 MSL" ~ retransmission window is = useful.) Perhaps we should define a time constant with a value that represents = the upper bound on what the Round Trip Time is allowed to be on the = operational network. I'd suggest a default of 20 seconds.=20 From fluffy@iii.ca Wed Apr 18 08:04:18 2012 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 3C98321F8569 for ; Wed, 18 Apr 2012 08:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4U+x6U0P-ki for ; Wed, 18 Apr 2012 08:04:17 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9983821F8533 for ; Wed, 18 Apr 2012 08:04:17 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7B9A722E1F4; Wed, 18 Apr 2012 11:04:16 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <031DD135F9160444ABBE3B0C36CED618092AF8@011-DB3MPN1-013.MGDPHG.emi.philips.com> Date: Wed, 18 Apr 2012 09:04:15 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <031DD135F9160444ABBE3B0C36CED618092AF8@011-DB3MPN1-013.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1084) Cc: "core@ietf.org" , Klaus Hartke Subject: Re: [core] draft-ietf-core-block-08 - Block ordering X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 15:04:18 -0000 On Apr 12, 2012, at 3:36 AM, Dijk, Esko wrote: > Option 2) e.g. specify a CoAP end-point MAY use block numbers in = sequential fashion. > [this automatically implies an end-point MUST be prepared = to receive sequential block numbers. At least an implementer MUST > consider this possibility.] Saying a sever MAY do something is more or less equivalent to saying the = client MUST NOT bother to use this. I'm not a fan of anything where the = client will not know if three code will work with the server or not.=20 From fluffy@iii.ca Wed Apr 18 08:05:30 2012 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 C54EC21F85D3 for ; Wed, 18 Apr 2012 08:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yirtR0CHRpi2 for ; Wed, 18 Apr 2012 08:05:27 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3E921F85CC for ; Wed, 18 Apr 2012 08:05:27 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5974522E25C; Wed, 18 Apr 2012 11:05:26 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Wed, 18 Apr 2012 09:05:25 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <3838EDF5-A1C8-4A4B-833A-F09C76A961C5@iii.ca> References: To: Klaus Hartke X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org Subject: Re: [core] draft-ietf-core-block-08 - Block ordering X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 15:05:30 -0000 To make your questions a little more pointed .... lets assume that the = resource is the type that changes rapidly and where the server has to = provide take a snapshot of the whole resource to keep it consistent. So = say a resource is 7 blocks long and the client requests block 3 causing = the server to make a snapshot of it with the assumption that the client = will request the other blocks. Then the client asks for block 5. If the = client never asks for another block, when does the server discard the = snapshot ? On Apr 10, 2012, at 10:32 PM, Klaus Hartke wrote: > Is a client allowed to up/download multiple blocks of the same > representation concurrently? Or does it have to wait for the response > before it up/downloads the next block? >=20 > Do blocks have to be up/downloaded with strictly increasing block = numbers? >=20 > If blocks do not need to be uploaded with strictly increasing block > numbers, should the client set the M in the request with the highest > block number or in the last request it sends? >=20 > Use case: > Step 1. The client uploads the first block to check if the server > supports block-wise transfers. > Step 2. The client uploads the last block to check if the server is > willing to accept a representation of this size. > Step 3. The client concurrently uploads all blocks in between, with > the M bit unset in the second-to-last block. >=20 >=20 > Klaus > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From angelo.castellani@gmail.com Wed Apr 18 08:06:03 2012 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 0EB0221F85EF for ; Wed, 18 Apr 2012 08:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.847 X-Spam-Level: X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DS312iW62NKV for ; Wed, 18 Apr 2012 08:06:02 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5A12D21F85E3 for ; Wed, 18 Apr 2012 08:06:02 -0700 (PDT) Received: by werb10 with SMTP id b10so5861390wer.31 for ; Wed, 18 Apr 2012 08:06:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=ilRdDs4Zgb7Bt/gbeFl34cvWShRo90x+SBSztWV1nFo=; b=KVq0hbAJUnTVVkVm6eQDn0ImJowUMFrQx7CLptJv/Xh0Sna5T20ZjTt/JO1gf5joBe 1sjx+kTisdxXdsOvX6tj7oCdUnlZGvpgm4BeIopFeOaZH+A+G5O4ZKVTv8nzolDk/Wfq J4PLhz5xswXeu6wnFa3jBa4lS7ribEf3WQGt6Sq20b8iQ3fvwC1FDm6pnmwSXq5OEQ01 fJ+r4mMpLdkzF3JV8RUwdznq1+YXIvELLeG81gq4j7eAuC4Pdjs2AVodpNtbBWbvD+jK hm67bbpkaShGUiH4Bbx7k3c54mz7v2CjXEGp+7q2Yb3ieDK09YfpzaJ6qAmC7HbDbIFf VmWw== Received: by 10.180.73.143 with SMTP id l15mr7085463wiv.11.1334761561225; Wed, 18 Apr 2012 08:06:01 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.214.20 with HTTP; Wed, 18 Apr 2012 08:05:45 -0700 (PDT) In-Reply-To: <5B365D30-B8F1-4344-A87B-0CE8BF56E401@iii.ca> References: <626A389E-CC7E-4EB5-9B55-7B18723A1BCF@tzi.org> <5B365D30-B8F1-4344-A87B-0CE8BF56E401@iii.ca> From: "Angelo P. Castellani" Date: Wed, 18 Apr 2012 17:05:45 +0200 X-Google-Sender-Auth: 7q-FLdLgRkRqvqa5sG_TZae1La0 Message-ID: To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Cc: core Subject: Re: [core] WGLC comment for draft-ietf-core-coap-09: Resetting NONs X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 15:06:03 -0000 On Wed, Apr 18, 2012 at 16:57, Cullen Jennings wrote: > Perhaps we should define a time constant with a value that represents the upper bound on what the Round Trip Time is allowed to be on the operational network. I'd suggest a default of 20 seconds. Isn't that too much? 10 seconds of flight time seems unrealistic to me. Best, Angelo From angelo.castellani@gmail.com Wed Apr 18 08:06:50 2012 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 98C4121F85D3 for ; Wed, 18 Apr 2012 08:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.859 X-Spam-Level: X-Spam-Status: No, score=-2.859 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id woItcxJLAMJ9 for ; Wed, 18 Apr 2012 08:06:49 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1888921F856A for ; Wed, 18 Apr 2012 08:06:48 -0700 (PDT) Received: by werb10 with SMTP id b10so5862062wer.31 for ; Wed, 18 Apr 2012 08:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=Sy2N4qowddSFu/kUa458gPjj543bdArKIjx+1JoAprA=; b=SGo1mHSD9yX7T55QH8V4oGu7VQuPY7CzElaRBeZbRnchmiY/BLsCrBhCgRPYivbAfl vquuySNgdqVyDxraCkSOQVGa+2uQvYGCTcVaxmbqJXOPh4lZpHKcE9UFbTg8R6QmheyO J08vLr8Lt8J2BAwSLXZi9l0Fw9cA1GAXbh7aG6L8lNntFqLwIXlamdIXl+VAac1UCRbn 9DF/gb/QGzXsObUYy2qHQFe94hggLPGfFy20/le90Wuk9q/k4qIwggkph0rfD42vSBAt tTRmboPBVOSypL1K909UMoFo9Lzat1zajas2FN7UAY6n8s3I+/MdxLDYrR6H1nWkcGUT MXYw== Received: by 10.216.131.30 with SMTP id l30mr1630417wei.111.1334761608326; Wed, 18 Apr 2012 08:06:48 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.214.20 with HTTP; Wed, 18 Apr 2012 08:06:32 -0700 (PDT) In-Reply-To: References: <626A389E-CC7E-4EB5-9B55-7B18723A1BCF@tzi.org> <5B365D30-B8F1-4344-A87B-0CE8BF56E401@iii.ca> From: "Angelo P. Castellani" Date: Wed, 18 Apr 2012 17:06:32 +0200 X-Google-Sender-Auth: UfbEAu9bqlyOwbSpnblDfMBGKPM Message-ID: To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Cc: core Subject: Re: [core] WGLC comment for draft-ietf-core-coap-09: Resetting NONs X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 15:06:51 -0000 I had hoped something like 5-10 seconds of default value. On Wed, Apr 18, 2012 at 17:05, Angelo P. Castellani wrote: > On Wed, Apr 18, 2012 at 16:57, Cullen Jennings wrote: >> Perhaps we should define a time constant with a value that represents the upper bound on what the Round Trip Time is allowed to be on the operational network. I'd suggest a default of 20 seconds. > > Isn't that too much? > > 10 seconds of flight time seems unrealistic to me. > > Best, > Angelo From fluffy@iii.ca Wed Apr 18 08:13:02 2012 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 6A2A421F859B for ; Wed, 18 Apr 2012 08:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgLcXSTIdyj9 for ; Wed, 18 Apr 2012 08:13:02 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id D790B21F84E4 for ; Wed, 18 Apr 2012 08:13:01 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C795222E259; Wed, 18 Apr 2012 11:13:00 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Wed, 18 Apr 2012 09:13:00 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Angelo P. Castellani X-Mailer: Apple Mail (2.1084) Cc: core Subject: Re: [core] draft-ietf-core-coap-09: retransmission window X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 15:13:02 -0000 On Mar 28, 2012, at 3:00 AM, Angelo P. Castellani wrote: > Section 4.1 tells: >=20 > The same Message ID MUST NOT be re-used (per Message > ID variable) within the potential retransmission window, calculated > as RESPONSE_TIMEOUT * RESPONSE_RANDOM_FACTOR * (2 ^ MAX_RETRANSMIT = - > 1) plus the expected maximum round trip time. >=20 >=20 > Question 1: Given that these parameters are not mandated by the = standard, does the spec assume that will be available some way to = synchronize those parameters across different implementations to = correctly avoid reusing a MID in the retransmission window? The IESG will want to know that this protocol is TCP Friendly. Setting = these values very low would cause this protocol to not be TCP Friendly. = We will need to meet the appropriate BCP on congestion control for this = spec to be approved. I would fall over backwards to see the IESG approve = this spec with the spec saying you can set these however you want.=20 I know that it seems to the WG like, hey, I should be able to set these = however I want for my network and that is a good thing. But I don't = think you will like this. The end result will be huge pressure on vendor = B to set their default values to be more aggressive than vendor A. The = arms race to aggression will result in setting that are too aggressive = for many networks.=20 The setting of these values is a classic case where we want to avoid = tragedy of the commons. What the vendors need is standards body to set a = bound on the level of aggression and that is what people will use as the = if they want to say their device implements the RFC. Sure, the vendor = might allow you to configure the device in a way that is not compliant = with the spec - but hopefully it won't default to non compliant they = want to put "Supports RFC XXXX" in their product sheet.=20 From fluffy@cisco.com Wed Apr 18 08:15:27 2012 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 6E06921F8607 for ; Wed, 18 Apr 2012 08:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.067 X-Spam-Level: X-Spam-Status: No, score=-110.067 tagged_above=-999 required=5 tests=[AWL=0.532, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFl55IGxez6B for ; Wed, 18 Apr 2012 08:15:23 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id D951F21F85EF for ; Wed, 18 Apr 2012 08:15:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=3094; q=dns/txt; s=iport; t=1334762122; x=1335971722; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=DFJ1xK3OhhYMkI8/9nSigPFb5PjbAq/Dnwsw06yx3kE=; b=CUk55JfMmX7G67n9qLhvQ5HfKOdsmm1ABGpdNdBWToOolyCRy68LAnf7 5Mm6qyCX986EthxovZ7UcEw0451uCH+3vNa0LQH1lSJSsnG4CP6AMOlRr /8/coysHKQQG0Sq6G2ZPOcue8ORywVuXpLO40I5yYyuLsBZgMtRIB/7A8 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmMGAGfZjk+rRDoJ/2dsb2JhbABEgxyuIYEHggkBAQEDAQEBAQ8BVAcLBQsLDgouJzAGEyKHaAQMmn2gGgSKZIUhYwSIXI0ThXOIXoFpgwaBNQc X-IronPort-AV: E=Sophos;i="4.75,441,1330905600"; d="scan'208";a="38519834" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 18 Apr 2012 15:15:22 +0000 Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3IFFMOL020153; Wed, 18 Apr 2012 15:15:22 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: Date: Wed, 18 Apr 2012 09:15:23 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9E5F67AC-943D-4A97-B19D-313B7194D9AF@cisco.com> To: Carsten Bormann X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] WGLC draft-ietf-core-coap-09 Reuse of MID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 15:15:27 -0000 Ok, sounds like we need the spec to say MUST not reuse for "awhile" and = define "awhile" in seconds. I really hope it can be less than 256.=20 On Apr 18, 2012, at 1:20 AM, Carsten Bormann wrote: > On Apr 18, 2012, at 06:57, Cullen Jennings wrote: >=20 >>=20 >>=20 >> I don't understand when a MID can be reused. >=20 > A MID is to be used again for retransmitting the same message. >=20 > After completing (re-)transmitting a message, the MID should not be = used for a while. > In my implementation, I don't *re*use a MID (i.e., for a different = message) 256 seconds after having used it. >=20 >> I'm primarily concerned about use of default MID.=20 >=20 > I don't think anyone implements a default MID. Do you mean a default = token? >=20 > We had a discussion around the Paris plug test about the way MID and = Token together make sure that there is no confusion. > Angelo Castellani has written up some of that in = draft-castellani-lwig-coap-separate-responses-00.txt -- the title is a = bit misleading, this draft collects a number of examples for packet = exchanges. I hope we can develop this into an informational RFC that = explains the finer points of why this works. >=20 > Note that the complexity of *implementation* is quite limited here; = the discussion in the draft is extensive as it shows a large number of = cases. >=20 > See also ticket #201. >=20 >> Say I am on a network with 5 seconds latency but no packets are lost.=20= >>=20 >> A sends Req1 to B. Due to latency, A retransmits Req1 to B. >=20 > Both use, say, MID 47, and, for minimal packet size, Token 0 (default = token), >=20 >> B sends response 1 to A which A receives. >=20 > If this is piggybacked in an ACK, it will have MID 47, too. >=20 >> No A decided to immediately send Req2 to B. >=20 > This would *have* to have a new MID, say, 48. >=20 >> In the meantime, B had received the retransmission of Req1 and resent = the response. The response arrives at A after A has send the second = request but because the MID are the same, >=20 > Even if the second request carries the same token 0 (which is allowed = as the token of the first request has been "put back" by the first = response), it still has to have a different MID if it is so close. >=20 >> A mistakenly thinks that the response is a response to Request2 when = really it was a response to Req1. =20 >=20 > The important observation here is that the protection against = duplicate packets (which are quite likely to occur because of = retransmission and lost/delayed ACKs) comes from the MID. >=20 >> It seems to me that that once a MID is used, it can't be re-used for = some significant amount of time.=20 >=20 > I don't know if 256 s is "significant", but yes, the "2 MSL" argument = applies here. >=20 > There is no such need for timeout-based blocking for the reuse of = token values. >=20 > Gr=FC=DFe, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From fluffy@iii.ca Wed Apr 18 08:21:09 2012 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 9088821F859F for ; Wed, 18 Apr 2012 08:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TcbFVGMIayqi for ; Wed, 18 Apr 2012 08:21:05 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD1021F85B8 for ; Wed, 18 Apr 2012 08:21:05 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 240FD22E25C; Wed, 18 Apr 2012 11:20:56 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4F8DFF3D.50201@itm.uni-luebeck.de> Date: Wed, 18 Apr 2012 09:20:55 -0600 Content-Transfer-Encoding: 7bit Message-Id: <085E1C1D-4E7B-4494-9B75-D9BFC487A261@iii.ca> References: <4F8DFF3D.50201@itm.uni-luebeck.de> To: Stephan Lohse X-Mailer: Apple Mail (2.1084) Cc: "core@ietf.org WG" Subject: Re: [core] End of Options Marker/Use of a delta of 15 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 15:21:10 -0000 Good question - I just found a bug in my code - thanks :-) On Apr 17, 2012, at 5:39 PM, Stephan Lohse wrote: > Hi, > > do "unlimited options" and the need for an end-of-options marker mean > that deltas of 15 should not be used in that case, or is using a delta > of 15 fine as long as the length is not zero? > > Regards, > - Stephan Lohse > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From angelo.castellani@gmail.com Wed Apr 18 08:22:08 2012 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 8116521F846F for ; Wed, 18 Apr 2012 08:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.869 X-Spam-Level: X-Spam-Status: No, score=-2.869 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AzYG0D6c-xG for ; Wed, 18 Apr 2012 08:22:08 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA4C21F8455 for ; Wed, 18 Apr 2012 08:22:07 -0700 (PDT) Received: by werb10 with SMTP id b10so5875855wer.31 for ; Wed, 18 Apr 2012 08:22:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=T4IqYjSlP8FM7TnYOk5pbHehRRolRpQ4bIy+Ruc22WQ=; b=RAi8zK/SfmpE/IFoxMoGPkFYObaOAFgldCtzz6dJVbvpy0K57JU0MFEYGnt3WgiB4U RE3yVGhY3i7W2xI+q8rlTKwzqu9mn3uDeqNxA28k9CQhFP7HUwAzduiS8mLMX4BgQC7B Xw6qfWPiZPGLspqLvujFTsU4QHUgaHVaFJcgTbANz0GvwT4pYwjUAzM0Y9B6qPbmgHZk zge0ybWvfeQ3dsawTQqBJnv/csHlm5jfSk94HM8vHHEFM2z1IpF7AS4pLlXvfLSX1Cuw b5lHSn5dTj+oLtva7abHrpHJhHJZPUV5l+k4uCM1AFvxGY+zMZDF/SAmS2jsr4j+bUJK RsaA== Received: by 10.180.89.9 with SMTP id bk9mr7204830wib.11.1334762526669; Wed, 18 Apr 2012 08:22:06 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.214.20 with HTTP; Wed, 18 Apr 2012 08:21:46 -0700 (PDT) In-Reply-To: References: <9E5F67AC-943D-4A97-B19D-313B7194D9AF@cisco.com> From: "Angelo P. Castellani" Date: Wed, 18 Apr 2012 17:21:46 +0200 X-Google-Sender-Auth: Rfm0vCQkInqWflQtTg06gdhskPc Message-ID: To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Cc: core WG Subject: Re: [core] WGLC draft-ietf-core-coap-09 Reuse of MID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 15:22:08 -0000 On Wed, Apr 18, 2012 at 17:15, Cullen Jennings wrote: > Ok, sounds like we need the spec to say MUST not reuse for "awhile" and define "awhile" in seconds. I really hope it can be less than 256. The problem itself is not related to the client reusing it, which since it is paired to destination host, destination port and token, it is hard that a collision happens. The real problem is on the recipient side, that has to track the received MIDs paired with source host, source port and token, to really enable deduplication... This is hard and leads to heavy RAM usage, and may hardly limit the ability to receive messages. See the related discussion happening on the thread pointed in the previous mail. Best, Angelo From fluffy@iii.ca Wed Apr 18 08:24:09 2012 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 64A7221F860E for ; Wed, 18 Apr 2012 08:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77BT1ySl-Ebz for ; Wed, 18 Apr 2012 08:24:05 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB8D21F85F7 for ; Wed, 18 Apr 2012 08:24:05 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 242C422E256; Wed, 18 Apr 2012 11:24:02 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Wed, 18 Apr 2012 09:24:02 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <37D1F6CA-9A43-4B8E-8B67-0186C39D458B@iii.ca> References: To: Klaus Hartke X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org Subject: Re: [core] draft-ietf-core-block-08 - Disentangle Block and Success Response Codes X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 15:24:09 -0000 +1 - this solution makes sense to me.=20 On Apr 16, 2012, at 8:18 PM, Klaus Hartke wrote: > When a client performs an atomic block-wise POST/PUT, the server > returns a 2.01 (Created) or 2.04 (Changed) response for each uploaded > block. coap-09 defines the two response codes as follows: >=20 > * 2.01 (Created) means that a resource was created at the target > URI/Location URI and requires that a cache marks any stored response > for the created resource as not fresh. > * 2.04 (Changed) means that the target resource was changed and > requires that a cache marks any stored response for the changed > resource as not fresh. >=20 > The problem is: the target resource is not really created or changed > in an atomic block-wise POST/PUT before the last block is uploaded. > Invalidating all caches long before the POST/PUT is complete doesn't > sound like a good idea. >=20 > I propose to return a different, new response code that doesn't have > an effect on caches and conveys the non-final nature of the response. > An equivalent of the HTTP 100 status code [1] would be the best fit: >=20 > - 100 Continue >=20 > The client SHOULD continue with its request. This > interim response is used to inform the client that the > initial part of the request has been received and has > not yet been rejected by the server. The client > SHOULD continue by sending the remainder of the > request or, if the request has already been completed, > ignore this response. The server MUST send a final > response after the request has been completed. >=20 >=20 > Klaus >=20 >=20 > [1] = http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-19#section-7.1.= 1 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From fluffy@iii.ca Wed Apr 18 08:27:09 2012 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 3DAB221F859B for ; Wed, 18 Apr 2012 08:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3S2KRGMgbHM for ; Wed, 18 Apr 2012 08:27:05 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 35E8D21F8459 for ; Wed, 18 Apr 2012 08:27:05 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D996822E25E; Wed, 18 Apr 2012 11:27:01 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Cullen Jennings In-Reply-To: <051.e7fbc0f0f5736d305a309a9e8d0cd924@trac.tools.ietf.org> Date: Wed, 18 Apr 2012 09:27:01 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <61887542-A2C0-4DF2-B784-34ABE12E38EF@iii.ca> References: <051.e7fbc0f0f5736d305a309a9e8d0cd924@trac.tools.ietf.org> To: trac+core@trac.tools.ietf.org X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-core-coap@tools.ietf.org, core@ietf.org Subject: Re: [core] #202: Remove the 270 byte artificial limit X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 15:27:09 -0000 I'm not a fan to removing the limit. Thought we could do it, I don't see = the need for doing it and I think it will increase the number of bugs = and reduce interoperability where one person assumes a limit of 1024 and = someone else assumes 65k.=20 On Mar 28, 2012, at 6:27 AM, core issue tracker wrote: > #202: Remove the 270 byte artificial limit >=20 > For a while, it seemed we had consensus to leave in the artificial = limit > of 270 bytes for the option length. However, this left a scar on Uri- > Proxy, which needed special handling for the rare case where this = creates > a problem. >=20 > Matthias Kovatsch has now proposed a simple way to remove the = artificial > limitation, which is documented in section 2.1 of >=20 > = http://tools.ietf.org/html/draft-bormann-coap-misc-14#section-2.1 >=20 > This change will also enable the reverting of Uri-Proxy to its natural > state of a non-repeatable option. >=20 > --=20 > -----------------------------+------------------------------------ > Reporter: cabo@=85 | Owner: draft-ietf-core-coap@=85 > Type: protocol defect | Status: new > Priority: minor | Milestone: > Component: coap | Version: > Severity: In WG Last Call | Keywords: > -----------------------------+------------------------------------ >=20 > Ticket URL: > core >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From salvatore.loreto@ericsson.com Wed Apr 18 09:02:41 2012 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 B1C0E21F859B for ; Wed, 18 Apr 2012 09:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.317 X-Spam-Level: X-Spam-Status: No, score=-106.317 tagged_above=-999 required=5 tests=[AWL=-0.668, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3jq3qYCObxY for ; Wed, 18 Apr 2012 09:02:37 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0960A21F85C9 for ; Wed, 18 Apr 2012 09:02:36 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-46-4f8ee59b1c65 Authentication-Results: mailgw1.ericsson.se x-tls.subject="/CN=esessmw0256"; auth=fail (cipher=AES128-SHA) Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0256", Issuer "esessmw0256" (not verified)) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 86.6B.25560.B95EE8F4; Wed, 18 Apr 2012 18:02:35 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.213.0; Wed, 18 Apr 2012