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

Section 4.3 defines matching based on Message ID for= both unicast and multicast. Only for unicast, there is additional source/d= estination matching required.

Could/should we require matching of source/destinati= on for multicast as well, in as far as possible?

 

E.g. in NoSec, UDP destination port number of multic= ast message and unicast response source port must match. [In case we don= 217;t include this on purpose, why then is this not needed for multicast bu= t is needed for unicast?]

Or, e.g. for any tbd-in-the-future secured multicast= modes the security context MUST match.

 

Esko Dijk

Senior scientist, Lighting Control Systems

 

Philips Group Innov= ation, Research

High Tech Campus 34= (room 1.059)

5656 AE  Eindh= oven, The Netherlands

Phone: +31 40 2= 7 47947, E-Mail: esko.dijk@philips.com

Mobile: +31 6 1= 2642103

www.research.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_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 18:02:35 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 1C19B2325 for ; Wed, 18 Apr 2012 19:02:35 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 23F1A520FC for ; Wed, 18 Apr 2012 19:02:35 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D409750984 for ; Wed, 18 Apr 2012 19:02:34 +0300 (EEST) Message-ID: <4F8EE59A.2030304@ericsson.com> Date: Wed, 18 Apr 2012 19:02:34 +0300 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: 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== Subject: Re: [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 16:02:41 -0000 On 4/18/12 5:36 PM, Cullen Jennings wrote: > 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. > > Thanks, > Cullen > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core it works for me. Salvatore -- Salvatore Loreto, PhD www.sloreto.com From cabo@tzi.org Wed Apr 18 09:06: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 1F44021F85DB for ; Wed, 18 Apr 2012 09:06:12 -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 6tMpFZN0rzOi for ; Wed, 18 Apr 2012 09:06: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 BFB9A11E8081 for ; Wed, 18 Apr 2012 09:06: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 q3IG5i70010869; Wed, 18 Apr 2012 18:05:44 +0200 (CEST) Received: from [192.168.217.105] (p5489A708.dip.t-dialin.net [84.137.167.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 474375A0; Wed, 18 Apr 2012 18:05:44 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: <61887542-A2C0-4DF2-B784-34ABE12E38EF@iii.ca> Date: Wed, 18 Apr 2012 18:05:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5BEC4E4C-FF04-44DC-A14B-2FA73E3D573F@tzi.org> References: <051.e7fbc0f0f5736d305a309a9e8d0cd924@trac.tools.ietf.org> <61887542-A2C0-4DF2-B784-34ABE12E38EF@iii.ca> To: Cullen Jennings X-Mailer: Apple Mail (2.1257) Cc: draft-ietf-core-coap@tools.ietf.org, trac+core@gamay.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 16:06:12 -0000 On Apr 18, 2012, at 17:27, Cullen Jennings wrote: >=20 > 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 Two observations: 1) There is a gross upper limit on all this: datagram size. This is = currently constrained by the lack of Path MTU discovery to 1280. 2) 270 was deemed too low for the Proxy-Uri option. We now have a = special case just for that, which already has all the unpleasant = properties you describe. Instead of doing another special case for = every new option that might come up, doing this once is more attractive. = Or we might get rid of the Proxy-Uri special case! Gr=FC=DFe, Carsten From trac+core@trac.tools.ietf.org Wed Apr 18 09:16: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 997F811E8081 for ; Wed, 18 Apr 2012 09:16:16 -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 QUF5T95cxZ1v for ; Wed, 18 Apr 2012 09:16:11 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE7621F8552 for ; Wed, 18 Apr 2012 09:16:11 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SKXY4-0005WO-Ri; Wed, 18 Apr 2012 12:16:04 -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, 18 Apr 2012 16:16:04 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/211 Message-ID: <051.1e6287ce725552ffe1353c663f4c2d17@trac.tools.ietf.org> X-Trac-Ticket-ID: 211 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: <20120418161611.9BE7621F8552@ietfa.amsl.com> Resent-Date: Wed, 18 Apr 2012 09:16:11 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #211: Signal provisional responses (atomic Block1) in the response code 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 16:16:16 -0000 #211: Signal provisional responses (atomic Block1) in the response code Esko Dijk and Klaus Hartke point out that the 2.01/2.04 responses that are foreseen for provisional responses to atomic blockwise request body transfers (Block1) are misleading. Section 2.1 currently proposes signaling the fact that a response to a single block is only provisional and the whole body will be reassembled before the method is actually performed, using the M bit in the response; the response code is more or less invalidated as provisional when the M bit is set in a Block1 option in the response. Klaus Hartke proposes to introduce a provisional response code similar to 100 continue in HTTP, which is defined as follows: - 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. (http://tools.ietf.org/html/draft-ietf- httpbis-p2-semantics-19#section-7.1.1) If we pick this up: 1) Section 5.9 of CoAP-09 currently only defines Success (2.xx), Client Error (4.xx), and Server Error (5.xx); the provisional response code could be grouped under Success (2.xx) or start a new class (1.xx?). 2) Once this code is defined, the M bit in the Block1 response option may or may not continue to be used in the way block-08 does. -- -----------------------------+------------------------------------- Reporter: cabo@… | Owner: draft-ietf-core-block@… Type: protocol defect | Status: new Priority: major | Milestone: Component: block | Version: Severity: In WG Last Call | Keywords: -----------------------------+------------------------------------- Ticket URL: core From cabo@tzi.org Wed Apr 18 09:16: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 6810121E8011 for ; Wed, 18 Apr 2012 09:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.401 X-Spam-Level: X-Spam-Status: No, score=-106.401 tagged_above=-999 required=5 tests=[AWL=-0.152, 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 3KHp7-M5n6Mw for ; Wed, 18 Apr 2012 09:16:41 -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 42CB011E8091 for ; Wed, 18 Apr 2012 09:16: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 q3IGGSkT015663 for ; Wed, 18 Apr 2012 18:16:28 +0200 (CEST) Received: from [192.168.217.105] (p5489A708.dip.t-dialin.net [84.137.167.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 37F695B0; Wed, 18 Apr 2012 18:16:28 +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 18:16:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5529BBFC-B3E7-4573-9E32-9F60F858F9AB@tzi.org> References: To: Klaus Hartke X-Mailer: Apple Mail (2.1257) 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 16:16:42 -0000 On Apr 17, 2012, at 04:18, Klaus Hartke wrote: > - 100 Continue Now #211. Gr=FC=DFe, Carsten From cabo@tzi.org Wed Apr 18 09:42: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 8A06A21F8537 for ; Wed, 18 Apr 2012 09:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.897 X-Spam-Level: X-Spam-Status: No, score=-103.897 tagged_above=-999 required=5 tests=[AWL=-2.648, BAYES_00=-2.599, GB_SUMOF=5, 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 sarf8aZ-r5CS for ; Wed, 18 Apr 2012 09:42:00 -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 D14D221F8596 for ; Wed, 18 Apr 2012 09:41: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 q3IGfkan028433; Wed, 18 Apr 2012 18:41:46 +0200 (CEST) Received: from [192.168.217.105] (p5489A708.dip.t-dialin.net [84.137.167.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C25C65D5; Wed, 18 Apr 2012 18:41:45 +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 18:41:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7D196561-77B0-411B-96EB-F60504165E05@tzi.org> References: <9E5F67AC-943D-4A97-B19D-313B7194D9AF@cisco.com> To: "Angelo P. Castellani" X-Mailer: Apple Mail (2.1257) Cc: Cullen Jennings , 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 16:42:00 -0000 Well, both client and server need to process the MID. Let "awhile1" be the time constant that is equivalent to TCP's "2 MSL", = i.e. the sum of the maximum latency we expect on the way forward and the = maximum latency. "awhile0" is just the difference between minimum and maximum forward = latency ("MSL" for all intents and purposes). "retransmission window" is awhile1 + the maximum time between the first = and the last transmission in a CON retransmission sequence. (There is = also a related number that can be built from awhile0.) It is relatively easy for the emitter of a CON/NON to choose = non-conflicting MIDs, unless it sends at a rate of more than = 65536/"retransmission window" messages from/to the same endpoint, or it = forgets its state and comes up again before retransmission window = expires: just keep a number (per endpoint pair, or if 65536/retrwin is = enough for this, even for the entire client), and increment it per = message use. The duplicate detection at the receiver is more work. One strategy for = this is discussed in 3.4.2.3 in draft-bormann-lwig-guidance-01.txt. As = Esko notes there, this is easier if the emitter uses the "sequential" = (i.e., one counter per peer end-point) strategy. If we want to standardize MSL values, we need to consider sleeping = nodes. Where a node is aware (e.g., on L2) of the sleep schedule of the = next-hop node, it may buffer a packet for quite some time. There is = *no* reasonable upper bound for this. However, traditional IP-based = protocols become less useful once this storage time exceeds a couple of = minutes. Hence my shot in the dark of "256 s" for the retransmission = window. But we don't have any *assurance* that all packets will have = left the network within that time. Gr=FC=DFe, Carsten PS.: My personal record for an RTT actually measured in an in-use, = production IPv4 network with real-world users surfing the Web and = sending email is 385 s. From fluffy@cisco.com Wed Apr 18 10:08:37 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 42FEF21F846D for ; Wed, 18 Apr 2012 10:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.181 X-Spam-Level: X-Spam-Status: No, score=-110.181 tagged_above=-999 required=5 tests=[AWL=0.418, 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 DyDNBDlaP0Io for ; Wed, 18 Apr 2012 10:08:33 -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 1957B21F856A for ; Wed, 18 Apr 2012 10:08:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=278; q=dns/txt; s=iport; t=1334768913; x=1335978513; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=l//wPjZawaNrw9ZgbzkkGvctTcCLTSwmTwk/DzLL74U=; b=J4u+7971ROFX9hXWWthN1Ax1ngipt5TeXBlxtOzfFsT7jG8K3vXTJj8c SIB6jzXWAkPaoWg4sDRwhjMeKrpfuLK73OlEqGoaCTgvn3/LAix7nEi+u XHO5P8R6qnvji3mrH8ydDr8biA+2faxiVIftee9HN+e2ZaEeZ3U0xFx30 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYGANvzjk+rRDoH/2dsb2JhbABEgxyuI4EHggkBAQEDARIBJz8FCxk4VwY1h2gEmw2gG49SYwSIXI0ThXOIXoFpgwaBPQ X-IronPort-AV: E=Sophos;i="4.75,442,1330905600"; d="scan'208";a="41119653" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 18 Apr 2012 17:08:32 +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 q3IH8V9F006740; Wed, 18 Apr 2012 17:08:31 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <7D196561-77B0-411B-96EB-F60504165E05@tzi.org> Date: Wed, 18 Apr 2012 11:08:32 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9E5F67AC-943D-4A97-B19D-313B7194D9AF@cisco.com> <7D196561-77B0-411B-96EB-F60504165E05@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: [core] RTT side topic 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 17:08:37 -0000 On Apr 18, 2012, at 10:41 AM, Carsten Bormann wrote: > PS.: My personal record for an RTT actually measured in an in-use, = production IPv4 network with real-world users surfing the Web and = sending email is 385 s. This sounds fascinating. Can you tell me more.=20= From cabo@tzi.org Wed Apr 18 10: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 296B921F854D for ; Wed, 18 Apr 2012 10:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.334 X-Spam-Level: X-Spam-Status: No, score=-106.334 tagged_above=-999 required=5 tests=[AWL=-0.085, 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 GxDZnXa11+QB for ; Wed, 18 Apr 2012 10:12: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 5328921F8541 for ; Wed, 18 Apr 2012 10:12: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 q3IHCIhb010756; Wed, 18 Apr 2012 19:12:18 +0200 (CEST) Received: from [192.168.217.105] (p5489A708.dip.t-dialin.net [84.137.167.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 15A095ED; Wed, 18 Apr 2012 19:12:18 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <3838EDF5-A1C8-4A4B-833A-F09C76A961C5@iii.ca> Date: Wed, 18 Apr 2012 19:12:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3838EDF5-A1C8-4A4B-833A-F09C76A961C5@iii.ca> To: Cullen Jennings 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: Wed, 18 Apr 2012 17:12:28 -0000 On Apr 18, 2012, at 17:05, Cullen Jennings wrote: > 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 ? The Block2 server cache timeout issue is unrelated to the block ordering = issue -- you can make up an equivalent scenario with the numbers 0, 1, = and 2. To me this sounds like a quality of implementation issue, though. A = server that wants to provide this kind of cache will have to do this = within the space it has. So some will be able to keep it up for = hundreds of seconds, while others will have to discard the cache = earlier. What can we standardize here, except for the clients to plan = for occasional failure? It is probably worth pointing out in the draft that "admitting" each = further client by giving it a new cache (and discarding even relatively = young older caches in the process) is not a winning strategy. Sharing = the cache is better, but limits the rate in which updates can be made = available, to that of the slowest requester. That is only a complete = strategy as long as there is enough space for one cache for each = resource... An so on. Lots of room for policy evolution, no need for = mechanism. Except maybe another error code ("would like to, but can't build cache = for you"). 5.00 might work, though. Gr=FC=DFe, Carsten From fluffy@iii.ca Wed Apr 18 10:29: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 8A8DB11E8081 for ; Wed, 18 Apr 2012 10:29: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 tjAaBjc8-wFG for ; Wed, 18 Apr 2012 10:29:14 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 67DEA21F845C for ; Wed, 18 Apr 2012 10:29:14 -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 14FE422E259; Wed, 18 Apr 2012 13:29:04 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <5BEC4E4C-FF04-44DC-A14B-2FA73E3D573F@tzi.org> Date: Wed, 18 Apr 2012 11:29:04 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2A346094-E537-4536-AE35-7C88D70AC55C@iii.ca> References: <051.e7fbc0f0f5736d305a309a9e8d0cd924@trac.tools.ietf.org> <61887542-A2C0-4DF2-B784-34ABE12E38EF@iii.ca> <5BEC4E4C-FF04-44DC-A14B-2FA73E3D573F@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-core-coap@tools.ietf.org, trac+core@gamay.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 17:29:18 -0000 On Apr 18, 2012, at 10:05 AM, Carsten Bormann wrote: > 2) 270 was deemed too low for the Proxy-Uri option. We now have a = special case just for that, which already has all the unpleasant = properties you describe. Instead of doing another special case for every = new option that might come up, doing this once is more attractive. Or = we might get rid of the Proxy-Uri special case! so my key concern is we have a well defined limit. I'm less concerned = about the value of that limit other than any client knows that the = server will support things up to that limit.=20 But tell my why 270 is too low for Proxy-URI? I'm unconvinced - I will = point out that at there is some argument that goo.gl/x6YHG is about as long a you really need for HTTP URLs. From fluffy@iii.ca Wed Apr 18 10:36: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 BF5D111E8087 for ; Wed, 18 Apr 2012 10:36:35 -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 xUjuvc5uBHlg for ; Wed, 18 Apr 2012 10:36:31 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD1A11E8091 for ; Wed, 18 Apr 2012 10:36:31 -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 5500322E257; Wed, 18 Apr 2012 13:36:30 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <93B860C2-622D-46D4-817D-AB1C37D717D3@koanlogic.com> Date: Wed, 18 Apr 2012 11:36:29 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <93B860C2-622D-46D4-817D-AB1C37D717D3@koanlogic.com> To: Thomas Fossati X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org, Klaus Hartke 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: Wed, 18 Apr 2012 17:36:35 -0000 I'm weakly in favor of keeping 'obs'=20 (but very supportive of the general idea of figuring out what we can get = rid of - so thanks for raising this) On Apr 17, 2012, at 1:19 AM, Thomas Fossati wrote: > I'm waving the flag for poor 'obs' here. >=20 > 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). >=20 > [ 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 :-) ] > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From fluffy@iii.ca Wed Apr 18 11:40: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 AC91D21F84FA; Wed, 18 Apr 2012 11:40:52 -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 F2AIUUFAFLS3; Wed, 18 Apr 2012 11:40:52 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id D3E0821F84EB; Wed, 18 Apr 2012 11:40:51 -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 BBA5B22E25D; Wed, 18 Apr 2012 14:40:44 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <78A0D3BA-5EFE-4AD7-ACD6-56196CB588CF@sensinode.com> Date: Wed, 18 Apr 2012 12:40:43 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <0EAC1438-90B0-459D-8A7B-1C54683E1C0C@iii.ca> References: <4F3D931C.1000101@nostrum.com> <4F3FFB16.6030502@joelhalpern.com> <78A0D3BA-5EFE-4AD7-ACD6-56196CB588CF@sensinode.com> To: Zach Shelby X-Mailer: Apple Mail (2.1084) Cc: gen-art@ietf.org, "Joel M. Halpern" , "A. Jean Mahoney" , core WG Subject: Re: [core] [Gen-art] Review: draft-ietf-core-link-format-11 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 18:40:52 -0000 On Mar 8, 2012, at 5:55 AM, Zach Shelby wrote: >>=20 >> Major issues: >> What is the registration / collision avoidance strategy for = resource type (rt) and interface description (if) values? They are both = defined as opaque strings which can happen to be URIs. So there seems = to be potential for collision. >=20 > There is definitely a possibility for collision for those two = attributes, especially as there will be a mix of specifications that = define specific values to be used, and developers using their own = values. Currently while those are being defined in CoRE drafts we can = avoid collisions, but when other WGs or SDOs start defining them... >=20 > We have deliberated on the idea of defining registries for rt=3D and = if=3D values, but it has not been clear if that should be done in this = document. Recently several CoRE drafts have been written that do specify = well-known values for those fields, so it starts to become obvious that = those registries would be useful. If I understand right, your = recommendation would be that we define those registries in the IANA = section of this document? I would be in favor of doing that. Where are we on resolving topic? This is closely linked with the = registry proposed in senml.=20 From kovatsch@inf.ethz.ch Wed Apr 18 12:19: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 3E2BA21F84D6 for ; Wed, 18 Apr 2012 12:19:06 -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 CL16VgIlKO0u for ; Wed, 18 Apr 2012 12:19:02 -0700 (PDT) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) by ietfa.amsl.com (Postfix) with ESMTP id B33A321F84D3 for ; Wed, 18 Apr 2012 12:19:01 -0700 (PDT) Received: from CAS21.d.ethz.ch (172.31.51.111) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 18 Apr 2012 21:18:58 +0200 Received: from MBX10.d.ethz.ch ([169.254.1.51]) by CAS21.d.ethz.ch ([fe80::55ba:c4a5:d8a7:ab62%10]) with mapi id 14.01.0355.002; Wed, 18 Apr 2012 21:18:59 +0200 From: "Kovatsch Matthias" To: Cullen Jennings , Carsten Bormann Thread-Topic: [core] #202: Remove the 270 byte artificial limit Thread-Index: AQHNHXfKOwTEAqxLy0KL8FjKmBADiZagnb4AgAAXSwCAAD0xAA== Date: Wed, 18 Apr 2012 19:18:58 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B51398E11D@MBX10.d.ethz.ch> References: <051.e7fbc0f0f5736d305a309a9e8d0cd924@trac.tools.ietf.org> <61887542-A2C0-4DF2-B784-34ABE12E38EF@iii.ca> <5BEC4E4C-FF04-44DC-A14B-2FA73E3D573F@tzi.org> <2A346094-E537-4536-AE35-7C88D70AC55C@iii.ca> In-Reply-To: <2A346094-E537-4536-AE35-7C88D70AC55C@iii.ca> Accept-Language: en-US, de-CH Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [178.83.15.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-core-coap@tools.ietf.org" , "trac+core@gamay.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 19:19:06 -0000 > goo.gl/x6YHG >=20 > is about as long a you really need for HTTP URLs. This is like going back to ZigBee's binary cluster identifiers. People are, however, pretty bad in handling this machine gibberish and thus= need a long time to understand the components and to integrate systems. Th= is is why self-descriptive URIs are so nice and in turn why the Web took of= f as it did. =09 Regards Matthias From zach@sensinode.com Wed Apr 18 13:06: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 B0D1D21F8460; Wed, 18 Apr 2012 13:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 SO8pEaxitGMU; Wed, 18 Apr 2012 13:06:28 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 8649121F8462; Wed, 18 Apr 2012 13:06:28 -0700 (PDT) Received: from [192.168.1.102] (188-67-41-63.bb.dnainternet.fi [188.67.41.63]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q3IK6Nit008913; Wed, 18 Apr 2012 23:06:24 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <0EAC1438-90B0-459D-8A7B-1C54683E1C0C@iii.ca> Date: Wed, 18 Apr 2012 23:06:23 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <19A8C610-C350-44E1-8DCA-275FF3BD19D1@sensinode.com> References: <4F3D931C.1000101@nostrum.com> <4F3FFB16.6030502@joelhalpern.com> <78A0D3BA-5EFE-4AD7-ACD6-56196CB588CF@sensinode.com> <0EAC1438-90B0-459D-8A7B-1C54683E1C0C@iii.ca> To: Cullen Jennings X-Mailer: Apple Mail (2.1084) Cc: gen-art@ietf.org, "Joel M. Halpern" , "A. Jean Mahoney" , core WG Subject: Re: [core] [Gen-art] Review: draft-ietf-core-link-format-11 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 20:06:34 -0000 On Apr 18, 2012, at 9:40 PM, Cullen Jennings wrote: >=20 > On Mar 8, 2012, at 5:55 AM, Zach Shelby wrote: >=20 >>>=20 >>> Major issues: >>> What is the registration / collision avoidance strategy for = resource type (rt) and interface description (if) values? They are both = defined as opaque strings which can happen to be URIs. So there seems = to be potential for collision. >>=20 >> There is definitely a possibility for collision for those two = attributes, especially as there will be a mix of specifications that = define specific values to be used, and developers using their own = values. Currently while those are being defined in CoRE drafts we can = avoid collisions, but when other WGs or SDOs start defining them... >>=20 >> We have deliberated on the idea of defining registries for rt=3D and = if=3D values, but it has not been clear if that should be done in this = document. Recently several CoRE drafts have been written that do specify = well-known values for those fields, so it starts to become obvious that = those registries would be useful. If I understand right, your = recommendation would be that we define those registries in the IANA = section of this document? I would be in favor of doing that. >=20 > Where are we on resolving topic? This is closely linked with the = registry proposed in senml.=20 Yes, it is being resolved in Ticket #195. I am adding both registries = following the same style as the relation registry in RFC5988.=20 http://trac.tools.ietf.org/wg/core/trac/ticket/195 The only action point right now is for me to update the draft closing = this and the other tickets. Zach --=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 esko.dijk@philips.com Wed Apr 18 13:37: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 0389F21F84E7 for ; Wed, 18 Apr 2012 13:37: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 P2SUkgCfTjjU for ; Wed, 18 Apr 2012 13:37:47 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id E91C521F84E1 for ; Wed, 18 Apr 2012 13:37:46 -0700 (PDT) Received: from mail169-ch1-R.bigfish.com (10.43.68.247) by CH1EHSOBE016.bigfish.com (10.43.70.66) with Microsoft SMTP Server id 14.1.225.23; Wed, 18 Apr 2012 20:37:46 +0000 Received: from mail169-ch1 (localhost [127.0.0.1]) by mail169-ch1-R.bigfish.com (Postfix) with ESMTP id 4BC2234053F; Wed, 18 Apr 2012 20:37:46 +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 mail169-ch1 (localhost.localdomain [127.0.0.1]) by mail169-ch1 (MessageSwitch) id 1334781464458355_4781; Wed, 18 Apr 2012 20:37:44 +0000 (UTC) Received: from CH1EHSMHS001.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.226]) by mail169-ch1.bigfish.com (Postfix) with ESMTP id 6CF524C00EE; Wed, 18 Apr 2012 20:37:44 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CH1EHSMHS001.bigfish.com (10.43.70.1) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 18 Apr 2012 20:37:43 +0000 Received: from 011-DB3MPN1-013.MGDPHG.emi.philips.com ([169.254.3.240]) by 011-DB3MMR1-011.MGDPHG.emi.philips.com ([10.128.28.50]) with mapi id 14.01.0355.003; Wed, 18 Apr 2012 21:37:42 +0100 From: "Dijk, Esko" To: "matthieu.vial@non.schneider-electric.com" , Carsten Bormann Thread-Topic: [core] draft-ietf-core-block-08 - multicast Thread-Index: AQHNHGyQSMM09+CguEqSZiSaRLjQT5afDZ0ggAAAi4CAAR4xAIAA1USQ Date: Wed, 18 Apr 2012 20:40:26 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618093C38@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: [86.94.216.29] Content-Type: text/plain; charset="us-ascii" 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 - 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 20:37:51 -0000 Maybe I could check a number of core-block + multicast use cases to see if = special support is needed? A first case: for a GET like in Fig 2 of section 3, but sent in multicast t= o a group of servers, some servers may send the last block earlier than oth= ers because of different resource sizes. These servers (with relatively sma= ll resource size) will get requests for block numbers that are too high / o= ut of range. Then the discussion "GETs beyond resource size" (http://www.ietf.org/mail-a= rchive/web/core/current/msg02595.html ) becomes relevant except that the cl= ient really can't avoid sending such requests beyond resource size like it = could in unicast. Another case: a GET like in Fig 3 of section 3, but now multicast again to = a group by the client. Suppose server S1 responds with Block option 2/0/1/6= 4, while server S2 responds with 2/0/1/32. The draft states: "The server SHOULD use the block size indicated in the request option or a smaller size, but the requester MUST take note of the actual block size used in the response it receives to its initial request and proceed to use it in subsequent requests." Now S1 assumes that client MUST use size 64 in subsequent requests, while S= 2 assumes that client MUST use size 32 - an issue. (Maybe the client could go for the lowest size returned over all servers in= the group; but this needs changes in functionality) Another point is that multicast uses NON messages, which presumably causes = a different timing and interaction pattern than the existing examples in -b= lock. E.g. there's no retry of CON due to missing ACK on the one hand, but on the= other hand a client has to retry the same NON to get the data blocks. The current text raises a bit of the question "can I use NON in the first p= lace?" and if so, any special timing/interaction patterns or is it simply t= he same as the pattern with CON/ACK (but then instead using NON/NON message= s)? There may be some more things raised by checking PUT/POST/DELETE cases or c= ases where some server(s) responds relatively late with block-size preferen= ces. Esko -----Original Message----- From: matthieu.vial@non.schneider-electric.com [mailto:matthieu.vial@non.sc= hneider-electric.com] Sent: Wednesday 18 April 2012 10:12 To: Carsten Bormann Cc: core@ietf.org; Dijk, Esko Subject: Re: [core] draft-ietf-core-block-08 - multicast 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 ________________________________ 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 Thu Apr 19 00:07: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 30FEC11E8076 for ; Thu, 19 Apr 2012 00:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.877 X-Spam-Level: X-Spam-Status: No, score=-2.877 tagged_above=-999 required=5 tests=[AWL=0.100, 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 k-uXP8AT9Naq for ; Thu, 19 Apr 2012 00:06:59 -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 C7C7321F84C4 for ; Thu, 19 Apr 2012 00:06:58 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so5608447wgb.13 for ; Thu, 19 Apr 2012 00:06: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=f89bfcdUK2pygZfgeuYOVS89ON6cZwt1yRHhgmDcOSI=; b=XHrBzFeH9HTbQ2dan8w1vcg+GCSZsuVpmXsj+au9RI7tdrNYc9qZrpvraKsnL58ODj EMKH9GYV2QYaSGeZu5H2T1sfToeAfoqkOyOrOKRb/G+L1vX1SZ+JWYLK0RnGnd8tTCNJ uoqiCt7NCf6hM9wHAeNzS1rCQPFxLtEpZa0IaGk93RKOVl398MZMC+6jviAFZIXtyorp jdi755XLurz6ERuqTLVSjYkBMZUUxG2twWz38B4d17TjOkp76weivX+pM4SKgM3pBTYF 86mSFs2mA//goWkT8X5rAS1K+SQCfzh88IOCBjHJcR1sJYVItDxlJbwQOW5fMNciW5bl CGYw== Received: by 10.216.132.202 with SMTP id o52mr575591wei.106.1334819217834; Thu, 19 Apr 2012 00:06:57 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.214.20 with HTTP; Thu, 19 Apr 2012 00:06:42 -0700 (PDT) In-Reply-To: References: From: "Angelo P. Castellani" Date: Thu, 19 Apr 2012 09:06:42 +0200 X-Google-Sender-Auth: Y91MgqWBpYMSRBjf6lQ1FRr--G4 Message-ID: To: Cullen Jennings 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: Thu, 19 Apr 2012 07:07:02 -0000 On Wed, Apr 18, 2012 at 17:13, Cullen Jennings wrote: > The setting of these values is a classic case where we want to avoid trag= edy 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. +1 From dromasca@avaya.com Thu Apr 19 01:41:29 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 5E9E721F85ED for ; Thu, 19 Apr 2012 01:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.432 X-Spam-Level: X-Spam-Status: No, score=-103.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 hSuMvrqjD36e for ; Thu, 19 Apr 2012 01:41:25 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 3118F21F85E4 for ; Thu, 19 Apr 2012 01:41:25 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAMbOj0/GmAcF/2dsb2JhbABDsUqBB4IJAQEBAQMBAQEPHgo0FwQCAQgNAQMEAQELBgwLAQYBJh8JCAEBBAESCBqHbQudHZ1BBI9SYwScBIolgmmBWg X-IronPort-AV: E=Sophos;i="4.75,445,1330923600"; d="scan'208";a="302613273" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 19 Apr 2012 04:41:21 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 19 Apr 2012 04:39:12 -0400 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, 19 Apr 2012 10:41:20 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Next Steps Thread-Index: Ac0dcK50qrDZqBV5SKWX8FM1N7x4EQAlxHxw References: From: "Romascanu, Dan (Dan)" To: "Cullen Jennings" , Subject: Re: [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: Thu, 19 Apr 2012 08:41:29 -0000 Hi Cullen, By 'a few hour call phone call' you mean a virtual interim?=20 Dan > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of > Cullen Jennings > Sent: Wednesday, April 18, 2012 5:37 PM > To: core@ietf.org WG > Subject: [core] Next Steps >=20 >=20 > This email with my co-chair hat on ... >=20 > 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. >=20 > 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 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From esko.dijk@philips.com Thu Apr 19 02:34: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 4E52D21F84EE for ; Thu, 19 Apr 2012 02:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.072 X-Spam-Level: X-Spam-Status: No, score=-4.072 tagged_above=-999 required=5 tests=[AWL=-0.473, 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 1dZ1WAOdNm-j for ; Thu, 19 Apr 2012 02:34:22 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe004.messaging.microsoft.com [213.199.154.142]) by ietfa.amsl.com (Postfix) with ESMTP id E2BCB21F84CD for ; Thu, 19 Apr 2012 02:34:21 -0700 (PDT) Received: from mail97-db3-R.bigfish.com (10.3.81.236) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.23; Thu, 19 Apr 2012 09:34:21 +0000 Received: from mail97-db3 (localhost [127.0.0.1]) by mail97-db3-R.bigfish.com (Postfix) with ESMTP id 1A1734A08A4; Thu, 19 Apr 2012 09:34:21 +0000 (UTC) X-SpamScore: -39 X-BigFish: VPS-39(zz217bL15d6O9251J542M4015Izz1202hzz1033IL8275dhz2dh2a8h668h839h944hd25h) 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 mail97-db3 (localhost.localdomain [127.0.0.1]) by mail97-db3 (MessageSwitch) id 1334828058676418_22361; Thu, 19 Apr 2012 09:34:18 +0000 (UTC) Received: from DB3EHSMHS009.bigfish.com (unknown [10.3.81.250]) by mail97-db3.bigfish.com (Postfix) with ESMTP id A08EF1E0076; Thu, 19 Apr 2012 09:34:18 +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, 19 Apr 2012 09:34:13 +0000 Received: from 011-DB3MPN1-012.MGDPHG.emi.philips.com ([169.254.2.189]) by 011-DB3MMR1-008.MGDPHG.emi.philips.com ([10.128.28.47]) with mapi id 14.01.0355.003; Thu, 19 Apr 2012 10:34:13 +0100 From: "Dijk, Esko" To: Cullen Jennings , "core@ietf.org WG" Thread-Topic: [core] Next Steps Thread-Index: AQHNHXEQPpntzzwB906676y9OPFcKpah4z6A Date: Thu, 19 Apr 2012 09:36:57 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED61809CEE9@011-DB3MPN1-012.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] 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: Thu, 19 Apr 2012 09:34:26 -0000 Ok for me; if the 'list' can be made available some time before the call. (= E.g. >=3D 2 working days) thanks, Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Cul= len Jennings Sent: Wednesday 18 April 2012 16:37 To: core@ietf.org WG Subject: [core] Next Steps 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 su= ggestions but here is my straw man suggestion. The authors go thought the c= omments received and pick out the ones that they don't understand or ones t= he do not think there is general agreement with and form a list of those. T= hen we have a few hour phone call to work through them. This may take a ser= ies of phone calls. After that, I hope the authors can update the draft wit= h 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 lo= ng as we do something that moves the ball forward. If this sounds reasonabl= e, I'll start a doodle poll to pick a time for a phone call. Thanks, Cullen _______________________________________________ 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 19 02: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 D2D6621F8469 for ; Thu, 19 Apr 2012 02:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.532 X-Spam-Level: X-Spam-Status: No, score=-1.532 tagged_above=-999 required=5 tests=[AWL=-2.933, BAYES_00=-2.599, GB_SUMOF=5, 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 M09uyeT2q3-Z for ; Thu, 19 Apr 2012 02:54:08 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe005.messaging.microsoft.com [213.199.154.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8795121F845B for ; Thu, 19 Apr 2012 02:54:07 -0700 (PDT) Received: from mail96-db3-R.bigfish.com (10.3.81.226) by DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id 14.1.225.23; Thu, 19 Apr 2012 09:54:06 +0000 Received: from mail96-db3 (localhost [127.0.0.1]) by mail96-db3-R.bigfish.com (Postfix) with ESMTP id 6F31E20A23; Thu, 19 Apr 2012 09:54:06 +0000 (UTC) X-SpamScore: -38 X-BigFish: VPS-38(zz217bL15d6O9251Jc89bh542Mzz1202hzz1033IL8275dhz2dh2a8h668h839hd25h) 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 mail96-db3 (localhost.localdomain [127.0.0.1]) by mail96-db3 (MessageSwitch) id 1334829244745122_5486; Thu, 19 Apr 2012 09:54:04 +0000 (UTC) Received: from DB3EHSMHS007.bigfish.com (unknown [10.3.81.247]) by mail96-db3.bigfish.com (Postfix) with ESMTP id B332A460096; Thu, 19 Apr 2012 09:54:04 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by DB3EHSMHS007.bigfish.com (10.3.87.107) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 19 Apr 2012 09:54:04 +0000 Received: from 011-DB3MPN1-012.MGDPHG.emi.philips.com ([169.254.2.189]) by 011-DB3MMR1-003.MGDPHG.emi.philips.com ([10.128.28.53]) with mapi id 14.01.0355.003; Thu, 19 Apr 2012 10:56:49 +0100 From: "Dijk, Esko" To: Carsten Bormann , "Angelo P. Castellani" Thread-Topic: [core] WGLC draft-ietf-core-coap-09 Reuse of MID Thread-Index: AQHNHR++JtMDpg7JdU2judUzexJQvpagHHkAgACEqoCAAAHJAIAAFlcAgAEuSjA= Date: Thu, 19 Apr 2012 09:56:48 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED61809CF08@011-DB3MPN1-012.MGDPHG.emi.philips.com> References: <9E5F67AC-943D-4A97-B19D-313B7194D9AF@cisco.com> <7D196561-77B0-411B-96EB-F60504165E05@tzi.org> In-Reply-To: <7D196561-77B0-411B-96EB-F60504165E05@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: Cullen Jennings , 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: Thu, 19 Apr 2012 09:54:11 -0000 The RAM reduction strategy of 3.4.2.3 in draft-bormann-lwig-guidance-01 is = more successful, the more CoAP end-points use sequential MIDs. Hence my previous proposals to mention sequential MIDs and potential benefi= ts in core-coap (see thread http://www.ietf.org/mail-archive/web/core/current/msg02517.html= ). A SHOULD requirement for sequential MIDs was found too strong by the WG, a = MAY requirement is very weak but at least mentions the point. The discussion on the MAY is in my view not yet concluded, so if not pursue= d on the ML could we add this to the list for the WG interim meeting? Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Car= sten Bormann Sent: Wednesday 18 April 2012 18:42 To: Angelo P. Castellani Cc: Cullen Jennings; core WG Subject: Re: [core] WGLC draft-ietf-core-coap-09 Reuse of MID Well, both client and server need to process the MID. Let "awhile1" be the time constant that is equivalent to TCP's "2 MSL", i.e= . the sum of the maximum latency we expect on the way forward and the maxim= um latency. "awhile0" is just the difference between minimum and maximum forward latenc= y ("MSL" for all intents and purposes). "retransmission window" is awhile1 + the maximum time between the first and= the last transmission in a CON retransmission sequence. (There is also a = related number that can be built from awhile0.) It is relatively easy for the emitter of a CON/NON to choose non-conflictin= g MIDs, unless it sends at a rate of more than 65536/"retransmission window= " messages from/to the same endpoint, or it forgets its state and comes up = again before retransmission window expires: just keep a number (per endpoin= t pair, or if 65536/retrwin is enough for this, even for the entire client)= , and increment it per message use. The duplicate detection at the receiver is more work. One strategy for thi= s is discussed in 3.4.2.3 in draft-bormann-lwig-guidance-01.txt. As Esko n= otes there, this is easier if the emitter uses the "sequential" (i.e., one = counter per peer end-point) strategy. If we want to standardize MSL values, we need to consider sleeping nodes. Where a node is aware (e.g., on L2) of the sleep schedule of the next-hop n= ode, it may buffer a packet for quite some time. There is *no* reasonable = upper bound for this. However, traditional IP-based protocols become less = useful once this storage time exceeds a couple of minutes. Hence my shot i= n the dark of "256 s" for the retransmission window. But we don't have any= *assurance* that all packets will have left the network within that time. Gr=FC=DFe, Carsten PS.: My personal record for an RTT actually measured in an in-use, producti= on IPv4 network with real-world users surfing the Web and sending email is = 385 s. _______________________________________________ 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 Thu Apr 19 02:58: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 1160F21F8568 for ; Thu, 19 Apr 2012 02:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.332 X-Spam-Level: X-Spam-Status: No, score=-106.332 tagged_above=-999 required=5 tests=[AWL=-0.083, 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 xVGqIoGVuCPd for ; Thu, 19 Apr 2012 02:58: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 408A021F8491 for ; Thu, 19 Apr 2012 02:58: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 q3J9wKN2009405; Thu, 19 Apr 2012 11:58:20 +0200 (CEST) Received: from [192.168.217.105] (p5489A708.dip.t-dialin.net [84.137.167.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C567D8A7; Thu, 19 Apr 2012 11:58:19 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <031DD135F9160444ABBE3B0C36CED61809CF08@011-DB3MPN1-012.MGDPHG.emi.philips.com> Date: Thu, 19 Apr 2012 11:58:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <407DE5C2-0B90-4487-AE44-D8B9601486DD@tzi.org> References: <9E5F67AC-943D-4A97-B19D-313B7194D9AF@cisco.com> <7D196561-77B0-411B-96EB-F60504165E05@tzi.org> <031DD135F9160444ABBE3B0C36CED61809CF08@011-DB3MPN1-012.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1257) Cc: Cullen Jennings , 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: Thu, 19 Apr 2012 09:58:35 -0000 > could we add this to the list for the WG interim meeting? (this =3D implementation note to encourage sequential MIDs) I will make a ticket. I expect that Klaus and I will make on the order of 200 tickets in the = next 48 hours. We should work on closing as many as possible on the list; otherwise = this will be a very long phone call :-) Gr=FC=DFe, Carsten From trac+core@trac.tools.ietf.org Thu Apr 19 04:03: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 8A77121F85C5 for ; Thu, 19 Apr 2012 04:03:38 -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 TA5qGlH6NxlL for ; Thu, 19 Apr 2012 04:03:34 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 9717A21F85D5 for ; Thu, 19 Apr 2012 04:03:31 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SKp8s-0000zC-FQ; Thu, 19 Apr 2012 07:03:14 -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: Thu, 19 Apr 2012 11:03:13 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/212 Message-ID: <051.4e6cdfc507a23a9b28c6274a5b955113@trac.tools.ietf.org> X-Trac-Ticket-ID: 212 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: <20120419110331.9717A21F85D5@ietfa.amsl.com> Resent-Date: Thu, 19 Apr 2012 04:03:31 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #212: Option numbers 14, 28, 42, ... reserved but usable 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: Thu, 19 Apr 2012 11:03:38 -0000 #212: Option numbers 14, 28, 42, ... reserved but usable 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. -> Clarify that while the positive option numbers divisible by 14 are indeed reserved, they still are available for allocation as long as a zero-length option with each of these numbers remains available as a no-operation option for fenceposting. (msg03034a, also covers msg03072cc) -- -----------------------------+------------------------------------ Reporter: cabo@… | Owner: draft-ietf-core-coap@… Type: editorial | Status: new Priority: minor | Milestone: post-WGLC-1 Component: coap | Version: coap-09 Severity: In WG Last Call | Keywords: -----------------------------+------------------------------------ Ticket URL: core From trac+core@trac.tools.ietf.org Thu Apr 19 04:10: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 5104D21F85C5 for ; Thu, 19 Apr 2012 04:10:40 -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 ozVFYUgCdYOi for ; Thu, 19 Apr 2012 04:10:35 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 3D27421F85B1 for ; Thu, 19 Apr 2012 04:10:34 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SKpFm-0002Dm-Ua; Thu, 19 Apr 2012 07:10:22 -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: Thu, 19 Apr 2012 11:10:22 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/213 Message-ID: <051.f64d92d9c3856bce4b514a7bba1d49af@trac.tools.ietf.org> X-Trac-Ticket-ID: 213 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: <20120419111035.3D27421F85B1@ietfa.amsl.com> Resent-Date: Thu, 19 Apr 2012 04:10:34 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #213: Path/Query options minimum length 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: Thu, 19 Apr 2012 11:10:40 -0000 #213: Path/Query options minimum length 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. (RFC 3986 is quite clear that segment = *pchar i.e., a segment can have zero or more pchars. For example, a zero-length path segment is needed to differentiate coap://example.com/a/ from coap://example.com/a ) -- -----------------------------+------------------------------------ Reporter: cabo@… | Owner: draft-ietf-core-coap@… Type: protocol defect | Status: new Priority: minor | Milestone: post-WGLC-1 Component: coap | Version: coap-09 Severity: In WG Last Call | Keywords: -----------------------------+------------------------------------ Ticket URL: core From trac+core@trac.tools.ietf.org Thu Apr 19 04: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 5255E21F849B for ; Thu, 19 Apr 2012 04:27:24 -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 I2QMA8D5V6Wy for ; Thu, 19 Apr 2012 04:27:20 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 320DA21F8577 for ; Thu, 19 Apr 2012 04:27:19 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SKpVy-0006GM-Sa; Thu, 19 Apr 2012 07:27:06 -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: Thu, 19 Apr 2012 11:27:06 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/214 Message-ID: <051.09186ada57b912f27c3147c188e4fd71@trac.tools.ietf.org> X-Trac-Ticket-ID: 214 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: <20120419112720.320DA21F8577@ietfa.amsl.com> Resent-Date: Thu, 19 Apr 2012 04:27:19 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #214: Adopt vendor-defined option into core-coap 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: Thu, 19 Apr 2012 11:27:24 -0000 #214: Adopt vendor-defined option into core-coap Alper Yegin (http://www.ietf.org/mail- archive/web/core/current/msg02958.html): I recommend we migrate Section 3. Vendor-defined Options of coap-misc I-D into core-coap I-D. ➔ This would then become 5.10.11. -- ----------------------------------+------------------------------------ Reporter: cabo@… | Owner: draft-ietf-core-coap@… Type: protocol enhancement | Status: new Priority: minor | Milestone: post-WGLC-1 Component: coap | Version: coap-09 Severity: In WG Last Call | Keywords: ----------------------------------+------------------------------------ Ticket URL: core From trac+core@trac.tools.ietf.org Thu Apr 19 04:30: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 1198821F85E3 for ; Thu, 19 Apr 2012 04:30:35 -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 Bn5B4tbVEwK3 for ; Thu, 19 Apr 2012 04:30:31 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id E06E521F84E1 for ; Thu, 19 Apr 2012 04:30:30 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SKpZE-00080a-7n; Thu, 19 Apr 2012 07:30:28 -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: Thu, 19 Apr 2012 11:30:28 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/208#comment:1 Message-ID: <066.60c51412d72fbc8070daf17966dc4dbb@trac.tools.ietf.org> References: <051.84365211a7b3ff2c11cb254d636ac5ca@trac.tools.ietf.org> X-Trac-Ticket-ID: 208 In-Reply-To: <051.84365211a7b3ff2c11cb254d636ac5ca@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: <20120419113030.E06E521F84E1@ietfa.amsl.com> Resent-Date: Thu, 19 Apr 2012 04:30:30 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [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: Thu, 19 Apr 2012 11:30:35 -0000 #208: Fix editing error in 5.10.2 Changes (by cabo@…): * status: new => closed * resolution: => fixed Comment: Fixed in [557]: Fix #208 -- -----------------------------+------------------------------------- Reporter: cabo@… | Owner: draft-ietf-core-coap@… Type: editorial | Status: closed Priority: minor | Milestone: post-WGLC-1 Component: coap | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+------------------------------------- Ticket URL: core From Akbar.Rahman@InterDigital.com Thu Apr 19 06:32: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 454F621F85DF for ; Thu, 19 Apr 2012 06:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, 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 A3I+PfLQlIDH for ; Thu, 19 Apr 2012 06:32:42 -0700 (PDT) Received: from idcout.InterDigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7D421F85D9 for ; Thu, 19 Apr 2012 06:32:41 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Apr 2012 09:32:41 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 19 Apr 2012 09:32:40 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Next Steps Thread-Index: Ac0dcK45qVs5GKoxSHiGJ2vcWg5KFwAwCVZg References: From: "Rahman, Akbar" To: "Cullen Jennings" X-OriginalArrivalTime: 19 Apr 2012 13:32:41.0520 (UTC) FILETIME=[E523BB00:01CD1E30] Cc: core@ietf.org Subject: Re: [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: Thu, 19 Apr 2012 13:32:46 -0000 Hi Cullen, Seems like a good approach. Akbar -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Wednesday, April 18, 2012 10:37 AM To: core@ietf.org WG Subject: [core] Next Steps 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 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From fluffy@cisco.com Thu Apr 19 07:04: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 0943921F862B for ; Thu, 19 Apr 2012 07:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.233 X-Spam-Level: X-Spam-Status: No, score=-110.233 tagged_above=-999 required=5 tests=[AWL=0.366, 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 TX4nQkuZxqoA for ; Thu, 19 Apr 2012 07:03:59 -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 A005521F8631 for ; Thu, 19 Apr 2012 07:03:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1712; q=dns/txt; s=iport; t=1334844239; x=1336053839; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=8FOiNyAgGeRI2vbqPA26yhtmy9jpxYwo0gdjdsFvSGs=; b=RAF/nHpMDeJC0mygrh22v8mRclJBDvR/6Puu+JFwsZcT9Q++AyT/oic0 fMtTVYHwaFc9plNWgyc1qQX3N5006PM+fBcgU2OwsPqBzMbkZQXsdO3EF kHymUM5BhQrHFnERdWxMo26jgOYTn12IvjpHbJEp6uXNUy6ZH1EWa6oEP I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlAGAEQakE+rRDoG/2dsb2JhbABDgxyuJoEHggkBAQEDAQEBAQ8BJzQLBQcECxEEAQEoBycfCQgGEyKHaAQMmjOgOASPWmMEiFyNE4V0iF6BaYMGgT0 X-IronPort-AV: E=Sophos;i="4.75,446,1330905600"; d="scan'208";a="41171344" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 19 Apr 2012 14:03:59 +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 q3JE3wZC017323; Thu, 19 Apr 2012 14:03:58 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Thu, 19 Apr 2012 08:03:59 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Romascanu, Dan (Dan)" X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org Subject: Re: [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: Thu, 19 Apr 2012 14:04:04 -0000 Yes ... and I have to go find the rules on how far in advance I need to = announce it :-) On Apr 19, 2012, at 2:41 AM, Romascanu, Dan (Dan) wrote: > Hi Cullen, >=20 > By 'a few hour call phone call' you mean a virtual interim?=20 >=20 > Dan >=20 >=20 >=20 >=20 >> -----Original Message----- >> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf > Of >> Cullen Jennings >> Sent: Wednesday, April 18, 2012 5:37 PM >> To: core@ietf.org WG >> Subject: [core] Next Steps >>=20 >>=20 >> This email with my co-chair hat on ... >>=20 >> 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. >>=20 >> 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 >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From cabo@tzi.org Thu Apr 19 07: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 A323121F863D for ; Thu, 19 Apr 2012 07:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.33 X-Spam-Level: X-Spam-Status: No, score=-106.33 tagged_above=-999 required=5 tests=[AWL=-0.081, 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 ivPLSM8YikhL for ; Thu, 19 Apr 2012 07:05: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 6E40D21F863E for ; Thu, 19 Apr 2012 07:05: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 q3JE5Iu4012316 for ; Thu, 19 Apr 2012 16:05:18 +0200 (CEST) Received: from [192.168.217.105] (p54899A0A.dip.t-dialin.net [84.137.154.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 76ACCAF3; Thu, 19 Apr 2012 16:05:18 +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, 19 Apr 2012 16:05:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7AC5EB28-8D28-40B6-9FE8-4D685F434E79@tzi.org> References: To: Klaus Hartke X-Mailer: Apple Mail (2.1257) Cc: core@ietf.org Subject: Re: [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: Thu, 19 Apr 2012 14:05:27 -0000 On Apr 17, 2012, at 03:47, Klaus Hartke wrote: > Why is the Content-Type Option critical and not elective? Because you can't understand (the payload and thus) the message without = understanding the content-type? The distinction is kind of moot as it is hard to imagine an = implementation that does not handle content-type. What would be good arguments to make it elective? Gr=FC=DFe, Carsten From fluffy@iii.ca Thu Apr 19 07:11: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 2C8DB21F861C for ; Thu, 19 Apr 2012 07:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, GB_SUMOF=5] 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 0E897-Xr76HT for ; Thu, 19 Apr 2012 07:11:33 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 7B98821F860F for ; Thu, 19 Apr 2012 07:11:33 -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 685AA22E25F; Thu, 19 Apr 2012 10:11:26 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: <7D196561-77B0-411B-96EB-F60504165E05@tzi.org> Date: Thu, 19 Apr 2012 08:11:26 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <6C22C05A-F22E-4E09-BF05-E65ECA85ACBD@iii.ca> References: <9E5F67AC-943D-4A97-B19D-313B7194D9AF@cisco.com> <7D196561-77B0-411B-96EB-F60504165E05@tzi.org> 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: Thu, 19 Apr 2012 14:11:34 -0000 On Apr 18, 2012, at 10:41 AM, Carsten Bormann wrote: > Well, both client and server need to process the MID. >=20 > Let "awhile1" be the time constant that is equivalent to TCP's "2 = MSL", i.e. the sum of the maximum latency we expect on the way forward = and the maximum latency. > "awhile0" is just the difference between minimum and maximum forward = latency ("MSL" for all intents and purposes). > "retransmission window" is awhile1 + the maximum time between the = first and the last transmission in a CON retransmission sequence. = (There is also a related number that can be built from awhile0.) >=20 > It is relatively easy for the emitter of a CON/NON to choose = non-conflicting MIDs, unless it sends at a rate of more than = 65536/"retransmission window" messages from/to the same endpoint, or it = forgets its state and comes up again before retransmission window = expires: just keep a number (per endpoint pair, or if 65536/retrwin is = enough for this, even for the entire client), and increment it per = message use. >=20 > The duplicate detection at the receiver is more work. One strategy = for this is discussed in 3.4.2.3 in draft-bormann-lwig-guidance-01.txt. = As Esko notes there, this is easier if the emitter uses the "sequential" = (i.e., one counter per peer end-point) strategy. >=20 > If we want to standardize MSL values, we need to consider sleeping = nodes. > Where a node is aware (e.g., on L2) of the sleep schedule of the = next-hop node, it may buffer a packet for quite some time. There is = *no* reasonable upper bound for this. However, traditional IP-based = protocols become less useful once this storage time exceeds a couple of = minutes. Hence my shot in the dark of "256 s" for the retransmission = window. But we don't have any *assurance* that all packets will have = left the network within that time. >=20 > Gr=FC=DFe, Carsten OK, but what I am reading here is it's broken if you don't wait long = enough. And there is no upper bound on how long, long enough is. The = logical conclusion is this sounds broken and we are going to need to = constrain something to be able to solve this.=20 My natural tendency is the thing to break is the idea that nodes will = buffer packets for long periods of time waiting to deliver them to a = sleeping node. I can see that working in something like an ATM network = but I think that is likely to break too many assumptions of an IP = network.=20 From cabo@tzi.org Thu Apr 19 07:21: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 A1B0921F864E for ; Thu, 19 Apr 2012 07:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.328 X-Spam-Level: X-Spam-Status: No, score=-106.328 tagged_above=-999 required=5 tests=[AWL=-0.079, 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 6GRpIomCYfbA for ; Thu, 19 Apr 2012 07:21: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 CD9C821F864D for ; Thu, 19 Apr 2012 07:21: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 q3JEL5eu021198; Thu, 19 Apr 2012 16:21:05 +0200 (CEST) Received: from [192.168.217.105] (p54899A0A.dip.t-dialin.net [84.137.154.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 430D8B1A; Thu, 19 Apr 2012 16:21: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: <6C22C05A-F22E-4E09-BF05-E65ECA85ACBD@iii.ca> Date: Thu, 19 Apr 2012 16:21:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <819CF97B-25C9-4867-A149-E10E08BFDC88@tzi.org> References: <9E5F67AC-943D-4A97-B19D-313B7194D9AF@cisco.com> <7D196561-77B0-411B-96EB-F60504165E05@tzi.org> <6C22C05A-F22E-4E09-BF05-E65ECA85ACBD@iii.ca> 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: Thu, 19 Apr 2012 14:21:15 -0000 > OK, but what I am reading here is it's broken if you don't wait long = enough. And there is no upper bound on how long, long enough is. The = logical conclusion is this sounds broken and we are going to need to = constrain something to be able to solve this.=20 Yes. All I was trying to say was that "awhile1 =3D 20 s" may be an = order of magnitude too low. > My natural tendency is the thing to break is the idea that nodes will = buffer packets for long periods of time waiting to deliver them to a = sleeping node. I can see that working in something like an ATM network = but I think that is likely to break too many assumptions of an IP = network.=20 Right. Almost nothing we do over IP today continues to work when you = suddenly get these long-term sleeper IP packets. (TTL used to be a = "time to live" and was 8-bit... This thinking is heavily ingrained in = our protocols.) So nodes that buffer for more than ~ 1e2 seconds may = need to participate in the application protocols instead. Good that we = have the proxy model in CoRE to make this possible... But I stick to the order of magnitude in my "256 s" strawman. Gr=FC=DFe, Carsten From esko.dijk@philips.com Thu Apr 19 08:16: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 0CA4E21F8623 for ; Thu, 19 Apr 2012 08:16:18 -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 C3YmfJpSnkbE for ; Thu, 19 Apr 2012 08:16:13 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id B8A3521F85A4 for ; Thu, 19 Apr 2012 08:16:12 -0700 (PDT) Received: from mail50-ch1-R.bigfish.com (10.43.68.238) by CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id 14.1.225.23; Thu, 19 Apr 2012 15:16:11 +0000 Received: from mail50-ch1 (localhost [127.0.0.1]) by mail50-ch1-R.bigfish.com (Postfix) with ESMTP id 2CB1F46034C; Thu, 19 Apr 2012 15:16:11 +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 mail50-ch1 (localhost.localdomain [127.0.0.1]) by mail50-ch1 (MessageSwitch) id 1334848568836777_19515; Thu, 19 Apr 2012 15:16:08 +0000 (UTC) Received: from CH1EHSMHS009.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.228]) by mail50-ch1.bigfish.com (Postfix) with ESMTP id B1F0B100139; Thu, 19 Apr 2012 15:16:08 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CH1EHSMHS009.bigfish.com (10.43.70.9) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 19 Apr 2012 15:16:07 +0000 Received: from 011-DB3MPN1-012.MGDPHG.emi.philips.com ([169.254.2.189]) by 011-DB3MMR1-003.MGDPHG.emi.philips.com ([10.128.28.53]) with mapi id 14.01.0355.003; Thu, 19 Apr 2012 16:18:51 +0100 From: "Dijk, Esko" To: "matthieu.vial@non.schneider-electric.com" , Carsten Bormann Thread-Topic: [core] draft-ietf-core-block-08 - multicast Thread-Index: AQHNHGyQSMM09+CguEqSZiSaRLjQT5afDZ0ggAAAi4CAAR4xAIAA1USQgADqb7A= Date: Thu, 19 Apr 2012 15:18:50 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED61809D122@011-DB3MPN1-012.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED618093C38@011-DB3MPN1-013.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED618093C38@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: [86.94.216.29] Content-Type: text/plain; charset="us-ascii" 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 - 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: Thu, 19 Apr 2012 15:16:18 -0000 (Prev. email continued) I checked some more cases of using block with multicast, based on the Examp= les in -block. Conclusion: for me it's not clear how the current draft should be applied i= n multicast use cases. Various details are missing. On the other hand, not all multicast+Block cases are useful - we should per= haps only check realistic use cases and make it work for those. (Nice input= to the groupcomm draft?) * Case multicast atomic PUT / Fig 7 & 9; I think a server MUST be prepared to receive Block1 PUTs that use a same bl= ock number as sent before (e.g. block sequence 1 2 3 3 4 5 6 6 ... etc.) Reason 1: a NON PUT was not received by all recipients known to the client,= therefore client resends same NON PUT with a new MID. (for discussion: whe= ther this is the right behavior?) Reason 2: a NON PUT was truncated in a subset of recipients, returning 4.13= , client retries with smaller block size to all recipients. * Case multicast atomic POST with Block2 response / Fig 10; - This case relies on the client sending empty ACKs with Block2. I assume s= uch 'ACKs' are multicast. Is this possible? (Assuming NON is used for multi= cast and responses to multicast) Should it be an 'empty NON' or some sort o= f 'NON-ACK' (which behaves exactly like an ACK...) Or simply use CON/ACK anyway in this multicast case? The use of Block1/Block2 in an empty message seems not described in the d= raft. - A server MUST be prepared to receive the 'ACKs' from the client for block= numbers that the server did not even send. Reason: I assume these client 'ACKs' are multicast. One server S2 may pre= fer smaller Block2 SZX than server S1. Client adapts to smallest SZX (that = of S2). E.g. S1 SZX=3D128, S2 SZX=3D64. S1 sends its first block 0 of 128 b= ytes, S2 sends its first block 0 of 64 bytes. Client 'ACKs' block 0 and ind= icates SZX=3D64 in Block2 option. Server S1 now sends block 2 (counted in t= he smaller size 64) and Server S2 sends block 1 (counted in block size 64 )= . Client ACKs block 1 - which S1 did not send! Maybe a figure would be help= ful here :) - Finally, in Fig 10 the client seems to echo the M bit (in fact the whole = Block2 option) that's sent by the server within the Block2 option. In a mul= ticast case, that's not always possible since one server may send its last = block while another one still has more blocks to go. So there need to be so= me rules defined how to handle this case. Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Dij= k, Esko Sent: Wednesday 18 April 2012 22:40 To: matthieu.vial@non.schneider-electric.com; Carsten Bormann Cc: core@ietf.org Subject: Re: [core] draft-ietf-core-block-08 - multicast Maybe I could check a number of core-block + multicast use cases to see if = special support is needed? A first case: for a GET like in Fig 2 of section 3, but sent in multicast t= o a group of servers, some servers may send the last block earlier than oth= ers because of different resource sizes. These servers (with relatively sma= ll resource size) will get requests for block numbers that are too high / o= ut of range. Then the discussion "GETs beyond resource size" (http://www.ietf.org/mail-a= rchive/web/core/current/msg02595.html ) becomes relevant except that the cl= ient really can't avoid sending such requests beyond resource size like it = could in unicast. Another case: a GET like in Fig 3 of section 3, but now multicast again to = a group by the client. Suppose server S1 responds with Block option 2/0/1/6= 4, while server S2 responds with 2/0/1/32. The draft states: "The server SHOULD use the block size indicated in the request option or a smaller size, but the requester MUST take note of the actual block size used in the response it receives to its initial request and proceed to use it in subsequent requests." Now S1 assumes that client MUST use size 64 in subsequent requests, while S= 2 assumes that client MUST use size 32 - an issue. (Maybe the client could go for the lowest size returned over all servers in= the group; but this needs changes in functionality) Another point is that multicast uses NON messages, which presumably causes = a different timing and interaction pattern than the existing examples in -b= lock. E.g. there's no retry of CON due to missing ACK on the one hand, but on the= other hand a client has to retry the same NON to get the data blocks. The current text raises a bit of the question "can I use NON in the first p= lace?" and if so, any special timing/interaction patterns or is it simply t= he same as the pattern with CON/ACK (but then instead using NON/NON message= s)? There may be some more things raised by checking PUT/POST/DELETE cases or c= ases where some server(s) responds relatively late with block-size preferen= ces. Esko _______________________________________________ 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 Thu Apr 19 08: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 F0D7121F85AC for ; Thu, 19 Apr 2012 08:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.327 X-Spam-Level: X-Spam-Status: No, score=-106.327 tagged_above=-999 required=5 tests=[AWL=-0.078, 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 xQmOawp55kyC for ; Thu, 19 Apr 2012 08:34: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 E47D521F86B0 for ; Thu, 19 Apr 2012 08:34: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 q3JFYMkR028157; Thu, 19 Apr 2012 17:34:22 +0200 (CEST) Received: from [192.168.217.105] (p54899A0A.dip.t-dialin.net [84.137.154.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 959ADBCD; Thu, 19 Apr 2012 17:34: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: <0F5E905B-9933-4F52-8FF7-C88C96E0A780@iii.ca> Date: Thu, 19 Apr 2012 17:34:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0F5E905B-9933-4F52-8FF7-C88C96E0A780@iii.ca> To: Cullen Jennings 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: Thu, 19 Apr 2012 15:34:34 -0000 On Apr 18, 2012, at 16:18, Cullen Jennings wrote: >=20 > 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 There is definitely one application that needs to work: -- a multicast GET request is made to /.well-known/core (plus maybe some = query parameters) -- some of the (unicast!) responses contain Block2, some don't. In this example, no Block option occurs in a multicast message, but = multicast is used in the exchange. A Block2 option could be used in the = request to indicate a preferred response size, though. I don't see a very convincing reason to continue using multicast in the = followup blockwise GETs (block number 1 up). I would have continued = with unicast CON. > I can imagine using multicast block to do something like upgrade all = the firmware on many devices at once.=20 Now this is Block1. As Esko points out, this may need "manual" retransmissions. Of course, an implementation might send multiple copies of the multicast = NON with the same MID to accomplish that (saturation). But all this sounds like material for the groupcomm draft, not for = -block. Block provides the mechanism that can be used in more or less = interesting ways. Trying to prescribe exactly the ways of using the mechanism we can come = up with at the moment in the spec does not sound like a recipe for sound = protocol evolution. It also makes the spec appear way more complicated = than it is. Gr=FC=DFe, Carsten From trac+core@trac.tools.ietf.org Thu Apr 19 08:55: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 D88D321F8427 for ; Thu, 19 Apr 2012 08:55:47 -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 jn-RTOCAIVzQ for ; Thu, 19 Apr 2012 08:55:43 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 92CCC21F843F for ; Thu, 19 Apr 2012 08:55:42 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SKthf-00065T-VP; Thu, 19 Apr 2012 11:55:28 -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: Thu, 19 Apr 2012 15:55:27 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/215 Message-ID: <051.45ee7476d5dde81710e3ef0e9dc7fb7f@trac.tools.ietf.org> X-Trac-Ticket-ID: 215 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: <20120419155543.92CCC21F843F@ietfa.amsl.com> Resent-Date: Thu, 19 Apr 2012 08:55:42 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #215: editorial issues around Congestion Control 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: Thu, 19 Apr 2012 15:55:48 -0000 #215: editorial issues around Congestion Control Salvatore Loreto notes (http://www.ietf.org/mail- archive/web/core/current/msg03042.html): 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). -> The section is indeed entirely about congestion control and not about server load control at all. It may need to be improved to reduce the potential for misunderstanding here. Cullen Jennings (msg03072s, t, u,v) makes a couple of technical points (e.g., he argues that CoAP needs to be more strict about the number of concurrent requests than HTTP is). These are technical issue that need further discussion. Also, Salvatore notes (msg03039) that the reference to draft-eggert-core- congestion-control in 4.5 would point to an expired draft. As 4.5 now has expanded discussion of multicast congestion control, maybe the reference is no longer necessary. It could also be replaced by a copy of the first two paragraphs in section 3.4 of draft-eggert-core-congestion-control (the third paragraph is now covered by material in 4.5 that was not available at the time 3.4 was written). -- -----------------------------+------------------------------------ Reporter: cabo@… | Owner: draft-ietf-core-coap@… Type: editorial | Status: new Priority: major | Milestone: post-WGLC-1 Component: coap | Version: coap-09 Severity: In WG Last Call | Keywords: -----------------------------+------------------------------------ Ticket URL: core From cabo@tzi.org Thu Apr 19 09:17: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 D742021F867A for ; Thu, 19 Apr 2012 09:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.325 X-Spam-Level: X-Spam-Status: No, score=-106.325 tagged_above=-999 required=5 tests=[AWL=-0.076, 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 nzqx4G1+r0Sz for ; Thu, 19 Apr 2012 09:17:41 -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 F35BB21F867E for ; Thu, 19 Apr 2012 09:17: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 q3JGHSah018838; Thu, 19 Apr 2012 18:17:28 +0200 (CEST) Received: from [192.168.217.105] (p54899A0A.dip.t-dialin.net [84.137.154.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 818A9C1F; Thu, 19 Apr 2012 18:17:28 +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, 19 Apr 2012 18:17:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <783A2F31-F8E6-4A95-B664-9D3899ED675F@tzi.org> References: To: Cullen Jennings X-Mailer: Apple Mail (2.1257) Cc: core WG Subject: Re: [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: Thu, 19 Apr 2012 16:17:42 -0000 On Apr 18, 2012, at 06:58, Cullen Jennings wrote: > 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 Giving a hard limit for the number of parallel connections was tried = with HTTP, and finally given up upon in HTTPBIS. Good riddance. If we indeed were to succeed in getting all clients to implement this = hard limit, as was miraculously managed for HTTP for a decade, servers = that need more concurrency will just go ahead and allocate multiple IP = addresses, or do whatever it takes. We have a decade of experience with = trying these stunts in the HTTP space. Let's not make the same 100 = million dollar mistake again. If it is not in the best interest of the implementers to have congestion = control, we will indeed not have congestion control. (It, however, sure = is, and that's why we provide the mechanisms.) > 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 No. The same is true for an amplification attack (the server will have = no way to distinguish the two cases, and the mitigation will be the = same). We probably need to point to 10.3.3 in 4.6. > 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 Good point. The Leisure period needs to be additive with that of = existing responses that are waiting to be sent. > Have people implemented the congestion control and what does it look = like under failure.=20 (If we can get data on this, this would indeed be interesting to know.) Gr=FC=DFe, Carsten From trac+core@trac.tools.ietf.org Thu Apr 19 10:02: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 EB06E21F8670 for ; Thu, 19 Apr 2012 10:02:49 -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 Kg-GYpF37e1N for ; Thu, 19 Apr 2012 10:02:43 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 41A0E21F8665 for ; Thu, 19 Apr 2012 10:02:43 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SKukX-0006si-Ph; Thu, 19 Apr 2012 13:02:29 -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: Thu, 19 Apr 2012 17:02:29 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/216 Message-ID: <051.b4a18821cc4ddb8421c1989a2a275047@trac.tools.ietf.org> X-Trac-Ticket-ID: 216 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: <20120419170243.41A0E21F8665@ietfa.amsl.com> Resent-Date: Thu, 19 Apr 2012 10:02:43 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #216: IANA: get Multicast addresses 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: Thu, 19 Apr 2012 17:02:50 -0000 #216: IANA: get Multicast addresses Cullen Jennings notes (msg03072b): I think we should have IANA allocate a v4 and v6 default address to use for multicast -> Add text to IANA considerations. TBD: This would be a variable scope multicast address for IPv6 (RFC 3307) and a scoped multicast address for IPv4 (RFC 5771)? -- -----------------------------+------------------------------------ Reporter: cabo@… | Owner: draft-ietf-core-coap@… Type: other technical | Status: new Priority: major | Milestone: post-WGLC-1 Component: coap | Version: coap-09 Severity: In WG Last Call | Keywords: -----------------------------+------------------------------------ Ticket URL: core From trac+core@trac.tools.ietf.org Thu Apr 19 11:50: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 0B2B621F85C3 for ; Thu, 19 Apr 2012 11:50:47 -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 v7MOAf1CtzDy for ; Thu, 19 Apr 2012 11:50:46 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 700B121F85BB for ; Thu, 19 Apr 2012 11:50:45 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SKwQy-0002F2-RI; Thu, 19 Apr 2012 14:50: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-observe@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Thu, 19 Apr 2012 18:50:23 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/217 Message-ID: <051.9ec4e5813aa29f30a67cab16c3a9ea51@trac.tools.ietf.org> X-Trac-Ticket-ID: 217 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: <20120419185046.700B121F85BB@ietfa.amsl.com> Resent-Date: Thu, 19 Apr 2012 11:50:45 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #217: how fast must the observe clock be able to go? 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: Thu, 19 Apr 2012 18:50:47 -0000 #217: how fast must the observe clock be able to go? Cullen Jennings notes (msg03073g): 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. -> The client-side algorithm is specified in 3.4. The current "MUST NOT reuse" in 4.4 is very conservative, reflecting a very simple implementation strategy. We could come up with alternative, more elaborate server-side requirements that enable faster updates. How fast is fast enough? How much are we willing to assume about reordering and delivery probabilities (distributions, actually)? -- ----------------------------------+--------------------------------------- Reporter: cabo@… | Owner: draft-ietf-core-observe@… Type: protocol enhancement | Status: new Priority: major | Milestone: post-WGLC-1 Component: observe | Version: observe-05 Severity: In WG Last Call | Keywords: ----------------------------------+--------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Thu Apr 19 12:14:20 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 25F4D11E8081 for ; Thu, 19 Apr 2012 12:14:20 -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 kxDBQppWQYvU for ; Thu, 19 Apr 2012 12:14:19 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 0393E11E8074 for ; Thu, 19 Apr 2012 12:14:18 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SKwo6-0007lR-9u; Thu, 19 Apr 2012 15:14:18 -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: hartke@tzi.org, cabo@tzi.org X-Trac-Project: core Date: Thu, 19 Apr 2012 19:14:18 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/218 Message-ID: <051.7d815a68bfc98553d3a253f599448da9@trac.tools.ietf.org> X-Trac-Ticket-ID: 218 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartke@tzi.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 Cc: core@ietf.org Subject: [core] #218: Mostly obvious section 5.10.8 fixes 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: Thu, 19 Apr 2012 19:14:20 -0000 #218: Mostly obvious section 5.10.8 fixes Klaus Hartke (msg03034d): 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. Also: Esko Dijk (msg03057m): Section 5.10.8 “The two options MAY be included in a response to indicate the location of a new resource created with POST.” “the two options MAY” -> this sounds like they have to be included as a pair, which is not the case. Also: Klaus Hartke (msg03034e): Section 5.10.8. (Location-Path and Location-Query) should define that "the value of a Location-Path Option MUST NOT be '.' or '..'." Also: Make sure it is obvious that all the options together indicate *one* Location. (cf. msg03072ba) Also: (Fix grammar of sentence 1 in the process.) -- -----------------------------+------------------------- Reporter: cabo@… | Owner: hartke@… Type: other technical | Status: new Priority: minor | Milestone: post-WGLC-1 Component: coap | Version: coap-09 Severity: In WG Last Call | Keywords: -----------------------------+------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Thu Apr 19 12:47: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 AD2B921F86C2 for ; Thu, 19 Apr 2012 12:47:21 -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 Po1XAD6CVWgM for ; Thu, 19 Apr 2012 12:47:21 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 6084121F86B2 for ; Thu, 19 Apr 2012 12:47:16 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SKxJz-0006YL-1T; Thu, 19 Apr 2012 15:47:15 -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: hartke@tzi.org, cabo@tzi.org X-Trac-Project: core Date: Thu, 19 Apr 2012 19:47:14 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/218#comment:1 Message-ID: <066.0bcd90e8e29e986eb4621ab72c65a513@trac.tools.ietf.org> References: <051.7d815a68bfc98553d3a253f599448da9@trac.tools.ietf.org> X-Trac-Ticket-ID: 218 In-Reply-To: <051.7d815a68bfc98553d3a253f599448da9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartke@tzi.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 Cc: core@ietf.org Subject: Re: [core] #218: Mostly obvious section 5.10.8 fixes 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: Thu, 19 Apr 2012 19:47:21 -0000 #218: Mostly obvious section 5.10.8 fixes Comment (by cabo@…): Just to check that we have been doing the right thing here (no change is being proposed): in the HTTP space, there is draft-nottingham-linked- cache-inv that states: HTTP [...] provides for [...] a state-changing request to invalidate related resources (using the Location and Content-Location headers in the response), but this is of limited utility, because those headers have defined semantics, *and can only occur once each.* The draft solves that problem by showing how to use the Link: header field to invalidate more cached representations. CoAP does not have an equivalent Link option (we carry Link information in link-format payloads, so far). But maybe it also doesn't need to solve the original problem either. -- -----------------------------+-------------------------- Reporter: cabo@… | Owner: hartke@… Type: other technical | Status: new Priority: minor | Milestone: post-WGLC-1 Component: coap | Version: coap-09 Severity: In WG Last Call | Resolution: Keywords: | -----------------------------+-------------------------- Ticket URL: core From fluffy@cisco.com Thu Apr 19 13:54:05 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 751E411E80CE for ; Thu, 19 Apr 2012 13:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.255 X-Spam-Level: X-Spam-Status: No, score=-110.255 tagged_above=-999 required=5 tests=[AWL=0.344, 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 Ia3pX8yxqZQF for ; Thu, 19 Apr 2012 13:54:01 -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 7942F11E80CA for ; Thu, 19 Apr 2012 13:54:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=861; q=dns/txt; s=iport; t=1334868841; x=1336078441; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=/h39RwCDxf/krjvPRBLjrcl012qBqYfmEaSr+nHWNJw=; b=TYq+s56Lte/K0Jaovh1r8UTxRok9DvA4I+eqoZKMInmYyrKk6wFBoqN+ CgrrUYb+x3ORLdtDCQnxuxz3DZagYYet7Fmjf8TBNdT0QaUs2X1U+m7sI Q4icwX03Q7hECkFZfy+LJhdSXJGv0r/WE8FVOSJ9hw/0lfNX3MKFSVfvg w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8GAFp6kE+rRDoH/2dsb2JhbABDgxyuK4EHgiIBJy8BD4E+NYdsDJp9oBWQBGMEiFyNE4V0iF6BaYMG X-IronPort-AV: E=Sophos;i="4.75,447,1330905600"; d="scan'208";a="41235718" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 19 Apr 2012 20:54:01 +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 q3JKs0rp004876; Thu, 19 Apr 2012 20:54:01 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Apr 2012 14:54:02 -0600 Message-Id: <74BE9ECA-1DDA-41C6-BC11-D317DB8ECF28@cisco.com> To: core WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Barry Leiba Subject: [core] CORE Virtual Interim doodle poll 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, 19 Apr 2012 20:54:05 -0000 The CORE WG is considering having a virtual interim meeting to discuss = the open issues with the three drafts we recently had a WGLC for. Please = indicate your preferences by the end of Thursday, April 28. If you think = other times should be added to the poll, let the chairs knows. This will be a 2 hour long meeting phone call.=20 Please indicate your availability at=20 http://www.doodle.com/rs3cr3iqkwcmxr92 I realize all the dates seem a bit out in the future, but once we pick a = time, we need to have 2 weeks notice to announce it. I realize that I = only provided times that were early for west coast and late for europe - = past experience indicates that times outside this range are very = unlikely to get selected so I did not add other times but if someone = feels I really should of, let me know and I will.=20 Cullen From barryleiba@gmail.com Thu Apr 19 14: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 8CB7F21F85F6 for ; Thu, 19 Apr 2012 14:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.903 X-Spam-Level: X-Spam-Status: No, score=-102.903 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 7lpp+8L3oh4y for ; Thu, 19 Apr 2012 14:01:34 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 063B321F8526 for ; Thu, 19 Apr 2012 14:01:33 -0700 (PDT) Received: by obbwd20 with SMTP id wd20so8273736obb.31 for ; Thu, 19 Apr 2012 14:01:33 -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:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/HRqLKnTDp14GYBlmI+WSykYQS0ReyeeXYiuw3LMuEc=; b=F5ktvh/5lh0cArlwo7PrhHvZ4p6AdzIeNc6H3JnXNgtIqPbecR2PhH98ZRlMeihPK8 9rCXjSxDSFHOT4nbvgyTzyowaiHTxUJ/yTXyxmzrUWcIXi30VtJYD8iRlOMYGgXzAsW0 kiwpPV3muvbxA5slNXH6Mb6tJQpyCiQnVYE5WbDcxVrmCCK6aWiTnv7YjCNYHWuLiGA7 io72XA9vv6QDPyTAdenKVIruYxhg4HY8/nKmO55WxUMK+P/gTzeU6jca873vMNzgL2fo 2dSgzOrALbg8AZ84xNWAtB/XvmZEQ+YD5XYh5tlw+DJxVVBCNkaNws8NogL1PH65wSTh BCfg== MIME-Version: 1.0 Received: by 10.182.13.99 with SMTP id g3mr5282798obc.22.1334869293498; Thu, 19 Apr 2012 14:01:33 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.60.10.68 with HTTP; Thu, 19 Apr 2012 14:01:33 -0700 (PDT) In-Reply-To: <74BE9ECA-1DDA-41C6-BC11-D317DB8ECF28@cisco.com> References: <74BE9ECA-1DDA-41C6-BC11-D317DB8ECF28@cisco.com> Date: Thu, 19 Apr 2012 17:01:33 -0400 X-Google-Sender-Auth: vUniYbNi41XTM5bpuLz7aAy0mac Message-ID: From: Barry Leiba To: Cullen Jennings Content-Type: text/plain; charset=ISO-8859-1 Cc: core WG Subject: Re: [core] CORE Virtual Interim doodle poll 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, 19 Apr 2012 21:01:34 -0000 > The CORE WG is considering having a virtual interim meeting to discuss the > open issues with the three drafts we recently had a WGLC for. Please indicate > your preferences by the end of Thursday, April 28. If you think other times should > be added to the poll, let the chairs knows. I've responded, but please consider me very low priority for attendance, and don't work it around me at all. Barry, (ir)responsible AD From angelo.castellani@gmail.com Fri Apr 20 00:46: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 407EF21F8562 for ; Fri, 20 Apr 2012 00:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.884 X-Spam-Level: X-Spam-Status: No, score=-2.884 tagged_above=-999 required=5 tests=[AWL=0.093, 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 aaJyNTRGhSfb for ; Fri, 20 Apr 2012 00:46:01 -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 694D621F853D for ; Fri, 20 Apr 2012 00:46:01 -0700 (PDT) Received: by werb10 with SMTP id b10so7240269wer.31 for ; Fri, 20 Apr 2012 00:46:00 -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=yGJr92G073QuBdTWagPgD3uN6ZsvZ95o7GnlL769hhQ=; b=IMkRAXO5GOtzUfMxjtkFKswDtfCPNjazCUdPzGiyIuHH0ezwFZCAYbwLxlr5fQMLCa BRrAPmHbCg/uZCqVi5hwolHeiS/jlzswiLHbaiuGe/eg9BKZ3Ycyr7HAkoOexGzeXOFO XIjIsdFTR/mE4Frw796ddTR4Z6ngy9OG0IvTmWuvwY8odD2OkUpp9nVqKqppm86tfx+x OFNcKG1vsfZkzWt1Q8d1puyi9nnCEW+em7qsd4qTYCHhigCnrqO20N7raEd5Qwr1I6ll Slou7n3h2cUpcuY3dN6zIWoJtcrRz7x8h+yJ+B/PltJGbf28elGeZ6SZpH8XIPwreCHr tzqA== Received: by 10.180.95.37 with SMTP id dh5mr5540917wib.8.1334907960520; Fri, 20 Apr 2012 00:46:00 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.214.20 with HTTP; Fri, 20 Apr 2012 00:45:45 -0700 (PDT) In-Reply-To: <819CF97B-25C9-4867-A149-E10E08BFDC88@tzi.org> References: <9E5F67AC-943D-4A97-B19D-313B7194D9AF@cisco.com> <7D196561-77B0-411B-96EB-F60504165E05@tzi.org> <6C22C05A-F22E-4E09-BF05-E65ECA85ACBD@iii.ca> <819CF97B-25C9-4867-A149-E10E08BFDC88@tzi.org> From: "Angelo P. Castellani" Date: Fri, 20 Apr 2012 09:45:45 +0200 X-Google-Sender-Auth: TzV71oXqGB0lQy7FEr_I7Paj8cM Message-ID: To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Fri, 20 Apr 2012 07:46:02 -0000 On Thu, Apr 19, 2012 at 16:21, Carsten Bormann wrote: > Yes. =C2=A0All I was trying to say was that "awhile1 =3D 20 s" may be an = order of magnitude too low. > [...] > But I stick to the order of magnitude in my "256 s" strawman. 256 seconds are a pain for class-I devices... I cite a still unanswered message that you find in a related thread (http://www.ietf.org/mail-archive/web/core/current/msg03082.html) On Wed, Apr 18, 2012 at 09:49, Angelo P. Castellani wrote: > 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. If this timeout is 256 seconds, then the fill this deduplication slots in this devices is really easy! > When deduplication cannot be assured anymore, since the deduplication > slots in my buffer are all busy, new messages should be ignored? Is it right? > 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 =C2=A0RST 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 If this timeout is 256, to be able to receive one message every second I need 256 slots which are really a lot and hardly available on class-I dev= ices. > Probably in this case sending some RST will be benificial. Even using the aggregation technique (where possible) proposed by you and Esko, the problem itself is not solved for class-I devices. Typically servers and clients talk to different endpoints, and a (small?) part of the slots may be aggregated using that technique. In my opinion we need a window smaller than 256 seconds. A possible solution would be to use an adaptive value, proportional to the measured RTT. However there is no easy way to measure RTT, especially for a CoAP server. Best, Angelo From tho@koanlogic.com Fri Apr 20 03:00: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 5F4C921F874A for ; Fri, 20 Apr 2012 03:00: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 6C2MYLRrSlhi for ; Fri, 20 Apr 2012 03:00:01 -0700 (PDT) Received: from gonzo.koanlogic.com (koanlogic.com [64.251.31.111]) by ietfa.amsl.com (Postfix) with ESMTP id B311D21F8533 for ; Fri, 20 Apr 2012 03:00:01 -0700 (PDT) Received: from chello084112045229.2.11.vie.surfer.at ([84.112.45.229]:52355 helo=[172.16.101.93]) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1SLAcy-00069x-MI for core@ietf.org; Fri, 20 Apr 2012 06:00:00 -0400 From: Thomas Fossati Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Apr 2012 11:59:41 +0200 Message-Id: <55DA56AE-0790-4116-96CB-A96CD99AC088@koanlogic.com> 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] s/one/many/ virtual interim ? 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, 20 Apr 2012 10:00:02 -0000 Folks, given the huge number of topics we have on the table, I was wondering = whether splitting one interim into a number of more focused interim's = would be more effective to make progress in a fast and shared way. If we manage to cleanly separate working items, then we may assign them = to sub-groups that can focus on a specific theme, and come up with = concrete proposals that can later be synthesized by I-Ds authors. The 2 hours slot allocated for the current interim could be much more = useful if we could employ it as a divide-et-impera stage used to prepare = the subsequent real work (by identifying both work areas and folks = willing to tackle each of these.) I think that offloading some of the enormous burden from the author's = shoulders may be a sensible thing to do at this point. Thomas.= From cabo@tzi.org Fri Apr 20 04:04: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 5D8BE21F86B6 for ; Fri, 20 Apr 2012 04:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.988 X-Spam-Level: X-Spam-Status: No, score=-105.988 tagged_above=-999 required=5 tests=[AWL=0.261, 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 sLc5QXyZ34-3 for ; Fri, 20 Apr 2012 04:04: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 8BDBC21F86D5 for ; Fri, 20 Apr 2012 04:04:47 -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 q3KB4Zgs027337; Fri, 20 Apr 2012 13:04:36 +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 DD2BAFDC; Fri, 20 Apr 2012 13:04: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: <55DA56AE-0790-4116-96CB-A96CD99AC088@koanlogic.com> Date: Fri, 20 Apr 2012 13:04:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <232DD51A-3CC7-4E66-99F7-B7E9908915F7@tzi.org> References: <55DA56AE-0790-4116-96CB-A96CD99AC088@koanlogic.com> To: Thomas Fossati X-Mailer: Apple Mail (2.1257) Cc: core WG Subject: Re: [core] s/one/many/ virtual interim ? 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, 20 Apr 2012 11:04:48 -0000 Hi Thomas, I think we indeed may need more than the one 2-hour slot we have right = now. (In the formative stages of CoRE, we met per phone about once a month. For post-WGLC processing, we probably need a denser cluster of = meetings.) I don't think we can officially split off subgroups very well here. That of course doesn't mean that, e.g. some of the authors, would mind = having a phone call or two on an informal (IETF term: hallway) level. I for one plan to do a couple of Google+ hangouts once we have got = further in processing the WGLC comments. (This is just a personal = thing, imagine gathering in the IETF hallway, nothing will be decided, = but high-bandwidth back and forth can help information flow more = efficiently.) Re the processing of WGLC comments: The authors have identified some 205 separate comments. About 32 of = those have been processed so far (direct minor editorial changes in the = SVN, just ticking off "things to check", creating tickets). This will = continue for a while. We now have 17 active tickets on the WGLC = documents (in addition to the 12 we have open after the IETF last-call = on link-format). While we are doing this, we may be suggesting solutions in the tickets = already created (some comments already contained solutions). If a = ticket has been carrying a solution for a couple of days without further = discussion, we may close it by applying the solution. E.g., #208 was closed yesterday -- you had suggested text, and, with = minor adaptations, that is now in the SVN. All changes to the tickets are echoed to the mailing list. That may = seem a bit arduous at first, but it is really useful. Please do pay close attention to what is going on with the tickets. = This will enable the authors to do a -10/-09/-06 that will have = successfully resolved the existing comments. Gr=FC=DFe, Carsten From fluffy@iii.ca Fri Apr 20 05: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 5B32321F8670 for ; Fri, 20 Apr 2012 05:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[AWL=0.208, 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 X4owdkUcEL0v for ; Fri, 20 Apr 2012 05:40:49 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id C27B021F8450 for ; Fri, 20 Apr 2012 05:40:49 -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 741D322E256; Fri, 20 Apr 2012 08:40:37 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <7AC5EB28-8D28-40B6-9FE8-4D685F434E79@tzi.org> Date: Fri, 20 Apr 2012 06:40:36 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7AC5EB28-8D28-40B6-9FE8-4D685F434E79@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org, Klaus Hartke Subject: Re: [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: Fri, 20 Apr 2012 12:40:51 -0000 On Apr 19, 2012, at 8:05 AM, Carsten Bormann wrote: > The distinction is kind of moot as it is hard to imagine an = implementation that does not handle content-type. for what it's worth ... one of the implementation that I had access to = the source code of does not do this. The CoAP stack on the server = correctly parsed the Accept option but the application ignored it and = returned the same data regardless of what the client asked for. The = client parsed the return value of the Content-Type then ignore it and = did the same thing with the data regardless of Content-Type.=20 I suspect this type of behavior is not unique - I know many HTTP clients = and servers do about the same thing.=20 I'm not 100% sure of what I think of this - perhaps the server and = client are just broken. Perhaps it does not matter. The one thing that = the server did do is correctly set the Content-Type of the returned = data. Of course it set it to text/plain even thought is was only meant = to be a machine readable value ad conformed to a very specific syntax.=20= From fluffy@iii.ca Fri Apr 20 05: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 EC15221F86DE for ; Fri, 20 Apr 2012 05:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.192, 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 xojzRZN4Z-TO for ; Fri, 20 Apr 2012 05:41:43 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 121A421F86DB for ; Fri, 20 Apr 2012 05:41:43 -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 9C88B22E259; Fri, 20 Apr 2012 08:41:41 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: <000e01ccfb9e$8688ab50$939a01f0$@uni-rostock.de> Date: Fri, 20 Apr 2012 06:41:40 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120305094330.27895.2135.idtracker@ietfa.amsl.com> <525954D5-9A28-4C2B-A591-817999FB6A56@sensinode.com> <003001ccfb8e$8305b960$89112c20$@uni-rostock.de> <1DAC05A7-F0F1-4415-8EEA-6975685F1D73@sensinode.com> <000e01ccfb9e$8688ab50$939a01f0$@uni-rostock.de> To: Guido Moritz X-Mailer: Apple Mail (2.1084) Cc: 'core WG' Subject: Re: [core] Fwd: New Version Notification for draft-shelby-exi-registration-00.txt 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, 20 Apr 2012 12:41:45 -0000 Let say a that there were two different formats defined and called sep1 = and sep2 - they both happen to be EXI.=20 A client supporting both and would prefer to get sep2, but it would be = willing to get sep1 is the server did not support sep2.=20 have a media type of application/sep1+exi and application/sep2+exi allow = the client to say it would prefer sep2 but take sep1, and the server can = return sep2 if it supports that and sep1 if it does not.=20 If we just used application/exi for both sep1 and sep2, this would not = work. I do understand that the actually data transferred may also have = information inside the body that allows an exi parser to figure out if = it is sep1 or sep2.=20 Identifying the schema and such in the EXI does add significant sizes to = the EXI in some cases. On Mar 6, 2012, at 6:39 AM, Guido Moritz wrote: > I am still the opinion that this is way too much semantics that is = tried to > push into the Media Type field. EXI has its own mechanisms/header = field for > this (i.e. EXI header including SchemaID field).=20 >=20 > To get a comprehensive solution, also all the other options of the EXI > header (alignment, compression, strict, preserve...) must be included = in the > Media Type definition. >=20 > I still do not get the point, why the way EXI handles these by = internal > options is not sufficient? The only thing to carry in the Media Type = is that > whether it is EXI or not. Everything beyond that, i.e. the specific = EXI > mode, should be expressed by the existing EXI options.=20 >=20 > All these definitions are application/protocol specific. Sure, it must = be > defined somewhere. But I would say define a new Media Type for each = possible > combination of protocol schemas, application specific schemas and = schema > versions is not an appropriate solution.=20 >=20 > Maybe some realistic examples of +exi Media Types to be defined would = help > to generate new input for this discussion?=20 >=20 > Guido >=20 >> -----Urspr=FCngliche Nachricht----- >> Von: Zach Shelby [mailto:zach@sensinode.com] >> Gesendet: Dienstag, 6. M=E4rz 2012 14:22 >> An: Guido Moritz >> Cc: 'core WG' >> Betreff: Re: AW: [core] Fwd: New Version Notification for > draft-shelby-exi- >> registration-00.txt >>=20 >> Hi, >>=20 >> On Mar 6, 2012, at 1:44 PM, Guido Moritz wrote: >>=20 >>> Hi Zach, >>>=20 >>> I have read the draft and also stumbled through the discussion on = the > APPS >>> WG list. You describe two scenarios for the usage of +exi. I would > mainly >>> pick up the second: >>=20 >> The idea was that the use of +exi is recommended for both bullet = points. > The >> point of that section is just to guide readers to where the use of = +exi is >> appropriate compared to the existing exi content encoding or > application/exi >> approaches. >>=20 >>>=20 >>> o Use EXI as a native encoding (without the use of XML as an >>> interemediate) in Strict Schema-informed mode, and the base = Media >>> Type indicates to the protocol the Schema that was used to = produce >>> the EXI grammar. >>>=20 >>> The major intention of this use case is to indicate the used schemas > that >>> are required to generate the appropriate EXI grammar. >>=20 >> Not only the used schema, but also the underlying semantics of what = is >> contained in the schema. >>=20 >>> To come up with an >>> example I would use application/soap. But there is no clear = relationship >>> which schemas have to be included if application/soap+exi is used. = Is it >>> only the SOAP schema? Which version of SOAP? Is it also the > WS-Addressing >>> schema? Which version of WS-Addressing? What WS-* or application > specific >>> schemas else?! >>=20 >> The purpose of this draft is to define the registration guidelines = for > someone >> registering an application/foo+exi media type. So it would be up to = the > person >> requesting that media type to describe what schemas are used and how = to >> interpret the Schema ID field (in case multiple schemas are possible > e.g.). So if >> you are registering the media type application/soap+exi then you need = to >> define those details. >>=20 >>> Thus, it would be required to define for each Media Type very strict > which >>> schemas and versions are required and which not. >>=20 >> Yes, each media type registration needs to define these things. This = is > needed >> to ensure interoperability. Is that a bad thing? >>=20 >>> The approach described in >>> the draft is too generic. I would argue this definition is not in = the >>> responsibility of the IETF, but must be e.g. part of the W3C EXI WG. >>=20 >> This draft is just defining the +exi suffix registration procedure, = which > should be >> generic. In my understanding the iETF is the right place to do it. >>=20 >> Zach >>=20 >>=20 >>>=20 >>> My 2 cents, >>> Guido >>>=20 >>>> -----Urspr=FCngliche Nachricht----- >>>> Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im = Auftrag > von >>>> Zach Shelby >>>> Gesendet: Montag, 5. M=E4rz 2012 10:51 >>>> An: core WG >>>> Betreff: [core] Fwd: New Version Notification for >>> draft-shelby-exi-registration- >>>> 00.txt >>>>=20 >>>> Here is a draft I wrote up describing a +exi Media Type suffix, and > which >>> we >>>> have discussed over on the apps-discuss mailing list. Soliciting = any >>> comments >>>> from CoRE as well. >>>>=20 >>>> http://www.ietf.org/id/draft-shelby-exi-registration-00.txt >>>>=20 >>>> Zach >>>>=20 >>>> Begin forwarded message: >>>>=20 >>>>> From: internet-drafts@ietf.org >>>>> Date: March 5, 2012 11:43:30 AM GMT+02:00 >>>>> To: zach@sensinode.com >>>>> Subject: New Version Notification for >>> draft-shelby-exi-registration-00.txt >>>>>=20 >>>>> A new version of I-D, draft-shelby-exi-registration-00.txt has = been >>> successfully >>>> submitted by Zach Shelby and posted to the IETF repository. >>>>>=20 >>>>> Filename: draft-shelby-exi-registration >>>>> Revision: 00 >>>>> Title: The +exi Media Type Suffix >>>>> Creation date: 2012-03-05 >>>>> WG ID: Individual Submission >>>>> Number of pages: 5 >>>>>=20 >>>>> Abstract: >>>>> Efficient XML Interchange (EXI) is an XML representation technique >>>>> specified by the W3C to provie a binary alternative to the = standard >>>>> text XML representation. This document defines a new Structure >>>>> Syntax Suffix "+exi" for use in a specific class of >>> protocols, where >>>>> "exi" content-type encoding or the generic >>>> "application/exi" Media >>>>> Type are not applicable. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The IETF Secretariat >>>>=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 >>>>=20 >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>>=20 >>=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 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From fluffy@iii.ca Fri Apr 20 05:42: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 1E2CD21F86DB for ; Fri, 20 Apr 2012 05:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, J_CHICKENPOX_33=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 1JSyH9HKqCTe for ; Fri, 20 Apr 2012 05:42: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 9B1AB21F876C for ; Fri, 20 Apr 2012 05:42: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 A1CA622DD6D for ; Fri, 20 Apr 2012 08:42:16 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Cullen Jennings In-Reply-To: <4F8D1EA8.6080800@ericsson.com> Date: Fri, 20 Apr 2012 06:42:16 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: 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> <4F8D1EA8.6080800@ericsson.com> To: core WG X-Mailer: Apple Mail (2.1084) 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: Fri, 20 Apr 2012 12:42:19 -0000 This thread seems to be leading towards a separate bit in the option = that indicates if a proxy needs to understand the option or not. Not = sure what I think of that idea but it would be one possibility to = consider.=20 On Apr 17, 2012, at 1:41 AM, Salvatore Loreto wrote: > Hi there, >=20 > 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 >=20 > my guess is that at the end it will be something similar to what we = have in httpbis-p6=20 >=20 > 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. >=20 >=20 > then my problem is with the option that change the semantic of a = request like Observe. > This is something we have to solve! >=20 > cheers > Salvatore >=20 > --=20 > Salvatore Loreto, PhD >=20 > www.sloreto.com >=20 >=20 > On 4/17/12 9:03 AM, Thomas Fossati wrote: >> Hi Klaus, >>=20 >> On Apr 17, 2012, at 3:45 AM, Klaus Hartke wrote: >>=20 >>> let me rephrase this to make sure I understand it correctly: >>> [...] >>>=20 >> yes, nearly. The missing bit is not there because I was not crystal = clear (I implied a prior email of mine.) >>=20 >> 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. >>=20 >> Further, my concern is more about future options than those defined = in the base spec since these are likely to be implemented pervasively. >>=20 >>=20 >>> * 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. >>>=20 >> This happens because of an optimization in Block, not for the = segmentation logics per se, right ? >>=20 >> 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 >>=20 >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From fluffy@iii.ca Fri Apr 20 05:42: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 18D0321F86DE for ; Fri, 20 Apr 2012 05:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.187, 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 joWSVhal2fsS for ; Fri, 20 Apr 2012 05:42:32 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 8755E21F86DD for ; Fri, 20 Apr 2012 05:42:32 -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 97FD622E256; Fri, 20 Apr 2012 08:42:31 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4F8C4249.7040401@ericsson.com> Date: Fri, 20 Apr 2012 06:42:31 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9A30B54A-8BA1-4679-B791-25CE1AA959ED@iii.ca> References: <4F8C4249.7040401@ericsson.com> To: Salvatore Loreto X-Mailer: Apple Mail (2.1084) Cc: "core@ietf.org" Subject: Re: [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: Fri, 20 Apr 2012 12:42:33 -0000 I don't think that Lars intended to progress this to an RFC so we might = want to cut and paste in the important information from this draft.=20 On Apr 16, 2012, at 10:01 AM, Salvatore Loreto wrote: > Hi >=20 > 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: >=20 > "This document motivates the need for additional congestion control = mechanisms, and defines some simple strawman proposals.=20 > The goal is to encourage experimentation with these and other = proposals, in order to determine which mechanisms are feasible=20 > to implement on resource- constrained nodes and are effective in real = deployments." >=20 > I am not sure about the opportunity to keep referencing it in the = spec. >=20 > /Sal > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From fluffy@iii.ca Fri Apr 20 05:42: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 E56CE21F8766 for ; Fri, 20 Apr 2012 05:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.924 X-Spam-Level: X-Spam-Status: No, score=-2.924 tagged_above=-999 required=5 tests=[AWL=0.675, 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 d42atkePC6qI for ; Fri, 20 Apr 2012 05:42:59 -0700 (PDT) Received: from fallback-in2.mxes.net (fallback-out2.mxes.net [216.86.168.191]) by ietfa.amsl.com (Postfix) with ESMTP id 5F58021F86DB for ; Fri, 20 Apr 2012 05:42:59 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by fallback-in1.mxes.net (Postfix) with ESMTP id B38832FD7BD for ; Fri, 20 Apr 2012 08:42:52 -0400 (EDT) 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 BEF0822E259; Fri, 20 Apr 2012 08:42:51 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Fri, 20 Apr 2012 06:42:51 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6029ED8C-2341-4199-A439-F0DB02A55DA4@koanlogic.com> To: Klaus Hartke 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: Fri, 20 Apr 2012 12:43:00 -0000 Virtual hosting could work in coap if we using DNS or something like = that because the URI=20 coap://server1.example.com=20 and=20 coap://server2.example.com=20 could resolve to the same IP address. But if we think we are not using = DNS, it gets harder. Using ports could obviously work but make discover = of the server on the non default port hard.=20 I don't like how SNMP does this but you could have one server on the = default port that all it did was tell you about all the other servers = running on different ports. Anyways, I'd like to see us resolve this one = way or another.=20 On Apr 13, 2012, at 5:42 PM, 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. >=20 > 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. >=20 >=20 > Klaus > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From fluffy@iii.ca Fri Apr 20 05:45: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 517D021F8771 for ; Fri, 20 Apr 2012 05:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 b0uAfEMZ3mNr for ; Fri, 20 Apr 2012 05:45: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 4C02121F8766 for ; Fri, 20 Apr 2012 05:44:49 -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 250AF22E259; Fri, 20 Apr 2012 08:44:47 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Fri, 20 Apr 2012 06:44:45 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <0B4BE9E8-93E5-45BD-BD6C-8717AF618943@iii.ca> References: <626A389E-CC7E-4EB5-9B55-7B18723A1BCF@tzi.org> <5B365D30-B8F1-4344-A87B-0CE8BF56E401@iii.ca> To: "Angelo P. Castellani" 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: Fri, 20 Apr 2012 12:45:03 -0000 Sure - I could live with 5 seconds. It won't work to access a device = over a satellite link which is why I suggested a larger number. Carsten = has pointed out in other threads this may be much longer so will be an = interesting question.=20 The important thing to me is that we have a well defined number. = Whatever that number is, there will be some things that won't work but = it gives applications and users something they know will work.=20 It occurs to me that by defining the stop and wait retransmission time = at 2 seconds, we are already assuming that the max round trip time is = perhaps 2 seconds or perhaps 4 seconds but probably not hugely larger = than that. On Apr 18, 2012, at 9:06 AM, Angelo P. Castellani wrote: > I had hoped something like 5-10 seconds of default value. >=20 > 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. >>=20 >> Isn't that too much? >>=20 >> 10 seconds of flight time seems unrealistic to me. >>=20 >> Best, >> Angelo From skip.ashton@ember.com Fri Apr 20 05:46: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 C773B21F86DD for ; Fri, 20 Apr 2012 05:46:18 -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 zyAUfBi3zbpW for ; Fri, 20 Apr 2012 05:46:17 -0700 (PDT) Received: from p01c12o142.mxlogic.net (p01c12o142.mxlogic.net [208.65.145.65]) by ietfa.amsl.com (Postfix) with ESMTP id 79FF721F872F for ; Fri, 20 Apr 2012 05:46:17 -0700 (PDT) Received: from unknown [216.236.254.3] (EHLO p01c12o142.mxlogic.net) by p01c12o142.mxlogic.net(mxl_mta-6.13.0-3) with ESMTP id 99a519f4.70aea940.26830.00-582.49484.p01c12o142.mxlogic.net (envelope-from ); Fri, 20 Apr 2012 06:46:17 -0600 (MDT) X-MXL-Hash: 4f915a99240ca23b-bb6dc1732bc11a3209e3ef60aa04294639895410 Received: from unknown [216.236.254.3] (EHLO usmail.ember.com) by p01c12o142.mxlogic.net(mxl_mta-6.13.0-3) over TLS secured channel with ESMTP id 69a519f4.0.26824.00-362.49471.p01c12o142.mxlogic.net (envelope-from ); Fri, 20 Apr 2012 06:46:16 -0600 (MDT) X-MXL-Hash: 4f915a984deae6cc-28eb15989ce9a4aae12c6f74eca9b32264314a1a Received: from USMAIL.hq.ember.com ([fe80::414:51ae:1b16:3f29]) by USMail.hq.ember.com ([fe80::414:51ae:1b16:3f29%10]) with mapi id 14.01.0355.002; Fri, 20 Apr 2012 08:48:04 -0400 From: Skip Ashton To: Cullen Jennings , Guido Moritz Thread-Topic: [core] Fwd: New Version Notification for draft-shelby-exi-registration-00.txt Thread-Index: AQHNHvPTeaRN5fxDcUK/Hz3BZ8DfHQ== Date: Fri, 20 Apr 2012 12:48:03 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 x-originating-ip: [192.168.90.89] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [216.236.254.3] X-AnalysisOut: [v=1.0 c=1 a=obHFMR_yD0QA:10 a=JKwNZ9Yr-6MA:10 a=Z8eb2nvohJ] X-AnalysisOut: [AA:10 a=saA6nF2ZJaAA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:1] X-AnalysisOut: [0 a=xqWC_Br6kY4A:10 a=MYqPJgym4Kx47q1P90kooQ==:17 a=CobiIj] X-AnalysisOut: [ckAAAA:8 a=48vgC7mUAAAA:8 a=Tg463-roAAAA:8 a=YTYBLLhbAAAA:] X-AnalysisOut: [8 a=wsPE3ohxyPVfC94F8CEA:9 a=ZAg-pcWKx3FugR6vyt0A:7 a=wPNL] X-AnalysisOut: [vfGTeEIA:10 a=1w0Pz7LYYPAA:10 a=lZB815dzVvQA:10] Cc: 'core WG' Subject: Re: [core] Fwd: New Version Notification for draft-shelby-exi-registration-00.txt 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, 20 Apr 2012 12:46:18 -0000 The problem we were discussing in SE2 this week is it is not enough to say SE2 since we have to expect there will be SE2.1 and SE 2.2 etc. So it is not enough for a device to say it does SE2, we would also need schema negotiation between devices. Have people thought about how to do this? Skip On 4/20/12 8:41 AM, "Cullen Jennings" wrote: > >Let say a that there were two different formats defined and called sep1 >and sep2 - they both happen to be EXI. > >A client supporting both and would prefer to get sep2, but it would be >willing to get sep1 is the server did not support sep2. > >have a media type of application/sep1+exi and application/sep2+exi allow >the client to say it would prefer sep2 but take sep1, and the server can >return sep2 if it supports that and sep1 if it does not. > >If we just used application/exi for both sep1 and sep2, this would not >work. I do understand that the actually data transferred may also have >information inside the body that allows an exi parser to figure out if it >is sep1 or sep2.=20 > >Identifying the schema and such in the EXI does add significant sizes to >the EXI in some cases. > > > > >On Mar 6, 2012, at 6:39 AM, Guido Moritz wrote: > >> I am still the opinion that this is way too much semantics that is >>tried to >> push into the Media Type field. EXI has its own mechanisms/header field >>for >> this (i.e. EXI header including SchemaID field). >>=20 >> To get a comprehensive solution, also all the other options of the EXI >> header (alignment, compression, strict, preserve...) must be included >>in the >> Media Type definition. >>=20 >> I still do not get the point, why the way EXI handles these by internal >> options is not sufficient? The only thing to carry in the Media Type is >>that >> whether it is EXI or not. Everything beyond that, i.e. the specific EXI >> mode, should be expressed by the existing EXI options. >>=20 >> All these definitions are application/protocol specific. Sure, it must >>be >> defined somewhere. But I would say define a new Media Type for each >>possible >> combination of protocol schemas, application specific schemas and schema >> versions is not an appropriate solution. >>=20 >> Maybe some realistic examples of +exi Media Types to be defined would >>help >> to generate new input for this discussion? >>=20 >> Guido >>=20 >>> -----Urspr=FCngliche Nachricht----- >>> Von: Zach Shelby [mailto:zach@sensinode.com] >>> Gesendet: Dienstag, 6. M=E4rz 2012 14:22 >>> An: Guido Moritz >>> Cc: 'core WG' >>> Betreff: Re: AW: [core] Fwd: New Version Notification for >> draft-shelby-exi- >>> registration-00.txt >>>=20 >>> Hi, >>>=20 >>> On Mar 6, 2012, at 1:44 PM, Guido Moritz wrote: >>>=20 >>>> Hi Zach, >>>>=20 >>>> I have read the draft and also stumbled through the discussion on the >> APPS >>>> WG list. You describe two scenarios for the usage of +exi. I would >> mainly >>>> pick up the second: >>>=20 >>> The idea was that the use of +exi is recommended for both bullet >>>points. >> The >>> point of that section is just to guide readers to where the use of >>>+exi is >>> appropriate compared to the existing exi content encoding or >> application/exi >>> approaches. >>>=20 >>>>=20 >>>> o Use EXI as a native encoding (without the use of XML as an >>>> interemediate) in Strict Schema-informed mode, and the base Media >>>> Type indicates to the protocol the Schema that was used to produce >>>> the EXI grammar. >>>>=20 >>>> The major intention of this use case is to indicate the used schemas >> that >>>> are required to generate the appropriate EXI grammar. >>>=20 >>> Not only the used schema, but also the underlying semantics of what is >>> contained in the schema. >>>=20 >>>> To come up with an >>>> example I would use application/soap. But there is no clear >>>>relationship >>>> which schemas have to be included if application/soap+exi is used. Is >>>>it >>>> only the SOAP schema? Which version of SOAP? Is it also the >> WS-Addressing >>>> schema? Which version of WS-Addressing? What WS-* or application >> specific >>>> schemas else?! >>>=20 >>> The purpose of this draft is to define the registration guidelines for >> someone >>> registering an application/foo+exi media type. So it would be up to the >> person >>> requesting that media type to describe what schemas are used and how to >>> interpret the Schema ID field (in case multiple schemas are possible >> e.g.). So if >>> you are registering the media type application/soap+exi then you need >>>to >>> define those details. >>>=20 >>>> Thus, it would be required to define for each Media Type very strict >> which >>>> schemas and versions are required and which not. >>>=20 >>> Yes, each media type registration needs to define these things. This is >> needed >>> to ensure interoperability. Is that a bad thing? >>>=20 >>>> The approach described in >>>> the draft is too generic. I would argue this definition is not in the >>>> responsibility of the IETF, but must be e.g. part of the W3C EXI WG. >>>=20 >>> This draft is just defining the +exi suffix registration procedure, >>>which >> should be >>> generic. In my understanding the iETF is the right place to do it. >>>=20 >>> Zach >>>=20 >>>=20 >>>>=20 >>>> My 2 cents, >>>> Guido >>>>=20 >>>>> -----Urspr=FCngliche Nachricht----- >>>>> Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag >> von >>>>> Zach Shelby >>>>> Gesendet: Montag, 5. M=E4rz 2012 10:51 >>>>> An: core WG >>>>> Betreff: [core] Fwd: New Version Notification for >>>> draft-shelby-exi-registration- >>>>> 00.txt >>>>>=20 >>>>> Here is a draft I wrote up describing a +exi Media Type suffix, and >> which >>>> we >>>>> have discussed over on the apps-discuss mailing list. Soliciting any >>>> comments >>>>> from CoRE as well. >>>>>=20 >>>>> http://www.ietf.org/id/draft-shelby-exi-registration-00.txt >>>>>=20 >>>>> Zach >>>>>=20 >>>>> Begin forwarded message: >>>>>=20 >>>>>> From: internet-drafts@ietf.org >>>>>> Date: March 5, 2012 11:43:30 AM GMT+02:00 >>>>>> To: zach@sensinode.com >>>>>> Subject: New Version Notification for >>>> draft-shelby-exi-registration-00.txt >>>>>>=20 >>>>>> A new version of I-D, draft-shelby-exi-registration-00.txt has been >>>> successfully >>>>> submitted by Zach Shelby and posted to the IETF repository. >>>>>>=20 >>>>>> Filename: draft-shelby-exi-registration >>>>>> Revision: 00 >>>>>> Title: The +exi Media Type Suffix >>>>>> Creation date: 2012-03-05 >>>>>> WG ID: Individual Submission >>>>>> Number of pages: 5 >>>>>>=20 >>>>>> Abstract: >>>>>> Efficient XML Interchange (EXI) is an XML representation technique >>>>>> specified by the W3C to provie a binary alternative to the standard >>>>>> text XML representation. This document defines a new Structure >>>>>> Syntax Suffix "+exi" for use in a specific class of >>>> protocols, where >>>>>> "exi" content-type encoding or the generic >>>>> "application/exi" Media >>>>>> Type are not applicable. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> The IETF Secretariat >>>>>=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 >>>>>=20 >>>>> _______________________________________________ >>>>> core mailing list >>>>> core@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/core >>>>=20 >>>=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 >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > >_______________________________________________ >core mailing list >core@ietf.org >https://www.ietf.org/mailman/listinfo/core From fluffy@iii.ca Fri Apr 20 05:46: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 DF2EE21F8779 for ; Fri, 20 Apr 2012 05:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, 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 9zRVQziQseBT for ; Fri, 20 Apr 2012 05:46:23 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 42CCE21F8778 for ; Fri, 20 Apr 2012 05:46:23 -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 9953F22E25B; Fri, 20 Apr 2012 08:46:21 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <000f01ccedb0$cd0fe620$672fb260$@uni-rostock.de> Date: Fri, 20 Apr 2012 06:46:20 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <5961B851-CBE9-445D-945A-2FC800A9667E@iii.ca> References: <001b01cced71$c60c8b60$5225a220$@uni-rostock.de> <07CC0900-8116-4242-AB96-D74879E247D8@tzi.org> <001e01cced78$e09dd400$a1d97c00$@uni-rostock.de> <73456E11-9651-4FB8-82E3-1CBC490C55DF@tzi.org> <4F3E758B.8020007@stpeter.im> <000f01ccedb0$cd0fe620$672fb260$@uni-rostock.de> To: Guido Moritz X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org Subject: Re: [core] EXI content type and encoding (was: Resolution to tickets #176, #177, #181) 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, 20 Apr 2012 12:46:24 -0000 =46rom a pragmatic point of view, regardless of what you think the = relation between EXI and XML is I'm very much in favor of CoAP having = content-type value along the lines of =20 application/se+exi=20 On Feb 17, 2012, at 1:14 PM, Guido Moritz wrote: >> I am not an EXI expert, but my understanding from a conversation with >> Zach in Taipei (and afterward on the apps-discuss list) is that one >> could see EXI as either (1) a content-encoding of XML or (2) a new = and >> different content-type. The matter isn't settled, but it would be = good >> to settle it. :) >=20 > I also had to think about this issue for a while, because I have to = explain the differences and perspectives as part of my Phd thesis...keep = fingers cross to have finished it before Paris ;). Overall I concluded = in (2) and describe EXI as a completely new and different = 'content-type', i.e. 'on wire encoding' of XML-Infoset serialized object = structures. >=20 > I think how and why people favor one of the two options is how they = use it. There are applications/implementations that are already using = XML and to save bandwidth now the data stream is changed for several = parts/communications into the EXI format. In this use case, EXI can even = be a compressor, i.e. compression is the process changing the data = representation to a more efficient one. But because their = applications/implementations are still parsing and processing native = Unicode XML, EXI is just another encoding for the existing XML = structures. =46rom this perspective absolutely feasibly to favor (1).=20 >=20 > But EXI is, in contrast to e.g. gzip, also capable to be a standalone = representation that can be parsed and processed directly by the = implementations. This is how the EXI format was designed by the W3C, as = a complete replacement for Unicode XML if required. In this case there = is no need to change EXI to XML to process it. In this case (2) is more = feasible. And this is also the way we are using EXI within our = 6LoWPAN-related implementations.=20 >=20 > My 2 cents, > Maybe we can discuss it in Paris while having a nice wine,=20 > Guido >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From fluffy@iii.ca Fri Apr 20 05:47: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 7DC5A21F86DE for ; Fri, 20 Apr 2012 05:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 BCAn5gigVFCu for ; Fri, 20 Apr 2012 05:47:21 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB7E21F86DD for ; Fri, 20 Apr 2012 05:47:21 -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 8006822E25C for ; Fri, 20 Apr 2012 08:47:20 -0400 (EDT) From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Apr 2012 06:47:20 -0600 Message-Id: To: core WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] notes to add to IANA sections 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, 20 Apr 2012 12:47:21 -0000 For all our IANA section that require us to send an email to some other = review list, I would really appreciate it if we could put in a note in = the draft that indicates the date the email was sent and who sent it so = we can easily find the emails. The notes can include instructions for = the RFC Editor to remove this note before publishing but this will help = us not miss things and it makes it easier for the IESG to review.=20 From fluffy@iii.ca Fri Apr 20 05:47: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 3993E21F8772 for ; Fri, 20 Apr 2012 05:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, 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 ucLpfV9RYLFv for ; Fri, 20 Apr 2012 05:47:45 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 00BB821F8771 for ; Fri, 20 Apr 2012 05:47:45 -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 064B622E256; Fri, 20 Apr 2012 08:47:43 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <000f01ccedb0$cd0fe620$672fb260$@uni-rostock.de> Date: Fri, 20 Apr 2012 06:47:43 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <100EEAA8-8263-43CC-81F6-EB7168AEDD4C@iii.ca> References: <001b01cced71$c60c8b60$5225a220$@uni-rostock.de> <07CC0900-8116-4242-AB96-D74879E247D8@tzi.org> <001e01cced78$e09dd400$a1d97c00$@uni-rostock.de> <73456E11-9651-4FB8-82E3-1CBC490C55DF@tzi.org> <4F3E758B.8020007@stpeter.im> <000f01ccedb0$cd0fe620$672fb260$@uni-rostock.de> To: Guido Moritz X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] EXI content type and encoding (was: Resolution to tickets #176, #177, #181) 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, 20 Apr 2012 12:47:45 -0000 =46rom a pragmatic point of view, regardless of what you think the = relation between EXI and XML is I'm very much in favor of CoAP having = content-type value along the lines of =20 application/se+exi=20 On Feb 17, 2012, at 1:14 PM, Guido Moritz wrote: >> I am not an EXI expert, but my understanding from a conversation with >> Zach in Taipei (and afterward on the apps-discuss list) is that one >> could see EXI as either (1) a content-encoding of XML or (2) a new = and >> different content-type. The matter isn't settled, but it would be = good >> to settle it. :) >=20 > I also had to think about this issue for a while, because I have to = explain the differences and perspectives as part of my Phd thesis...keep = fingers cross to have finished it before Paris ;). Overall I concluded = in (2) and describe EXI as a completely new and different = 'content-type', i.e. 'on wire encoding' of XML-Infoset serialized object = structures. >=20 > I think how and why people favor one of the two options is how they = use it. There are applications/implementations that are already using = XML and to save bandwidth now the data stream is changed for several = parts/communications into the EXI format. In this use case, EXI can even = be a compressor, i.e. compression is the process changing the data = representation to a more efficient one. But because their = applications/implementations are still parsing and processing native = Unicode XML, EXI is just another encoding for the existing XML = structures. =46rom this perspective absolutely feasibly to favor (1).=20 >=20 > But EXI is, in contrast to e.g. gzip, also capable to be a standalone = representation that can be parsed and processed directly by the = implementations. This is how the EXI format was designed by the W3C, as = a complete replacement for Unicode XML if required. In this case there = is no need to change EXI to XML to process it. In this case (2) is more = feasible. And this is also the way we are using EXI within our = 6LoWPAN-related implementations.=20 >=20 > My 2 cents, > Maybe we can discuss it in Paris while having a nice wine,=20 > Guido >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From fluffy@iii.ca Fri Apr 20 05:49: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 3835821F873E for ; Fri, 20 Apr 2012 05:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 QwlAxVZ34+Xs for ; Fri, 20 Apr 2012 05:49: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 B23D821F872F for ; Fri, 20 Apr 2012 05:49: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 2ADF022E256 for ; Fri, 20 Apr 2012 08:49:42 -0400 (EDT) From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Apr 2012 06:49:40 -0600 Message-Id: To: core WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] Test case for proxy + block + cache 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, 20 Apr 2012 12:49:43 -0000 Here are some test cases that I would hope would work.=20 Two clients A and B are both using proxy P to access server S.=20 A the same time A and B are using block to do a GET of a large resource.=20= A has just retrieved a resources from S without using block and it is = freshly cached in P. B gets the same resources using block and hopefully = P transfers the blocks from the cache.=20 A is doing a PUT using block at the same time B is doing a get of the = same resource.=20 A and B both try to GET a resource that is an integer, add one to it, = and PUT it back to server. They want to use the if-match approach to = making sure their increment is atomic and does not get overwritten by = the other client.=20 Similar to above but they instead of an integer, it is a large resource = and clients are using block.=20 From cabo@tzi.org Fri Apr 20 05:51: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 91CBA21F8714 for ; Fri, 20 Apr 2012 05:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.006 X-Spam-Level: X-Spam-Status: No, score=-106.006 tagged_above=-999 required=5 tests=[AWL=0.243, 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 P87R0rLtzNSf for ; Fri, 20 Apr 2012 05:51:25 -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 6B5DD21F8712 for ; Fri, 20 Apr 2012 05:51:25 -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 q3KCpH1F011673; Fri, 20 Apr 2012 14:51:17 +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 0192FCD; Fri, 20 Apr 2012 14:51:17 +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, 20 Apr 2012 14:51:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: 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> <4F8D1EA8.6080800@ericsson.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1257) Cc: core WG 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: Fri, 20 Apr 2012 12:51:26 -0000 On Apr 20, 2012, at 14:42, Cullen Jennings wrote: >=20 > This thread seems to be leading towards a separate bit in the option = that indicates if a proxy needs to understand the option or not. Not = sure what I think of that idea but it would be one possibility to = consider.=20 I would like to see a real-live example for an option that is neither = critical nor elective, first. We have had this discussion for a long = time, but nobody ever came up with an option that would *need* that = third/fourth state. Gr=FC=DFe, Carsten From fluffy@iii.ca Fri Apr 20 06:21: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 75FDC21F84E4 for ; Fri, 20 Apr 2012 06:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 m2UDbQ+msEqA for ; Fri, 20 Apr 2012 06:21:38 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 52FCE21F84DD for ; Fri, 20 Apr 2012 06:21:37 -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 BBC5722E259; Fri, 20 Apr 2012 09:21:29 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: Date: Fri, 20 Apr 2012 07:21:28 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Skip Ashton X-Mailer: Apple Mail (2.1084) Cc: 'core WG' Subject: Re: [core] Fwd: New Version Notification for draft-shelby-exi-registration-00.txt 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, 20 Apr 2012 13:21:39 -0000 Yes, you would register a new media type for every different schema.=20 So perhaps my example should have been=20 application/se2dot1+exi On Apr 20, 2012, at 6:48 AM, Skip Ashton wrote: > The problem we were discussing in SE2 this week is it is not enough to = say > SE2 since we have to expect there will be SE2.1 and SE 2.2 etc. So it = is > not enough for a device to say it does SE2, we would also need schema > negotiation between devices. Have people thought about how to do = this? >=20 > Skip >=20 > On 4/20/12 8:41 AM, "Cullen Jennings" wrote: >=20 >>=20 >> Let say a that there were two different formats defined and called = sep1 >> and sep2 - they both happen to be EXI. >>=20 >> A client supporting both and would prefer to get sep2, but it would = be >> willing to get sep1 is the server did not support sep2. >>=20 >> have a media type of application/sep1+exi and application/sep2+exi = allow >> the client to say it would prefer sep2 but take sep1, and the server = can >> return sep2 if it supports that and sep1 if it does not. >>=20 >> If we just used application/exi for both sep1 and sep2, this would = not >> work. I do understand that the actually data transferred may also = have >> information inside the body that allows an exi parser to figure out = if it >> is sep1 or sep2.=20 >>=20 >> Identifying the schema and such in the EXI does add significant sizes = to >> the EXI in some cases. >>=20 >>=20 >>=20 >>=20 >> On Mar 6, 2012, at 6:39 AM, Guido Moritz wrote: >>=20 >>> I am still the opinion that this is way too much semantics that is >>> tried to >>> push into the Media Type field. EXI has its own mechanisms/header = field >>> for >>> this (i.e. EXI header including SchemaID field). >>>=20 >>> To get a comprehensive solution, also all the other options of the = EXI >>> header (alignment, compression, strict, preserve...) must be = included >>> in the >>> Media Type definition. >>>=20 >>> I still do not get the point, why the way EXI handles these by = internal >>> options is not sufficient? The only thing to carry in the Media Type = is >>> that >>> whether it is EXI or not. Everything beyond that, i.e. the specific = EXI >>> mode, should be expressed by the existing EXI options. >>>=20 >>> All these definitions are application/protocol specific. Sure, it = must >>> be >>> defined somewhere. But I would say define a new Media Type for each >>> possible >>> combination of protocol schemas, application specific schemas and = schema >>> versions is not an appropriate solution. >>>=20 >>> Maybe some realistic examples of +exi Media Types to be defined = would >>> help >>> to generate new input for this discussion? >>>=20 >>> Guido >>>=20 >>>> -----Urspr=FCngliche Nachricht----- >>>> Von: Zach Shelby [mailto:zach@sensinode.com] >>>> Gesendet: Dienstag, 6. M=E4rz 2012 14:22 >>>> An: Guido Moritz >>>> Cc: 'core WG' >>>> Betreff: Re: AW: [core] Fwd: New Version Notification for >>> draft-shelby-exi- >>>> registration-00.txt >>>>=20 >>>> Hi, >>>>=20 >>>> On Mar 6, 2012, at 1:44 PM, Guido Moritz wrote: >>>>=20 >>>>> Hi Zach, >>>>>=20 >>>>> I have read the draft and also stumbled through the discussion on = the >>> APPS >>>>> WG list. You describe two scenarios for the usage of +exi. I would >>> mainly >>>>> pick up the second: >>>>=20 >>>> The idea was that the use of +exi is recommended for both bullet >>>> points. >>> The >>>> point of that section is just to guide readers to where the use of >>>> +exi is >>>> appropriate compared to the existing exi content encoding or >>> application/exi >>>> approaches. >>>>=20 >>>>>=20 >>>>> o Use EXI as a native encoding (without the use of XML as an >>>>> interemediate) in Strict Schema-informed mode, and the base = Media >>>>> Type indicates to the protocol the Schema that was used to = produce >>>>> the EXI grammar. >>>>>=20 >>>>> The major intention of this use case is to indicate the used = schemas >>> that >>>>> are required to generate the appropriate EXI grammar. >>>>=20 >>>> Not only the used schema, but also the underlying semantics of what = is >>>> contained in the schema. >>>>=20 >>>>> To come up with an >>>>> example I would use application/soap. But there is no clear >>>>> relationship >>>>> which schemas have to be included if application/soap+exi is used. = Is >>>>> it >>>>> only the SOAP schema? Which version of SOAP? Is it also the >>> WS-Addressing >>>>> schema? Which version of WS-Addressing? What WS-* or application >>> specific >>>>> schemas else?! >>>>=20 >>>> The purpose of this draft is to define the registration guidelines = for >>> someone >>>> registering an application/foo+exi media type. So it would be up to = the >>> person >>>> requesting that media type to describe what schemas are used and = how to >>>> interpret the Schema ID field (in case multiple schemas are = possible >>> e.g.). So if >>>> you are registering the media type application/soap+exi then you = need >>>> to >>>> define those details. >>>>=20 >>>>> Thus, it would be required to define for each Media Type very = strict >>> which >>>>> schemas and versions are required and which not. >>>>=20 >>>> Yes, each media type registration needs to define these things. = This is >>> needed >>>> to ensure interoperability. Is that a bad thing? >>>>=20 >>>>> The approach described in >>>>> the draft is too generic. I would argue this definition is not in = the >>>>> responsibility of the IETF, but must be e.g. part of the W3C EXI = WG. >>>>=20 >>>> This draft is just defining the +exi suffix registration procedure, >>>> which >>> should be >>>> generic. In my understanding the iETF is the right place to do it. >>>>=20 >>>> Zach >>>>=20 >>>>=20 >>>>>=20 >>>>> My 2 cents, >>>>> Guido >>>>>=20 >>>>>> -----Urspr=FCngliche Nachricht----- >>>>>> Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im = Auftrag >>> von >>>>>> Zach Shelby >>>>>> Gesendet: Montag, 5. M=E4rz 2012 10:51 >>>>>> An: core WG >>>>>> Betreff: [core] Fwd: New Version Notification for >>>>> draft-shelby-exi-registration- >>>>>> 00.txt >>>>>>=20 >>>>>> Here is a draft I wrote up describing a +exi Media Type suffix, = and >>> which >>>>> we >>>>>> have discussed over on the apps-discuss mailing list. Soliciting = any >>>>> comments >>>>>> from CoRE as well. >>>>>>=20 >>>>>> http://www.ietf.org/id/draft-shelby-exi-registration-00.txt >>>>>>=20 >>>>>> Zach >>>>>>=20 >>>>>> Begin forwarded message: >>>>>>=20 >>>>>>> From: internet-drafts@ietf.org >>>>>>> Date: March 5, 2012 11:43:30 AM GMT+02:00 >>>>>>> To: zach@sensinode.com >>>>>>> Subject: New Version Notification for >>>>> draft-shelby-exi-registration-00.txt >>>>>>>=20 >>>>>>> A new version of I-D, draft-shelby-exi-registration-00.txt has = been >>>>> successfully >>>>>> submitted by Zach Shelby and posted to the IETF repository. >>>>>>>=20 >>>>>>> Filename: draft-shelby-exi-registration >>>>>>> Revision: 00 >>>>>>> Title: The +exi Media Type Suffix >>>>>>> Creation date: 2012-03-05 >>>>>>> WG ID: Individual Submission >>>>>>> Number of pages: 5 >>>>>>>=20 >>>>>>> Abstract: >>>>>>> Efficient XML Interchange (EXI) is an XML representation = technique >>>>>>> specified by the W3C to provie a binary alternative to the = standard >>>>>>> text XML representation. This document defines a new Structure >>>>>>> Syntax Suffix "+exi" for use in a specific class of >>>>> protocols, where >>>>>>> "exi" content-type encoding or the generic >>>>>> "application/exi" Media >>>>>>> Type are not applicable. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> The IETF Secretariat >>>>>>=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 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> core mailing list >>>>>> core@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/core >>>>>=20 >>>>=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 >>>=20 >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 From tho@koanlogic.com Fri Apr 20 06:23: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 F02E821F86DF for ; Fri, 20 Apr 2012 06:23:48 -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 30G9mr8t+C1J for ; Fri, 20 Apr 2012 06:23:48 -0700 (PDT) Received: from gonzo.koanlogic.com (koanlogic.com [64.251.31.111]) by ietfa.amsl.com (Postfix) with ESMTP id E033021F86DB for ; Fri, 20 Apr 2012 06:23:47 -0700 (PDT) Received: from chello084112045229.2.11.vie.surfer.at ([84.112.45.229]:54622 helo=[172.16.101.93]) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1SLDoC-0006rU-VG; Fri, 20 Apr 2012 09:23:43 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: Date: Fri, 20 Apr 2012 15:23:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <68B487AC-7384-4B75-9E1F-32CB8454D2F0@koanlogic.com> 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> <4F8D1EA8.6080800@ericsson.com> 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] 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: Fri, 20 Apr 2012 13:23:49 -0000 Carsten, On Apr 20, 2012, at 2:51 PM, Carsten Bormann wrote: >> This thread seems to be leading towards a separate bit in the option = that indicates if a proxy needs to understand the option or not. Not = sure what I think of that idea but it would be one possibility to = consider.=20 >=20 > I would like to see a real-live example for an option that is neither = critical nor elective, first. We have had this discussion for a long = time, but nobody ever came up with an option that would *need* that = third/fourth state. the issue here is that we need a way to distinguish end-to-end from = hop-by-hop semantics in options, otherwise proxies can't cooperate in = making CoAP networks scale. I don't mind if we want to do that with an explicit bit, or by some = implicit rule -- as I proposed previously in this same thread -- but we = need to do that. The current caching rule set treats an intermediary the same way as an = endpoint, forcing a flow to break at a forwarder whenever some = end-to-end semantics is not understood. And this is plain wrong. We don't know how much CoAP will need to scale, but embedding such a = limitation in the core protocol is something that we could regret.= From matthieu.vial@non.schneider-electric.com Fri Apr 20 06:34: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 EC46B21F875E; Fri, 20 Apr 2012 06:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.509 X-Spam-Level: X-Spam-Status: No, score=-5.509 tagged_above=-999 required=5 tests=[AWL=1.090, 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 l9YRaKeP2Bct; Fri, 20 Apr 2012 06:34:55 -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 5C37121F875D; Fri, 20 Apr 2012 06:34:55 -0700 (PDT) Received: from ATEUI01.schneider-electric.com ([10.198.14.9]) by mailX03.eud.schneider-electric.com with ESMTP id 2012042015345310-67823 ; Fri, 20 Apr 2012 15:34:53 +0200 In-Reply-To: To: Cullen Jennings 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: Fri, 20 Apr 2012 15:33:54 +0200 X-MIMETrack: Serialize by Router on ATEUI01.Schneider-Electric.com/T/SVR/Schneider at 20/04/2012 15:35:59, Serialize complete at 20/04/2012 15:35:59, Itemize by SMTP Server on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 20/04/2012 15:34:53, Serialize by Router on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 20/04/2012 15:34:54, Serialize complete at 20/04/2012 15:34:54 Content-Type: text/plain; charset="US-ASCII" Cc: core-bounces@ietf.org, 'core WG' Subject: Re: [core] Fwd: New Version Notification for draft-shelby-exi-registration-00.txt 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, 20 Apr 2012 13:34:56 -0000 >Yes, you would register a new media type for every different schema. >So perhaps my example should have been >application/se2dot1+exi What about using resource discovery and link-format for fine-grained schema negotiation? We just need a new attribute for the schema id and we also may have to define some kind of attribute inheritance to avoid repeating the schema on every single resource. application/sep2+exi is still useful if we assume se2.1, 2.2... have compatible schemas. When compatibility is broken just go with another content type. I don't think it is reasonable to register each minor schema variation from all standards in a 2-byte registry. Matthieu From angelo.castellani@gmail.com Fri Apr 20 07: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 18CC621F8736 for ; Fri, 20 Apr 2012 07:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.89 X-Spam-Level: X-Spam-Status: No, score=-2.89 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 JLP7M0-xMmSy for ; Fri, 20 Apr 2012 07:05:29 -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 4108E21F8704 for ; Fri, 20 Apr 2012 07:05:29 -0700 (PDT) Received: by werb10 with SMTP id b10so7508280wer.31 for ; Fri, 20 Apr 2012 07:05:28 -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=5Z56dGX0evXfo3C6RwegrSkLCmlsqmwPu6/nWD1/UsQ=; b=IqJU+BmtTBrXGYjX1mevdHQm/lXa7Z79wa6LqRzdf27YaWMUrdAvIYVzZtZ99CJTrO qoyfLZSrooPUdJceYzkmwd+XmgkXoXGzX3MwAVDcgAlFuwfoO1tldemWRKCZkis2xvx0 3jAniN6KEQ27wIVJ2xoiWHHCnwfzpEn5LdHQ2XUhr6hj72wr/iSVfTZmlgGCiXhbM66t 82+Xx7+N4xsTH6jBRfQEPu7GxsRKm36nAxBx8W4QK0RhxUWmdWpW8ZSSWhUSt6O3elwx 2ZFubYQUUKaq+h9Z+6OUzPlGrgzniCbKUALa+kuwJrfRmAWNTcq9Xdpug2IJndqCuyyd ns5Q== Received: by 10.216.132.202 with SMTP id o52mr1507907wei.106.1334930726530; Fri, 20 Apr 2012 07:05:26 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.214.20 with HTTP; Fri, 20 Apr 2012 07:05:11 -0700 (PDT) In-Reply-To: <0B4BE9E8-93E5-45BD-BD6C-8717AF618943@iii.ca> References: <626A389E-CC7E-4EB5-9B55-7B18723A1BCF@tzi.org> <5B365D30-B8F1-4344-A87B-0CE8BF56E401@iii.ca> <0B4BE9E8-93E5-45BD-BD6C-8717AF618943@iii.ca> From: "Angelo P. Castellani" Date: Fri, 20 Apr 2012 16:05:11 +0200 X-Google-Sender-Auth: pSm_LqgAzvKUF2t4R76Se2qBlxU Message-ID: To: Cullen Jennings Content-Type: multipart/alternative; boundary=0016e6d647b2c12e2804be1cc755 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: Fri, 20 Apr 2012 14:05:30 -0000 --0016e6d647b2c12e2804be1cc755 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 20, 2012 at 14:44, Cullen Jennings wrote: > It occurs to me that by defining the stop and wait retransmission time at > 2 seconds, we are already assuming that the max round trip time is perhaps > 2 seconds or perhaps 4 seconds but probably not hugely larger than that. > Yes. However it should be noted that the spec defines that: 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. *plus the expected maximum round trip time* which could be arbitrarily high. How the endpoint emitting the CON knows this "maximum round trip time" is not clear in the current writing. Moreover in the case that this round trip time is very high, all the copies of the messages are always transmitted and if loss rate is low a copy of the ACK will be received for each with varying delay, thus this requires deduplication at the recipient endpoint... Best, Angelo --0016e6d647b2c12e2804be1cc755 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Apr 20, 2012 at 14:44, Cullen Jennings <= span dir=3D"ltr"><fluffy@iii.ca>= wrote:
It occurs to me that by defining the stop and wait retrans= mission time at 2 seconds, we are already assuming that the max round trip = time is perhaps 2 seconds or perhaps 4 seconds but probably not hugely larg= er than that.

Yes. However it should be noted that the s= pec defines that:=C2=A0

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.

*plus the expected maximum round trip time* which could be arbi= trarily high.=C2=A0How the endpoint emitting the CON knows this "maxim= um round trip time" is not clear in the current writing.

Moreover in the case that this round trip time is very = high, all the copies of the messages are always transmitted and if loss rat= e is low a copy of the ACK will be received for each with varying delay, th= us this requires deduplication at the recipient endpoint...

Best,
Angelo
--0016e6d647b2c12e2804be1cc755-- From ari.keranen@nomadiclab.com Fri Apr 20 07:44: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 A122721F872A for ; Fri, 20 Apr 2012 07:44:53 -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 VwoI-EcSiquN for ; Fri, 20 Apr 2012 07:44:52 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id 91D3221F8779 for ; Fri, 20 Apr 2012 07:44:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 577284E6EC; Fri, 20 Apr 2012 17:44:50 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGZARvYpduq7; Fri, 20 Apr 2012 17:44:45 +0300 (EEST) Received: from tri59.nomadiclab.com (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id 193034E6ED; Fri, 20 Apr 2012 17:44:45 +0300 (EEST) Message-ID: <4F91765C.5010000@nomadiclab.com> Date: Fri, 20 Apr 2012 17:44:44 +0300 From: Ari Keranen 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: draft-ietf-core-coap@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: core Subject: [core] draft-ietf-core-coap-09 review 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, 20 Apr 2012 14:44:53 -0000 Hi, Here's a set of review comments on the coap-09 draft. Cheers, Ari 1.2. Terminology Elective Option An option that is intended be ignored by an end-point that does not understand it, which nonetheless still can correctly process the message (Section 5.4.1). This was a bit confusing. Perhaps rephrase into something like: An option that is intended to be ignored by an end-point that does not understand it. Even without understanding the option the end-point can still correctly process the message (Section 5.4.1). 2. Constrained Application Protocol The basic exchanges of the four types of messages are transparent to the request/response interactions. What this means is not clear. I'd rephrase or remove this sentence. 2.2. Request/Response Model Figure 4: Two GET requests with piggy-backed responses, one successful, one not found s/one not found/one resulting in a "not found" error/ (right?) (Note that the detailed semantics of CoAP methods are "almost, but not entirely unlike" those of HTTP methods: Should this be "like" instead of "unlike"? 3.1. Message Format If set to 15, then the number of options is unlimited, and an end-of-options marker is used to indicate no more options. "unlimited" sounds quite strange here, how about: s/number of options is unlimited, and an end-of-options marker is used to indicate no more options/number of options is not indicated in the header but instead with an end-of-options marker (Section 3.2)/ Also in section 3.2. "unlimited" is used in this context. Message ID: 16-bit unsigned integer. Used for the detection of Even if the Message ID is in practice an opaque bit string (right?), you could end up with byte-order problems (say, two different implementations print the value differently and then someone compares the printed values); better to say explicitly that the ID is "in network byte order". 3.2. Option Format The Option Numbers 14, 28, 42, ... are reserved for no-op options when they are sent with an empty value (they are ignored) and can be used as "fenceposts" Maybe this would be better as "The Option Numbers that are multiples of 14 (i.e., 14, 28, 42, ...) are reserved [...]" Also, how about those options with non-empty value? How should one react (ignore option, drop message, error response)? 4.1. Reliable Messages The Message ID is a 16-bit unsigned integer that is generated by the sender of a confirmable message and included in the CoAP header. The rules being same for CON and NON messages, saying here explicitly that the sender of *CON* messages generates the ID is a bit odd. Perhaps the whole ID generation discussion should be earlier in the doc, e.g., in section 4 or 3.1. since it applies to both types. 4.2. Unreliable Messages A sender MAY choose to transmit a non- confirmable message multiple times which, for this purpose, specifies a Message ID as well. Hard to parse this. The sender specifies the Message ID, or the fact that one chooses to transmit confirmable message multiple times does? Also, see the previous comment (is it necessary to talk about the ID here?). 4.4.1. Confirmable (CON) A confirmable message always carries either a request or response and MUST NOT be empty. How to react to empty CON and NON messages? 5.2.2. Separate For a separate exchange, both the acknowledgement to the confirmable request and the acknowledgement to the confirmable response MUST be an empty message, i.e. one that carries neither a request nor a response. Should the receiver still consider non empty (but otherwise OK) ACK as a valid ACK or keep retransmitting? 5.5. Payload Its format is specified by the Internet media type given by the Content-Type Option. No default value is assumed in the absence of this option. ..but the content type must be inferred from the context by the application? 5.7. Proxying All options present in a proxy request MUST be processed at the proxy. But not be forwarded? If the request to the destination returns an response that cannot be processed by the proxy [...] What would qualify as "cannot be processed"? Unrecognized options? Malformed response? 6.2. coaps URI Scheme Resources made available via the "coaps" scheme have no shared identity with the "coap" scheme even if their resource identifiers indicate the same authority (the same host listening to the same UDP port). Is it OK to have coap and coaps URIs pointing to the same UDP port on the same host (i.e., run DTLS and plain CoAP in the same port)? The text seems to imply so. 10. Security Considerations I'd consider moving sections 10-10.2. out of the "Security Considerations" and into a section of their own (called something like "Securing CoAP") and make just the section 10.3. the Security Considerations. The text in 10-10.2. looks like "regular specification text" whereas 10.3. is what I'd expect to see in Security Considerations. 10.1.3. Certificate Mode Implementations in Certificate Mode MUST support the mandatory to implement cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as specified in [RFC5246]. RFC5246 doesn't contain string "TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8". Add at least reference to the right section(s) in RFC5246 and preferably split the cipher suite name in relevant parts to make it clear what actually should be implemented. 11. IANA Considerations I'd suggest "IETF Review or IESG Approval" as the policy for the registries. This way also also non-standards-track RFCs and documents from other SDOs could get values, if IESG thinks it makes sense. 11.3. Media Type Registry Why are the current IDs allocated so sparsely? Is the idea to group similar types with adjacent IDs? Should the reason/policy be mentioned here? From trac+core@trac.tools.ietf.org Fri Apr 20 07:54: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 5C5CD21F8757 for ; Fri, 20 Apr 2012 07:54:45 -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 9GYnJrD68UCo for ; Fri, 20 Apr 2012 07:54:44 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id ADE5D21F85E7 for ; Fri, 20 Apr 2012 07:54:44 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SLFED-0006rE-Mn; Fri, 20 Apr 2012 10:54:29 -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: Fri, 20 Apr 2012 14:54:28 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/219 Message-ID: <051.cfc94b11d618b2c0973e3df850501ffd@trac.tools.ietf.org> X-Trac-Ticket-ID: 219 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: <20120420145444.ADE5D21F85E7@ietfa.amsl.com> Resent-Date: Fri, 20 Apr 2012 07:54:44 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #219: Clarify that observe is about eventual consistency 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, 20 Apr 2012 14:54:45 -0000 #219: Clarify that observe is about eventual consistency Jeroen Hoebeke notes (msg02900): There is a difference between the following: 1. informing a client about every change of the state of a resource: this is what one would expect when just reading the abstract of the draft 2. delivering a client an always fresh representation of a resource (even if the resource did not change): this is what the draft actually implements through the max-age option -> a) observe is indeed about eventual consistency, only, at this point in time We need to ensure that the abstract provides truth in advertising. (See also next ticket.) -- -----------------------------+--------------------------------------- Reporter: cabo@… | Owner: draft-ietf-core-observe@… Type: editorial | Status: new Priority: minor | Milestone: post-WGLC-1 Component: observe | Version: observe-05 Severity: In WG Last Call | Keywords: -----------------------------+--------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Fri Apr 20 07:57: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 1628721F85F4 for ; Fri, 20 Apr 2012 07:57:00 -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 A13rdGySIrUr for ; Fri, 20 Apr 2012 07:56:59 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 18AF821F861D for ; Fri, 20 Apr 2012 07:56:59 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SLFGS-0007YT-5V; Fri, 20 Apr 2012 10:56:48 -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: Fri, 20 Apr 2012 14:56:48 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/220 Message-ID: <051.26bde5f98fc2c31bc73b4e7c8374b34e@trac.tools.ietf.org> X-Trac-Ticket-ID: 220 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: <20120420145659.18AF821F861D@ietfa.amsl.com> Resent-Date: Fri, 20 Apr 2012 07:56:59 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #220: Should observer support time series data? 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, 20 Apr 2012 14:57:00 -0000 #220: Should observer support time series data? Jeroen Hoebeke notes (msg02900): There is a difference between the following: 1. informing a client about every change of the state of a resource: this is what one would expect when just reading the abstract of the draft 2. delivering a client an always fresh representation of a resource (even if the resource did not change): this is what the draft actually implements through the max-age option Having both makes a lot of sense. Draft observe could fulfill both purposes (and would be a good place to do so). If draft observe is only about 1) and the abstract clarifies this, an extension to observe (introducing pledge) for case 2) seems an obvious step. Personally, I am in favor of having this in a single draft. -> Observe currently is about 2 (eventual consistency). What kinds of mechanisms would we need to add to support time series data as in 1? Is the resulting set of changes a desirable addition? -- ----------------------------------+--------------------------------------- Reporter: cabo@… | Owner: draft-ietf-core-observe@… Type: protocol enhancement | Status: new Priority: minor | Milestone: post-WGLC-1 Component: observe | Version: observe-05 Severity: In WG Last Call | Keywords: ----------------------------------+--------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Fri Apr 20 07:58: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 AE69021F8779 for ; Fri, 20 Apr 2012 07:58:15 -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 BQqZBSh9pGOc for ; Fri, 20 Apr 2012 07:58:15 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 5E92D21F8757 for ; Fri, 20 Apr 2012 07:58:14 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SLFHg-0007dp-6c; Fri, 20 Apr 2012 10:58:04 -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: Fri, 20 Apr 2012 14:58:04 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/220#comment:1 Message-ID: <066.5e61a4a1b643a56b4bd0e1ee806e5f06@trac.tools.ietf.org> References: <051.26bde5f98fc2c31bc73b4e7c8374b34e@trac.tools.ietf.org> X-Trac-Ticket-ID: 220 In-Reply-To: <051.26bde5f98fc2c31bc73b4e7c8374b34e@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: <20120420145814.5E92D21F8757@ietfa.amsl.com> Resent-Date: Fri, 20 Apr 2012 07:58:14 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #220: Should observe support time series data? (was: Should observer support time series data?) 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, 20 Apr 2012 14:58:15 -0000 #220: Should observe support time series data? Description changed by cabo@…: Old description: > Jeroen Hoebeke notes (msg02900): > > There is a difference between the following: > > 1. informing a client about every change of the state of a resource: this > is what one would expect when just reading the abstract of the draft > > 2. delivering a client an always fresh representation of a resource (even > if the resource did not change): this is what the draft actually > implements through the max-age option > > Having both makes a lot of sense. Draft observe could fulfill both > purposes (and would be a good place to do so). If draft observe is only > about 1) and the abstract clarifies this, an extension to observe > (introducing pledge) for case 2) seems an obvious step. Personally, I am > in favor of having this in a single draft. > > -> > > Observe currently is about 2 (eventual consistency). What kinds of > mechanisms would we need to add to support time series data as in 1? Is > the resulting set of changes a desirable addition? New description: Jeroen Hoebeke notes (msg02900): There is a difference between the following: 1. informing a client about every change of the state of a resource: this is what one would expect when just reading the abstract of the draft 2. delivering a client an always fresh representation of a resource (even if the resource did not change): this is what the draft actually implements through the max-age option Having both makes a lot of sense. Draft observe could fulfill both purposes (and would be a good place to do so). If draft observe is only about 1) and the abstract clarifies this, an extension to observe (introducing pledge) for case 2) seems an obvious step. Personally, I am in favor of having this in a single draft. -> Observe currently is about 2 (eventual consistency). What kinds of mechanisms would we need to add to support time series data as in 1? Is the resulting set of changes a desirable addition? (see also #219) -- -- ----------------------------------+---------------------------------------- Reporter: cabo@… | Owner: draft-ietf-core-observe@… Type: protocol enhancement | Status: new Priority: minor | Milestone: post-WGLC-1 Component: observe | Version: observe-05 Severity: In WG Last Call | Resolution: Keywords: | ----------------------------------+---------------------------------------- Ticket URL: core From angelo.castellani@gmail.com Fri Apr 20 08:08: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 5E8B421F8778 for ; Fri, 20 Apr 2012 08:08:03 -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 JOiJT2Y89pGg for ; Fri, 20 Apr 2012 08:08:02 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3D14021F8766 for ; Fri, 20 Apr 2012 08:08:02 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so614261wib.13 for ; Fri, 20 Apr 2012 08:08: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 :content-transfer-encoding; bh=9pLwzAX3lZCJnyHfk1VajycHOB0YQW6InhQJ1QoSpMo=; b=r1KuIWpWNhajphdAuqJBg71CF8QYWz+oHBgrBloTzC1viUwWGjlQq7dZnITbA5SHmj iR/1m5ViU333H3tDgVcreCbgQvfnhmU6lg9UTKoyZrt4+LVJp6oKLnbtxOj3K9r3DM6w TX2JeRkXM7ZfxiPOfsGDAO/RPhlUozrkBLRLTdAq7XYFXNs4T4RMn0NJLbImYgw02UmZ bk2NpwBusgwgZl//hAdpZNZuP27AFCGzwLEil3BTfK0+Gu+eTUIXn6eqYocQI7xIbLz/ 8AmsPyxhcWU7ejehlbRtJt7u4RNR9vz7lO9VX5QYPB9QISPrtSG2UJjnVhRc+XAmLsjJ Y5dA== Received: by 10.180.83.198 with SMTP id s6mr15911638wiy.8.1334934481461; Fri, 20 Apr 2012 08:08:01 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.214.20 with HTTP; Fri, 20 Apr 2012 08:07:46 -0700 (PDT) In-Reply-To: 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> <4F8D1EA8.6080800@ericsson.com> From: "Angelo P. Castellani" Date: Fri, 20 Apr 2012 17:07:46 +0200 X-Google-Sender-Auth: DZZfyJ2fYhLjPw5msHbmfFT64Cg Message-ID: To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: core WG 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: Fri, 20 Apr 2012 15:08:03 -0000 EXAMPLE 1 Suppose that in the future there will be the need to standardize a "Date" option, e.g. containing the number of seconds from epoch. That option will probably be elective, so that a client not understanding it silently ignores the date. But why a cache, not knowing this new option, should ignore it as well? Shouldn't be better to save that option together with other options (known) in the cache, and forward them to the client, which is the only recipient of that option? EXAMPLE 2 A minimalistic cache implementation could not know the (still critical) "Content-Type" option, and save its value along with the representation treating them as "opaque binary string". Handling "Content-Type" at a cache is not useful, because it is not required to understand the content of the response, or even if the Content-Type value makes sense or not (in the future more values will be added hopefully). So in this context why should that cache discard that representation? ####### I am personally in favour of having some kind of bit somewhere to distinguish between end-to-end and hop-by-hop options, as others like Cullen and Thomas suggested. Best, Angelo On Fri, Apr 20, 2012 at 14:51, Carsten Bormann wrote: > I would like to see a real-live example for an option that is neither cri= tical nor elective, first. =C2=A0We have had this discussion for a long tim= e, but nobody ever came up with an option that would *need* that third/four= th state. From angelo.castellani@gmail.com Fri Apr 20 08:10:05 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 1EE2521F8795 for ; Fri, 20 Apr 2012 08:10:05 -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=[AWL=-0.000, 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 eslnc2dnjL8r for ; Fri, 20 Apr 2012 08:10:04 -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 5A81221F8794 for ; Fri, 20 Apr 2012 08:10:04 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so626473wib.13 for ; Fri, 20 Apr 2012 08:10:03 -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=ykzenuGLVwmwM47YdpPFtpHj84YQanJlIlcFU8MbJjw=; b=jBS72459y4zhJGz4fa+hoHS96lYAKua9QSx1VoINQzqmJx+pc6fgu6PhIfFYJd5kbJ L9GgE1jybNDLNHYZnhiVgTG2Vsiab+LuA9l/OfYqmYLG166GPyhodrIfkbt9VSAN/Sk4 4XPZ+Lr+RAhAB+58h8PVh5nFfG/ydSevW5AtA4F+pfcPgarKn5HXSFS7ItRqU4uiXEjK fju6UW05etSEefAGxGEVR3HQqXlqY8ItnYAHkzwmHSZUXyphdlObUbyt/qJANTmdAKWL wg/K+pkVM926r+Wm1eUel7n6MEPYZeXo8rGRTvW4I7XV/VxdDM5dlaiM4ytA3JxXRSJ6 rDfQ== Received: by 10.180.95.74 with SMTP id di10mr8862806wib.1.1334934603363; Fri, 20 Apr 2012 08:10:03 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.214.20 with HTTP; Fri, 20 Apr 2012 08:09:48 -0700 (PDT) In-Reply-To: References: <4F8C1A5C.10309@ericsson.com> <4F8C393E.9090403@ericsson.com> <65FED8AA-4B3E-4F57-BE42-982F140D0E07@koanlogic.com> From: "Angelo P. Castellani" Date: Fri, 20 Apr 2012 17:09:48 +0200 X-Google-Sender-Auth: 2pcYkbwVzYR6t_K_V-IKlV8TRyQ Message-ID: To: Klaus Hartke Content-Type: text/plain; charset=UTF-8 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: Fri, 20 Apr 2012 15:10:05 -0000 A failed request, does not ever end in returning "4.02 Bad Option" for a ca= che. In my understanding a cache only stores responses, so it can never emit 4.xx (client error) messages to the server sending the "critical" option in its response. On Mon, Apr 16, 2012 at 20:20, Klaus Hartke wrote: > > =C2=A0 =C2=A0 o Unrecognized options of class "critical" that > =C2=A0 =C2=A0 =C2=A0 =C2=A0occur in a confirmable request MUST cause the > =C2=A0 =C2=A0 =C2=A0 =C2=A0return 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. From cabo@tzi.org Fri Apr 20 08:12:29 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 9990821F8797 for ; Fri, 20 Apr 2012 08:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.021 X-Spam-Level: X-Spam-Status: No, score=-106.021 tagged_above=-999 required=5 tests=[AWL=0.228, 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 C2R0TxzuvIrA for ; Fri, 20 Apr 2012 08:12:29 -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 84B9D21F877A for ; Fri, 20 Apr 2012 08:12:28 -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 q3KFCJIE028567 for ; Fri, 20 Apr 2012 17:12:19 +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 107401CB; Fri, 20 Apr 2012 17:12:19 +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, 20 Apr 2012 17:12:17 +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-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: Fri, 20 Apr 2012 15:12:29 -0000 On Apr 17, 2012, at 02:14, Klaus Hartke wrote: > Do we really need the "obs" link attribute? Today? No. A client can always simply send the Observe option and see what the = server does. (Well, maybe obs also is a hint what *kind* of resource this is.) In the future, we might have a number of extensions like (or unlike) = -observe that a server can offer. I think it is generally better to = clarify the presence or absence of an extension at the discovery stage = than requiring all those extension options (the ones that would make = sense for the client) to be sent with the request. Gr=FC=DFe, Carsten From angelo.castellani@gmail.com Fri Apr 20 08:17: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 296CB21F8786 for ; Fri, 20 Apr 2012 08:17:13 -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 16W2xfaNT0X7 for ; Fri, 20 Apr 2012 08:17:12 -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 7103621F8773 for ; Fri, 20 Apr 2012 08:17:12 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so632572wib.13 for ; Fri, 20 Apr 2012 08:17:11 -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=v5LMsvBlHuhUTty+xOen8Xv5L77RT2/Q8o6kDKPlBoQ=; b=HZ7JQQdwbfiBXhdQk/HQhRLYzgYBfge+VEoi9VHQxqPC+jYV92pTg8dw+yxBf/ufGl npc/ImCp4+Qi5187C5fdfJTo6i+nqUkkuzFwW8ZN/OCWG9QKkj6BJnzosb/+uB2DWX30 97rVmuKb9MWydjUq0gQy8X7g1SKTYTsKMsb9QqyOALUOETSsfmPF27rxIkICFqdVqSvT EpgcDTbosGpIx2KTDAYo6fQXwMPIlUeNsq6Mxhs1NRDPwE9aUw9+/IhSJnJkqcH2jTwY tEiC/4O24vbf7Iikf0zHuwu86gEbk05T2KOAJQfYHuGo7OfqhGpOyY++UlaotGMRTe70 gbRw== Received: by 10.180.95.37 with SMTP id dh5mr9044090wib.8.1334935031599; Fri, 20 Apr 2012 08:17:11 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.214.20 with HTTP; Fri, 20 Apr 2012 08:16:56 -0700 (PDT) In-Reply-To: <051.26bde5f98fc2c31bc73b4e7c8374b34e@trac.tools.ietf.org> References: <051.26bde5f98fc2c31bc73b4e7c8374b34e@trac.tools.ietf.org> From: "Angelo P. Castellani" Date: Fri, 20 Apr 2012 17:16:56 +0200 X-Google-Sender-Auth: mSvpf3rTPRpulfM5pCAd5SaEhmw Message-ID: To: trac+core@trac.tools.ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-core-observe@tools.ietf.org, core@ietf.org Subject: Re: [core] #220: Should observer support time series data? 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, 20 Apr 2012 15:17:13 -0000 On Fri, Apr 20, 2012 at 16:56, core issue tracker wrote: > =C2=A0Observe currently is about 2 (eventual consistency). =C2=A0What kin= ds of > =C2=A0mechanisms would we need to add to support time series data as in 1= ? =C2=A0Is > =C2=A0the resulting set of changes a desirable addition? With (1) a rapidly changing resource will quickly fill network buffers, and lead to congestion collapse... It's not an easy addition in general. In my opinion we need some lower bound on the resource update interval, and some stronger mechanism of congestion control to do this. Angelo From trac+core@trac.tools.ietf.org Fri Apr 20 08:37: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 6ECE421F8766 for ; Fri, 20 Apr 2012 08:37:22 -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 ZFbA2-GVRa5O for ; Fri, 20 Apr 2012 08:37:21 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7F921F8731 for ; Fri, 20 Apr 2012 08:37:21 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SLFtR-0001CL-7c; Fri, 20 Apr 2012 11:37:05 -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: Fri, 20 Apr 2012 15:37:05 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/221 Message-ID: <051.96050ca332dbb50866094e054b75514d@trac.tools.ietf.org> X-Trac-Ticket-ID: 221 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: <20120420153721.8D7F921F8731@ietfa.amsl.com> Resent-Date: Fri, 20 Apr 2012 08:37:21 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #221: Occasionally sending CON is not just a security consideration 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, 20 Apr 2012 15:37:22 -0000 #221: Occasionally sending CON is not just a security consideration Cullen Jennings notes (msg03073a): 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? -> This is currently discussed in the security considerations, but only for NoSec mode. The need to at least occasionally intersperse CONs needs to be discussed earlier (and explained in more detail, msg03073i). Another reason for sending a CON at certain points: Just sending NON for a long time does not guarantee eventual consistency. -- -----------------------------+--------------------------------------- Reporter: cabo@… | Owner: draft-ietf-core-observe@… Type: protocol defect | Status: new Priority: minor | Milestone: post-WGLC-1 Component: observe | Version: observe-05 Severity: In WG Last Call | Keywords: -----------------------------+--------------------------------------- Ticket URL: core From zach@sensinode.com Fri Apr 20 08:38: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 F2ACE21F8731 for ; Fri, 20 Apr 2012 08:38:44 -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 8kxroGXxPG8n for ; Fri, 20 Apr 2012 08:38:44 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id C27E821F85E1 for ; Fri, 20 Apr 2012 08:38:43 -0700 (PDT) Received: from [192.168.1.102] (87-95-14-237.bb.dnainternet.fi [87.95.14.237]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q3KFccF1018290; Fri, 20 Apr 2012 18:38:39 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Fri, 20 Apr 2012 18:38:37 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Klaus Hartke X-Mailer: Apple Mail (2.1084) 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: Fri, 20 Apr 2012 15:38:45 -0000 Hi, I would like to keep the 'obs' link attribute. =46rom the experience = deploying products and systems using CoAP so far, we have actually found = this attribute useful. Two reasons: 1. Although in theory the protocol still works through trial and error = as you describe below, it is useful for a CoAP client to plan its = behavior before making a request. 2. Knowledge of the Observability of a resource is useful at the = application layer, where some M2M application needs to make use of these = resources. The behavior of dealing with a polling-only resource vs. an = observable resource is pretty different, and an observable resource = might result in a different graphical representation to the user which = needs to be known already during discovery. I like the philosophy otherwise for finding things to take away, but not = this one please. Zach On Apr 17, 2012, at 3:14 AM, Klaus Hartke wrote: > 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]: >=20 > Do we really need the "obs" link attribute? >=20 > Some thoughts: >=20 > * 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. >=20 > * 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. >=20 > * If a client wants a single snapshot representation of a resource, it > can omit the Observe option from its request. >=20 > 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? >=20 >=20 > Klaus >=20 >=20 > [1] http://tools.ietf.org/html/rfc1925 > _______________________________________________ > 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 trac+core@trac.tools.ietf.org Fri Apr 20 08:49: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 BAF9421F8726 for ; Fri, 20 Apr 2012 08:49:41 -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 4R5rTgpFbTv9 for ; Fri, 20 Apr 2012 08:49:41 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9F821F8720 for ; Fri, 20 Apr 2012 08:49:40 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SLG5a-0002gM-Qp; Fri, 20 Apr 2012 11:49:38 -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: zach@sensinode.com X-Trac-Project: core Date: Fri, 20 Apr 2012 15:49:38 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/222 Message-ID: <057.f44297cd39b3b1ff3294035adc0e7f16@trac.tools.ietf.org> X-Trac-Ticket-ID: 222 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 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 Cc: core@ietf.org Subject: [core] #222: RawPublicKey identifier 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, 20 Apr 2012 15:49:41 -0000 #222: RawPublicKey identifier During the IETF-83 CoRE meeting a slide was presented on how to close the RawPublicKey identifier issue in the draft. Out of the three options presented (just use the public key, define it in the CoAP draft, define it in some other draft), there was room consensus to define this in a separate draft. Ari Keränen took an action point to work on this draft with other security people, which has been completed and published here: http://tools.ietf.org/html/draft-farrell-decade-ni-03 This ticket proposes the following changes: 1. Remove Appendix D 2. Add the following text to Section 10.1.2 (contributed by Ari, thanks!): Provisioning in RawPublicKey Mode 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. An identifier is calculated from the public key as described in Section 2 of [draft-ni]. All implementations that support checking RawPublicKey identities MUST support at least the sha-256-120 mode (SHA-256 truncated to 120 bits). Implementations SHOULD support also longer length identifiers and MAY support shorter lengths. Note that the shorter lengths provide less security against attacks and their use is NOT RECOMMENDED. Depending on how identifiers are given to the system that verifies them, support for URI, binary, and/or human-readable format [draft-ni] needs to be implemented. All implementations SHOULD support the binary mode and implementations that have a user interface SHOULD also support the human-readable format. During provisioning, the identifier 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 identifiers. These identifiers are then installed in the corresponding end-point, for example an M2M data collection server. The identifier 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 identifiers the device may start DTLS sessions with SHOULD also be installed. -- ----------------------------------+-------------------- Reporter: zach@… | Owner: zach@… Type: protocol enhancement | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: ----------------------------------+-------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Fri Apr 20 08:57: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 24C8921F86B4 for ; Fri, 20 Apr 2012 08:57:45 -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 2-ODyvSOKeX7 for ; Fri, 20 Apr 2012 08:57:44 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id A374121F866A for ; Fri, 20 Apr 2012 08:57:44 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SLGDF-000787-5W; Fri, 20 Apr 2012 11:57: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-observe@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Fri, 20 Apr 2012 15:57:32 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/223 Message-ID: <051.acde5fdaa7ce0628e8cf421bf2db279f@trac.tools.ietf.org> X-Trac-Ticket-ID: 223 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: <20120420155744.A374121F866A@ietfa.amsl.com> Resent-Date: Fri, 20 Apr 2012 08:57:44 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #223: Fix reordering detection condition description 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, 20 Apr 2012 15:57:45 -0000 #223: Fix reordering detection condition description Cullen Jennings notes (msg03073b): 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. -> avoid the term "not fresh" (which we otherwise use for caching considerations!) and replace by "can safely be skipped" as above. -- -----------------------------+--------------------------------------- Reporter: cabo@… | Owner: draft-ietf-core-observe@… Type: editorial | Status: new Priority: minor | Milestone: post-WGLC-1 Component: observe | Version: observe-05 Severity: In WG Last Call | Keywords: -----------------------------+--------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Fri Apr 20 09:01: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 BC34021F863B for ; Fri, 20 Apr 2012 09:01:41 -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 G5+zd77NyV9y for ; Fri, 20 Apr 2012 09:01:41 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2A521F8598 for ; Fri, 20 Apr 2012 09:01:40 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SLGH3-0003WY-3i; Fri, 20 Apr 2012 12:01:29 -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: Fri, 20 Apr 2012 16:01:29 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/224 Message-ID: <051.7d125c7c9032a5950eb61f480c23f91a@trac.tools.ietf.org> X-Trac-Ticket-ID: 224 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: <20120420160141.3A2A521F8598@ietfa.amsl.com> Resent-Date: Fri, 20 Apr 2012 09:01:40 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #224: Comments 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, 20 Apr 2012 16:01:41 -0000 #224: Comments Cullen Jennings notes (msg03073c): 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. -> Clarify that "client" here is a subclass of "endpoint", which is identified by its transport address (IP address/port) and security association. -- -----------------------------+--------------------------------------- Reporter: cabo@… | Owner: draft-ietf-core-observe@… Type: editorial | Status: new Priority: minor | Milestone: post-WGLC-1 Component: observe | Version: observe-05 Severity: In WG Last Call | Keywords: -----------------------------+--------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Fri Apr 20 09:06: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 58CC821F8759 for ; Fri, 20 Apr 2012 09:06: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 lCc6sKcGu9it for ; Fri, 20 Apr 2012 09:06:57 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id D3A5D21F8748 for ; Fri, 20 Apr 2012 09:06:57 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SLGMA-0007To-LL; Fri, 20 Apr 2012 12:06:46 -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: Fri, 20 Apr 2012 16:06:46 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/204#comment:2 Message-ID: <066.5993a8a45550ffca1ac4c8d8f558003f@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: <20120420160657.D3A5D21F8748@ietfa.amsl.com> Resent-Date: Fri, 20 Apr 2012 09:06:57 -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: Fri, 20 Apr 2012 16:06:58 -0000 #204: Introduce a minimal version of Pledge Comment (by cabo@…): Cullen comments (msg03073d): 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. -> editorially separate the concepts of max-age (cache freshness) and pledge. For now, both have the same value, but future extensions might provide options to give them different values. -- ----------------------------------+---------------------------------------- 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 trac+core@trac.tools.ietf.org Fri Apr 20 09:13: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 56FC821F8764 for ; Fri, 20 Apr 2012 09:13:57 -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 gWlOdTioIvEc for ; Fri, 20 Apr 2012 09:13:56 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id CA44C21F8773 for ; Fri, 20 Apr 2012 09:13:56 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SLGSp-0000hf-Gd; Fri, 20 Apr 2012 12:13:39 -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: Fri, 20 Apr 2012 16:13:39 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/225 Message-ID: <051.8dc4d4529b0eb768972bc70c3c71cca2@trac.tools.ietf.org> X-Trac-Ticket-ID: 225 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: <20120420161356.CA44C21F8773@ietfa.amsl.com> Resent-Date: Fri, 20 Apr 2012 09:13:56 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #225: Explain why it is not always possible to react to a RST that is in reply to a NON 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, 20 Apr 2012 16:13:57 -0000 #225: Explain why it is not always possible to react to a RST that is in reply to a NON Cullen Jennings notes (msg03073e): Last paragraph of section 4.2 says MAY remove but I think this needs to be a MUST remove. -> No, this is indeed intended to be MAY. We want to make the need to store state for a NON optional. A sender of a NON message may discard the MID state for that message whenever it wants. That may make acting on a RST to that MID impossible. Hence MAY. -> change the wording to make it clearer that we expect (as a quality of implementation issue) a server that still happens to have the state to also react to the RST. -- -----------------------------+--------------------------------------- Reporter: cabo@… | Owner: draft-ietf-core-observe@… Type: editorial | Status: new Priority: minor | Milestone: post-WGLC-1 Component: observe | Version: observe-05 Severity: In WG Last Call | Keywords: -----------------------------+--------------------------------------- Ticket URL: core From cabo@tzi.org Fri Apr 20 09:34: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 4D90921F872B for ; Fri, 20 Apr 2012 09:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.034 X-Spam-Level: X-Spam-Status: No, score=-106.034 tagged_above=-999 required=5 tests=[AWL=0.215, 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 1iQNbECQP7x0 for ; Fri, 20 Apr 2012 09:34: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 783B221F872A for ; Fri, 20 Apr 2012 09:34:21 -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 q3KGYBVm025213; Fri, 20 Apr 2012 18:34:11 +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 373FC215; Fri, 20 Apr 2012 18:34:11 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <1DC55BCC-78E1-42A0-BC36-1AB842E34034@cisco.com> Date: Fri, 20 Apr 2012 18:34:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1DC55BCC-78E1-42A0-BC36-1AB842E34034@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1257) Cc: core WG Subject: Re: [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: Fri, 20 Apr 2012 16:34:22 -0000 On Apr 18, 2012, at 06:58, Cullen Jennings wrote: > 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 I think that is an essential requirement if we have the aborting = mechanism in place (which, in turn, I think is also an essential = requirement). Imagine the client goes away. Without this, if a server has a new value for the resource every five = seconds, it will send the new value and set back the binary exponential = back-off to the first attempt. It will 1) send retransmission packets at a rate of a packet every 2.5 seconds = (OK, that is not yet a disaster) 2) it will never notice the client is gone. Gr=FC=DFe, Carsten From lohse@itm.uni-luebeck.de Fri Apr 20 09:44: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 8A4E621F865B for ; Fri, 20 Apr 2012 09:44:56 -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 7Pn0tIubaTS0 for ; Fri, 20 Apr 2012 09:44:56 -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 B319621F8659 for ; Fri, 20 Apr 2012 09:44:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQFAJ6RkU+NU0Rk/2dsb2JhbABEgxyuHIEHggkBAQEEAQEBawoRCxgJFg8JAwIBAgEVMAYNBgIBAYgPB7sCBJBnBJttikmCaQ Received: from itm01.itm.uni-luebeck.de ([141.83.68.100]) by ip1.rz.uni-luebeck.de with ESMTP; 20 Apr 2012 18:44:54 +0200 Received: from [192.168.178.21] (p5B269030.dip0.t-ipconnect.de [91.38.144.48]) (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 D5CFB83F8E3 for ; Fri, 20 Apr 2012 18:44:53 +0200 (CEST) Message-ID: <4F919240.3010401@itm.uni-luebeck.de> Date: Fri, 20 Apr 2012 18:43:44 +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" References: <4F8DFF3D.50201@itm.uni-luebeck.de> <085E1C1D-4E7B-4494-9B75-D9BFC487A261@iii.ca> In-Reply-To: <085E1C1D-4E7B-4494-9B75-D9BFC487A261@iii.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Fri, 20 Apr 2012 16:44:56 -0000 Glad to be of help, however, that didn't answer my question...? :D Although, looking at issue #212 I might hazard a guess... Regards, - Stephan On 18/04/12 17:20, Cullen Jennings wrote: > > 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 tho@koanlogic.com Fri Apr 20 11:03: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 B2E9E21F85E1 for ; Fri, 20 Apr 2012 11:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.275 X-Spam-Level: X-Spam-Status: No, score=-2.275 tagged_above=-999 required=5 tests=[AWL=0.324, 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 g1R9pIv2Isbj for ; Fri, 20 Apr 2012 11:03:14 -0700 (PDT) Received: from gonzo.koanlogic.com (koanlogic.com [64.251.31.111]) by ietfa.amsl.com (Postfix) with ESMTP id E8F9121F8573 for ; Fri, 20 Apr 2012 11:03:13 -0700 (PDT) Received: from chello062178222142.13.15.univie.teleweb.at ([62.178.222.142]:57599 helo=[192.168.0.11]) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1SLIAj-0007iS-EW; Fri, 20 Apr 2012 14:03:12 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: <232DD51A-3CC7-4E66-99F7-B7E9908915F7@tzi.org> Date: Fri, 20 Apr 2012 20:02:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4CA7D58E-B551-4F2D-8235-9E3407D8F770@koanlogic.com> References: <55DA56AE-0790-4116-96CB-A96CD99AC088@koanlogic.com> <232DD51A-3CC7-4E66-99F7-B7E9908915F7@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 Subject: Re: [core] s/one/many/ virtual interim ? 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, 20 Apr 2012 18:03:15 -0000 Carsten, On Apr 20, 2012, at 1:04 PM, Carsten Bormann wrote: > I don't think we can officially split off subgroups very well here. > That of course doesn't mean that, e.g. some of the authors, would mind = having a phone call or two on an informal (IETF term: hallway) level. >=20 > I for one plan to do a couple of Google+ hangouts once we have got = further in processing the WGLC comments. (This is just a personal = thing, imagine gathering in the IETF hallway, nothing will be decided, = but high-bandwidth back and forth can help information flow more = efficiently.) this is perfectly fine for me. My proposal was meant to just make sure = that we, as WG, can do everything possible to help authors to digest the = flood of WGLC comments. If you think you have enough spare = cycles/energy to handle the process, that's great. > While we are doing this, we may be suggesting solutions in the tickets = already created (some comments already contained solutions). If a = ticket has been carrying a solution for a couple of days without further = discussion, we may close it by applying the solution. > E.g., #208 was closed yesterday -- you had suggested text, and, with = minor adaptations, that is now in the SVN. >=20 > All changes to the tickets are echoed to the mailing list. That may = seem a bit arduous at first, but it is really useful. > Please do pay close attention to what is going on with the tickets. = This will enable the authors to do a -10/-09/-06 that will have = successfully resolved the existing comments. Ok.= From lishitao@huawei.com Fri Apr 20 18:49: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 D786B11E8080 for ; Fri, 20 Apr 2012 18:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] 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+KqTUp+lhP3 for ; Fri, 20 Apr 2012 18:49:49 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5F011E8073 for ; Fri, 20 Apr 2012 18:49:49 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFK07717; Fri, 20 Apr 2012 21:49:49 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 20 Apr 2012 18:47:46 -0700 Received: from SZXEML425-HUB.china.huawei.com (10.72.61.33) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 20 Apr 2012 18:47:48 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.43]) by szxeml425-hub.china.huawei.com ([10.72.61.33]) with mapi id 14.01.0323.003; Sat, 21 Apr 2012 09:47:47 +0800 From: Lishitao To: Carsten Bormann Thread-Topic: [core] wglc: coap caching and observe, caching underspecified Thread-Index: AQHNG9J9fc9f+ucq3Eya3xKW4wA2vJadBy0AgAAElQCAAAyFgIAAG0eAgAAJ3YCAACSbAIAAV+CAgABY1ACAAAqDAIAFCwoAgAAChgCAAV7qcA== Date: Sat, 21 Apr 2012 01:47:47 +0000 Message-ID: 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> <4F8D1EA8.6080800@ericsson.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.73.39] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: core WG Subject: [core] =?utf-8?b?562U5aSNOiAgd2dsYzogY29hcCBjYWNoaW5nIGFuZCBvYnNl?= =?utf-8?q?rve=2C_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: Sat, 21 Apr 2012 01:49:54 -0000 Q2Fyc3Rlbg0KDQpJIHRoaW5rIGF0IGxlYXN0IHRoZSBwcm94eSBuZWVkcyB0byB1bmRlcnN0YW5k IHRoZSBPYnNlcnZlIG9wdGlvbiwgc28gaXQgY2FuIGRpc3Rpbmd1aXNoIGEgbm9ybWFsIGdldCBy ZXF1ZXN0IGFuZCBhbiBvYnNlcnZlciByZXF1ZXN0LiANCg0KT3RoZXIgZXhhbXBsZSwgbGlrZSB3 aGF0IHdlIGRpZCByaWdodCBub3cgZm9yIHRoZSBDb25kaXRpb24gb3B0aW9uIChpbiBkcmFmdC1s aS1jb3JlLWNvbmRpdGlvbmFsLW9ic2VydmUtMDEpLCB0aGUgcHJveHkgYWxzbyBuZWVkcyB0byB1 bmRlcnN0YW5kaW5nIHRoaXMgb3B0aW9uLCANCg0Kc28gaXQgd2lsbCBub3QgY29tYmluZSB0aG9z ZSByZXF1ZXN0cyB3aXRoIGRpZmZlcmVudCBjb25kaXRpb25zIGJ1dCB0byB0aGUgc2FtZSByZXNv dXJjZSB0b2dldGhlci4NCg0KVGhlIHVzYWdlIG9mIG9ic2VydmUgbWVjaGFuaXNtIGlzIGRpZmZl cmVudCBmcm9tIEhUVFAgKEhUVFAgZG9lcyBub3QgaGF2ZSB0aGlzKSwgc28gd2hlbiB3ZSBkZWZp bmUgY2FjaGluZyBmb3IgY29hcCwgYSBzcGVjaWFsIGNvbnNpZGVyYXRpb24gb3Igc3BlY2lhbCBw cm9jZXNzaW5nIG1pZ2h0IGJlIG5lZWRlZC4NCg0Kc2hpdGFvDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2 LS0tLS0NCuWPkeS7tuS6ujogY29yZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y29yZS1ib3Vu Y2VzQGlldGYub3JnXSDku6PooaggQ2Fyc3RlbiBCb3JtYW5uDQrlj5HpgIHml7bpl7Q6IDIwMTLl ubQ05pyIMjDml6UgMjA6NTENCuaUtuS7tuS6ujogQ3VsbGVuIEplbm5pbmdzDQrmioTpgIE6IGNv cmUgV0cNCuS4u+mimDogUmU6IFtjb3JlXSB3Z2xjOiBjb2FwIGNhY2hpbmcgYW5kIG9ic2VydmUs IGNhY2hpbmcgdW5kZXJzcGVjaWZpZWQNCg0KT24gQXByIDIwLCAyMDEyLCBhdCAxNDo0MiwgQ3Vs bGVuIEplbm5pbmdzIHdyb3RlOg0KDQo+IA0KPiBUaGlzIHRocmVhZCBzZWVtcyB0byBiZSBsZWFk aW5nIHRvd2FyZHMgYSBzZXBhcmF0ZSBiaXQgaW4gdGhlIG9wdGlvbiB0aGF0IGluZGljYXRlcyBp ZiBhIHByb3h5IG5lZWRzIHRvIHVuZGVyc3RhbmQgdGhlIG9wdGlvbiBvciBub3QuIE5vdCBzdXJl IHdoYXQgSSB0aGluayBvZiB0aGF0IGlkZWEgYnV0IGl0IHdvdWxkIGJlIG9uZSBwb3NzaWJpbGl0 eSB0byBjb25zaWRlci4gDQoNCkkgd291bGQgbGlrZSB0byBzZWUgYSByZWFsLWxpdmUgZXhhbXBs ZSBmb3IgYW4gb3B0aW9uIHRoYXQgaXMgbmVpdGhlciBjcml0aWNhbCBub3IgZWxlY3RpdmUsIGZp cnN0LiAgV2UgaGF2ZSBoYWQgdGhpcyBkaXNjdXNzaW9uIGZvciBhIGxvbmcgdGltZSwgYnV0IG5v Ym9keSBldmVyIGNhbWUgdXAgd2l0aCBhbiBvcHRpb24gdGhhdCB3b3VsZCAqbmVlZCogdGhhdCB0 aGlyZC9mb3VydGggc3RhdGUuDQoNCkdyw7zDn2UsIENhcnN0ZW4NCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmNvcmUgbWFpbGluZyBsaXN0DQpjb3Jl QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCg== From stephen.farrell@cs.tcd.ie Fri Apr 20 19: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 E6A3B11E8073 for ; Fri, 20 Apr 2012 19:20:47 -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 sWGDo1HgobCF for ; Fri, 20 Apr 2012 19:20:43 -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 01A4421F84BF for ; Fri, 20 Apr 2012 19:20:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 48ABC17147D; Sat, 21 Apr 2012 03:20:42 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1334974837; bh=AZ37c0IKzRLHwh iGc3A1w5pOn863TAAw6NrQGeTJMLw=; b=xAuTmoCr7ml4CZvAcMvqgDS4aVo2jM 54FIEEumdkJsM9y87fwVywpDPCEMNHwuz8xF9lwhhvOBUowgj/evbiUoQTAEHSpw AGH8c4tw78fWr6jOCVtQwx1cQ//Gd/9WTe5/RTy1lEFiUaW0EEya7KH+1FB0STlF ruy6ma0tcLU1fHmhJMHNdto2Rg33NW/st/ite88hHq5k9CJUPexOQ+D1imsonj+C gfZXoEw4o3Suga/WzYq82kJQOv2mwU1wfU9kQ7N707Muo/nmXcEY2ruDPHpG5+qq ierPg45m7wedMo2vlcOubfr9wnKIezKjNbWomNy6BLsmCd75iw+lr+8Q== 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 ei2PQDWFvH9H; Sat, 21 Apr 2012 03:20:37 +0100 (IST) Received: from [1.202.85.154] (unknown [1.202.85.154]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 4FEBA171474; Sat, 21 Apr 2012 03:20:33 +0100 (IST) Message-ID: <4F92196E.9000701@cs.tcd.ie> Date: Sat, 21 Apr 2012 03:20:30 +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: Thomas Fossati 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> <4F8D1EA8.6080800@ericsson.com> <68B487AC-7384-4B75-9E1F-32CB8454D2F0@koanlogic.com> In-Reply-To: <68B487AC-7384-4B75-9E1F-32CB8454D2F0@koanlogic.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: core WG 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: Sat, 21 Apr 2012 02:20:48 -0000 Hi, On 04/20/2012 02:23 PM, Thomas Fossati wrote: > Carsten, > > On Apr 20, 2012, at 2:51 PM, Carsten Bormann wrote: >>> This thread seems to be leading towards a separate bit in the option that indicates if a proxy needs to understand the option or not. Not sure what I think of that idea but it would be one possibility to consider. >> >> I would like to see a real-live example for an option that is neither critical nor elective, first. We have had this discussion for a long time, but nobody ever came up with an option that would *need* that third/fourth state. > > the issue here is that we need a way to distinguish end-to-end from hop-by-hop semantics in options, otherwise proxies can't cooperate in making CoAP networks scale. > > I don't mind if we want to do that with an explicit bit, or by some implicit rule -- as I proposed previously in this same thread -- but we need to do that. > > The current caching rule set treats an intermediary the same way as an endpoint, forcing a flow to break at a forwarder whenever some end-to-end semantics is not understood. And this is plain wrong. So I've no real opinion as to whether this extra bit is needed/useful or not, but if its added then it'll need to play well with how DTLS is done. Be a shame to accidentally muck things up embedding some hop-by-hop option into something secured end-to-end. I would guess that any solution here that isn't "don't use hop-by-hop options if you need (e2e) security" will be fairly complex. S > > We don't know how much CoAP will need to scale, but embedding such a limitation in the core protocol is something that we could regret. > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From hartke@tzi.org Fri Apr 20 19:52: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 DBE1D21E8019 for ; Fri, 20 Apr 2012 19:52:57 -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 OpUdSJFKYJPm for ; Fri, 20 Apr 2012 19:52: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 2794221E8013 for ; Fri, 20 Apr 2012 19:52: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 q3L2qlWj005393 for ; Sat, 21 Apr 2012 04:52:47 +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 0BDAD282 for ; Sat, 21 Apr 2012 04:52:46 +0200 (CEST) Received: by dady13 with SMTP id y13so18395442dad.27 for ; Fri, 20 Apr 2012 19:52:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.224.228 with SMTP id rf4mr17432315pbc.22.1334976764756; Fri, 20 Apr 2012 19:52:44 -0700 (PDT) Received: by 10.68.23.37 with HTTP; Fri, 20 Apr 2012 19:52:44 -0700 (PDT) In-Reply-To: References: Date: Sat, 21 Apr 2012 04:52:44 +0200 Message-ID: From: Klaus Hartke To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 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: Sat, 21 Apr 2012 02:52:58 -0000 Zach Shelby wrote: > The behavior of dealing with a polling-only resource vs. an observable resource is pretty different, and an observable resource might result in a different graphical representation to the user which needs to be known already during discovery. That's an aspect I hadn't considered so far and find very useful. Maybe we could expand section 7 of -observe a bit to give advice in this direction? Klaus From hartke@tzi.org Fri Apr 20 19:54: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 C12BF21E8013 for ; Fri, 20 Apr 2012 19:54:54 -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 4vwrUxSY0okO for ; Fri, 20 Apr 2012 19:54:54 -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 D60BF21E8011 for ; Fri, 20 Apr 2012 19:54:53 -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 q3L2siZj006419 for ; Sat, 21 Apr 2012 04:54:44 +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 4F10F283 for ; Sat, 21 Apr 2012 04:54:44 +0200 (CEST) Received: by dady13 with SMTP id y13so18397179dad.27 for ; Fri, 20 Apr 2012 19:54:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.226.133 with SMTP id rs5mr4552715pbc.85.1334976882296; Fri, 20 Apr 2012 19:54:42 -0700 (PDT) Received: by 10.68.23.37 with HTTP; Fri, 20 Apr 2012 19:54:42 -0700 (PDT) In-Reply-To: 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> <4F8D1EA8.6080800@ericsson.com> Date: Sat, 21 Apr 2012 04:54:42 +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: Sat, 21 Apr 2012 02:54:54 -0000 Cullen Jennings wrote: > This thread seems to be leading towards a separate bit in the option that indicates if a proxy needs to understand the option or not. Not sure what I think of that idea but it would be one possibility to consider. Picking up Thomas Fossati's suggestion of forwarding unrecognised options, I could imagine a bit that says "this option can be safely forwarded by an intermediary that doesn't understand it". With such a bit, specifying out-of-band whether an option is part of the cache key doesn't work any longer, so I guess we'd need another bit that says "this option is part of the cache key". Klaus From hartke@tzi.org Fri Apr 20 20:02:29 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 4D15021E8019 for ; Fri, 20 Apr 2012 20:02:29 -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 KZDlEbowsPTY for ; Fri, 20 Apr 2012 20:02:28 -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 7F15321E8013 for ; Fri, 20 Apr 2012 20:02:28 -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 q3L32JIx012392 for ; Sat, 21 Apr 2012 05:02:19 +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 E896F284 for ; Sat, 21 Apr 2012 05:02:18 +0200 (CEST) Received: by pbbrp16 with SMTP id rp16so1747546pbb.31 for ; Fri, 20 Apr 2012 20:02:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.204.9 with SMTP id ku9mr17437355pbc.1.1334977336924; Fri, 20 Apr 2012 20:02:16 -0700 (PDT) Received: by 10.68.23.37 with HTTP; Fri, 20 Apr 2012 20:02:16 -0700 (PDT) In-Reply-To: References: <4F8C1A5C.10309@ericsson.com> <4F8C393E.9090403@ericsson.com> <65FED8AA-4B3E-4F57-BE42-982F140D0E07@koanlogic.com> Date: Sat, 21 Apr 2012 05:02:16 +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: Sat, 21 Apr 2012 03:02:29 -0000 Angelo P. Castellani wrote: > A failed request, does not ever end in returning "4.02 Bad Option" for a cache. > > In my understanding a cache only stores responses, so it can never > emit 4.xx (client error) messages to the server sending the "critical" > option in its response. Assume you have a client, a proxy with cache, and a server: If the client makes a request to the proxy with a critical option that the proxy does not understand, the proxy returns a 4.02 (Bad Option) response to the client. If the client makes a request to the proxy that the proxy understands and the proxy makes a request to the server with a critical option that the server does not understand, the server returns a 4.02 (Bad Option) response to the proxy and the proxy in turn returns a 5.02 (Bad Gateway) response to the client. (This is all defined in section 5.7.) So you are right that the proxy never sends a 4.02 (Bad Option) response to the server in reply to a response. The quoted text also doesn't say that: it's only a confirmable *request* that MUST cause the return of a 4.02 (Bad Option) response. (Section 5.4.1.) Klaus From hartke@tzi.org Fri Apr 20 20:06: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 C33FA21F8512 for ; Fri, 20 Apr 2012 20:06:26 -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 0f4gWWul-D6N for ; Fri, 20 Apr 2012 20:06:26 -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 03A9F21F84F1 for ; Fri, 20 Apr 2012 20:06:25 -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 q3L36Hx5014544 for ; Sat, 21 Apr 2012 05: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 D1DC9285 for ; Sat, 21 Apr 2012 05:06:16 +0200 (CEST) Received: by pbbrp16 with SMTP id rp16so1749865pbb.31 for ; Fri, 20 Apr 2012 20:06:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.226.133 with SMTP id rs5mr4612891pbc.85.1334977574787; Fri, 20 Apr 2012 20:06:14 -0700 (PDT) Received: by 10.68.23.37 with HTTP; Fri, 20 Apr 2012 20:06:14 -0700 (PDT) In-Reply-To: <4F919240.3010401@itm.uni-luebeck.de> References: <4F8DFF3D.50201@itm.uni-luebeck.de> <085E1C1D-4E7B-4494-9B75-D9BFC487A261@iii.ca> <4F919240.3010401@itm.uni-luebeck.de> Date: Sat, 21 Apr 2012 05:06:14 +0200 Message-ID: From: Klaus Hartke To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 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: Sat, 21 Apr 2012 03:06:26 -0000 Stephan Lohse wrote: > Glad to be of help, however, that didn't answer my question...? :D > Although, looking at issue #212 I might hazard a guess... Ticket #212 is about the option *number* 14 (and option numbers that are multiples of 14), not the option *delta* 14. The option *delta* 15 is special in that it is used as the end-of-option marker -- if and only if (a) the 'oc' field in the message header is set to 15 and (b) the 'length' field in the option header is set to 0. So using 15 as a delta is fine as long 'oc' is not 15 or 'length' is not 0. (This is what coap-09 says at moment. I think the length constraint should be dropped.) Klaus From hartke@tzi.org Fri Apr 20 20:25: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 0E28F21F84FB for ; Fri, 20 Apr 2012 20:25: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 1xShf18oe3Wa for ; Fri, 20 Apr 2012 20:25: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 490DF21F84B8 for ; Fri, 20 Apr 2012 20:25: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 q3L3PP84026575 for ; Sat, 21 Apr 2012 05:25:25 +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 08FFD287 for ; Sat, 21 Apr 2012 05:25:24 +0200 (CEST) Received: by dady13 with SMTP id y13so18427202dad.27 for ; Fri, 20 Apr 2012 20:25:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.195.163 with SMTP id if3mr9516678pbc.127.1334978723002; Fri, 20 Apr 2012 20:25:23 -0700 (PDT) Received: by 10.68.23.37 with HTTP; Fri, 20 Apr 2012 20:25:22 -0700 (PDT) In-Reply-To: References: <6029ED8C-2341-4199-A439-F0DB02A55DA4@koanlogic.com> Date: Sat, 21 Apr 2012 05:25:22 +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-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, 21 Apr 2012 03:25:35 -0000 Hi Zach, On 15 April 2012 19:47, Zach Shelby wrote: > What this means in practice is that the target for this relation has to b= e on the same origin server. The result is that if the target is an absolut= e URI, then the host part should be interpreted as a virtual host name (and= thus should be included in the Uri-Host option). [...]=A0There is no reaso= n your virtual host name couldn't be really short though and thus just as e= fficient as using the Uri-Host field. Do you mean a server like "sensor1.example.com" could advertise a virtual host "xy" rather than "temp.sensor1.example.com" in its well-known core? What happens when two different servers both advertise a virtual host "xy"? Can a client with a cache use a stored response that is the result of retrieving resource "/res" of virtual host "xy" at [2001:DB8::abcd] to satisfy a request for resource "/res" of virtual host "xy" at [2001:DB8::9999]? The request URI is in both cases. Klaus From zach@sensinode.com Fri Apr 20 23:27: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 AB5C121F85A5 for ; Fri, 20 Apr 2012 23:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=0.600, 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 zG0caLwefbeK for ; Fri, 20 Apr 2012 23:27: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 8F80B21F85A4 for ; Fri, 20 Apr 2012 23:27:45 -0700 (PDT) Received: from [192.168.1.102] (87-93-1-88.bb.dnainternet.fi [87.93.1.88]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q3L6Rfdf016368; Sat, 21 Apr 2012 09:27:42 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Sat, 21 Apr 2012 09:27:41 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6C8DF5A0-F915-48F1-B5CB-C20F5851AC2C@sensinode.com> References: To: Klaus Hartke X-Mailer: Apple Mail (2.1084) 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: Sat, 21 Apr 2012 06:27:51 -0000 On Apr 21, 2012, at 5:52 AM, Klaus Hartke wrote: > Zach Shelby wrote: >> The behavior of dealing with a polling-only resource vs. an = observable resource is pretty different, and an observable resource = might result in a different graphical representation to the user which = needs to be known already during discovery. >=20 > That's an aspect I hadn't considered so far and find very useful. >=20 > Maybe we could expand section 7 of -observe a bit to give advice in > this direction? Sure. A couple sentences on where an indication of 'obs' can be useful = is a good addition.=20 Zach --=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 zach@sensinode.com Fri Apr 20 23:40:05 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 194C121E802A for ; Fri, 20 Apr 2012 23:40:05 -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.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 EVlow0aS0Zer for ; Fri, 20 Apr 2012 23:40:00 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id D45D021E8020 for ; Fri, 20 Apr 2012 23:39:59 -0700 (PDT) Received: from [192.168.1.102] (87-93-1-88.bb.dnainternet.fi [87.93.1.88]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q3L6dv5G017036; Sat, 21 Apr 2012 09:39:57 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Sat, 21 Apr 2012 09:39:56 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6029ED8C-2341-4199-A439-F0DB02A55DA4@koanlogic.com> To: Klaus Hartke X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org 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, 21 Apr 2012 06:40:05 -0000 On Apr 21, 2012, at 6:25 AM, Klaus Hartke wrote: > Hi Zach, >=20 > On 15 April 2012 19:47, Zach Shelby wrote: >> 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). [...] 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. >=20 > Do you mean a server like "sensor1.example.com" could advertise a > virtual host "xy" rather than "temp.sensor1.example.com" in its > well-known core? There is no "sensor1.example.com" in the first place as you are not = using DNS in this case. The origin server in this example would be = identified by [2001:DB8::abcd]:5683. If /.well-known/core returns a link = then maybe a cache should identify that as = coap://xy.[2001:DB8::abcd]/res or in some other way associated with the = IP address:port as this is the only unique identifier it could possibly = have for the server. I do agree that is a bit awkward, other ideas? Zach >=20 > What happens when two different servers both advertise a virtual host > "xy"? Can a client with a cache use a stored response that is the > result of retrieving resource "/res" of virtual host "xy" at > [2001:DB8::abcd] to satisfy a request for resource "/res" of virtual > host "xy" at [2001:DB8::9999]? The request URI is in > both cases. >=20 >=20 > Klaus > _______________________________________________ > 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 zach@sensinode.com Fri Apr 20 23:51: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 96EA221F853E for ; Fri, 20 Apr 2012 23:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 hdw6vnxGXa02 for ; Fri, 20 Apr 2012 23:51:19 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 3511021F853C for ; Fri, 20 Apr 2012 23:51:17 -0700 (PDT) Received: from [192.168.1.102] (87-93-1-88.bb.dnainternet.fi [87.93.1.88]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q3L6pDNQ017660; Sat, 21 Apr 2012 09:51:14 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <5961B851-CBE9-445D-945A-2FC800A9667E@iii.ca> Date: Sat, 21 Apr 2012 09:51:12 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <91B1300E-F3A2-4672-8715-A0C006990DEB@sensinode.com> References: <001b01cced71$c60c8b60$5225a220$@uni-rostock.de> <07CC0900-8116-4242-AB96-D74879E247D8@tzi.org> <001e01cced78$e09dd400$a1d97c00$@uni-rostock.de> <73456E11-9651-4FB8-82E3-1CBC490C55DF@tzi.org> <4F3E758B.8020007@stpeter.im> <000f01ccedb0$cd0fe620$672fb260$@uni-rostock.de> <5961B851-CBE9-445D-945A-2FC800A9667E@iii.ca> To: Cullen Jennings X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org Subject: Re: [core] EXI content type and encoding (was: Resolution to tickets #176, #177, #181) 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, 21 Apr 2012 06:51:23 -0000 Cullen, Guido, There has been a long discussion on this over on the apps area discuss = list (including W3C folks), and if you have an opinion on this it is = probably best to speak up there. Right now we are basically stuck in the = conversation as it seems Schema-informed mode use of EXI is not a valid = content-encoding but nor is it a valid media type suffix according to = the media type experts. So it falls between the cracks. =20 Instead we are now looking at the use of an informal naming like = application/senml-exi where there is no structured suffix exactly, but = this still means EXI for the application. What we are now trying to = figure out is what to day about that in the media type registration. = This means at least the SenML media type registration needs an update.=20= Anyways, let's continue that discussion over on the apps area list if = needed. Zach=20 On Apr 20, 2012, at 3:46 PM, Cullen Jennings wrote: >=20 > =46rom a pragmatic point of view, regardless of what you think the = relation between EXI and XML is I'm very much in favor of CoAP having = content-type value along the lines of =20 >=20 > application/se+exi=20 >=20 >=20 > On Feb 17, 2012, at 1:14 PM, Guido Moritz wrote: >=20 >>> I am not an EXI expert, but my understanding from a conversation = with >>> Zach in Taipei (and afterward on the apps-discuss list) is that one >>> could see EXI as either (1) a content-encoding of XML or (2) a new = and >>> different content-type. The matter isn't settled, but it would be = good >>> to settle it. :) >>=20 >> I also had to think about this issue for a while, because I have to = explain the differences and perspectives as part of my Phd thesis...keep = fingers cross to have finished it before Paris ;). Overall I concluded = in (2) and describe EXI as a completely new and different = 'content-type', i.e. 'on wire encoding' of XML-Infoset serialized object = structures. >>=20 >> I think how and why people favor one of the two options is how they = use it. There are applications/implementations that are already using = XML and to save bandwidth now the data stream is changed for several = parts/communications into the EXI format. In this use case, EXI can even = be a compressor, i.e. compression is the process changing the data = representation to a more efficient one. But because their = applications/implementations are still parsing and processing native = Unicode XML, EXI is just another encoding for the existing XML = structures. =46rom this perspective absolutely feasibly to favor (1).=20 >>=20 >> But EXI is, in contrast to e.g. gzip, also capable to be a standalone = representation that can be parsed and processed directly by the = implementations. This is how the EXI format was designed by the W3C, as = a complete replacement for Unicode XML if required. In this case there = is no need to change EXI to XML to process it. In this case (2) is more = feasible. And this is also the way we are using EXI within our = 6LoWPAN-related implementations.=20 >>=20 >> My 2 cents, >> Maybe we can discuss it in Paris while having a nice wine,=20 >> Guido >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=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 cabo@tzi.org Sat Apr 21 00:33: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 703E621F85D1 for ; Sat, 21 Apr 2012 00:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.322 X-Spam-Level: X-Spam-Status: No, score=-106.322 tagged_above=-999 required=5 tests=[AWL=-0.073, 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 HPc5F9F-EitW for ; Sat, 21 Apr 2012 00:33: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 16FB121F85CC for ; Sat, 21 Apr 2012 00:33: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 q3L7XjAK028836 for ; Sat, 21 Apr 2012 09:33:45 +0200 (CEST) Received: from [192.168.217.105] (p5489AAC2.dip.t-dialin.net [84.137.170.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9241D2A1; Sat, 21 Apr 2012 09:33:44 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: Carsten Bormann In-Reply-To: Date: Sat, 21 Apr 2012 09:33:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <59F77F53-9086-47A2-987B-EB2021022850@tzi.org> References: <4F8DFF3D.50201@itm.uni-luebeck.de> <085E1C1D-4E7B-4494-9B75-D9BFC487A261@iii.ca> <4F919240.3010401@itm.uni-luebeck.de> To: Klaus Hartke X-Mailer: Apple Mail (2.1257) Cc: core@ietf.org 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: Sat, 21 Apr 2012 07:33:56 -0000 On Apr 21, 2012, at 05:06, Klaus Hartke wrote: > Stephan Lohse wrote: >> Glad to be of help, however, that didn't answer my question...? :D >> Although, looking at issue #212 I might hazard a guess... >=20 > Ticket #212 is about the option *number* 14 (and option numbers that > are multiples of 14), not the option *delta* 14. >=20 > The option *delta* 15 is special in that it is used as the > end-of-option marker -- if and only if (a) the 'oc' field in the > message header is set to 15 and (b) the 'length' field in the option > header is set to 0. So using 15 as a delta is fine as long 'oc' is not > 15 or 'length' is not 0. >=20 > (This is what coap-09 says at moment. Indeed, that is what I had in mind when I wrote this. The "Note..." was just meant to point out that the end-of-options marker = in no way makes option number 15 special. > I think the length constraint > should be dropped.) I was hoping to get a bit feedback from implementers which approach is = better, but it appears to turn out this is pretty much a bike shed = decision. My current decoder code just compares the next byte to 0xF0. So 0xFx = with x =E2=89=A0 0 is not special in that decoder. But then my encoder code does not go to the trouble of trying to use 15 = as an option delta at all (which for oc=3D15 would require checking that = this is a non-zero-length option). Bike shed, bike shed. But I'm a little in favor of reserving the entirety of 0xFx for oc=3D15. If we ever start to make use of that reserved space, x would be a normal = option data structure length (including x=3D15 taking another byte). Gr=C3=BC=C3=9Fe, Carsten From cabo@tzi.org Sat Apr 21 00:59: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 6B4CC21F858F for ; Sat, 21 Apr 2012 00:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.321 X-Spam-Level: X-Spam-Status: No, score=-106.321 tagged_above=-999 required=5 tests=[AWL=-0.072, 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 poeYuxisfIhs for ; Sat, 21 Apr 2012 00:59: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 3EED121F8551 for ; Sat, 21 Apr 2012 00:59:07 -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 q3L7wuOR009369; Sat, 21 Apr 2012 09:58:56 +0200 (CEST) Received: from [192.168.217.105] (p5489AAC2.dip.t-dialin.net [84.137.170.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 0CB3A2AB; Sat, 21 Apr 2012 09:58: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: <91B1300E-F3A2-4672-8715-A0C006990DEB@sensinode.com> Date: Sat, 21 Apr 2012 09:58:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <175E4D4E-31AE-44CF-8CFF-DC6A26A64F74@tzi.org> References: <001b01cced71$c60c8b60$5225a220$@uni-rostock.de> <07CC0900-8116-4242-AB96-D74879E247D8@tzi.org> <001e01cced78$e09dd400$a1d97c00$@uni-rostock.de> <73456E11-9651-4FB8-82E3-1CBC490C55DF@tzi.org> <4F3E758B.8020007@stpeter.im> <000f01ccedb0$cd0fe620$672fb260$@uni-rostock.de> <5961B851-CBE9-445D-945A-2FC800A9667E@iii.ca> <91B1300E-F3A2-4672-8715-A0C006990DEB@sensinode.com> To: Zach Shelby X-Mailer: Apple Mail (2.1257) Cc: core@ietf.org Subject: Re: [core] EXI content type and encoding (was: Resolution to tickets #176, #177, #181) 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, 21 Apr 2012 07:59:09 -0000 > Instead we are now looking at the use of an informal naming like = application/senml-exi where there is no structured suffix exactly, but = this still means EXI for the application. What we are now trying to = figure out is what to day about that in the media type registration. = This means at least the SenML media type registration needs an update.=20= Luckily, we are decoupled from that discussion; we can give the thing a = number whenever we want. The intention is clearly to put application/senml[__]exi into our set of = registered content-type/content-coding combinations along with = application/senml+json and application/senml+xml. (Fill in the blank = after the discussion in apps-discuss closed.) We could start agreeing on the numbers that will be registered here. By the way, continuing to call option 1 Content-Type may now be slightly = confusing to HTTP mapper implementers. (Changing it to something akin = to "Content-Type-And-Encoding-Id" is ugly and will confuse the CoAP = implementers. I'm not sure who I want to confuse more. Maybe sticking = with the wrong name is better.) Gr=FC=DFe, Carsten From cabo@tzi.org Sat Apr 21 01:13: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 DCA6721F856D for ; Sat, 21 Apr 2012 01:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.319 X-Spam-Level: X-Spam-Status: No, score=-106.319 tagged_above=-999 required=5 tests=[AWL=-0.070, 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 ycUpuhZ9OB+3 for ; Sat, 21 Apr 2012 01:13: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 C1E3821F8497 for ; Sat, 21 Apr 2012 01:13:21 -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 q3L8DCbL016647; Sat, 21 Apr 2012 10:13:12 +0200 (CEST) Received: from [192.168.217.105] (p5489AAC2.dip.t-dialin.net [84.137.170.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B1D182B1; Sat, 21 Apr 2012 10:13:11 +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: Sat, 21 Apr 2012 10:13:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6029ED8C-2341-4199-A439-F0DB02A55DA4@koanlogic.com> To: Zach Shelby X-Mailer: Apple Mail (2.1257) Cc: core@ietf.org, 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, 21 Apr 2012 08:13:25 -0000 On Apr 21, 2012, at 08:39, Zach Shelby wrote: > coap://xy.[2001:DB8::abcd]/res Ouch. One of our problems seems to be that to set up a reverse proxy, you want = to be able to both tell the origin servers what the original SNI was as = well as specify the actual address of the origin server. You can't cram = both into an URI. (We had the same problem with Uri-Port before.) But URIs are the thing we write down in link-format documents. So = link-format is maybe a bit weak to configure reverse-proxy style = situations? We should not try to fix that problem by tweaking the URIs, = but by finding ways to represent the desirable information in = link-format. Gr=FC=DFe, Carsten From tho@koanlogic.com Sat Apr 21 03: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 9CD2821F8565 for ; Sat, 21 Apr 2012 03:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[AWL=0.288, 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 BuvglTgAj9UD for ; Sat, 21 Apr 2012 03:11:26 -0700 (PDT) Received: from gonzo.koanlogic.com (koanlogic.com [64.251.31.111]) by ietfa.amsl.com (Postfix) with ESMTP id 2444421F8557 for ; Sat, 21 Apr 2012 03:11:25 -0700 (PDT) Received: from chello062178222142.13.15.univie.teleweb.at ([62.178.222.142]:61757 helo=[192.168.0.11]) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1SLXHV-0000Yp-Av; Sat, 21 Apr 2012 06:11:12 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: <4F92196E.9000701@cs.tcd.ie> Date: Sat, 21 Apr 2012 12:11:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9158B27B-8C40-43A7-B957-961A9E29448B@koanlogic.com> 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> <4F8D1EA8.6080800@ericsson.com> <68B487AC-7384-4B75-9E1F-32CB8454D2F0@koanlogic.com> <4F92196E.9000701@cs.tcd.ie> To: Stephen Farrell 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] 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: Sat, 21 Apr 2012 10:11:26 -0000 Hi Stephen, On Apr 21, 2012, at 4:20 AM, Stephen Farrell wrote: > So I've no real opinion as to whether this extra bit is > needed/useful or not, but if its added then it'll need > to play well with how DTLS is done. >=20 > Be a shame to accidentally muck things up embedding some > hop-by-hop option into something secured end-to-end. >=20 > I would guess that any solution here that isn't "don't > use hop-by-hop options if you need (e2e) security" will > be fairly complex. currently CoAP provides no way to do E2E security in presence of = intermediaries. BTW Angelo, me and Sal contributed a position paper about that (and = argued about a CONNECT-like method for CoAP) in the SOS workshop in = Paris.= From zach@sensinode.com Sat Apr 21 05:54: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 9DCC121F857F for ; Sat, 21 Apr 2012 05:54:39 -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 wYJ6oa7o4nVZ for ; Sat, 21 Apr 2012 05:54:34 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 8620821F8575 for ; Sat, 21 Apr 2012 05:54:34 -0700 (PDT) Received: from [172.20.10.4] (81-197-58-223.elisa-mobile.fi [81.197.58.223]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q3LCsVqt007165; Sat, 21 Apr 2012 15:54:31 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Sat, 21 Apr 2012 15:54:28 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <621B125F-FC64-4B07-BB82-D2477E5F47FB@sensinode.com> References: <6029ED8C-2341-4199-A439-F0DB02A55DA4@koanlogic.com> To: Carsten Bormann X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org, 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, 21 Apr 2012 12:54:39 -0000 On Apr 21, 2012, at 11:13 AM, Carsten Bormann wrote: >> coap://xy.[2001:DB8::abcd]/res >=20 > Ouch. >=20 > One of our problems seems to be that to set up a reverse proxy, you = want to be able to both tell the origin servers what the original SNI = was as well as specify the actual address of the origin server. You = can't cram both into an URI. (We had the same problem with Uri-Port = before.) >=20 > But URIs are the thing we write down in link-format documents. So = link-format is maybe a bit weak to configure reverse-proxy style = situations? We should not try to fix that problem by tweaking the URIs, = but by finding ways to represent the desirable information in = link-format. Right, so you would prefer to represent virtual host names in some other = way. What about something like this? ;vh=3D"host1", ;vh=3D"host2" Thus when requesting the first link Uri-Host=3Dhost1 and for the second = link Uri-Host=3Dhost2. This leaves us with the same caching problem that = Klaus pointed out, how to differentiate between a cached resource = host1/res on this server vs. host1/res on some other server?=20 Zach --=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 cabo@tzi.org Sat Apr 21 08:14: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 8892E21F85E5 for ; Sat, 21 Apr 2012 08:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.318 X-Spam-Level: X-Spam-Status: No, score=-106.318 tagged_above=-999 required=5 tests=[AWL=-0.069, 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 xkAQ7DLx+DEs for ; Sat, 21 Apr 2012 08:14: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 58AE921F858B for ; Sat, 21 Apr 2012 08:14: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 q3LFEBCq015493; Sat, 21 Apr 2012 17:14:11 +0200 (CEST) Received: from [192.168.217.105] (p5489B641.dip.t-dialin.net [84.137.182.65]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 935AD319; Sat, 21 Apr 2012 17:14:11 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <621B125F-FC64-4B07-BB82-D2477E5F47FB@sensinode.com> Date: Sat, 21 Apr 2012 17:14:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6029ED8C-2341-4199-A439-F0DB02A55DA4@koanlogic.com> <621B125F-FC64-4B07-BB82-D2477E5F47FB@sensinode.com> To: Zach Shelby X-Mailer: Apple Mail (2.1257) Cc: core@ietf.org, 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, 21 Apr 2012 15:14:22 -0000 On Apr 21, 2012, at 14:54, Zach Shelby wrote: > Right, so you would prefer to represent virtual host names in some = other way. What about something like this? >=20 > ;vh=3D"host1", > ;vh=3D"host2" Well, I'd prefer not to *have* virtual host names :-) Once we want to have a single endpoint represent multiple endpoint = identities, we run into this problem. It's exacerbated by reverse = proxies that need to carry around these identities together with the = real endpoint (address/port) information. I understand why all this was necessary in an IPv4 HTTP world, but I'm = not so sure for CoAP. Gr=FC=DFe, Carsten From stephen.farrell@cs.tcd.ie Sat Apr 21 09:15: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 5896321F861B for ; Sat, 21 Apr 2012 09:15:06 -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 0XzM3cqlGy-n for ; Sat, 21 Apr 2012 09:15:01 -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 B9F5421F8613 for ; Sat, 21 Apr 2012 09:15:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 889651714D9; Sat, 21 Apr 2012 17:14:59 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1335024899; bh=phvIG8MIWWUzGh FgvFiC7AXurfbRdb9/Xu/Z4/dECs8=; b=WTQoj1SRdlVn9HrcGrIxGBsQT4Bske W+U40C9WDEcOHwAjZNDPGjdd4PncjihVZxaSrUIoHOWv1tEHE8Pzbv6qn/Rg30f0 QDhwq2tRNRy1QWIRWAoC6iQpH/QRbHZD04VVy8ekgqinHzKYHeHon+NyV6vIQBiL D33Jr358yj8FSyW8uJLU17dlyItWaT4P21Ww4qj5ZHVzGEPDaN/dpgMYnRBW3Wwk f9TzgP6zBjAsGWaP6Uctsx3HotEBPPcxPKjFsWAnvl+jkHgylZUD6oJDa3Ot1eQ0 UVT/pGwmH2ILGEQaPhUYJui+WFHkvbYQE1K62mQkWOwTMaM7cdr7B13g== 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 pFQYtofHHBYx; Sat, 21 Apr 2012 17:14:59 +0100 (IST) Received: from [10.0.9.83] (unknown [77.241.230.246]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 08CAE171473; Sat, 21 Apr 2012 17:14:56 +0100 (IST) Message-ID: <4F92DCFF.4090301@cs.tcd.ie> Date: Sat, 21 Apr 2012 17:14:55 +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: Thomas Fossati 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> <4F8D1EA8.6080800@ericsson.com> <68B487AC-7384-4B75-9E1F-32CB8454D2F0@koanlogic.com> <4F92196E.9000701@cs.tcd.ie> <9158B27B-8C40-43A7-B957-961A9E29448B@koanlogic.com> In-Reply-To: <9158B27B-8C40-43A7-B957-961A9E29448B@koanlogic.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: core WG 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: Sat, 21 Apr 2012 16:15:06 -0000 On 04/21/2012 11:11 AM, Thomas Fossati wrote: > Hi Stephen, > > On Apr 21, 2012, at 4:20 AM, Stephen Farrell wrote: >> So I've no real opinion as to whether this extra bit is >> needed/useful or not, but if its added then it'll need >> to play well with how DTLS is done. >> >> Be a shame to accidentally muck things up embedding some >> hop-by-hop option into something secured end-to-end. >> >> I would guess that any solution here that isn't "don't >> use hop-by-hop options if you need (e2e) security" will >> be fairly complex. > > currently CoAP provides no way to do E2E security in presence of intermediaries. So I could buy not being able to benefit from middleboxes if you want e2e security but the mere existence of a middlebox shouldn't stop a node from using e2e, or did you mean something else? > > BTW Angelo, me and Sal contributed a position paper about that (and argued about a CONNECT-like method for CoAP) in the SOS workshop in Paris. Couldn't make it there unfortunately. S. From tho@koanlogic.com Sat Apr 21 09:41: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 5679821F85D7 for ; Sat, 21 Apr 2012 09:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[AWL=0.259, 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 n5KuStbHLXop for ; Sat, 21 Apr 2012 09:41:32 -0700 (PDT) Received: from gonzo.koanlogic.com (koanlogic.com [64.251.31.111]) by ietfa.amsl.com (Postfix) with ESMTP id D204621F8589 for ; Sat, 21 Apr 2012 09:41:32 -0700 (PDT) Received: from chello062178222142.13.15.univie.teleweb.at ([62.178.222.142]:64647 helo=[192.168.0.11]) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1SLdMY-0001Hr-0z; Sat, 21 Apr 2012 12:41:29 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: <4F92DCFF.4090301@cs.tcd.ie> Date: Sat, 21 Apr 2012 18:40:39 +0200 Content-Transfer-Encoding: 7bit Message-Id: <7C11BCD4-3A3A-41AE-B4BC-E374BE737B47@koanlogic.com> 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> <4F8D1EA8.6080800@ericsson.com> <68B487AC-7384-4B75-9E1F-32CB8454D2F0@koanlogic.com> <4F92196E.9000701@cs.tcd.ie> <9158B27B-8C40-43A7-B957-961A9E29448B@koanlogic.com> <4F92DCFF.4090301@cs.tcd.ie> To: Stephen Farrell 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] 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: Sat, 21 Apr 2012 16:41:33 -0000 On Apr 21, 2012, at 6:14 PM, Stephen Farrell wrote: > So I could buy not being able to benefit from > middleboxes if you want e2e security but the > mere existence of a middlebox shouldn't stop a > node from using e2e, or did you mean something > else? Yep, I meant exactly so. From stephen.farrell@cs.tcd.ie Sat Apr 21 09: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 CEA1D21F8559 for ; Sat, 21 Apr 2012 09:57:18 -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 P48gzhmgrO27 for ; Sat, 21 Apr 2012 09:57:14 -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 4A3A021F8554 for ; Sat, 21 Apr 2012 09:57:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id B5D2217147A; Sat, 21 Apr 2012 17:57:13 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1335027433; bh=9OpgcWSZ0BR3VU z6mJcRHm5ARoaw3g/TMnyhtTox5rg=; b=D2/p9OU9fqDIH+j/CNNJ5q2Tch2EnW vKkEl6h4eFvXE9MNWPtzZ3hZPKfaXDUDK5dpYQ5+6lL68KDEtj2UfCCNW34qEfoQ kD64pUGaT0wXQh+MVgt4EZ1v8i4QssbJJLug4W1Z5Lgbv+5kFWmkWYdUMSD36Nju YPhY7orVuQ3qVwmuJZXd1QcVovNlb/meWs6Vv5blRvY5nfPO39ZUePegt7AA/k+H h/mhPXAp7tCc4E+fTTJPCUnxuEfmdCflnU2A519eFJhSzhKnztKq8iWok3miDTpw 0adcJ75rg71bY+4Pvdgr7jNZUL3MGEX6jyumVwYrRkk1oUkYGd6jpXUw== 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 Wnq+u7QU1fs9; Sat, 21 Apr 2012 17:57:13 +0100 (IST) Received: from [10.0.9.83] (unknown [77.241.230.246]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 3C610171473; Sat, 21 Apr 2012 17:57:13 +0100 (IST) Message-ID: <4F92E6E5.9010906@cs.tcd.ie> Date: Sat, 21 Apr 2012 17:57:09 +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: Thomas Fossati 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> <4F8D1EA8.6080800@ericsson.com> <68B487AC-7384-4B75-9E1F-32CB8454D2F0@koanlogic.com> <4F92196E.9000701@cs.tcd.ie> <9158B27B-8C40-43A7-B957-961A9E29448B@koanlogic.com> <4F92DCFF.4090301@cs.tcd.ie> <7C11BCD4-3A3A-41AE-B4BC-E374BE737B47@koanlogic.com> In-Reply-To: <7C11BCD4-3A3A-41AE-B4BC-E374BE737B47@koanlogic.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: core WG 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: Sat, 21 Apr 2012 16:57:18 -0000 On 04/21/2012 05:40 PM, Thomas Fossati wrote: > On Apr 21, 2012, at 6:14 PM, Stephen Farrell wrote: >> So I could buy not being able to benefit from >> middleboxes if you want e2e security but the >> mere existence of a middlebox shouldn't stop a >> node from using e2e, or did you mean something >> else? > > Yep, I meant exactly so. Well, with an AD hat on then that's going to be an issue. Why exactly is it good that the existence of a middlebox prevents use of e2e security? (I'm not saying you personally want that, the question is to the wg) S > From cabo@tzi.org Sat Apr 21 10:01: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 5BAB921F85AE for ; Sat, 21 Apr 2012 10:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.316 X-Spam-Level: X-Spam-Status: No, score=-106.316 tagged_above=-999 required=5 tests=[AWL=-0.067, 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 SEAYRU4Isls2 for ; Sat, 21 Apr 2012 10:01: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 06CF921F8592 for ; Sat, 21 Apr 2012 10:01: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 q3LH1PXi001706; Sat, 21 Apr 2012 19:01:25 +0200 (CEST) Received: from [192.168.217.117] (p5489B641.dip.t-dialin.net [84.137.182.65]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C297632B; Sat, 21 Apr 2012 19:01: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: <7C11BCD4-3A3A-41AE-B4BC-E374BE737B47@koanlogic.com> Date: Sat, 21 Apr 2012 19:01:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4F1131E2-6997-4F2B-A51A-DD2A8607F9E0@tzi.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> <4F8D1EA8.6080800@ericsson.com> <68B487AC-7384-4B75-9E1F-32CB8454D2F0@koanlogic.com> <4F92196E.9000701@cs.tcd.ie> <9158B27B-8C40-43A7-B957-961A9E29448B@koanlogic.com> <4F92DCFF.4090301@cs.tcd.ie> <7C11BCD4-3A3A-41AE-B4BC-E374BE737B47@koanlogic.com> To: Thomas Fossati X-Mailer: Apple Mail (2.1257) Cc: core WG 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: Sat, 21 Apr 2012 17:01:36 -0000 On Apr 21, 2012, at 18:40, Thomas Fossati wrote: > On Apr 21, 2012, at 6:14 PM, Stephen Farrell wrote: >> So I could buy not being able to benefit from >> middleboxes if you want e2e security but the >> mere existence of a middlebox shouldn't stop a >> node from using e2e, or did you mean something >> else? >=20 > Yep, I meant exactly so. I think there is some confusion here. (I'm not addressing Thomas specifically here, I know that he has thought = a lot about the issues.) CoAP does not address middleboxes in the general sense, at all. We support intermediaries, which by definition break up an end-to-end = relationship to do some processing (often some form of caching). CoAP "does not support" end-to-end security in the sense that SMTP "does = not support" end-to-end security. Nothing in the architecture stops a = CoAP application from employing end-to-end security by e.g. layering = object security on top. Whether a concept like "CONNECT" actually does something remotely useful = for improving end-to-end security is up for discussion. If you need = end-to-end comsec, just don't go through an intermediary in the first = place. Use IP instead. Much better. Or, if you indeed need the services of an intermediary without trusting = it, use object security on top (like SMTP would be doing). Now we all know that, as of today, we don't have a credible object = security story for constrained systems. The CoRE working group is = unlikely to change that. JOSE might. Burdening the standardization of = CoAP with this can of worms would be insane. Gr=FC=DFe, Carsten From fluffy@iii.ca Sat Apr 21 10:14: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 BD78721F863B for ; Sat, 21 Apr 2012 10:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.988 X-Spam-Level: X-Spam-Status: No, score=-0.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_SORBS_WEB=0.619] 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 DPvMuRlG4FkU for ; Sat, 21 Apr 2012 10:14:12 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4433021F861A for ; Sat, 21 Apr 2012 10:14:12 -0700 (PDT) Received: from [172.20.10.3] (unknown [74.198.151.32]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 53C1222E256; Sat, 21 Apr 2012 13:14:04 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Fri, 20 Apr 2012 14:14:11 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2D6BA6D1-0AE5-4C4D-BFFB-14E79E236B37@iii.ca> References: To: matthieu.vial@non.schneider-electric.com X-Mailer: Apple Mail (2.1257) Cc: core WG Subject: Re: [core] New Version Notification for draft-shelby-exi-registration-00.txt 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, 21 Apr 2012 17:14:12 -0000 On Apr 20, 2012, at 7:33 , matthieu.vial@non.schneider-electric.com = wrote: >> Yes, you would register a new media type for every different schema.=20= >> So perhaps my example should have been=20 >> application/se2dot1+exi >=20 > What about using resource discovery and link-format for fine-grained=20= > schema negotiation? > We just need a new attribute for the schema id and we also may have to=20= > define some kind of attribute inheritance to avoid repeating the = schema on=20 > every single resource. > application/sep2+exi is still useful if we assume se2.1, 2.2... have=20= > compatible schemas. When compatibility is broken just go with another=20= > content type. Well if 2.2 is backwards compatible with 2.1, then agree that one can = just register 2 and use it for all the 2.x, a non backwards compatible = change would force the registrations of 3.=20 > I don't think it is reasonable to register each minor schema variation=20= > from all standards in a 2-byte registry. If there is any concern we might run out, should probably move this to = allow 3 byte values as well.=20 >=20 > Matthieu >=20 From fluffy@iii.ca Sat Apr 21 10:15:01 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 49BA521F8642 for ; Sat, 21 Apr 2012 10:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.988 X-Spam-Level: X-Spam-Status: No, score=-0.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_SORBS_WEB=0.619] 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 3Ge7a+rLSKtr for ; Sat, 21 Apr 2012 10:14:57 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 3B00821F863B for ; Sat, 21 Apr 2012 10:14:57 -0700 (PDT) Received: from [172.20.10.3] (unknown [74.198.151.32]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 58C6622E256; Sat, 21 Apr 2012 13:14:55 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <55877B3AFB359744BA0F2140E36F52B51398E11D@MBX10.d.ethz.ch> Date: Fri, 20 Apr 2012 14:18:17 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <051.e7fbc0f0f5736d305a309a9e8d0cd924@trac.tools.ietf.org> <61887542-A2C0-4DF2-B784-34ABE12E38EF@iii.ca> <5BEC4E4C-FF04-44DC-A14B-2FA73E3D573F@tzi.org> <2A346094-E537-4536-AE35-7C88D70AC55C@iii.ca> <55877B3AFB359744BA0F2140E36F52B51398E11D@MBX10.d.ethz.ch> To: Kovatsch Matthias X-Mailer: Apple Mail (2.1257) Cc: core WG 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: Sat, 21 Apr 2012 17:15:01 -0000 On Apr 18, 2012, at 13:18 , Kovatsch Matthias wrote: >> goo.gl/x6YHG >>=20 >> is about as long a you really need for HTTP URLs. >=20 > This is like going back to ZigBee's binary cluster identifiers. > People are, however, pretty bad in handling this machine gibberish and = thus need a long time to understand the components and to integrate = systems. This is why self-descriptive URIs are so nice and in turn why = the Web took off as it did. I agree and I would not suggest a limit of 15 bytes for a URL. But I do = think some limit is need for practical implementations and once we have = a limit, we need to have some agreement on what it is. Given the URL are = primarily for machine not human consumption, it seems like they can = easily be designed to be relatively short and and still easy for a human = to debug.=20 > =09 > Regards > Matthias >=20 From fluffy@iii.ca Sat Apr 21 10:15: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 5D77D21F8647 for ; Sat, 21 Apr 2012 10:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.488 X-Spam-Level: X-Spam-Status: No, score=-1.488 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 BHTldpHngywD for ; Sat, 21 Apr 2012 10:15:06 -0700 (PDT) Received: from fallback-in2.mxes.net (fallback-out2.mxes.net [216.86.168.191]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5B421F8646 for ; Sat, 21 Apr 2012 10:15:05 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by fallback-in1.mxes.net (Postfix) with ESMTP id E6DD32FDBEB for ; Sat, 21 Apr 2012 13:14:58 -0400 (EDT) Received: from [172.20.10.3] (unknown [74.198.151.32]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C65CC22E257; Sat, 21 Apr 2012 13:14:57 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Cullen Jennings In-Reply-To: <4F919240.3010401@itm.uni-luebeck.de> Date: Fri, 20 Apr 2012 14:23:37 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <3B2538D9-5E8A-481B-8E33-C47A266074A4@iii.ca> References: <4F8DFF3D.50201@itm.uni-luebeck.de> <085E1C1D-4E7B-4494-9B75-D9BFC487A261@iii.ca> <4F919240.3010401@itm.uni-luebeck.de> To: Stephan Lohse X-Mailer: Apple Mail (2.1257) 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: Sat, 21 Apr 2012 17:15:10 -0000 On Apr 20, 2012, at 10:43 , Stephan Lohse wrote: > Glad to be of help, however, that didn't answer my question...? :D > Although, looking at issue #212 I might hazard a guess=85 Sorry - I don't know what it should be. The issues from my point of view = is having too ways to indicate the number of items in the list just = seems to be an optimization that is probably not needed.=20 >=20 > Regards, > - Stephan >=20 > On 18/04/12 17:20, Cullen Jennings wrote: >>=20 >> Good question - I just found a bug in my code - thanks :-)=20 >>=20 >> On Apr 17, 2012, at 5:39 PM, Stephan Lohse wrote: >>=20 >>> Hi, >>>=20 >>> 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? >>>=20 >>> Regards, >>> - Stephan Lohse >>> _______________________________________________ >>> 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 From fluffy@cisco.com Sat Apr 21 10:16: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 B35A321F860E for ; Sat, 21 Apr 2012 10:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.778 X-Spam-Level: X-Spam-Status: No, score=-109.778 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, 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 2EIR5GPMqFIm for ; Sat, 21 Apr 2012 10:16:14 -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 661A621F85A7 for ; Sat, 21 Apr 2012 10:16:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1277; q=dns/txt; s=iport; t=1335028574; x=1336238174; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=usZHEEZu3cH/mkkh8AxxeBFuStvT2w13zwX6/KRZYFc=; b=g2oqzj0iqdtWMuAEB9K9vgjNNkktmSA4yvKvSdOeBI8lxCWp4wJVzjYy AJToyOg9vU1G44/fkro//1d5m0h5qQpP5gfzOAVp/4f/mc3zENE9VG11K pnMEywuu5o1qRmbF2XMTCR5Foi+jeLFeitoS+mRa2LPTVNLitfj5A/IAT g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHPqkk+rRDoI/2dsb2JhbABEsUKBB4IJAQEBAwESAWYFCwsOCi5XBjWHaASacZ9WkFBjBIhjjReOVYFpgwg X-IronPort-AV: E=Sophos;i="4.75,459,1330905600"; d="scan'208";a="41495063" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 21 Apr 2012 17:16:14 +0000 Received: from sjc-vpn6-1884.cisco.com (sjc-vpn6-1884.cisco.com [10.21.127.92]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3LHGBUG005592; Sat, 21 Apr 2012 17:16:13 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: Date: Fri, 20 Apr 2012 14:26:25 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1DC55BCC-78E1-42A0-BC36-1AB842E34034@cisco.com> To: Carsten Bormann X-Mailer: Apple Mail (2.1257) Cc: core WG Subject: Re: [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: Sat, 21 Apr 2012 17:16:18 -0000 On Apr 20, 2012, at 10:34 , Carsten Bormann wrote: > On Apr 18, 2012, at 06:58, Cullen Jennings wrote: >=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 > I think that is an essential requirement if we have the aborting = mechanism in place (which, in turn, I think is also an essential = requirement). >=20 > Imagine the client goes away. > Without this, if a server has a new value for the resource every five = seconds, it will send the new value and set back the binary exponential = back-off to the first attempt. It will >=20 > 1) send retransmission packets at a rate of a packet every 2.5 seconds = (OK, that is not yet a disaster) >=20 > 2) it will never notice the client is gone. I certainly agree that we need a way to notice the client is gone. I = would have proposed that if you abort the previous transaction, then you = need to copy over the retransmit state to the new transaction. But if = you don't cancel the old transaction, the device still finds out the = device is gone.=20 >=20 > Gr=FC=DFe, Carsten >=20 >=20 From fluffy@iii.ca Sat Apr 21 10:16: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 B400B21F8616 for ; Sat, 21 Apr 2012 10:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=-0.391, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] 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 m5UyGvmz7dPn for ; Sat, 21 Apr 2012 10:16:18 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id B07F321F847B for ; Sat, 21 Apr 2012 10:16:18 -0700 (PDT) Received: from sjc-vpn6-1884.cisco.com (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 8C42A22E1EB; Sat, 21 Apr 2012 13:16:16 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Cullen Jennings In-Reply-To: <051.8dc4d4529b0eb768972bc70c3c71cca2@trac.tools.ietf.org> Date: Fri, 20 Apr 2012 14:30:14 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <173A8B45-7872-4024-B07D-852F3DD3F2EB@iii.ca> References: <051.8dc4d4529b0eb768972bc70c3c71cca2@trac.tools.ietf.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1257) Cc: core WG Subject: Re: [core] #225: Explain why it is not always possible to react to a RST that is in reply to a NON 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, 21 Apr 2012 17:16:22 -0000 What I am wondering about is the case where a A has a subscription to B. = B is sending a series of NON responses to A. If A sends a RST, the = subscription needs to be canceled.=20 On Apr 20, 2012, at 10:13 , core issue tracker wrote: > #225: Explain why it is not always possible to react to a RST that is = in reply to > a NON >=20 > Cullen Jennings notes (msg03073e): >=20 > Last paragraph of section 4.2 says MAY remove but I think this needs = to be > a MUST remove. >=20 > -> >=20 >=20 > No, this is indeed intended to be MAY. > We want to make the need to store state for a NON optional. > A sender of a NON message may discard the MID state for that message > whenever it wants. > That may make acting on a RST to that MID impossible. > Hence MAY. >=20 > -> change the wording to make it clearer that we expect (as a quality = of > implementation issue) a server that still happens to have the state to > also react to the RST. >=20 > --=20 > -----------------------------+--------------------------------------- > Reporter: cabo@=85 | Owner: draft-ietf-core-observe@=85= > Type: editorial | Status: new > Priority: minor | Milestone: post-WGLC-1 > Component: observe | Version: observe-05 > 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 fluffy@iii.ca Sat Apr 21 10:16: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 34E1D21F8643 for ; Sat, 21 Apr 2012 10:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.981 X-Spam-Level: X-Spam-Status: No, score=-1.981 tagged_above=-999 required=5 tests=[AWL=-0.374, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] 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 QkIyW7KR4zNK for ; Sat, 21 Apr 2012 10:16:34 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id C446C21F8630 for ; Sat, 21 Apr 2012 10:16:28 -0700 (PDT) Received: from sjc-vpn6-1884.cisco.com (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 2261422E256; Sat, 21 Apr 2012 13:16:26 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Cullen Jennings In-Reply-To: <051.96050ca332dbb50866094e054b75514d@trac.tools.ietf.org> Date: Fri, 20 Apr 2012 14:35:24 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <4F0E220C-8651-47AF-81C2-940197C22354@iii.ca> References: <051.96050ca332dbb50866094e054b75514d@trac.tools.ietf.org> To: trac+core@trac.tools.ietf.org X-Mailer: Apple Mail (2.1257) Cc: draft-ietf-core-observe@tools.ietf.org, core@ietf.org Subject: Re: [core] #221: Occasionally sending CON is not just a security consideration 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, 21 Apr 2012 17:16:38 -0000 I might not understand the full Pledge proposal but it seems like it = would also address this problem. If we go with a solution of sending = period CON, that needs to be normatively specified in the draft.=20 On Apr 20, 2012, at 9:37 , core issue tracker wrote: > #221: Occasionally sending CON is not just a security consideration >=20 > Cullen Jennings notes (msg03073a): >=20 > 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 > -> >=20 > This is currently discussed in the security considerations, but only = for > NoSec mode. > The need to at least occasionally intersperse CONs needs to be = discussed > earlier (and explained in more detail, msg03073i). >=20 > Another reason for sending a CON at certain points: >=20 > Just sending NON for a long time does not guarantee eventual = consistency. >=20 > --=20 > -----------------------------+--------------------------------------- > Reporter: cabo@=85 | Owner: draft-ietf-core-observe@=85= > Type: protocol defect | Status: new > Priority: minor | Milestone: post-WGLC-1 > Component: observe | Version: observe-05 > 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 fluffy@iii.ca Sat Apr 21 10:16: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 9B89121F847B for ; Sat, 21 Apr 2012 10:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, 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 WKVgshKvMOvL for ; Sat, 21 Apr 2012 10:16:34 -0700 (PDT) Received: from fallback-in2.mxes.net (fallback-out2.mxes.net [216.86.168.191]) by ietfa.amsl.com (Postfix) with ESMTP id B9F9C21F863C for ; Sat, 21 Apr 2012 10:16:34 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by fallback-in1.mxes.net (Postfix) with ESMTP id 685042FDBF0 for ; Sat, 21 Apr 2012 13:16:34 -0400 (EDT) Received: from sjc-vpn6-1884.cisco.com (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 B520722E257; Sat, 21 Apr 2012 13:16:30 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Cullen Jennings In-Reply-To: <051.26bde5f98fc2c31bc73b4e7c8374b34e@trac.tools.ietf.org> Date: Fri, 20 Apr 2012 14:38:24 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <8299C38F-2321-48F3-A650-CB8DBAADA85C@iii.ca> References: <051.26bde5f98fc2c31bc73b4e7c8374b34e@trac.tools.ietf.org> To: trac+core@trac.tools.ietf.org X-Mailer: Apple Mail (2.1257) Cc: draft-ietf-core-observe@tools.ietf.org, core@ietf.org Subject: Re: [core] #220: Should observer support time series data? 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, 21 Apr 2012 17:16:38 -0000 I think we want #2 and not #1. If an application wants to arrange it's = data so a get returns the buffer of all previous values over a certain = horizon, then #2 can be used to implement #1.=20 In general, trying to have guaranteed delivery of anything just does = not work out on IP networks.=20 On Apr 20, 2012, at 8:56 , core issue tracker wrote: > #220: Should observer support time series data? >=20 > Jeroen Hoebeke notes (msg02900): >=20 > There is a difference between the following: >=20 > 1. informing a client about every change of the state of a resource: = this > is what one would expect when just reading the abstract of the draft >=20 > 2. delivering a client an always fresh representation of a resource = (even > if the resource did not change): this is what the draft actually > implements through the max-age option >=20 > Having both makes a lot of sense. Draft observe could fulfill both > purposes (and would be a good place to do so). If draft observe is = only > about 1) and the abstract clarifies this, an extension to observe > (introducing pledge) for case 2) seems an obvious step. Personally, I = am > in favor of having this in a single draft. >=20 > -> >=20 > Observe currently is about 2 (eventual consistency). What kinds of > mechanisms would we need to add to support time series data as in 1? = Is > the resulting set of changes a desirable addition? >=20 > --=20 > = ----------------------------------+---------------------------------------= > Reporter: cabo@=85 | Owner: = draft-ietf-core-observe@=85 > Type: protocol enhancement | Status: new > Priority: minor | Milestone: post-WGLC-1 > Component: observe | Version: observe-05 > 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 fluffy@cisco.com Sat Apr 21 10:16: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 77EF521F847B for ; Sat, 21 Apr 2012 10:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.761 X-Spam-Level: X-Spam-Status: No, score=-109.761 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, 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 u9Y8JwdsXYuj for ; Sat, 21 Apr 2012 10:16:35 -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 52AB221F863E for ; Sat, 21 Apr 2012 10:16:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=876; q=dns/txt; s=iport; t=1335028595; x=1336238195; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=kDliJ1AMsrPv6EElydWiRgILJja3JXvBAyqFZz3uF9A=; b=VvCI13kDe81+5p8o4f+TPqnBoy+tkcujAJ/t+UQ5vehp+DGPFM30WGEQ N909s1O5kY7YipBLwPWxhfM9bNBZgWeT2hvtRmDdIANjGaYOyz10/nhzM uTUE34JeCCDShIZ7xIcEKvrrX+ZqagU2MhaXX5OTjXZXMpbHVxkVfiTgu 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4GAA3qkk+rRDoI/2dsb2JhbABEr0iBeoEHggkBAQEDARIBJzIKAxALRlc7h2gEmm+fVo4OgkJjBIhjjReOVYFpgwg X-IronPort-AV: E=Sophos;i="4.75,459,1330905600"; d="scan'208";a="39010048" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 21 Apr 2012 17:16:35 +0000 Received: from sjc-vpn6-1884.cisco.com (sjc-vpn6-1884.cisco.com [10.21.127.92]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3LHGBUI005592; Sat, 21 Apr 2012 17:16:34 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <051.4e6cdfc507a23a9b28c6274a5b955113@trac.tools.ietf.org> Date: Fri, 20 Apr 2012 16:06:59 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <70F0C1F2-42A6-4897-8776-318F529069B4@cisco.com> References: <051.4e6cdfc507a23a9b28c6274a5b955113@trac.tools.ietf.org> To: trac+core@trac.tools.ietf.org X-Mailer: Apple Mail (2.1257) Cc: draft-ietf-core-coap@tools.ietf.org, core@ietf.org Subject: Re: [core] #212: Option numbers 14, 28, 42, ... reserved but usable 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, 21 Apr 2012 17:16:39 -0000 On Apr 19, 2012, at 5:03 , core issue tracker wrote: >=20 > Clarify that while the positive option numbers divisible by 14 are = indeed > reserved, they still are available for allocation as long as a = zero-length > option with each of these numbers remains available as a no-operation > option for fenceposting. >=20 > (msg03034a, also covers msg03072cc) I wonder how many existing implementations do the right thing is they = encounter a non zero length option code 14. This gives us a very small = gain in the size of the option space (less than 10%) and makes things = more complicated. I think the goal here is small simple code that = interoperates - if we think we need a bigger options space, we can make = a bigger option space. I'm more worried about simplicity, bugs, and = small code than squeezing every last bit out of the bandwidth.=20 From kovatsch@inf.ethz.ch Sat Apr 21 10:20: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 4102021F84A1 for ; Sat, 21 Apr 2012 10:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.266 X-Spam-Level: X-Spam-Status: No, score=-9.266 tagged_above=-999 required=5 tests=[AWL=1.333, 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 6pnOK4Je6DhW for ; Sat, 21 Apr 2012 10:20:42 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id 7336D21F8499 for ; Sat, 21 Apr 2012 10:20:42 -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; Sat, 21 Apr 2012 19:20:41 +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; Sat, 21 Apr 2012 19:20:41 +0200 From: "Kovatsch Matthias" To: Cullen Jennings Thread-Topic: [core] #202: Remove the 270 byte artificial limit Thread-Index: AQHNHXfKOwTEAqxLy0KL8FjKmBADiZagnb4AgAAXSwCAAD0xAIADFsCAgAGBCyA= Date: Sat, 21 Apr 2012 17:20:40 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B513990663@MBX10.d.ethz.ch> References: <051.e7fbc0f0f5736d305a309a9e8d0cd924@trac.tools.ietf.org> <61887542-A2C0-4DF2-B784-34ABE12E38EF@iii.ca> <5BEC4E4C-FF04-44DC-A14B-2FA73E3D573F@tzi.org> <2A346094-E537-4536-AE35-7C88D70AC55C@iii.ca> <55877B3AFB359744BA0F2140E36F52B51398E11D@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: core WG 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: Sat, 21 Apr 2012 17:20:43 -0000 > But I do think > some limit is need for practical implementations and once we have a limit= , we > need to have some agreement on what it is. Given the URL are primarily fo= r > machine not human consumption, it seems like they can easily be designed > to be relatively short and and still easy for a human to debug. The implementations could decide that through the applications they shall s= upport. A server for instance must only support its own longest hostname/Uri-Path/U= ri-Query. Clients could use the limitations from application profiles such as SEP 2.0= or IPSO. I think it would generally be best, if such profiles would specify limitati= ons and the protocol itself can be kept flexible, without artificial limita= tions. > > Regards > > Matthias From stephen.farrell@cs.tcd.ie Sat Apr 21 10:31: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 97EAA21F854F for ; Sat, 21 Apr 2012 10:31:23 -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 1cosOoaETLjf for ; Sat, 21 Apr 2012 10:31:19 -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 D0F7121F854D for ; Sat, 21 Apr 2012 10:31:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id DF4DB171473; Sat, 21 Apr 2012 18:31:16 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1335029476; bh=MqZTHBhAStJwwq 3q5fhAoStR/vWePOU7Ng0pWW9Bw2M=; b=Xj/6DbLp5eScG2JEtEE0B+dDUnfMuM thw3S41IQc58Qg7yuvGmRzCOtc9p9e/aOQO02eYsnwgcUgdMD23FjTc9tt3/MATa JwqfUP8+dQFaEisPZme+a2dtKUDLYj7L7+gUwYuXVN8StTUonERvZt9VgwKv3pdN aRId7aGQMkiLmtteqdBhcNuAFajp1kiaBQKoN1mvizRJLfa/ZwohDNr7Wv3EvxyB lqBqpcDBcztDwgJFMgUlxd+MnKOQ3+9V+ZhzSbUZsuUNZAd772nLHvkfmWUhxXLl PUYXmLGGl2C1XJa+F6vesapBkArwcdDfRk/0iWl4JGbAgfx+1erCFlpg== 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 6z4-7Ga4oGOq; Sat, 21 Apr 2012 18:31:16 +0100 (IST) Received: from [10.0.9.83] (unknown [77.241.230.246]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 73A2D171472; Sat, 21 Apr 2012 18:31:15 +0100 (IST) Message-ID: <4F92EEE2.6080801@cs.tcd.ie> Date: Sat, 21 Apr 2012 18:31:14 +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: Carsten Bormann 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> <4F8D1EA8.6080800@ericsson.com> <68B487AC-7384-4B75-9E1F-32CB8454D2F0@koanlogic.com> <4F92196E.9000701@cs.tcd.ie> <9158B27B-8C40-43A7-B957-961A9E29448B@koanlogic.com> <4F92DCFF.4090301@cs.tcd.ie> <7C11BCD4-3A3A-41AE-B4BC-E374BE737B47@koanlogic.com> <4F1131E2-6997-4F2B-A51A-DD2A8607F9E0@tzi.org> In-Reply-To: <4F1131E2-6997-4F2B-A51A-DD2A8607F9E0@tzi.org> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: core WG 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: Sat, 21 Apr 2012 17:31:23 -0000 On 04/21/2012 06:01 PM, Carsten Bormann wrote: > On Apr 21, 2012, at 18:40, Thomas Fossati wrote: > >> On Apr 21, 2012, at 6:14 PM, Stephen Farrell wrote: >>> So I could buy not being able to benefit from >>> middleboxes if you want e2e security but the >>> mere existence of a middlebox shouldn't stop a >>> node from using e2e, or did you mean something >>> else? >> >> Yep, I meant exactly so. > > I think there is some confusion here. Quite possible. > (I'm not addressing Thomas specifically here, I know that he has thought a lot about the issues.) > > CoAP does not address middleboxes in the general sense, at all. > We support intermediaries, which by definition break up an end-to-end relationship to do some processing (often some form of caching). > > CoAP "does not support" end-to-end security in the sense that SMTP "does not support" end-to-end security. Nothing in the architecture stops a CoAP application from employing end-to-end security by e.g. layering object security on top. > > Whether a concept like "CONNECT" actually does something remotely useful for improving end-to-end security is up for discussion. If you need end-to-end comsec, just don't go through an intermediary in the first place. Use IP instead. Much better. > Or, if you indeed need the services of an intermediary without trusting it, use object security on top (like SMTP would be doing). > > Now we all know that, as of today, we don't have a credible object security story for constrained systems. The CoRE working group is unlikely to change that. JOSE might. Burdening the standardization of CoAP with this can of worms would be insane. I agree with that last and am not trying to burden CoAP with that. (It'd be great if a good object security scheme existed, but that's just not a pre-condition of any sort.) However, if e.g. a node that sometimes uses a proxy can't ever use e2e security, then that'd be a problem. It'd also be a problem if being "behind" a proxy, in practice meant you could not turn on e2e security. (When I say "problem" I mean a thing that needs to be properly justified, not a religious sin type thing that can never be accepted.) Its that latter that I took from Thomas' mail (without having read the drafts, sorry). If requiring e2e or not is the sender's choice for each session then its probably fine. (Bringing us back to the start of this, where setting that putative new bit related to caching would seem to make no sense in an e2e-secured session.) S > Gre, Carsten > > From tho@koanlogic.com Sat Apr 21 12:27: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 BEE2721F8598 for ; Sat, 21 Apr 2012 12:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.363 X-Spam-Level: X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=0.236, 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 pjZEgl9uvlsg for ; Sat, 21 Apr 2012 12:27:49 -0700 (PDT) Received: from gonzo.koanlogic.com (koanlogic.com [64.251.31.111]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF7521F8584 for ; Sat, 21 Apr 2012 12:27:49 -0700 (PDT) Received: from chello062178222142.13.15.univie.teleweb.at ([62.178.222.142]:49456 helo=[192.168.0.11]) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1SLfy7-0001ZW-2u; Sat, 21 Apr 2012 15:27:46 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: <4F92EEE2.6080801@cs.tcd.ie> Date: Sat, 21 Apr 2012 21:27:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <94216E93-4059-4EA2-B4AE-88BF67E74369@koanlogic.com> 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> <4F8D1EA8.6080800@ericsson.com> <68B487AC-7384-4B75-9E1F-32CB8454D2F0@koanlogic.com> <4F92196E.9000701@cs.tcd.ie> <9158B27B-8C40-43A7-B957-961A9E29448B@koanlogic.com> <4F92DCFF.4090301@cs.tcd.ie> <7C11BCD4-3A3A-41AE-B4BC-E374BE737B47@koanlogic.com> <4F1131E2-6997-4F2B-A51A-DD2A8607F9E0@tzi.org> <4F92EEE2.6080801@cs.tcd.ie> To: Stephen Farrell 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] 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: Sat, 21 Apr 2012 19:27:49 -0000 On Apr 21, 2012, at 7:31 PM, Stephen Farrell wrote: > On 04/21/2012 06:01 PM, Carsten Bormann wrote: >> On Apr 21, 2012, at 18:40, Thomas Fossati wrote: >>> On Apr 21, 2012, at 6:14 PM, Stephen Farrell wrote: >>>> So I could buy not being able to benefit from >>>> middleboxes if you want e2e security but the >>>> mere existence of a middlebox shouldn't stop a >>>> node from using e2e, or did you mean something >>>> else? >>>=20 >>> Yep, I meant exactly so. >>=20 >> I think there is some confusion here. >=20 > Quite possible. Sorry, I read "middlebox" as per RFC 3234, hence including proxies into = the category. Thus the confusion.= From cabo@tzi.org Sat Apr 21 12:50: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 E651B21F8636 for ; Sat, 21 Apr 2012 12:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.221 X-Spam-Level: X-Spam-Status: No, score=-104.221 tagged_above=-999 required=5 tests=[AWL=-1.622, 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 dADmG85rGQA4 for ; Sat, 21 Apr 2012 12:50:22 -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 EE14521F85C7 for ; Sat, 21 Apr 2012 12:50:21 -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 q3LJo7PI017823; Sat, 21 Apr 2012 21:50:09 +0200 (CEST) Message-Id: <49276523-70CC-40F2-9D34-FF8F3348BA0C@tzi.org> From: Carsten Bormann To: Thomas Fossati In-Reply-To: <94216E93-4059-4EA2-B4AE-88BF67E74369@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, 21 Apr 2012 21:50:07 +0200 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> <4F8D1EA8.6080800@ericsson.com> <68B487AC-7384-4B75-9E1F-32CB8454D2F0@koanlogic.com> <4F92196E.9000701@cs.tcd.ie> <9158B27B-8C40-43A7-B957-961A9E29448B@koanlogic.com> <4F92DCFF.4090301@cs.tcd.ie> <7C11BCD4-3A3A-41AE-B4BC-E374BE737B47@koanlogic.com> <4F1131E2-6997-4F2B-A51A-DD2A8607F9E0@tzi.org> <4F92EEE2.6080801@cs.tcd.ie> <94216E93-4059-4EA2-B4AE-88BF67E74369@koanlogic.com> X-Mailer: Apple Mail (2.936) Cc: core WG 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: Sat, 21 Apr 2012 19:50:23 -0000 On Apr 21 2012, at 21:27, Thomas Fossati wrote: > Sorry, I read "middlebox" as per RFC 3234, hence including proxies > into the category. A CoAP intermediary is not "on the datagram path" in the sense of 3234. I think the confusion comes in when people start to think about CoAP intermediaries in the same way we tend to think about midleboxes in the IPv4 Internet. In the IPv4 Internet, middleboxes are (or at least have the connotation of) "network fog" -- they are in the way, you are stuck with them, you can't get around them. This is not the primary use I see for CoAP intermediaries. CoAP intermediaries are voluntarily used by CoAP endpoints, typically to improve some performance characteristic (battery life, response time, throughput, reliability). In the CoAP applications I'm seeing, CoAP intermediaries are not "put in the way" to restrict communication (or to bridge address spaces -- most work on CoAP is IPv6 based). Often, CoAP intermediaries mark trust boundaries. There may be no end-to-end trust relationship at all, so no use for end-to-end security -- (CoAP-hop)-by-hop security is actually what is desirable in these cases. However, there are also applications where the performance improvement is essential (i.e., the intermediary is "getting in the way" for performance reasons) but does not imply any trust. That's where it would help to have alternate modes of security to the ones we already have. This is also true where the intermediaries are placed mainly to perform a protocol transition, e.g. from CoAP to HTTP -- the only things end-to-end here are the URIs and the payloads. It is conceivable to augment this by, say, tunneling DTLS through HTTP, so a CONNECT-style function might be made to work (i.e., the HTTP-side endpoint would run CoAP over DTLS over HTTP to the intermediary, then the DTLS is unpacked and sent on over UDP to the CoAP-side endpoint). Alper Yegin also launched a trial balloon a while ago that had a special security protocol transported within CoAP options -- I think the WG consensus was we didn't quite know how to make that work. There is a bit too much invention going on here for my security taste. Also, all these proposals do not cover securing other aspects such as discovery. For the applications I have looked at that really need to cross untrusted intermediaries, I'd rather do object security. Gruesse, Carsten From tho@koanlogic.com Sat Apr 21 13:56:01 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 1922C21F84EB for ; Sat, 21 Apr 2012 13:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.383 X-Spam-Level: X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[AWL=0.216, 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 gMrSk6lhTcOW for ; Sat, 21 Apr 2012 13:56:00 -0700 (PDT) Received: from gonzo.koanlogic.com (koanlogic.com [64.251.31.111]) by ietfa.amsl.com (Postfix) with ESMTP id 6273A21F84EA for ; Sat, 21 Apr 2012 13:56:00 -0700 (PDT) Received: from chello062178222142.13.15.univie.teleweb.at ([62.178.222.142]:50186 helo=[192.168.0.11]) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1SLhLQ-0001ia-OI; Sat, 21 Apr 2012 16:55:56 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: <49276523-70CC-40F2-9D34-FF8F3348BA0C@tzi.org> Date: Sat, 21 Apr 2012 22:55:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: 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> <4F8D1EA8.6080800@ericsson.com> <68B487AC-7384-4B75-9E1F-32CB8454D2F0@koanlogic.com> <4F92196E.9000701@cs.tcd.ie> <9158B27B-8C40-43A7-B957-961A9E29448B@koanlogic.com> <4F92DCFF.4090301@cs.tcd.ie> <7C11BCD4-3A3A-41AE-B4BC-E374BE737B47@koanlogic.com> <4F1131E2-6997-4F2B-A51A-DD2A8607F9E0@tzi.org> <4F92EEE2.6080801@cs.tcd.ie> <94216E93-4059-4EA2-B4AE-88BF67E74369@koanlogic.com> <49276523-70CC-40F2-9D34 -FF8F3348BA0C@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 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: Sat, 21 Apr 2012 20:56:01 -0000 On Apr 21, 2012, at 9:50 PM, Carsten Bormann wrote: > On Apr 21 2012, at 21:27, Thomas Fossati wrote: >> Sorry, I read "middlebox" as per RFC 3234, hence including proxies = into the category. >=20 > A CoAP intermediary is not "on the datagram path" in the sense of = 3234. Actually, section 2.14 says that proxies fall under the same term = "because the actual applications sessions traverse them." =20 Ten years have passed since 3234, so the terminology may have shifted a = bit in the meanwhile, but since there was no "updated by" nor "obsoleted = by" I've just taken it for granted. > In the CoAP applications I'm seeing, CoAP intermediaries are not "put = in the way" to restrict communication (or to bridge address spaces -- = most work on CoAP is IPv6 based). There may be different use cases though, where some kind of policy is = enforced (e.g. allow this, deny that, etc.) at an intermediary. > Often, CoAP intermediaries mark trust boundaries. > There may be no end-to-end trust relationship at all, so no use for = end-to-end security -- (CoAP-hop)-by-hop security is actually what is = desirable in these cases. Is the requesting client supposed to be aware of the hop-by-hop security = in place ? If yes (i.e. if the client can explicitly decide to request a secured = path), we need to specify what a Proxy-Uri with a coaps scheme means in = terms of requirements on the intermediaries. > However, there are also applications where the performance improvement = is essential (i.e., the intermediary is "getting in the way" for = performance reasons) but does not imply any trust. > That's where it would help to have alternate modes of security to the = ones we already have. Right. That's exactly the scenario that we took into consideration for = the SOS paper. I think that Angelo has an use case for this. > This is also true where the intermediaries are placed mainly to = perform a protocol transition, e.g. from CoAP to HTTP -- the only things = end-to-end here are the URIs and the payloads. > It is conceivable to augment this by, say, tunneling DTLS through = HTTP, so a CONNECT-style function might be made to work (i.e., the = HTTP-side endpoint would run CoAP over DTLS over HTTP to the = intermediary, then the DTLS is unpacked and sent on over UDP to the = CoAP-side endpoint). Yes, or use websocket as the tunneling facility (looks simpler.) > For the applications I have looked at that really need to cross = untrusted intermediaries, I'd rather do object security. Well, at present the only way to go with object security in CoAP seems = to roll your own crypto envelope, which is an *extremely* delicate task. = So, basically, we are left with no sensible choice at that layer, and = neither we have one at the IP layer [*]. That's why DTLS is, in theory, = an appealing way out. But still we have to figure out how to make it = fit into the constrained devices without the application bits being = spilled on the desk :-) [*] there was some work on IPsec at SICS in collaboration with Lancaster = University, someone knows more about the current status ?= From cabo@tzi.org Sat Apr 21 14:38: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 2C40F11E8072 for ; Sat, 21 Apr 2012 14:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.315 X-Spam-Level: X-Spam-Status: No, score=-106.315 tagged_above=-999 required=5 tests=[AWL=-0.066, 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 CjwI+Bry3Iuc for ; Sat, 21 Apr 2012 14:38:46 -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 DB6AD21F860D for ; Sat, 21 Apr 2012 14:38:45 -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 q3LLcX2w010826; Sat, 21 Apr 2012 23:38:33 +0200 (CEST) Received: from [192.168.217.105] (p5489B641.dip.t-dialin.net [84.137.182.65]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D069C34B; Sat, 21 Apr 2012 23:38:32 +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: Sat, 21 Apr 2012 23:38:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3A4E7A39-C78D-45A9-97ED-9D48B4107DED@tzi.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> <4F8D1EA8.6080800@ericsson.com> <68B487AC-7384-4B75-9E1F-32CB8454D2F0@koanlogic.com> <4F92196E.9000701@cs.tcd.ie> <9158B27B-8C40-43A7-B957-961A9E29448B@koanlogic.com> <4F92DCFF.4090301@cs.tcd.ie> <7C11BCD4-3A3A-41AE-B4BC-E374BE737B47@koanlogic.com> <4F1131E2-6997-4F2B-A51A-DD2A8607F9E0@tzi.org> <4F92EEE2.6080801@cs.tcd.ie> <94216E93-4059-4EA2-B4AE-88BF67E74369@koanlogic.com> <49276523-70CC-40F2-9D34 -FF8F3348BA0C@tzi.org> To: Thomas Fossati X-Mailer: Apple Mail (2.1257) Cc: core WG Subject: [core] Specifying security parameters 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, 21 Apr 2012 21:38:50 -0000 On Apr 21, 2012, at 22:55, Thomas Fossati wrote: > Is the requesting client supposed to be aware of the hop-by-hop = security in place ? >=20 > If yes (i.e. if the client can explicitly decide to request a secured = path), we need to specify what a Proxy-Uri with a coaps scheme means in = terms of requirements on the intermediaries. The client that asks an intermediary to do a "coaps://" request has = pretty much the same problem as a local client that asks a local piece = of software to do a "coaps://" request. (Except that, in the latter case, it may or may not be easier to = establish some side channels for transferring the security information. = But let's assume for generality it is not.) So what I'd like to convey with a request, inside or outside the URI, = is: -- what are my requirements on the communications security? ("coaps" is just one bit, but doesn't tell me what kind of security I = actually want -- what certificates/cert chains do I accept, what cipher = suites are acceptable, ...) -- what kind of (mutual?) authentication do I want to use? Is that = implicit in the comsec setup (as with PSK identities or client = certificates)? Or do I add things like oauth, password-style options = like http authentication, cookies, ... -- what other parameters do I want to supply to enable authorization = (say, role selection in a chinese wall scenario)? etc. HTTP solves essentially none of that, so there is nothing we can go = ahead and copy. So far, the working hypothesis is that there is some local out-of-band = mechanism to get a local DTLS implementation to do most of this for us. = This doesn't transfer to the proxy scenario, where we'd need a way to = transport all these data from the client to the proxy so that it can do = the right security for us. Again, having a "coaps" scheme strikes me as pretty non-functional -- it = conveys one bit, "hey, I'd like some security with that", but none of = the crucial information listed above. Useless. Until we are able to put this stuff into or alongside a URI, I see no = way to do this. And it's none of the business of the CoRE working group to invent all = this mechanism. Gr=FC=DFe, Carsten PS.: = http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05026.html points to another thread around the same basic problem. From tho@koanlogic.com Sun Apr 22 03:22: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 1A56521F85E4 for ; Sun, 22 Apr 2012 03:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 wctTW2MLsXv1 for ; Sun, 22 Apr 2012 03:22:42 -0700 (PDT) Received: from gonzo.koanlogic.com (koanlogic.com [64.251.31.111]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFBD21F85DF for ; Sun, 22 Apr 2012 03:22:42 -0700 (PDT) Received: from chello062178222142.13.15.univie.teleweb.at ([62.178.222.142]:52890 helo=[192.168.0.11]) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1SLtw2-0002Za-0g; Sun, 22 Apr 2012 06:22:35 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: <3A4E7A39-C78D-45A9-97ED-9D48B4107DED@tzi.org> Date: Sun, 22 Apr 2012 12:22:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8731C205-19B1-43A0-B522-CE167C7BD80B@koanlogic.com> 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> <4F8D1EA8.6080800@ericsson.com> <68B487AC-7384-4B75-9E1F-32CB8454D2F0@koanlogic.com> <4F92196E.9000701@cs.tcd.ie> <9158B27B-8C40-43A7-B957-961A9E29448B@koanlogic.com> <4F92DCFF.4090301@cs.tcd.ie> <7C11BCD4-3A3A-41AE-B4BC-E374BE737B47@koanlogic.com> <4F1131E2-6997-4F2B-A51A-DD2A8607F9E0@tzi.org> <4F92EEE2.6080801@cs.tcd.ie> <94216E93-4059-4EA2-B4AE-88BF67E74369@koanlogic.com> <49276523-70CC-40F2-9D34 -FF8F3348BA0C@tzi.org> <3A4E7A39-C78D-45A9-97ED-9D48B4107DED@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 Subject: Re: [core] Specifying security parameters 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, 22 Apr 2012 10:22:43 -0000 On Apr 21, 2012, at 11:38 PM, Carsten Bormann wrote: > Until we are able to put this stuff into or alongside a URI, I see no = way to do this. > And it's none of the business of the CoRE working group to invent all = this mechanism. I think instead that there is room to provide a decent level of security = even in presence of proxies. Either using a CONNECT-like primitive, or = forcing intermediaries to always act on coaps URIs in some pre-arranged = way (e.g. CoAP spec says that each proxy in the chain has to provide a = security level at least "X" when the coaps scheme is used -- where X = could be TLS or DTLS with mutual auth.) Or, if we don't agree that this is possible, we should state it clearly = in the spec: "resources in the coaps scheme cannot be retrieved through = proxies, and are therefore not allowed in Proxy-Uri." > PS.: = http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05026.html > points to another thread around the same basic problem. Pushing security related meta-info in the URI may close our issue, but = then opens another which may be actually bigger, ie. the secure binding = of these meta-info to the underlying secure channel. This all leave us = in a situation where in the short/middle term we don't have a practical = solution in place.= From cabo@tzi.org Sun Apr 22 04:56: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 D9D0521F860D for ; Sun, 22 Apr 2012 04:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.314 X-Spam-Level: X-Spam-Status: No, score=-106.314 tagged_above=-999 required=5 tests=[AWL=-0.065, 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 IBC0-g41DdqZ for ; Sun, 22 Apr 2012 04:56: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 0EBD721F85EF for ; Sun, 22 Apr 2012 04:56: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 q3MBucP6021568; Sun, 22 Apr 2012 13:56:38 +0200 (CEST) Received: from [192.168.217.105] (p5489B676.dip.t-dialin.net [84.137.182.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id CC22D3BC; Sun, 22 Apr 2012 13:56: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: <8731C205-19B1-43A0-B522-CE167C7BD80B@koanlogic.com> Date: Sun, 22 Apr 2012 13:56:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0645900D-3DA0-4324-BE2C-61814F51CC3F@tzi.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> <4F8D1EA8.6080800@ericsson.com> <68B487AC-7384-4B75-9E1F-32CB8454D2F0@koanlogic.com> <4F92196E.9000701@cs.tcd.ie> <9158B27B-8C40-43A7-B957-961A9E29448B@koanlogic.com> <4F92DCFF.4090301@cs.tcd.ie> <7C11BCD4-3A3A-41AE-B4BC-E374BE737B47@koanlogic.com> <4F1131E2-6997-4F2B-A51A-DD2A8607F9E0@tzi.org> <4F92EEE2.6080801@cs.tcd.ie> <94216E93-4059-4EA2-B4AE-88BF67E74369@koanlogic.com> <49276523-70CC-40F2-9D34 -FF8F3348BA0C@tzi.org> <3A4E7A39-C78D-45A9-97ED-9D48B4107DED@tzi.org> <8731C205-19B1-43A0-B522-CE167C7BD80B@koanlogic.com> To: Thomas Fossati X-Mailer: Apple Mail (2.1257) Cc: core WG Subject: Re: [core] Specifying security parameters 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, 22 Apr 2012 11:56:50 -0000 On Apr 22, 2012, at 12:22, Thomas Fossati wrote: > On Apr 21, 2012, at 11:38 PM, Carsten Bormann wrote: >> Until we are able to put this stuff into or alongside a URI, I see no = way to do this. >> And it's none of the business of the CoRE working group to invent all = this mechanism. >=20 > I think instead that there is room to provide a decent level of = security even in presence of proxies. =20 (I think we should clearly differentiate between trusted and untrusted = intermediaries.) > Either using a CONNECT-like primitive, (This would be the untrusted intermediary?) I don't know how to do this in a way that is not just tunneling DTLS. Instead of tunneling DTLS, I'd rather send it over (UDP over) IP. That already works. > or forcing intermediaries to always act on coaps URIs in some = pre-arranged way (e.g. CoAP spec says that each proxy in the chain has = to provide a security level at least "X" when the coaps scheme is used = -- where X could be TLS or DTLS with mutual auth.) (Trusted intermediary? But not trusted enough to set the outgoing = security properly?) So where do all the security parameters come from that I listed? (I don't think there is such a thing as a "security level".) > Or, if we don't agree that this is possible, we should state it = clearly in the spec: "resources in the coaps scheme cannot be retrieved = through proxies, and are therefore not allowed in Proxy-Uri." Since the coaps scheme is all but meaningless, it is indeed not hard to = "support" it. The more important question is what are the security objectives that can = be met. >> PS.: = http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05026.html >> points to another thread around the same basic problem. >=20 > Pushing security related meta-info in the URI (important point: I said "into or alongside" the URI... =20 I don't have an answer on how to do this yet.) > may close our issue, but then opens another which may be actually = bigger, ie. the secure binding of these meta-info to the underlying = secure channel. This all leave us in a situation where in the = short/middle term we don't have a practical solution in place. Can you give an example where such a binding would be needed? Gr=FC=DFe, Carsten From kovatsch@inf.ethz.ch Sun Apr 22 09:45: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 699F021F8551 for ; Sun, 22 Apr 2012 09:45:59 -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, 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 ZdD5DLkH2WUW for ; Sun, 22 Apr 2012 09:45:58 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id 22B8C21F8541 for ; Sun, 22 Apr 2012 09:45:56 -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; Sun, 22 Apr 2012 18:45:55 +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; Sun, 22 Apr 2012 18:45:55 +0200 From: "Kovatsch Matthias" To: "cabo@tzi.org" , "core@ietf.org" Thread-Topic: Separate response + Block2 = non-empty ACK by client? Thread-Index: Ac0gp1Wk/jK2uX6/TpyYrwHQ/18PfA== Date: Sun, 22 Apr 2012 16:45:54 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B5139914ED@MBX10.d.ethz.ch> Accept-Language: en-US, de-CH Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [178.83.15.45] Content-Type: multipart/alternative; boundary="_000_55877B3AFB359744BA0F2140E36F52B5139914EDMBX10dethzch_" MIME-Version: 1.0 Subject: [core] Separate response + Block2 = non-empty ACK by client? 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, 22 Apr 2012 16:45:59 -0000 --_000_55877B3AFB359744BA0F2140E36F52B5139914EDMBX10dethzch_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8NCg0KDQoNCkkganVzdCBoaXQgdGhlIHVzZS1jYXNlIHdoZXJlIGEgcmVxdWVzdCB3aXRo IHNlcGFyYXRlIHJlc3BvbnNlIHJlcXVpcmVzIEJsb2NrMiB0cmFuc2Zlci4NCg0KV2hpbGUgZmln dXJpbmcgb3V0IHRoYXQgbXkgdHJhbnNmZXIgbGF5ZXIgc2V0IHRoZSB0eXBlIHRvIEFDSyBpbnN0 ZWFkIG9mIENPTiwgSSBub3RpY2VkIHRoaXMgaW4gdGhlIGJsb2NrIGRyYWZ0Og0KDQoNCg0KRmln dXJlIDEwLCBhZnRlciBhIFBPU1Qgd2l0aCBzZXBhcmF0ZSByZXNwb25zZToNCg0KDQoNCiAgICAg fCA8LS0tLS0tICAgQ09OIFtNSUQ9NDcxMl0sIDIuMDEgQ3JlYXRlZCwgMzdhLCAyLzAvMS8xMjgg ICB8DQoNCiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8DQoNCiAgICAgfCBBQ0sgW01JRD00NzEyXSwgMCwgMi8wLzEvMTI4ICAg ICAgICAgICAgICAgICAgICAgLS0tLS0tPiB8DQoNCiAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQoNCiAgICAgfCA8LS0tLS0t ICAgQ09OIFtNSUQ9NDcxM10sIDIuMDEgQ3JlYXRlZCwgMzdhLCAyLzEvMS8xMjggICB8DQoNCg0K DQpCdXQgdGhpcyBtZWFucyB0aGF0IHRoZSBjbGllbnQgc2VuZHMgYW4gZW1wdHkgQUNLIHdpdGgg YmxvY2sgb3B0aW9uISBJIHdhcyBpbiB0aGUgdW5kZXJzdGFuZGluZyB0aGF0IGVtcHR5IEFDS3Mg YXJlIGVtcHR5Pw0KDQpBbnlob3csIEkgdGhpbmsgdGhpcyBicmVha3MgYWxsIGxheWVyZWQgYXBw bGljYXRpb25zIChvciBtYWtlcyB0aGVtIHVubmVjZXNzYXJpbHkgY29tcGxleCkuDQoNCg0KDQpB bSBJIHdyb25nIGFzc3VtaW5nIHRoYXQgdGhpcyAoQmxvY2syIHdpdGggcmVxdWVzdC1kZXBlbmRp bmcgcmVzcG9uc2UpIGFsc28gb25seSB3b3JrcyBmb3Igc2VydmVycyB0aGF0IGNhY2hlIHRoZSBi b2R5IGZvciB0aGUgY2xpZW50cz8gTWF5YmUgdGhlIGRvY3VtZW50IHNob3VsZCBhZHZpc2UgdG8g dXNlIHJlc291cmNlIHN0YXRlIGFuZCBwb2ludCB0aGVyZSB2aWEgTG9jYXRpb24/DQoNCg0KDQpB c3N1bWluZyBjYWNoaW5nLCB0aGUgQ09OIHNob3VsZCBiZSBBQ0tlZCAoZW1wdHkpIGFuZCB0aGVu IHRoZSBjbGllbnQgcmVwZWF0cyBoaXMgcmVxdWVzdCBmb3IgdGhlIG5leHQgYmxvY2sgdG8gaGF2 ZSBhIOKAnG5vcm1hbOKAnSBCbG9jazIgdHJhbnNmZXIuDQoNCg0KDQpDaWFvDQoNCk1hdHRoaWFz DQoNCg0K --_000_55877B3AFB359744BA0F2140E36F52B5139914EDMBX10dethzch_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRl eHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJOdXIgVGV4dCBa Y2huIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVM7fQ0Kc3Bhbi5OdXJUZXh0WmNobg0KCXttc28tc3R5bGUtbmFtZToi TnVyIFRleHQgWmNobiI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJOdXIgVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVw dCAxMjkuNzVwdCAyLjBjbSAxMjkuN3B0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iREUtQ0giIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5IZWxsbzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPkkganVzdCBoaXQgdGhl IHVzZS1jYXNlIHdoZXJlIGEgcmVxdWVzdCB3aXRoIHNlcGFyYXRlIHJlc3BvbnNlIHJlcXVpcmVz IEJsb2NrMiB0cmFuc2Zlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5XaGlsZSBmaWd1 cmluZyBvdXQgdGhhdCBteSB0cmFuc2ZlciBsYXllciBzZXQgdGhlIHR5cGUgdG8gQUNLIGluc3Rl YWQgb2YgQ09OLCBJIG5vdGljZWQgdGhpcyBpbiB0aGUgYmxvY2sgZHJhZnQ6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Rmln dXJlIDEwLCBhZnRlciBhIFBPU1Qgd2l0aCBzZXBhcmF0ZSByZXNwb25zZTo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fCAmbHQ7LS0tLS0tJm5ic3A7Jm5ic3A7IENPTiBbTUlEPTQ3MTJdLCAyLjAxIENyZWF0ZWQsIDM3 YSwgMi8wLzEvMTI4Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgQUNLIFtNSUQ9NDcxMl0s IDAsIDIvMC8xLzEyOCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAtLS0tLS0mZ3Q7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDt8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgJmx0Oy0tLS0t LSZuYnNwOyZuYnNwOyBDT04gW01JRD00NzEzXSwgMi4wMSBDcmVhdGVkLCAzN2EsIDIvMS8xLzEy OCZuYnNwOyZuYnNwOyB8PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Ymxh Y2siPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJjb2xvcjpibGFjayI+QnV0IHRoaXMgbWVhbnMgdGhhdCB0aGUgY2xpZW50IHNlbmRzIGFuIGVt cHR5IEFDSyB3aXRoIGJsb2NrIG9wdGlvbiEgSSB3YXMgaW4gdGhlIHVuZGVyc3RhbmRpbmcgdGhh dCBlbXB0eSBBQ0tzIGFyZSBlbXB0eT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5Bbnlo b3csIEkgdGhpbmsgdGhpcyBicmVha3MgYWxsIGxheWVyZWQgYXBwbGljYXRpb25zIChvciBtYWtl cyB0aGVtIHVubmVjZXNzYXJpbHkgY29tcGxleCkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+QW0gSSB3cm9uZyBhc3N1bWlu ZyB0aGF0IHRoaXMgKEJsb2NrMiB3aXRoIHJlcXVlc3QtZGVwZW5kaW5nIHJlc3BvbnNlKSBhbHNv IG9ubHkgd29ya3MgZm9yIHNlcnZlcnMgdGhhdCBjYWNoZSB0aGUgYm9keSBmb3IgdGhlIGNsaWVu dHM/IE1heWJlIHRoZSBkb2N1bWVudCBzaG91bGQgYWR2aXNlIHRvIHVzZSByZXNvdXJjZSBzdGF0 ZSBhbmQNCiBwb2ludCB0aGVyZSB2aWEgTG9jYXRpb24/PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+QXNzdW1pbmcgY2FjaGlu ZywgdGhlIENPTiBzaG91bGQgYmUgQUNLZWQgKGVtcHR5KSBhbmQgdGhlbiB0aGUgY2xpZW50IHJl cGVhdHMgaGlzIHJlcXVlc3QgZm9yIHRoZSBuZXh0IGJsb2NrIHRvIGhhdmUgYSDigJxub3JtYWzi gJ0gQmxvY2syIHRyYW5zZmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPkNpYW88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs YWNrIj5NYXR0aGlhczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_55877B3AFB359744BA0F2140E36F52B5139914EDMBX10dethzch_-- From cabo@tzi.org Sun Apr 22 09:59: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 0044B21F85A4 for ; Sun, 22 Apr 2012 09:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.292 X-Spam-Level: X-Spam-Status: No, score=-106.292 tagged_above=-999 required=5 tests=[AWL=-0.043, 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 W2Cm+3gD9ZDl for ; Sun, 22 Apr 2012 09:59: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 1BD4B21F8599 for ; Sun, 22 Apr 2012 09:59: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 q3MGxUFD000423; Sun, 22 Apr 2012 18:59:30 +0200 (CEST) Received: from [192.168.217.117] (p5489B676.dip.t-dialin.net [84.137.182.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 0982442E; Sun, 22 Apr 2012 18:59:29 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: <55877B3AFB359744BA0F2140E36F52B5139914ED@MBX10.d.ethz.ch> Date: Sun, 22 Apr 2012 18:59:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55877B3AFB359744BA0F2140E36F52B5139914ED@MBX10.d.ethz.ch> To: "Kovatsch Matthias" X-Mailer: Apple Mail (2.1257) Cc: "core@ietf.org" Subject: Re: [core] Separate response + Block2 = non-empty ACK by client? 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, 22 Apr 2012 16:59:36 -0000 Yes, I don't think we really have tested the concepts demonstrated in = Figure 10, which is about the interaction between Block1 and Block2 (see = also ticket #203). Good to revisit this. If we go forward with #210, much of this will become simpler. With #210, there is no need to send back Block2 options just for = disambiguating them. This would solve the problem you note with an ACK 0 suddenly carrying = options. > =20 > Figure 10, after a POST with separate response: > =20 > | <------ CON [MID=3D4712], 2.01 Created, 37a, 2/0/1/128 | > | | > | ACK [MID=3D4712], 0, 2/0/1/128 ------> | > | | > | <------ CON [MID=3D4713], 2.01 Created, 37a, 2/1/1/128 | > =20 > But this means that the client sends an empty ACK with block option! I = was in the understanding that empty ACKs are empty? Right, let's fix that. > Anyhow, I think this breaks all layered applications (or makes them = unnecessarily complex). "this" =3D ? > Am I wrong assuming that this (Block2 with request-depending response) = also only works for servers that cache the body for the clients? Well, the specific use case was POST, and this is for sending back the = (atomic) POST response. > Maybe the document should advise to use resource state and point there = via Location? That would be the preferred way to send back information that is already = represented in a resource. Maybe not so useful for SOAP. > Assuming caching, the CON should be ACKed (empty) and then the client = repeats his request for the next block to have a =93normal=94 Block2 = transfer. Well, what exactly would who repeat? Gr=FC=DFe, Carsten From kovatsch@inf.ethz.ch Sun Apr 22 10:17: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 E875821F8609 for ; Sun, 22 Apr 2012 10:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[AWL=1.000, 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 XiJu8p6v4Y37 for ; Sun, 22 Apr 2012 10:17:24 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id 246F421F85B6 for ; Sun, 22 Apr 2012 10:17:24 -0700 (PDT) Received: from CAS12.d.ethz.ch (172.31.38.212) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.2.283.3; Sun, 22 Apr 2012 19:17:23 +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; Sun, 22 Apr 2012 19:17:23 +0200 From: "Kovatsch Matthias" To: Carsten Bormann Thread-Topic: Separate response + Block2 = non-empty ACK by client? Thread-Index: Ac0gp1Wk/jK2uX6/TpyYrwHQ/18PfP//4l4A///eChA= Date: Sun, 22 Apr 2012 17:17:21 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B513991576@MBX10.d.ethz.ch> References: <55877B3AFB359744BA0F2140E36F52B5139914ED@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] Separate response + Block2 = non-empty ACK by client? 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, 22 Apr 2012 17:17:25 -0000 > If we go forward with #210, much of this will become simpler. > With #210, there is no need to send back Block2 options just for > disambiguating them. But how will the client request the next block? (see "what to repeat" below= ) =20 > > Anyhow, I think this breaks all layered applications (or makes them > unnecessarily complex). >=20 > "this" =3D ? That ACKing CONs (no piggybacking) is entangled with block transfer control= .=20 > > Assuming caching, the CON should be ACKed (empty) and then the client > repeats his request for the next block to have a "normal" Block2 transfer= . >=20 > Well, what exactly would who repeat? The client sends again a POST with the same token, Block2 with increased bl= ock number. In my implementation, the POST would not be executed again because the tran= sfer layer handles it out of its cache and does not pass it up to the resou= rce. The problem is now, that I use the token to identify this request (so for m= e the token was always a session/transaction ID (just like MID, only for a = "session" (the unpopular word..) of multiple messages). With ticket #210, h= owever, the server can only guess from the block number, what the client wa= nts (num=3D0 or no Block2: new transaction, num>0 continue transfer). At the moment, I can only think of actually introducing sessions (or overal= l transactions) by more definitions on how to use the token or, second, som= ehow forbid these ambiguous actions that need the notion of a session... > Gr=FC=DFe, Carsten Matthias From cabo@tzi.org Sun Apr 22 11:44: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 75A8221F8642 for ; Sun, 22 Apr 2012 11:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.291 X-Spam-Level: X-Spam-Status: No, score=-106.291 tagged_above=-999 required=5 tests=[AWL=-0.042, 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 12QozdUDhD9z for ; Sun, 22 Apr 2012 11:44:22 -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 9E01E21F8639 for ; Sun, 22 Apr 2012 11:44:21 -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 q3MIiEPm005391; Sun, 22 Apr 2012 20:44:14 +0200 (CEST) Received: from [192.168.217.117] (p5489B676.dip.t-dialin.net [84.137.182.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A80E8469; Sun, 22 Apr 2012 20:44: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: <55877B3AFB359744BA0F2140E36F52B513991576@MBX10.d.ethz.ch> Date: Sun, 22 Apr 2012 20:44:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <903EF52F-34A4-41E0-AF5C-98268ADB6F2C@tzi.org> References: <55877B3AFB359744BA0F2140E36F52B5139914ED@MBX10.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B513991576@MBX10.d.ethz.ch> To: "Kovatsch Matthias" X-Mailer: Apple Mail (2.1257) Cc: "core@ietf.org" Subject: Re: [core] Separate response + Block2 = non-empty ACK by client? 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, 22 Apr 2012 18:44:22 -0000 On Apr 22, 2012, at 19:17, Kovatsch Matthias wrote: >> If we go forward with #210, much of this will become simpler. >> With #210, there is no need to send back Block2 options just for >> disambiguating them. >=20 > But how will the client request the next block? (see "what to repeat" = below) It wouldn't (see below). >>> Anyhow, I think this breaks all layered applications (or makes them >> unnecessarily complex). >>=20 >> "this" =3D ? >=20 > That ACKing CONs (no piggybacking) is entangled with block transfer = control.=20 OK, let's get rid of that. >>> Assuming caching, the CON should be ACKed (empty) and then the = client >> repeats his request for the next block to have a "normal" Block2 = transfer. >>=20 >> Well, what exactly would who repeat? >=20 > The client sends again a POST with the same token, Block2 with = increased block number. That was what I was trying to avoid with the scheme in Figure 10, and = what we need to nail down to close #203. Essentially, the idea is that a Block2 with PUT/POST would be "turned = around" in the spirit of a separate response, similar to the way observe = works with Block2: The server takes the initiative to send the blocks. (There is no point in trying to be stateless here, so from my point of = view, leaving the initiative with the server is OK.) The only thing that the client does at this point is send ACKs, and = these might as well be ACK/0s. The only thing that is missing when we take the Block2 options out of = the ACKs is the block size negotiation. The best way to do this might = be for the client to send a Block2 request option early. There is no = way left to do late negotiation in this scheme. Gr=FC=DFe, Carsten From tho@koanlogic.com Sun Apr 22 12:00: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 66C4321F867A for ; Sun, 22 Apr 2012 12:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.414 X-Spam-Level: X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[AWL=0.185, 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 sP+GLr5i62HO for ; Sun, 22 Apr 2012 12:00:21 -0700 (PDT) Received: from gonzo.koanlogic.com (koanlogic.com [64.251.31.111]) by ietfa.amsl.com (Postfix) with ESMTP id EFF8621F8698 for ; Sun, 22 Apr 2012 12:00:19 -0700 (PDT) Received: from chello062178222142.13.15.univie.teleweb.at ([62.178.222.142]:57813 helo=[192.168.0.11]) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1SM211-0003gU-7A; Sun, 22 Apr 2012 15:00:15 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: <0645900D-3DA0-4324-BE2C-61814F51CC3F@tzi.org> Date: Sun, 22 Apr 2012 21:00:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: 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> <4F8D1EA8.6080800@ericsson.com> <68B487AC-7384-4B75-9E1F-32CB8454D2F0@koanlogic.com> <4F92196E.9000701@cs.tcd.ie> <9158B27B-8C40-43A7-B957-961A9E29448B@koanlogic.com> <4F92DCFF.4090301@cs.tcd.ie> <7C11BCD4-3A3A-41AE-B4BC-E374BE737B47@koanlogic.com> <4F1131E2-6997-4F2B-A51A-DD2A8607F9E0@tzi.org> <4F92EEE2.6080801@cs.tcd.ie> <94216E93-4059-4EA2-B4AE-88BF67E74369@koanlogic.com> <49276523-70CC-40F2-9D34 -FF8F3348BA0C@tzi.org> <3A4E7A39-C78D-45A9-97ED-9D48B4107DED@tzi.org> <8731C205-19B1-43A0-B522-CE167C7BD80B@koanlogic.com> <0645900D-3DA0-4324-BE2C-61814F51CC3F@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 Subject: Re: [core] Specifying security parameters 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, 22 Apr 2012 19:00:23 -0000 On Apr 22, 2012, at 1:56 PM, Carsten Bormann wrote: > (I think we should clearly differentiate between trusted and untrusted = intermediaries.) Sure, this may represent a basic discriminant. =20 Anyway it's not always possible for a client to assume it (eg. if = multiple proxies may be traversed and trust is not transitive.) And = this is always true whenever the trust relationship has to be composed = hop-by-hop and there is no E2E verification.=20 >> Either using a CONNECT-like primitive, >=20 > (This would be the untrusted intermediary?) > I don't know how to do this in a way that is not just tunneling DTLS. > Instead of tunneling DTLS, I'd rather send it over (UDP over) IP. > That already works. How does it work if proxy is an ALG but not a BR ? You seem to assume = that the proxy is always a BR. >> Pushing security related meta-info in the URI >=20 > (important point: I said "into or alongside" the URI... =20 > I don't have an answer on how to do this yet.) If it doesn't get its way into the URI, it has to be specified as a CoAP = option, or in some other (to be defined) CoAP specific way. This train is headed straight to an in-CoAP security mechanism (which, = given the peculiar nature of CoAP deployments and target hardware seems = to me like the less painful approach.) >> may close our issue, but then opens another which may be actually = bigger, ie. the secure binding of these meta-info to the underlying = secure channel. This all leave us in a situation where in the = short/middle term we don't have a practical solution in place. >=20 > Can you give an example where such a binding would be needed? What I meant is: how do the client gets undeniable evidence that the = requested COMSEC services have been enforced on each step of the path to = the resource ? Ie. how the requested security attributes are bound to the response so = that the client can verify their application ? I feel like we are waiting for Godot (pick one of DTLS, IPsec, JOSE, = OAuth), while still missing the basic set of security services to = operate CoAP networks with a decent level of security. Perhaps it's time to think seriously about a CoAP specific COMSEC = mechanism instead of relying on external blocks that for one reason or = another are never completely satisfactory and/or applicable ? From kovatsch@inf.ethz.ch Sun Apr 22 12:06: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 62F3F21F8663 for ; Sun, 22 Apr 2012 12:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[AWL=1.000, 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 2BBDCY1Kv3Z2 for ; Sun, 22 Apr 2012 12:06:14 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3697D21F8594 for ; Sun, 22 Apr 2012 12:06:11 -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; Sun, 22 Apr 2012 21:06:11 +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; Sun, 22 Apr 2012 21:06:11 +0200 From: "Kovatsch Matthias" To: Carsten Bormann Thread-Topic: Separate response + Block2 = non-empty ACK by client? Thread-Index: Ac0gp1Wk/jK2uX6/TpyYrwHQ/18PfP//4l4A///eChCAAD83AP//3MTg Date: Sun, 22 Apr 2012 19:06:09 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B5139916FE@MBX10.d.ethz.ch> References: <55877B3AFB359744BA0F2140E36F52B5139914ED@MBX10.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B513991576@MBX10.d.ethz.ch> <903EF52F-34A4-41E0-AF5C-98268ADB6F2C@tzi.org> In-Reply-To: <903EF52F-34A4-41E0-AF5C-98268ADB6F2C@tzi.org> Accept-Language: en-US, de-CH Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [178.83.15.45] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "core@ietf.org" Subject: Re: [core] Separate response + Block2 = non-empty ACK by client? 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, 22 Apr 2012 19:06:18 -0000 > > The client sends again a POST with the same token, Block2 with increase= d > block number. >=20 > That was what I was trying to avoid with the scheme in Figure 10, and wha= t we > need to nail down to close #203. >=20 > Essentially, the idea is that a Block2 with PUT/POST would be "turned aro= und" in > the spirit of a separate response, similar to the way observe works with = Block2: > The server takes the initiative to send the blocks. Okay, I wondered whether this was implied by the example... probably someth= ing else we need text on. Oh, I missed that observe + Block2 should work that way. There I also used a client-initiated GET for further blocks. This would als= o leave more control to the client. Maybe it does not want to receive the c= omplete representation right away or is already happy that he is still on t= he list. What should he do in this case with this turn-around scheme? Wait = until the retransmissions time out? Send a RST? But that also cancels the o= bserve relationship... > (There is no point in trying to be stateless here, so from my point of vi= ew, > leaving the initiative with the server is OK.) The only thing that the cl= ient does at > this point is send ACKs, and these might as well be ACK/0s. >=20 > The only thing that is missing when we take the Block2 options out of the= ACKs is > the block size negotiation. The best way to do this might be for the cli= ent to > send a Block2 request option early. There is no way left to do late nego= tiation in > this scheme. At the moment, I have the same problem with GET and blockwise separate resp= onse. Odd, to also waive late negotiation here... Only way I see is to force the programmer of the resource handler to take c= are of this caching and so only have a separate response from time to time. >=20 > Gr=FC=DFe, Carsten From cabo@tzi.org Sun Apr 22 12:23: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 DFEE521F85D9 for ; Sun, 22 Apr 2012 12:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.29 X-Spam-Level: X-Spam-Status: No, score=-106.29 tagged_above=-999 required=5 tests=[AWL=-0.041, 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 7L8-MQsMGtJO for ; Sun, 22 Apr 2012 12:23: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 19A9F21F85D3 for ; Sun, 22 Apr 2012 12:23: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 q3MJN5Xt017341; Sun, 22 Apr 2012 21:23:05 +0200 (CEST) Received: from [192.168.217.117] (p5489B676.dip.t-dialin.net [84.137.182.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3AD6B477; Sun, 22 Apr 2012 21:23: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: <55877B3AFB359744BA0F2140E36F52B5139916FE@MBX10.d.ethz.ch> Date: Sun, 22 Apr 2012 21:23:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55877B3AFB359744BA0F2140E36F52B5139914ED@MBX10.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B513991576@MBX10.d.ethz.ch> <903EF52F-34A4-41E0-AF5C-98268ADB6F2C@tzi.org> <55877B3AFB359744BA0F2140E36F52B5139916FE@MBX10.d.ethz.ch> To: "Kovatsch Matthias" X-Mailer: Apple Mail (2.1257) Cc: "core@ietf.org" Subject: Re: [core] Separate response + Block2 = non-empty ACK by client? 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, 22 Apr 2012 19:23:13 -0000 > Okay, I wondered whether this was implied by the example... probably = something else we need text on. Yes, we do, as part of resolving #203, I think. > Maybe it does not want to receive the complete representation right = away or is already happy that he is still on the list. What should he do = in this case with this turn-around scheme? Wait until the = retransmissions time out? Send a RST? But that also cancels the observe = relationship... Well, if you are an observer, you *want* the data (otherwise there won't = be eventual consistency). If you don't want the data, canceling the = observation relationship is exactly what you want to do. (But maybe I'm missing the use case.) >> The only thing that is missing when we take the Block2 options out of = the ACKs is >> the block size negotiation. The best way to do this might be for the = client to >> send a Block2 request option early. There is no way left to do late = negotiation in >> this scheme. >=20 > At the moment, I have the same problem with GET and blockwise separate = response. But that is not a problem -- with block-wise GET, you get the separate = response for that block only. The "turn-around" (server initiative for sending Block2 blocks) would be = needed for PUT/POST and observe, not for GET. Actually, with GET, nothing stops the server from sending half of the = blocks in separate responses and the other half piggy-backed on the = ACKs. In other words, the decision to "turn around" is not at all following = from the decision to do a separate response. (Once you do turn around, = of course, everything behaves like separate responses.) Gr=FC=DFe, Carsten From cabo@tzi.org Sun Apr 22 12:53: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 2549421F85C3 for ; Sun, 22 Apr 2012 12:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.289 X-Spam-Level: X-Spam-Status: No, score=-106.289 tagged_above=-999 required=5 tests=[AWL=-0.040, 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 xrNCLc-JjzNs for ; Sun, 22 Apr 2012 12:53: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 3107B21F848B for ; Sun, 22 Apr 2012 12:53: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 q3MJr1h9026514; Sun, 22 Apr 2012 21:53:01 +0200 (CEST) Received: from [192.168.217.117] (p5489B676.dip.t-dialin.net [84.137.182.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C1230483; Sun, 22 Apr 2012 21:53:00 +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: Sun, 22 Apr 2012 21:52:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7C60E917-1E01-40B5-9785-13A11DF87E53@tzi.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> <4F8D1EA8.6080800@ericsson.com> <68B487AC-7384-4B75-9E1F-32CB8454D2F0@koanlogic.com> <4F92196E.9000701@cs.tcd.ie> <9158B27B-8C40-43A7-B957-961A9E29448B@koanlogic.com> <4F92DCFF.4090301@cs.tcd.ie> <7C11BCD4-3A3A-41AE-B4BC-E374BE737B47@koanlogic.com> <4F1131E2-6997-4F2B-A51A-DD2A8607F9E0@tzi.org> <4F92EEE2.6080801@cs.tcd.ie> <94216E93-4059-4EA2-B4AE-88BF67E74369@koanlogic.com> <49276523-70CC-40F2-9D34 -FF8F3348BA0C@tzi.org> <3A4E7A39-C78D-45A9-97ED-9D48B4107DED@tzi.org> <8731C205-19B1-43A0-B522-CE167C7BD80B@koanlogic.com> <0645900D-3DA0-4324-BE2C-61814F51CC3F@tzi.org> To: Thomas Fossati X-Mailer: Apple Mail (2.1257) Cc: core WG Subject: Re: [core] Specifying security parameters 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, 22 Apr 2012 19:53:10 -0000 On Apr 22, 2012, at 21:00, Thomas Fossati wrote: > On Apr 22, 2012, at 1:56 PM, Carsten Bormann wrote: >> (I think we should clearly differentiate between trusted and = untrusted intermediaries.) >=20 > Sure, this may represent a basic discriminant. =20 >=20 > Anyway it's not always possible for a client to assume it (eg. if = multiple proxies may be traversed and trust is not transitive.) And = this is always true whenever the trust relationship has to be composed = hop-by-hop and there is no E2E verification.=20 I have three use-cases in mind for the trusted intermediary: 1) the intermediary is the client's big brother. The client doesn't = really have the security smarts, so the client asks the big brother to = please handle all that stuff for me. That would be one of the trusted = intermediary cases. =20 2) the intermediary is the server's big brother -- again, the server = leaves the handling of complicated things like certificates to its big = brother (which probably talks via PSK to it). While the client does not = really "trust" the intermediary, it will have to trust it as much as it = trusts the server. In both cases, the intermediaries are pretty much autonomous to make = security-related decisions; there is very little point to try to get = something transitive going on. 3) the intermediary embodies a domain boundary, but is not tightly = implicated in the security dealings of either the client or the server. = I can blindly trust it with my data, but I can't trust it to know (read: = I need to tell it) how to talk to that other guy. That requires a lot = more work, and maybe that is what you have in mind. For now, I'd try to avoid that case. For the untrusted intermediary, I'm a bit at a loss, see below. > How does it work if proxy is an ALG but not a BR ? You seem to assume = that the proxy is always a BR. If I just want to send packets, I don't need an intermediary. So I don't care whether the proxy is a router or not: I'm not talking to = it in the first place. I'm sending my packets right to where they have to go. >>> Pushing security related meta-info in the URI >>=20 >> (important point: I said "into or alongside" the URI... =20 >> I don't have an answer on how to do this yet.) >=20 > If it doesn't get its way into the URI, it has to be specified as a = CoAP option, or in some other (to be defined) CoAP specific way. I was trying to point out that other spaces have similar problems here. But, sure, we don't have to solve their problems. However, as soon as we want to interoperate with, say, HTTP, we do. > This train is headed straight to an in-CoAP security mechanism (which, = given the peculiar nature of CoAP deployments and target hardware seems = to me like the less painful approach.) Again, how do we transport this over HTTP. If the answer is "run CoAP = over Websockets", that is easy. If we actually want to interoperate = with the HTTP world, we may need a grander vision. > What I meant is: how do the client gets undeniable evidence that the = requested COMSEC services have been enforced on each step of the path to = the resource ? It doesn't. > Ie. how the requested security attributes are bound to the response so = that the client can verify their application ? If the server were to certify "yes, this request came in over DTLS with = AES-128 based on a DHE handshake authenticated with ECC-mumble", the = client still wouldn't know anything about what else happened on the way = while the intermediary had unpacked the data. Maybe I don't get what = you want to be able to verify. > I feel like we are waiting for Godot (pick one of DTLS, IPsec, JOSE, = OAuth), while still missing the basic set of security services to = operate CoAP networks with a decent level of security. We know how to do that, and we have zeroed in on the use of DTLS for = that. We just don't know how to get miracles out of intermediaries, yet. If we can't solve your use-case, we probably need to know more about = your use-case. > Perhaps it's time to think seriously about a CoAP specific COMSEC = mechanism instead of relying on external blocks that for one reason or = another are never completely satisfactory and/or applicable ? Well, Alper tried that... I'm pretty sure DTLS is the right comsec mechanism for us, at least as = long as we don't try to use multicast. But I'm always willing to be surprised... Gr=FC=DFe, Carsten From jeroen.hoebeke@intec.ugent.be Sun Apr 22 13:16: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 5AA4B21F858A for ; Sun, 22 Apr 2012 13:16:30 -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=[AWL=0.001, 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 ltYcH8K1NiVM for ; Sun, 22 Apr 2012 13:16:29 -0700 (PDT) Received: from smtp3.ugent.be (smtp3.ugent.be [157.193.49.127]) by ietfa.amsl.com (Postfix) with ESMTP id CC78621F8582 for ; Sun, 22 Apr 2012 13:16:29 -0700 (PDT) Received: from localhost (mcheck2.ugent.be [157.193.49.249]) by smtp3.ugent.be (Postfix) with ESMTP id 89596C35F; Sun, 22 Apr 2012 22:16:28 +0200 (CEST) X-Virus-Scanned: by UGent DICT Received: from smtp3.ugent.be ([157.193.49.127]) by localhost (mcheck2.UGent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id 9Fwbh5dFC47Y; Sun, 22 Apr 2012 22:16:28 +0200 (CEST) Received: from [192.168.123.5] (78-21-4-198.access.telenet.be [78.21.4.198]) (Authenticated sender: jjhoebek) by smtp3.ugent.be (Postfix) with ESMTPSA id 29B40C35E; Sun, 22 Apr 2012 22:16:28 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: Jeroen Hoebeke In-Reply-To: <59F77F53-9086-47A2-987B-EB2021022850@tzi.org> Date: Sun, 22 Apr 2012 22:16:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F8DFF3D.50201@itm.uni-luebeck.de> <085E1C1D-4E7B-4494-9B75-D9BFC487A261@iii.ca> <4F919240.3010401@itm.uni-luebeck.de> <59F77F53-9086-47A2-987B-EB2021022850@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1257) X-Miltered: at jchkm3 with ID 4F94671B.00D by Joe's j-chkmail (http://helpdesk.ugent.be/email/)! X-j-chkmail-Enveloppe: 4F94671B.00D from 78-21-4-198.access.telenet.be/78-21-4-198.access.telenet.be/78.21.4.198/[192.168.123.5]/ X-j-chkmail-Score: MSGID : 4F94671B.00D on smtp3.ugent.be : j-chkmail score : X : R=. U=. O=## B=0.000 -> S=0.166 X-j-chkmail-Status: Ham Cc: core WG , Klaus Hartke 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: Sun, 22 Apr 2012 20:16:30 -0000 On 21 Apr 2012, at 09:33, Carsten Bormann wrote: > I was hoping to get a bit feedback from implementers which approach is = better, but it appears to turn out this is pretty much a bike shed = decision. Easiest way of adding this to our implementation would be: - encoder: use fencepost whenever difference between last and current = option number is >=3D 15 (=3D> never use 15 as option delta, except for = the end-of-option marker).=20 - decoder: oc =3D 15 and delta =3D 15 -> end-marker (without checking = length) For the case where the difference is equal to 15, you have the 1-byte = overhead for the fencepost. But it safes the trouble of dealing with the encoding of a zero-length = option that would normally result in an option delta of 15. So, +1 for reserving the entirety of 0xFx for oc=3D15 >=20 > My current decoder code just compares the next byte to 0xF0. So 0xFx = with x =E2=89=A0 0 is not special in that decoder. > But then my encoder code does not go to the trouble of trying to use = 15 as an option delta at all (which for oc=3D15 would require checking = that this is a non-zero-length option). >=20 > Bike shed, bike shed. >=20 > But I'm a little in favor of reserving the entirety of 0xFx for oc=3D15.= > If we ever start to make use of that reserved space, x would be a = normal option data structure length (including x=3D15 taking another = byte). Kind regards, Jeroen= From robert.cragie@gridmerge.com Mon Apr 23 07:57: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 4BF9E21F86D7; Mon, 23 Apr 2012 07:57:39 -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 tO3xKQcPYgBp; Mon, 23 Apr 2012 07:57:37 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id 883BC21F86C7; Mon, 23 Apr 2012 07:57:36 -0700 (PDT) Received: from client-86-29-169-249.brhm-bam-3.adsl.virginmedia.com ([86.29.169.249] helo=[192.168.0.2]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) id 1SMKhq-000528-Ig; Mon, 23 Apr 2012 15:57:34 +0100 Message-ID: <4F956E63.80408@gridmerge.com> Date: Mon, 23 Apr 2012 15:59:47 +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: apps-discuss@ietf.org, core Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080306000909040508090609" X-Authenticated-As: robert.cragie@gridmerge.com Subject: [core] Closing on the application/foo+exi discussion 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: Mon, 23 Apr 2012 14:57:42 -0000 This is a cryptographically signed message in MIME format. --------------ms080306000909040508090609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable I have read through the many e-mails on the topic and it didn't look=20 like we had closure on this. I don't see what is wrong with having an 'application/foo+exi' media=20 type. There are already precedents for using this type of syntax. All it = means is that the schemaId in the EXI options has specific meaning in=20 the 'foo' space and can be used to select a schema for schema-informed=20 EXI, as stated in Zach's draft. The alternative of using media type=20 'application/xml' and content coding 'exi', or media type=20 'application/exi' (equivalent IMHO) means that (assuming no a priori=20 knowledge) schemaId, if present, must be unambiguous, and this basically = means a URI. This is given as an example in the EXI specification but is = not mandated. If schemaId is not present, it should mean what it says in = the EXI specification, i.e. schema-less encoding. Often in constrained environment, originator and recipient may have=20 schema knowledge a priori and could choose to elide information=20 regarding media type and content coding and, in the case of EXI, EXI=20 options. Robert --------------ms080306000909040508090609 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 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQyMzE0NTk0N1owIwYJKoZI hvcNAQkEMRYEFJ+PDtwuUFgecTYK7Y8jTPtMeK9oMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDCBuQYJKwYBBAGCNxAEMYGrMIGoMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD VQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9mMIG7BgsqhkiG 9w0BCRACCzGBq6CBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3 BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0BAQEFAASCAQCPjUfjhf2SuEwF98xL8RMk PbfxHqqzdDVWeQWHkCLRH305Ldk1XpuVAGQDyRCGHzf9cEvnqnrNtj/M33WpxjHRMZcaTWoa iPU73q3R9SeSAtJ+uZk81Vizq5XWzyQMfgT4IdcJYgFoNyN0Z34+ei5wt9AYRRVJGIn3E663 8LhUD87iCZ+F+Cc4hfVqrqnE9V55Sfs+XvegzzTzjgvfgqf0qBQHr4BQmQNg90Hn/ZvHv/v6 /L1O/nWjWS4s+7ZUawozC4vpeZMym4pp3sBAMxnneQZhymNWT9tSYXd/taHgsOhTI6C1/7/x HYmhpqONRd+xiIp5uU0d2v2uSHwfvL+IAAAAAAAA --------------ms080306000909040508090609-- From fluffy@iii.ca Mon Apr 23 10:28: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 87FA921F86BB for ; Mon, 23 Apr 2012 10:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] 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 fR9csUTIbzQf for ; Mon, 23 Apr 2012 10:28:43 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 1856B21F876A for ; Mon, 23 Apr 2012 10:28:43 -0700 (PDT) Received: from sjc-vpn7-1727.cisco.com (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 746C622E256; Mon, 23 Apr 2012 13:28:36 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <55877B3AFB359744BA0F2140E36F52B513990663@MBX10.d.ethz.ch> Date: Mon, 23 Apr 2012 05:53:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <051.e7fbc0f0f5736d305a309a9e8d0cd924@trac.tools.ietf.org> <61887542-A2C0-4DF2-B784-34ABE12E38EF@iii.ca> <5BEC4E4C-FF04-44DC-A14B-2FA73E3D573F@tzi.org> <2A346094-E537-4536-AE35-7C88D70AC55C@iii.ca> <55877B3AFB359744BA0F2140E36F52B51398E11D@MBX10.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B513990663@MBX10.d.ethz.ch> To: Kovatsch Matthias X-Mailer: Apple Mail (2.1257) Cc: core WG 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: Mon, 23 Apr 2012 17:28:43 -0000 On Apr 21, 2012, at 10:20 , Kovatsch Matthias wrote: >> But I do think >> some limit is need for practical implementations and once we have a = limit, we >> need to have some agreement on what it is. Given the URL are = primarily for >> machine not human consumption, it seems like they can easily be = designed >> to be relatively short and and still easy for a human to debug. >=20 > The implementations could decide that through the applications they = shall support. > A server for instance must only support its own longest = hostname/Uri-Path/Uri-Query. > Clients could use the limitations from application profiles such as = SEP 2.0 or IPSO. >=20 > I think it would generally be best, if such profiles would specify = limitations and the protocol itself can be kept flexible, without = artificial limitations. So let me get this right, your think SEP 2.0 should define a limit but = IETF should not? What happens when I want to buy a COAP stack and use it = for both a SEP and IPSO profile?=20 >=20 >>> Regards >>> Matthias >=20 From fluffy@iii.ca Mon Apr 23 10:28: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 EA84B21F85BD for ; Mon, 23 Apr 2012 10:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] 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 ehfkTgi9xbxd for ; Mon, 23 Apr 2012 10:28:57 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 7669D21F876A for ; Mon, 23 Apr 2012 10:28:57 -0700 (PDT) Received: from sjc-vpn7-1727.cisco.com (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 2706722E25B; Mon, 23 Apr 2012 13:28:55 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: <175E4D4E-31AE-44CF-8CFF-DC6A26A64F74@tzi.org> Date: Mon, 23 Apr 2012 05:56:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2DC1D69D-9D89-409F-A8B2-94729A3787ED@iii.ca> References: <001b01cced71$c60c8b60$5225a220$@uni-rostock.de> <07CC0900-8116-4242-AB96-D74879E247D8@tzi.org> <001e01cced78$e09dd400$a1d97c00$@uni-rostock.de> <73456E11-9651-4FB8-82E3-1CBC490C55DF@tzi.org> <4F3E758B.8020007@stpeter.im> <000f01ccedb0$cd0fe620$672fb260$@uni-rostock.de> <5961B851-CBE9-445D-945A-2FC800A9667E@iii.ca> <91B1300E-F3A2-4672-8715-A0C006990DEB@sensinode.com> <175E4D4E-31AE-44CF-8CFF-DC6A26A64F74@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1257) Cc: core@ietf.org Subject: Re: [core] EXI content type and encoding (was: Resolution to tickets #176, #177, #181) 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, 23 Apr 2012 17:28:58 -0000 On Apr 21, 2012, at 24:58 , Carsten Bormann wrote: >> Instead we are now looking at the use of an informal naming like = application/senml-exi where there is no structured suffix exactly, but = this still means EXI for the application. What we are now trying to = figure out is what to day about that in the media type registration. = This means at least the SenML media type registration needs an update.=20= >=20 > Luckily, we are decoupled from that discussion; we can give the thing = a number whenever we want. >=20 > The intention is clearly to put application/senml[__]exi into our set = of registered content-type/content-coding combinations along with = application/senml+json and application/senml+xml. (Fill in the blank = after the discussion in apps-discuss closed.) >=20 > We could start agreeing on the numbers that will be registered here. >=20 > By the way, continuing to call option 1 Content-Type may now be = slightly confusing to HTTP mapper implementers. (Changing it to = something akin to "Content-Type-And-Encoding-Id" is ugly and will = confuse the CoAP implementers. I'm not sure who I want to confuse more. = Maybe sticking with the wrong name is better.) Given that there will be many more implementation is the future than = there has been so far, I think we should error not the side of con suing = the current developers. I don't think they will be very confused by this = so I'd rather see us change things to the best name possible.=20 >=20 > Gr=FC=DFe, Carsten >=20 From fluffy@cisco.com Mon Apr 23 10:29: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 E716321F8795 for ; Mon, 23 Apr 2012 10:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[AWL=0.350, 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 6x7oPIXyRFma for ; Mon, 23 Apr 2012 10:29:06 -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 A088421F8734 for ; Mon, 23 Apr 2012 10:29:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1041; q=dns/txt; s=iport; t=1335202144; x=1336411744; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=EH3DORzPNW3XIRzqnn8RPCgzeWQrE4o1obqPW66x8QA=; b=C6393Mg3fKiOre0bI3XSI/H5GcirFYSyZF5RKDB4V/yU7WRKVU77rchL Vzc1hh34OYkp4n1l9WrkXMPgr4s3iBYcv1V9QVCAGVZwHIu3ggL5mMWVd pBl9IW8pXoBrenqYmNCELKTQFBky8Pb1F8Hg0SgGCEyJUWXFj1PacAnyv k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABSQlU+rRDoG/2dsb2JhbABEsVGBB4IJAQEBAwESAVQSBQsLDjhXBjWHaASaWqAginKFemMEiGONF45VgWmDCYE0 X-IronPort-AV: E=Sophos;i="4.75,467,1330905600"; d="scan'208";a="39225535" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 23 Apr 2012 17:29:02 +0000 Received: from sjc-vpn7-1727.cisco.com (sjc-vpn7-1727.cisco.com [10.21.150.191]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3NHSXV3018821; Mon, 23 Apr 2012 17:29:02 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: <4F7C7177.6030807@irisa.fr> Date: Mon, 23 Apr 2012 07:31:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: 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: Mon, 23 Apr 2012 17:29:07 -0000 On Apr 4, 2012, at 9:06 , Anthony Baire wrote: > we noticed one client implementation using a different UDP source port = for each request=20 just as a bit of information about this - long in the past, we saw SIP = implementations that used new source ports frequently. Much of the time = this works fine but unfortunately, these experienced lots of problems in = some deployment scenarios and would not recommend writing your client = this way.=20 The issue is the that each new UDP flow is setting up new state in NATs, = Firewalls, and various security systems and this often takes time. We = found the first request on a new UDP flow was much more likely to be = lost and typically took longer than other UDP packets later in the same = flow. In the case of carrier grade NATs, the number of UDP flows a given = endpoint can have is often limited and given the UDP flows can only be = "de-allocated" based on a timer (as the UDP flow has no FIN or RST), a = client doing this may run out of flows it can use.=20 From fluffy@iii.ca Mon Apr 23 10:29: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 20DEA21F8792 for ; Mon, 23 Apr 2012 10:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.954 X-Spam-Level: X-Spam-Status: No, score=-2.954 tagged_above=-999 required=5 tests=[AWL=0.601, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 zOR1RS1b+tEU for ; Mon, 23 Apr 2012 10:29:07 -0700 (PDT) Received: from fallback-in2.mxes.net (fallback-out2.mxes.net [216.86.168.191]) by ietfa.amsl.com (Postfix) with ESMTP id 717AB21F8795 for ; Mon, 23 Apr 2012 10:29:07 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by fallback-in1.mxes.net (Postfix) with ESMTP id 7FCEB2FDC67 for ; Mon, 23 Apr 2012 13:29:06 -0400 (EDT) Received: from sjc-vpn7-1727.cisco.com (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 F2A2522E253; Mon, 23 Apr 2012 13:29:01 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Cullen Jennings In-Reply-To: Date: Mon, 23 Apr 2012 07:08:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <448F1DD2-1380-4D09-8EBC-B86FD8BBEF61@iii.ca> References: <6029ED8C-2341-4199-A439-F0DB02A55DA4@koanlogic.com> <621B125F-FC64-4B07-BB82-D2477E5F47FB@sensinode.com> To: Carsten Bormann X-Mailer: Apple Mail (2.1257) Cc: Klaus Hartke , core@ietf.org 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, 23 Apr 2012 17:29:08 -0000 up leveling a bit =85 why do we think we need virtual hosts? On Apr 21, 2012, at 8:14 , Carsten Bormann wrote: > On Apr 21, 2012, at 14:54, Zach Shelby wrote: >=20 >> Right, so you would prefer to represent virtual host names in some = other way. What about something like this? >>=20 >> ;vh=3D"host1", >> ;vh=3D"host2" >=20 > Well, I'd prefer not to *have* virtual host names :-) >=20 > Once we want to have a single endpoint represent multiple endpoint = identities, we run into this problem. It's exacerbated by reverse = proxies that need to carry around these identities together with the = real endpoint (address/port) information. >=20 > I understand why all this was necessary in an IPv4 HTTP world, but I'm = not so sure for CoAP. >=20 > Gr=FC=DFe, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From fluffy@iii.ca Mon Apr 23 10:37: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 348D321F8709 for ; Mon, 23 Apr 2012 10:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.995 X-Spam-Level: X-Spam-Status: No, score=-2.995 tagged_above=-999 required=5 tests=[AWL=0.560, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 5juKRiq4XD5P for ; Mon, 23 Apr 2012 10:37:05 -0700 (PDT) Received: from fallback-in2.mxes.net (fallback-out2.mxes.net [216.86.168.191]) by ietfa.amsl.com (Postfix) with ESMTP id C255C21F871C for ; Mon, 23 Apr 2012 10:37:05 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by fallback-in1.mxes.net (Postfix) with ESMTP id 5041F2FDC5F for ; Mon, 23 Apr 2012 13:29:01 -0400 (EDT) Received: from sjc-vpn7-1727.cisco.com (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 124A322E261; Mon, 23 Apr 2012 13:29:00 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: <3A4E7A39-C78D-45A9-97ED-9D48B4107DED@tzi.org> Date: Mon, 23 Apr 2012 06:59:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <46159D39-58EC-45CE-BEFA-091F4F85366E@iii.ca> 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> <4F8D1EA8.6080800@ericsson.com> <68B487AC-7384-4B75-9E1F-32CB8454D2F0@koanlogic.com> <4F92196E.9000701@cs.tcd.ie> <9158B27B-8C40-43A7-B957-961A9E29448B@koanlogic.com> <4F92DCFF.4090301@cs.tcd.ie> <7C11BCD4-3A3A-41AE-B4BC-E374BE737B47@koanlogic.com> <4F1131E2-6997-4F2B-A51A-DD2A8607F9E0@tzi.org> <4F92EEE2.6080801@cs.tcd.ie> <94216E93-4059-4EA2-B4AE-88BF67E74369@koanlogic.com> <49276523-70CC-40F2-9D34 -FF8F3348BA0C@tzi.org> <3A4E7A39-C78D-45A9-97ED-9D48B4107DED@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1257) Cc: core WG Subject: Re: [core] Specifying security parameters 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, 23 Apr 2012 17:37:06 -0000 On Apr 21, 2012, at 14:38 , Carsten Bormann wrote: > And it's none of the business of the CoRE working group to invent all = this mechanism. It is 100% the job of CoAP to define how to secure CoAP.=20 From kovatsch@inf.ethz.ch Mon Apr 23 10:49: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 39A1C21F8772 for ; Mon, 23 Apr 2012 10:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.799 X-Spam-Level: X-Spam-Status: No, score=-7.799 tagged_above=-999 required=5 tests=[AWL=-1.200, 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 KCjCpxOWC0Kx for ; Mon, 23 Apr 2012 10:49:32 -0700 (PDT) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) by ietfa.amsl.com (Postfix) with ESMTP id 75DD121F875A for ; Mon, 23 Apr 2012 10:49:32 -0700 (PDT) Received: from CAS20.d.ethz.ch (172.31.51.110) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.2.283.3; Mon, 23 Apr 2012 19:49:30 +0200 Received: from MBX10.d.ethz.ch ([169.254.1.51]) by CAS20.d.ethz.ch ([fe80::2cd8:4907:7776:c56d%10]) with mapi id 14.01.0355.002; Mon, 23 Apr 2012 19:49:31 +0200 From: "Kovatsch Matthias" To: Cullen Jennings Thread-Topic: [core] #202: Remove the 270 byte artificial limit Thread-Index: AQHNHXfKOwTEAqxLy0KL8FjKmBADiZagnb4AgAAXSwCAAD0xAIADFsCAgAGBCyCAArmZAIAAbuBw Date: Mon, 23 Apr 2012 17:49:28 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B513992640@MBX10.d.ethz.ch> References: <051.e7fbc0f0f5736d305a309a9e8d0cd924@trac.tools.ietf.org> <61887542-A2C0-4DF2-B784-34ABE12E38EF@iii.ca> <5BEC4E4C-FF04-44DC-A14B-2FA73E3D573F@tzi.org> <2A346094-E537-4536-AE35-7C88D70AC55C@iii.ca> <55877B3AFB359744BA0F2140E36F52B51398E11D@MBX10.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B513990663@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: core WG 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: Mon, 23 Apr 2012 17:49:33 -0000 > > I think it would generally be best, if such profiles would specify limi= tations > and the protocol itself can be kept flexible, without artificial limitati= ons. >=20 > So let me get this right, your think SEP 2.0 should define a limit but IE= TF > should not? What happens when I want to buy a COAP stack and use it for > both a SEP and IPSO profile? I would not buy it in the first place when the limit is hardcoded... As I said, I think the limit is purely application-specific and probably te= chnically caused by the hardware you use. But if you want to support 1k URI= s, you have to pick the right platform. The overall stack has so many parameters and choices that have to be harmon= ized and this is done by profiles. AFAIK, HTTP also has no limitation (only some too long error codes). So, I still not see why we need that limitation. From tho@koanlogic.com Mon Apr 23 11:27: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 B2CC221F84D2 for ; Mon, 23 Apr 2012 11:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, 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 PU+hK6d41YuI for ; Mon, 23 Apr 2012 11:27:33 -0700 (PDT) Received: from gonzo.koanlogic.com (koanlogic.com [64.251.31.111]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA4121F84FB for ; Mon, 23 Apr 2012 11:27:32 -0700 (PDT) Received: from chello062178222142.13.15.univie.teleweb.at ([62.178.222.142]:53629 helo=[192.168.0.14]) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1SMNys-0007ai-KQ for core@ietf.org; Mon, 23 Apr 2012 14:27:30 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Thomas Fossati In-Reply-To: <7C60E917-1E01-40B5-9785-13A11DF87E53@tzi.org> Date: Mon, 23 Apr 2012 20:27:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: 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> <4F8D1EA8.6080800@ericsson.com> <68B487AC-7384-4B75-9E1F-32CB8454D2F0@koanlogic.com> <4F92196E.9000701@cs.tcd.ie> <9158B27B-8C40-43A7-B957-961A9E29448B@koanlogic.com> <4F92DCFF.4090301@cs.tcd.ie> <7C11BCD4-3A3A-41AE-B4BC-E374BE737B47@koanlogic.com> <4F1131E2-6997-4F2B-A51A-DD2A8607F9E0@tzi.org> <4F92EEE2.6080801@cs.tcd.ie> <94216E93-4059-4EA2-B4AE-88BF67E74369@koanlogic.com> <49276523-70CC-40F2-9D34 -FF8F3348BA0C@tzi.org> <3A4E7A39-C78D-45A9-97ED-9D48B4107DED@tzi.org> <8731C205-19B1-43A0-B522-CE167C7BD80B@koanlogic.com> <0645900D-3DA0-4324-BE2C-61814F51CC3F@tzi.org> <7C60E917-1E01-40B5-9785-13A11DF87E53@tzi.org> To: core WG 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] Proxy-URI and coaps scheme 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, 23 Apr 2012 18:27:33 -0000 Just to recap the base question I've posed, that may have been diluted a = bit in the ping-pong with Carsten :-) Proxy-URI and coaps scheme, currently an obscure corner of the spec. = How shall we treat the combo ? 1) Deprecate because we don't know how to make it work; 2) leave as an implementation/deployment "detail"; 3) define a pass-through facility (ie. CONNECT-like method) to allow E2E = DTLS; 4) define a comprehensive solution for both trusted and untrusted = intermediary scenarios; 5) other?= From zach@sensinode.com Mon Apr 23 11:52: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 67F9F21F8638 for ; Mon, 23 Apr 2012 11:52:10 -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 4DEMNcEHSa67 for ; Mon, 23 Apr 2012 11:52:09 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD6121F8633 for ; Mon, 23 Apr 2012 11:52:09 -0700 (PDT) Received: from [172.20.10.4] (84-231-127-42.elisa-mobile.fi [84.231.127.42]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q3NIq6wH014927; Mon, 23 Apr 2012 21:52:06 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <2DC1D69D-9D89-409F-A8B2-94729A3787ED@iii.ca> Date: Mon, 23 Apr 2012 21:51:56 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6552ED5D-DB09-4F91-A869-73F90233E55F@sensinode.com> References: <001b01cced71$c60c8b60$5225a220$@uni-rostock.de> <07CC0900-8116-4242-AB96-D74879E247D8@tzi.org> <001e01cced78$e09dd400$a1d97c00$@uni-rostock.de> <73456E11-9651-4FB8-82E3-1CBC490C55DF@tzi.org> <4F3E758B.8020007@stpeter.im> <000f01ccedb0$cd0fe620$672fb260$@uni-rostock.de> <5961B851-CBE9-445D-945A-2FC800A9667E@iii.ca> <91B1300E-F3A2-4672-8715-A0C006990DEB@sensinode.com> <175E4D4E-31AE-44CF-8CFF-DC6A26A64F74@tzi.org> <2DC1D69D-9D89-409F-A8B2-94729A3787ED@iii.ca> To: Cullen Jennings X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org Subject: Re: [core] EXI content type and encoding (was: Resolution to tickets #176, #177, #181) 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, 23 Apr 2012 18:52:10 -0000 On Apr 23, 2012, at 3:56 PM, Cullen Jennings wrote: >> By the way, continuing to call option 1 Content-Type may now be = slightly confusing to HTTP mapper implementers. (Changing it to = something akin to "Content-Type-And-Encoding-Id" is ugly and will = confuse the CoAP implementers. I'm not sure who I want to confuse more. = Maybe sticking with the wrong name is better.) >=20 > Given that there will be many more implementation is the future than = there has been so far, I think we should error not the side of con suing = the current developers. I don't think they will be very confused by this = so I'd rather see us change things to the best name possible.=20 Content-And-Encoding-Id? --=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 zach@sensinode.com Mon Apr 23 11:59:05 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 A944E21F863B for ; Mon, 23 Apr 2012 11:59:05 -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 U+vDlh9D8EcN for ; Mon, 23 Apr 2012 11:59:05 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id AE53121F8636 for ; Mon, 23 Apr 2012 11:59:04 -0700 (PDT) Received: from [172.20.10.4] (84-231-127-42.elisa-mobile.fi [84.231.127.42]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q3NIx0eX015476; Mon, 23 Apr 2012 21:59:02 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Zach Shelby In-Reply-To: <448F1DD2-1380-4D09-8EBC-B86FD8BBEF61@iii.ca> Date: Mon, 23 Apr 2012 21:58:57 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <10A3926F-740D-4D23-844E-EEE37ECB6EA0@sensinode.com> References: <6029ED8C-2341-4199-A439-F0DB02A55DA4@koanlogic.com> <621B125F-FC64-4B07-BB82-D2477E5F47FB@sensinode.com> <448F1DD2-1380-4D09-8EBC-B86FD8BBEF61@iii.ca> To: Cullen Jennings X-Mailer: Apple Mail (2.1084) Cc: Klaus Hartke , core@ietf.org 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, 23 Apr 2012 18:59:05 -0000 On Apr 23, 2012, at 5:08 PM, Cullen Jennings wrote: > up leveling a bit =85 why do we think we need virtual hosts? Well, we have the ability to identify a virtual host using the Uri-Host = option in a request. Thomas has a need for using CoAP virtual hosts, = which is why this came up. We actually make use of virtual CoAP hosts in = our backend servers as well, but we don't have a need to discover them = using link-format. Thomas thinks it would be good to have a way to = discover the available virtual host names using link-format. Now, Klaus and Carsten have pointed out that trying to indicate virtual = hosts (and then identify the resource in a cache) using the link-format = is problematic. So probably we will end up only being able to indicate = port numbers of other available servers on a host in the link-format. = You can of course use DNS if you really want to use virtual hosts.=20 Zach >=20 >=20 > On Apr 21, 2012, at 8:14 , Carsten Bormann wrote: >=20 >> On Apr 21, 2012, at 14:54, Zach Shelby wrote: >>=20 >>> Right, so you would prefer to represent virtual host names in some = other way. What about something like this? >>>=20 >>> ;vh=3D"host1", >>> ;vh=3D"host2" >>=20 >> Well, I'd prefer not to *have* virtual host names :-) >>=20 >> Once we want to have a single endpoint represent multiple endpoint = identities, we run into this problem. It's exacerbated by reverse = proxies that need to carry around these identities together with the = real endpoint (address/port) information. >>=20 >> I understand why all this was necessary in an IPv4 HTTP world, but = I'm not so sure for CoAP. >>=20 >> Gr=FC=DFe, Carsten >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 --=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 Mon Apr 23 12:07: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 BF60121E802B for ; Mon, 23 Apr 2012 12:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 5xoFfWPPyyBp for ; Mon, 23 Apr 2012 12:07:35 -0700 (PDT) Received: from gonzo.koanlogic.com (koanlogic.com [64.251.31.111]) by ietfa.amsl.com (Postfix) with ESMTP id B668521E8025 for ; Mon, 23 Apr 2012 12:07:34 -0700 (PDT) Received: from chello062178222142.13.15.univie.teleweb.at ([62.178.222.142]:53973 helo=[192.168.0.14]) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1SMObZ-0007gf-Ph; Mon, 23 Apr 2012 15:07:30 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: <7C60E917-1E01-40B5-9785-13A11DF87E53@tzi.org> Date: Mon, 23 Apr 2012 21:07:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3BD7437B-00DB-4AD4-921D-8D3B9D8B6F8A@koanlogic.com> 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> <4F8D1EA8.6080800@ericsson.com> <68B487AC-7384-4B75-9E1F-32CB8454D2F0@koanlogic.com> <4F92196E.9000701@cs.tcd.ie> <9158B27B-8C40-43A7-B957-961A9E29448B@koanlogic.com> <4F92DCFF.4090301@cs.tcd.ie> <7C11BCD4-3A3A-41AE-B4BC-E374BE737B47@koanlogic.com> <4F1131E2-6997-4F2B-A51A-DD2A8607F9E0@tzi.org> <4F92EEE2.6080801@cs.tcd.ie> <94216E93-4059-4EA2-B4AE-88BF67E74369@koanlogic.com> <49276523-70CC-40F2-9D34 -FF8F3348BA0C@tzi.org> <3A4E7A39-C78D-45A9-97ED-9D48B4107DED@tzi.org> <8731C205-19B1-43A0-B522-CE167C7BD80B@koanlogic.com> <0645900D-3DA0-4324-BE2C-61814F51CC3F@tzi.org> <7C60E917-1E01-40B5-9785-13A11DF87E53@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 Subject: Re: [core] Specifying security parameters 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, 23 Apr 2012 19:07:35 -0000 On Apr 22, 2012, at 9:52 PM, Carsten Bormann wrote: > 1) the intermediary is the client's big brother. The client doesn't = really have the security smarts, so the client asks the big brother to = please handle all that stuff for me. That would be one of the trusted = intermediary cases. Right, let's put some taxonomy in place: this could be the "forward = trusted proxy". > 2) the intermediary is the server's big brother -- again, the server = leaves the handling of complicated things like certificates to its big = brother (which probably talks via PSK to it). While the client does not = really "trust" the intermediary, it will have to trust it as much as it = trusts the server. This one the "reverse trusted proxy". > In both cases, the intermediaries are pretty much autonomous to make = security-related decisions; there is very little point to try to get = something transitive going on. Well, it depends on how many proxies are in the chain from the client to = the server. Trust transitivity comes in its full splendor when nproxies = > 1, i.e. when there is an explicit leap of faith of the client WRT the = next, non directly visible, proxy in the chain. > 3) the intermediary embodies a domain boundary, but is not tightly = implicated in the security dealings of either the client or the server. = I can blindly trust it with my data, but I can't trust it to know (read: = I need to tell it) how to talk to that other guy. That requires a lot = more work, and maybe that is what you have in mind. > For now, I'd try to avoid that case. This would imply also some sort of discovery/publishing, which is a = (possibly overlooked) companion theme WRT the Proxy-URI handling. > If I just want to send packets, I don't need an intermediary. > So I don't care whether the proxy is a router or not: I'm not talking = to it in the first place. > I'm sending my packets right to where they have to go. Ok, so you are not talking about proxies here :-) > I was trying to point out that other spaces have similar problems = here. > But, sure, we don't have to solve their problems. > However, as soon as we want to interoperate with, say, HTTP, we do. Agreed, yet the HTTP-CoAP boundary is already a well defined interface, = which provides a natural demarcation point where to handle all the = needed translations -- even if these are more complex than a simple = non-lossy manipulation of the wire format. So to say that we may or may not be interested in keeping 1:1 semantic = compatibility with whatever comsec mechanism will be (or is) specified = in the future of the HTTP world since a CoAP-HTTP translator is already = expected to be a well placed, robust and intelligent beast. >> This train is headed straight to an in-CoAP security mechanism = (which, given the peculiar nature of CoAP deployments and target = hardware seems to me like the less painful approach.) >=20 > Again, how do we transport this over HTTP. If the answer is "run CoAP = over Websockets", that is easy. If we actually want to interoperate = with the HTTP world, we may need a grander vision. What are you thinking of specifically, OAuth 2 ? If so, that could be = ok for an unconstrained scenario (say, Repute over CoAP), but asking a = constrained endpoint to implement a full blown web protocol (as you = rightly say, "Grander") seems quite out of scope for their tiny brains. >> What I meant is: how do the client gets undeniable evidence that the = requested COMSEC services have been enforced on each step of the path to = the resource ? >=20 > It doesn't. Well, lack of verification implies full trust. And if this is to be = assumed anyway, I think it is not even interesting to supply parameters = from the client to the proxy through some possibly complex protocol = (which should e.g. take into consideration that other clients on the = same link are not as trustworthy as the proxy). Just let the big = brother do what it deems better for our good... >> Ie. how the requested security attributes are bound to the response = so that the client can verify their application ? >=20 > If the server were to certify "yes, this request came in over DTLS = with AES-128 based on a DHE handshake authenticated with ECC-mumble", = the client still wouldn't know anything about what else happened on the = way while the intermediary had unpacked the data. Maybe I don't get = what you want to be able to verify. I'd like to give the evidence to the client that the security services = expected from the proxy have been enforced E2E. Otherwise, if the proxy = can basically do whatever it likes, I don't see the point in supplying = the sec attributes in the first place. >> I feel like we are waiting for Godot (pick one of DTLS, IPsec, JOSE, = OAuth), while still missing the basic set of security services to = operate CoAP networks with a decent level of security. >=20 > We know how to do that, and we have zeroed in on the use of DTLS for = that. Ok, and in fact we've taken this advice so seriously that we are = actually trying to push DTLS on class 1 devices. But this seems to be a = much more difficult task than expected. The shortfall in pushing the MTI comsec primitives on (a certain class = of) end nodes must be acknowledged because it raises a very different = model for (constrained) CoAP networks, where a "plaintext" island needs = to establish trust relationships with another island through = computationally robust intermediaries that can handle the delegated = security -- i.e. where the proxy role gains more and more weight than = initially expected. DTLS is perfect if it can flow E2E, but if no end node is able to use it = (and they currently can't, both because it is difficult to push DTLS on = a class 1 node without leaving basically no space for the application, = and because - even if DTLS were cheaply available -- proxies are still = too thick to let the E2E flow pass through.= From cabo@tzi.org Mon Apr 23 12:16: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 D60D721F84FB for ; Mon, 23 Apr 2012 12:16:02 -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 RmnrrLyZWl9R for ; Mon, 23 Apr 2012 12:16: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 1ADA821F84D3 for ; Mon, 23 Apr 2012 12:16: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 q3NJFr46018158; Mon, 23 Apr 2012 21:15:53 +0200 (CEST) Received: from [192.168.217.105] (p5B3E6405.dip.t-dialin.net [91.62.100.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A1EABAE8; Mon, 23 Apr 2012 21:15:53 +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, 23 Apr 2012 21:15:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <05A2FA1E-CD1B-479E-90D6-527104CE49CE@tzi.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> <4F8D1EA8.6080800@ericsson.com> <68B487AC-7384-4B75-9E1F-32CB8454D2F0@koanlogic.com> <4F92196E.9000701@cs.tcd.ie> <9158B27B-8C40-43A7-B957-961A9E29448B@koanlogic.com> <4F92DCFF.4090301@cs.tcd.ie> <7C11BCD4-3A3A-41AE-B4BC-E374BE737B47@koanlogic.com> <4F1131E2-6997-4F2B-A51A-DD2A8607F9E0@tzi.org> <4F92EEE2.6080801@cs.tcd.ie> <94216E93-4059-4EA2-B4AE-88BF67E74369@koanlogic.com> <49276523-70CC-40F2-9D34 -FF8F3348BA0C@tzi.org> <3A4E7A39-C78D-45A9-97ED-9D48B4107DED@tzi.org> <8731C205-19B1-43A0-B522-CE167C7BD80B@koanlogic.com> <0645900D-3DA0-4324-BE2C-61814F51CC3F@tzi.org> <7C60E917-1E01-40B5-9785-13A11DF87E53@tzi.org> To: Thomas Fossati X-Mailer: Apple Mail (2.1257) Cc: core WG Subject: Re: [core] Proxy-URI and coaps scheme 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, 23 Apr 2012 19:16:03 -0000 On Apr 23, 2012, at 20:27, Thomas Fossati wrote: > Just to recap the base question I've posed, that may have been diluted = a bit in the ping-pong with Carsten :-) >=20 > Proxy-URI and coaps scheme, currently an obscure corner of the spec. = How shall we treat the combo ? >=20 > 1) Deprecate because we don't know how to make it work; Wo know how to make it work, if: 1) the intermediary is trusted with the confidentiality and integrity of = the data 2) the intermediary has enough context to translate the coaps:// into = the security parameters needed. The problem is that coaps://, like https://, relies on a lot of context. For HTTP, this context was pretty much fixed for a decade (use TLS 1.0 = without client authentication, authenticate the server's DNS name and = verify its cert based on the 200 "known-good" root CAs etc.), so people = often did not notice the problems until they started to use more complex = setups such as OpenID. > 2) leave as an implementation/deployment "detail"; That's what we have with https:// (and what won't work too well with = coaps://). > 3) define a pass-through facility (ie. CONNECT-like method) to allow = E2E DTLS; Not needed in the use-cases I know -- just use end-to-end DTLS. What would be your use-case where you can't do that? Why is it the job of the CoAP intermediary to forward your packets? > 4) define a comprehensive solution for both trusted and untrusted = intermediary scenarios; Does that exist? > 5) other? Be my guest. Gr=FC=DFe, Carsten From cabo@tzi.org Mon Apr 23 12:35: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 CCA7B21E8025 for ; Mon, 23 Apr 2012 12:35:11 -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 ksk4MWXsBtxw for ; Mon, 23 Apr 2012 12:35: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 E27D021E8019 for ; Mon, 23 Apr 2012 12:35: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 q3NJZ1Cl025020; Mon, 23 Apr 2012 21:35:01 +0200 (CEST) Received: from [192.168.217.105] (p5B3E6405.dip.t-dialin.net [91.62.100.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 24BB1AEE; Mon, 23 Apr 2012 21:35:01 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <3BD7437B-00DB-4AD4-921D-8D3B9D8B6F8A@koanlogic.com> Date: Mon, 23 Apr 2012 21:35:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2F98C031-3111-4CA7-A59B-B1AC4356B1D2@tzi.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> <4F8D1EA8.6080800@ericsson.com> <68B487AC-7384-4B75-9E1F-32CB8454D2F0@koanlogic.com> <4F92196E.9000701@cs.tcd.ie> <9158B27B-8C40-43A7-B957-961A9E29448B@koanlogic.com> <4F92DCFF.4090301@cs.tcd.ie> <7C11BCD4-3A3A-41AE-B4BC-E374BE737B47@koanlogic.com> <4F1131E2-6997-4F2B-A51A-DD2A8607F9E0@tzi.org> <4F92EEE2.6080801@cs.tcd.ie> <94216E93-4059-4EA2-B4AE-88BF67E74369@koanlogic.com> <49276523-70CC-40F2-9D34 -FF8F3348BA0C@tzi.org> <3A4E7A39-C78D-45A9-97ED-9D48B4107DED@tzi.org> <8731C205-19B1-43A0-B522-CE167C7BD80B@koanlogic.com> <0645900D-3DA0-4324-BE2C-61814F51CC3F@tzi.org> <7C60E917-1E01-40B5-9785-13A11DF87E53@tzi.org> <3BD7437B-00DB-4AD4-921D-8D3B9D8B6F8A@koanlogic.com> To: Thomas Fossati X-Mailer: Apple Mail (2.1257) Cc: core WG Subject: Re: [core] Specifying security parameters 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, 23 Apr 2012 19:35:11 -0000 Thomas, good thoughts, thank you. >> Again, how do we transport this over HTTP. If the answer is "run = CoAP over Websockets", that is easy. If we actually want to = interoperate with the HTTP world, we may need a grander vision. >=20 > What are you thinking of specifically, OAuth 2 ? If so, that could be = ok for an unconstrained scenario (say, Repute over CoAP), but asking a = constrained endpoint to implement a full blown web protocol (as you = rightly say, "Grander") seems quite out of scope for their tiny brains. I haven't looked at the complexity of doing a protocol that could = interwork with OAuth. Yes, OAuth itself may be something that must be left to the big brother = intermediaries. >> If the server were to certify "yes, this request came in over DTLS = with AES-128 based on a DHE handshake authenticated with ECC-mumble", = the client still wouldn't know anything about what else happened on the = way while the intermediary had unpacked the data. Maybe I don't get = what you want to be able to verify. >=20 > I'd like to give the evidence to the client that the security services = expected from the proxy have been enforced E2E. Otherwise, if the proxy = can basically do whatever it likes, I don't see the point in supplying = the sec attributes in the first place. Do you have a mechanism in mind to do that? >>> I feel like we are waiting for Godot (pick one of DTLS, IPsec, JOSE, = OAuth), while still missing the basic set of security services to = operate CoAP networks with a decent level of security. >>=20 >> We know how to do that, and we have zeroed in on the use of DTLS for = that. >=20 > Ok, and in fact we've taken this advice so seriously that we are = actually trying to push DTLS on class 1 devices. But this seems to be a = much more difficult task than expected. Well, there are implementations now that are tailored to class-1 = environments (e.g., tinydtls). It is probably going to be the most complex software component on the = device, but we never expected otherwise for end-to-end security. > The shortfall in pushing the MTI comsec primitives on (a certain class = of) end nodes must be acknowledged because it raises a very different = model for (constrained) CoAP networks, where a "plaintext" island needs = to establish trust relationships with another island through = computationally robust intermediaries that can handle the delegated = security -- i.e. where the proxy role gains more and more weight than = initially expected. That is another, quite valid way to do a deployment. It should not be the only one. > DTLS is perfect if it can flow E2E, but if no end node is able to use = it (and they currently can't, both because it is difficult to push DTLS = on a class 1 node without leaving basically no space for the = application, Olaf's number in Paris was < 13KiB with PSK and hardware AES (I think he = has optimized it even a bit further since). That is not a beautiful = number, but within the capabilities of at least some class-1 devices. > and because - even if DTLS were cheaply available -- proxies are still = too thick to let the E2E flow pass through. Again, if their job is to just pass through DTLS, they are IP routers, = not CoAP intermediaries. Gr=FC=DFe, Carsten From stephen.farrell@cs.tcd.ie Mon Apr 23 15:46:20 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 694EE11E8075 for ; Mon, 23 Apr 2012 15:46:20 -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 mfyKPiKnjR+3 for ; Mon, 23 Apr 2012 15:46:15 -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 4C00121F856C for ; Mon, 23 Apr 2012 15:46:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 0BE191714DA; Mon, 23 Apr 2012 23:46:13 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1335221172; bh=HSrQdY5F4XLPLL DQ3aTZWJlRXw18s/vqqeyc9akQzyY=; b=JIkVcLvKrgPDEh+lrjglkM2MJIMKku 6SJiXbvzKdbvqNVuI+AR5cy/7LhY5Cvnvc+M+Mq9GOUCiCoB3aLdd2fL9KxzZCOr ediQ4S9J8oZfkfhrp42mRGY3tnXaGYSs5l/Mp2L+SrLi8EOl7X4tIyTZQkZqq0sD 4kdKn9sd5GtyebYJkgRalIhVBWeqgNSdf+JjPRc+BV56e6GrBmHz6F+RAS2glR/9 o/jHpZrhcPHSbxFylvG+u7+mqmn5Qd1epvfx20XdobxW/y99nBvkWpFK9c5LY4rv jtp3GW8+BaSJd14Rm0PY7IPVhc0Me2of4GVShJL8fKANM1gp1lhh7lrw== 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 JS8g+oF8kZRz; Mon, 23 Apr 2012 23:46:12 +0100 (IST) Received: from [10.87.48.9] (unknown [86.46.27.213]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 4B1461714D9; Mon, 23 Apr 2012 23:46:11 +0100 (IST) Message-ID: <4F95DBB2.5010005@cs.tcd.ie> Date: Mon, 23 Apr 2012 23:46:10 +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: Carsten Bormann References: <4F8C1A5C.10309@ericsson.com> <4F8D1EA8.6080800@ericsson.com> <68B487AC-7384-4B75-9E1F-32CB8454D2F0@koanlogic.com> <4F92196E.9000701@cs.tcd.ie> <9158B27B-8C40-43A7-B957-961A9E29448B@koanlogic.com> <4F92DCFF.4090301@cs.tcd.ie> <7C11BCD4-3A3A-41AE-B4BC-E374BE737B47@koanlogic.com> <4F1131E2-6997-4F2B-A51A-DD2A8607F9E0@tzi.org> <4F92EEE2.6080801@cs.tcd.ie> <94216E93-4059-4EA2-B4AE-88BF67E74369@koanlogic.com> <49276523-70CC-40F2-9D34 -FF8F3348BA0C@tzi.org> <3A4E7A39-C78D-45A9-97ED-9D48B4107DED@tzi.org> <8731C205-19B1-43A0-B522-CE167C7BD80B@koanlogic.com> <0645900D-3DA0-4324-BE2C-61814F51CC3F@tzi.org> <7C60E917-1E01-40B5-9785-13A11DF87E53@tzi.org> <3BD7437B-00DB-4AD4-921D-8D3B9D8B6F8A@koanlogic.com> <2F98C031-3111-4CA7-A59B-B1AC4356B1D2@tzi.org> In-Reply-To: <2F98C031-3111-4CA7-A59B-B1AC4356B1D2@tzi.org> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: core WG Subject: Re: [core] Specifying security parameters 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, 23 Apr 2012 22:46:20 -0000 Hi Carsten, On 04/23/2012 08:35 PM, Carsten Bormann wrote: > Again, if their job is to just pass through DTLS, they are IP routers, not CoAP intermediaries. Is there text somewhere saying something like: "don't setup a gateway device that's a CoAP proxy but turns off IP routing since that'd prevent devices "behind" that proxy using e2e DTLS"? I'm sure that'd need a good bit of wordsmithing and I'm not at all sure where it'd go (being more of a deployment consideration). I do have to wonder though if that approach will work out. Won't people be just too likely to turn off IP routing on many gateway devices so they get that happy firewalled feeling? (I'm not saying they're right, I'm worried it'll happen regardless.) If so, that'd mean lots of cases where e2e DTLS would fail in practice, which seems like a bad outcome. (Related question: is there any CoAP-level routing happening in proxies that'd mean that the e2e DTLS packets really do need to go to the CoAP process on the middlebox?) S From tho@koanlogic.com Mon Apr 23 23:48: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 BF8BC21E800F for ; Mon, 23 Apr 2012 23:48:00 -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 9BjMMVhClAnq for ; Mon, 23 Apr 2012 23:47:59 -0700 (PDT) Received: from gonzo.koanlogic.com (koanlogic.com [64.251.31.111]) by ietfa.amsl.com (Postfix) with ESMTP id BFF1711E80AB for ; Mon, 23 Apr 2012 23:47:59 -0700 (PDT) Received: from chello084112045229.2.11.vie.surfer.at ([84.112.45.229]:56208 helo=[172.16.101.93]) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1SMZXL-0000VI-4q; Tue, 24 Apr 2012 02:47:54 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: <2F98C031-3111-4CA7-A59B-B1AC4356B1D2@tzi.org> Date: Tue, 24 Apr 2012 08:47:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: 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> <4F8D1EA8.6080800@ericsson.com> <68B487AC-7384-4B75-9E1F-32CB8454D2F0@koanlogic.com> <4F92196E.9000701@cs.tcd.ie> <9158B27B-8C40-43A7-B957-961A9E29448B@koanlogic.com> <4F92DCFF.4090301@cs.tcd.ie> <7C11BCD4-3A3A-41AE-B4BC-E374BE737B47@koanlogic.com> <4F1131E2-6997-4F2B-A51A-DD2A8607F9E0@tzi.org> <4F92EEE2.6080801@cs.tcd.ie> <94216E93-4059-4EA2-B4AE-88BF67E74369@koanlogic.com> <49276523-70CC-40F2-9D34 -FF8F3348BA0C@tzi.org> <3A4E7A39-C78D-45A9-97ED-9D48B4107DED@tzi.org> <8731C205-19B1-43A0-B522-CE167C7BD80B@koanlogic.com> <0645900D-3DA0-4324-BE2C-61814F51CC3F@tzi.org> <7C60E917-1E01-40B5-9785-13A11DF87E53@tzi.org> <3BD7437B-00DB-4AD4-921D-8D3B9D8B6F8A@koanlogic.com> <2F98C031-3111-4CA7-A59B-B1AC4356B1D2@tzi.org> 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] Specifying security parameters 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, 24 Apr 2012 06:48:00 -0000 On Apr 23, 2012, at 9:35 PM, Carsten Bormann wrote: >> I'd like to give the evidence to the client that the security = services expected from the proxy have been enforced E2E. Otherwise, if = the proxy can basically do whatever it likes, I don't see the point in = supplying the sec attributes in the first place. >=20 > Do you have a mechanism in mind to do that? No I've not really thought about it. My guess is that we'd need a new = option with something like: (a) code representing the requested E2E security services (b) a random transaction id that is acknowledged (HMAC'd or PK signed) by the receiving party using = an E2E credential (usual PSK or public key should work). >> DTLS is perfect if it can flow E2E, but if no end node is able to use = it (and they currently can't, both because it is difficult to push DTLS = on a class 1 node without leaving basically no space for the = application, >=20 > Olaf's number in Paris was < 13KiB with PSK and hardware AES (I think = he has optimized it even a bit further since). That is not a beautiful = number, but within the capabilities of at least some class-1 devices. 13K (+ 1K-2K if AES is done in software) is an interesting number indeed = (last time I've tried TinyDTLS the example client was ~70KB, I'll give = it another look, definitely!). Yet we may still face the need to answer the hard question: who am I = throwing out of the window, RPL or DTLS ? And no, as you know very well, go and buy some other RAM/ROM is not an = option :-)= From tho@koanlogic.com Tue Apr 24 00:08: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 BB73311E808D for ; Tue, 24 Apr 2012 00:08:24 -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 u4ADi0Q4iK31 for ; Tue, 24 Apr 2012 00:08:24 -0700 (PDT) Received: from gonzo.koanlogic.com (koanlogic.com [64.251.31.111]) by ietfa.amsl.com (Postfix) with ESMTP id 31A0721F8554 for ; Tue, 24 Apr 2012 00:08:24 -0700 (PDT) Received: from chello084112045229.2.11.vie.surfer.at ([84.112.45.229]:56510 helo=[172.16.101.93]) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1SMZrC-0000YX-8G; Tue, 24 Apr 2012 03:08:21 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: <6552ED5D-DB09-4F91-A869-73F90233E55F@sensinode.com> Date: Tue, 24 Apr 2012 09:08:12 +0200 Content-Transfer-Encoding: 7bit Message-Id: <3DCEBC7F-AEF7-43B0-8960-FD53F77175E8@koanlogic.com> References: <001b01cced71$c60c8b60$5225a220$@uni-rostock.de> <07CC0900-8116-4242-AB96-D74879E247D8@tzi.org> <001e01cced78$e09dd400$a1d97c00$@uni-rostock.de> <73456E11-9651-4FB8-82E3-1CBC490C55DF@tzi.org> <4F3E758B.8020007@stpeter.im> <000f01ccedb0$cd0fe620$672fb260$@uni-rostock.de> <5961B851-CBE9-445D-945A-2FC800A9667E@iii.ca> <91B1300E-F3A2-4672-8715-A0C006990DEB@sensinode.com> <175E4D4E-31AE-44CF-8CFF-DC6A26A64F74@tzi.org> <2DC1D69D-9D89-409F-A8B2-94729A3787ED@iii.ca> <6552ED5D-DB09-4F91-A869-73F90233E55F@sensinode.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@ietf.org Subject: Re: [core] EXI content type and encoding (was: Resolution to tickets #176, #177, #181) 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, 24 Apr 2012 07:08:24 -0000 On Apr 23, 2012, at 8:51 PM, Zach Shelby wrote: > Content-And-Encoding-Id? Media-Encoding ? From zach@sensinode.com Tue Apr 24 00:42: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 9AB7C21F85D2 for ; Tue, 24 Apr 2012 00:42:50 -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 FMkdoD9GFmHr for ; Tue, 24 Apr 2012 00:42:49 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF3421F853B for ; Tue, 24 Apr 2012 00:42:47 -0700 (PDT) Received: from [172.20.10.4] (84-231-127-42.elisa-mobile.fi [84.231.127.42]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q3O7gc0J027327; Tue, 24 Apr 2012 10:42:42 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <3DCEBC7F-AEF7-43B0-8960-FD53F77175E8@koanlogic.com> Date: Tue, 24 Apr 2012 10:42:37 +0300 Content-Transfer-Encoding: 7bit Message-Id: <3085D9B3-0722-4280-9FD4-CD7E9091FEED@sensinode.com> References: <001b01cced71$c60c8b60$5225a220$@uni-rostock.de> <07CC0900-8116-4242-AB96-D74879E247D8@tzi.org> <001e01cced78$e09dd400$a1d97c00$@uni-rostock.de> <73456E11-9651-4FB8-82E3-1CBC490C55DF@tzi.org> <4F3E758B.8020007@stpeter.im> <000f01ccedb0$cd0fe620$672fb260$@uni-rostock.de> <5961B851-CBE9-445D-945A-2FC800A9667E@iii.ca> <91B1300E-F3A2-4672-8715-A0C006990DEB@sensinode.com> <175E4D4E-31AE-44CF-8CFF-DC6A26A64F74@tzi.org> <2DC1D69D-9D89-409F-A8B2-94729A3787ED@iii.ca> <6552ED5D-DB09-4F91-A869-73F90233E55F@sensinode.com> <3DCEBC7F-AEF7-43B0-8960-FD53F77175E8@koanlogic.com> To: Thomas Fossati X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org Subject: Re: [core] EXI content type and encoding (was: Resolution to tickets #176, #177, #181) 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, 24 Apr 2012 07:42:52 -0000 On Apr 24, 2012, at 10:08 AM, Thomas Fossati wrote: > On Apr 23, 2012, at 8:51 PM, Zach Shelby wrote: >> Content-And-Encoding-Id? > > Media-Encoding ? Yes, I like that better. Zach -- 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 cabo@tzi.org Tue Apr 24 02:20: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 E5B1C21F853F for ; Tue, 24 Apr 2012 02:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.961 X-Spam-Level: X-Spam-Status: No, score=-105.961 tagged_above=-999 required=5 tests=[AWL=0.288, 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 si0YUGFKbwOe for ; Tue, 24 Apr 2012 02:20:44 -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 E584521F86F5 for ; Tue, 24 Apr 2012 02:20:43 -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 q3O9KTZ2003452; Tue, 24 Apr 2012 11:20:31 +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 DD1F1D3D; Tue, 24 Apr 2012 11:20:29 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <4F95DBB2.5010005@cs.tcd.ie> Date: Tue, 24 Apr 2012 11:20:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <05679D7C-DFAA-478A-8D74-8E630775C992@tzi.org> References: <4F8C1A5C.10309@ericsson.com> <4F8D1EA8.6080800@ericsson.com> <68B487AC-7384-4B75-9E1F-32CB8454D2F0@koanlogic.com> <4F92196E.9000701@cs.tcd.ie> <9158B27B-8C40-43A7-B957-961A9E29448B@koanlogic.com> <4F92DCFF.4090301@cs.tcd.ie> <7C11BCD4-3A3A-41AE-B4BC-E374BE737B47@koanlogic.com> <4F1131E2-6997-4F2B-A51A-DD2A8607F9E0@tzi.org> <4F92EEE2.6080801@cs.tcd.ie> <94216E93-4059-4EA2-B4AE-88BF67E74369@koanlogic.com> <49276523-70CC-40F2-9D34 -FF8F3348BA0C@tzi.org> <3A4E7A39-C78D-45A9-97ED-9D48B4107DED@tzi.org> <8731C205-19B1-43A0-B522-CE167C7BD80B@koanlogic.com> <0645900D-3DA0-4324-BE2C-61814F51CC3F@tzi.org> <7C60E917-1E01-40B5-9785-13A11DF87E53@tzi.org> <3BD7437B-00DB-4AD4-921D-8D3B9D8B6F8A@koanlogic.com> <2F98C031-3111-4CA7-A59B-B1AC4356B1D2@tzi.org> <4F95DBB2.5010005@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1257) Cc: core WG Subject: Re: [core] Specifying security parameters 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, 24 Apr 2012 09:20:45 -0000 On Apr 24, 2012, at 00:46, Stephen Farrell wrote: > On 04/23/2012 08:35 PM, Carsten Bormann wrote: >=20 >> Again, if their job is to just pass through DTLS, they are IP = routers, not CoAP intermediaries. >=20 > Is there text somewhere saying something like: "don't setup a > gateway device that's a CoAP proxy but turns off IP routing > since that'd prevent devices "behind" that proxy using e2e > DTLS"? That would be a charter item of the end-to-end protocol police, no? I don't think "saying" that will make any difference... > I'm sure that'd need a good bit of wordsmithing and I'm not > at all sure where it'd go (being more of a deployment > consideration). >=20 > I do have to wonder though if that approach will work out. > Won't people be just too likely to turn off IP routing on > many gateway devices so they get that happy firewalled > feeling? (I'm not saying they're right, I'm worried it'll > happen regardless.) As long as the above protocol police isn't invested with universal = powers, you are probably right. > If so, that'd mean lots of cases where e2e DTLS would fail > in practice, which seems like a bad outcome. Another potential outcome might be that people stop designing their = networks around mandatory application layer gateways where they really = need end-to-end security. But maybe I'm fantasizing... > (Related question: is there any CoAP-level routing happening > in proxies that'd mean that the e2e DTLS packets really do > need to go to the CoAP process on the middle box?) One could imagine a constrained client using the hostname lookup (e.g., = DNS) in an intermediary to talk to a server. A bit like a SOCKS5 for = CoAP and DTLS. I went ahead and put a strawman CONNECT in coap-misc: http://tools.ietf.org/html/draft-bormann-coap-misc-15#section-5 I feel a bit dirty, I'm going to take a shower now... I still hope that this lands in Appendix B of that document (the = cemetery), but at least we now have something specific to discuss. Gr=FC=DFe, Carsten From stephen.farrell@cs.tcd.ie Tue Apr 24 02:48: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 DC72121F876F for ; Tue, 24 Apr 2012 02:48:33 -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 wepnd4AtkCFT for ; Tue, 24 Apr 2012 02:48:32 -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 C501121F8716 for ; Tue, 24 Apr 2012 02:48:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id C06591714DC; Tue, 24 Apr 2012 10:48:30 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1335260910; bh=G18Yu5w3chYzFs yB2fkWNb9aFP3uNwnpIOAdHa4hRGE=; b=C6vN5nU61IL442eJQ/ZOXjFBS8cVQl pcWn9KE8KwNYbo6k324B/wtVk2V5zXIL4WNCgN4yumgeH0fjcC8jot2ZWcrd3n9Y SFQU66xvSyG2mmoSuYiAqVqwU6slv6ynzAcT81pVJglRZm7SajIa+MfPi9mpgQxD ZpHrwTi2YwxuyLsChmT9F+Je3af3zBAZRTbGkH1KFF1GnNVBuWQvaKy8aW0gBnAo edXkLiejB9zAwicxBKY+cQ4+3sdeKRUu+tf7IAld7YIeVwyb4VbuGw8lLe8KkWHv X9noBOJJgXZja563RvVNYCx29eUGDPAkdxw1t8F6PeLsScDxbEC2KG/Q== 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 yhbQlH-s3ZGt; Tue, 24 Apr 2012 10:48:30 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id F1D2D1714DB; Tue, 24 Apr 2012 10:48:29 +0100 (IST) Message-ID: <4F9676EA.9030201@cs.tcd.ie> Date: Tue, 24 Apr 2012 10:48:26 +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: Carsten Bormann References: <4F8C1A5C.10309@ericsson.com> <68B487AC-7384-4B75-9E1F-32CB8454D2F0@koanlogic.com> <4F92196E.9000701@cs.tcd.ie> <9158B27B-8C40-43A7-B957-961A9E29448B@koanlogic.com> <4F92DCFF.4090301@cs.tcd.ie> <7C11BCD4-3A3A-41AE-B4BC-E374BE737B47@koanlogic.com> <4F1131E2-6997-4F2B-A51A-DD2A8607F9E0@tzi.org> <4F92EEE2.6080801@cs.tcd.ie> <94216E93-4059-4EA2-B4AE-88BF67E74369@koanlogic.com> <49276523-70CC-40F2-9D34 -FF8F3348BA0C@tzi.org> <3A4E7A39-C78D-45A9-97ED-9D48B4107DED@tzi.org> <8731C205-19B1-43A0-B522-CE167C7BD80B@koanlogic.com> <0645900D-3DA0-4324-BE2C-61814F51CC3F@tzi.org> <7C60E917-1E01-40B5-9785-13A11DF87E53@tzi.org> <3BD7437B-00DB-4AD4-921D-8D3B9D8B6F8A@koanlogic.com> <2F98C031-3111-4CA7-A59B-B1AC4356B1D2@tzi.org> <4F95DBB2.5010005@cs.tcd.ie> <05679D7C-DFAA-478A-8D74-8E630775C992@tzi.org> In-Reply-To: <05679D7C-DFAA-478A-8D74-8E630775C992@tzi.org> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: core WG Subject: Re: [core] Specifying security parameters 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, 24 Apr 2012 09:48:34 -0000 On 04/24/2012 10:20 AM, Carsten Bormann wrote: > I feel a bit dirty, I'm going to take a shower now... I feel your pain:-) Having a strawman for this is a good approach I'd say so folks get to figure it out. Only other thing - some of Thomas' ideas sound like a recent discussion on httpbis about making TLS always-on for HTTP/2.0. I'm a bit skeptical that it can be done well, but if it were to be attempted, there would I guess be benefits in having similar approaches in core and httpbis. (Note: I don't mean the same on the wire format, so I should probably use the word architecture but then I'm never quite sure what that means;-) Some of the TLS discussion starts at [1]. Probably best not to re-ignite the thread over there unless/until there's a concrete proposal over here though. S. [1] http://lists.w3.org/Archives/Public/ietf-http-wg/2012AprJun/0085.html From alper.yegin@yegin.org Tue Apr 24 07:17: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 6816221F87E4 for ; Tue, 24 Apr 2012 07:17:11 -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=[AWL=-0.000, 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 SbjjgH5pQF0v for ; Tue, 24 Apr 2012 07:17:11 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id C73A521F87E2 for ; Tue, 24 Apr 2012 07:17:10 -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 0MQiRh-1SoUoQ21Ur-00UmpS; Tue, 24 Apr 2012 10:16:58 -0400 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_4BEB4BBA-F2FC-405C-80AA-7B04B7238C6D" From: Alper Yegin In-Reply-To: <7C60E917-1E01-40B5-9785-13A11DF87E53@tzi.org> Date: Tue, 24 Apr 2012 17:16:36 +0300 Message-Id: <97B6DAFB-6C33-4918-B762-9FD265ED662F@yegin.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> <4F8D1EA8.6080800@ericsson.com> <68B487AC-7384-4B75-9E1F-32CB8454D2F0@koanlogic.com> <4F92196E.9000701@cs.tcd.ie> <9158B27B-8C40-43A7-B957-961A9E29448B@koanlogic.com> <4F92DCFF.4090301@cs.tcd.ie> <7C11BCD4-3A3A-41AE-B4BC-E374BE737B47@koanlogic.com> <4F1131E2-6997-4F2B-A51A-DD2A8607F9E0@tzi.org> <4F92EEE2.6080801@cs.tcd.ie> <94216E93-4059-4EA2-B4AE-88BF67E74369@koanlogic.com> <49276523-70CC-40F2-9D34 -FF8F3348BA0C@tzi.org> <3A4E7A39-C78D-45A9-97ED-9D48B4107DED@tzi.org> <8731C205-19B1-43A0-B522-CE167C7BD80B@koanlogic.com> <0645900D-3DA0-4324-BE2C-61814F51CC3F@tzi.org> <7C60E917-1E01-40B5-9785-13A11DF87E53@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1257) X-Provags-ID: V02:K0:k9Rt/gxU/getSdO5thulcg8nu+8+L+VSZDamZDmZJrB pHboG25TSzFcsz9vKFGHF6N9yTmq5Iw4OpHNHicujtAP7fk32t O6HbzWXANEBy4eAlrFTRa9vwJpNzf4q1Nt7ikmPgFG9i4Lrkuo JRrE9VyZj7b3j3oz7TTqBH9e+IGKIBp2g5kmViyX9cdy2pQNTw kyrggzTc60Q4fbpV+NBdluUd+UmE27zuPW1ypPc/fAnVcpGItK u6IMzaY9Y+KDygxRHL65dPdL7jWeWFjursqpNE+uZWNm7TvsDt rYdfqpwg+rmmgXRykdadxPwAeDnTpMaAPUnBIvNOILo+7A6XSL uauZDN+KyRdfy4nhU20qos71i3BMwRfQamkZ9waY8ZSULDZG7+ enuFv5NuR0wmw== Cc: core WG Subject: Re: [core] Specifying security parameters 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, 24 Apr 2012 14:17:11 -0000 --Apple-Mail=_4BEB4BBA-F2FC-405C-80AA-7B04B7238C6D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 >> Perhaps it's time to think seriously about a CoAP specific COMSEC = mechanism instead of relying on external blocks that for one reason or = another are never completely satisfactory and/or applicable ? >=20 > Well, Alper tried that=85 Yep, I did. draft-yegin-coap-security-options. Folks found missing pieces to make it fully workable. Things that are = easily fixable. But more importantly, main objection I received was "we have TLS, we = don't need anything else".=20 So discussions like the one in this thread, and points like > I'm pretty sure DTLS is the right comsec mechanism for us, at least as = long as we don't try to use multicast. > But I'm always willing to be surprised=85 >=20 and "For the applications I have looked at that really need to cross = untrusted intermediaries, I'd rather do object security." are worth noting in this context. Alper --Apple-Mail=_4BEB4BBA-F2FC-405C-80AA-7B04B7238C6D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Perhaps = it's time to think seriously about a CoAP specific COMSEC mechanism = instead of relying on external blocks that for one reason or another are = never completely satisfactory and/or applicable = ?

Well, Alper tried = that=85

Yep, I did. = draft-yegin-coap-security-options.

Folks found = missing pieces to make it fully workable. Things that are easily = fixable.
But more importantly, main objection I received was = "we have TLS, we don't need anything = else". 

So discussions like the one in = this thread, and points = like


I'm pretty sure DTLS is the right comsec mechanism = for us, at least as long as we don't try to use multicast.
But I'm = always willing to be = surprised=85


and

"F= or the applications I have looked at that really need to cross untrusted = intermediaries, I'd rather do object = security."

are worth noting in this = context.

Alper

= --Apple-Mail=_4BEB4BBA-F2FC-405C-80AA-7B04B7238C6D-- From fluffy@iii.ca Tue Apr 24 08:37: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 3D7ED21F881C for ; Tue, 24 Apr 2012 08:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 gnsMIDSow700 for ; Tue, 24 Apr 2012 08:37:33 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id F0CF021F881B for ; Tue, 24 Apr 2012 08:37:32 -0700 (PDT) Received: from [10.154.36.65] (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 DF3E322E256; Tue, 24 Apr 2012 11:37:25 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <3DCEBC7F-AEF7-43B0-8960-FD53F77175E8@koanlogic.com> Date: Tue, 24 Apr 2012 08:37:25 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <001b01cced71$c60c8b60$5225a220$@uni-rostock.de> <07CC0900-8116-4242-AB96-D74879E247D8@tzi.org> <001e01cced78$e09dd400$a1d97c00$@uni-rostock.de> <73456E11-9651-4FB8-82E3-1CBC490C55DF@tzi.org> <4F3E758B.8020007@stpeter.im> <000f01ccedb0$cd0fe620$672fb260$@uni-rostock.de> <5961B851-CBE9-445D-945A-2FC800A9667E@iii.ca> <91B1300E-F3A2-4672-8715-A0C006990DEB@sensinode.com> <175E4D4E-31AE-44CF-8CFF-DC6A26A64F74@tzi.org> <2DC1D69D-9D89-409F-A8B2-94729A3787ED@iii.ca> <6552ED5D-DB09-4F91-A869-73F90233E55F@sensinode.com> <3DCEBC7F-AEF7-43B0-8960-FD53F77175E8@koanlogic.com> To: Thomas Fossati X-Mailer: Apple Mail (2.1257) Cc: core@ietf.org Subject: Re: [core] EXI content type and encoding (was: Resolution to tickets #176, #177, #181) 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, 24 Apr 2012 15:37:34 -0000 On Apr 24, 2012, at 24:08 , Thomas Fossati wrote: >> Content-And-Encoding-Id? > > Media-Encoding ? Content-Format ? From cabo@tzi.org Tue Apr 24 08:43: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 5048921F8844 for ; Tue, 24 Apr 2012 08:43: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_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 IsB-i6SZDkBK for ; Tue, 24 Apr 2012 08:43: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 8E02B21F8746 for ; Tue, 24 Apr 2012 08:43: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 q3OFh4H8003026; Tue, 24 Apr 2012 17:43:04 +0200 (CEST) Received: from [192.168.217.105] (p5B3E64AF.dip.t-dialin.net [91.62.100.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id F276F79; Tue, 24 Apr 2012 17:43:03 +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, 24 Apr 2012 17:43:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <001b01cced71$c60c8b60$5225a220$@uni-rostock.de> <07CC0900-8116-4242-AB96-D74879E247D8@tzi.org> <001e01cced78$e09dd400$a1d97c00$@uni-rostock.de> <73456E11-9651-4FB8-82E3-1CBC490C55DF@tzi.org> <4F3E758B.8020007@stpeter.im> <000f01ccedb0$cd0fe620$672fb260$@uni-rostock.de> <5961B851-CBE9-445D-945A-2FC800A9667E@iii.ca> <91B1300E-F3A2-4672-8715-A0C006990DEB@sensinode.com> <175E4D4E-31AE-44CF-8CFF-DC6A26A64F74@tzi.org> <2DC1D69D-9D89-409F-A8B2-94729A3787ED@iii.ca> <6552ED5D-DB09-4F91-A869-73F90233E55F@sensinode.com> <3DCEBC7F-AEF7-43B0-8960-FD53F77175E8@koanlogic.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1257) Cc: core@ietf.org Subject: Re: [core] EXI content type and encoding (was: Resolution to tickets #176, #177, #181) 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, 24 Apr 2012 15:43:13 -0000 On Apr 24, 2012, at 17:37, Cullen Jennings wrote: > Content-Format ? That's closer. Format =3D Type + Encoding, very well. But why content? Payload-Format? Gr=FC=DFe, Carsten From cabo@tzi.org Tue Apr 24 08:47: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 36BBD21F8686 for ; Tue, 24 Apr 2012 08:47:46 -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 EdliA82J3LhY for ; Tue, 24 Apr 2012 08:47:45 -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 251C521F8681 for ; Tue, 24 Apr 2012 08:47:44 -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 q3OFlc10004863; Tue, 24 Apr 2012 17:47:38 +0200 (CEST) Received: from [192.168.217.105] (p5B3E64AF.dip.t-dialin.net [91.62.100.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D05377E; Tue, 24 Apr 2012 17:47: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: Date: Tue, 24 Apr 2012 17:47:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <434ADF6F-052B-4061-85B8-736942EE3402@tzi.org> References: <001b01cced71$c60c8b60$5225a220$@uni-rostock.de> <07CC0900-8116-4242-AB96-D74879E247D8@tzi.org> <001e01cced78$e09dd400$a1d97c00$@uni-rostock.de> <73456E11-9651-4FB8-82E3-1CBC490C55DF@tzi.org> <4F3E758B.8020007@stpeter.im> <000f01ccedb0$cd0fe620$672fb260$@uni-rostock.de> <5961B851-CBE9-445D-945A-2FC800A9667E@iii.ca> <91B1300E-F3A2-4672-8715-A0C006990DEB@sensinode.com> <175E4D4E-31AE-44CF-8CFF-DC6A26A64F74@tzi.org> <2DC1D69D-9D89-409F-A8B2-94729A3787ED@iii.ca> <6552ED5D-DB09-4F91-A869-73F90233E55F@sensinode.com> <3DCEBC7F-AEF7-43B0-8960-FD53F77175E8@koanlogic.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1257) Cc: core@ietf.org Subject: Re: [core] EXI content type and encoding (was: Resolution to tickets #176, #177, #181) 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, 24 Apr 2012 15:47:46 -0000 On Apr 24, 2012, at 17:43, Carsten Bormann wrote: > Payload-Format? On the other hand, Content-Format can still be abbreviated ct -- no need = to change link-format on-the-wire :) Gr=FC=DFe, Carsten From fluffy@iii.ca Tue Apr 24 08:53: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 133C821F87AB for ; Tue, 24 Apr 2012 08:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 uHfDt+FSh2kP for ; Tue, 24 Apr 2012 08:53:25 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9906121F86D8 for ; Tue, 24 Apr 2012 08:53:25 -0700 (PDT) Received: from [10.154.36.65] (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 D90D522E267; Tue, 24 Apr 2012 11:53:24 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: Date: Tue, 24 Apr 2012 08:53:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9254990E-EDD9-41DE-A789-EC58D3D22B02@iii.ca> References: <001b01cced71$c60c8b60$5225a220$@uni-rostock.de> <07CC0900-8116-4242-AB96-D74879E247D8@tzi.org> <001e01cced78$e09dd400$a1d97c00$@uni-rostock.de> <73456E11-9651-4FB8-82E3-1CBC490C55DF@tzi.org> <4F3E758B.8020007@stpeter.im> <000f01ccedb0$cd0fe620$672fb260$@uni-rostock.de> <5961B851-CBE9-445D-945A-2FC800A9667E@iii.ca> <91B1300E-F3A2-4672-8715-A0C006990DEB@sensinode.com> <175E4D4E-31AE-44CF-8CFF-DC6A26A64F74@tzi.org> <2DC1D69D-9D89-409F-A8B2-94729A3787ED@iii.ca> <6552ED5D-DB09-4F91-A869-73F90233E55F@sensinode.com> <3DCEBC7F-AEF7-43B0-8960-FD53F77175E8@koanlogic.com> To: Carsten Bormann X-Mailer: Apple Mail (2.1257) Cc: core@ietf.org Subject: Re: [core] EXI content type and encoding (was: Resolution to tickets #176, #177, #181) 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, 24 Apr 2012 15:53:26 -0000 On Apr 24, 2012, at 8:43 , Carsten Bormann wrote: > On Apr 24, 2012, at 17:37, Cullen Jennings wrote: >=20 >> Content-Format ? >=20 > That's closer. > Format =3D Type + Encoding, very well. >=20 > But why content? > Payload-Format? good point - I like Payload-Format better=20 >=20 > Gr=FC=DFe, Carsten >=20 From zach@sensinode.com Tue Apr 24 09:39: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 500C211E80BF for ; Tue, 24 Apr 2012 09:39:53 -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 9Vuqf8LZRgoM for ; Tue, 24 Apr 2012 09:39:51 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id E0F4411E80BA for ; Tue, 24 Apr 2012 09:39:50 -0700 (PDT) Received: from [192.168.1.101] (87-95-21-250.bb.dnainternet.fi [87.95.21.250]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q3OGdlMt023243; Tue, 24 Apr 2012 19:39:47 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <434ADF6F-052B-4061-85B8-736942EE3402@tzi.org> Date: Tue, 24 Apr 2012 19:39:46 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <001b01cced71$c60c8b60$5225a220$@uni-rostock.de> <07CC0900-8116-4242-AB96-D74879E247D8@tzi.org> <001e01cced78$e09dd400$a1d97c00$@uni-rostock.de> <73456E11-9651-4FB8-82E3-1CBC490C55DF@tzi.org> <4F3E758B.8020007@stpeter.im> <000f01ccedb0$cd0fe620$672fb260$@uni-rostock.de> <5961B851-CBE9-445D-945A-2FC800A9667E@iii.ca> <91B1300E-F3A2-4672-8715-A0C006990DEB@sensinode.com> <175E4D4E-31AE-44CF-8CFF-DC6A26A64F74@tzi.org> <2DC1D69D-9D89-409F-A8B2-94729A3787ED@iii.ca> <6552ED5D-DB09-4F91-A869-73F90233E55F@sensinode.com> <3DCEBC7F-AEF7-43B0-8960-FD53F77175E8@koanlogic.com> <434ADF6F-052B-4061-85B8-736942EE3402@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org Subject: Re: [core] EXI content type and encoding (was: Resolution to tickets #176, #177, #181) 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, 24 Apr 2012 16:39:53 -0000 On Apr 24, 2012, at 6:47 PM, Carsten Bormann wrote: >> Payload-Format? >=20 > On the other hand, Content-Format can still be abbreviated ct -- no = need to change link-format on-the-wire :) Oh, very good point! My final vote is for Content-Format (keeping ct=3D as the link-format = attribute) :-) Zach --=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 peter.van.der.stok@philips.com Wed Apr 25 01:10: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 14D4E21F86F1 for ; Wed, 25 Apr 2012 01:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.635 X-Spam-Level: X-Spam-Status: No, score=-5.635 tagged_above=-999 required=5 tests=[AWL=0.963, 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 VsBlumksHnnK for ; Wed, 25 Apr 2012 01:09:59 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id 15FCA21F86EB for ; Wed, 25 Apr 2012 01:09:58 -0700 (PDT) Received: from mail139-va3-R.bigfish.com (10.7.14.238) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Wed, 25 Apr 2012 08:09:57 +0000 Received: from mail139-va3 (localhost [127.0.0.1]) by mail139-va3-R.bigfish.com (Postfix) with ESMTP id BF23D240420; Wed, 25 Apr 2012 08:09:57 +0000 (UTC) X-SpamScore: -14 X-BigFish: VPS-14(zz217bL15d6O9251Jc85fh1521Izz1202hzz8275bhz2dh2a8h668h839hd25h) 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 mail139-va3 (localhost.localdomain [127.0.0.1]) by mail139-va3 (MessageSwitch) id 1335341395513046_12303; Wed, 25 Apr 2012 08:09:55 +0000 (UTC) Received: from VA3EHSMHS020.bigfish.com (unknown [10.7.14.241]) by mail139-va3.bigfish.com (Postfix) with ESMTP id 6A6302C0092; Wed, 25 Apr 2012 08:09:55 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by VA3EHSMHS020.bigfish.com (10.7.99.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 25 Apr 2012 08:09:55 +0000 Received: from 011-DB3MMR1-014.MGDPHG.emi.philips.com (10.128.28.98) by 011-DB3MMR1-011.MGDPHG.emi.philips.com (10.128.28.50) with Microsoft SMTP Server (TLS) id 14.1.355.3; Wed, 25 Apr 2012 09:09:54 +0100 Received: from 011-DB3MPN1-062.MGDPHG.emi.philips.com ([169.254.2.41]) by 011-DB3MMR1-014.MGDPHG.emi.philips.com ([10.128.28.98]) with mapi id 14.01.0355.003; Wed, 25 Apr 2012 09:12:46 +0100 From: "Stok, Peter van der" To: "core@ietf.org" , Carsten Bormann , Zach Shelby Thread-Topic: objectives of block-08 draft Thread-Index: Ac0iusrYCc5kqXp5S+yNrFTCsEaKiQ== Date: Wed, 25 Apr 2012 08:09:53 +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_A31CB84F6F0BFC449C6807DF752A715B066194011DB3MPN1062MGDP_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: [core] objectives of block-08 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: Wed, 25 Apr 2012 08:10:00 -0000 --_000_A31CB84F6F0BFC449C6807DF752A715B066194011DB3MPN1062MGDP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Carsten and Zach, Reading the block-08 draft I seem to understand 3 objectives of the propose= d block protocol. I recommend to separate these in as many protocols. The objectives of block as I understand them (correct me if wrong) are: 1) Transfer of bulk of data when one datagram is not sufficient, like = supported by tftp or, more efficiently from a packet number point of view, = by tcp. 2) Transferring a subset of blocks out of a sequence of blocks, like s= upported by NFS to transfer one specific disk block from the set of blocks = constituting the file. 3) Prevention of fragmentation at the link layer, thus increasing the = reliability of the datagram transfer at network layer. The problems I have with block-08 are: As a consequence of combining these objectives, it is possible to define th= e block size. This possibility defeats objective 3, because fragmentation c= an occur. Looking at the block protocol, I wonder if it is really better than what tf= tp accomplishes with respect to objective 1. My suggestion is to leave objective 1 and adapt existing protocols like tft= p or tcp, if the wish of bulk transport exists. Objective 2 can be interesting, and I do see a use when a sensor accumulate= s history data, and a particular measurement out of the whole history is ne= eded. Objective 3 seems interesting given that many UDP based applications are op= timized to send one UDP packet which unfortunately may exceed the payload s= ize of a single IP packet. Consequently, it seems reasonable to specify two protocols: a block transfe= r protocol (objective 2) and a fragmentation protocol (objective 3). The possibly large blocks delivered by objective 2 protocol can be fragment= ed by objective 3 protocol. For objective 3, one can ask whether this is single hop, or that it is an e= nd-to-end protocol from fragmenting node to receiving or defragmenting node= over multiple hops. Greetings, Peter Peter van der Stok phone +31 492 474673 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_A31CB84F6F0BFC449C6807DF752A715B066194011DB3MPN1062MGDP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Carsten and Zach,

 

Reading the block-08 draft I seem to understand 3 ob= jectives of the proposed block protocol. I recommend to separate these in a= s many protocols.

The objectives of block as I understand them (correc= t me if wrong) are:

1)  &nbs= p;   Transfer of bulk of data when one datagram is not sufficient,= like supported by tftp or, more efficiently from a packet number point of = view, by tcp.

2)  &nbs= p;   Transferring a subset of blocks out of a sequence of blocks, = like supported by NFS to transfer one specific disk block from the set of b= locks constituting the file.

3)  &nbs= p;   Prevention of fragmentation at the link layer, thus increasin= g the reliability of the datagram transfer at network layer.

 

The problems I have with block-08 are:

As a consequence of combining these objectives, it i= s possible to define the block size. This possibility defeats objective 3, = because fragmentation can occur.

Looking at the block protocol, I wonder if it is rea= lly better than what tftp accomplishes with respect to objective 1.

 

My suggestion is to leave objective 1 and adapt exis= ting protocols like tftp or tcp, if the wish of bulk transport exists.

Objective 2 can be interesting, and I do see a use w= hen a sensor accumulates history data, and a particular measurement out of = the whole history is needed.

Objective 3 seems interesting given that many UDP ba= sed applications are optimized to send one UDP packet which unfortunately m= ay exceed the payload size of a single IP packet.

 

Consequently, it seems reasonable to specify two pro= tocols: a block transfer protocol (objective 2) and a fragmentation protoco= l (objective 3).

The possibly large blocks delivered by objective 2 p= rotocol can be fragmented by objective 3 protocol.

For objective 3, one can ask whether this is single = hop, or that it is an end-to-end protocol from fragmenting node to receivin= g or defragmenting node over multiple hops.

 

Greetings,

 

Peter

 

 

Peter van der Stok

phone +31 492 474673      &= nbsp;    

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_A31CB84F6F0BFC449C6807DF752A715B066194011DB3MPN1062MGDP_-- From peter.van.der.stok@philips.com Wed Apr 25 05:18: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 CB1AC21F8754 for ; Wed, 25 Apr 2012 05:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.221 X-Spam-Level: X-Spam-Status: No, score=-2.221 tagged_above=-999 required=5 tests=[AWL=-2.611, BAYES_00=-2.599, FRT_STOCK1=3.988, 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 BtjQ1HbXyCSx for ; Wed, 25 Apr 2012 05:18:52 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe004.messaging.microsoft.com [213.199.154.142]) by ietfa.amsl.com (Postfix) with ESMTP id C089821F8743 for ; Wed, 25 Apr 2012 05:18:51 -0700 (PDT) Received: from mail98-db3-R.bigfish.com (10.3.81.252) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.23; Wed, 25 Apr 2012 12:18:51 +0000 Received: from mail98-db3 (localhost [127.0.0.1]) by mail98-db3-R.bigfish.com (Postfix) with ESMTP id CF7591E00B4; Wed, 25 Apr 2012 12:18:50 +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 mail98-db3 (localhost.localdomain [127.0.0.1]) by mail98-db3 (MessageSwitch) id 1335356328490978_18178; Wed, 25 Apr 2012 12:18:48 +0000 (UTC) Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.236]) by mail98-db3.bigfish.com (Postfix) with ESMTP id 7327280072; Wed, 25 Apr 2012 12:18:48 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 25 Apr 2012 12:18:47 +0000 Received: from 011-DB3MPN1-062.MGDPHG.emi.philips.com ([169.254.2.41]) by 011-DB3MMR1-008.MGDPHG.emi.philips.com ([10.128.28.47]) with mapi id 14.01.0355.003; Wed, 25 Apr 2012 13:18:47 +0100 From: "Stok, Peter van der" To: "core@ietf.org" , Klaus Hartke Thread-Topic: observe-05 draft Thread-Index: Ac0i3ZBPIClqRC8LR2GUm1Fubck1jQ== Date: Wed, 25 Apr 2012 12:18:47 +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_A31CB84F6F0BFC449C6807DF752A715B06620F011DB3MPN1062MGDP_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: [core] observe-05 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: Wed, 25 Apr 2012 12:18:53 -0000 --_000_A31CB84F6F0BFC449C6807DF752A715B06620F011DB3MPN1062MGDP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Klaus, Probably, this has been stated before, in that case I like to reiterate tha= t a reference to the groupcomm draft is called for. The subject: a node sends messages about resource state changes to a group = of clients is indeed at the heart of group communication as pointed out in = the groupcomm draft. This draft also clarifies the different requirements on group communication= and the protocols that satisfy a subset of these requirements. In your implementation, each client is forced to ack a unicast when it is s= ent with a CON message, and otherwise the message is not ack'ed and no reli= ability is "guaranteed". Some multicast protocols can guarantee reliability without acking but by re= plicating a message along different paths. IMO, the draft will certainly improve when these possibilities are taken in= to account by explaining how to use an appropriate group communication prot= ocol when it is present. Another point is the statement that the node should maintain a list of clie= nts. In principle this is not necessary when a multicast address is used for add= ressing the group. The node only needs to maintain the multicast address th= us saving RAM space. Groups can be maintained in DNS-SD, or the resource directory (Zach allowin= g this). How the group communication to the group, using the multicast address, is d= one - with a multicast or with individual unicasts- is the concern of the g= roup communication protocol. Hope you see my point. Greetings, peter Peter van der Stok Kamperfoelie 8 5708 DM Helmond, The Netherlands phone +31 492 474673 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_A31CB84F6F0BFC449C6807DF752A715B06620F011DB3MPN1062MGDP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear  Klaus,

 

Probably, this has been stated before, in that case = I like to reiterate that a reference to the groupcomm draft is called for.<= /p>

The subject: a node sends messages about resource st= ate changes to a group of clients is indeed at the heart of group communica= tion as pointed out in the groupcomm draft.

This draft also clarifies the different requirements= on group communication and the protocols that satisfy a subset of these re= quirements.

In your implementation, each client is forced to ack= a unicast when it is sent with a CON message, and otherwise the message is= not ack’ed and no reliability is “guaranteed”.

Some multicast protocols can guarantee reliability w= ithout acking but by replicating  a message along different paths.

IMO, the draft will certainly improve when these pos= sibilities are taken into account by explaining how to use an appropriate g= roup communication protocol when it is present.

 

Another point is the statement that the node should = maintain a list of clients.

In principle this is not necessary when a multicast = address is used for addressing the group. The node only needs to maintain t= he multicast address thus saving RAM space.

Groups can be maintained in DNS-SD, or the resource = directory (Zach allowing this).

How the group communication to the group, using the = multicast address, is done - with a multicast or with individual unicasts- = is the concern of the group communication protocol.

 

Hope you see my point.

 

Greetings,

 

peter

 

Peter van der Stok

Kamperfoelie 8

5708 DM Helmond, The Netherlands

phone +31 492 474673      &= nbsp;    

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_A31CB84F6F0BFC449C6807DF752A715B06620F011DB3MPN1062MGDP_-- From cabo@tzi.org Wed Apr 25 09:12: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 48F5021F87C9 for ; Wed, 25 Apr 2012 09:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.975 X-Spam-Level: X-Spam-Status: No, score=-105.975 tagged_above=-999 required=5 tests=[AWL=0.274, 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 UC8Vgj3dSL-t for ; Wed, 25 Apr 2012 09:12: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 D2E4B21F87C7 for ; Wed, 25 Apr 2012 09:12: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 q3PGC10T013400; Wed, 25 Apr 2012 18:12:01 +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 4CF576CE; Wed, 25 Apr 2012 18:12:01 +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, 25 Apr 2012 18:11:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Stok, Peter van der" X-Mailer: Apple Mail (2.1257) Cc: "core@ietf.org" Subject: Re: [core] objectives of block-08 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: Wed, 25 Apr 2012 16:12:16 -0000 Hi Peter, the objective of the block options is to enable the transfer of payloads = larger than can be comfortably sent in one datagram. This is not exactly your objective 1, because CoAP is not meant to be a = bulk data transfer protocol. CoAP is efficient for bulk transfer in the = sense that it does not tax network resources in an unneeded way, but it = is not efficient in the sense of actually using all the network = resources that may be available (like TCP would do). "Comfortably" implies your objective 3, but is not identical with it. Actually, objective 3 *cannot* be achieved until we have something like = ALFI (http://tools.ietf.org/html/draft-bormann-intarea-alfi -- thanks = for prompting me to finally write this one up). But Block opens up the = selection of datagram sizes at CoAP end-points sufficiently that they = may be able to address most of this problem area. Your objective 2 never was one. It just turns out that the design of = -block makes it trivial to achieve, so we decided to take it as well = (rarely, but occasionally, simplicity and generality do have synergy). I don't understand these two sentences: > As a consequence of combining these objectives, it is possible to = define the block size. This possibility defeats objective 3, because = fragmentation can occur. Obviously, adaptation layer fragmentation can occur, for the reasons = that ALFI is addressing. Right now there is no way to fix that. (With = ALFI, there would be.) > Looking at the block protocol, I wonder if it is really better than = what tftp accomplishes with respect to objective 1. I have no idea what some people like about TFTP. Its only redeeming = feature appears to be that it has existed for a long time, and some of = its considerable breakage has already been fixed. But if it does solve your problem, you know where to find it. > My suggestion is to leave objective 1 and adapt existing protocols = like tftp or tcp, if the wish of bulk transport exists. If bulk transport is a significant aspect of your application, you are = better off with implementing TCP, which actually can fill all of the = network resources available. (We might even make CoAP available over TCP at some point in the future, = it certainly has been designed to make that straightforward.) Block has mainly been designed for CoAP applications that mostly need = small payloads, but may need to ship larger objects e.g. during = discovery and security setup. Cullen has indicated that he has another interesting use-case where even = the "small payloads" would benefit from -block; it will be interesting = how to address this without ALFI, but I still think CoAP -block has all = that's needed for that. =20 Just don't ship the most recent episode of your favorite TV show over = -block, please. For now, I'll take this as an editorial comment to clarify the = objectives of CoAP -block in the abstract. Gr=FC=DFe, Carsten From sarikaya2012@gmail.com Wed Apr 25 09:16: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 D382221F860B for ; Wed, 25 Apr 2012 09:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 ewia987lewQ8 for ; Wed, 25 Apr 2012 09:16:07 -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 17BC221F85DF for ; Wed, 25 Apr 2012 09:16:06 -0700 (PDT) Received: by iazz13 with SMTP id z13so312256iaz.31 for ; Wed, 25 Apr 2012 09:16:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=twMoUkSNNVxUTDVfk3lZChR54u5LxCKm44aUc/RSacE=; b=NBy561PK4HEuWqse/xvvFsTtupYQJCokBETkVGim6BscjJBbhLSGfmewtKPhzE2xkz HeKQ4c8A4CprAiRfHEev9mm/egOfx+vftctK55t/lEstmVkBdWsQPhNS+JXKLeDwUCMx wV3stxw6nHydc4fPc9NuMCnzBvySNBVg7kdRbOiB4e9B6zqwhB113/9Bd7l4v/D7T2Jd l/b9Ae9uWQgfGjUfSyPTdFKrMn54j5YnpKn0FgcCKtfJmpJviCdIztaYicKNtTXPpufK mra6v2XK72zLpowPzS4bayvXZrtkUUF3afCLwIscL+c54JQlJMrZSPuPdaU+vFVvQIJe c4Bw== MIME-Version: 1.0 Received: by 10.42.80.19 with SMTP id t19mr2656647ick.55.1335370561546; Wed, 25 Apr 2012 09:16:01 -0700 (PDT) Received: by 10.231.194.73 with HTTP; Wed, 25 Apr 2012 09:16:01 -0700 (PDT) In-Reply-To: References: <20120424201721.22657.8851.idtracker@ietfa.amsl.com> Date: Wed, 25 Apr 2012 11:16:01 -0500 Message-ID: From: Behcet Sarikaya To: core WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [core] Fwd: New Version Notification for draft-sarikaya-core-sbootstrapping-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.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, 25 Apr 2012 16:16:08 -0000 Folks, We have done a major revision on our secure bootstrapping draft. Please read it and let us know what you think? Regards, Behcet ---------- Forwarded message ---------- From: Behcet Sarikaya Date: Tue, Apr 24, 2012 at 3:19 PM Subject: Re: New Version Notification for draft-sarikaya-core-sbootstrapping-04.txt To: caozhen@chinamobile.com, rgm@labs.htt-consult.com, yoshihiro.ohba@toshiba.co.jp, robert.cragie@gridmerge.com Hi all, I revised the draft and now made it a solution draft. Please check everything and if OK, let's work hard to make it advance. Behcet On Tue, Apr 24, 2012 at 3:17 PM, =A0 wrote: > A new version of I-D, draft-sarikaya-core-sbootstrapping-04.txt has been = successfully submitted by Behcet Sarikaya and posted to the IETF repository= . > > Filename: =A0 =A0 =A0 =A0draft-sarikaya-core-sbootstrapping > Revision: =A0 =A0 =A0 =A004 > Title: =A0 =A0 =A0 =A0 =A0 Security Bootstrapping Solution for Resource-C= onstrained Devices > Creation date: =A0 2012-04-24 > WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission > Number of pages: 27 > > Abstract: > =A0 This document describes how to initially configure the network of > =A0 resource constrained nodes securely, a.k.a., security bootstrapping. > =A0 Bootstrapping architecture, communication channel and bootstrap > =A0 security methods are described. =A0System level objectives for securi= ty > =A0 bootstrapping are stated followed by the protocols that can be used. > =A0 Bootstrapping solution is based on EAP-TLS authentication with the > =A0 use of raw public keys used as certificates. > > > > > The IETF Secretariat From peter.van.der.stok@philips.com Thu Apr 26 00:50: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 7F49821F845F for ; Thu, 26 Apr 2012 00:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.015 X-Spam-Level: X-Spam-Status: No, score=-4.015 tagged_above=-999 required=5 tests=[AWL=-0.416, 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 NLFXJ2daJ2QC for ; Thu, 26 Apr 2012 00:50:52 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id ADE6521F87D1 for ; Thu, 26 Apr 2012 00:50:50 -0700 (PDT) Received: from mail22-am1-R.bigfish.com (10.3.201.240) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.23; Thu, 26 Apr 2012 07:50:49 +0000 Received: from mail22-am1 (localhost [127.0.0.1]) by mail22-am1-R.bigfish.com (Postfix) with ESMTP id CE531400125; Thu, 26 Apr 2012 07:50:48 +0000 (UTC) X-SpamScore: -49 X-BigFish: VPS-49(zz217bL15d6O9251Jc89bh1521I542M148cM1447Mzz1202hzz1033IL8275dhz2dh2a8h668h839hd25h) 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 1335426646430388_16898; Thu, 26 Apr 2012 07:50:46 +0000 (UTC) Received: from AM1EHSMHS012.bigfish.com (unknown [10.3.201.238]) by mail22-am1.bigfish.com (Postfix) with ESMTP id 5AEEBA0046; Thu, 26 Apr 2012 07:50:46 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by AM1EHSMHS012.bigfish.com (10.3.207.112) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 26 Apr 2012 07:50:46 +0000 Received: from 011-DB3MPN1-062.MGDPHG.emi.philips.com ([169.254.2.41]) by 011-DB3MMR1-001.MGDPHG.emi.philips.com ([10.128.28.51]) with mapi id 14.01.0355.003; Thu, 26 Apr 2012 08:50:45 +0100 From: "Stok, Peter van der" To: Carsten Bormann Thread-Topic: objectives of block-08 draft Thread-Index: Ac0iusrYCc5kqXp5S+yNrFTCsEaKiQAOvG+AACHSvOA= Date: Thu, 26 Apr 2012 07:50:44 +0000 Message-ID: References: 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] objectives of block-08 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: Thu, 26 Apr 2012 07:50:54 -0000 Hi Carsten, Thanks for your extensive answer. Glad to read that we agree more than I had inferred from the block-08 text. If I understand correctly, block-08 specifies a way to transport 1-4 consec= utive blocks of specifiable size reliably where the size of the blocks is i= ndependent of the units of transport over the link, but can be adapted to t= he unit of transport by the application. > For now, I'll take this as an editorial comment to clarify the objectives= of CoAP -block in the abstract. Some text in block-08 that confused me: - In the abstract several references to IP fragmentation are rather promine= nt. - Introduction: bullet 2, reducing message size to minimize fragments - Introduction: several references to link layer fragmentation - Introduction: page 5, bullet 1, reference to link-layer - section 2 page 6, bullet 3, reference to adaptation fragmentation - section 2, use of coap datagram and coap message without knowing their re= lation and relation to payload size of UDP datagram. Section 3 examples are rather protocol technical. The addition of an exampl= e at application level that explains the reason to use block for the presen= ted use case(s) would be very helpful indeed. A reaction to your remark: > I don't understand these two sentences: >> As a consequence of combining these objectives, it is possible to define= the block size. This possibility defeats objective 3, because fragmentatio= n can occur. I wanted to point out that when you want to avoid packet fragmentation, the= maximum size of the blocks does not allow much negotiation (is fixed). Giving the possibility of defining larger block sizes will lead to blocks w= hich need to be fragmented which (in my understanding) you wanted to avoid = in block-08 draft. Thanks for the alfi draft; Rarely my suggestions lead to such fast reaction= s. Explaining in block-08 better the relation between block option and the avo= idance of fragmentation, also pointing out the variable payload size per pa= cket could help understand the purpose of block much better. Greetings, peter -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: Wednesday 25 April 2012 18:12 To: Stok, Peter van der Cc: core@ietf.org; Zach Shelby Subject: Re: objectives of block-08 draft Hi Peter, the objective of the block options is to enable the transfer of payloads la= rger than can be comfortably sent in one datagram. This is not exactly your objective 1, because CoAP is not meant to be a bul= k data transfer protocol. CoAP is efficient for bulk transfer in the sense= that it does not tax network resources in an unneeded way, but it is not e= fficient in the sense of actually using all the network resources that may = be available (like TCP would do). "Comfortably" implies your objective 3, but is not identical with it. Actually, objective 3 *cannot* be achieved until we have something like ALF= I (http://tools.ietf.org/html/draft-bormann-intarea-alfi -- thanks for prom= pting me to finally write this one up). But Block opens up the selection o= f datagram sizes at CoAP end-points sufficiently that they may be able to a= ddress most of this problem area. Your objective 2 never was one. It just turns out that the design of -bloc= k makes it trivial to achieve, so we decided to take it as well (rarely, bu= t occasionally, simplicity and generality do have synergy). I don't understand these two sentences: > As a consequence of combining these objectives, it is possible to define = the block size. This possibility defeats objective 3, because fragmentation= can occur. Obviously, adaptation layer fragmentation can occur, for the reasons that A= LFI is addressing. Right now there is no way to fix that. (With ALFI, the= re would be.) > Looking at the block protocol, I wonder if it is really better than what = tftp accomplishes with respect to objective 1. I have no idea what some people like about TFTP. Its only redeeming featur= e appears to be that it has existed for a long time, and some of its consid= erable breakage has already been fixed. But if it does solve your problem, you know where to find it. > My suggestion is to leave objective 1 and adapt existing protocols like t= ftp or tcp, if the wish of bulk transport exists. If bulk transport is a significant aspect of your application, you are bett= er off with implementing TCP, which actually can fill all of the network re= sources available. (We might even make CoAP available over TCP at some point in the future, it= certainly has been designed to make that straightforward.) Block has mainly been designed for CoAP applications that mostly need small= payloads, but may need to ship larger objects e.g. during discovery and se= curity setup. Cullen has indicated that he has another interesting use-case where even th= e "small payloads" would benefit from -block; it will be interesting how to= address this without ALFI, but I still think CoAP -block has all that's ne= eded for that. Just don't ship the most recent episode of your favorite TV show over -bloc= k, please. For now, I'll take this as an editorial comment to clarify the objectives o= f CoAP -block in the abstract. 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 cabo@tzi.org Thu Apr 26 01:40: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 8A3BB21F87AB for ; Thu, 26 Apr 2012 01:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106 X-Spam-Level: X-Spam-Status: No, score=-106 tagged_above=-999 required=5 tests=[AWL=0.249, 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 iNMH1Z8dqjGD for ; Thu, 26 Apr 2012 01:40: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 9D75821F87C7 for ; Thu, 26 Apr 2012 01:40: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 q3Q8dxLT012387; Thu, 26 Apr 2012 10:39:59 +0200 (CEST) Received: from eduroam-pool3-365.wlan.uni-bremen.de (eduroam-pool3-365.wlan.uni-bremen.de [134.102.233.109]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 336298F8; Thu, 26 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: <4F9676EA.9030201@cs.tcd.ie> Date: Thu, 26 Apr 2012 10:39:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F8C1A5C.10309@ericsson.com> <68B487AC-7384-4B75-9E1F-32CB8454D2F0@koanlogic.com> <4F92196E.9000701@cs.tcd.ie> <9158B27B-8C40-43A7-B957-961A9E29448B@koanlogic.com> <4F92DCFF.4090301@cs.tcd.ie> <7C11BCD4-3A3A-41AE-B4BC-E374BE737B47@koanlogic.com> <4F1131E2-6997-4F2B-A51A-DD2A8607F9E0@tzi.org> <4F92EEE2.6080801@cs.tcd.ie> <94216E93-4059-4EA2-B4AE-88BF67E74369@koanlogic.com> <49276523-70CC-40F2-9D34 -FF8F3348BA0C@tzi.org> <3A4E7A39-C78D-45A9-97ED-9D48B4107DED@tzi.org> <8731C205-19B1-43A0-B522-CE167C7BD80B@koanlogic.com> <0645900D-3DA0-4324-BE2C-61814F51CC3F@tzi.org> <7C60E917-1E01-40B5-9785-13A11DF87E53@tzi.org> <3BD7437B-00DB-4AD4-921D-8D3B9D8B6F8A@koanlogic.com> <2F98C031-3111-4CA7-A59B-B1AC4356B1D2@tzi.org> <4F95DBB2.5010005@cs.tcd.ie> <05679D7C-DFAA-478A-8D74-8E630775C992@tzi.org> <4F9676EA.9030201@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1257) Cc: core WG Subject: Re: [core] Specifying security parameters 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, 26 Apr 2012 08:40:12 -0000 On Apr 24, 2012, at 11:48, Stephen Farrell wrote: > Having a strawman for this is a good approach I'd say > so folks get to figure it out. It also appears to be a good way to terminate a thread :-) Back to the actual subject of this thread: Note that CONNECT gets around the need to (as opposed to solves how to) = specify security parameters. We still have the need in coaps:// -- I'm = not seeing anything equivalent being discussed for https://. Note that, for https://, the need for discussion of "breaking TLS" is = about retroactively opening up (without consent of the parties) the = existing assumption of a homogeneous security semantics of https://. = For coaps://, we could do a lot more to capture intent/consent, so much = of the discussion in that thread simply does not apply.=20 Let me try to summarize that rather verbose discussion anyway: -- Some site/network administrators require visibility into traffic -- whether for bogus legal reasons, legitimate malware protection or DLP requirements or whatever is pretty much irrelevant -- Some end-points need to deny that visibility -- banking, paypal, ... but is that really all? -- HTTPS has no way of expressing any consent or denial -- so the policy has to be cooked up out of thin air -- clients interpret "let's have some security" based on their random local policy (which may or may not include untrustable root CAs and MITM certs) -- intermediaries have policies that are second-guessing the end-points' policies (e.g., exception tables for banking) -- servers have no say (except flat out denying port 80), which is a pity as their administrators are often in a better position to provide informed input than the clients' end-users -- intermediaries can't really negotiate their policies in such a way that the end-points can live with the result -- users have no visibility about the actual outcome -- (we can't even say whether HTTPS is specified to achieve confidentiality or just integrity protection) -- Summary: HTTPS is horribly broken -- extending its security model to the entire Web (and not just the part that agreed to suffer by using the https:// scheme) would expose this breakage in unacceptable ways (this is what people mean when they say "all-or-nothing security"). -- on the other hand "using encryption sparingly" is not really going to help HTTPS either, because there *are* many valid uses for security that require different policies than paypal, and the system already is bursting at its seams as is. Note that I said HTTPS is broken, not TLS -- it is the combination of TLS with a single implied one-size-fits-all security policy that is causing the problem. In the HTTP web, we are now building tables that map server domain names to security policy information (e.g., firewall exception tables for banking, client tables for HSTS, ...). Hosts.txt for security clearly does not scale beyond an elite club (which doesn't mean it won't work well for Paypal). Maybe linked data can help, but I'm not sure its proponents have thought much about liability issues. Other observations: 1) Conveying security policy towards the client in or alongside a URI only provides part of the picture, as this information could, too, be compromised by a MITM-style intermediary (Roberto Peon seems to have = some ideas here, promised a draft); there often needs to be some mutual checking. 2) This checking is, however, fundamentally limited by clients that collude with what would be an adversary from the point of view of the server. 3) Ceterum censeo: Trying to use the CoRE WG to invent all the required mechanism to solve this area of problems would be insane. So let's try to get some focus on the issue what security parameters = would have to come with a coaps:// scheme. Gr=FC=DFe, Carsten From esko.dijk@philips.com Thu Apr 26 02:47: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 028D021F8627 for ; Thu, 26 Apr 2012 02:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.292 X-Spam-Level: X-Spam-Status: No, score=-5.292 tagged_above=-999 required=5 tests=[AWL=1.307, 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 29QEI50lgBFt for ; Thu, 26 Apr 2012 02:47:51 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 07F6721F87EC for ; Thu, 26 Apr 2012 02:47:50 -0700 (PDT) Received: from mail24-tx2-R.bigfish.com (10.9.14.236) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.23; Thu, 26 Apr 2012 09:47:49 +0000 Received: from mail24-tx2 (localhost [127.0.0.1]) by mail24-tx2-R.bigfish.com (Postfix) with ESMTP id 76980C00DA; Thu, 26 Apr 2012 09:47:49 +0000 (UTC) X-SpamScore: -49 X-BigFish: VPS-49(zz217bL15d6O9251Jc89bh1521I542M148cM1447Mzz1202hzz1033IL8275dhz2dh2a8h668h839hd25h) 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 mail24-tx2 (localhost.localdomain [127.0.0.1]) by mail24-tx2 (MessageSwitch) id 1335433667346574_5916; Thu, 26 Apr 2012 09:47:47 +0000 (UTC) Received: from TX2EHSMHS036.bigfish.com (unknown [10.9.14.251]) by mail24-tx2.bigfish.com (Postfix) with ESMTP id 4D8B14800C0; Thu, 26 Apr 2012 09:47:47 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by TX2EHSMHS036.bigfish.com (10.9.99.136) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 26 Apr 2012 09:47:46 +0000 Received: from 011-DB3MPN1-012.MGDPHG.emi.philips.com ([169.254.2.221]) by 011-DB3MMR1-006.MGDPHG.emi.philips.com ([10.128.28.56]) with mapi id 14.01.0355.003; Thu, 26 Apr 2012 10:47:43 +0100 From: "Dijk, Esko" To: "Stok, Peter van der" , Carsten Bormann Thread-Topic: objectives of block-08 draft Thread-Index: AQHNI4G74pfhKEDzgU6mqL/fBjldQJas2GbQ Date: Thu, 26 Apr 2012 09:47:43 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED6180B2610@011-DB3MPN1-012.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] objectives of block-08 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: Thu, 26 Apr 2012 09:47:52 -0000 Confusion may be also caused by the difference between minimizing fragmenta= tion and avoiding fragmentation. (Peter you mention avoiding.) One choice i= s to refer to "minimizing" rather than "avoiding" in -block? Thus choosing a smaller block size will always (on average) reduce the prob= ability of fragmentation, so ability to choose block size and negotiation t= o smaller block sizes really helps. (Without the CoAP end-point actually kn= owing whether fragmentation occurs.) The following text in -block suggests "avoidance" a bit: "No hard-to-manage conversation state is created at the adaptation layer or IP layer for fragmentation." rather -> "Minimal" or "less" hard-to-manage conversation state is created = at the adaptation... ? "by the desire to avoid adaptation layer fragmentation (60-80 bytes for 6LoWPAN [RFC4919])" -> "desire to minimize" ? Esko =20 -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Sto= k, Peter van der Sent: Thursday 26 April 2012 9:51 To: Carsten Bormann Cc: core@ietf.org Subject: Re: [core] objectives of block-08 draft Hi Carsten, Thanks for your extensive answer. Glad to read that we agree more than I had inferred from the block-08 text. If I understand correctly, block-08 specifies a way to transport 1-4 consec= utive blocks of specifiable size reliably where the size of the blocks is i= ndependent of the units of transport over the link, but can be adapted to t= he unit of transport by the application. > For now, I'll take this as an editorial comment to clarify the objectives= of CoAP -block in the abstract. Some text in block-08 that confused me: - In the abstract several references to IP fragmentation are rather promine= nt. - Introduction: bullet 2, reducing message size to minimize fragments - Introduction: several references to link layer fragmentation - Introduction: page 5, bullet 1, reference to link-layer - section 2 page 6, bullet 3, reference to adaptation fragmentation - section 2, use of coap datagram and coap message without knowing their re= lation and relation to payload size of UDP datagram. Section 3 examples are rather protocol technical. The addition of an exampl= e at application level that explains the reason to use block for the presen= ted use case(s) would be very helpful indeed. A reaction to your remark: > I don't understand these two sentences: >> As a consequence of combining these objectives, it is possible to define= the block size. This possibility defeats objective 3, because fragmentatio= n can occur. I wanted to point out that when you want to avoid packet fragmentation, the= maximum size of the blocks does not allow much negotiation (is fixed). Giving the possibility of defining larger block sizes will lead to blocks w= hich need to be fragmented which (in my understanding) you wanted to avoid = in block-08 draft. Thanks for the alfi draft; Rarely my suggestions lead to such fast reaction= s. Explaining in block-08 better the relation between block option and the avo= idance of fragmentation, also pointing out the variable payload size per pa= cket could help understand the purpose of block much better. Greetings, peter -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: Wednesday 25 April 2012 18:12 To: Stok, Peter van der Cc: core@ietf.org; Zach Shelby Subject: Re: objectives of block-08 draft Hi Peter, the objective of the block options is to enable the transfer of payloads la= rger than can be comfortably sent in one datagram. This is not exactly your objective 1, because CoAP is not meant to be a bul= k data transfer protocol. CoAP is efficient for bulk transfer in the sense= that it does not tax network resources in an unneeded way, but it is not e= fficient in the sense of actually using all the network resources that may = be available (like TCP would do). "Comfortably" implies your objective 3, but is not identical with it. Actually, objective 3 *cannot* be achieved until we have something like ALF= I (http://tools.ietf.org/html/draft-bormann-intarea-alfi -- thanks for prom= pting me to finally write this one up). But Block opens up the selection o= f datagram sizes at CoAP end-points sufficiently that they may be able to a= ddress most of this problem area. Your objective 2 never was one. It just turns out that the design of -bloc= k makes it trivial to achieve, so we decided to take it as well (rarely, bu= t occasionally, simplicity and generality do have synergy). I don't understand these two sentences: > As a consequence of combining these objectives, it is possible to define = the block size. This possibility defeats objective 3, because fragmentation= can occur. Obviously, adaptation layer fragmentation can occur, for the reasons that A= LFI is addressing. Right now there is no way to fix that. (With ALFI, the= re would be.) > Looking at the block protocol, I wonder if it is really better than what = tftp accomplishes with respect to objective 1. I have no idea what some people like about TFTP. Its only redeeming featur= e appears to be that it has existed for a long time, and some of its consid= erable breakage has already been fixed. But if it does solve your problem, you know where to find it. > My suggestion is to leave objective 1 and adapt existing protocols like t= ftp or tcp, if the wish of bulk transport exists. If bulk transport is a significant aspect of your application, you are bett= er off with implementing TCP, which actually can fill all of the network re= sources available. (We might even make CoAP available over TCP at some point in the future, it= certainly has been designed to make that straightforward.) Block has mainly been designed for CoAP applications that mostly need small= payloads, but may need to ship larger objects e.g. during discovery and se= curity setup. Cullen has indicated that he has another interesting use-case where even th= e "small payloads" would benefit from -block; it will be interesting how to= address this without ALFI, but I still think CoAP -block has all that's ne= eded for that. Just don't ship the most recent episode of your favorite TV show over -bloc= k, please. For now, I'll take this as an editorial comment to clarify the objectives o= f CoAP -block in the abstract. 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 esko.dijk@philips.com Thu Apr 26 05:10: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 3E8ED21F8772 for ; Thu, 26 Apr 2012 05:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.879 X-Spam-Level: X-Spam-Status: No, score=-3.879 tagged_above=-999 required=5 tests=[AWL=-0.280, 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 nays9DMwhqdM for ; Thu, 26 Apr 2012 05:10:40 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8424421F8796 for ; Thu, 26 Apr 2012 05:10:40 -0700 (PDT) Received: from mail184-va3-R.bigfish.com (10.7.14.245) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Thu, 26 Apr 2012 12:10:39 +0000 Received: from mail184-va3 (localhost [127.0.0.1]) by mail184-va3-R.bigfish.com (Postfix) with ESMTP id 99B9E20519; Thu, 26 Apr 2012 12:10:38 +0000 (UTC) X-SpamScore: -38 X-BigFish: VPS-38(zz217bL15d6O9251Jc89bh542Mzz1202hzz1033IL8275dhz2dh2a8h668h839hd25h) 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 mail184-va3 (localhost.localdomain [127.0.0.1]) by mail184-va3 (MessageSwitch) id 133544223666183_5324; Thu, 26 Apr 2012 12:10:36 +0000 (UTC) Received: from VA3EHSMHS007.bigfish.com (unknown [10.7.14.245]) by mail184-va3.bigfish.com (Postfix) with ESMTP id 00A29A0157; Thu, 26 Apr 2012 12:10:36 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by VA3EHSMHS007.bigfish.com (10.7.99.17) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 26 Apr 2012 12:10:35 +0000 Received: from 011-DB3MMR1-021.MGDPHG.emi.philips.com (10.128.28.103) by 011-DB3MMR1-007.MGDPHG.emi.philips.com (10.128.28.57) with Microsoft SMTP Server (TLS) id 14.1.355.3; Thu, 26 Apr 2012 13:10:34 +0100 Received: from 011-DB3MPN1-012.MGDPHG.emi.philips.com ([169.254.2.221]) by 011-DB3MMR1-021.MGDPHG.emi.philips.com ([fe80::f066:9203:e7da:3658%11]) with mapi id 14.01.0355.003; Thu, 26 Apr 2012 13:10:34 +0100 From: "Dijk, Esko" To: Carsten Bormann Thread-Topic: [core] draft-ietf-core-coap-09 - Proxying of multicast requests Thread-Index: Ac0ciu7lLw120uPlTeKfdF2mdWqI2AAHQrsAAb8Z1bA= Date: Thu, 26 Apr 2012 12:10:33 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED6180B26D6@011-DB3MPN1-012.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED6180936F2@011-DB3MPN1-013.MGDPHG.emi.philips.com> <7F92E32D-5F89-4EFF-980C-EA56B4960508@tzi.org> In-Reply-To: <7F92E32D-5F89-4EFF-980C-EA56B4960508@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 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: Thu, 26 Apr 2012 12:10:41 -0000 > with a special "virtual" critical option "this was a response to multicas= t"? Maybe the "virtual critical option" explanation is ok, or maybe it need not= be introduced as a concept by mandating that cached multicast responses MU= ST NOT be used to serve unicast requests and vice versa. Should we then mention in the draft that multicast requests address a diffe= rent resource namespace (similar to coaps requests being different from coa= p requests)? Whether this is the case or not is not fully clear to me yet from the text.= Or maybe it should be the same resource namespace with just some added rul= es for when to respond and when not. groeten, Esko -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: Tuesday 17 April 2012 17:40 To: Dijk, Esko Cc: core@ietf.org WG Subject: Re: [core] draft-ietf-core-coap-09 - Proxying of multicast request= s Good point. I think the most important thing to understand here is how a multicast requ= est (there are no multicast responses) uses/modifies our endpoint abstracti= on. Say, I do a 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 differen= tly 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 GET coap://[aaaa::4711]/.well-known/core with a special "virtual" critical option "this was a response to multicast"= ? 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 angelo.castellani@gmail.com Thu Apr 26 05:38: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 B17FE21F8744 for ; Thu, 26 Apr 2012 05:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[AWL=0.081, 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 4XWZkpDeqz9W for ; Thu, 26 Apr 2012 05:38:07 -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 EA4A621F8740 for ; Thu, 26 Apr 2012 05:38:06 -0700 (PDT) Received: by werb10 with SMTP id b10so898384wer.31 for ; Thu, 26 Apr 2012 05:38:05 -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=/TPiEa0TcX3MskzbEbMik3Z4EbSr5LqOsz5ChENB6kU=; b=0ooHf0qezyXkIpuFFHP8Hw+WZ53E7SOML0iPOTrYqQFAO40XANwPnCe1TcbSYhJ21g kM3Hz3Ty96qHE3km/xso16MN6zmHPAK/4y60lDfBjP1nn9pG1AOe+/3CMsQJnCq/XugY DQWzULgpCybrIivPYpdqFxAnhzt2kSoBcCP3+0l95t9933MW4Yi9/uH6Yoj4BsOnfROe AaZGqW1NyYDV1vLolyIeElApvN20zeU0DSzeE5IAld3hQ1thGXEc4gaU6lh1tGZLGRnz EY0bonbXyU+hr+jS2vDHY4WrJ7J6M5qUtx0knSb2kZj2QJefOHTciO4W4csltYA8Ybmq xPLg== Received: by 10.180.89.9 with SMTP id bk9mr16220839wib.11.1335443885834; Thu, 26 Apr 2012 05:38:05 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.214.20 with HTTP; Thu, 26 Apr 2012 05:37:50 -0700 (PDT) In-Reply-To: <7F92E32D-5F89-4EFF-980C-EA56B4960508@tzi.org> References: <031DD135F9160444ABBE3B0C36CED6180936F2@011-DB3MPN1-013.MGDPHG.emi.philips.com> <7F92E32D-5F89-4EFF-980C-EA56B4960508@tzi.org> From: "Angelo P. Castellani" Date: Thu, 26 Apr 2012 14:37:50 +0200 X-Google-Sender-Auth: Y2F9bMsTTXf2W-o-S0COKnloVrQ Message-ID: To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 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: Thu, 26 Apr 2012 12:38:07 -0000 On Tue, Apr 17, 2012 at 17:40, Carsten Bormann wrote: > with a special "virtual" critical option "this was a response to multicast"? How can we reuse this response? case A) We can use it to respond to successive unicast requests. Then the cache updates the older entry (if any). case B) We cannot reuse it to respond to successive unicast requests. Multicast responses should be cached separately. ###### PROBLEMS WITH CASE B In case B there is (at least) one issue, which is briefly discussed in Sec. 4.3.3 of http-mapping I-D (http://tools.ietf.org/html/draft-castellani-core-http-mapping-03#section-4.3.3). I synthetize the problem afterwards. When a new multicast request cames in, generally speaking the proxy couldn't rely only on cached responses to serve client request, since multicast group membership could be dynamic, and the cached representation(s) may represent a subset of the actual group, due to network loss of the previous request/response exchange. The proxy can, in general, effectively reuse cached representation(s) only when it has an updated knowledge of the hosts partecipating to the multicast group, if something is missing the request should be repeated anyway. ####### However if we are satisfied with case A, multicast itself could be a very interesting approach to update the proxy cache for popular resources, and could even be paired with Observe to obtain this in a very efficient way. Best, Angelo From esko.dijk@philips.com Thu Apr 26 06:28: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 A3DD621F8816 for ; Thu, 26 Apr 2012 06:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.361 X-Spam-Level: X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[AWL=1.238, 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 KeeAZGAnaqeX for ; Thu, 26 Apr 2012 06:28:53 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id E147721F8797 for ; Thu, 26 Apr 2012 06:28:52 -0700 (PDT) Received: from mail50-tx2-R.bigfish.com (10.9.14.239) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.23; Thu, 26 Apr 2012 13:28:51 +0000 Received: from mail50-tx2 (localhost [127.0.0.1]) by mail50-tx2-R.bigfish.com (Postfix) with ESMTP id 2F9B3460313; Thu, 26 Apr 2012 13:28:51 +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 mail50-tx2 (localhost.localdomain [127.0.0.1]) by mail50-tx2 (MessageSwitch) id 1335446929402678_15882; Thu, 26 Apr 2012 13:28:49 +0000 (UTC) Received: from TX2EHSMHS018.bigfish.com (unknown [10.9.14.250]) by mail50-tx2.bigfish.com (Postfix) with ESMTP id 523B0A007B; Thu, 26 Apr 2012 13:28:49 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by TX2EHSMHS018.bigfish.com (10.9.99.118) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 26 Apr 2012 13:28:48 +0000 Received: from 011-DB3MPN1-012.MGDPHG.emi.philips.com ([169.254.2.221]) by 011-DB3MMR1-008.MGDPHG.emi.philips.com ([10.128.28.47]) with mapi id 14.01.0355.003; Thu, 26 Apr 2012 14:28:47 +0100 From: "Dijk, Esko" To: Carsten Bormann , Thomas Fossati Thread-Topic: [core] Proxy-URI and coaps scheme Thread-Index: AQHNIX7HpYR9WF0BmU2AFgF93tpmQ5aotz4AgARjESA= Date: Thu, 26 Apr 2012 13:28:47 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED6180B27A2@011-DB3MPN1-012.MGDPHG.emi.philips.com> 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> <4F8D1EA8.6080800@ericsson.com> <68B487AC-7384-4B75-9E1F-32CB8454D2F0@koanlogic.com> <4F92196E.9000701@cs.tcd.ie> <9158B27B-8C40-43A7-B957-961A9E29448B@koanlogic.com> <4F92DCFF.4090301@cs.tcd.ie> <7C11BCD4-3A3A-41AE-B4BC-E374BE737B47@koanlogic.com> <4F1131E2-6997-4F2B-A51A-DD2A8607F9E0@tzi.org> <4F92EEE2.6080801@cs.tcd.ie> <94216E93-4059-4EA2-B4AE-88BF67E74369@koanlogic.com> <49276523-70CC-40F2-9D34 -FF8F3348BA0C@tzi.org> <3A4E7A39-C78D-45A9-97ED-9D48B4107DED@tzi.org> <8731C205-19B1-43A0-B522-CE167C7BD80B@koanlogic.com> <0645900D-3DA0-4324-BE2C-61814F51CC3F@tzi.org> <7C60E917-1E01-40B5-9785-13A11DF87E53@tzi.org> <05A2FA1E-CD1B-479E-90D6-527104CE49CE@tzi.org> In-Reply-To: <05A2FA1E-CD1B-479E-90D6-527104CE49CE@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 WG Subject: Re: [core] Proxy-URI and coaps scheme 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, 26 Apr 2012 13:28:53 -0000 > We know how to make it work, if: > > 1) the intermediary is trusted with the confidentiality and integrity of = the data > 2) the intermediary has enough context to translate the coaps:// into the= security parameters needed. That was exactly the case I thought was missing from Thomas' list. There's = no E2E security then. But that's how I interpret the current spec and it se= ems clear how the combo Proxy-URI/coaps is treated. The proxy simply acts i= n its role of a CoAP client who MUST use "coaps" to execute a request. Secu= rity parameters are the ones predefined for the "coaps" scheme. (This proce= ss is "clear" except for the mentioned lack of details in what a 'coaps' re= quest means - but that's a more general issue not specific to this combo.) But maybe others will see this as option 2. Anyhow, that's what the spec cu= rrently seems to define. Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Car= sten Bormann Sent: Monday 23 April 2012 21:16 To: Thomas Fossati Cc: core WG Subject: Re: [core] Proxy-URI and coaps scheme On Apr 23, 2012, at 20:27, Thomas Fossati wrote: > Just to recap the base question I've posed, that may have been diluted a = bit in the ping-pong with Carsten :-) > > Proxy-URI and coaps scheme, currently an obscure corner of the spec. How= shall we treat the combo ? > > 1) Deprecate because we don't know how to make it work; Wo know how to make it work, if: 1) the intermediary is trusted with the confidentiality and integrity of th= e data 2) the intermediary has enough context to translate the coaps:// into the s= ecurity parameters needed. The problem is that coaps://, like https://, relies on a lot of context. For HTTP, this context was pretty much fixed for a decade (use TLS 1.0 with= out client authentication, authenticate the server's DNS name and verify it= s cert based on the 200 "known-good" root CAs etc.), so people often did no= t notice the problems until they started to use more complex setups such as= OpenID. > 2) leave as an implementation/deployment "detail"; That's what we have with https:// (and what won't work too well with coaps:= //). > 3) define a pass-through facility (ie. CONNECT-like method) to allow E2E = DTLS; Not needed in the use-cases I know -- just use end-to-end DTLS. What would be your use-case where you can't do that? Why is it the job of the CoAP intermediary to forward your packets? > 4) define a comprehensive solution for both trusted and untrusted interme= diary scenarios; Does that exist? > 5) other? Be my guest. 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 matthieu.vial@non.schneider-electric.com Thu Apr 26 06:50: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 9D4B721F86F1; Thu, 26 Apr 2012 06:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.618 X-Spam-Level: X-Spam-Status: No, score=-5.618 tagged_above=-999 required=5 tests=[AWL=0.981, 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 MViFpGBGCPfr; Thu, 26 Apr 2012 06:50:22 -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 0183D21F86D4; Thu, 26 Apr 2012 06:50:21 -0700 (PDT) Received: from ATEUI01.schneider-electric.com ([10.198.14.9]) by mailX03.eud.schneider-electric.com with ESMTP id 2012042615501950-1652 ; Thu, 26 Apr 2012 15:50:19 +0200 In-Reply-To: <031DD135F9160444ABBE3B0C36CED6180B26D6@011-DB3MPN1-012.MGDPHG.emi.philips.com> To: "Dijk, Esko" 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, 26 Apr 2012 15:50:15 +0200 X-MIMETrack: Serialize by Router on ATEUI01.Schneider-Electric.com/T/SVR/Schneider at 26/04/2012 15:51:27, Serialize complete at 26/04/2012 15:51:27, Itemize by SMTP Server on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 26/04/2012 15:50:19, Serialize by Router on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 26/04/2012 15:50:21, Serialize complete at 26/04/2012 15:50:21 Content-Type: text/plain; charset="US-ASCII" Cc: core-bounces@ietf.org, "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: Thu, 26 Apr 2012 13:50:22 -0000 >Should we then mention in the draft that multicast requests address a different resource namespace (similar to coaps requests being different from coap requests)? >Whether this is the case or not is not fully clear to me yet from the text. Or maybe it should be the same resource namespace with just some added rules for when to respond and when not. For me it's clear that the resource trees could be different between unicast and multicast requests. But if we register an AllCoapServers multicast address we could make Carsten's rule applicable to this special adddress GET coap://[AllCoapServers]/.well-known/core == GET coap://[aaaa::4711]/.well-known/core We could also use Location-* options in responses to multicast requests to indicate where is located the corresponding unicast resource. If the multicast address is not AllCoapServers and Location-* options are not recognized we can just say that the response is not cacheable. My 2 cents Matthieu From esko.dijk@philips.com Thu Apr 26 06:59: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 C0D0921F8425 for ; Thu, 26 Apr 2012 06:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.434 X-Spam-Level: X-Spam-Status: No, score=-5.434 tagged_above=-999 required=5 tests=[AWL=1.165, 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 mUpqL0Xri-Ym for ; Thu, 26 Apr 2012 06:59:43 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id E65E821F8573 for ; Thu, 26 Apr 2012 06:59:42 -0700 (PDT) Received: from mail185-tx2-R.bigfish.com (10.9.14.244) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.23; Thu, 26 Apr 2012 13:59:41 +0000 Received: from mail185-tx2 (localhost [127.0.0.1]) by mail185-tx2-R.bigfish.com (Postfix) with ESMTP id 6D59F22010D; Thu, 26 Apr 2012 13:59:41 +0000 (UTC) X-SpamScore: -46 X-BigFish: VPS-46(zz217bL15d6O9251J542M1453M98dKzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h93fhd25h) 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 mail185-tx2 (localhost.localdomain [127.0.0.1]) by mail185-tx2 (MessageSwitch) id 1335448778974600_4615; Thu, 26 Apr 2012 13:59:38 +0000 (UTC) Received: from TX2EHSMHS006.bigfish.com (unknown [10.9.14.248]) by mail185-tx2.bigfish.com (Postfix) with ESMTP id E9751C043D; Thu, 26 Apr 2012 13:59:38 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by TX2EHSMHS006.bigfish.com (10.9.99.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 26 Apr 2012 13:59:38 +0000 Received: from 011-DB3MMR1-020.MGDPHG.emi.philips.com (10.128.28.101) by 011-DB3MMR1-004.MGDPHG.emi.philips.com (10.128.28.54) with Microsoft SMTP Server (TLS) id 14.1.355.3; Thu, 26 Apr 2012 14:59:34 +0100 Received: from 011-DB3MPN1-012.MGDPHG.emi.philips.com ([169.254.2.221]) by 011-DB3MMR1-020.MGDPHG.emi.philips.com ([fe80::65e7:4d4c:4c67:daa9%11]) with mapi id 14.01.0355.003; Thu, 26 Apr 2012 15:02:28 +0100 From: "Dijk, Esko" To: "Angelo P. Castellani" , Carsten Bormann Thread-Topic: [core] draft-ietf-core-coap-09 - Proxying of multicast requests Thread-Index: Ac0ciu7lLw120uPlTeKfdF2mdWqI2AAHQrsAAb5CIwAAA+W1QA== Date: Thu, 26 Apr 2012 13:59:34 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED6180B27C4@011-DB3MPN1-012.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED6180936F2@011-DB3MPN1-013.MGDPHG.emi.philips.com> <7F92E32D-5F89-4EFF-980C-EA56B4960508@tzi.org> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: philips.com 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: Thu, 26 Apr 2012 13:59:43 -0000 U3VwcG9zZSBhIHByb3h5IGhhcyBubyBrbm93bGVkZ2Ugb2YgaG9zdHMgcGFydGljaXBhdGluZyBp biBhIG11bHRpY2FzdCBncm91cC4gVGhlbiBpbmRlZWQgaXQgY2FuJ3QgcmVseSBvbiBpdHMgY2Fj aGVkIG11bHRpY2FzdCByZXNwb25zZXMgYWxvbmUuIEkgd2FzIHRoaW5raW5nIG1vcmUgYWJvdXQg dGhpcyBjYXNlIGFuZCBob3cgaXQgY2FuIHN0aWxsIHVzZSBjYWNoZWQgcmVzcG9uc2VzOg0KDQog MS0gcHJveHkgY2FjaGVzIHByZXZpb3VzIHJlc3BvbnNlcyB0byBhIG11bHRpY2FzdCByZXF1ZXN0 DQogMi0gZm9yIGVhY2ggbmV3IFByb3h5LVVyaSBtdWx0aWNhc3QgcmVxdWVzdCB0aGF0IGNvbWVz IGluLCBpdCBhbHdheXMgc2VuZHMgb3V0IGEgQ29BUCBtdWx0aWNhc3QgcmVxdWVzdCB0byB0aGUg bXVsdGljYXN0IGdyb3VwDQogICBbc2luY2UgdGhlcmUgbWF5IGJlIG5ldyBncm91cCBtZW1iZXJz IHRoYXQgam9pbmVkIG1lYW53aGlsZSBvciBvbmVzIHRoYXQgZGlkIG5vdCBnZXQgdGhlIHByZXZp b3VzIHJlcXVlc3RdDQogMy0gcHJveHkgY2FjaGVzIGFsbCBpbmNvbWluZyByZXNwb25zZXMsIHBv c3NpYmx5IG92ZXJ3cml0aW5nIHRoZSBvbGRlciBzdG9yZWQgcmVzcG9uc2VzDQogNC0gaW52YWxp ZCAvIGV4cGlyZWQgcmVzcG9uc2VzIGFyZSBvZiBjb3Vyc2UgcmVtb3ZlZCBmcm9tIHRoZSBjYWNo ZQ0KIDUtIHByb3h5IHNlbmRzIGFsbCByZXNwb25zZXMgKGJvdGggY2FjaGVkLXN0aWxsLWZyZXNo IGFuZCAnbmV3JykgYmFjayB0byB0aGUgb3JpZ2luYWwgY2xpZW50Lg0KDQpIZXJlIGNhY2hpbmcg aGVscHMgdG8gZ2V0IGEgbW9yZSBjb21wbGV0ZSBzZXQgb2YgcmVzcG9uc2VzOiBpZiBmb3Igc29t ZSByZWFzb24gMjAlIG9mIGdyb3VwIG1lbWJlcnMgZG9uJ3QgcmVjZWl2ZSBhIDJuZCBtdWx0aWNh c3QgcmVxdWVzdDsgdGhlIHByb3h5IG1heSBzdGlsbCBoYXZlIHZhbGlkIGluZm9ybWF0aW9uIGlu IGNhY2hlIGFib3V0IGFsbCBvciBtb3N0IG9mIHRoZXNlIDIwJSBub2RlcyB3aGljaCB3YXMgcmVj ZWl2ZWQgZHVyaW5nIGEgMXN0IG11bHRpY2FzdCBDb0FQIHJlcXVlc3QuDQoNCk5vdGUgaW4gdGhl IGFib3ZlIGNhc2UgYW4gaW1wbGljaXQgYXNzdW1wdGlvbiBpcyB0aGF0IGEgQ29BUCBzZXJ2ZXIs IHdobyBzZW5kcyBvdXQgYSBjYWNoZWFibGUgcmVzcG9uc2UgaW4gcmVzcG9uc2UgdG8gYSBtdWx0 aWNhc3QgcmVxdWVzdCwgZXhwZWN0cy9wcm9taXNlcyB0byBiZSBwYXJ0IG9mIHRoYXQgbXVsdGlj YXN0IGdyb3VwIGZvciBhdCBsZWFzdCB0aGUgdGltZSAoTWF4LUFnZSkgb2YgdGhlIHJlc3BvbnNl LiBUaGF0IGNvdWxkIGJlIHdyaXR0ZW4gZXhwbGljaXRseSAoaWYgd2Ugd2FudCB0byBzYXkgc29t ZXRoaW5nIGFib3V0IGNhY2hpbmcgb2YgcmVzcG9uc2VzIHRvIG11bHRpY2FzdCByZXF1ZXN0cyku DQoNCkFyZW4ndCB0aGVyZSA0IGNhc2VzIGJ5IHRoZSB3YXk/DQoNCiAgICAgICAgfCAgcmV1c2Ug Zm9yIG11bHRpY2FzdCBZL04NCi0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N CnJldXNlICAgfCAgIFkvWSAgICAgICAgIFkvTg0KZm9yICAgICB8DQp1bmljYXN0IHwgICBOL1kg ICAgICAgICBOL04NClkgLyBOICAgfA0KDQpyZWdhcmRzDQpFc2tvDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBhbmdlbG8uY2FzdGVsbGFuaUBnbWFpbC5jb20gW21haWx0bzph bmdlbG8uY2FzdGVsbGFuaUBnbWFpbC5jb21dIE9uIEJlaGFsZiBPZiBBbmdlbG8gUC4gQ2FzdGVs bGFuaQ0KU2VudDogVGh1cnNkYXkgMjYgQXByaWwgMjAxMiAxNDozOA0KVG86IENhcnN0ZW4gQm9y bWFubg0KQ2M6IERpamssIEVza287IGNvcmVAaWV0Zi5vcmcgV0cNClN1YmplY3Q6IFJlOiBbY29y ZV0gZHJhZnQtaWV0Zi1jb3JlLWNvYXAtMDkgLSBQcm94eWluZyBvZiBtdWx0aWNhc3QgcmVxdWVz dHMNCg0KT24gVHVlLCBBcHIgMTcsIDIwMTIgYXQgMTc6NDAsIENhcnN0ZW4gQm9ybWFubiA8Y2Fi b0B0emkub3JnPiB3cm90ZToNCj4gd2l0aCBhIHNwZWNpYWwgInZpcnR1YWwiIGNyaXRpY2FsIG9w dGlvbiAidGhpcyB3YXMgYSByZXNwb25zZSB0byBtdWx0aWNhc3QiPw0KDQpIb3cgY2FuIHdlIHJl dXNlIHRoaXMgcmVzcG9uc2U/DQoNCmNhc2UgQSkgV2UgY2FuIHVzZSBpdCB0byByZXNwb25kIHRv IHN1Y2Nlc3NpdmUgdW5pY2FzdCByZXF1ZXN0cy4NCg0KVGhlbiB0aGUgY2FjaGUgdXBkYXRlcyB0 aGUgb2xkZXIgZW50cnkgKGlmIGFueSkuDQoNCmNhc2UgQikgV2UgY2Fubm90IHJldXNlIGl0IHRv IHJlc3BvbmQgdG8gc3VjY2Vzc2l2ZSB1bmljYXN0IHJlcXVlc3RzLg0KDQpNdWx0aWNhc3QgcmVz cG9uc2VzIHNob3VsZCBiZSBjYWNoZWQgc2VwYXJhdGVseS4NCg0KIyMjIyMjIFBST0JMRU1TIFdJ VEggQ0FTRSBCDQpJbiBjYXNlIEIgdGhlcmUgaXMgKGF0IGxlYXN0KSBvbmUgaXNzdWUsIHdoaWNo IGlzIGJyaWVmbHkgZGlzY3Vzc2VkIGluDQpTZWMuIDQuMy4zIG9mIGh0dHAtbWFwcGluZyBJLUQN CihodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jYXN0ZWxsYW5pLWNvcmUtaHR0cC1t YXBwaW5nLTAzI3NlY3Rpb24tNC4zLjMpLg0KSSBzeW50aGV0aXplIHRoZSBwcm9ibGVtIGFmdGVy d2FyZHMuDQoNCldoZW4gYSBuZXcgbXVsdGljYXN0IHJlcXVlc3QgY2FtZXMgaW4sIGdlbmVyYWxs eSBzcGVha2luZyB0aGUgcHJveHkNCmNvdWxkbid0IHJlbHkgb25seSBvbiBjYWNoZWQgcmVzcG9u c2VzIHRvIHNlcnZlIGNsaWVudCByZXF1ZXN0LCBzaW5jZQ0KbXVsdGljYXN0IGdyb3VwIG1lbWJl cnNoaXAgY291bGQgYmUgZHluYW1pYywgYW5kIHRoZSBjYWNoZWQNCnJlcHJlc2VudGF0aW9uKHMp IG1heSByZXByZXNlbnQgYSBzdWJzZXQgb2YgdGhlIGFjdHVhbCBncm91cCwgZHVlIHRvDQpuZXR3 b3JrIGxvc3Mgb2YgdGhlIHByZXZpb3VzIHJlcXVlc3QvcmVzcG9uc2UgZXhjaGFuZ2UuDQoNClRo ZSBwcm94eSBjYW4sIGluIGdlbmVyYWwsIGVmZmVjdGl2ZWx5IHJldXNlIGNhY2hlZCByZXByZXNl bnRhdGlvbihzKQ0Kb25seSB3aGVuIGl0IGhhcyBhbiB1cGRhdGVkIGtub3dsZWRnZSBvZiB0aGUg aG9zdHMgcGFydGVjaXBhdGluZyB0bw0KdGhlIG11bHRpY2FzdCBncm91cCwgaWYgc29tZXRoaW5n IGlzIG1pc3NpbmcgdGhlIHJlcXVlc3Qgc2hvdWxkIGJlDQpyZXBlYXRlZCBhbnl3YXkuDQojIyMj IyMjDQoNCkhvd2V2ZXIgaWYgd2UgYXJlIHNhdGlzZmllZCB3aXRoIGNhc2UgQSwgbXVsdGljYXN0 IGl0c2VsZiBjb3VsZCBiZSBhDQp2ZXJ5IGludGVyZXN0aW5nIGFwcHJvYWNoIHRvIHVwZGF0ZSB0 aGUgcHJveHkgY2FjaGUgZm9yIHBvcHVsYXINCnJlc291cmNlcywgYW5kIGNvdWxkIGV2ZW4gYmUg cGFpcmVkIHdpdGggT2JzZXJ2ZSB0byBvYnRhaW4gdGhpcyBpbiBhDQp2ZXJ5IGVmZmljaWVudCB3 YXkuDQoNCkJlc3QsDQpBbmdlbG8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N ClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdlIG1heSBiZSBjb25maWRl bnRpYWwgYW5kIGxlZ2FsbHkgcHJvdGVjdGVkIHVuZGVyIGFwcGxpY2FibGUgbGF3LiBUaGUgbWVz c2FnZSBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNzZWUocykuIElmIHlvdSBhcmUg bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQg YW55IHVzZSwgZm9yd2FyZGluZywgZGlzc2VtaW5hdGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRo aXMgbWVzc2FnZSBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElm IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBz ZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCBhbmQgZGVzdHJveSBhbGwgY29waWVzIG9mIHRoZSBvcmln aW5hbCBtZXNzYWdlLg0K From hartke@tzi.org Thu Apr 26 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 280C121F86B9 for ; Thu, 26 Apr 2012 08:06: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=[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 XQVGX9t0v-gQ for ; Thu, 26 Apr 2012 08:06: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 4C3DB21F86B8 for ; Thu, 26 Apr 2012 08:06: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 q3QF6geT016657 for ; Thu, 26 Apr 2012 17:06:42 +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 AE1BBC5E for ; Thu, 26 Apr 2012 17:06:41 +0200 (CEST) Received: by dady13 with SMTP id y13so2605165dad.27 for ; Thu, 26 Apr 2012 08:06:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.195.163 with SMTP id if3mr15975893pbc.127.1335452799877; Thu, 26 Apr 2012 08:06:39 -0700 (PDT) Received: by 10.68.23.37 with HTTP; Thu, 26 Apr 2012 08:06:39 -0700 (PDT) In-Reply-To: <031DD135F9160444ABBE3B0C36CED6180B27C4@011-DB3MPN1-012.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED6180936F2@011-DB3MPN1-013.MGDPHG.emi.philips.com> <7F92E32D-5F89-4EFF-980C-EA56B4960508@tzi.org> <031DD135F9160444ABBE3B0C36CED6180B27C4@011-DB3MPN1-012.MGDPHG.emi.philips.com> Date: Thu, 26 Apr 2012 17:06:39 +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-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: Thu, 26 Apr 2012 15:06:50 -0000 Esko wrote: > =A04- invalid / expired responses are of course removed from the cache If a response has an etag, the cache can attempt to revalidate an expired response instead of immediately removing it. How would revalidation work with multicast? Etags are resource-local identifiers, and the etag generated by one origin server might identify a completely different resource state on another server. > Aren't there 4 cases by the way? > > | reuse for multicast Y/N > --------+---------------------------- > reuse | Y/Y Y/N > for | > unicast | N/Y N/N > Y / N | Yes. So, combining what Esko and Matthieu say, what about something along the following lines: * The responses received in reply to a GET request to a multicast group can be used to satisfy a subsequent request on the same request URI, but can not be validated using the ETag option. * Before the stored responses can be used to satisfy the subsequent request, the proxy always makes a new request to the multicast group and updates the cache with the received responses. * A server MAY include a Content-Location option in a response to a GET request. Similar to the HTTP Content-Location header field, the option indicates that if one were to perform a GET on this URI at the time of this message's generation, then a 2.05 (Content) response would contain the same representation that is enclosed as payload in this message. * If a response contains a Content-Location option, then a cache MAY use the response to satisfy a subsequent request on the Content-Location URI in addition to the request URI. (This is different from HTTP.) * If a response contains both an ETag option and a Content-Location option, then a cache can revalidate the response by making a GET request on the Content-Location URI. The more the use of multicast modifies the normal rules of coap though, the more I'd like to see everything multicast-related in a different document together rather than sprinkled all over the core document. Klaus From angelo.castellani@gmail.com Thu Apr 26 08:14: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 9572F21E804E for ; Thu, 26 Apr 2012 08:14:26 -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 5NRLRQflvAkd for ; Thu, 26 Apr 2012 08:14:26 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 13EE421E8049 for ; Thu, 26 Apr 2012 08:14:25 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so1154335vcb.31 for ; Thu, 26 Apr 2012 08:14:25 -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=Hr1xNOV2z9WTa1UgHdffMzX6CDPcqjsUySHlASXuUI8=; b=GXOX2dmyAsUc8cARw9594EJhB71y2d/eT17k8fa6v4deNHkpUxltYAbaxWTt0PUIom EuRRvo4E7feohGlE3fihW76Gzimott4SHcYVaOivXC4py2mwuDoCuSpTWCmr8UWiEL4K /T1ARhFmzpobcgI3fja3KIzoVEc4VdEyxYzdJL1FTCJUff7S1u1z8jwqAOuExxkmfiW+ tXuDcxfP6FclMURDvcExhL3q9WXhmGj683QAm0vdjzq2W3dD1jsasWwiftTRUGIo0V5A rsGbzeK58wI7rIezZ5z9vVy9/yN3cUB5aiHdBH+6R9MCMkt1ilp/YMaf7n/c2KBS8Hq6 e3CQ== Received: by 10.52.91.72 with SMTP id cc8mr6729077vdb.17.1335453265587; Thu, 26 Apr 2012 08:14:25 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.220.158.7 with HTTP; Thu, 26 Apr 2012 08:14:10 -0700 (PDT) In-Reply-To: References: <031DD135F9160444ABBE3B0C36CED6180936F2@011-DB3MPN1-013.MGDPHG.emi.philips.com> <7F92E32D-5F89-4EFF-980C-EA56B4960508@tzi.org> <031DD135F9160444ABBE3B0C36CED6180B27C4@011-DB3MPN1-012.MGDPHG.emi.philips.com> From: "Angelo P. Castellani" Date: Thu, 26 Apr 2012 17:14:10 +0200 X-Google-Sender-Auth: EPfOK4IswzEYcQB3RGOu1mkDs_E Message-ID: To: Klaus Hartke Content-Type: text/plain; charset=UTF-8 Cc: core@ietf.org 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: Thu, 26 Apr 2012 15:14:26 -0000 On Thu, Apr 26, 2012 at 17:06, Klaus Hartke wrote: > * Before the stored responses can be used to satisfy the subsequent > request, the proxy always makes a new request to the multicast group > and updates the cache with the received responses. In this way, when network loss is low enough, there is no benefit at all in having that cache. As said in my previous message, the only "real" use-case in caching multicast responses is to serve the responses in unicast requests. Best, Angelo From cabo@tzi.org Thu Apr 26 08:37: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 7D9A121E80E0 for ; Thu, 26 Apr 2012 08:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.011 X-Spam-Level: X-Spam-Status: No, score=-106.011 tagged_above=-999 required=5 tests=[AWL=0.238, 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 MKIy96AWP1dE for ; Thu, 26 Apr 2012 08:37: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 B128C21E80DF for ; Thu, 26 Apr 2012 08:37:29 -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 q3QFbMjW004527 for ; Thu, 26 Apr 2012 17:37: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 711DEC96; Thu, 26 Apr 2012 17:37: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, 26 Apr 2012 17:37:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <031DD135F9160444ABBE3B0C36CED6180936F2@011-DB3MPN1-013.MGDPHG.emi.philips.com> <7F92E32D-5F89-4EFF-980C-EA56B4960508@tzi.org> <031DD135F9160444ABBE3B0C36CED6180B27C4@011-DB3MPN1-012.MGDPHG.emi.philips.com> To: Klaus Hartke X-Mailer: Apple Mail (2.1257) Cc: core@ietf.org 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: Thu, 26 Apr 2012 15:37:30 -0000 On Apr 26, 2012, at 17:06, Klaus Hartke wrote: > can not be validated using the ETag option That would be a serious loss. I think we have to keep in mind why we are using multicast: Do discover servers that have useful content. Once we have discovered them, we might want to switch to unicast to = interact with them in more detail. It should be possible to use = previous content received via multicast as a basis of such a unicast = relationship. So, with respect to the "virtual option" = this-was-obtained-via-a-multicast-request: This should not cause a new document space or a new namespace for Etags = (like the difference between http:// and https:// causes, which I think = simply is a bug of HTTP that we don't need to import into CoAP). I should be able to use an Etag received via a unicast response to a = multicast request, in order to validate the representation in a unicast = request to the same resource. Gr=FC=DFe, Carsten From zach@sensinode.com Thu Apr 26 09:08: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 634CF21E809C for ; Thu, 26 Apr 2012 09:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.479 X-Spam-Level: X-Spam-Status: No, score=-3.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 hLSvCRbiMi5Z for ; Thu, 26 Apr 2012 09:08:52 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 982C721E8036 for ; Thu, 26 Apr 2012 09:08:50 -0700 (PDT) Received: from [192.168.1.100] (188-67-166-73.bb.dnainternet.fi [188.67.166.73]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q3QG8kNe004484; Thu, 26 Apr 2012 19:08:46 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Thu, 26 Apr 2012 19:08:45 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <031DD135F9160444ABBE3B0C36CED6180936F2@011-DB3MPN1-013.MGDPHG.emi.philips.com> <7F92E32D-5F89-4EFF-980C-EA56B4960508@tzi.org> <031DD135F9160444ABBE3B0C36CED6180B27C4@011-DB3MPN1-012.MGDPHG.emi.philips.com> To: Carsten Bormann X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org, Klaus Hartke 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: Thu, 26 Apr 2012 16:08:52 -0000 On Apr 26, 2012, at 6:37 PM, Carsten Bormann wrote: >> can not be validated using the ETag option >=20 > That would be a serious loss. >=20 > I think we have to keep in mind why we are using multicast: > Do discover servers that have useful content. > Once we have discovered them, we might want to switch to unicast to = interact with them in more detail. It should be possible to use = previous content received via multicast as a basis of such a unicast = relationship. >=20 > So, with respect to the "virtual option" = this-was-obtained-via-a-multicast-request: > This should not cause a new document space or a new namespace for = Etags (like the difference between http:// and https:// causes, which I = think simply is a bug of HTTP that we don't need to import into CoAP). > I should be able to use an Etag received via a unicast response to a = multicast request, in order to validate the representation in a unicast = request to the same resource. +1 --=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 hartke@tzi.org Thu Apr 26 09:11: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 C1E8211E809C for ; Thu, 26 Apr 2012 09:11: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=[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 finIs+ba5NVq for ; Thu, 26 Apr 2012 09:11:03 -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 EF8C711E809A for ; Thu, 26 Apr 2012 09:11:02 -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 q3QGAuGD023264 for ; Thu, 26 Apr 2012 18:10:56 +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 CACF8CC0 for ; Thu, 26 Apr 2012 18:10:55 +0200 (CEST) Received: by pbbrp16 with SMTP id rp16so3017688pbb.31 for ; Thu, 26 Apr 2012 09:10:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.189.229 with SMTP id gl5mr10761452pbc.148.1335456653932; Thu, 26 Apr 2012 09:10:53 -0700 (PDT) Received: by 10.68.23.37 with HTTP; Thu, 26 Apr 2012 09:10:53 -0700 (PDT) In-Reply-To: References: <031DD135F9160444ABBE3B0C36CED6180936F2@011-DB3MPN1-013.MGDPHG.emi.philips.com> <7F92E32D-5F89-4EFF-980C-EA56B4960508@tzi.org> <031DD135F9160444ABBE3B0C36CED6180B27C4@011-DB3MPN1-012.MGDPHG.emi.philips.com> Date: Thu, 26 Apr 2012 18:10:53 +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 - 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: Thu, 26 Apr 2012 16:11:03 -0000 Carsten Bormann wrote: > I should be able to use an Etag received via a unicast response to a multicast request, in order to validate the representation in a unicast request to the same resource. Yes. That's what I tried to enable with the Content-Location option, because you need the unicast request URI to validate the response. But maybe the option is not really needed... Second attempt: * The responses received in reply to a GET request to a multicast group MAY be used to satisfy a subsequent request on the same request URI. * When a new Proxy-Uri multicast request comes in, the proxy always makes a new request to the multicast group and MAY update the cache with the received responses. * A response received in reply to a GET request to a multicast group MAY also be used to satisfy a subsequent request on the unicast request URI. The unicast request URI is obtained by replacing the authority part of the request URI with the transport layer source address of the response message. * A cache MAY revalidate a response by making a GET request on the unicast request URI. * A GET request to a multicast group MUST NOT contain an ETag option. Klaus From fluffy@iii.ca Thu Apr 26 16:11: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 EB7DB21F86F9 for ; Thu, 26 Apr 2012 16:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 1Utm7MvKW54o for ; Thu, 26 Apr 2012 16:11:44 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 672D021F86F5 for ; Thu, 26 Apr 2012 16:11:44 -0700 (PDT) Received: from [192.168.4.106] (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 993A222E253; Thu, 26 Apr 2012 19:11:37 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Thu, 26 Apr 2012 15:30:47 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <98B06B5C-91B6-468D-A7E8-A94F6E645BB6@iii.ca> 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> <4F8D1EA8.6080800@ericsson.com> <68B487AC-7384-4B75-9E1F-32CB8454D2F0@koanlogic.com> <4F92196E.9000701@cs.tcd.ie> <9158B27B-8C40-43A7-B957-961A9E29448B@koanlogic.com> <4F92DCFF.4090301@cs.tcd.ie> <7C11BCD4-3A3A-41AE-B4BC-E374BE737B47@koanlogic.com> <4F1131E2-6997-4F2B-A51A-DD2A8607F9E0@tzi.org> <4F92EEE2.6080801@cs.tcd.ie> <94216E93-4059-4EA2-B4AE-88BF67E74369@koanlogic.com> <49276523-70CC-40F2-9D34 -FF8F3348BA0C@tzi.org> <3A4E7A39-C78D-45A9-97ED-9D48B4107DED@tzi.org> <8731C205-19B1-43A0-B522-CE167C7BD80B@koanlogic.com> <0645900D-3DA0-4324-BE2C-61814F51CC3F@tzi.org> <7C60E917-1E01-40B5-9785-13A11DF87E53@tzi.org> To: Thomas Fossati X-Mailer: Apple Mail (2.1257) Cc: core WG Subject: Re: [core] Proxy-URI and coaps scheme 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, 26 Apr 2012 23:11:45 -0000 On Apr 23, 2012, at 12:27 , Thomas Fossati wrote: > Just to recap the base question I've posed, that may have been diluted = a bit in the ping-pong with Carsten :-) >=20 > Proxy-URI and coaps scheme, currently an obscure corner of the spec. = How shall we treat the combo ? >=20 > 1) Deprecate because we don't know how to make it work; > 2) leave as an implementation/deployment "detail"; > 3) define a pass-through facility (ie. CONNECT-like method) to allow = E2E DTLS; > 4) define a comprehensive solution for both trusted and untrusted = intermediary scenarios; > 5) other? > _______________________________________________ I don't want 2 and don't want 3.=20 From cabo@tzi.org Thu Apr 26 23:25: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 38A0221F8724 for ; Thu, 26 Apr 2012 23:25: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 a6Gjw2O328jg for ; Thu, 26 Apr 2012 23:25: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 6598421F8718 for ; Thu, 26 Apr 2012 23:25: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 q3R6P6eu015049; Fri, 27 Apr 2012 08:25:06 +0200 (CEST) Received: from [192.168.217.105] (p5B3E6293.dip.t-dialin.net [91.62.98.147]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 2E355DE2; Fri, 27 Apr 2012 08:25: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: <98B06B5C-91B6-468D-A7E8-A94F6E645BB6@iii.ca> Date: Fri, 27 Apr 2012 08:25:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: 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> <4F8D1EA8.6080800@ericsson.com> <68B487AC-7384-4B75-9E1F-32CB8454D2F0@koanlogic.com> <4F92196E.9000701@cs.tcd.ie> <9158B27B-8C40-43A7-B957-961A9E29448B@koanlogic.com> <4F92DCFF.4090301@cs.tcd.ie> <7C11BCD4-3A3A-41AE-B4BC-E374BE737B47@koanlogic.com> <4F1131E2-6997-4F2B-A51A-DD2A8607F9E0@tzi.org> <4F92EEE2.6080801@cs.tcd.ie> <94216E93-4059-4EA2-B4AE-88BF67E74369@koanlogic.com> <49276523-70CC-40F2-9D34 -FF8F3348BA0C@tzi.org> <3A4E7A39-C78D-45A9-97ED-9D48B4107DED@tzi.org> <8731C205-19B1-43A0-B522-CE167C7BD80B@koanlogic.com> <0645900D-3DA0-4324-BE2C-61814F51CC3F@tzi.org> <7C60E917-1E01-40B5-9785-13A11DF87E53@tzi.org> <98B06B5C-91B6-468D-A7E8-A94F6E645BB6@iii.ca> To: Cullen Jennings X-Mailer: Apple Mail (2.1257) Cc: core WG Subject: Re: [core] Proxy-URI and coaps scheme 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, 27 Apr 2012 06:25:16 -0000 On Apr 26, 2012, at 23:30, Cullen Jennings wrote: >=20 > On Apr 23, 2012, at 12:27 , Thomas Fossati wrote: >=20 >> Just to recap the base question I've posed, that may have been = diluted a bit in the ping-pong with Carsten :-) >>=20 >> Proxy-URI and coaps scheme, currently an obscure corner of the spec. = How shall we treat the combo ? >>=20 >> 1) Deprecate because we don't know how to make it work; >> 2) leave as an implementation/deployment "detail"; >> 3) define a pass-through facility (ie. CONNECT-like method) to allow = E2E DTLS; >> 4) define a comprehensive solution for both trusted and untrusted = intermediary scenarios; >> 5) other? >> _______________________________________________ >=20 > I don't want 2 well, obviously. > and don't want 3.=20 Do you mean you don't want a 3 at all (I proposed one straw man way of = doing this in http://tools.ietf.org/html/draft-bormann-coap-misc-15#section-5) or that = you don't want this to be the only outcome? I'm leaning towards: -- 1 for now, and -- start a separate work item on 4 (with some limits on = "comprehensive"), and -- maybe also further investigate 3. Gr=FC=DFe, Carsten From peter.van.der.stok@philips.com Thu Apr 26 23:26: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 174EA21F86BA for ; Thu, 26 Apr 2012 23:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=-1.810, BAYES_20=-0.74, FRT_STOCK1=3.988, 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 20MY62YHKQNW for ; Thu, 26 Apr 2012 23:26:31 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id EFFCA21F8618 for ; Thu, 26 Apr 2012 23:26:30 -0700 (PDT) Received: from mail109-tx2-R.bigfish.com (10.9.14.248) by TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id 14.1.225.23; Fri, 27 Apr 2012 06:26:28 +0000 Received: from mail109-tx2 (localhost [127.0.0.1]) by mail109-tx2-R.bigfish.com (Postfix) with ESMTP id 887284C012B for ; Fri, 27 Apr 2012 06:26:28 +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 mail109-tx2 (localhost.localdomain [127.0.0.1]) by mail109-tx2 (MessageSwitch) id 133550798649687_5448; Fri, 27 Apr 2012 06:26:26 +0000 (UTC) Received: from TX2EHSMHS025.bigfish.com (unknown [10.9.14.252]) by mail109-tx2.bigfish.com (Postfix) with ESMTP id 076562C008D for ; Fri, 27 Apr 2012 06:26:26 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by TX2EHSMHS025.bigfish.com (10.9.99.125) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 27 Apr 2012 06:26:25 +0000 Received: from 011-DB3MMR1-019.MGDPHG.emi.philips.com (10.128.28.106) by 011-DB3MMR1-002.MGDPHG.emi.philips.com (10.128.28.52) with Microsoft SMTP Server (TLS) id 14.1.355.3; Fri, 27 Apr 2012 07:29:17 +0100 Received: from 011-DB3MPN1-062.MGDPHG.emi.philips.com ([169.254.2.41]) by 011-DB3MMR1-019.MGDPHG.emi.philips.com ([10.128.28.106]) with mapi id 14.01.0355.003; Fri, 27 Apr 2012 07:29:17 +0100 From: "Stok, Peter van der" To: "core@ietf.org" Thread-Topic: coap-09 proxy typos Thread-Index: Ac0kPquVzkqf9AS3QReeR+v3okkt6A== Date: Fri, 27 Apr 2012 06:26:23 +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_A31CB84F6F0BFC449C6807DF752A715B06656D011DB3MPN1062MGDP_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: [core] coap-09 proxy typos 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, 27 Apr 2012 06:26:32 -0000 --_000_A31CB84F6F0BFC449C6807DF752A715B06656D011DB3MPN1062MGDP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In section 5.7 paragraph 2 mentions that coap requests to proxies specify t= he request URI in a different way. I assume that "reverse proxies excepted" needs to be added. Section 5.10.8 first line: indicates replace with indicate. Peter Peter van der Stok Kamperfoelie 8 5708 DM Helmond, The Netherlands phone +31 492 474673 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_A31CB84F6F0BFC449C6807DF752A715B06656D011DB3MPN1062MGDP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In section 5.7 paragraph 2 mentions that coap reques= ts to proxies specify the request URI in a different way.

I assume that “reverse proxies excepted”= needs to be added.

 

Section 5.10.8 first line: indicates replace with in= dicate.

 

 

Peter

 

Peter van der Stok

Kamperfoelie 8

5708 DM Helmond, The Netherlands

phone +31 492 474673      &= nbsp;    

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_A31CB84F6F0BFC449C6807DF752A715B06656D011DB3MPN1062MGDP_-- From zach@sensinode.com Thu Apr 26 23:37: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 6EF8221F8741 for ; Thu, 26 Apr 2012 23:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 xxOI5ygC25KU for ; Thu, 26 Apr 2012 23:37:09 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 364E321F8740 for ; Thu, 26 Apr 2012 23:37:08 -0700 (PDT) Received: from [192.168.1.100] (188-67-166-73.bb.dnainternet.fi [188.67.166.73]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q3R6b4JO006247; Fri, 27 Apr 2012 09:37:05 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Fri, 27 Apr 2012 09:37:04 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <474633E2-983D-4B7E-B8F8-9571C84DF2B8@sensinode.com> 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> <4F8D1EA8.6080800@ericsson.com> <68B487AC-7384-4B75-9E1F-32CB8454D2F0@koanlogic.com> <4F92196E.9000701@cs.tcd.ie> <9158B27B-8C40-43A7-B957-961A9E29448B@koanlogic.com> <4F92DCFF.4090301@cs.tcd.ie> <7C11BCD4-3A3A-41AE-B4BC-E374BE737B47@koanlogic.com> <4F1131E2-6997-4F2B-A51A-DD2A8607F9E0@tzi.org> <4F92EEE2.6080801@cs.tcd.ie> <94216E93-4059-4EA2-B4AE-88BF67E74369@koanlogic.com> <49276523-70CC-40F2-9D3! 4 -FF8F3348BA0C@tzi.org> <3A4E7A39-C78D-45A9-97ED-9D48B4107DED@tzi.org> <8731C205-19B1-43A0-B522-CE167C7BD80B@koanlogic.com> <0645900D-3DA0-4324-BE2C-61814F51CC3F@tzi.org> <7C60E917-1E01-40B5-9785-13A11DF87E53@tzi.org> <98B06B5C-91B6-468D-A7E8-A94F6E645BB6@iii.ca> To: Carsten Bormann X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] Proxy-URI and coaps scheme 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, 27 Apr 2012 06:37:10 -0000 On Apr 27, 2012, at 9:25 AM, Carsten Bormann wrote: > On Apr 26, 2012, at 23:30, Cullen Jennings wrote: >=20 >>=20 >> On Apr 23, 2012, at 12:27 , Thomas Fossati wrote: >>=20 >>> Just to recap the base question I've posed, that may have been = diluted a bit in the ping-pong with Carsten :-) >>>=20 >>> Proxy-URI and coaps scheme, currently an obscure corner of the spec. = How shall we treat the combo ? >>>=20 >>> 1) Deprecate because we don't know how to make it work; >>> 2) leave as an implementation/deployment "detail"; >>> 3) define a pass-through facility (ie. CONNECT-like method) to allow = E2E DTLS; >>> 4) define a comprehensive solution for both trusted and untrusted = intermediary scenarios; >>> 5) other? >>> _______________________________________________ >>=20 >> I don't want 2 >=20 > well, obviously. >=20 >> and don't want 3.=20 >=20 > Do you mean you don't want a 3 at all (I proposed one straw man way of = doing this in > http://tools.ietf.org/html/draft-bormann-coap-misc-15#section-5) or = that you don't want this to be the only outcome? At least personally I don't find 3 to be useful. There would be good = reasons for enabling end-to-end TLS security work across a CoAP-HTTP = proxy, but I think that falls under 4 in Thomas's list. > I'm leaning towards: > -- 1 for now, and Agreed. > -- start a separate work item on 4 (with some limits on = "comprehensive"), and Smells like someone needs to start such a draft. > -- maybe also further investigate 3. If we really see a need. Zach --=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 trac+core@trac.tools.ietf.org Thu Apr 26 23:49: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 8A7A321F873C for ; Thu, 26 Apr 2012 23:49:38 -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 6EsAkkSTJa9x for ; Thu, 26 Apr 2012 23:49: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 14CBC21F8737 for ; Thu, 26 Apr 2012 23:49:37 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SNezY-0000eS-Rt; Fri, 27 Apr 2012 02:49: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, 27 Apr 2012 06:49:19 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/226 Message-ID: <051.6d1a8fefd2f87314224527d7678c8be2@trac.tools.ietf.org> X-Trac-Ticket-ID: 226 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: <20120427064938.14CBC21F8737@ietfa.amsl.com> Resent-Date: Thu, 26 Apr 2012 23:49:37 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #226: Clarify which language addresses intermediaries in general vs. forward proxies specifically 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, 27 Apr 2012 06:49:38 -0000 #226: Clarify which language addresses intermediaries in general vs. forward proxies specifically Peter van der Stok notes: In section 5.7 paragraph 2 mentions that coap requests to proxies specify the request URI in a different way. I assume that “reverse proxies excepted” needs to be added. -> We need to make a run through the document to find which language is specific e.g. to the use of Proxy-Uri, which language addresses intermediaries in general (and maybe differentiate between CoAP-CoAP intermediaries and protocol mappers), and where specifically CoAP forward proxies (in the sense Fielding uses for proxies) are meant. This is mostly editorial work, but may raise technical points. -- -----------------------------+------------------------------------ Reporter: cabo@… | Owner: draft-ietf-core-coap@… Type: other technical | Status: new Priority: major | Milestone: post-WGLC-1 Component: coap | Version: coap-09 Severity: In WG Last Call | Keywords: -----------------------------+------------------------------------ Ticket URL: core From cabo@tzi.org Thu Apr 26 23:52: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 89D0221F86E2 for ; Thu, 26 Apr 2012 23:52:48 -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 fmS9ReYZlbNo for ; Thu, 26 Apr 2012 23:52:48 -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 9E2A021F86DA for ; Thu, 26 Apr 2012 23:52:47 -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 q3R6qe7r025951; Fri, 27 Apr 2012 08:52:40 +0200 (CEST) Received: from [192.168.217.105] (p5B3E6293.dip.t-dialin.net [91.62.98.147]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 19222DFB; Fri, 27 Apr 2012 08:52:40 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: Date: Fri, 27 Apr 2012 08:52:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Stok, Peter van der" X-Mailer: Apple Mail (2.1257) Cc: "core@ietf.org" Subject: Re: [core] coap-09 proxy typos 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, 27 Apr 2012 06:52:49 -0000 On Apr 27, 2012, at 08:26, Stok, Peter van der wrote: > In section 5.7 paragraph 2 mentions that coap requests to proxies = specify the request URI in a different way. > I assume that =93reverse proxies excepted=94 needs to be added. Captured as #226. > Section 5.10.8 first line: indicates replace with indicate. Fixed right in SVN [612]. Thanks! Gr=FC=DFe, Carsten From tho@koanlogic.com Thu Apr 26 23:54: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 4D1EE21F8710 for ; Thu, 26 Apr 2012 23:54:06 -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 QZv6Pda8kyyE for ; Thu, 26 Apr 2012 23:54:05 -0700 (PDT) Received: from gonzo.koanlogic.com (koanlogic.com [64.251.31.111]) by ietfa.amsl.com (Postfix) with ESMTP id 9E58921F870E for ; Thu, 26 Apr 2012 23:54:05 -0700 (PDT) Received: from chello084112045229.2.11.vie.surfer.at ([84.112.45.229]:49676 helo=[172.16.101.93]) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1SNf3y-0002cD-7m; Fri, 27 Apr 2012 02:54:01 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: <474633E2-983D-4B7E-B8F8-9571C84DF2B8@sensinode.com> Date: Fri, 27 Apr 2012 08:53:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3F7D3C25-90F7-4196-97AB-1196765ECA4C@koanlogic.com> 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> <4F8D1EA8.6080800@ericsson.com> <68B487AC-7384-4B75-9E1F-32CB8454D2F0@koanlogic.com> <4F92196E.9000701@cs.tcd.ie> <9158B27B-8C40-43A7-B957-961A9E29448B@koanlogic.com> <4F92DCFF.4090301@cs.tcd.ie> <7C11BCD4-3A3A-41AE-B4BC-E374BE737B47@koanlogic.com> <4F1131E2-6997-4F2B-A51A-DD2A8607F9E0@tzi.org> <4F92EEE2.6080801@cs.tcd.ie> <94216E93-4059-4EA2-B4AE-88BF67E74369@koanlogic.com> <49276523-70CC-40F2-9D3! 4 -FF8F3348BA0C@tzi.org> <3A4E7A39-C78D-45A9-97ED-9D48B4107DED@tzi.org> <8731C205-19B1-43A0-B522-CE167C7BD80B@koanlogic.com> <0645900D-3DA0-4324-BE2C-61814F51CC3F@tzi.org> <7C60E917-1E01-40B5-9785-13A11DF87E53@tzi.org> <98B06B5C-91B6-468D-A7E8-A94F6E645BB6@iii.ca> <474633E2-983D-4B7E-B8F8-9571C84DF2B8@sensinode.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] Proxy-URI and coaps scheme 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, 27 Apr 2012 06:54:06 -0000 On Apr 27, 2012, at 8:37 AM, Zach Shelby wrote: >> -- start a separate work item on 4 (with some limits on = "comprehensive"), and >=20 > Smells like someone needs to start such a draft. Well, I have this embryonic idea about pushing a challenge-response = scheme into the base request-response messaging model of CoAP. = Unfortunately I have yet to find the time to sketch a proposal. Anyone who finds it as a sound approach, and would like to do some = brainstorming, is definitely welcome.= From esko.dijk@philips.com Fri Apr 27 00:05: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 45B2121F8712 for ; Fri, 27 Apr 2012 00:05: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=[AWL=-0.400, 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 xXDBvB1v6qw6 for ; Fri, 27 Apr 2012 00:05:10 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7F421F8711 for ; Fri, 27 Apr 2012 00:05:08 -0700 (PDT) Received: from mail152-va3-R.bigfish.com (10.7.14.242) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Fri, 27 Apr 2012 07:05:06 +0000 Received: from mail152-va3 (localhost [127.0.0.1]) by mail152-va3-R.bigfish.com (Postfix) with ESMTP id 74F6CA026E; Fri, 27 Apr 2012 07:05:05 +0000 (UTC) X-SpamScore: -41 X-BigFish: VPS-41(zz217bL15d6O9251J542M98dKzz1202hzz1033IL8275dhz2dh2a8h668h839h944hd25h) 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 mail152-va3 (localhost.localdomain [127.0.0.1]) by mail152-va3 (MessageSwitch) id 1335510303602998_28170; Fri, 27 Apr 2012 07:05:03 +0000 (UTC) Received: from VA3EHSMHS006.bigfish.com (unknown [10.7.14.236]) by mail152-va3.bigfish.com (Postfix) with ESMTP id 83E6242048B; Fri, 27 Apr 2012 07:05:03 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by VA3EHSMHS006.bigfish.com (10.7.99.16) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 27 Apr 2012 07:05:02 +0000 Received: from 011-DB3MMR1-018.MGDPHG.emi.philips.com (10.128.28.104) by 011-DB3MMR1-006.MGDPHG.emi.philips.com (10.128.28.56) with Microsoft SMTP Server (TLS) id 14.1.355.3; Fri, 27 Apr 2012 08:05:02 +0100 Received: from 011-DB3MPN1-012.MGDPHG.emi.philips.com ([169.254.2.221]) by 011-DB3MMR1-018.MGDPHG.emi.philips.com ([10.128.28.104]) with mapi id 14.01.0355.003; Fri, 27 Apr 2012 08:05:02 +0100 From: "Dijk, Esko" To: Klaus Hartke , "core@ietf.org" Thread-Topic: [core] draft-ietf-core-coap-09 - Proxying of multicast requests Thread-Index: Ac0ciu7lLw120uPlTeKfdF2mdWqI2AAHQrsAAb5CIwAAA+W1QAABTNGAAAESe4AAASvPgAAhQ3gg Date: Fri, 27 Apr 2012 07:05:02 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED6180B390B@011-DB3MPN1-012.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED6180936F2@011-DB3MPN1-013.MGDPHG.emi.philips.com> <7F92E32D-5F89-4EFF-980C-EA56B4960508@tzi.org> <031DD135F9160444ABBE3B0C36CED6180B27C4@011-DB3MPN1-012.MGDPHG.emi.philips.com> 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 - 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: Fri, 27 Apr 2012 07:05:11 -0000 +1 I am too in favor of the "shared resource namespace" and I think this formu= lation also addresses Angelo's concerns. Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Kla= us Hartke Sent: Thursday 26 April 2012 18:11 To: core@ietf.org Subject: Re: [core] draft-ietf-core-coap-09 - Proxying of multicast request= s Carsten Bormann wrote: > I should be able to use an Etag received via a unicast response to a mult= icast request, in order to validate the representation in a unicast request= to the same resource. Yes. That's what I tried to enable with the Content-Location option, because you need the unicast request URI to validate the response. But maybe the option is not really needed... Second attempt: * The responses received in reply to a GET request to a multicast group MAY be used to satisfy a subsequent request on the same request URI. * When a new Proxy-Uri multicast request comes in, the proxy always makes a new request to the multicast group and MAY update the cache with the received responses. * A response received in reply to a GET request to a multicast group MAY also be used to satisfy a subsequent request on the unicast request URI. The unicast request URI is obtained by replacing the authority part of the request URI with the transport layer source address of the response message. * A cache MAY revalidate a response by making a GET request on the unicast request URI. * A GET request to a multicast group MUST NOT contain an ETag option. Klaus _______________________________________________ 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 Fri Apr 27 00:22: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 E4A3521F86FE for ; Fri, 27 Apr 2012 00:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=0.076, 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 508QQf7z4zXH for ; Fri, 27 Apr 2012 00:22:24 -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 EEDC621F86F6 for ; Fri, 27 Apr 2012 00:22:23 -0700 (PDT) Received: by werb10 with SMTP id b10so297206wer.31 for ; Fri, 27 Apr 2012 00:22:23 -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=1P3UPch3AE75SWzqzvMXuVK7jZ42YmTobw0fPOtXOAs=; b=wwX8mWNr00dfyaNiakrmMx3x7BG4paaFiTPNH4545/+IT1dKWzK0mXTANDFd38Sl2m w/KEAp0QGL1mRaQbK88Ag7cZbII5tQU/gSOzO2hdBNB/EgcUzht2cQUWYVsJSxe7+s6N +MNCICwc89kFdxblmuj/XmOnGc+sTkYhK/nLNZp2jJjO0GzAFIKNinvhSYX9bu3zckh/ /xdEAE7IK+VZ6PAC0sKcF6L8KGmUd7iGPKsIoV0GR+J+zAsBlYWL2RjOeCl/7zloYwdS LNggtgRZrOWxtoSNgcCOyU9R9LuS2w75HLDe9nlDf0wZcrzPO+FUzCzPQ/2W72IE4ExJ icww== Received: by 10.180.24.7 with SMTP id q7mr3187673wif.11.1335511342305; Fri, 27 Apr 2012 00:22:22 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.214.20 with HTTP; Fri, 27 Apr 2012 00:22:07 -0700 (PDT) In-Reply-To: References: <031DD135F9160444ABBE3B0C36CED6180936F2@011-DB3MPN1-013.MGDPHG.emi.philips.com> <7F92E32D-5F89-4EFF-980C-EA56B4960508@tzi.org> <031DD135F9160444ABBE3B0C36CED6180B27C4@011-DB3MPN1-012.MGDPHG.emi.philips.com> From: "Angelo P. Castellani" Date: Fri, 27 Apr 2012 09:22:07 +0200 X-Google-Sender-Auth: NLU9WP39P7uqIBTovz-U14fdjCU Message-ID: To: Klaus Hartke Content-Type: text/plain; charset=UTF-8 Cc: core@ietf.org 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: Fri, 27 Apr 2012 07:22:25 -0000 On Thu, Apr 26, 2012 at 18:10, Klaus Hartke wrote: > Second attempt: > > * The responses received in reply to a GET request to a multicast > group MAY be used to satisfy a subsequent request on the same request > URI. > > * When a new Proxy-Uri multicast request comes in, the proxy always > makes a new request to the multicast group and MAY update the cache > with the received responses. > > * A response received in reply to a GET request to a multicast group > MAY also be used to satisfy a subsequent request on the unicast > request URI. The unicast request URI is obtained by replacing the > authority part of the request URI with the transport layer source > address of the response message. > > * A cache MAY revalidate a response by making a GET request on the > unicast request URI. What are we standardizing here? If we decide that the representation provided in response to a multicast request MUST be the same as in the unicast request, then it is obviously the case to cache those representations and we open the path for another efficient cache update mechanism. But if we don't enforce that this by a MUST, a couple of MAYs don't provide any standard at all, everything is lecit and nothing is wrong... Is it really useful? > * A GET request to a multicast group MUST NOT contain an ETag option. This is the only rule provided, which I am not sure that I share. EXAMPLE: Imagine a resource that has the same representation everywhere (e.g. a boolean one), and you want to check that its representation is still the same everywhere. Why shouldn't you use Etag? Angelo From matthieu.vial@non.schneider-electric.com Fri Apr 27 00:25: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 5C92A21F86F1; Fri, 27 Apr 2012 00:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.707 X-Spam-Level: X-Spam-Status: No, score=-5.707 tagged_above=-999 required=5 tests=[AWL=0.892, 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 GSxG95Q6+Tmc; Fri, 27 Apr 2012 00:24:59 -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 91AE221F86DB; Fri, 27 Apr 2012 00:24:59 -0700 (PDT) Received: from ateui02.Schneider-Electric.com ([10.198.14.10]) by mailX03.eud.schneider-electric.com with ESMTP id 2012042709245495-21085 ; Fri, 27 Apr 2012 09:24:54 +0200 In-Reply-To: To: Klaus Hartke 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: Fri, 27 Apr 2012 09:24:53 +0200 X-MIMETrack: Serialize by Router on ATEUI02.Schneider-Electric.com/T/SVR/Schneider at 27/04/2012 09:25:50, Serialize complete at 27/04/2012 09:25:50, Itemize by SMTP Server on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 27/04/2012 09:24:54, Serialize by Router on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 27/04/2012 09:24:58, Serialize complete at 27/04/2012 09:24:58 Content-Type: text/plain; charset="US-ASCII" Cc: core-bounces@ietf.org, core@ietf.org 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: Fri, 27 Apr 2012 07:25:00 -0000 >* A response received in reply to a GET request to a multicast group >MAY also be used to satisfy a subsequent request on the unicast >request URI. The unicast request URI is obtained by replacing the >authority part of the request URI with the transport layer source >address of the response message. In concrete terms it means we can't create virtual servers with multicast addresses without also having a new unicast address attached to this virtual server (impossible with IPv4 we need names and DNS for that). I can see use cases where a multicast virtual server that serves a sub tree of the main resource tree could be useful. That's why I liked the idea of having the same multicast/unicast resource tree only for the AllCoapServers multicast address. Matthieu From cabo@tzi.org Fri Apr 27 00:39: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 44D2F21F86BD for ; Fri, 27 Apr 2012 00:39:46 -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 7Pn9XzuWw9KY for ; Fri, 27 Apr 2012 00:39:45 -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 19F0E21F86BB for ; Fri, 27 Apr 2012 00:39: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 q3R7dY6B016894 for ; Fri, 27 Apr 2012 09:39:34 +0200 (CEST) Received: from [192.168.217.105] (p5B3E6293.dip.t-dialin.net [91.62.98.147]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A0AC4E43; Fri, 27 Apr 2012 09:39:34 +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, 27 Apr 2012 09:39:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <031DD135F9160444ABBE3B0C36CED6180936F2@011-DB3MPN1-013.MGDPHG.emi.philips.com> <7F92E32D-5F89-4EFF-980C-EA56B4960508@tzi.org> <031DD135F9160444ABBE3B0C36CED6180B27C4@011-DB3MPN1-012.MGDPHG.emi.philips.com> To: Klaus Hartke X-Mailer: Apple Mail (2.1257) Cc: core@ietf.org 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: Fri, 27 Apr 2012 07:39:46 -0000 On Apr 26, 2012, at 18:10, Klaus Hartke wrote: > * When a new Proxy-Uri multicast request comes in, the proxy always > makes a new request to the multicast group and MAY update the cache > with the received responses. One thing we are missing to make this more useful is a way to suppress = responses the client already has. For unicast, we do some of this with ETags, but these are in a namespace = made up by each server, so they don't mean anything for a multicast = group as a whole. For multicast, we'd have to list pairs of authorities and ETags. Obviously, these lists can become big quickly. There are good ways to do suppression on a probabilistic basic (bloom = filters are the obvious way, which can be asymptotically perfect in = particular if you vary some hash seed with each request). Given the limited use of multicast in constrained networks, I'm not = suggesting that we standardize anything here, but we could add a note = that this spec does not yet define a suppression mechanism ("left for = further study" would be the CCITT term :-). (Then some bright young grad students can go ahead and spend a year to = design the perfect bloom filter for constrained node/networks...) Note that we also employ the concept of filters already (for = link-format), so if we are just searching, say, for lights that are = still on, we know how to do that. Gr=FC=DFe, Carsten From esko.dijk@philips.com Fri Apr 27 01:11: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 98CAF21F8619 for ; Fri, 27 Apr 2012 01:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.978 X-Spam-Level: X-Spam-Status: No, score=-3.978 tagged_above=-999 required=5 tests=[AWL=-0.379, 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 l6760XcgvbCj for ; Fri, 27 Apr 2012 01:11:05 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 640FB21F861F for ; Fri, 27 Apr 2012 01:11:05 -0700 (PDT) Received: from mail37-ch1-R.bigfish.com (10.43.68.228) by CH1EHSOBE018.bigfish.com (10.43.70.68) with Microsoft SMTP Server id 14.1.225.23; Fri, 27 Apr 2012 08:11:03 +0000 Received: from mail37-ch1 (localhost [127.0.0.1]) by mail37-ch1-R.bigfish.com (Postfix) with ESMTP id C74F346049B; Fri, 27 Apr 2012 08:11:02 +0000 (UTC) X-SpamScore: -54 X-BigFish: VPS-54(zz217bL15d6O9371I9251J1803M542M1432N1418I98dKzz1202hzz8275ch1033IL8275bh8275dhz2dh2a8h668h839h944hd25h) 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 mail37-ch1 (localhost.localdomain [127.0.0.1]) by mail37-ch1 (MessageSwitch) id 1335514260177118_17356; Fri, 27 Apr 2012 08:11:00 +0000 (UTC) Received: from CH1EHSMHS029.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.234]) by mail37-ch1.bigfish.com (Postfix) with ESMTP id 1EFBC600A4; Fri, 27 Apr 2012 08:11:00 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CH1EHSMHS029.bigfish.com (10.43.70.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 27 Apr 2012 08:11:00 +0000 Received: from 011-DB3MMR1-021.MGDPHG.emi.philips.com (10.128.28.103) by 011-DB3MMR1-006.MGDPHG.emi.philips.com (10.128.28.56) with Microsoft SMTP Server (TLS) id 14.1.355.3; Fri, 27 Apr 2012 09:10:25 +0100 Received: from 011-DB3MPN1-012.MGDPHG.emi.philips.com ([169.254.2.221]) by 011-DB3MMR1-021.MGDPHG.emi.philips.com ([fe80::f066:9203:e7da:3658%11]) with mapi id 14.01.0355.003; Fri, 27 Apr 2012 09:10:26 +0100 From: "Dijk, Esko" To: Zach Shelby , Carsten Bormann , Thomas Fossati Thread-Topic: [core] Proxy-URI and coaps scheme Thread-Index: AQHNIX7HpYR9WF0BmU2AFgF93tpmQ5atk+6AgACVSICAAANZAIAAG1bQ Date: Fri, 27 Apr 2012 08:10:25 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED6180B3958@011-DB3MPN1-012.MGDPHG.emi.philips.com> 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> <4F8D1EA8.6080800@ericsson.com> <68B487AC-7384-4B75-9E1F-32CB8454D2F0@koanlogic.com> <4F92196E.9000701@cs.tcd.ie> <9158B27B-8C40-43A7-B957-961A9E29448B@koanlogic.com> <4F92DCFF.4090301@cs.tcd.ie> <7C11BCD4-3A3A-41AE-B4BC-E374BE737B47@koanlogic.com> <4F1131E2-6997-4F2B-A51A-DD2A8607F9E0@tzi.org> <4F92EEE2.6080801@cs.tcd.ie> <94216E93-4059-4EA2-B4AE-88BF67E74369@koanlogic.com> <49276523-70CC-40F2-9D3! 4 -FF8F3348BA0C@tzi.org> <3A4E7A39-C78D-45A9-97ED-9D48B4107DED@tzi.org> <8731C205-19B1-43A0-B522-CE167C7BD80B@koanlogic.com> <0645900D-3DA0-4324-BE2C-61814F51CC3F@tzi.org> <7C60E917-1E01-40B5-9785-13A11DF87E53@tzi.org> <98B06B5C-91B6-468D-A7E8-A94F6E645BB6@iii.ca> <474633E2-983D-4B7E-B8F8-9571C84DF2B8@sensinode.com> In-Reply-To: <474633E2-983D-4B7E-B8F8-9571C84DF2B8@sensinode.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: core WG Subject: Re: [core] Proxy-URI and coaps scheme 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, 27 Apr 2012 08:11:07 -0000 Zach, Carsten, Thomas, I'm curious what are the reasons you have to now favor deprecation (option = 1)...? Two arguments I have seen so far are "we know how to make it work" and "we = don't know how to make it work". If the argument is "we can't make E2E security work" then it implies we als= o must deprecate these cases: - CoAP request with "coaps://" Proxy-URI - CoAP request with "https://" Proxy-URI - CoAPS request with "https://" Proxy-URI - HTTP request with "coaps://" Request-Line - HTTPS request with "coaps://" Request-Line These are not obscure corners of the spec IMO, but clearly present througho= ut in -coap "Proxying" and "HTTP mapping". Esko PS The following cases should be ok as it's the client's own choice to *not= * request E2E security: - CoAPS request with "coap://" Proxy-URI - CoAPS request with "http://" Proxy-URI - HTTPS request with "coap://" Request-Line -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Zac= h Shelby Sent: Friday 27 April 2012 8:37 To: Carsten Bormann Cc: core WG Subject: Re: [core] Proxy-URI and coaps scheme On Apr 27, 2012, at 9:25 AM, Carsten Bormann wrote: > On Apr 26, 2012, at 23:30, Cullen Jennings wrote: > >> >> On Apr 23, 2012, at 12:27 , Thomas Fossati wrote: >> >>> Just to recap the base question I've posed, that may have been diluted = a bit in the ping-pong with Carsten :-) >>> >>> Proxy-URI and coaps scheme, currently an obscure corner of the spec. H= ow shall we treat the combo ? >>> >>> 1) Deprecate because we don't know how to make it work; >>> 2) leave as an implementation/deployment "detail"; >>> 3) define a pass-through facility (ie. CONNECT-like method) to allow E2= E DTLS; >>> 4) define a comprehensive solution for both trusted and untrusted inter= mediary scenarios; >>> 5) other? >>> _______________________________________________ >> >> I don't want 2 > > well, obviously. > >> and don't want 3. > > Do you mean you don't want a 3 at all (I proposed one straw man way of do= ing this in > http://tools.ietf.org/html/draft-bormann-coap-misc-15#section-5) or that = you don't want this to be the only outcome? At least personally I don't find 3 to be useful. There would be good reason= s for enabling end-to-end TLS security work across a CoAP-HTTP proxy, but I= think that falls under 4 in Thomas's list. > I'm leaning towards: > -- 1 for now, and Agreed. > -- start a separate work item on 4 (with some limits on "comprehensive"),= and Smells like someone needs to start such a draft. > -- maybe also further investigate 3. If we really see a need. Zach -- 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 ________________________________ 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 Fri Apr 27 03:03: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 D4ED321F8859 for ; Fri, 27 Apr 2012 03:03: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 RTsQDLvhsWt3 for ; Fri, 27 Apr 2012 03:03: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 5B3C821F8858 for ; Fri, 27 Apr 2012 03:03: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 q3RA3PkJ009129; Fri, 27 Apr 2012 12:03:25 +0200 (CEST) Received: from [192.168.217.105] (p5B3E6293.dip.t-dialin.net [91.62.98.147]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 2918F158; Fri, 27 Apr 2012 12:03: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: <031DD135F9160444ABBE3B0C36CED6180B3958@011-DB3MPN1-012.MGDPHG.emi.philips.com> Date: Fri, 27 Apr 2012 12:03:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: 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> <4F8D1EA8.6080800@ericsson.com> <68B487AC-7384-4B75-9E1F-32CB8454D2F0@koanlogic.com> <4F92196E.9000701@cs.tcd.ie> <9158B27B-8C40-43A7-B957-961A9E29448B@koanlogic.com> <4F92DCFF.4090301@cs.tcd.ie> <7C11BCD4-3A3A-41AE-B4BC-E374BE737B47@koanlogic.com> <4F1131E2-6997-4F2B-A51A-DD2A8607F9E0@tzi.org> <4F92EEE2.6080801@cs.tcd.ie> <94216E93-4059-4EA2-B4AE-88BF67E74369@koanlogic.com> <49276523-70CC-40F2-9D3! 4 -FF8F3348BA0C@tzi.org> <3A4E7A39-C78D-45A9-97ED-9D48B4107DED@tzi.org> <8731C205-19B1-43A0-B522-CE167C7BD80B@koanlogic.com> <0645900D-3DA0-4324-BE2C-61814F51CC3F@tzi.org> <7C60E917-1E01-40B5-9785-13A11DF87E53@tzi.org> <98B06B5C-91B6-468D-A7E8-A94F6E645BB6@iii.ca> <474633E2-983D-4B7E-B8F8-9571C84DF2B8@sensinode.com> <031DD135F9160444ABBE3B0C36CED6180B3958@011-DB3MPN1-012.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1257) Cc: core WG Subject: Re: [core] Proxy-URI and coaps scheme 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, 27 Apr 2012 10:03:36 -0000 On Apr 27, 2012, at 10:10, Dijk, Esko wrote: > Zach, Carsten, Thomas, >=20 > I'm curious what are the reasons you have to now favor deprecation = (option 1)...? Well, deprecation is the wrong word (we use that when existing = functionality gets out of fashion). Saying "this doesn't mean very much until we define what it means" is = more like it. > Two arguments I have seen so far are "we know how to make it work" and = "we don't know how to make it work". >=20 > If the argument is "we can't make E2E security work" then it implies = we also must deprecate these cases: > - CoAP request with "coaps://" Proxy-URI > - CoAP request with "https://" Proxy-URI > - CoAPS request with "https://" Proxy-URI > - HTTP request with "coaps://" Request-Line > - HTTPS request with "coaps://" Request-Line There is no new problem with https:// -- the security parameters that = are expected here are relatively well understood, even if the certainty = in this space is quickly eroding. Obviously, the URI does not give us a = way to trigger other HTTP-based security features such as sending OAuth = tokens in "Authorization:" headers (well, there is a lively debate on = how to enable equivalent URI functionality right now; see also = http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-19#section-2.3). = At some point it would also be nice for a client to be able to influence = which cipher suites, root CAs etc. an intermediary accepts on the way = forward. But I think everybody understands that the ways to specify any = such additional security parameters will be the subject of future work, = outside of the CoRE WG, and nobody expects to be able to use e.g. PSK = for HTTPS. There is a problem with every use of coaps:// -- independent of whether = that is interpreted in an intermediary or right in a client. For use = within a client, one could make the argument that the client is likely = to be able to map aspects of the URI such as the authority to security = parameters, e.g., it has a table that indicates that it tends to speak = to the water meter using a PSK it has stored for this specific purpose. = There is a bit of a problem with HATEOAS here, as the server really = should be able to indicate its preferences when supplying the next URI = to use, but that's just reflecting the state of the art. For intermediaries, the client component of the intermediary has to = determine the security parameters for its outgoing DTLS connection. The = same argument as above can be made for *some* trusted intermediary = scenarios. Where the forward proxy chosen by a client is its "big = brother", it may actually know more about the right way to set up the = DTLS connection than the client itself. Similarly, a border reverse = proxy may know the best way to talk to the nodes in "its" 6LoWPAN. The = vague "coaps://" is appropriate here and need not be recommended against = as long as we clearly describe the boundaries of this narrow = application. To me, option 1 means just that: clearly delimiting the area where = coaps:// already "works" (and supplying a bit more detail where needed). Of course, we want to expand that area, and that expansion is the work = of option 4. Again, the problem is not the proxying, but the fact that the coaps;// = scheme is necessarily underspecified ("CoAP with *some* security" :-). Gr=FC=DFe, Carsten From esko.dijk@philips.com Fri Apr 27 04:09: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 5CF1A21F860B for ; Fri, 27 Apr 2012 04:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.959 X-Spam-Level: X-Spam-Status: No, score=-3.959 tagged_above=-999 required=5 tests=[AWL=-0.360, 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 cLd-FRCSQIU8 for ; Fri, 27 Apr 2012 04:09:17 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 2334A21F85D4 for ; Fri, 27 Apr 2012 04:09:17 -0700 (PDT) Received: from mail145-ch1-R.bigfish.com (10.43.68.241) by CH1EHSOBE016.bigfish.com (10.43.70.66) with Microsoft SMTP Server id 14.1.225.23; Fri, 27 Apr 2012 11:09:14 +0000 Received: from mail145-ch1 (localhost [127.0.0.1]) by mail145-ch1-R.bigfish.com (Postfix) with ESMTP id 483DD4E0184; Fri, 27 Apr 2012 11:09:14 +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 mail145-ch1 (localhost.localdomain [127.0.0.1]) by mail145-ch1 (MessageSwitch) id 1335524952669251_13210; Fri, 27 Apr 2012 11:09:12 +0000 (UTC) Received: from CH1EHSMHS010.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.237]) by mail145-ch1.bigfish.com (Postfix) with ESMTP id 9EDE21C004B; Fri, 27 Apr 2012 11:09:12 +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; Fri, 27 Apr 2012 11:09:12 +0000 Received: from 011-DB3MMR1-015.MGDPHG.emi.philips.com (10.128.28.99) by 011-DB3MMR1-001.MGDPHG.emi.philips.com (10.128.28.51) with Microsoft SMTP Server (TLS) id 14.1.355.3; Fri, 27 Apr 2012 12:09:12 +0100 Received: from 011-DB3MPN1-012.MGDPHG.emi.philips.com ([169.254.2.221]) by 011-DB3MMR1-015.MGDPHG.emi.philips.com ([10.128.28.99]) with mapi id 14.01.0355.003; Fri, 27 Apr 2012 12:09:12 +0100 From: "Dijk, Esko" To: Carsten Bormann Thread-Topic: [core] Proxy-URI and coaps scheme Thread-Index: AQHNIX7HpYR9WF0BmU2AFgF93tpmQ5atk+6AgACVSICAAANZAIAAG1bQgAAeT4CAAB4ugA== Date: Fri, 27 Apr 2012 11:09:11 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED6180B39D5@011-DB3MPN1-012.MGDPHG.emi.philips.com> 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> <4F8D1EA8.6080800@ericsson.com> <68B487AC-7384-4B75-9E1F-32CB8454D2F0@koanlogic.com> <4F92196E.9000701@cs.tcd.ie> <9158B27B-8C40-43A7-B957-961A9E29448B@koanlogic.com> <4F92DCFF.4090301@cs.tcd.ie> <7C11BCD4-3A3A-41AE-B4BC-E374BE737B47@koanlogic.com> <4F1131E2-6997-4F2B-A51A-DD2A8607F9E0@tzi.org> <4F92EEE2.6080801@cs.tcd.ie> <94216E93-4059-4EA2-B4AE-88BF67E74369@koanlogic.com> <49276523-70CC-40F2-9D3! 4 -FF8F3348BA0C@tzi.org> <3A4E7A39-C78D-45A9-97ED-9D48B4107DED@tzi.org> <8731C205-19B1-43A0-B522-CE167C7BD80B@koanlogic.com> <0645900D-3DA0-4324-BE2C-61814F51CC3F@tzi.org> <7C60E917-1E01-40B5-9785-13A11DF87E53@tzi.org> <98B06B5C-91B6-468D-A7E8-A94F6E645BB6@iii.ca> <474633E2-983D-4B7E-B8F8-9571C84DF2B8@sensinode.com> <031DD135F9160444ABBE3B0C36CED6180B3958@011-DB3MPN1-012.MGDPHG.emi.philips.com> 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 WG Subject: Re: [core] Proxy-URI and coaps scheme 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, 27 Apr 2012 11:09:18 -0000 Thanks Carsten, > To me, option 1 means just that: clearly delimiting the area where coaps:= // already "works" (and supplying a bit more detail where needed). That's an option 1 I can agree to! Now besides the technical details: this means for this limited scope use ca= se that the proxy is "allowed" to forward a response, obtained securely (co= aps or https), containing sensitive data, via an unprotected channel to the= client. I just point this out to check if anyone sees a problem with that.= (The client at least seems not bothered; the server has no say here.) regards, Esko -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: Friday 27 April 2012 12:03 To: Dijk, Esko Cc: Zach Shelby; Thomas Fossati; core WG Subject: Re: [core] Proxy-URI and coaps scheme On Apr 27, 2012, at 10:10, Dijk, Esko wrote: > Zach, Carsten, Thomas, > > I'm curious what are the reasons you have to now favor deprecation (optio= n 1)...? Well, deprecation is the wrong word (we use that when existing functionalit= y gets out of fashion). Saying "this doesn't mean very much until we define what it means" is more = like it. > Two arguments I have seen so far are "we know how to make it work" and "w= e don't know how to make it work". > > If the argument is "we can't make E2E security work" then it implies we a= lso must deprecate these cases: > - CoAP request with "coaps://" Proxy-URI > - CoAP request with "https://" Proxy-URI > - CoAPS request with "https://" Proxy-URI > - HTTP request with "coaps://" Request-Line > - HTTPS request with "coaps://" Request-Line There is no new problem with https:// -- the security parameters that are e= xpected here are relatively well understood, even if the certainty in this = space is quickly eroding. Obviously, the URI does not give us a way to tri= gger other HTTP-based security features such as sending OAuth tokens in "Au= thorization:" headers (well, there is a lively debate on how to enable equi= valent URI functionality right now; see also http://tools.ietf.org/html/dra= ft-ietf-oauth-v2-bearer-19#section-2.3). At some point it would also be ni= ce for a client to be able to influence which cipher suites, root CAs etc. = an intermediary accepts on the way forward. But I think everybody understa= nds that the ways to specify any such additional security parameters will b= e the subject of future work, outside of the CoRE WG, and nobody expects to= be able to use e.g. PSK for HTTPS. There is a problem with every use of coaps:// -- independent of whether tha= t is interpreted in an intermediary or right in a client. For use within a= client, one could make the argument that the client is likely to be able t= o map aspects of the URI such as the authority to security parameters, e.g.= , it has a table that indicates that it tends to speak to the water meter u= sing a PSK it has stored for this specific purpose. There is a bit of a pr= oblem with HATEOAS here, as the server really should be able to indicate it= s preferences when supplying the next URI to use, but that's just reflectin= g the state of the art. For intermediaries, the client component of the intermediary has to determi= ne the security parameters for its outgoing DTLS connection. The same argu= ment as above can be made for *some* trusted intermediary scenarios. Where= the forward proxy chosen by a client is its "big brother", it may actually= know more about the right way to set up the DTLS connection than the clien= t itself. Similarly, a border reverse proxy may know the best way to talk = to the nodes in "its" 6LoWPAN. The vague "coaps://" is appropriate here an= d need not be recommended against as long as we clearly describe the bounda= ries of this narrow application. To me, option 1 means just that: clearly delimiting the area where coaps://= already "works" (and supplying a bit more detail where needed). Of course, we want to expand that area, and that expansion is the work of o= ption 4. Again, the problem is not the proxying, but the fact that the coaps;// sche= me is necessarily underspecified ("CoAP with *some* security" :-). 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 cabo@tzi.org Fri Apr 27 06:50: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 907E421F86BA for ; Fri, 27 Apr 2012 06:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.289 X-Spam-Level: X-Spam-Status: No, score=-106.289 tagged_above=-999 required=5 tests=[AWL=-0.040, 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 KA3h7yEIqcrY for ; Fri, 27 Apr 2012 06:50: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 C0E0921F86B7 for ; Fri, 27 Apr 2012 06:50: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 q3RDoGEi002399; Fri, 27 Apr 2012 15:50:16 +0200 (CEST) Received: from [192.168.217.105] (p54899853.dip.t-dialin.net [84.137.152.83]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5D7FC2E7; Fri, 27 Apr 2012 15:50:16 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: <031DD135F9160444ABBE3B0C36CED6180B2610@011-DB3MPN1-012.MGDPHG.emi.philips.com> Date: Fri, 27 Apr 2012 15:50:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <031DD135F9160444ABBE3B0C36CED6180B2610@011-DB3MPN1-012.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1257) Cc: "core@ietf.org" Subject: Re: [core] objectives of block-08 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, 27 Apr 2012 13:50:24 -0000 Peter, Esko, thanks, this is great input. I now just have to find time to realize = Klaus' and your really constructive input into a new version... Peter: one comment: -block certainly is not *limited* to 1=964 = exchanges, it is just optimized for it. You can do a firmware upload (or maybe a state dump) using -block. The one thing you cannot expect is to fill the network. Gr=FC=DFe, Carsten From ari.keranen@nomadiclab.com Fri Apr 27 09:36: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 5940B21F85A4 for ; Fri, 27 Apr 2012 09:36: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=[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 fzLCYo16TeT2 for ; Fri, 27 Apr 2012 09:36:32 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA4121F8688 for ; Fri, 27 Apr 2012 09:36:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id D60194E6E9 for ; Fri, 27 Apr 2012 19:36:22 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tVt5CmtwRAO for ; Fri, 27 Apr 2012 19:36:22 +0300 (EEST) Received: from As-MacBook-Air.local (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id 9D4944E679 for ; Fri, 27 Apr 2012 19:36:21 +0300 (EEST) Message-ID: <4F9ACB0D.7020508@nomadiclab.com> Date: Fri, 27 Apr 2012 11:36:29 -0500 From: Ari Keranen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: core Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [core] draft-farrell-decade-ni-04 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, 27 Apr 2012 16:36:33 -0000 Folks, We have now updated the hash naming draft [1] once more and think it's ready to move forward. The only "bigger" technical changes based on the feedback and some more implementation experience were the change from base32 to base16 (hex) encoding for the human-readable format and also allow for encoding the hash-algorithm and length using Suite IDs. The first change makes the human-readable format's hash part slightly longer, but the second change reduces the length with commonly used algorithms by 9-10 characters. The slightly longer length for the hash is unfortunate, but the difference is actually quite small (6 characters with the 120-bit hash) and the simplicity of implementation and specification (e.g., no need to worry about bit-boundaries and padding) makes up for it. Cheers, Ari [1] http://tools.ietf.org/html/draft-farrell-decade-ni-04 From fluffy@cisco.com Fri Apr 27 09:57: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 5582821F8714 for ; Fri, 27 Apr 2012 09:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.28 X-Spam-Level: X-Spam-Status: No, score=-110.28 tagged_above=-999 required=5 tests=[AWL=0.319, 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 6KavrD01qS8Z for ; Fri, 27 Apr 2012 09:57:46 -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 EC64021F86DB for ; Fri, 27 Apr 2012 09:57:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=459; q=dns/txt; s=iport; t=1335545865; x=1336755465; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=XnQHgiaGcyWzOO23g7Y6D5MFyRr3HK8hRNc+Lm2Jnyo=; b=CnZkMDNfXVoMDK1MlndRMOODzcGZ9+5w3tahFzH2UEI2Bd/y73T9JkSo Wz3WWG4tCAN7jJ5UoNyy5xEZOTVDOTME/V8wNtabQjHKTlWgqIQYE/mOs gtjAtiWENwRjPqJo+OM1CQCtYYaEdb1Z1p7PU8Y0z57it2+PbXVLnCn0G c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuUFACvPmk+rRDoH/2dsb2JhbABEgx2uU4EHgiIBJz+BPjWHapwhoCOQYGMEiGONGoV0iGOBaYMH X-IronPort-AV: E=Sophos;i="4.75,492,1330905600"; d="scan'208";a="39388959" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 27 Apr 2012 16:57:45 +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 q3RGvjOB004875; Fri, 27 Apr 2012 16:57:45 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Apr 2012 10:57:44 -0600 Message-Id: <500E1CE0-EF1D-4D69-8FDB-3E2BAD19A1C1@cisco.com> To: core WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] CORE Virtual Interim - May 16 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, 27 Apr 2012 16:57:46 -0000 We plan to run a virtual interim meeting for CORE on Wednesday, May 16, = at 14:30Z.=20 This will be a webex phone call that is scheduled for three hours. The = original poll was for two hours but looking at the volume of issues and = tickets, and the availability of folks in the doodle poll, we took the = liberty of extending it for an extra hour. We realize some people may = have to join later or drop early.=20 Thank, Cullen & Carsten=20 From iesg-secretary@ietf.org Fri Apr 27 13:31: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 D7A2B21F84F1; Fri, 27 Apr 2012 13:31: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 zJlvu-sdSrjF; Fri, 27 Apr 2012 13:31:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A44821F84E1; Fri, 27 Apr 2012 13:31:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120427203111.26615.43755.idtracker@ietfa.amsl.com> Date: Fri, 27 Apr 2012 13:31:11 -0700 Cc: core@ietf.org Subject: [core] CORE WG Virtual Interim Meeting: May 16, 2012, 14:30Z 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, 27 Apr 2012 20:31:12 -0000 We plan to run a virtual interim meeting for CORE WG on Wednesday, May 16, = at 14:30Z. This will be a webex phone call that is scheduled for three hour= s. The agenda and conference bridge details will be announced on the CORE W= G email list.=20 From michael.scharf@alcatel-lucent.com Sun Apr 29 14:37: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 549CC21F85C0; Sun, 29 Apr 2012 14:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.69 X-Spam-Level: X-Spam-Status: No, score=-9.69 tagged_above=-999 required=5 tests=[AWL=0.559, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 60+dMYA4lQES; Sun, 29 Apr 2012 14:37:51 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 5AEE821F85B5; Sun, 29 Apr 2012 14:37:50 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q3TLbkNq028973 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 29 Apr 2012 23:37:47 +0200 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Sun, 29 Apr 2012 23:37:46 +0200 From: "Scharf, Michael (Michael)" To: "zach@sensinode.com" , "hartke@tzi.org" , "cabo@tzi.org" , "brian@skyfoundry.com" Date: Sun, 29 Apr 2012 23:37:45 +0200 Thread-Topic: Congestion control in draft-ietf-core-coap-09? Thread-Index: Ac0f4okScn+6bbmcT42OZyPxLdwNOgGXc2Eg Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E891A1F4E9C@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <87E81A3B-9008-48B4-9A03-FECA3F3452E1@cisco.com> In-Reply-To: <87E81A3B-9008-48B4-9A03-FECA3F3452E1@cisco.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 X-Mailman-Approved-At: Sun, 29 Apr 2012 22:32:22 -0700 Cc: Cullen Jennings , "core@ietf.org" , "tsv-dir@ietf.org" Subject: [core] Congestion control in 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: Sun, 29 Apr 2012 21:37:52 -0000 Hi, Cullen asked tsv-dir for feedback on draft-ietf-core-coap-09. Please find b= elow some thoughts after scanning through the TCP-like functions. This is n= ot a formal tsv-dir review, but I have raised similar concerns for other dr= afts in past tsv-dir reviews. Unfortunately I have not followed the core WG= . I apologize for my ignorance about the background (I am also not subscrib= ed to the core list, so please CC me if needed). > be randomized. The same Message ID MUST NOT be re-used=20 > (per Message > ID variable) within the potential retransmission window, calculated > as RESPONSE_TIMEOUT * RESPONSE_RANDOM_FACTOR * (2 ^=20 > MAX_RETRANSMIT - > 1) plus the expected maximum round trip time. At first sight, the RTT is not mentioned elsewhere in the document. Is my u= nderstanding correct that core does not measure the RTT? If so, it is not c= lear to me how a sender would know the "expected maxium round trip time". Also, note that if the intention is to ensure uniqueness of messages, the M= aximum Segment Lifetime (MSL) matters. RFC 793 (arbitrarily) sets it to 2 m= inutes for TCP. > 4.6. Congestion Control >=20 > Basic congestion control for CoAP is provided by the exponential > back-off mechanism in Section 4.1. In my understanding, Section 4.1 defines a reliability mechanism with expon= ential back-off. Timer backoff is a pre-requisite for congestion control. B= ut a backoff mechanism alone does not provide congestion control. > In order not to cause congestion, Clients (including=20 > proxies) SHOULD > strictly limit the number of simultaneous outstanding interactions > that they maintain to a given server (including proxies). An > outstanding interaction is either a CON for which an ACK=20 > has not yet > been received but is still expected (message layer) or a=20 > request for > which a response has not yet been received but is still expected > (which may both occur at the same time, counting as one outstanding > interaction). A good value for this limit is the number 1. (Note > that [RFC2616], in trying to achieve a similar objective,=20 > did specify > a specific number of simultaneous connections as a ceiling. While > revising [RFC2616], this was found to be impractical for many > applications [I-D.ietf-httpbis-p1-messaging]. For the same > considerations, this specification does not mandate a particular > maximum number of outstanding interactions, but instead encourages > clients to be conservative when initiating interactions.) If there is no limitation of the number of outstanding interactions, I don'= t understand how congestion control is actually achieved. Also, note that R= FC2616 is about a limit for TCP connections, which is not the same. I think that this document should consider and discuss the guidelines of RF= C 5405. For instance, the following guideline therein matters: "It is important to = stress that an application SHOULD perform congestion control over all UDP t= raffic it sends to a destination, independently from how it generates this = traffic. For example, an application that forks multiple worker processes = or otherwise uses multiple sockets to generate UDP datagrams SHOULD perform= congestion control over the aggregate traffic." As long as there is only one outstanding interaction, the core protocol see= ms to fall into the class of "low data-volume applications" according to se= ction 3.1.2 of RFC 5405. In that case, an exponential backoff of the retran= smission timer is considered sufficient for congestion control. Thus, for t= hat case, the protocol mechanisms defined in the draft seem to be sufficien= t. However, the text only mentions that "A good value for this limit is the nu= mber 1". This is too weak, imho. I think that this should be at least a SHO= ULD, and the section should refer to RFC 5405. Also, I think that the docum= ent should explain that using any value significantly larger than one will = require implementation of an aggregate, TCP-friendly congestion control, e.= g., by adapting the limit according to the observed packet loss (this won'= t be trivial). > Further congestion control optimizations and considerations are > expected in the future, which may for example provide automatic > initialization of the CoAP constants defined in Section 9. As already mentioned, congestion control might also have to control the lim= it of interactions, if the value is larger than 1. > 9. Protocol Constants >=20 > This section defines the relevant protocol constants=20 > defined in this > document: >=20 > RESPONSE_TIMEOUT 2 seconds >=20 > RESPONSE_RANDOM_FACTOR 1.5 >=20 > MAX_RETRANSMIT 4 These values seem to be OK. > The values for RESPONSE_TIMEOUT, RESPONSE_RANDOM_FACTOR, and > MAX_RETRANSMIT may be configured to values specific to the > application environment, however the configuration method is out of > scope of this document. It is recommended that an application > environment use consistent values for these parameters. A decrease of RESPONSE_TIMEOUT below 1 second would violate the guidelines = of RFC 5405, and it would not be save for use in the Internet. Also note that significantly decreasing the RESPONSE_TIMEOUT would require = an adaptive RTT measurement to be robust, see RFC 5405 or draft-allman-tcpm= -rto-consider. I think that the draft should strongly discourage any decrea= se of RESPONSE_TIMOUT until such more advanced mechanisms exist, and it sho= uld explain why. Thanks Michael From trac+core@trac.tools.ietf.org Mon Apr 30 11:06: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 E375D21F86E2 for ; Mon, 30 Apr 2012 11:06:31 -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 XQQ0SdyducBT for ; Mon, 30 Apr 2012 11:06:30 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 9963621F87CB for ; Mon, 30 Apr 2012 11:06:30 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SOuzS-0001Ez-AQ; Mon, 30 Apr 2012 14:06:26 -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, hartke@tzi.org X-Trac-Project: core Date: Mon, 30 Apr 2012 18:06:25 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/227 Message-ID: <053.2559d3887bb640b2a7c324910c10ae1c@trac.tools.ietf.org> X-Trac-Ticket-ID: 227 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-observe@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: <20120430180630.9963621F87CB@ietfa.amsl.com> Resent-Date: Mon, 30 Apr 2012 11:06:30 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #227: Make aborting the previous transaction optional 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, 30 Apr 2012 18:06:32 -0000 #227: Make aborting the previous transaction optional Section 4.5 requires a server implementation to stop an old transmission and carry the retransmit count over to the new transaction. Cullen Jennings notes (msg03073h) that this is hard to implement in some cases and a minor optimization for an edge case. He proposes that a server implementation can choose if it wants to abort the previous transaction or run two transactions in parallel. * If it aborts the previous transaction, then it needs to copy over the retransmit state to the new transaction. * If it doesn't cancel the old transaction, the device still finds out the device is gone. -- ----------------------------------+--------------------------------------- Reporter: hartke@… | Owner: draft-ietf-core-observe@… Type: protocol enhancement | Status: new Priority: minor | Milestone: post-WGLC-1 Component: observe | Version: observe-05 Severity: In WG Last Call | Keywords: ----------------------------------+--------------------------------------- Ticket URL: core From hartke@tzi.org Mon Apr 30 11:11: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 EFF4721F887A for ; Mon, 30 Apr 2012 11:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.697 X-Spam-Level: X-Spam-Status: No, score=-4.697 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, 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 AkNWDEUAYaoC for ; Mon, 30 Apr 2012 11:11: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 0B79321F87FD for ; Mon, 30 Apr 2012 11:11: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 q3UIBG6c011940 for ; Mon, 30 Apr 2012 20:11:16 +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 421A19C0 for ; Mon, 30 Apr 2012 20:11:16 +0200 (CEST) Received: by dady13 with SMTP id y13so5869457dad.27 for ; Mon, 30 Apr 2012 11:11:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.234.161 with SMTP id uf1mr7961874pbc.148.1335809474091; Mon, 30 Apr 2012 11:11:14 -0700 (PDT) Received: by 10.68.23.37 with HTTP; Mon, 30 Apr 2012 11:11:14 -0700 (PDT) In-Reply-To: References: Date: Mon, 30 Apr 2012 20:11: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] 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: Mon, 30 Apr 2012 18:11:25 -0000 Zach Shelby wrote: > 2. Knowledge of the Observability of a resource is useful at the applicat= ion layer, where some M2M application needs to make use of these resources.= The behavior of dealing with a polling-only resource vs. an observable res= ource is pretty different, and an observable resource might result in a dif= ferent graphical representation to the user which needs to be known already= during discovery. So, to understand this in the greater context of web linking: if HTML had an "obs" attribute for links, then I guess would indicate that a user agent should observe the resource and update the presentation whenever a new version is available ("data monitoring"), while would retain the existing semantics of retrieving the image once and not updating the presentation until the page is reloaded ("data retrieval"). So it seems that the "obs" attribute is orthogonal to supporting -observe: The question is not polling vs. observing a resource, but whether the resource is meant for data retrieval or data monitoring. If a server indicates that a resource is meant for data monitoring but does not implement -observe (or is temporarily not accepting -observe requests), it still makes sense for a client to present the resource in the "data monitoring" graphical representation and poll the resource if necessary to achieve this goal. Klaus From trac+core@trac.tools.ietf.org Mon Apr 30 11:40:01 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 7D95221F8929 for ; Mon, 30 Apr 2012 11:40:01 -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 9nCOUIG+kMjy for ; Mon, 30 Apr 2012 11:40:01 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id E55E921F8925 for ; Mon, 30 Apr 2012 11:40:00 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SOvVg-0007zV-S0; Mon, 30 Apr 2012 14:39:44 -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: Mon, 30 Apr 2012 18:39:44 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/228 Message-ID: <053.14c1896b5eae7fbbc5ad1a8f77d383ce@trac.tools.ietf.org> X-Trac-Ticket-ID: 228 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: <20120430184000.E55E921F8925@ietfa.amsl.com> Resent-Date: Mon, 30 Apr 2012 11:40:00 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #228: Proxying of multicast requests 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, 30 Apr 2012 18:40:01 -0000 #228: Proxying of multicast requests Esko Dijk notes (msg03065): In Section 5.7 (Proxying) the possibility of a multicast request in the Proxy-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?) -> Create a multicast section, between section 9 and 10 with the existing content of section 4.5 and the following additional rules: * When a new Proxy-Uri multicast request comes in, the proxy always makes a new request to the multicast group (since there may be new group members that joined meanwhile or ones that did not get the previous request). It MAY update the cache with the received responses. Then it sends all responses (both cached-still-fresh and 'new') back to the original client. * A response received in reply to a GET request to a multicast group MAY be used to satisfy a subsequent request on the related unicast request URI. [Only for the AllCoapServers multicast group?] The unicast request URI is obtained by replacing the authority part of the request URI with the transport layer source address of the response message. [Overridden by a Content-Location option?] * A cache MAY revalidate a response by making a GET request on the related unicast request URI. * A GET request to a multicast group MUST NOT contain an ETag option. ---- Carsten Bormann notes (msg03272): One thing we are missing to make this more useful is a way to suppress responses the client already has. For unicast, we do some of this with ETags, but these are in a namespace made up by each server, so they don't mean anything for a multicast group as a whole. For multicast, we'd have to list pairs of authorities and ETags. Obviously, these lists can become big quickly. -> Add a note that this spec does not yet define a suppression mechanism ("left for further study" would be the CCITT term :-). -- ----------------------------------+------------------------------------ Reporter: hartke@… | Owner: draft-ietf-core-coap@… Type: protocol enhancement | Status: new Priority: minor | Milestone: post-WGLC-1 Component: coap | Version: coap-09 Severity: In WG Last Call | Keywords: ----------------------------------+------------------------------------ Ticket URL: core From trac+core@trac.tools.ietf.org Mon Apr 30 11:43: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 9588421F8878 for ; Mon, 30 Apr 2012 11:43:31 -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 Hvl5moynfnku for ; Mon, 30 Apr 2012 11:43:31 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 04A8A21F885C for ; Mon, 30 Apr 2012 11:43:31 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SOvZE-0005mn-AF; Mon, 30 Apr 2012 14:43: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-coap@tools.ietf.org, hartke@tzi.org X-Trac-Project: core Date: Mon, 30 Apr 2012 18:43:24 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/229 Message-ID: <053.ce983dd14dc89fbf38d56d60d83000f0@trac.tools.ietf.org> X-Trac-Ticket-ID: 229 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: <20120430184331.04A8A21F885C@ietfa.amsl.com> Resent-Date: Mon, 30 Apr 2012 11:43:31 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #229: Move sections 10-10.2. out of the "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, 30 Apr 2012 18:43:31 -0000 #229: Move sections 10-10.2. out of the "Security Considerations" Ari Keränen notes (msg03157p): I'd consider moving sections 10-10.2. out of the "Security Considerations" and into a section of their own (called something like "Securing CoAP") and make just the section 10.3. the Security Considerations. The text in 10-10.2. looks like "regular specification text" whereas 10.3. is what I'd expect to see in Security Considerations. -- -----------------------------+------------------------------------ Reporter: hartke@… | Owner: draft-ietf-core-coap@… Type: editorial | Status: new Priority: minor | Milestone: post-WGLC-1 Component: coap | Version: coap-09 Severity: In WG Last Call | Keywords: -----------------------------+------------------------------------ Ticket URL: core