From nobody Tue Jul 1 07:53:48 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8760E1A0353 for ; Tue, 1 Jul 2014 07:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.251 X-Spam-Level: X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCayvPZmKtsp for ; Tue, 1 Jul 2014 07:53:46 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECC861A034F for ; Tue, 1 Jul 2014 07:53: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.5/8.14.5) with ESMTP id s61ErgZR016842 for ; Tue, 1 Jul 2014 16:53:43 +0200 (CEST) Received: from [192.168.217.106] (p5489156F.dip0.t-ipconnect.de [84.137.21.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 639C5497; Tue, 1 Jul 2014 16:53:42 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: <16F71367-A8FA-48BE-AA60-33529337B636@tzi.org> Date: Tue, 1 Jul 2014 16:53:40 +0200 X-Mao-Original-Outgoing-Id: 425919220.708499-4f286bc9b9cc3ba92ad0990388043919 Content-Transfer-Encoding: quoted-printable Message-Id: References: <16F71367-A8FA-48BE-AA60-33529337B636@tzi.org> To: core X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/core/TLoWieNAW9V39nPlcYbHF-QBy1o Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_draft-ietf-core-coap-18_now_RFC_725?= =?utf-8?q?2?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 01 Jul 2014 14:53:47 -0000 On 27 Jun 2014, at 10:28, Carsten Bormann wrote: > To celebrate the occasion, and to provide a focus for information > about the community that is building around CoAP, we have set up a web > site. Before it finds a more permanent home, please find the draft > site at: >=20 > http://6lowapp.net Thank you all for the positive feedback for this web site. The site is now available at its permanent home: http://coap.technology (Yes, .technology is now a top-level domain.) You=92re welcome to communicate this link to people interested in CoAP. And, to reiterate: if you have anything that should be mentioned on that = site, or any other comment, please don't hesitate to send me mail or open an issue on the site. Gr=FC=DFe, Carsten From nobody Wed Jul 2 02:24:34 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC8F1A0154 for ; Wed, 2 Jul 2014 02:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4EonjwFig39P for ; Wed, 2 Jul 2014 02:24:31 -0700 (PDT) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id C907C1A014F for ; Wed, 2 Jul 2014 02:24:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,587,1400005800"; d="scan'208";a="551871414" Received: from INKOLSALDLPMTA1.india.tcs.com (unknown [127.0.0.1]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id 2D284DAC12; Wed, 2 Jul 2014 14:54:26 +0530 (IST) Received: from InKolM02.tcs.com (unknown [172.18.18.104]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id E9956DAC02; Wed, 2 Jul 2014 14:54:25 +0530 (IST) In-Reply-To: References: To: core@ietf.org, esko.dijk@philips.com MIME-Version: 1.0 X-KeepSent: CF9BC4DF:EEB30338-65257D09:003145E4; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0 March 08, 2013 Message-ID: From: Abhijan Bhattacharyya Date: Wed, 2 Jul 2014 14:54:27 +0530 X-MIMETrack: Serialize by Notes Server on InKolM02/TCS(Release 9.0.1HF198 | January 23, 2014) at 07/02/2014 14:54:25, Serialize complete at 07/02/2014 14:54:25, Serialize by Router on InKolM02/TCS(Release 9.0.1HF198 | January 23, 2014) at 07/02/2014 14:54:25 Content-Type: multipart/alternative; boundary="=_alternative 0033ABE565257D09_=" Archived-At: http://mailarchive.ietf.org/arch/msg/core/dXy4B3hTn-E8I2lGUII3FymBsfU Subject: Re: [core] Updates in core-groupcomm-19 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 02 Jul 2014 09:24:33 -0000 This is a multipart message in MIME format. --=_alternative 0033ABE565257D09_= MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRXNrbywNCj4gDQo+IFRoZSBUb2tlbiB2YWx1ZSByZS11c2UgZ3VpZGVsaW5lIGlzIGFuIGFk ZGl0aW9uIGJhc2VkIG9uIHRoZSANCj4gZGlzY3Vzc2lvbiB0aHJlYWQg4oCcSGFuZGxpbmcgdG9r ZW5zIGZvciBOby1yZXNwb25zZeKAnSwgd2hlcmUgdGhpcyANCj4gaXNzdWUgd2FzIGlkZW50aWZp ZWQuDQo+IEZvciBtdWx0aWNhc3QgdGhlIFRva2VuIHJlLXVzZSB0aW1lIGlzIG5vdyBhZHZpc2Vk IHRvIGJlIGF0IGxlYXN0OiANCj4gICBOT05fTElGRVRJTUUgKyBNQVhfTEFURU5DWSArIE1BWF9T RVJWRVJfUkVTUE9OU0VfREVMQVkNCj4gd2hpY2ggaXMgaW4gdGhlIG9yZGVyIG9mIHNldmVyYWwg bWludXRlcy4gTm90ZSB0aGF0IHRoZXJlIGlzIG5vIA0KPiBsaW1pdCBvbiBNQVhfU0VSVkVSX1JF U1BPTlNFX0RFTEFZIGluIHRoZSBDb0FQIHByb3RvY29sLCBqdXN0IGxpa2UgDQo+IGluIHRoZSBI VFRQIGNhc2UuDQo+IA0KSW5kZWVkLiBXZSBoYXZlIGFsc28gbWVudGlvbmVkIHNpbWlsYXIgc3Vn Z2VzdGlvbiBpbiBzZWN0aW9uIDUuMiBvZiANCmh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFm dC10Y3MtY29hcC1uby1yZXNwb25zZS1vcHRpb24tMDYudHh0DQp0byBrZWVwIHN5bmVyZ3kuIEly cmVzcGVjdGl2ZSBvZiB3aGV0aGVyIHRoZSBjbGllbnQgZXhwbGljaXRseSBleHByZXNzZXMgDQpk aXNpbnRlcmVzdCBpbiB0aGUgcmVzcG9uc2UgKHVzaW5nIE5vLVJlc3BvbnNlIG9wdGlvbikgb3Ig dGhlIHNlcnZlciANCmRlY2lkZXMgb24gaXRzIG93biB0byBzdXBwcmVzcyByZXNwb25zZXMgKGFz IGluIG11bHRpY2FzdCkgdGhlIHByb2JsZW0gDQp1bHRpbWF0ZWx5IGJvaWxzIGRvd24gdG8gc2Vy dmVyJ3MgdW5jZXJ0YWludHkgaW4gcmVzcG9uZGluZy4gDQoNCg0KUmVnYXJkcw0KQWJoaWphbiBC aGF0dGFjaGFyeXlhDQpBc3NvY2lhdGUgQ29uc3VsdGFudA0KU2NpZW50aXN0LCBJbm5vdmF0aW9u IExhYiwgS29sa2F0YSwgSW5kaWENClRhdGEgQ29uc3VsdGFuY3kgU2VydmljZXMgTGltaXRlZA0K TWFpbHRvOiBhYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbQ0KV2Vic2l0ZTogaHR0cDovL3d3 dy50Y3MuY29tDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K RXhwZXJpZW5jZSBjZXJ0YWludHkuICAgSVQgU2VydmljZXMNCiAgICAgICAgICAgICAgICAgICAg ICAgIEJ1c2luZXNzIFNvbHV0aW9ucw0KICAgICAgICAgICAgICAgICAgICAgICAgQ29uc3VsdGlu Zw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj09PT09LS0t LS09PT09PS0tLS0tPT09PT0KTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRo aXMgZS1tYWlsCm1lc3NhZ2UgYW5kL29yIGF0dGFjaG1lbnRzIHRvIGl0IG1heSBjb250YWluIApj b25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbi4gSWYgeW91IGFyZSAKbm90IHRo ZSBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNzZW1pbmF0aW9uLCB1c2UsIApyZXZpZXcsIGRp c3RyaWJ1dGlvbiwgcHJpbnRpbmcgb3IgY29weWluZyBvZiB0aGUgCmluZm9ybWF0aW9uIGNvbnRh aW5lZCBpbiB0aGlzIGUtbWFpbCBtZXNzYWdlIAphbmQvb3IgYXR0YWNobWVudHMgdG8gaXQgYXJl IHN0cmljdGx5IHByb2hpYml0ZWQuIElmIAp5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmlj YXRpb24gaW4gZXJyb3IsIApwbGVhc2Ugbm90aWZ5IHVzIGJ5IHJlcGx5IGUtbWFpbCBvciB0ZWxl cGhvbmUgYW5kIAppbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBtZXNzYWdl IAphbmQgYW55IGF0dGFjaG1lbnRzLiBUaGFuayB5b3UKCgo= --=_alternative 0033ABE565257D09_= MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEVza28sPC9mb250Pg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PiZndDsgVGhlIFRva2VuIHZhbHVlIHJlLXVzZSBndWlkZWxpbmUgaXMgYW4gYWRkaXRpb24NCmJh c2VkIG9uIHRoZSA8YnI+DQomZ3Q7IGRpc2N1c3Npb24gdGhyZWFkIOKAnEhhbmRsaW5nIHRva2Vu cyBmb3IgTm8tcmVzcG9uc2XigJ0sIHdoZXJlIHRoaXMNCjxicj4NCiZndDsgaXNzdWUgd2FzIGlk ZW50aWZpZWQuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEZvciBtdWx0 aWNhc3QgdGhlIFRva2VuIHJlLXVzZSB0aW1lIGlzIG5vdyBhZHZpc2VkDQp0byBiZSBhdCBsZWFz dDogPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyBOT05fTElG RVRJTUUgKyBNQVhfTEFURU5DWSArIE1BWF9TRVJWRVJfUkVTUE9OU0VfREVMQVk8L2ZvbnQ+PC90 dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgd2hpY2ggaXMgaW4gdGhlIG9yZGVyIG9mIHNl dmVyYWwgbWludXRlcy4gTm90ZQ0KdGhhdCB0aGVyZSBpcyBubyA8YnI+DQomZ3Q7IGxpbWl0IG9u IE1BWF9TRVJWRVJfUkVTUE9OU0VfREVMQVkgaW4gdGhlIENvQVAgcHJvdG9jb2wsIGp1c3QgbGlr ZQ0KPGJyPg0KJmd0OyBpbiB0aGUgSFRUUCBjYXNlLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+Jmd0OyA8YnI+DQo8L2ZvbnQ+PC90dD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+SW5kZWVkLiBXZSBoYXZlIGFsc28gbWVudGlvbmVkDQpzaW1pbGFyIHN1Z2dlc3Rpb24g aW4gc2VjdGlvbiA1LjIgb2YgPC9mb250PjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9p ZC9kcmFmdC10Y3MtY29hcC1uby1yZXNwb25zZS1vcHRpb24tMDYudHh0Ij48Zm9udCBzaXplPTMg Y29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2Ry YWZ0LXRjcy1jb2FwLW5vLXJlc3BvbnNlLW9wdGlvbi0wNi50eHQ8L2ZvbnQ+PC9hPg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj50byBrZWVwIHN5bmVyZ3kuIElycmVzcGVjdGl2 ZSBvZiB3aGV0aGVyDQp0aGUgY2xpZW50IGV4cGxpY2l0bHkgZXhwcmVzc2VzIGRpc2ludGVyZXN0 IGluIHRoZSByZXNwb25zZSAodXNpbmcgTm8tUmVzcG9uc2UNCm9wdGlvbikgb3IgdGhlIHNlcnZl ciBkZWNpZGVzIG9uIGl0cyBvd24gdG8gc3VwcHJlc3MgcmVzcG9uc2VzIChhcyBpbiBtdWx0aWNh c3QpDQp0aGUgcHJvYmxlbSB1bHRpbWF0ZWx5IGJvaWxzIGRvd24gdG8gc2VydmVyJ3MgdW5jZXJ0 YWludHkgaW4gcmVzcG9uZGluZy4NCiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KUmVnYXJkczxicj4NCkFiaGlqYW4gQmhhdHRhY2hh cnl5YTxicj4NCkFzc29jaWF0ZSBDb25zdWx0YW50PGJyPg0KU2NpZW50aXN0LCBJbm5vdmF0aW9u IExhYiwgS29sa2F0YSwgSW5kaWE8YnI+DQpUYXRhIENvbnN1bHRhbmN5IFNlcnZpY2VzIExpbWl0 ZWQ8YnI+DQpNYWlsdG86IGFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tPGJyPg0KV2Vic2l0 ZTogPC9mb250PjxhIGhyZWY9aHR0cDovL3d3dy50Y3MuY29tLz48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+aHR0cDovL3d3dy50Y3MuY29tPC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQpFeHBlcmllbmNlIGNlcnRhaW50eS4gJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7SVQgU2VydmljZXM8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QnVzaW5l c3MgU29sdXRpb25zPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0NvbnN1bHRpbmc8 YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvZm9udD4N PHA+PT09PT0tLS0tLT09PT09LS0tLS09PT09PTxicj4KTm90aWNlOiBUaGUgaW5mb3JtYXRpb24g Y29udGFpbmVkIGluIHRoaXMgZS1tYWlsPGJyPgptZXNzYWdlIGFuZC9vciBhdHRhY2htZW50cyB0 byBpdCBtYXkgY29udGFpbiA8YnI+CmNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0 aW9uLiBJZiB5b3UgYXJlIDxicj4Kbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNz ZW1pbmF0aW9uLCB1c2UsIDxicj4KcmV2aWV3LCBkaXN0cmlidXRpb24sIHByaW50aW5nIG9yIGNv cHlpbmcgb2YgdGhlIDxicj4KaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgZS1tYWlsIG1l c3NhZ2UgPGJyPgphbmQvb3IgYXR0YWNobWVudHMgdG8gaXQgYXJlIHN0cmljdGx5IHByb2hpYml0 ZWQuIElmIDxicj4KeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9y LCA8YnI+CnBsZWFzZSBub3RpZnkgdXMgYnkgcmVwbHkgZS1tYWlsIG9yIHRlbGVwaG9uZSBhbmQg PGJyPgppbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBtZXNzYWdlIDxicj4K YW5kIGFueSBhdHRhY2htZW50cy4gVGhhbmsgeW91PC9wPgoKPHA+PC9wPg== --=_alternative 0033ABE565257D09_=-- From nobody Fri Jul 4 00:12:03 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F103A1B2791 for ; Fri, 4 Jul 2014 00:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hen04wkAorVy for ; Fri, 4 Jul 2014 00:11:59 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 161A91B278A for ; Fri, 4 Jul 2014 00:11:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJP78190; Fri, 04 Jul 2014 07:11:56 +0000 (GMT) Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 4 Jul 2014 08:11:52 +0100 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.128]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Fri, 4 Jul 2014 15:11:46 +0800 From: Likepeng To: Abhijan Bhattacharyya , "core@ietf.org" , "esko.dijk@philips.com" Thread-Topic: [core] Updates in core-groupcomm-19 Thread-Index: AQHPldd08nBZb5MKhU6ginJ+79RmBpuPe1OQ Date: Fri, 4 Jul 2014 07:11:45 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F258173A43@SZXEMA501-MBS.china.huawei.com> References: 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.66.167.122] Content-Type: multipart/alternative; boundary="_000_34966E97BE8AD64EAE9D3D6E4DEE36F258173A43SZXEMA501MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/core/xtUzu8I2iID7MWf922xrWAj5Xsw Subject: Re: [core] Updates in core-groupcomm-19 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 04 Jul 2014 07:12:01 -0000 --_000_34966E97BE8AD64EAE9D3D6E4DEE36F258173A43SZXEMA501MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5JcnJlc3BlY3RpdmUgb2Ygd2hldGhlciB0aGUgY2xpZW50IGV4cGxpY2l0bHkgZXhw cmVzc2VzIGRpc2ludGVyZXN0IGluIHRoZSByZXNwb25zZSAodXNpbmcgTm8tUmVzcG9uc2Ugb3B0 aW9uKSBvciB0aGUgc2VydmVyIGRlY2lkZXMgb24gaXRzIG93biB0byBzdXBwcmVzcyByZXNwb25z ZXMgKGFzIGluIG11bHRpY2FzdCkgdGhlIHByb2JsZW0gdWx0aW1hdGVseSBib2lscyBkb3duIHRv IHNlcnZlcidzIHVuY2VydGFpbnR5IGluIHJlc3BvbmRpbmcuDQoNCkFub3RoZXIgcG9zc2liaWxp dHkgZm9yIHRoZSBzZXJ2ZXIgdG8gc3VwcHJlc3MgcmVzcG9uc2VzIGNhbiBiZSBiYXNlZCBvbiDi gJxQYXRpZW5jZeKAnSBvcHRpb24gcHJvcG9zZWQgaW4gdGhpcyBkcmFmdDoNCmh0dHA6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGktY29yZS1jb2FwLXBhdGllbmNlLW9wdGlvbi8N Cg0KSWYgdGhlIHNlcnZlciByZXNwb25zZSB0aW1lIGV4Y2VlZHMgdGhlIOKAnFBhdGllbmNl4oCd IHZhbHVlIHNwZWNpZmllZCBpbiB0aGUgY2xpZW50IHJlcXVlc3QsIHRoZSBzZXJ2ZXIgc2hvdWxk IHN1cHByZXNzIHRoZSByZXNwb25zZS4NCg0KS2luZCBSZWdhcmRzDQpLZXBlbmcNCg0K5Y+R5Lu2 5Lq6OiBjb3JlIFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnXSDku6PooaggQWJoaWphbiBC aGF0dGFjaGFyeXlhDQrlj5HpgIHml7bpl7Q6IDIwMTTlubQ35pyIMuaXpSAxNzoyNA0K5pS25Lu2 5Lq6OiBjb3JlQGlldGYub3JnOyBlc2tvLmRpamtAcGhpbGlwcy5jb20NCuS4u+mimDogUmU6IFtj b3JlXSBVcGRhdGVzIGluIGNvcmUtZ3JvdXBjb21tLTE5DQoNCkhpIEVza28sDQo+DQo+IFRoZSBU b2tlbiB2YWx1ZSByZS11c2UgZ3VpZGVsaW5lIGlzIGFuIGFkZGl0aW9uIGJhc2VkIG9uIHRoZQ0K PiBkaXNjdXNzaW9uIHRocmVhZCDigJxIYW5kbGluZyB0b2tlbnMgZm9yIE5vLXJlc3BvbnNl4oCd LCB3aGVyZSB0aGlzDQo+IGlzc3VlIHdhcyBpZGVudGlmaWVkLg0KPiBGb3IgbXVsdGljYXN0IHRo ZSBUb2tlbiByZS11c2UgdGltZSBpcyBub3cgYWR2aXNlZCB0byBiZSBhdCBsZWFzdDoNCj4gICBO T05fTElGRVRJTUUgKyBNQVhfTEFURU5DWSArIE1BWF9TRVJWRVJfUkVTUE9OU0VfREVMQVkNCj4g d2hpY2ggaXMgaW4gdGhlIG9yZGVyIG9mIHNldmVyYWwgbWludXRlcy4gTm90ZSB0aGF0IHRoZXJl IGlzIG5vDQo+IGxpbWl0IG9uIE1BWF9TRVJWRVJfUkVTUE9OU0VfREVMQVkgaW4gdGhlIENvQVAg cHJvdG9jb2wsIGp1c3QgbGlrZQ0KPiBpbiB0aGUgSFRUUCBjYXNlLg0KPg0KSW5kZWVkLiBXZSBo YXZlIGFsc28gbWVudGlvbmVkIHNpbWlsYXIgc3VnZ2VzdGlvbiBpbiBzZWN0aW9uIDUuMiBvZiBo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtdGNzLWNvYXAtbm8tcmVzcG9uc2Utb3B0aW9u LTA2LnR4dA0KdG8ga2VlcCBzeW5lcmd5LiBJcnJlc3BlY3RpdmUgb2Ygd2hldGhlciB0aGUgY2xp ZW50IGV4cGxpY2l0bHkgZXhwcmVzc2VzIGRpc2ludGVyZXN0IGluIHRoZSByZXNwb25zZSAodXNp bmcgTm8tUmVzcG9uc2Ugb3B0aW9uKSBvciB0aGUgc2VydmVyIGRlY2lkZXMgb24gaXRzIG93biB0 byBzdXBwcmVzcyByZXNwb25zZXMgKGFzIGluIG11bHRpY2FzdCkgdGhlIHByb2JsZW0gdWx0aW1h dGVseSBib2lscyBkb3duIHRvIHNlcnZlcidzIHVuY2VydGFpbnR5IGluIHJlc3BvbmRpbmcuDQoN Cg0KUmVnYXJkcw0KQWJoaWphbiBCaGF0dGFjaGFyeXlhDQpBc3NvY2lhdGUgQ29uc3VsdGFudA0K U2NpZW50aXN0LCBJbm5vdmF0aW9uIExhYiwgS29sa2F0YSwgSW5kaWENClRhdGEgQ29uc3VsdGFu Y3kgU2VydmljZXMgTGltaXRlZA0KTWFpbHRvOiBhYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNv bTxtYWlsdG86YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb20+DQpXZWJzaXRlOiBodHRwOi8v d3d3LnRjcy5jb208aHR0cDovL3d3dy50Y3MuY29tLz4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpFeHBlcmllbmNlIGNlcnRhaW50eS4gICAgICAgIElUIFNl cnZpY2VzDQogICAgICAgICAgICAgICAgICAgICAgIEJ1c2luZXNzIFNvbHV0aW9ucw0KICAgICAg ICAgICAgICAgICAgICAgICBDb25zdWx0aW5nDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KDQo9PT09PS0tLS0tPT09PT0tLS0tLT09PT09DQpOb3RpY2U6IFRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBlLW1haWwNCm1lc3NhZ2UgYW5kL29yIGF0 dGFjaG1lbnRzIHRvIGl0IG1heSBjb250YWluDQpjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBp bmZvcm1hdGlvbi4gSWYgeW91IGFyZQ0Kbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBk aXNzZW1pbmF0aW9uLCB1c2UsDQpyZXZpZXcsIGRpc3RyaWJ1dGlvbiwgcHJpbnRpbmcgb3IgY29w eWluZyBvZiB0aGUNCmluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFpbCBtZXNzYWdl DQphbmQvb3IgYXR0YWNobWVudHMgdG8gaXQgYXJlIHN0cmljdGx5IHByb2hpYml0ZWQuIElmDQp5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsDQpwbGVhc2Ugbm90 aWZ5IHVzIGJ5IHJlcGx5IGUtbWFpbCBvciB0ZWxlcGhvbmUgYW5kDQppbW1lZGlhdGVseSBhbmQg cGVybWFuZW50bHkgZGVsZXRlIHRoZSBtZXNzYWdlDQphbmQgYW55IGF0dGFjaG1lbnRzLiBUaGFu ayB5b3UNCg== --_000_34966E97BE8AD64EAE9D3D6E4DEE36F258173A43SZXEMA501MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQp0dA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnNwYW4uRW1haWxTdHlsZTE5 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0O0lycmVzcGVjdGl2ZSBv ZiB3aGV0aGVyIHRoZSBjbGllbnQgZXhwbGljaXRseSBleHByZXNzZXMgZGlzaW50ZXJlc3QgaW4g dGhlIHJlc3BvbnNlICh1c2luZyBOby1SZXNwb25zZSBvcHRpb24pIG9yIHRoZSBzZXJ2ZXIgZGVj aWRlcyBvbiBpdHMgb3duIHRvIHN1cHByZXNzIHJlc3BvbnNlcw0KIChhcyBpbiBtdWx0aWNhc3Qp IHRoZSBwcm9ibGVtIHVsdGltYXRlbHkgYm9pbHMgZG93biB0byBzZXJ2ZXIncyB1bmNlcnRhaW50 eSBpbiByZXNwb25kaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+QW5vdGhlciBwb3NzaWJpbGl0eSBmb3IgdGhlIHNlcnZlciB0 byBzdXBwcmVzcyByZXNwb25zZXMgY2FuIGJlIGJhc2VkIG9uIOKAnFBhdGllbmNl4oCdIG9wdGlv biBwcm9wb3NlZCBpbiB0aGlzIGRyYWZ0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBo cmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxpLWNvcmUtY29hcC1w YXRpZW5jZS1vcHRpb24vIj5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxp LWNvcmUtY29hcC1wYXRpZW5jZS1vcHRpb24vPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SWYgdGhlIHNlcnZlciByZXNwb25z ZSB0aW1lIGV4Y2VlZHMgdGhlIOKAnFBhdGllbmNl4oCdIHZhbHVlIHNwZWNpZmllZCBpbiB0aGUg Y2xpZW50IHJlcXVlc3QsIHRoZSBzZXJ2ZXIgc2hvdWxkIHN1cHByZXNzIHRoZSByZXNwb25zZS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPktpbmQgUmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5LZXBlbmc8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPuWPkeS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4gY29yZSBbbWFpbHRv OmNvcmUtYm91bmNlc0BpZXRmLm9yZ10NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdCI+5Luj6KGoIDwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0Ij5BYmhpamFuIEJoYXR0YWNoYXJ5eWE8YnI+DQo8L3NwYW4+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuWPkemAgeaXtumXtDxzcGFuIGxhbmc9IkVOLVVTIj46 PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij4gMjAxNDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5bm0PHNwYW4g bGFuZz0iRU4tVVMiPjc8L3NwYW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjI8L3NwYW4+5pelPHNw YW4gbGFuZz0iRU4tVVMiPiAxNzoyNDxicj4NCjwvc3Bhbj48Yj7mlLbku7bkuro8c3BhbiBsYW5n PSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBjb3JlQGlldGYub3JnOyBl c2tvLmRpamtAcGhpbGlwcy5jb208YnI+DQo8L3NwYW4+PGI+5Li76aKYPHNwYW4gbGFuZz0iRU4t VVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gUmU6IFtjb3JlXSBVcGRhdGVzIGlu IGNvcmUtZ3JvdXBjb21tLTE5PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkhpIEVza28sPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij4NCjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij4mZ3Q7ICZuYnNwOzwvc3Bhbj48L3R0PjxzcGFuIGxhbmc9IkVOLVVTIj4NCjxicj4N Cjwvc3Bhbj48dHQ+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4m Z3Q7IFRoZSBUb2tlbiB2YWx1ZSByZS11c2UgZ3VpZGVsaW5lIGlzIGFuIGFkZGl0aW9uIGJhc2Vk IG9uIHRoZQ0KPC9zcGFuPjwvdHQ+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij48YnI+DQo8dHQ+Jmd0OyBkaXNjdXNzaW9uIHRocmVhZCDigJxIYW5kbGluZyB0b2tl bnMgZm9yIE5vLXJlc3BvbnNl4oCdLCB3aGVyZSB0aGlzIDwvdHQ+PGJyPg0KPHR0PiZndDsgaXNz dWUgd2FzIGlkZW50aWZpZWQuPC90dD48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPiA8YnI+DQo8 L3NwYW4+PHR0PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0 OyBGb3IgbXVsdGljYXN0IHRoZSBUb2tlbiByZS11c2UgdGltZSBpcyBub3cgYWR2aXNlZCB0byBi ZSBhdCBsZWFzdDoNCjwvc3Bhbj48L3R0PjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8L3NwYW4+ PHR0PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyAmbmJz cDsgTk9OX0xJRkVUSU1FICYjNDM7IE1BWF9MQVRFTkNZICYjNDM7IE1BWF9TRVJWRVJfUkVTUE9O U0VfREVMQVk8L3NwYW4+PC90dD48c3BhbiBsYW5nPSJFTi1VUyI+DQo8YnI+DQo8L3NwYW4+PHR0 PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyB3aGljaCBp cyBpbiB0aGUgb3JkZXIgb2Ygc2V2ZXJhbCBtaW51dGVzLiBOb3RlIHRoYXQgdGhlcmUgaXMgbm8N Cjwvc3Bhbj48L3R0PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ PGJyPg0KPHR0PiZndDsgbGltaXQgb24gTUFYX1NFUlZFUl9SRVNQT05TRV9ERUxBWSBpbiB0aGUg Q29BUCBwcm90b2NvbCwganVzdCBsaWtlIDwvdHQ+PGJyPg0KPHR0PiZndDsgaW4gdGhlIEhUVFAg Y2FzZS48L3R0Pjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+IDxicj4NCjwvc3Bhbj48dHQ+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7IDwvc3Bhbj48L3R0 PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PGJyPg0KPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JbmRlZWQuIFdlIGhhdmUg YWxzbyBtZW50aW9uZWQgc2ltaWxhciBzdWdnZXN0aW9uIGluIHNlY3Rpb24gNS4yIG9mDQo8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9k cmFmdC10Y3MtY29hcC1uby1yZXNwb25zZS1vcHRpb24tMDYudHh0Ij48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9p ZC9kcmFmdC10Y3MtY29hcC1uby1yZXNwb25zZS1vcHRpb24tMDYudHh0PC9zcGFuPjwvYT4NCjxi cj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+dG8ga2Vl cCBzeW5lcmd5LiBJcnJlc3BlY3RpdmUgb2Ygd2hldGhlciB0aGUgY2xpZW50IGV4cGxpY2l0bHkg ZXhwcmVzc2VzIGRpc2ludGVyZXN0IGluIHRoZSByZXNwb25zZSAodXNpbmcgTm8tUmVzcG9uc2Ug b3B0aW9uKSBvciB0aGUgc2VydmVyIGRlY2lkZXMgb24gaXRzIG93biB0byBzdXBwcmVzcw0KIHJl c3BvbnNlcyAoYXMgaW4gbXVsdGljYXN0KSB0aGUgcHJvYmxlbSB1bHRpbWF0ZWx5IGJvaWxzIGRv d24gdG8gc2VydmVyJ3MgdW5jZXJ0YWludHkgaW4gcmVzcG9uZGluZy4gJm5ic3A7PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+PGJyPg0KPGJyPg0KUmVnYXJkczxicj4NCkFiaGlqYW4gQmhhdHRhY2hh cnl5YTxicj4NCkFzc29jaWF0ZSBDb25zdWx0YW50PGJyPg0KU2NpZW50aXN0LCBJbm5vdmF0aW9u IExhYiwgS29sa2F0YSwgSW5kaWE8YnI+DQpUYXRhIENvbnN1bHRhbmN5IFNlcnZpY2VzIExpbWl0 ZWQ8YnI+DQpNYWlsdG86IDxhIGhyZWY9Im1haWx0bzphYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNz LmNvbSI+YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb208L2E+PGJyPg0KV2Vic2l0ZTogPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRwOi8vd3d3LnRjcy5jb20vIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5odHRwOi8vd3d3LnRjcy5jb208L3NwYW4+PC9hPjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpFeHBlcmllbmNlIGNlcnRh aW50eS4gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SVQgU2VydmljZXM8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO0J1c2luZXNzIFNvbHV0aW9uczxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7Q29uc3VsdGluZzxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4gPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPj09PT09LS0tLS09PT09PS0tLS0tPT09PT08 YnI+DQpOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBlLW1haWw8YnI+ DQptZXNzYWdlIGFuZC9vciBhdHRhY2htZW50cyB0byBpdCBtYXkgY29udGFpbiA8YnI+DQpjb25m aWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbi4gSWYgeW91IGFyZSA8YnI+DQpub3Qg dGhlIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc3NlbWluYXRpb24sIHVzZSwgPGJyPg0KcmV2 aWV3LCBkaXN0cmlidXRpb24sIHByaW50aW5nIG9yIGNvcHlpbmcgb2YgdGhlIDxicj4NCmluZm9y bWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFpbCBtZXNzYWdlIDxicj4NCmFuZC9vciBhdHRh Y2htZW50cyB0byBpdCBhcmUgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgPGJyPg0KeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCA8YnI+DQpwbGVhc2Ugbm90aWZ5 IHVzIGJ5IHJlcGx5IGUtbWFpbCBvciB0ZWxlcGhvbmUgYW5kIDxicj4NCmltbWVkaWF0ZWx5IGFu ZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG1lc3NhZ2UgPGJyPg0KYW5kIGFueSBhdHRhY2htZW50 cy4gVGhhbmsgeW91PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_34966E97BE8AD64EAE9D3D6E4DEE36F258173A43SZXEMA501MBSchi_-- From nobody Fri Jul 4 00:35:28 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C133C1B2C45 for ; Fri, 4 Jul 2014 00:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOICaHwo5yuA for ; Fri, 4 Jul 2014 00:35:24 -0700 (PDT) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 40DC51B2C40 for ; Fri, 4 Jul 2014 00:35:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,599,1400005800"; d="scan'208";a="552735350" X-DISCLAIMER: FALSE Received: from INKOLSALDLPMTA1.india.tcs.com (unknown [127.0.0.1]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id 714FFDAC12; Fri, 4 Jul 2014 13:05:20 +0530 (IST) Received: from InKolM02.tcs.com (unknown [172.18.18.104]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id 290C2DAC02; Fri, 4 Jul 2014 13:05:20 +0530 (IST) In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F258173A43@SZXEMA501-MBS.china.huawei.com> References: <34966E97BE8AD64EAE9D3D6E4DEE36F258173A43@SZXEMA501-MBS.china.huawei.com> To: Likepeng MIME-Version: 1.0 X-KeepSent: 05B97B76:75DB609F-65257D0B:00292A9D; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0 March 08, 2013 Message-ID: From: Abhijan Bhattacharyya Date: Fri, 4 Jul 2014 13:05:18 +0530 X-MIMETrack: Serialize by Notes Server on InKolM02/TCS(Release 9.0.1HF198 | January 23, 2014) at 07/04/2014 13:05:20, Serialize complete at 07/04/2014 13:05:20, Serialize by Router on InKolM02/TCS(Release 9.0.1HF198 | January 23, 2014) at 07/04/2014 13:05:20 Content-Type: multipart/alternative; boundary="=_alternative 0029AE3165257D0B_=" Archived-At: http://mailarchive.ietf.org/arch/msg/core/NekzO31xIfRCfZ3O2OshlUnqj14 Cc: "core@ietf.org" Subject: Re: [core] Updates in core-groupcomm-19 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 04 Jul 2014 07:35:26 -0000 This is a multipart message in MIME format. --=_alternative 0029AE3165257D0B_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgS2VwZW5nLA0KWWVzLCB0aGF0IGlzIHRvdWNoZWQgdXBvbiBpbiBTZWN0aW9uIDUuMiAoUmUt dXNpbmcgVG9rZW5zKSBvZiANCmh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC10Y3MtY29h cC1uby1yZXNwb25zZS1vcHRpb24tMDYudHh0Lg0KSGVyZSBpcyBzb21lIGV4Y2VycHQgZnJvbSB0 aGUgYWJvdmUgbWVudGlvbmVkIHNlY3Rpb24gZm9yIHJlYWR5IHJlZmVyZW5jZToNCg0KIlNvIHRo ZSBjbGllbnQgaW1wbGVtZW50YXRpb24gc2hvdWxkIGltcGxlbWVudCBhbiBhcHBsaWNhdGlvbg0K ICAgc3BlY2lmaWMgJ3BhdGllbmNlJyB0aW1lIHRpbGwgd2hpY2ggaXQgY2FuIHJlLXVzZSB0aGUg dG9rZW4uDQogICBBcHBlbmRpeC1CLjQuMSBvZiBbSS1ELmRyYWZ0LWJvcm1hbm4tY29hcC1taXNj XSBkZWZpbmVzICdwYXRpZW5jZScNCiAgIG9wdGlvbiB3aGljaCBpbiBlZmZlY3QgcHV0cyBhIGRl YWRsaW5lIHRvIHRoZSBzZXJ2ZXIgdG8gcmVzcG9uZA0KICAgYmFjay4gSG93ZXZlciwgJ3BhdGll bmNlJyBpcyBub3QgZXhwb3NlZCB0byB0aGUgcHJvdG9jb2wgbGV2ZWwgYXQNCiAgIHByZXNlbnQu IEhlbmNlLCBhIHJldXNlIHRpbWUgZm9yIHRva2VucyBpcyBzdWdnZXN0ZWQgd2l0aCBzaW1pbGFy DQogICBleHByZXNzaW9uIGFzIGluIFNlY3Rpb24gMi41IG9mIFtJLUQuaWV0Zi1jb3JlLWdyb3Vw Y29tbV06DQoNCiAgIFRPS0VOX1JFVVNFX1RJTUUgPSBOT05fTElGRVRJTUUgKyBNQVhfU0VSVkVS X1JFU1BPTlNFX0RFTEFZICsNCiAgIE1BWF9MQVRFTkNZLg0KDQogICBOT05fTElGRVRJTUUgYW5k IE1BWF9MQVRFTkNZIGFyZSBkZWZpbmVkIGluIDQuOC4yIG9mIFtJLUQuaWV0Zi1jb3JlLQ0KICAg Y29hcF0uIE1BWF9TRVJWRVJfUkVTUE9OU0VfREVMQVkgaGFzIHNhbWUgaW50ZXJwcmV0YXRpb24g YXMgaW4NCiAgIFNlY3Rpb24gMi41IG9mIFtJLUQuaWV0Zi1jb3JlLWdyb3VwY29tbV0gZm9yIG11 bHRpY2FzdCByZXF1ZXN0LiBCdXQNCiAgIGZvciB1bmljYXN0IHJlcXVlc3QgTUFYX1NFUlZFUl9S RVNQT05TRV9ERUxBWSBpcyBzaW1wbHkgdGhlIGV4cGVjdGVkDQogICBtYXhpbXVtIHJlc3BvbnNl IGRlbGF5IGZyb20gdGhlIHNlcnZlciB0byB3aGljaCBjbGllbnQgc2VudCB0aGUNCiAgIHJlcXVl c3QuIFRoaXMgZGVsYXkgaW5jbHVkZXMgdGhlIG1heGltdW0gTGVpc3VyZSB0aW1lIHBlcmlvZCBh cw0KICAgZGVmaW5lZCBpbiBTZWN0aW9uIDguMiBvZiBbSS1ELmlldGYtY29yZS1jb2FwXSBhbmQg QXBwZW5kaXgtQi40LjIgb2YNCiAgIFtJLUQuZHJhZnQtYm9ybWFubi1jb2FwLW1pc2Ndd2hlcmUg Z3JvdXAgc2l6ZSAoRykgPSAxIGZvciB1bmljYXN0DQogICByZXF1ZXN0LiINCg0KDQpSZWdhcmRz DQpBYmhpamFuIEJoYXR0YWNoYXJ5eWENCkFzc29jaWF0ZSBDb25zdWx0YW50DQpTY2llbnRpc3Qs IElubm92YXRpb24gTGFiLCBLb2xrYXRhLCBJbmRpYQ0KVGF0YSBDb25zdWx0YW5jeSBTZXJ2aWNl cyBMaW1pdGVkDQpNYWlsdG86IGFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tDQpXZWJzaXRl OiBodHRwOi8vd3d3LnRjcy5jb20NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpFeHBlcmllbmNlIGNlcnRhaW50eS4gICBJVCBTZXJ2aWNlcw0KICAgICAgICAg ICAgICAgICAgICAgICAgQnVzaW5lc3MgU29sdXRpb25zDQogICAgICAgICAgICAgICAgICAgICAg ICBDb25zdWx0aW5nDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KDQpMaWtlcGVuZyA8bGlrZXBlbmdAaHVhd2VpLmNvbT4gd3JvdGUgb24gMDcvMDQvMjAxNCAx Mjo0MTo0NSBQTToNCg0KPiBGcm9tOiBMaWtlcGVuZyA8bGlrZXBlbmdAaHVhd2VpLmNvbT4NCj4g VG86IEFiaGlqYW4gQmhhdHRhY2hhcnl5YSA8YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb20+ LCANCj4gImNvcmVAaWV0Zi5vcmciIDxjb3JlQGlldGYub3JnPiwgImVza28uZGlqa0BwaGlsaXBz LmNvbSIgDQo+IDxlc2tvLmRpamtAcGhpbGlwcy5jb20+DQo+IERhdGU6IDA3LzA0LzIwMTQgMTI6 NDIgUE0NCj4gU3ViamVjdDogUmU6IFtjb3JlXSBVcGRhdGVzIGluIGNvcmUtZ3JvdXBjb21tLTE5 DQo+IA0KPiBIaSwNCj4gDQo+ID5JcnJlc3BlY3RpdmUgb2Ygd2hldGhlciB0aGUgY2xpZW50IGV4 cGxpY2l0bHkgZXhwcmVzc2VzIGRpc2ludGVyZXN0DQo+IGluIHRoZSByZXNwb25zZSAodXNpbmcg Tm8tUmVzcG9uc2Ugb3B0aW9uKSBvciB0aGUgc2VydmVyIGRlY2lkZXMgb24gDQo+IGl0cyBvd24g dG8gc3VwcHJlc3MgcmVzcG9uc2VzIChhcyBpbiBtdWx0aWNhc3QpIHRoZSBwcm9ibGVtIA0KPiB1 bHRpbWF0ZWx5IGJvaWxzIGRvd24gdG8gc2VydmVyJ3MgdW5jZXJ0YWludHkgaW4gcmVzcG9uZGlu Zy4NCj4gDQo+IEFub3RoZXIgcG9zc2liaWxpdHkgZm9yIHRoZSBzZXJ2ZXIgdG8gc3VwcHJlc3Mg cmVzcG9uc2VzIGNhbiBiZSANCj4gYmFzZWQgb24gobBQYXRpZW5jZaGxIG9wdGlvbiBwcm9wb3Nl ZCBpbiB0aGlzIGRyYWZ0Og0KPiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWxpLWNvcmUtY29hcC1wYXRpZW5jZS1vcHRpb24vDQo+IA0KPiBJZiB0aGUgc2VydmVyIHJlc3Bv bnNlIHRpbWUgZXhjZWVkcyB0aGUgobBQYXRpZW5jZaGxIHZhbHVlIHNwZWNpZmllZCANCj4gaW4g dGhlIGNsaWVudCByZXF1ZXN0LCB0aGUgc2VydmVyIHNob3VsZCBzdXBwcmVzcyB0aGUgcmVzcG9u c2UuDQo+IA0KPiBLaW5kIFJlZ2FyZHMNCj4gS2VwZW5nDQo+IA0KPiC3orz+yMs6IGNvcmUgW21h aWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gQWJoaWphbiBCaGF0dGFjaGFyeXlhDQo+ ILeiy83KsbzkOiAyMDE0xOo31MIyyNUgMTc6MjQNCj4gytW8/sjLOiBjb3JlQGlldGYub3JnOyBl c2tvLmRpamtAcGhpbGlwcy5jb20NCj4g1vfM4jogUmU6IFtjb3JlXSBVcGRhdGVzIGluIGNvcmUt Z3JvdXBjb21tLTE5DQo+IA0KPiBIaSBFc2tvLCANCj4gPiANCj4gPiBUaGUgVG9rZW4gdmFsdWUg cmUtdXNlIGd1aWRlbGluZSBpcyBhbiBhZGRpdGlvbiBiYXNlZCBvbiB0aGUgDQo+ID4gZGlzY3Vz c2lvbiB0aHJlYWQgobBIYW5kbGluZyB0b2tlbnMgZm9yIE5vLXJlc3BvbnNlobEsIHdoZXJlIHRo aXMgDQo+ID4gaXNzdWUgd2FzIGlkZW50aWZpZWQuIA0KPiA+IEZvciBtdWx0aWNhc3QgdGhlIFRv a2VuIHJlLXVzZSB0aW1lIGlzIG5vdyBhZHZpc2VkIHRvIGJlIGF0IGxlYXN0OiANCj4gPiAgIE5P Tl9MSUZFVElNRSArIE1BWF9MQVRFTkNZICsgTUFYX1NFUlZFUl9SRVNQT05TRV9ERUxBWSANCj4g PiB3aGljaCBpcyBpbiB0aGUgb3JkZXIgb2Ygc2V2ZXJhbCBtaW51dGVzLiBOb3RlIHRoYXQgdGhl cmUgaXMgbm8gDQo+ID4gbGltaXQgb24gTUFYX1NFUlZFUl9SRVNQT05TRV9ERUxBWSBpbiB0aGUg Q29BUCBwcm90b2NvbCwganVzdCBsaWtlIA0KPiA+IGluIHRoZSBIVFRQIGNhc2UuIA0KPiA+IA0K PiBJbmRlZWQuIFdlIGhhdmUgYWxzbyBtZW50aW9uZWQgc2ltaWxhciBzdWdnZXN0aW9uIGluIHNl Y3Rpb24gNS4yIG9mIA0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtdGNzLWNvYXAt bm8tcmVzcG9uc2Utb3B0aW9uLTA2LnR4dCANCj4gdG8ga2VlcCBzeW5lcmd5LiBJcnJlc3BlY3Rp dmUgb2Ygd2hldGhlciB0aGUgY2xpZW50IGV4cGxpY2l0bHkgDQo+IGV4cHJlc3NlcyBkaXNpbnRl cmVzdCBpbiB0aGUgcmVzcG9uc2UgKHVzaW5nIE5vLVJlc3BvbnNlIG9wdGlvbikgb3IgDQo+IHRo ZSBzZXJ2ZXIgZGVjaWRlcyBvbiBpdHMgb3duIHRvIHN1cHByZXNzIHJlc3BvbnNlcyAoYXMgaW4g DQo+IG11bHRpY2FzdCkgdGhlIHByb2JsZW0gdWx0aW1hdGVseSBib2lscyBkb3duIHRvIHNlcnZl cidzIHVuY2VydGFpbnR5DQo+IGluIHJlc3BvbmRpbmcuIA0KPiANCj4gDQo+IFJlZ2FyZHMNCj4g QWJoaWphbiBCaGF0dGFjaGFyeXlhDQo+IEFzc29jaWF0ZSBDb25zdWx0YW50DQo+IFNjaWVudGlz dCwgSW5ub3ZhdGlvbiBMYWIsIEtvbGthdGEsIEluZGlhDQo+IFRhdGEgQ29uc3VsdGFuY3kgU2Vy dmljZXMgTGltaXRlZA0KPiBNYWlsdG86IGFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tDQo+ IFdlYnNpdGU6IGh0dHA6Ly93d3cudGNzLmNvbQ0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBFeHBlcmllbmNlIGNlcnRhaW50eS4gICAgICAgIElUIFNl cnZpY2VzDQo+ICAgICAgICAgICAgICAgICAgICAgICAgQnVzaW5lc3MgU29sdXRpb25zDQo+ICAg ICAgICAgICAgICAgICAgICAgICAgQ29uc3VsdGluZw0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXyANCj4gPT09PT0tLS0tLT09PT09LS0tLS09PT09PQ0KPiBO b3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBlLW1haWwNCj4gbWVzc2Fn ZSBhbmQvb3IgYXR0YWNobWVudHMgdG8gaXQgbWF5IGNvbnRhaW4gDQo+IGNvbmZpZGVudGlhbCBv ciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uLiBJZiB5b3UgYXJlIA0KPiBub3QgdGhlIGludGVuZGVk IHJlY2lwaWVudCwgYW55IGRpc3NlbWluYXRpb24sIHVzZSwgDQo+IHJldmlldywgZGlzdHJpYnV0 aW9uLCBwcmludGluZyBvciBjb3B5aW5nIG9mIHRoZSANCj4gaW5mb3JtYXRpb24gY29udGFpbmVk IGluIHRoaXMgZS1tYWlsIG1lc3NhZ2UgDQo+IGFuZC9vciBhdHRhY2htZW50cyB0byBpdCBhcmUg c3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgDQo+IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVu aWNhdGlvbiBpbiBlcnJvciwgDQo+IHBsZWFzZSBub3RpZnkgdXMgYnkgcmVwbHkgZS1tYWlsIG9y IHRlbGVwaG9uZSBhbmQgDQo+IGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhl IG1lc3NhZ2UgDQo+IGFuZCBhbnkgYXR0YWNobWVudHMuIFRoYW5rIHlvdQ0K --=_alternative 0029AE3165257D0B_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEtlcGVuZyw8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlllcywgdGhhdCBpcyB0b3VjaGVkIHVwb24gaW4g U2VjdGlvbg0KNS4yIChSZS11c2luZyBUb2tlbnMpIG9mIDwvZm9udD48YSBocmVmPSJodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtdGNzLWNvYXAtbm8tcmVzcG9uc2Utb3B0aW9uLTA2LnR4 dCI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+aHR0cDovL3Rvb2xz LmlldGYub3JnL2lkL2RyYWZ0LXRjcy1jb2FwLW5vLXJlc3BvbnNlLW9wdGlvbi0wNi50eHQ8L2Zv bnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4uPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5IZXJlIGlzIHNvbWUgZXhjZXJwdCBmcm9tIHRoZSBh Ym92ZQ0KbWVudGlvbmVkIHNlY3Rpb24gZm9yIHJlYWR5IHJlZmVyZW5jZTo8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90OzwvZm9udD48dHQ+PGZv bnQgc2l6ZT0zPlNvIHRoZQ0KY2xpZW50IGltcGxlbWVudGF0aW9uIHNob3VsZCBpbXBsZW1lbnQg YW4gYXBwbGljYXRpb248YnI+DQogJm5ic3A7IHNwZWNpZmljICdwYXRpZW5jZScgdGltZSB0aWxs IHdoaWNoIGl0IGNhbiByZS11c2UgdGhlIHRva2VuLjxicj4NCiAmbmJzcDsgQXBwZW5kaXgtQi40 LjEgb2YgW0ktRC5kcmFmdC1ib3JtYW5uLWNvYXAtbWlzY10gZGVmaW5lcyAncGF0aWVuY2UnPGJy Pg0KICZuYnNwOyBvcHRpb24gd2hpY2ggaW4gZWZmZWN0IHB1dHMgYSBkZWFkbGluZSB0byB0aGUg c2VydmVyIHRvIHJlc3BvbmQ8YnI+DQogJm5ic3A7IGJhY2suIEhvd2V2ZXIsICdwYXRpZW5jZScg aXMgbm90IGV4cG9zZWQgdG8gdGhlIHByb3RvY29sIGxldmVsDQphdDxicj4NCiAmbmJzcDsgcHJl c2VudC4gSGVuY2UsIGEgcmV1c2UgdGltZSBmb3IgdG9rZW5zIGlzIHN1Z2dlc3RlZCB3aXRoIHNp bWlsYXI8YnI+DQogJm5ic3A7IGV4cHJlc3Npb24gYXMgaW4gU2VjdGlvbiAyLjUgb2YgW0ktRC5p ZXRmLWNvcmUtZ3JvdXBjb21tXTo8YnI+DQo8YnI+DQogJm5ic3A7IFRPS0VOX1JFVVNFX1RJTUUg PSBOT05fTElGRVRJTUUgKyBNQVhfU0VSVkVSX1JFU1BPTlNFX0RFTEFZICs8YnI+DQogJm5ic3A7 IE1BWF9MQVRFTkNZLjxicj4NCjxicj4NCiAmbmJzcDsgTk9OX0xJRkVUSU1FIGFuZCBNQVhfTEFU RU5DWSBhcmUgZGVmaW5lZCBpbiA0LjguMiBvZiBbSS1ELmlldGYtY29yZS08YnI+DQogJm5ic3A7 IGNvYXBdLiBNQVhfU0VSVkVSX1JFU1BPTlNFX0RFTEFZIGhhcyBzYW1lIGludGVycHJldGF0aW9u IGFzIGluPGJyPg0KICZuYnNwOyBTZWN0aW9uIDIuNSBvZiBbSS1ELmlldGYtY29yZS1ncm91cGNv bW1dIGZvciBtdWx0aWNhc3QgcmVxdWVzdC4NCkJ1dDxicj4NCiAmbmJzcDsgZm9yIHVuaWNhc3Qg cmVxdWVzdCBNQVhfU0VSVkVSX1JFU1BPTlNFX0RFTEFZIGlzIHNpbXBseSB0aGUgZXhwZWN0ZWQ8 YnI+DQogJm5ic3A7IG1heGltdW0gcmVzcG9uc2UgZGVsYXkgZnJvbSB0aGUgc2VydmVyIHRvIHdo aWNoIGNsaWVudCBzZW50IHRoZTxicj4NCiAmbmJzcDsgcmVxdWVzdC4gVGhpcyBkZWxheSBpbmNs dWRlcyB0aGUgbWF4aW11bSBMZWlzdXJlIHRpbWUgcGVyaW9kIGFzPGJyPg0KICZuYnNwOyBkZWZp bmVkIGluIFNlY3Rpb24gOC4yIG9mIFtJLUQuaWV0Zi1jb3JlLWNvYXBdIGFuZCBBcHBlbmRpeC1C LjQuMg0Kb2Y8YnI+DQogJm5ic3A7IFtJLUQuZHJhZnQtYm9ybWFubi1jb2FwLW1pc2Ndd2hlcmUg Z3JvdXAgc2l6ZSAoRykgPSAxIGZvciB1bmljYXN0PGJyPg0KICZuYnNwOyByZXF1ZXN0LjwvZm9u dD48L3R0Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDs8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjxicj4NClJlZ2FyZHM8YnI+DQpB YmhpamFuIEJoYXR0YWNoYXJ5eWE8YnI+DQpBc3NvY2lhdGUgQ29uc3VsdGFudDxicj4NClNjaWVu dGlzdCwgSW5ub3ZhdGlvbiBMYWIsIEtvbGthdGEsIEluZGlhPGJyPg0KVGF0YSBDb25zdWx0YW5j eSBTZXJ2aWNlcyBMaW1pdGVkPGJyPg0KTWFpbHRvOiBhYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNz LmNvbTxicj4NCldlYnNpdGU6IDwvZm9udD48YSBocmVmPWh0dHA6Ly93d3cudGNzLmNvbS8+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmh0dHA6Ly93d3cudGNzLmNvbTwvZm9udD48L2E+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KRXhwZXJpZW5jZSBjZXJ0YWludHkuICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO0lUIFNlcnZpY2VzPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO0J1c2luZXNzIFNvbHV0aW9uczxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtDb25zdWx0aW5nPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188L2ZvbnQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5MaWtlcGVuZyAmbHQ7 bGlrZXBlbmdAaHVhd2VpLmNvbSZndDsgd3JvdGUgb24gMDcvMDQvMjAxNA0KMTI6NDE6NDUgUE06 PGJyPg0KPGJyPg0KJmd0OyBGcm9tOiBMaWtlcGVuZyAmbHQ7bGlrZXBlbmdAaHVhd2VpLmNvbSZn dDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgVG86IEFiaGlqYW4gQmhh dHRhY2hhcnl5YSAmbHQ7YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb20mZ3Q7LA0KPGJyPg0K Jmd0OyAmcXVvdDtjb3JlQGlldGYub3JnJnF1b3Q7ICZsdDtjb3JlQGlldGYub3JnJmd0OywgJnF1 b3Q7ZXNrby5kaWprQHBoaWxpcHMuY29tJnF1b3Q7DQo8YnI+DQomZ3Q7ICZsdDtlc2tvLmRpamtA cGhpbGlwcy5jb20mZ3Q7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IERh dGU6IDA3LzA0LzIwMTQgMTI6NDIgUE08L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PiZndDsgU3ViamVjdDogUmU6IFtjb3JlXSBVcGRhdGVzIGluIGNvcmUtZ3JvdXBjb21tLTE5PC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgSGksPC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmZ3Q7SXJyZXNwZWN0aXZlIG9mIHdoZXRoZXIgdGhlIGNs aWVudCBleHBsaWNpdGx5DQpleHByZXNzZXMgZGlzaW50ZXJlc3Q8YnI+DQomZ3Q7IGluIHRoZSBy ZXNwb25zZSAodXNpbmcgTm8tUmVzcG9uc2Ugb3B0aW9uKSBvciB0aGUgc2VydmVyIGRlY2lkZXMg b24NCjxicj4NCiZndDsgaXRzIG93biB0byBzdXBwcmVzcyByZXNwb25zZXMgKGFzIGluIG11bHRp Y2FzdCkgdGhlIHByb2JsZW0gPGJyPg0KJmd0OyB1bHRpbWF0ZWx5IGJvaWxzIGRvd24gdG8gc2Vy dmVyJ3MgdW5jZXJ0YWludHkgaW4gcmVzcG9uZGluZy48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m Z3Q7IEFub3RoZXIgcG9zc2liaWxpdHkgZm9yIHRoZSBzZXJ2ZXIgdG8gc3VwcHJlc3MNCnJlc3Bv bnNlcyBjYW4gYmUgPGJyPg0KJmd0OyBiYXNlZCBvbiChsFBhdGllbmNlobEgb3B0aW9uIHByb3Bv c2VkIGluIHRoaXMgZHJhZnQ6PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7 IDwvZm9udD48L3R0PjxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtbGktY29yZS1jb2FwLXBhdGllbmNlLW9wdGlvbi8iPjx0dD48Zm9udCBzaXplPTI+aHR0cDov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1saS1jb3JlLWNvYXAtcGF0aWVuY2Utb3B0 aW9uLzwvZm9udD48L3R0PjwvYT4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IElmIHRoZSBzZXJ2ZXIgcmVzcG9u c2UgdGltZSBleGNlZWRzIHRoZSChsFBhdGllbmNlobENCnZhbHVlIHNwZWNpZmllZCA8YnI+DQom Z3Q7IGluIHRoZSBjbGllbnQgcmVxdWVzdCwgdGhlIHNlcnZlciBzaG91bGQgc3VwcHJlc3MgdGhl IHJlc3BvbnNlLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgS2luZCBSZWdhcmRzPC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEtlcGVuZzwvZm9udD48L3R0Pg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZndDsgt6K8/sjLOiBjb3JlIFs8L2ZvbnQ+PC90dD48YSBocmVmPSJtYWlsdG86Y29y ZS1ib3VuY2VzQGlldGYub3JnIj48dHQ+PGZvbnQgc2l6ZT0yPm1haWx0bzpjb3JlLWJvdW5jZXNA aWV0Zi5vcmc8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj5dDQq0+rHtIEFiaGlqYW4g QmhhdHRhY2hhcnl5YTxicj4NCiZndDsgt6LLzcqxvOQ6IDIwMTTE6jfUwjLI1SAxNzoyNDxicj4N CiZndDsgytW8/sjLOiBjb3JlQGlldGYub3JnOyBlc2tvLmRpamtAcGhpbGlwcy5jb208YnI+DQom Z3Q7INb3zOI6IFJlOiBbY29yZV0gVXBkYXRlcyBpbiBjb3JlLWdyb3VwY29tbS0xOTwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPiZndDsgSGkgRXNrbywgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+ DQomZ3Q7ICZndDsgVGhlIFRva2VuIHZhbHVlIHJlLXVzZSBndWlkZWxpbmUgaXMgYW4gYWRkaXRp b24gYmFzZWQgb24gdGhlDQo8YnI+DQomZ3Q7ICZndDsgZGlzY3Vzc2lvbiB0aHJlYWQgobBIYW5k bGluZyB0b2tlbnMgZm9yIE5vLXJlc3BvbnNlobEsIHdoZXJlDQp0aGlzIDxicj4NCiZndDsgJmd0 OyBpc3N1ZSB3YXMgaWRlbnRpZmllZC4gPGJyPg0KJmd0OyAmZ3Q7IEZvciBtdWx0aWNhc3QgdGhl IFRva2VuIHJlLXVzZSB0aW1lIGlzIG5vdyBhZHZpc2VkIHRvIGJlIGF0IGxlYXN0Og0KPGJyPg0K Jmd0OyAmZ3Q7ICZuYnNwOyBOT05fTElGRVRJTUUgKyBNQVhfTEFURU5DWSArIE1BWF9TRVJWRVJf UkVTUE9OU0VfREVMQVkNCjxicj4NCiZndDsgJmd0OyB3aGljaCBpcyBpbiB0aGUgb3JkZXIgb2Yg c2V2ZXJhbCBtaW51dGVzLiBOb3RlIHRoYXQgdGhlcmUgaXMNCm5vIDxicj4NCiZndDsgJmd0OyBs aW1pdCBvbiBNQVhfU0VSVkVSX1JFU1BPTlNFX0RFTEFZIGluIHRoZSBDb0FQIHByb3RvY29sLCBq dXN0DQpsaWtlIDxicj4NCiZndDsgJmd0OyBpbiB0aGUgSFRUUCBjYXNlLiA8YnI+DQomZ3Q7ICZn dDsgPGJyPg0KJmd0OyBJbmRlZWQuIFdlIGhhdmUgYWxzbyBtZW50aW9uZWQgc2ltaWxhciBzdWdn ZXN0aW9uIGluIHNlY3Rpb24gNS4yIG9mDQo8YnI+DQomZ3Q7IDwvZm9udD48L3R0PjxhIGhyZWY9 Imh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC10Y3MtY29hcC1uby1yZXNwb25zZS1vcHRp b24tMDYudHh0Ij48dHQ+PGZvbnQgc2l6ZT0yPmh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFm dC10Y3MtY29hcC1uby1yZXNwb25zZS1vcHRpb24tMDYudHh0PC9mb250PjwvdHQ+PC9hPjx0dD48 Zm9udCBzaXplPTI+DQo8YnI+DQomZ3Q7IHRvIGtlZXAgc3luZXJneS4gSXJyZXNwZWN0aXZlIG9m IHdoZXRoZXIgdGhlIGNsaWVudCBleHBsaWNpdGx5IDxicj4NCiZndDsgZXhwcmVzc2VzIGRpc2lu dGVyZXN0IGluIHRoZSByZXNwb25zZSAodXNpbmcgTm8tUmVzcG9uc2Ugb3B0aW9uKSBvcg0KPGJy Pg0KJmd0OyB0aGUgc2VydmVyIGRlY2lkZXMgb24gaXRzIG93biB0byBzdXBwcmVzcyByZXNwb25z ZXMgKGFzIGluIDxicj4NCiZndDsgbXVsdGljYXN0KSB0aGUgcHJvYmxlbSB1bHRpbWF0ZWx5IGJv aWxzIGRvd24gdG8gc2VydmVyJ3MgdW5jZXJ0YWludHk8YnI+DQomZ3Q7IGluIHJlc3BvbmRpbmcu ICZuYnNwOyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBSZWdhcmRzPGJyPg0KJmd0 OyBBYmhpamFuIEJoYXR0YWNoYXJ5eWE8YnI+DQomZ3Q7IEFzc29jaWF0ZSBDb25zdWx0YW50PGJy Pg0KJmd0OyBTY2llbnRpc3QsIElubm92YXRpb24gTGFiLCBLb2xrYXRhLCBJbmRpYTxicj4NCiZn dDsgVGF0YSBDb25zdWx0YW5jeSBTZXJ2aWNlcyBMaW1pdGVkPGJyPg0KJmd0OyBNYWlsdG86IGFi aGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tPGJyPg0KJmd0OyBXZWJzaXRlOiA8L2ZvbnQ+PC90 dD48YSBocmVmPWh0dHA6Ly93d3cudGNzLmNvbS8+PHR0Pjxmb250IHNpemU9Mj5odHRwOi8vd3d3 LnRjcy5jb208L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQomZ3Q7IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBFeHBlcmll bmNlIGNlcnRhaW50eS4gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SVQgU2VydmljZXM8YnI+ DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwO0J1c2luZXNzIFNvbHV0aW9uczxicj4N CiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7Q29uc3VsdGluZzxicj4NCiZndDsgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gPC9mb250PjwvdHQ+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ID09PT09LS0tLS09PT09PS0tLS0tPT09PT08YnI+DQom Z3Q7IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFpbDxicj4N CiZndDsgbWVzc2FnZSBhbmQvb3IgYXR0YWNobWVudHMgdG8gaXQgbWF5IGNvbnRhaW4gPGJyPg0K Jmd0OyBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbi4gSWYgeW91IGFyZSA8 YnI+DQomZ3Q7IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzc2VtaW5hdGlvbiwg dXNlLCA8YnI+DQomZ3Q7IHJldmlldywgZGlzdHJpYnV0aW9uLCBwcmludGluZyBvciBjb3B5aW5n IG9mIHRoZSA8YnI+DQomZ3Q7IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFpbCBt ZXNzYWdlIDxicj4NCiZndDsgYW5kL29yIGF0dGFjaG1lbnRzIHRvIGl0IGFyZSBzdHJpY3RseSBw cm9oaWJpdGVkLiBJZiA8YnI+DQomZ3Q7IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNh dGlvbiBpbiBlcnJvciwgPGJyPg0KJmd0OyBwbGVhc2Ugbm90aWZ5IHVzIGJ5IHJlcGx5IGUtbWFp bCBvciB0ZWxlcGhvbmUgYW5kIDxicj4NCiZndDsgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5 IGRlbGV0ZSB0aGUgbWVzc2FnZSA8YnI+DQomZ3Q7IGFuZCBhbnkgYXR0YWNobWVudHMuIFRoYW5r IHlvdTwvZm9udD48L3R0Pg0K --=_alternative 0029AE3165257D0B_=-- From nobody Fri Jul 4 00:57:52 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16CDF1B2C56 for ; Fri, 4 Jul 2014 00:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kma0GZ-x0lmZ for ; Fri, 4 Jul 2014 00:57:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B28701B2C52 for ; Fri, 4 Jul 2014 00:57:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJP82446; Fri, 04 Jul 2014 07:57:46 +0000 (GMT) Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 4 Jul 2014 08:57:32 +0100 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.128]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0158.001; Fri, 4 Jul 2014 15:57:29 +0800 From: Likepeng To: Abhijan Bhattacharyya Thread-Topic: [core] Updates in core-groupcomm-19 Thread-Index: AQHPldd08nBZb5MKhU6ginJ+79RmBpuPe1OQ//+H4wCAAIqvQA== Date: Fri, 4 Jul 2014 07:57:27 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F258173A83@SZXEMA501-MBS.china.huawei.com> References: <34966E97BE8AD64EAE9D3D6E4DEE36F258173A43@SZXEMA501-MBS.china.huawei.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.66.167.122] Content-Type: multipart/alternative; boundary="_000_34966E97BE8AD64EAE9D3D6E4DEE36F258173A83SZXEMA501MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/core/vcm7qOfqJfJyO6HlM5OxJIORDNI Cc: "core@ietf.org" Subject: Re: [core] Updates in core-groupcomm-19 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 04 Jul 2014 07:57:51 -0000 --_000_34966E97BE8AD64EAE9D3D6E4DEE36F258173A83SZXEMA501MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgQWJoaWphbiwNCg0KVGhhbmtzIGZvciBwb2ludGluZyBvdXQuDQoNCj4gIFNvIHRoZSBjbGll bnQgaW1wbGVtZW50YXRpb24gc2hvdWxkIGltcGxlbWVudCBhbiBhcHBsaWNhdGlvbg0KPiAgc3Bl Y2lmaWMgJ3BhdGllbmNlJyB0aW1lIHRpbGwgd2hpY2ggaXQgY2FuIHJlLXVzZSB0aGUgdG9rZW4u DQo+ICBBcHBlbmRpeC1CLjQuMSBvZiBbSS1ELmRyYWZ0LWJvcm1hbm4tY29hcC1taXNjXSBkZWZp bmVzICdwYXRpZW5jZScNCj4gIG9wdGlvbiB3aGljaCBpbiBlZmZlY3QgcHV0cyBhIGRlYWRsaW5l IHRvIHRoZSBzZXJ2ZXIgdG8gcmVzcG9uZA0KPiAgYmFjay4gSG93ZXZlciwgJ3BhdGllbmNlJyBp cyBub3QgZXhwb3NlZCB0byB0aGUgcHJvdG9jb2wgbGV2ZWwgYXQgIHByZXNlbnQuDQoNCkluIHRo aXMgc2Vuc2UsIGl0IHdvdWxkIGJlIGJlbmVmaWNpYWwgdG8gc3RhbmRhcmRpemUgobBQYXRpZW5j ZaGxIG9wdGlvbiBhdCB0aGUgcHJvdG9jb2wgbGV2ZWwuDQoNCktpbmQgUmVnYXJkcw0KS2VwZW5n DQoNCreivP7IyzogQWJoaWphbiBCaGF0dGFjaGFyeXlhIFttYWlsdG86YWJoaWphbi5iaGF0dGFj aGFyeXlhQHRjcy5jb21dDQq3osvNyrG85DogMjAxNMTqN9TCNMjVIDE1OjM1DQrK1bz+yMs6IExp a2VwZW5nDQqzrcvNOiBjb3JlQGlldGYub3JnOyBlc2tvLmRpamtAcGhpbGlwcy5jb20NCtb3zOI6 IFJlOiBbY29yZV0gVXBkYXRlcyBpbiBjb3JlLWdyb3VwY29tbS0xOQ0KDQpIaSBLZXBlbmcsDQpZ ZXMsIHRoYXQgaXMgdG91Y2hlZCB1cG9uIGluIFNlY3Rpb24gNS4yIChSZS11c2luZyBUb2tlbnMp IG9mIGh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC10Y3MtY29hcC1uby1yZXNwb25zZS1v cHRpb24tMDYudHh0Lg0KSGVyZSBpcyBzb21lIGV4Y2VycHQgZnJvbSB0aGUgYWJvdmUgbWVudGlv bmVkIHNlY3Rpb24gZm9yIHJlYWR5IHJlZmVyZW5jZToNCg0KIlNvIHRoZSBjbGllbnQgaW1wbGVt ZW50YXRpb24gc2hvdWxkIGltcGxlbWVudCBhbiBhcHBsaWNhdGlvbg0KICBzcGVjaWZpYyAncGF0 aWVuY2UnIHRpbWUgdGlsbCB3aGljaCBpdCBjYW4gcmUtdXNlIHRoZSB0b2tlbi4NCiAgQXBwZW5k aXgtQi40LjEgb2YgW0ktRC5kcmFmdC1ib3JtYW5uLWNvYXAtbWlzY10gZGVmaW5lcyAncGF0aWVu Y2UnDQogIG9wdGlvbiB3aGljaCBpbiBlZmZlY3QgcHV0cyBhIGRlYWRsaW5lIHRvIHRoZSBzZXJ2 ZXIgdG8gcmVzcG9uZA0KICBiYWNrLiBIb3dldmVyLCAncGF0aWVuY2UnIGlzIG5vdCBleHBvc2Vk IHRvIHRoZSBwcm90b2NvbCBsZXZlbCBhdA0KICBwcmVzZW50LiBIZW5jZSwgYSByZXVzZSB0aW1l IGZvciB0b2tlbnMgaXMgc3VnZ2VzdGVkIHdpdGggc2ltaWxhcg0KICBleHByZXNzaW9uIGFzIGlu IFNlY3Rpb24gMi41IG9mIFtJLUQuaWV0Zi1jb3JlLWdyb3VwY29tbV06DQoNCiAgVE9LRU5fUkVV U0VfVElNRSA9IE5PTl9MSUZFVElNRSArIE1BWF9TRVJWRVJfUkVTUE9OU0VfREVMQVkgKw0KICBN QVhfTEFURU5DWS4NCg0KICBOT05fTElGRVRJTUUgYW5kIE1BWF9MQVRFTkNZIGFyZSBkZWZpbmVk IGluIDQuOC4yIG9mIFtJLUQuaWV0Zi1jb3JlLQ0KICBjb2FwXS4gTUFYX1NFUlZFUl9SRVNQT05T RV9ERUxBWSBoYXMgc2FtZSBpbnRlcnByZXRhdGlvbiBhcyBpbg0KICBTZWN0aW9uIDIuNSBvZiBb SS1ELmlldGYtY29yZS1ncm91cGNvbW1dIGZvciBtdWx0aWNhc3QgcmVxdWVzdC4gQnV0DQogIGZv ciB1bmljYXN0IHJlcXVlc3QgTUFYX1NFUlZFUl9SRVNQT05TRV9ERUxBWSBpcyBzaW1wbHkgdGhl IGV4cGVjdGVkDQogIG1heGltdW0gcmVzcG9uc2UgZGVsYXkgZnJvbSB0aGUgc2VydmVyIHRvIHdo aWNoIGNsaWVudCBzZW50IHRoZQ0KICByZXF1ZXN0LiBUaGlzIGRlbGF5IGluY2x1ZGVzIHRoZSBt YXhpbXVtIExlaXN1cmUgdGltZSBwZXJpb2QgYXMNCiAgZGVmaW5lZCBpbiBTZWN0aW9uIDguMiBv ZiBbSS1ELmlldGYtY29yZS1jb2FwXSBhbmQgQXBwZW5kaXgtQi40LjIgb2YNCiAgW0ktRC5kcmFm dC1ib3JtYW5uLWNvYXAtbWlzY113aGVyZSBncm91cCBzaXplIChHKSA9IDEgZm9yIHVuaWNhc3QN CiAgcmVxdWVzdC4iDQoNCg0KUmVnYXJkcw0KQWJoaWphbiBCaGF0dGFjaGFyeXlhDQpBc3NvY2lh dGUgQ29uc3VsdGFudA0KU2NpZW50aXN0LCBJbm5vdmF0aW9uIExhYiwgS29sa2F0YSwgSW5kaWEN ClRhdGEgQ29uc3VsdGFuY3kgU2VydmljZXMgTGltaXRlZA0KTWFpbHRvOiBhYmhpamFuLmJoYXR0 YWNoYXJ5eWFAdGNzLmNvbTxtYWlsdG86YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb20+DQpX ZWJzaXRlOiBodHRwOi8vd3d3LnRjcy5jb208aHR0cDovL3d3dy50Y3MuY29tLz4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpFeHBlcmllbmNlIGNlcnRhaW50 eS4gICAgICAgIElUIFNlcnZpY2VzDQogICAgICAgICAgICAgICAgICAgICAgIEJ1c2luZXNzIFNv bHV0aW9ucw0KICAgICAgICAgICAgICAgICAgICAgICBDb25zdWx0aW5nDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpMaWtlcGVuZyA8bGlrZXBlbmdAaHVh d2VpLmNvbTxtYWlsdG86bGlrZXBlbmdAaHVhd2VpLmNvbT4+IHdyb3RlIG9uIDA3LzA0LzIwMTQg MTI6NDE6NDUgUE06DQoNCj4gRnJvbTogTGlrZXBlbmcgPGxpa2VwZW5nQGh1YXdlaS5jb208bWFp bHRvOmxpa2VwZW5nQGh1YXdlaS5jb20+Pg0KPiBUbzogQWJoaWphbiBCaGF0dGFjaGFyeXlhIDxh YmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbTxtYWlsdG86YWJoaWphbi5iaGF0dGFjaGFyeXlh QHRjcy5jb20+PiwNCj4gImNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5vcmc+IiA8Y29y ZUBpZXRmLm9yZzxtYWlsdG86Y29yZUBpZXRmLm9yZz4+LCAiZXNrby5kaWprQHBoaWxpcHMuY29t PG1haWx0bzplc2tvLmRpamtAcGhpbGlwcy5jb20+Ig0KPiA8ZXNrby5kaWprQHBoaWxpcHMuY29t PG1haWx0bzplc2tvLmRpamtAcGhpbGlwcy5jb20+Pg0KPiBEYXRlOiAwNy8wNC8yMDE0IDEyOjQy IFBNDQo+IFN1YmplY3Q6IFJlOiBbY29yZV0gVXBkYXRlcyBpbiBjb3JlLWdyb3VwY29tbS0xOQ0K Pg0KPiBIaSwNCj4NCj4gPklycmVzcGVjdGl2ZSBvZiB3aGV0aGVyIHRoZSBjbGllbnQgZXhwbGlj aXRseSBleHByZXNzZXMgZGlzaW50ZXJlc3QNCj4gaW4gdGhlIHJlc3BvbnNlICh1c2luZyBOby1S ZXNwb25zZSBvcHRpb24pIG9yIHRoZSBzZXJ2ZXIgZGVjaWRlcyBvbg0KPiBpdHMgb3duIHRvIHN1 cHByZXNzIHJlc3BvbnNlcyAoYXMgaW4gbXVsdGljYXN0KSB0aGUgcHJvYmxlbQ0KPiB1bHRpbWF0 ZWx5IGJvaWxzIGRvd24gdG8gc2VydmVyJ3MgdW5jZXJ0YWludHkgaW4gcmVzcG9uZGluZy4NCj4N Cj4gQW5vdGhlciBwb3NzaWJpbGl0eSBmb3IgdGhlIHNlcnZlciB0byBzdXBwcmVzcyByZXNwb25z ZXMgY2FuIGJlDQo+IGJhc2VkIG9uIKGwUGF0aWVuY2WhsSBvcHRpb24gcHJvcG9zZWQgaW4gdGhp cyBkcmFmdDoNCj4gaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1saS1jb3Jl LWNvYXAtcGF0aWVuY2Utb3B0aW9uLw0KPg0KPiBJZiB0aGUgc2VydmVyIHJlc3BvbnNlIHRpbWUg ZXhjZWVkcyB0aGUgobBQYXRpZW5jZaGxIHZhbHVlIHNwZWNpZmllZA0KPiBpbiB0aGUgY2xpZW50 IHJlcXVlc3QsIHRoZSBzZXJ2ZXIgc2hvdWxkIHN1cHByZXNzIHRoZSByZXNwb25zZS4NCj4NCj4g S2luZCBSZWdhcmRzDQo+IEtlcGVuZw0KPg0KPiC3orz+yMs6IGNvcmUgW21haWx0bzpjb3JlLWJv dW5jZXNAaWV0Zi5vcmddILT6se0gQWJoaWphbiBCaGF0dGFjaGFyeXlhDQo+ILeiy83KsbzkOiAy MDE0xOo31MIyyNUgMTc6MjQNCj4gytW8/sjLOiBjb3JlQGlldGYub3JnPG1haWx0bzpjb3JlQGll dGYub3JnPjsgZXNrby5kaWprQHBoaWxpcHMuY29tPG1haWx0bzplc2tvLmRpamtAcGhpbGlwcy5j b20+DQo+INb3zOI6IFJlOiBbY29yZV0gVXBkYXRlcyBpbiBjb3JlLWdyb3VwY29tbS0xOQ0KPg0K PiBIaSBFc2tvLA0KPiA+DQo+ID4gVGhlIFRva2VuIHZhbHVlIHJlLXVzZSBndWlkZWxpbmUgaXMg YW4gYWRkaXRpb24gYmFzZWQgb24gdGhlDQo+ID4gZGlzY3Vzc2lvbiB0aHJlYWQgobBIYW5kbGlu ZyB0b2tlbnMgZm9yIE5vLXJlc3BvbnNlobEsIHdoZXJlIHRoaXMNCj4gPiBpc3N1ZSB3YXMgaWRl bnRpZmllZC4NCj4gPiBGb3IgbXVsdGljYXN0IHRoZSBUb2tlbiByZS11c2UgdGltZSBpcyBub3cg YWR2aXNlZCB0byBiZSBhdCBsZWFzdDoNCj4gPiAgIE5PTl9MSUZFVElNRSArIE1BWF9MQVRFTkNZ ICsgTUFYX1NFUlZFUl9SRVNQT05TRV9ERUxBWQ0KPiA+IHdoaWNoIGlzIGluIHRoZSBvcmRlciBv ZiBzZXZlcmFsIG1pbnV0ZXMuIE5vdGUgdGhhdCB0aGVyZSBpcyBubw0KPiA+IGxpbWl0IG9uIE1B WF9TRVJWRVJfUkVTUE9OU0VfREVMQVkgaW4gdGhlIENvQVAgcHJvdG9jb2wsIGp1c3QgbGlrZQ0K PiA+IGluIHRoZSBIVFRQIGNhc2UuDQo+ID4NCj4gSW5kZWVkLiBXZSBoYXZlIGFsc28gbWVudGlv bmVkIHNpbWlsYXIgc3VnZ2VzdGlvbiBpbiBzZWN0aW9uIDUuMiBvZg0KPiBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaWQvZHJhZnQtdGNzLWNvYXAtbm8tcmVzcG9uc2Utb3B0aW9uLTA2LnR4dA0KPiB0 byBrZWVwIHN5bmVyZ3kuIElycmVzcGVjdGl2ZSBvZiB3aGV0aGVyIHRoZSBjbGllbnQgZXhwbGlj aXRseQ0KPiBleHByZXNzZXMgZGlzaW50ZXJlc3QgaW4gdGhlIHJlc3BvbnNlICh1c2luZyBOby1S ZXNwb25zZSBvcHRpb24pIG9yDQo+IHRoZSBzZXJ2ZXIgZGVjaWRlcyBvbiBpdHMgb3duIHRvIHN1 cHByZXNzIHJlc3BvbnNlcyAoYXMgaW4NCj4gbXVsdGljYXN0KSB0aGUgcHJvYmxlbSB1bHRpbWF0 ZWx5IGJvaWxzIGRvd24gdG8gc2VydmVyJ3MgdW5jZXJ0YWludHkNCj4gaW4gcmVzcG9uZGluZy4N Cj4NCj4NCj4gUmVnYXJkcw0KPiBBYmhpamFuIEJoYXR0YWNoYXJ5eWENCj4gQXNzb2NpYXRlIENv bnN1bHRhbnQNCj4gU2NpZW50aXN0LCBJbm5vdmF0aW9uIExhYiwgS29sa2F0YSwgSW5kaWENCj4g VGF0YSBDb25zdWx0YW5jeSBTZXJ2aWNlcyBMaW1pdGVkDQo+IE1haWx0bzogYWJoaWphbi5iaGF0 dGFjaGFyeXlhQHRjcy5jb208bWFpbHRvOmFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tPg0K PiBXZWJzaXRlOiBodHRwOi8vd3d3LnRjcy5jb208aHR0cDovL3d3dy50Y3MuY29tLz4NCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRXhwZXJpZW5jZSBj ZXJ0YWludHkuICAgICAgICBJVCBTZXJ2aWNlcw0KPiAgICAgICAgICAgICAgICAgICAgICAgIEJ1 c2luZXNzIFNvbHV0aW9ucw0KPiAgICAgICAgICAgICAgICAgICAgICAgIENvbnN1bHRpbmcNCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPT09PT0tLS0t LT09PT09LS0tLS09PT09PQ0KPiBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4g dGhpcyBlLW1haWwNCj4gbWVzc2FnZSBhbmQvb3IgYXR0YWNobWVudHMgdG8gaXQgbWF5IGNvbnRh aW4NCj4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24uIElmIHlvdSBhcmUN Cj4gbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNzZW1pbmF0aW9uLCB1c2UsDQo+ IHJldmlldywgZGlzdHJpYnV0aW9uLCBwcmludGluZyBvciBjb3B5aW5nIG9mIHRoZQ0KPiBpbmZv cm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBlLW1haWwgbWVzc2FnZQ0KPiBhbmQvb3IgYXR0YWNo bWVudHMgdG8gaXQgYXJlIHN0cmljdGx5IHByb2hpYml0ZWQuIElmDQo+IHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwNCj4gcGxlYXNlIG5vdGlmeSB1cyBieSBy ZXBseSBlLW1haWwgb3IgdGVsZXBob25lIGFuZA0KPiBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50 bHkgZGVsZXRlIHRoZSBtZXNzYWdlDQo+IGFuZCBhbnkgYXR0YWNobWVudHMuIFRoYW5rIHlvdQ0K --_000_34966E97BE8AD64EAE9D3D6E4DEE36F258173A83SZXEMA501MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Abhijan= ,

 = ;

Thanks for= pointing out.

 = ;

> = So the client implementation should implement an application

> = specific 'patience' time till which it can re-use the token.

> = Appendix-B.4.1 of [I-D.draft-bormann-coap-misc] defines 'patience'

> = option which in effect puts a deadline to the server to respond=

> = back. However, 'patience' is not exposed to the protocol level at  pr= esent.

 = ;

In this se= nse, it would be beneficial to standardize =A1=B0Patience=A1=B1 option at t= he protocol level.

 = ;

Kind Regar= ds

Kepeng

 = ;

=B7=A2=BC=FE=C8= =CB: Abhijan Bhattacharyya [mailto:abhijan.bhattacharyya@tcs.co= m]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA7=D4=C24=C8=D5 15= :35
=CA=D5=BC=FE=C8=CB: Likepeng
=B3=AD=CB=CD: core@ietf.org; esko.dijk@philips.com
=D6=F7=CC=E2: Re: [core] Updates in core-groupcomm-19

 

Hi Kepeng,
Yes, that is touched upon in Section 5.2 (= Re-using Tokens) of http://tools.ietf.org/id/draft-tc= s-coap-no-response-option-06.txt.
Here is some excerpt from the above mentio= ned section for ready reference:

"So t= he client implementation should implement an application
  specific 'patience' time till which it can re-use the token.
  Appendix-B.4.1 of [I-D.draft-bormann-coap-misc] defines 'patienc= e'
  option which in effect puts a deadline to the server to respond<= /tt>
  back. However, 'patience' is not exposed to the protocol level a= t
  present. Hence, a reuse time for tokens is suggested with simila= r
  expression as in Section 2.5 of [I-D.ietf-core-groupcomm]:<= br>
  TOKEN_REUSE_TIME =3D NON_LIFETIME + MAX_SERVER_RESPONSE_DELA= Y +
  MAX_LATENCY.

  NON_LIFETIME and MAX_LATENCY are defined in 4.8.2 of [I-D.ietf-c= ore-
  coap]. MAX_SERVER_RESPONSE_DELAY has same interpretation as in
  Section 2.5 of [I-D.ietf-core-groupcomm] for multicast request. = But
  for unicast request MAX_SERVER_RESPONSE_DELAY is simply the expe= cted
  maximum response delay from the server to which client sent the<= /tt>
  request. This delay includes the maximum Leisure time period as<= /tt>
  defined in Section 8.2 of [I-D.ietf-core-coap] and Appendix-B.4.= 2 of
  [I-D.draft-bormann-coap-misc]where group size (G) =3D 1 for unic= ast
  request."


Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services Limited
Mailto: abhijan.bhattachar= yya@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty.        IT Services
                     = ;  Business Solutions
                     = ;  Consulting
____________________________________________
Likepeng <likepeng@huawei.com> wrote on 07= /04/2014 12:41:45 PM:

> From: Likepeng <likepeng= @huawei.com>
> To: Abhijan= Bhattacharyya <abhijan= .bhattacharyya@tcs.com>,
> "core@ietf.org" <= ;core@ietf.org>, "esko.dijk@philips.com"
> <esko.dijk@philips.com= >
> Date: 07/04= /2014 12:42 PM
> Subject: Re= : [core] Updates in core-groupcomm-19
>
> Hi,
>  
> >Irrespe= ctive of whether the client explicitly expresses disinterest
> in the response (using No-Response option) or the server decides o= n
> its own to suppress responses (as in multicast) the problem <= br> > ultimately boils down to server's uncertainty in responding.<= /span>
>  
> Another pos= sibility for the server to suppress responses can be
> based on =A1=B0Patience=A1=B1 option proposed in this draft:<= /span>
> http://data= tracker.ietf.org/doc/draft-li-core-coap-patience-option/
>  
> If the serv= er response time exceeds the =A1=B0Patience=A1=B1 value specified
> in the client request, the server should suppress the response.
>  
> Kind Regard= s
> Kepeng
>  
> =B7=A2=BC=FE=C8=CB: core [mailto:core-bounces@ie= tf.org] =B4=FA=B1=ED Abhijan Bhattacharyya
> =B7=A2=CB=CD=CA= =B1=BC=E4: 2014=C4=EA7=D4=C22=C8=D5 17:24
> =CA=D5=BC=FE=C8= =CB: core@ietf.org; esko.dijk@phili= ps.com
> =D6=F7=CC=E2: Re: [core] Updates in core-groupcomm-19
>  
> Hi Esko,
> >  
> > The Token value re-use guideline is an addition based on the =
> > discussion thread =A1=B0Handling tokens for No-response=A1=B1= , where this
> > issue was identified.
> > For multicast the Token re-use time is now advised to be at l= east:
> >   NON_LIFETIME + MAX_LATENCY + MAX_SERVER_RESPON= SE_DELAY
> > which is in the order of several minutes. Note that there is = no
> > limit on MAX_SERVER_RESPONSE_DELAY in the CoAP protocol, just= like
> > in the HTTP case.
> >
> Indeed. We have also mentioned similar suggestion in section 5.2 o= f
> http://tools.ietf.org/id/draft-tcs-coap-no-response-option-06.txt
> to keep synergy. Irrespective of whether the client explicitly
> expresses disinterest in the response (using No-Response option) o= r
> the server decides on its own to suppress responses (as in > multicast) the problem ultimately boils down to server's uncertain= ty
> in responding.  
>
>
> Regards
> Abhijan Bhattacharyya
> Associate Consultant
> Scientist, Innovation Lab, Kolkata, India
> Tata Consultancy Services Limited
> Mailto: abhijan.b= hattacharyya@tcs.com
> Website: http://www.tcs.com=
> ____________________________________________
> Experience certainty.        IT Services<= br> >                   &nb= sp;    Business Solutions
>                   &nb= sp;    Consulting
> ____________________________________________
> =3D=3D=3D= =3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank you

--_000_34966E97BE8AD64EAE9D3D6E4DEE36F258173A83SZXEMA501MBSchi_-- From nobody Fri Jul 4 01:37:02 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAFC01B2C6D for ; Fri, 4 Jul 2014 01:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbHQoQOdIQz0 for ; Fri, 4 Jul 2014 01:36:57 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 85D411A0067 for ; Fri, 4 Jul 2014 01:36:55 -0700 (PDT) Received: from WeiGengyuPC (unknown [10.103.241.112]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 223A119F36F; Fri, 4 Jul 2014 16:36:46 +0800 (HKT) Message-ID: <0935B66F196E44E685EC191E93ED9727@WeiGengyuPC> From: "weigengyu" To: "Likepeng" , "Abhijan Bhattacharyya" References: <34966E97BE8AD64EAE9D3D6E4DEE36F258173A43@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F258173A83@SZXEMA501-MBS.china.huawei.com> In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F258173A83@SZXEMA501-MBS.china.huawei.com> Date: Fri, 4 Jul 2014 16:36:44 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006D_01CF97A6.247B0100" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3522.110 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3522.110 Archived-At: http://mailarchive.ietf.org/arch/msg/core/FWJ7q9QTOni4SSlgiC1rP9ts9uc Cc: core@ietf.org Subject: Re: [core] Updates in core-groupcomm-19 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 04 Jul 2014 08:37:00 -0000 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à·½Óʼþ¡£ ------=_NextPart_000_006D_01CF97A6.247B0100 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi all,=20 > In this sense, it would be beneficial to standardize = =A1=B0Patience=A1=B1 option at the protocol level. I agree.=20 =20 And it will be beneficial to define some general token handling = mechanisms=20 based on characteristics of request and response(s). regards,=20 Gengyu WEI Network Technology Center School of Computer=20 Beijing University of Posts and Telecommunications From: Likepeng=20 Sent: Friday, July 04, 2014 3:57 PM To: Abhijan Bhattacharyya=20 Cc: core@ietf.org=20 Subject: Re: [core] Updates in core-groupcomm-19 Hi Abhijan, =20 Thanks for pointing out. =20 > So the client implementation should implement an application > specific 'patience' time till which it can re-use the token. > Appendix-B.4.1 of [I-D.draft-bormann-coap-misc] defines 'patience' > option which in effect puts a deadline to the server to respond > back. However, 'patience' is not exposed to the protocol level at = present. =20 In this sense, it would be beneficial to standardize = =A1=B0Patience=A1=B1 option at the protocol level. =20 Kind Regards Kepeng =20 =B7=A2=BC=FE=C8=CB: Abhijan Bhattacharyya = [mailto:abhijan.bhattacharyya@tcs.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA7=D4=C24=C8=D5 15:35 =CA=D5=BC=FE=C8=CB: Likepeng =B3=AD=CB=CD: core@ietf.org; esko.dijk@philips.com =D6=F7=CC=E2: Re: [core] Updates in core-groupcomm-19 =20 Hi Kepeng,=20 Yes, that is touched upon in Section 5.2 (Re-using Tokens) of = http://tools.ietf.org/id/draft-tcs-coap-no-response-option-06.txt.=20 Here is some excerpt from the above mentioned section for ready = reference:=20 "So the client implementation should implement an application specific 'patience' time till which it can re-use the token. Appendix-B.4.1 of [I-D.draft-bormann-coap-misc] defines 'patience' option which in effect puts a deadline to the server to respond back. However, 'patience' is not exposed to the protocol level at present. Hence, a reuse time for tokens is suggested with similar expression as in Section 2.5 of [I-D.ietf-core-groupcomm]: TOKEN_REUSE_TIME =3D NON_LIFETIME + MAX_SERVER_RESPONSE_DELAY + MAX_LATENCY. NON_LIFETIME and MAX_LATENCY are defined in 4.8.2 of [I-D.ietf-core- coap]. MAX_SERVER_RESPONSE_DELAY has same interpretation as in Section 2.5 of [I-D.ietf-core-groupcomm] for multicast request. But for unicast request MAX_SERVER_RESPONSE_DELAY is simply the expected maximum response delay from the server to which client sent the request. This delay includes the maximum Leisure time period as defined in Section 8.2 of [I-D.ietf-core-coap] and Appendix-B.4.2 of [I-D.draft-bormann-coap-misc]where group size (G) =3D 1 for unicast request."=20 Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Limited Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________=20 Likepeng wrote on 07/04/2014 12:41:45 PM: > From: Likepeng =20 > To: Abhijan Bhattacharyya ,=20 > "core@ietf.org" , "esko.dijk@philips.com"=20 > =20 > Date: 07/04/2014 12:42 PM=20 > Subject: Re: [core] Updates in core-groupcomm-19=20 >=20 > Hi,=20 > =20 > >Irrespective of whether the client explicitly expresses disinterest > in the response (using No-Response option) or the server decides on=20 > its own to suppress responses (as in multicast) the problem=20 > ultimately boils down to server's uncertainty in responding.=20 > =20 > Another possibility for the server to suppress responses can be=20 > based on =A1=B0Patience=A1=B1 option proposed in this draft:=20 > http://datatracker.ietf.org/doc/draft-li-core-coap-patience-option/=20 > =20 > If the server response time exceeds the =A1=B0Patience=A1=B1 value = specified=20 > in the client request, the server should suppress the response.=20 > =20 > Kind Regards=20 > Kepeng=20 > =20 > =B7=A2=BC=FE=C8=CB: core [mailto:core-bounces@ietf.org] =B4=FA=B1=ED = Abhijan Bhattacharyya > =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA7=D4=C22=C8=D5 17:24 > =CA=D5=BC=FE=C8=CB: core@ietf.org; esko.dijk@philips.com > =D6=F7=CC=E2: Re: [core] Updates in core-groupcomm-19=20 > =20 > Hi Esko,=20 > > =20 > > The Token value re-use guideline is an addition based on the=20 > > discussion thread =A1=B0Handling tokens for No-response=A1=B1, where = this=20 > > issue was identified.=20 > > For multicast the Token re-use time is now advised to be at least:=20 > > NON_LIFETIME + MAX_LATENCY + MAX_SERVER_RESPONSE_DELAY=20 > > which is in the order of several minutes. Note that there is no=20 > > limit on MAX_SERVER_RESPONSE_DELAY in the CoAP protocol, just like=20 > > in the HTTP case.=20 > >=20 > Indeed. We have also mentioned similar suggestion in section 5.2 of=20 > http://tools.ietf.org/id/draft-tcs-coap-no-response-option-06.txt=20 > to keep synergy. Irrespective of whether the client explicitly=20 > expresses disinterest in the response (using No-Response option) or=20 > the server decides on its own to suppress responses (as in=20 > multicast) the problem ultimately boils down to server's uncertainty > in responding. =20 >=20 >=20 > Regards > Abhijan Bhattacharyya > Associate Consultant > Scientist, Innovation Lab, Kolkata, India > Tata Consultancy Services Limited > Mailto: abhijan.bhattacharyya@tcs.com > Website: http://www.tcs.com > ____________________________________________ > Experience certainty. IT Services > Business Solutions > Consulting > ____________________________________________=20 > =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D > Notice: The information contained in this e-mail > message and/or attachments to it may contain=20 > confidential or privileged information. If you are=20 > not the intended recipient, any dissemination, use,=20 > review, distribution, printing or copying of the=20 > information contained in this e-mail message=20 > and/or attachments to it are strictly prohibited. If=20 > you have received this communication in error,=20 > please notify us by reply e-mail or telephone and=20 > immediately and permanently delete the message=20 > and any attachments. Thank you=20 -------------------------------------------------------------------------= ------- _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ------=_NextPart_000_006D_01CF97A6.247B0100 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi all, =

 

> In = this sense,=20 it would be beneficial to standardize =A1=B0Patience=A1=B1 option at the = protocol=20 level.

Gengyu=20 WEI
Network Technology Center
School of Computer
Beijing = University of=20 Posts and Telecommunications

 
From: Likepeng
Sent: Friday, July 04, 2014 3:57 PM
Subject: Re: [core] Updates in = core-groupcomm-19
 

Hi=20 Abhijan,

 

Thanks=20 for pointing out.

 

> =20 So the client implementation should implement an=20 application

> =20 specific 'patience' time till which it can re-use the=20 token.

> =20 Appendix-B.4.1 of [I-D.draft-bormann-coap-misc] defines=20 'patience'

> =20 option which in effect puts a deadline to the server to=20 respond

> =20 back. However, 'patience' is not exposed to the protocol level at =20 present.

 

In=20 this sense, it would be beneficial to standardize =A1=B0Patience=A1=B1 = option at the=20 protocol level.

 

Kind=20 Regards

Kepeng

 

=B7=A2=BC=FE=C8=CB: Abhijan=20 Bhattacharyya [mailto:abhijan.bhattacharyya@tcs.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA7=D4=C24=C8=D5=20 15:35
=CA=D5=BC=FE=C8=CB:=20 Likepeng
=B3=AD=CB=CD:=20 core@ietf.org; esko.dijk@philips.com
=D6=F7=CC=E2: Re: [core] Updates in=20 core-groupcomm-19

 

Hi=20 Kepeng,
Yes, that = is touched=20 upon in Section 5.2 (Re-using Tokens) of http://tools.ietf.org/id/draft-tcs-coap-no-response= -option-06.txt.
Here is = some excerpt=20 from the above mentioned section for ready reference:=20

"So the client implementation should implement an=20 application
  specific = 'patience' time=20 till which it can re-use the token.
  Appendix-B.4.1 of = [I-D.draft-bormann-coap-misc] defines 'patience'
  = option which=20 in effect puts a deadline to the server to respond
  = back.=20 However, 'patience' is not exposed to the protocol level = at
 =20 present. Hence, a reuse time for tokens is suggested with=20 similar
  expression as in Section 2.5 of=20 [I-D.ietf-core-groupcomm]:

  TOKEN_REUSE_TIME =3D=20 NON_LIFETIME + MAX_SERVER_RESPONSE_DELAY +
 =20 MAX_LATENCY.

  NON_LIFETIME and MAX_LATENCY are = defined in=20 4.8.2 of [I-D.ietf-core-
  coap]. = MAX_SERVER_RESPONSE_DELAY has=20 same interpretation as in
  Section 2.5 of=20 [I-D.ietf-core-groupcomm] for multicast request. But
  = for=20 unicast request MAX_SERVER_RESPONSE_DELAY is simply the=20 expected
  maximum response delay from the server to = which=20 client sent the
  request. This delay includes the = maximum=20 Leisure time period as
  defined in Section 8.2 of=20 [I-D.ietf-core-coap] and Appendix-B.4.2 of
 =20 [I-D.draft-bormann-coap-misc]where group size (G) =3D 1 for=20 unicast
  request."


Regards
Abhijan=20 Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, = Kolkata,=20 India
Tata Consultancy Services Limited
Mailto: abhijan.bhattacharyya@tcs.c= om
Website:=20 http://www.tcs.com
____________________________________________Experience=20 certainty.        IT=20 Services
          &= nbsp;           =20 Business=20 Solutions
          =              = Consulting
____________________________________________

Likepeng=20 <likepeng@huawei.com> = wrote on=20 07/04/2014 12:41:45 PM:

> From: Likepeng <likepeng@huawei.com>
> To:=20 Abhijan Bhattacharyya <mailto:abhijan.bhattacharyy= a@tcs.com>,=20
> = "core@ietf.org" <core@ietf.org>, "esko.dijk@philips.com" =
>=20 <esko.dijk@philips.com><= /SPAN>
> Date:=20 07/04/2014 12:42 PM
> Subject: Re: [core] Updates in=20 core-groupcomm-19
>
> Hi,=20
> =20
> >Irrespective of whether the client = explicitly=20 expresses disinterest
> in the response (using = No-Response option)=20 or the server decides on
> its own to suppress responses = (as in=20 multicast) the problem
> ultimately boils down to = server's=20 uncertainty in responding. =
> 
> Another=20 possibility for the server to suppress responses can be =
> based on = =A1=B0Patience=A1=B1 option=20 proposed in this draft: =
> http://datatracker.ietf.org/doc/draft-li-core-coap-patience-option/= =20
> =20
> If the server response time exceeds the = =A1=B0Patience=A1=B1=20 value specified
> in the client request, the server = should=20 suppress the response. =
> 
> Kind=20 Regards
> Kepeng=20
> =20
> =B7=A2=BC=FE=C8=CB: core = [mailto:core-bounces@ietf.org] =B4=FA=B1=ED Abhijan=20 Bhattacharyya
> =B7=A2=CB=CD=CA=B1=BC=E4: = 2014=C4=EA7=D4=C22=C8=D5=20 17:24
>=20 =CA=D5=BC=FE=C8=CB: core@ietf.org; esko.dijk@philips.com
> = =D6=F7=CC=E2: Re: [core] = Updates in=20 core-groupcomm-19 =
> 
> Hi Esko,=20
>=20 >  
> > The Token value re-use guideline = is an=20 addition based on the
> > discussion thread = =A1=B0Handling tokens=20 for No-response=A1=B1, where this
> > issue was = identified.=20
> > For multicast the Token re-use time is now = advised to be=20 at least:
> >   NON_LIFETIME + MAX_LATENCY = +=20 MAX_SERVER_RESPONSE_DELAY
> > which is in the order = of=20 several minutes. Note that there is no
> > limit on=20 MAX_SERVER_RESPONSE_DELAY in the CoAP protocol, just like =
> >=20 in the HTTP case.
> >
> Indeed. We = have also=20 mentioned similar suggestion in section 5.2 of
>=20 http://tools.ietf.org/id/draft-tcs-coap-no-response-option-06.txt
> to keep synergy. Irrespective of = whether=20 the client explicitly
> expresses disinterest in the = response=20 (using No-Response option) or
> the server decides on = its own to=20 suppress responses (as in
> multicast) the problem = ultimately=20 boils down to server's uncertainty
> in = responding.  =20
>
>
> = Regards
>=20 Abhijan Bhattacharyya
> Associate = Consultant
>=20 Scientist, Innovation Lab, Kolkata, India
> Tata = Consultancy=20 Services Limited
> Mailto: abhijan.bhattacharyya@tcs.c= om
>=20 Website: http://www.tcs.com
>=20 ____________________________________________
> Experience = certainty.        IT=20 Services
>        =             &= nbsp;  =20 Business=20 Solutions
>        = ;            =    =20 Consulting
> ____________________________________________ =
> = =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D
> Notice: The = information=20 contained in this e-mail
> message and/or attachments to = it may=20 contain
> confidential or privileged information. If you = are=20
> not the intended recipient, any dissemination, use,=20
> review, distribution, printing or copying of the=20
> information contained in this e-mail message =
>=20 and/or attachments to it are strictly prohibited. If
> = you have=20 received this communication in error,
> please notify us = by=20 reply e-mail or telephone and
> immediately and = permanently=20 delete the message
> and any attachments. Thank=20 you

_______________________________________________
core mailing=20 list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
------=_NextPart_000_006D_01CF97A6.247B0100-- From nobody Fri Jul 4 09:21:35 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E051B2D87; Fri, 4 Jul 2014 09:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhOxmdS0Pujg; Fri, 4 Jul 2014 09:21:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DD9AF1B2D95; Fri, 4 Jul 2014 09:21:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704162129.13686.28074.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 09:21:29 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/core/KoBlhzRTOlr5INc4sAKBFjpuPNI Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-http-mapping-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 16:21:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments Working Group of the IETF. Title : Guidelines for HTTP-CoAP Mapping Implementations Authors : Angelo P. Castellani Salvatore Loreto Akbar Rahman Thomas Fossati Esko Dijk Filename : draft-ietf-core-http-mapping-04.txt Pages : 28 Date : 2014-07-04 Abstract: This draft provides reference information for HTTP-CoAP protocol translation proxy implementation, focusing on the reverse proxy case. It details deployment options, defines a template for URI mapping, and provides a set of guidelines and considerations related to protocol translation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-http-mapping-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-core-http-mapping-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 4 12:34:43 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 042AA1B2F22; Fri, 4 Jul 2014 12:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eyXGrSsY0cxp; Fri, 4 Jul 2014 12:34:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 657541B2F12; Fri, 4 Jul 2014 12:34:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704193438.28516.28787.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 12:34:38 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/core/UAr68MMBZhW90WX2rZjDLITORMg Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-block-15.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 19:34:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments Working Group of the IETF. Title : Blockwise transfers in CoAP Authors : Carsten Bormann Zach Shelby Filename : draft-ietf-core-block-15.txt Pages : 32 Date : 2014-07-04 Abstract: CoAP is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for the small payloads we expect from temperature sensors, light switches, and similar building-automation devices. Occasionally, however, applications will need to transfer larger payloads -- for instance, for firmware updates. With HTTP, TCP does the grunt work of slicing large payloads up into multiple packets and ensuring that they all arrive and are handled in the right order. CoAP is based on datagram transports such as UDP or DTLS, which limits the maximum size of resource representations that can be transferred without too much fragmentation. Although UDP supports larger payloads through IP fragmentation, it is limited to 64 KiB and, more importantly, doesn't really work well for constrained applications and networks. Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options, for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. In summary, the Block options provide a minimal way to transfer larger representations in a block-wise fashion. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-block/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-block-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-core-block-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 4 14:04:56 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A931B2A2A; Fri, 4 Jul 2014 14:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zd6BpXgXPQ8c; Fri, 4 Jul 2014 14:04:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4998A1A032A; Fri, 4 Jul 2014 14:04:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704210453.30710.91186.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 14:04:53 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/core/kzlTo7zmcCjQ1kk8JJgjVKvWvdM Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-links-json-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 21:04:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments Working Group of the IETF. Title : Representing CoRE Link Collections in JSON Author : Carsten Bormann Filename : draft-ietf-core-links-json-02.txt Pages : 7 Date : 2014-07-04 Abstract: Web Linking (RFC5988) provides a way to represent links between Web resources as well as the relations expressed by them and attributes of such a link. In constrained networks, a collection of Web links can be exchanged in the CoRE link format (RFC6690). Outside of constrained environments, it may be useful to represent these collections of Web links in JSON format (RFC7159). This specification defines a common format for representing Web links in JSON format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-links-json/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-links-json-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-core-links-json-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 4 16:56:49 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0D501A0309 for ; Fri, 4 Jul 2014 16:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54KgKOwfL520 for ; Fri, 4 Jul 2014 16:56:46 -0700 (PDT) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B5101A0306 for ; Fri, 4 Jul 2014 16:56:46 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id r5so1892523qcx.8 for ; Fri, 04 Jul 2014 16:56:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=TQXoB15PkdlWgUQWCxFxXRFK7th/ihTiuK+AYBv4vXA=; b=E/jVHRU38DGYf9m0Us9TbUdwqlV+GOW6DfpRI57lcBv9UkZCxnP5CSC4bEbWPba2Ly LCprBy1NajHGN6FSt42NZ92OysNDzpaMHZwmTBIB89p4ImoRitqw3eojCoABj5ZMQ9DQ 7vxe7y66nMeVLhJQH6NclFBcJO4yBVk6zl7kljRMn7P5MNmRShyqswrLb+gmGQx0qhlR pug7xK4CorZlq2gV1zkcMjR0QBATgp1da8ZwZwdhFEmM/OIJ5ki6tI+1qT4qZlp938Ny LGXzSj/2WP6SoJfl0gboB8+hnTDEMgXtzlL4AB0LtBBrvTAb8GkEBoSz34dwi+6esA2+ L/1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=TQXoB15PkdlWgUQWCxFxXRFK7th/ihTiuK+AYBv4vXA=; b=Pf5K0yata3dTmmpRRO39R29T9UbMPLKolBsTTtGnvm3xVjxeikGz9SymIC4qyXK2tP rDwbxTdecwQPnrP+fd4UWrcA2HQzvaVHkSh3uulO1dSK4nYwZSSUSGS8ZQRtZfQF533b MbU9uCtFAHSo/L2RoPD+8XbZrgIV2DpV+6bkzGHkOPaZcJuO8E7hyvScRAitjotgyLhQ e1XloDO9tfkaJkUwzuU6Fz9mf24BoXMdDByjS6VHL/MCiqYpGHPmuRNGg53IUT7rqEDk FM9OjxBu9K03juDQYTxCx6NpjJHIRh3ybPdffo5W9pz7F6+gDYJ+L+Gg/5hT89SFSF2L gwSQ== X-Gm-Message-State: ALoCoQm5pgEt14WGZuSoB4JSJRYbV9/TLzPzcqf5niNYKFM0voi1WmpY+16hYP7ye60zMiQdKiwM MIME-Version: 1.0 X-Received: by 10.140.49.194 with SMTP id q60mr22856594qga.7.1404518205471; Fri, 04 Jul 2014 16:56:45 -0700 (PDT) Received: by 10.224.104.205 with HTTP; Fri, 4 Jul 2014 16:56:45 -0700 (PDT) Date: Sat, 5 Jul 2014 09:56:45 +1000 Message-ID: From: Andrew Mcgregor To: core , "core-chairs@tools.ietf.org" , Barry Leiba , Zach Shelby Content-Type: multipart/alternative; boundary=001a1135054cb7ef0404fd66e045 Archived-At: http://mailarchive.ietf.org/arch/msg/core/EyACuyFUeu7lfaM7_0GLezJJfRk Subject: [core] WGLC for draft-ietf-core-block-15 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 04 Jul 2014 23:56:48 -0000 --001a1135054cb7ef0404fd66e045 Content-Type: text/plain; charset=UTF-8 The chairs believe that draft-ietf-core-block is now ready for last call. We intend a short last call on this document, since we would like to be able to discuss the results in Toronto in two weeks time. Please make any comments as soon as possible. The draft is located at: http://www.ietf.org/internet-drafts/draft-ietf-core-block-15.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-core-block/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-core-block-15 Andrew -- Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 1071 2221 --001a1135054cb7ef0404fd66e045 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The chairs believe that draft-ietf-core-block is now= ready for last call. =C2=A0We intend a short last call on this document, s= ince we would like to be able to discuss the results in Toronto in two week= s time. =C2=A0Please make any comments as soon as possible.

The draft is located at:
http://www.ietf.o= rg/internet-drafts/draft-ietf-core-block-15.txt

<= span style=3D"font-family:arial,sans-serif;font-size:12.727272033691406px">= The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-core-block/

<= span style=3D"font-family:arial,sans-serif;font-size:12.727272033691406px">= Diff from previous version:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-block-15

Andrew

--
Andrew McGregor=C2=A0|=C2=A0SRE=C2=A0|=C2=A0andrewmcgr@google.com=C2=A0|=C2=A0+61 4 1071 2221
--001a1135054cb7ef0404fd66e045-- From nobody Sat Jul 5 01:03:13 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B89571A0362 for ; Sat, 5 Jul 2014 00:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7Y984QnWS-U for ; Sat, 5 Jul 2014 00:03:09 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71FDC1A0361 for ; Sat, 5 Jul 2014 00:03:09 -0700 (PDT) Received: from localhost ([::1]:46283 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X3Jzu-0002vJ-77; Sat, 05 Jul 2014 00:02:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Sat, 05 Jul 2014 07:02:58 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/365#comment:2 Message-ID: <075.dc98e20878f879c359d4336ba392048a@trac.tools.ietf.org> References: <060.2c2f9cc5f5382b4bd217c7f97f448102@trac.tools.ietf.org> X-Trac-Ticket-ID: 365 In-Reply-To: <060.2c2f9cc5f5382b4bd217c7f97f448102@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, angelo@castellani.net, esko.dijk@philips.com, salvatore.loreto@ericsson.com, thomas.fossati@alcatel-lucent.com Archived-At: http://mailarchive.ietf.org/arch/msg/core/icZPWN_HDJ4GitjB5OY7XNGTuCM X-Mailman-Approved-At: Sat, 05 Jul 2014 01:03:12 -0700 Cc: core@ietf.org Subject: Re: [core] #365 (http-mapping): Add text on media-type conversion by HTTP-CoAP proxy X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Reply-To: trac+core@zinfandel.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: Sat, 05 Jul 2014 07:03:11 -0000 #365: Add text on media-type conversion by HTTP-CoAP proxy Changes (by esko.dijk@philips.com): * status: new => closed * resolution: => fixed Comment: Done in -04, section 6.3 added. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-http- esko.dijk@philips.com | mapping@tools.ietf.org Type: protocol | Status: closed enhancement | Milestone: Priority: major | Version: Component: http- | Resolution: fixed mapping | Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From nobody Sat Jul 5 14:25:04 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96ECC1B287F for ; Sat, 5 Jul 2014 14:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kveS9cE9VugV for ; Sat, 5 Jul 2014 14:25:01 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B05A1B2873 for ; Sat, 5 Jul 2014 14:25:01 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id z10so3408753pdj.1 for ; Sat, 05 Jul 2014 14:25:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=LaYFl3pPdXgHGOhwU8WeYrvYlsSuPhziC1gSdxwTym8=; b=XPUp2xcEjOWSO/6ChCQZ3J7fpUn9OfVutVcDSa72OqyVzBomllubfRYyF/KXCfubGd W3cFeyjiTQPHDxJGouRY+jykOWG8VSK55g+rEZm7P+rLoUc8Prf1AsSIO7ucEO4PjJNF qOTwPfxJX/quCY5Eev+vj7nHcxxRYvYlgFiHRi/szbnl82ewLZeqipRoKkx3qdUTUbct jPKMHczXiQ1Glffwiw1/dBvFb9FLJTa3wngRReVVqv3PP2fKE8kJl6nb8bROjSpdRnjU HUROGuKB7St8jmy6bDSGhgbBQow0EgpfQ6WRXjm4p5fEt3MDjpM3tVX8eMhb0SpxI1B1 B50A== X-Received: by 10.68.227.164 with SMTP id sb4mr8812177pbc.63.1404595500971; Sat, 05 Jul 2014 14:25:00 -0700 (PDT) Received: from [10.0.0.11] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by mx.google.com with ESMTPSA id pg4sm14035287pdb.57.2014.07.05.14.24.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 05 Jul 2014 14:24:59 -0700 (PDT) From: Michael Koster Content-Type: multipart/alternative; boundary="Apple-Mail=_51A2A30A-6C11-42B5-BA5F-BCFC7E8D8F74" Message-Id: Date: Sat, 5 Jul 2014 14:25:01 -0700 To: core@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/core/BURRr787PT-ZH396TNIekk01Hn0 Subject: [core] New draft for Pub-Sub Message Queueing over CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 05 Jul 2014 21:25:02 -0000 --Apple-Mail=_51A2A30A-6C11-42B5-BA5F-BCFC7E8D8F74 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We would like to point out a newly submitted draft for review and = discussion. CoAP-MQ leverages CoRE RD and CoAP with Observe to specify = publish-subscribe interactions over CoAP. This draft is also meant to address key design requirements for mirror = server and support for sleepy/partially reachable endpoints.=20 https://datatracker.ietf.org/doc/draft-koster-core-coapmq/ We are planning to present this work at IETF 90 in Toronto. Best regards, Michael Koster= --Apple-Mail=_51A2A30A-6C11-42B5-BA5F-BCFC7E8D8F74 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
We would like to point out a newly submitted draft for review and discussion.

CoAP-MQ leverages CoRE RD and CoAP with Observe to specify publish-subscribe interactions over CoAP.

This draft is also meant to address key design requirements for mirror server and support for sleepy/partially reachable endpoints. 

https://datatracker.ietf.org/doc/draft-koster-core-coapmq/

We are planning to present this work at IETF 90 in Toronto.

Best regards,

Michael Koster
--Apple-Mail=_51A2A30A-6C11-42B5-BA5F-BCFC7E8D8F74-- From nobody Sun Jul 6 23:25:52 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C18E91A0B0F for ; Sun, 6 Jul 2014 23:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.587 X-Spam-Level: X-Spam-Status: No, score=0.587 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fdHgKKCvZMA for ; Sun, 6 Jul 2014 23:25:49 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 545971A0347 for ; Sun, 6 Jul 2014 23:25:47 -0700 (PDT) Received: from WeiGengyuPC (unknown [10.103.241.112]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id F27E519F344; Mon, 7 Jul 2014 14:25:45 +0800 (HKT) Message-ID: From: "weigengyu" To: "Andrew Mcgregor" , "Barry Leiba" , "Zach Shelby" References: In-Reply-To: Date: Mon, 7 Jul 2014 14:25:45 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3522.110 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3522.110 Archived-At: http://mailarchive.ietf.org/arch/msg/core/r4QP_VEhVvCxdTFpcgOqrnNdQec Cc: core@ietf.org Subject: Re: [core] WGLC for draft-ietf-core-block-15 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 07 Jul 2014 06:25:51 -0000 Hi, I have a question about using TOKEN in block tranfer. In page 14 Figure 2: Simple blockwise GET, there is one GET and three ACK, each ACK with BLOCK1 should have the same TOKEN as the GET. should these ACKs with BLOCK1 have the same TOKEN? In Page 15 Figure 3: Blockwise GET with early negotiation, there are serveal GETs and their ACKs. Should these GETs With BLOCK2 have the same TOKEN? So, for receiving two GETs as an example, when the last GET has the same TOKEN as the first GET, they belong to one request according to BLOCK2 option. Without BLOCK2 the last GET may be a retransmited request, or it is irregular. Correct? Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications From: Andrew Mcgregor Sent: Saturday, July 05, 2014 7:56 AM To: core ; core-chairs@tools.ietf.org ; Barry Leiba ; Zach Shelby Subject: [core] WGLC for draft-ietf-core-block-15 The chairs believe that draft-ietf-core-block is now ready for last call. We intend a short last call on this document, since we would like to be able to discuss the results in Toronto in two weeks time. Please make any comments as soon as possible. The draft is located at: http://www.ietf.org/internet-drafts/draft-ietf-core-block-15.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-core-block/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-core-block-15 Andrew -- Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 1071 2221 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Mon Jul 7 00:55:15 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A39E1B2796 for ; Mon, 7 Jul 2014 00:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCJG6Xu5T5ur for ; Mon, 7 Jul 2014 00:55:08 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95BBD1A0076 for ; Mon, 7 Jul 2014 00:55: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.5/8.14.5) with ESMTP id s677sxLZ006437; Mon, 7 Jul 2014 09:55:00 +0200 (CEST) Received: from [192.168.217.145] (p54893088.dip0.t-ipconnect.de [84.137.48.136]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3ED0BCCC; Mon, 7 Jul 2014 09:54:59 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann X-Priority: 3 In-Reply-To: Date: Mon, 7 Jul 2014 09:54:57 +0200 X-Mao-Original-Outgoing-Id: 426412497.334724-f18dda1730cd49d0f3fb8403e1221d9e Content-Transfer-Encoding: quoted-printable Message-Id: <127E09E4-6034-4F78-A427-131D8FC8AA29@tzi.org> References: To: weigengyu X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/core/SY_p9pa63XOEo722xcfEhSr0RqY Cc: core Subject: Re: [core] WGLC for draft-ietf-core-block-15 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 07 Jul 2014 07:55:10 -0000 > In page 14 Figure 2: Simple blockwise GET, > there is one GET and three ACK, each ACK with BLOCK1 should have the = same TOKEN as the GET. > should these ACKs with BLOCK1 have the same TOKEN? You lost me, Figure 2 is about Block2. > In Page 15 Figure 3: Blockwise GET with early negotiation, > there are serveal GETs and their ACKs. > Should these GETs With BLOCK2 have the same TOKEN? Each response (piggybacked in an ACK here) should have the same token = that the request has. The client gets to choose the request token for each request = independently; it might be reusing a token or it might be using a new = one; that is up to the client=92s token usage. In any case, you never need to worry about tokens with Block. You handle the tokens just like you would handle them for any other = sequence of CoAP requests. Tokens do not play any special role with Block. (That=92s why the draft doesn=92t even mention tokens, except in the = Observe example, where it is given to remind people that the Observation = relationship blocks its token so you have to use different ones for the = block-wise transfer. Now that example might give the impression the block-wise transfer *has* = to be done with the same token (here; 0xfc) for all requests. Actually, it just happens that it *can* be done with the same token in = this case, but maybe that fact should be spelled out. Thanks for making = me aware of this possible misunderstanding.) Gr=FC=DFe, Carsten From nobody Mon Jul 7 01:49:44 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8B91B27E0 for ; Mon, 7 Jul 2014 01:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.214 X-Spam-Level: X-Spam-Status: No, score=-0.214 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PA89EK-zVTP9 for ; Mon, 7 Jul 2014 01:49:40 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id A2E221A02D0 for ; Mon, 7 Jul 2014 01:49:39 -0700 (PDT) Received: from WeiGengyuPC (unknown [10.103.241.112]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id AC1E319F3A0; Mon, 7 Jul 2014 16:49:38 +0800 (HKT) Message-ID: <395B95C6BE9147B9A630BE06A8A0884A@WeiGengyuPC> From: "weigengyu" To: "Carsten Bormann" References: <127E09E4-6034-4F78-A427-131D8FC8AA29@tzi.org> In-Reply-To: <127E09E4-6034-4F78-A427-131D8FC8AA29@tzi.org> Date: Mon, 7 Jul 2014 16:49:37 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3522.110 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3522.110 Archived-At: http://mailarchive.ietf.org/arch/msg/core/whSXeeNmhMj7bqBZ5CserIImTKo Cc: core Subject: Re: [core] WGLC for draft-ietf-core-block-15 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 07 Jul 2014 08:49:42 -0000 Hi Castern, Thank you for your reply. >> In page 14 Figure 2: Simple blockwise GET, >> there is one GET and three ACK, each ACK with BLOCK1 should have the same >> TOKEN as the GET. >> should these ACKs with BLOCK1 have the same TOKEN? > You lost me, Figure 2 is about Block2. Thank you for your correction. > Now that example might give the impression the block-wise transfer *has* > to be done with the same token (here; 0xfc) for all requests. Yes. While one token identifies one request, retransmission of one request should affect messages with the same tokens. It will be different if each request has a different token. Current draft considered retransmission of message(s), it may also consider the retransmission of Request. Regard, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: Carsten Bormann Sent: Monday, July 07, 2014 3:54 PM To: weigengyu Cc: core Subject: Re: [core] WGLC for draft-ietf-core-block-15 > In page 14 Figure 2: Simple blockwise GET, > there is one GET and three ACK, each ACK with BLOCK1 should have the same > TOKEN as the GET. > should these ACKs with BLOCK1 have the same TOKEN? You lost me, Figure 2 is about Block2. > In Page 15 Figure 3: Blockwise GET with early negotiation, > there are serveal GETs and their ACKs. > Should these GETs With BLOCK2 have the same TOKEN? Each response (piggybacked in an ACK here) should have the same token that the request has. The client gets to choose the request token for each request independently; it might be reusing a token or it might be using a new one; that is up to the client’s token usage. In any case, you never need to worry about tokens with Block. You handle the tokens just like you would handle them for any other sequence of CoAP requests. Tokens do not play any special role with Block. (That’s why the draft doesn’t even mention tokens, except in the Observe example, where it is given to remind people that the Observation relationship blocks its token so you have to use different ones for the block-wise transfer. Now that example might give the impression the block-wise transfer *has* to be done with the same token (here; 0xfc) for all requests. Actually, it just happens that it *can* be done with the same token in this case, but maybe that fact should be spelled out. Thanks for making me aware of this possible misunderstanding.) Grüße, Carsten From nobody Mon Jul 7 02:04:21 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCB51B27EB for ; Mon, 7 Jul 2014 02:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJkzujaqQWq6 for ; Mon, 7 Jul 2014 02:04:18 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4C21B27E0 for ; Mon, 7 Jul 2014 02:04:17 -0700 (PDT) Received: from WeiGengyuPC (unknown [10.103.241.112]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id B5A0919F3AE; Mon, 7 Jul 2014 17:04:14 +0800 (HKT) Message-ID: <2332307C5FFB4AC5B95296F95B0B63E6@WeiGengyuPC> From: "weigengyu" To: "Carsten Bormann" References: <127E09E4-6034-4F78-A427-131D8FC8AA29@tzi.org> <395B95C6BE9147B9A630BE06A8A0884A@WeiGengyuPC> In-Reply-To: <395B95C6BE9147B9A630BE06A8A0884A@WeiGengyuPC> Date: Mon, 7 Jul 2014 17:04:13 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3522.110 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3522.110 Archived-At: http://mailarchive.ietf.org/arch/msg/core/esZBeQq8ilLvrrEnx3ylKv5Q9ks Cc: core Subject: Re: [core] WGLC for draft-ietf-core-block-15 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 07 Jul 2014 09:04:20 -0000 Hi Carsten, Thank you for your reply. >> In page 14 Figure 2: Simple blockwise GET, >> there is one GET and three ACK, each ACK with BLOCK1 should have the same >> TOKEN as the GET. >> should these ACKs with BLOCK1 have the same TOKEN? > You lost me, Figure 2 is about Block2. Thank you for your correction. > Now that example might give the impression the block-wise transfer *has* > to be done with the same token (here; 0xfc) for all requests. Yes. While one token identifies one request, retransmission of one request should affect messages with the same tokens. It will be different if each request has a different token. Current draft considered retransmission of message(s), it may also consider the retransmission of Request. Regard, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: Carsten Bormann Sent: Monday, July 07, 2014 3:54 PM To: weigengyu Cc: core Subject: Re: [core] WGLC for draft-ietf-core-block-15 > In page 14 Figure 2: Simple blockwise GET, > there is one GET and three ACK, each ACK with BLOCK1 should have the same > TOKEN as the GET. > should these ACKs with BLOCK1 have the same TOKEN? You lost me, Figure 2 is about Block2. > In Page 15 Figure 3: Blockwise GET with early negotiation, > there are serveal GETs and their ACKs. > Should these GETs With BLOCK2 have the same TOKEN? Each response (piggybacked in an ACK here) should have the same token that the request has. The client gets to choose the request token for each request independently; it might be reusing a token or it might be using a new one; that is up to the client’s token usage. In any case, you never need to worry about tokens with Block. You handle the tokens just like you would handle them for any other sequence of CoAP requests. Tokens do not play any special role with Block. (That’s why the draft doesn’t even mention tokens, except in the Observe example, where it is given to remind people that the Observation relationship blocks its token so you have to use different ones for the block-wise transfer. Now that example might give the impression the block-wise transfer *has* to be done with the same token (here; 0xfc) for all requests. Actually, it just happens that it *can* be done with the same token in this case, but maybe that fact should be spelled out. Thanks for making me aware of this possible misunderstanding.) Grüße, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Mon Jul 7 07:12:55 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B781B2860 for ; Mon, 7 Jul 2014 07:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmfZj6Rw4TJI for ; Mon, 7 Jul 2014 07:12:52 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 923771A0163 for ; Mon, 7 Jul 2014 07:12:52 -0700 (PDT) Received: from localhost ([::1]:48257 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X49ez-0004Uy-Q3; Mon, 07 Jul 2014 07:12:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Mon, 07 Jul 2014 14:12:49 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/362#comment:1 Message-ID: <066.31e7df9ae582a3b45f99b41b6f5418b9@trac.tools.ietf.org> References: <051.9ff0db7628ca0b646f7a814ed3152667@trac.tools.ietf.org> X-Trac-Ticket-ID: 362 In-Reply-To: <051.9ff0db7628ca0b646f7a814ed3152667@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 zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Archived-At: http://mailarchive.ietf.org/arch/msg/core/miHwF3yNqA9z7zSkeMIXluGwDlU Cc: core@ietf.org Subject: Re: [core] #362 (coap): We do have a NoCacheKey attribute in the base spec now X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Reply-To: trac+core@zinfandel.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, 07 Jul 2014 14:12:54 -0000 #362: We do have a NoCacheKey attribute in the base spec now Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in RFC 7252. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: editorial | Status: closed Priority: minor | Milestone: AUTH48 Component: coap | Version: coap-18 Severity: Submitted | Resolution: fixed WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From nobody Mon Jul 7 07:18:07 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB821A011C for ; Mon, 7 Jul 2014 07:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Qjx6WfDscyh for ; Mon, 7 Jul 2014 07:18:00 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 57EBC1A0127 for ; Mon, 7 Jul 2014 07:18:00 -0700 (PDT) Received: from WeiGengyuPC (unknown [222.131.14.182]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 5AAEF19F372 for ; Mon, 7 Jul 2014 22:17:59 +0800 (HKT) Message-ID: From: "weigengyu" To: References: <127E09E4-6034-4F78-A427-131D8FC8AA29@tzi.org> <395B95C6BE9147B9A630BE06A8A0884A@WeiGengyuPC> <2332307C5FFB4AC5B95296F95B0B63E6@WeiGengyuPC> In-Reply-To: <2332307C5FFB4AC5B95296F95B0B63E6@WeiGengyuPC> Date: Mon, 7 Jul 2014 22:17:55 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3522.110 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3522.110 Archived-At: http://mailarchive.ietf.org/arch/msg/core/E0ZS7kWKzKrZnINQMMrv23C6xYk Subject: Re: [core] WGLC for draft-ietf-core-block-15 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 07 Jul 2014 14:18:04 -0000 Hi all, The concept of one CoAP request in block transfer needs clarifying. And the the relation between token and one request has been described in RFC7252. So, If the request is sent in a block, then it may be (A) the whole bLock is a request, or (B) each piece of the block is a request. If (A), each piece of the block should have the same token. If (B), each piece of the block should use different token. By my understanding it is (A). The problem that I concern is when the request needs restransmiting, the client will re-send the whole block. Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: weigengyu Sent: Monday, July 07, 2014 5:04 PM To: Carsten Bormann Cc: core Subject: Re: [core] WGLC for draft-ietf-core-block-15 Hi Carsten, Thank you for your reply. >> In page 14 Figure 2: Simple blockwise GET, >> there is one GET and three ACK, each ACK with BLOCK1 should have the same >> TOKEN as the GET. >> should these ACKs with BLOCK1 have the same TOKEN? > You lost me, Figure 2 is about Block2. Thank you for your correction. > Now that example might give the impression the block-wise transfer *has* > to be done with the same token (here; 0xfc) for all requests. Yes. While one token identifies one request, retransmission of one request should affect messages with the same tokens. It will be different if each request has a different token. Current draft considered retransmission of message(s), it may also consider the retransmission of Request. Regard, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: Carsten Bormann Sent: Monday, July 07, 2014 3:54 PM To: weigengyu Cc: core Subject: Re: [core] WGLC for draft-ietf-core-block-15 > In page 14 Figure 2: Simple blockwise GET, > there is one GET and three ACK, each ACK with BLOCK1 should have the same > TOKEN as the GET. > should these ACKs with BLOCK1 have the same TOKEN? You lost me, Figure 2 is about Block2. > In Page 15 Figure 3: Blockwise GET with early negotiation, > there are serveal GETs and their ACKs. > Should these GETs With BLOCK2 have the same TOKEN? Each response (piggybacked in an ACK here) should have the same token that the request has. The client gets to choose the request token for each request independently; it might be reusing a token or it might be using a new one; that is up to the client’s token usage. In any case, you never need to worry about tokens with Block. You handle the tokens just like you would handle them for any other sequence of CoAP requests. Tokens do not play any special role with Block. (That’s why the draft doesn’t even mention tokens, except in the Observe example, where it is given to remind people that the Observation relationship blocks its token so you have to use different ones for the block-wise transfer. Now that example might give the impression the block-wise transfer *has* to be done with the same token (here; 0xfc) for all requests. Actually, it just happens that it *can* be done with the same token in this case, but maybe that fact should be spelled out. Thanks for making me aware of this possible misunderstanding.) Grüße, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Mon Jul 7 07:21:00 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C611A010A for ; Mon, 7 Jul 2014 07:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dq5BgmUZ50QG for ; Mon, 7 Jul 2014 07:20:54 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 082B31A00FF for ; Mon, 7 Jul 2014 07:20:54 -0700 (PDT) Received: from localhost ([::1]:49342 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X49mn-0004QU-Tr; Mon, 07 Jul 2014 07:20:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: cabo@tzi.org X-Trac-Project: core Date: Mon, 07 Jul 2014 14:20:53 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/368 Message-ID: <051.982738dd70bf31f802961c9bbcb44442@trac.tools.ietf.org> X-Trac-Ticket-ID: 368 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/core/q5WJwYmDzs9DLAhLMP9YXQHR_wo Cc: core@ietf.org Subject: [core] #368 (block): Clarify that there is nothing special about tokens in -block X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Reply-To: trac+core@zinfandel.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, 07 Jul 2014 14:20:56 -0000 #368: Clarify that there is nothing special about tokens in -block There is no mention of tokens in -block-15, which is good, as -block doesn't do anything special with tokens. Except for the examples in section 3.4, where the point is made that the block-wise transfer needs to use tokens different from the one in the notifications in the observation relationship. These simply show one additional token, but do not make the point that as usual the client is free to choose tokens for this as it likes. (Input from Gengyu WEI.) -- -----------------------------+-------------------------- Reporter: cabo@tzi.org | Owner: cabo@tzi.org Type: editorial | Status: new Priority: minor | Milestone: post-WGLC-2 Component: block | Version: Severity: In WG Last Call | Keywords: -----------------------------+-------------------------- Ticket URL: core From nobody Mon Jul 7 07:26:15 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C051F1A017C for ; Mon, 7 Jul 2014 07:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbDarHBOQHnL for ; Mon, 7 Jul 2014 07:26:11 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71B791A011C for ; Mon, 7 Jul 2014 07:26: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.5/8.14.5) with ESMTP id s67EQ0ak023873; Mon, 7 Jul 2014 16:26:00 +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 C01AFBA; Mon, 7 Jul 2014 16:25:59 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann X-Priority: 3 In-Reply-To: Date: Mon, 7 Jul 2014 16:25:59 +0200 X-Mao-Original-Outgoing-Id: 426435959.104522-5c851cf2d235d29f3b137adb6c8628b9 Content-Transfer-Encoding: quoted-printable Message-Id: <6C6E113C-2ACF-4492-B329-2EFD96EBC677@tzi.org> References: <127E09E4-6034-4F78-A427-131D8FC8AA29@tzi.org> <395B95C6BE9147B9A630BE06A8A0884A@WeiGengyuPC> <2332307C5FFB4AC5B95296F95B0B63E6@WeiGengyuPC> To: weigengyu X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/core/4wP6JS9TnJVliuuBYmF8QEmk0zY Cc: core@ietf.org Subject: Re: [core] WGLC for draft-ietf-core-block-15 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 07 Jul 2014 14:26:12 -0000 Point of terminology: we call the pieces =93blocks=94, not the entire = block-wise transfer. The -block protocol is strictly layered above the CoAP core protocol. So there is no way the block transfer can influence or take advantage of = specific token values. Each of the blocks (pieces) is its own CoAP transfer, with its own = request, response, and a token linking the two. For all the blocks in a = block-wise transfer, the token may be the same if the client chooses so = (and the conditions for re-using a token are fulfilled), they may be all = different, or a mixture of these. Gr=FC=DFe, Carsten From nobody Mon Jul 7 08:41:25 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 925FC1A0305 for ; Mon, 7 Jul 2014 08:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExxEpeKxrbQj for ; Mon, 7 Jul 2014 08:41:21 -0700 (PDT) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53FCE1A031F for ; Mon, 7 Jul 2014 08:41:21 -0700 (PDT) X-ASG-Debug-ID: 1404747679-06daaa097323c40001-aa7cYp Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id QYxNH3w9R1k64iat for ; Mon, 07 Jul 2014 11:41:19 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Jul 2014 11:41:18 -0400 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: Mon, 7 Jul 2014 11:41:17 -0400 X-ASG-Orig-Subj: RE: [core] WGLC for draft-ietf-core-block-15 Message-ID: In-Reply-To: <6C6E113C-2ACF-4492-B329-2EFD96EBC677@tzi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] WGLC for draft-ietf-core-block-15 Thread-Index: Ac+Z72pJVcU2mvZQSauuRqhpAt9IFwACeN2Q References: <127E09E4-6034-4F78-A427-131D8FC8AA29@tzi.org> <395B95C6BE9147B9A630BE06A8A0884A@WeiGengyuPC> <2332307C5FFB4AC5B95296F95B0B63E6@WeiGengyuPC> <6C6E113C-2ACF-4492-B329-2EFD96EBC677@tzi.org> From: "Rahman, Akbar" To: "Carsten Bormann" , "weigengyu" X-OriginalArrivalTime: 07 Jul 2014 15:41:18.0828 (UTC) FILETIME=[E5333AC0:01CF99F9] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1404747679 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.7316 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Archived-At: http://mailarchive.ietf.org/arch/msg/core/LdDiKr6Ka-BTaxn1DJkMeuNCN60 Cc: core@ietf.org Subject: Re: [core] WGLC for draft-ietf-core-block-15 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 07 Jul 2014 15:41:23 -0000 Hi Carsten, Do you think it is worth adding an updated version of the Figure 1 = (Abstract Layering of CoAP) from RFC 7252 into core-block-15 to show = this layering? Akbar -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: Monday, July 07, 2014 10:26 AM To: weigengyu Cc: core@ietf.org Subject: Re: [core] WGLC for draft-ietf-core-block-15 Point of terminology: we call the pieces "blocks", not the entire = block-wise transfer. The -block protocol is strictly layered above the CoAP core protocol. So there is no way the block transfer can influence or take advantage of = specific token values. Each of the blocks (pieces) is its own CoAP transfer, with its own = request, response, and a token linking the two. For all the blocks in a = block-wise transfer, the token may be the same if the client chooses so = (and the conditions for re-using a token are fulfilled), they may be all = different, or a mixture of these. Gr=FC=DFe, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Mon Jul 7 14:10:19 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA46A1B28E8 for ; Mon, 7 Jul 2014 14:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.214 X-Spam-Level: X-Spam-Status: No, score=-0.214 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSjGxWtCG1SA for ; Mon, 7 Jul 2014 14:10:16 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id D38421B28E6 for ; Mon, 7 Jul 2014 14:10:15 -0700 (PDT) Received: from WeiGengyuPC (unknown [222.131.14.182]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 2BB8F19F344; Tue, 8 Jul 2014 05:10:12 +0800 (HKT) Message-ID: From: "weigengyu" To: "Carsten Bormann" References: <127E09E4-6034-4F78-A427-131D8FC8AA29@tzi.org> <395B95C6BE9147B9A630BE06A8A0884A@WeiGengyuPC> <2332307C5FFB4AC5B95296F95B0B63E6@WeiGengyuPC> <6C6E113C-2ACF-4492-B329-2EFD96EBC677@tzi.org> In-Reply-To: <6C6E113C-2ACF-4492-B329-2EFD96EBC677@tzi.org> Date: Tue, 8 Jul 2014 05:10:11 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3522.110 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3522.110 Archived-At: http://mailarchive.ietf.org/arch/msg/core/GVsxKS9jIVgmVNd_aLqe3jxUKzo Cc: core@ietf.org Subject: Re: [core] WGLC for draft-ietf-core-block-15 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 07 Jul 2014 21:10:18 -0000 Hi Carsten, Using Block Transfer, the token of each CoAP request can be the same or not. Actually, token functions nothing for the client. Considering CoRE, zero length token is best for all requests as it is the shortest. Within the Block transfer option, another means is defined to relate each request carried one block and the response instead of using token. Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: Carsten Bormann Sent: Monday, July 07, 2014 10:25 PM To: weigengyu Cc: core@ietf.org Subject: Re: [core] WGLC for draft-ietf-core-block-15 Point of terminology: we call the pieces “blocksâ€, not the entire block-wise transfer. The -block protocol is strictly layered above the CoAP core protocol. So there is no way the block transfer can influence or take advantage of specific token values. Each of the blocks (pieces) is its own CoAP transfer, with its own request, response, and a token linking the two. For all the blocks in a block-wise transfer, the token may be the same if the client chooses so (and the conditions for re-using a token are fulfilled), they may be all different, or a mixture of these. Grüße, Carsten From nobody Mon Jul 7 14:21:56 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1985C1B291D for ; Mon, 7 Jul 2014 14:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-pIEZ4XDC9V for ; Mon, 7 Jul 2014 14:21:52 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2137A1B291C for ; Mon, 7 Jul 2014 14:21:49 -0700 (PDT) Received: from WeiGengyuPC (unknown [222.131.14.182]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 7C97C19F374; Tue, 8 Jul 2014 05:21:48 +0800 (HKT) Message-ID: <18BC942EC30140569A6670C55B1D26D7@WeiGengyuPC> From: "weigengyu" To: "Rahman, Akbar" , "Carsten Bormann" References: <127E09E4-6034-4F78-A427-131D8FC8AA29@tzi.org> <395B95C6BE9147B9A630BE06A8A0884A@WeiGengyuPC> <2332307C5FFB4AC5B95296F95B0B63E6@WeiGengyuPC> <6C6E113C-2ACF-4492-B329-2EFD96EBC677@tzi.org> In-Reply-To: Date: Tue, 8 Jul 2014 05:21:47 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3522.110 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3522.110 Archived-At: http://mailarchive.ietf.org/arch/msg/core/XaZBMqc4owIG-M3mRUEDDLCjpYc Cc: core@ietf.org Subject: Re: [core] WGLC for draft-ietf-core-block-15 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 07 Jul 2014 21:21:55 -0000 Hi Akbar, Refering to layered protocol concept, the upper layer is tried to use the lower layer capabilities instead of making useless. Regard, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: Rahman, Akbar Sent: Monday, July 07, 2014 11:41 PM To: Carsten Bormann ; weigengyu Cc: core@ietf.org Subject: RE: [core] WGLC for draft-ietf-core-block-15 Hi Carsten, Do you think it is worth adding an updated version of the Figure 1 (Abstract Layering of CoAP) from RFC 7252 into core-block-15 to show this layering? Akbar -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: Monday, July 07, 2014 10:26 AM To: weigengyu Cc: core@ietf.org Subject: Re: [core] WGLC for draft-ietf-core-block-15 Point of terminology: we call the pieces "blocks", not the entire block-wise transfer. The -block protocol is strictly layered above the CoAP core protocol. So there is no way the block transfer can influence or take advantage of specific token values. Each of the blocks (pieces) is its own CoAP transfer, with its own request, response, and a token linking the two. For all the blocks in a block-wise transfer, the token may be the same if the client chooses so (and the conditions for re-using a token are fulfilled), they may be all different, or a mixture of these. Grüße, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Thu Jul 10 15:04:07 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF521B27CA for ; Thu, 10 Jul 2014 15:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ew920S6zAGhE for ; Thu, 10 Jul 2014 15:04:04 -0700 (PDT) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93C0E1A000E for ; Thu, 10 Jul 2014 15:04:04 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ho1so420859wib.16 for ; Thu, 10 Jul 2014 15:04:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=RIyAD/QKbjesFcH0H5ynpEEGv0mx+Gx1zjqLtuVpl9E=; b=T3PHKqhCq7i/vrXNFAyEjW/5o53k0pSBnOlL82qJvX7NNA7fGfZ4s6dnMEIyKzhwut KwU1ryQbCOxIjoNFdRdBKzn1uivZvgvtyyvNpflHuy36g8g2W4DIp+GiWvQywhnHXbxS Zf9vMCM/vAE/aAHZ4fP/SlOT05xhduCBfZGEG2puQG/6mmqan6SGh/YOlBjsL93/ABE4 NvCj/PIqg4GKrQ+hldwk5G+NWBn84BP9iaY1iQbIKI37wDLzeKcuciAwtJ0+RVpxK/Yk ReGwWOlVnCxM6d1oUoJeDQoMJIJwb4bx9kl2i7niFGA/DtIPTb/TaOIuO2JhU495drGZ xfog== X-Gm-Message-State: ALoCoQmMGpl1WzEQtM7AqgBNBiIQXTI1OfNQ4sNa7Z6zl3ejhs/jAzHZY+ggLZQKdhqDzZYrocIW X-Received: by 10.180.78.74 with SMTP id z10mr18546396wiw.14.1405029843158; Thu, 10 Jul 2014 15:04:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.58.134 with HTTP; Thu, 10 Jul 2014 15:03:43 -0700 (PDT) From: Patrick Barrett Date: Thu, 10 Jul 2014 17:03:43 -0500 Message-ID: To: core@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/core/Wnr3G_2sTpErDP4XoQ0o0HPmk5c Subject: [core] CoAP Option for Authentication Token X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 10 Jul 2014 22:04:06 -0000 Our company is currently in the process of porting our HTTP API over to CoAP. With our current API we use an HTTP header (X-Exosite-CIK) for sending an auth token and in our current CoAP implementation we're just sending this as a query parameter. Since we'd like the option of sending it in a raw binary value from to save bytes, it's my understanding that this actually violates the protocol since it isn't guaranteed to be valid UTF-8. The only two options in the main RFC that allow opaque byte strings (If-Match and ETag) don't seem appropriate and don't allow long enough values. I looked through the other drafts and didn't see any that added options that seemed more appropriate. I also looked at the IANA registry, but that seems to only have the options from the RFC. Is there an existing option that would be appropriate for this use? If not what is the process for proposing one? I'm not fimilar with what the terms "IETF Review or IESG Approval", "Specification Required", or "Expert Review" mean. I'm willing to help in any way I can. Thanks -- Patrick Barrett // E X O S I T E // Minneapolis, MN // www.exosite.com From nobody Thu Jul 10 15:47:35 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F6B1A002A for ; Thu, 10 Jul 2014 15:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0ClPTOKSFXB for ; Thu, 10 Jul 2014 15:47:33 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 124141A004E for ; Thu, 10 Jul 2014 15:47:31 -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.5/8.14.5) with ESMTP id s6AMlS1g014218; Fri, 11 Jul 2014 00:47:28 +0200 (CEST) Received: from [192.168.217.145] (p548939E3.dip0.t-ipconnect.de [84.137.57.227]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 7F8565F3; Fri, 11 Jul 2014 00:47:27 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: Date: Fri, 11 Jul 2014 00:47:26 +0200 X-Mao-Original-Outgoing-Id: 426725245.923673-109e75f1e242a03fbd8fbe33c2c4862c Content-Transfer-Encoding: quoted-printable Message-Id: <0C645039-A1EB-413E-BF89-127CFA0F2669@tzi.org> References: To: Patrick Barrett X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/core/4AgT9OgI2Be10py5Yuei33j9-QM Cc: core@ietf.org Subject: Re: [core] CoAP Option for Authentication Token X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 10 Jul 2014 22:47:34 -0000 Hi Patrick, I think others will comment on whether it is wise to send authentication = tokens in the clear. Brace for impact=85 :-) I=92ll just try to answer these questions: On 11 Jul 2014, at 00:03, Patrick Barrett = wrote: > Is there an existing option that would be appropriate for this use? I don=92t think so. There is an active discussion about node-IDs, and maybe something coming = out of that discussion will come close, but that may be too late for = you. > If > not what is the process for proposing one? If you want to have a =93standard=94 one that everybody else will also = want to use, you just have started that process, but it might take a = while. If you really just want one for use between consenting implementations, = you could go for one of these (section 12.2): | 256-2047 | Specification Required | | 2048-64999 | Expert Review | Specification required means that you have written up in a stable form = what the option is supposed to do, so others have a chance to implement = it in an interoperable way (you can review http://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml for a related registry that is just a bit further along in the process). = Expert review just means there will be a review "to help ensure that = the option semantics are defined correctly=94 =97 that may be a very = useful review. In both cases, you use the form at http://www.iana.org/cgi-bin/assignments.pl to submit the request. If you want to be nice, you send a heads-up = beforehand to coap-parameters@ietf.org (after subscribing at https://www.ietf.org/mailman/listinfo/core-parameters so you see any ensuing discussion. Don=92t worry, the list traffic will = not kill you=85) Gr=FC=DFe, Carsten From nobody Thu Jul 10 17:22:39 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A58111B289A for ; Thu, 10 Jul 2014 17:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9tRYh48OKlo for ; Thu, 10 Jul 2014 17:22:34 -0700 (PDT) Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DCF31B2A89 for ; Thu, 10 Jul 2014 17:22:33 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id q58so307550wes.16 for ; Thu, 10 Jul 2014 17:22:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=EPwqbaZss6hPLOF18Ilrl9DoLXYuot9niWJf1mnhwfI=; b=a+FgZ5ocgrRMjaoIAbqe45G5idU3uLfmRzV0UQkm1moOn/+BUH6rE3hSsmHoqucMg2 i85t+Ep1a4GlFV+El23/T2x+wgBsq41ZMuaIA2+UkOU6Pippwulet/ReXOgP/FVe1ygp Fdk7tUrxCs25aUwKYrzsfYMuETyFiJqQqEdr7kwHAcUFSM0G0/G1tBP2myk27YxgH6wH a1fzUWdPqCavuJJ2gbVFYcRwQd5rxNS5VZC78e4/dFlVSb9wNcvNGju5QjFi2g+S1i1d 3G7YzQ0TkDKcHOCkNN2WJPqxKYqzBLPI+KmINVX3fRZVHB+4GKD0Cu5NvIqySfVf2Uxb yAIQ== X-Gm-Message-State: ALoCoQlZVsx4b1ks8mJ3XYRMr7BjBc6aNJbt/isB5U7M1vuUN5r5EMhXEJE7GUw1JwB7e79qGK7T X-Received: by 10.180.78.74 with SMTP id z10mr486150wiw.14.1405038149336; Thu, 10 Jul 2014 17:22:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.58.134 with HTTP; Thu, 10 Jul 2014 17:22:09 -0700 (PDT) In-Reply-To: <0C645039-A1EB-413E-BF89-127CFA0F2669@tzi.org> References: <0C645039-A1EB-413E-BF89-127CFA0F2669@tzi.org> From: Patrick Barrett Date: Thu, 10 Jul 2014 19:22:09 -0500 Message-ID: To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/core/8w3GLf0yLkFb0KF8HE5jaOm3qNo Cc: core@ietf.org Subject: Re: [core] CoAP Option for Authentication Token X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 11 Jul 2014 00:22:36 -0000 On Thu, Jul 10, 2014 at 5:47 PM, Carsten Bormann wrote: > Hi Patrick, > > I think others will comment on whether it is wise to send authentication = tokens in the clear. > Brace for impact=E2=80=A6 :-) I am aware, but we support it for devices like Arduino that don't support DTLS. Regardless, my soul is prepared for the incoming opinions. > > I=E2=80=99ll just try to answer these questions: > > On 11 Jul 2014, at 00:03, Patrick Barrett wr= ote: > >> Is there an existing option that would be appropriate for this use? > > I don=E2=80=99t think so. > There is an active discussion about node-IDs, and maybe something coming = out of that discussion will come close, but that may be too late for you. That looks like it may be a good option. Although it does claim that the format is string, but then it says that "The value can be in the form of Binary bits...", so maybe they actually intend for it to be an opaque format. >> If >> not what is the process for proposing one? > > If you want to have a =E2=80=9Cstandard=E2=80=9D one that everybody else = will also want to use, you just have started that process, but it might tak= e a while. > > If you really just want one for use between consenting implementations, y= ou could go for one of these (section 12.2): > > | 256-2047 | Specification Required | > | 2048-64999 | Expert Review | > > Specification required means that you have written up in a stable form wh= at the option is supposed to do, so others have a chance to implement it in= an interoperable way (you can review > > http://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml > > for a related registry that is just a bit further along in the process). = Expert review just means there will be a review "to help ensure that the o= ption semantics are defined correctly=E2=80=9D =E2=80=94 that may be a very= useful review. > > In both cases, you use the form at > > http://www.iana.org/cgi-bin/assignments.pl > > to submit the request. If you want to be nice, you send a heads-up befor= ehand to > > coap-parameters@ietf.org > > (after subscribing at > > https://www.ietf.org/mailman/listinfo/core-parameters > > so you see any ensuing discussion. Don=E2=80=99t worry, the list traffic= will not kill you=E2=80=A6) Thanks for taking the time to detail all this out for me. > > Gr=C3=BC=C3=9Fe, Carsten > --=20 Patrick Barrett // E X O S I T E // Minneapolis, MN // www.exosite.co= m From nobody Sun Jul 13 18:15:25 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7351A0217 for ; Sun, 13 Jul 2014 18:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.149 X-Spam-Level: X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YPMGlKE8FEr for ; Sun, 13 Jul 2014 18:15:20 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2277B1A0208 for ; Sun, 13 Jul 2014 18:15:18 -0700 (PDT) Received: from WeiGengyuPC (unknown [10.103.241.112]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 2F8FA19F36F for ; Mon, 14 Jul 2014 09:15:14 +0800 (HKT) Message-ID: <2A1C1F2703194C0F968CD839505116C0@WeiGengyuPC> From: "weigengyu" To: Date: Mon, 14 Jul 2014 09:15:07 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CF9F44.1ABF7060" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3522.110 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3522.110 Archived-At: http://mailarchive.ietf.org/arch/msg/core/m2Gdh-t6rbd831l5b5PB8qMm35M Subject: [core] Considering how to use Token X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 14 Jul 2014 01:15:23 -0000 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à·½Óʼþ¡£ ------=_NextPart_000_0007_01CF9F44.1ABF7060 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi all,=20 I have a question about using token when considering implementation of = CoAP.=20 My question is whether the Token is needed in a message of Empty? In RFC7252, Page 21,=20 =A1=B0Separate from the message type, a message may carry a request, a = response, or be Empty.=20 This is signaled by the Request/Response Code field in the CoAP Header=20 and is relevant to the request/response model.=20 Possible values for the field are maintained in the CoAP Code Registries = (Section 12.1). An Empty message has the Code field set to 0.00.=20 The Token Length field MUST be set to 0 and bytes of data MUST NOT be = present after the Message ID field.=20 If there are any bytes, they MUST be processed as a message format = error. =A1=B0 According to RFC7252, the message of Empty is used to acknowlege the CON message by MID, and = Token is meaningless. Could the token be omitted in the message of Empty?=20 Regards,=20 Gengyu WEI Network Technology Center School of Computer=20 Beijing University of Posts and Telecommunications ------=_NextPart_000_0007_01CF9F44.1ABF7060 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi all,
 
I have a question about using token when considering implementation = of=20 CoAP.
My question is whether the Token is needed in  a message of=20 Empty?
 
In RFC7252, Page 21,
=A1=B0Separate from the message type, a message may carry a = request, a response,=20 or be Empty.
This is signaled by the Request/Response Code field in the CoAP = Header=20
and is relevant to the request/response model.
Possible values for the field are maintained in the CoAP Code = Registries=20 (Section 12.1).
An Empty message has the Code field set to 0.00.
The Token Length field MUST be set to 0 and bytes of data MUST NOT = be=20 present after the Message ID field.
If there are any bytes, they MUST be processed as a message format = error.=20 =A1=B0
 
According to RFC7252,
the message of Empty is used to acknowlege the CON message by = MID, =20 and Token is meaningless.
Could the token be omitted in the message of Empty?
 
Regards,
 
Gengyu=20 WEI
Network Technology Center
School of Computer
Beijing = University of=20 Posts and Telecommunications
------=_NextPart_000_0007_01CF9F44.1ABF7060-- From nobody Mon Jul 14 00:42:18 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F951A0347 for ; Mon, 14 Jul 2014 00:42:14 -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=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flVvT4BX4Pog for ; Mon, 14 Jul 2014 00:42:11 -0700 (PDT) Received: from outbox.sics.se (outbox.sics.se [193.10.64.137]) by ietfa.amsl.com (Postfix) with ESMTP id 230081A033D for ; Mon, 14 Jul 2014 00:42:11 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [192.36.171.201]) by outbox.sics.se (Postfix) with ESMTPS id 5A4E757AE; Mon, 14 Jul 2014 09:42:09 +0200 (CEST) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s6E7g8RQ013294; Mon, 14 Jul 2014 09:42:08 +0200 Received: from [192.168.0.108] (unknown [85.235.11.178]) (Authenticated sender: ludwig@sics.se) by letter.sics.se (Postfix) with ESMTPSA id CA16B40116; Mon, 14 Jul 2014 09:42:08 +0200 (CEST) Message-ID: <53C389CB.4020607@sics.se> Date: Mon, 14 Jul 2014 09:42:03 +0200 From: Ludwig Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: core@ietf.org References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050002040609070902080400" X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sics-se:default, sics-se:default, base:default, @@RPTN) X-p0f-Info: os=Solaris 10, link=Ethernet or modem X-CanIt-Geo: =?UTF-8?Q?ip=3D85.235.11.178; _country=3DSE; _region=3DSk=C3=A5ne; _city=3DLund; _latitude=3D55.7000; _longitude=3D13.1833; _http://maps.google.com/maps=3Fq=3D55.7000,13.1833&z=3D6?= X-CanItPRO-Stream: outbound-sics-se:outbound (inherits from outbound-sics-se:default, sics-se:default, base:default) X-Canit-Stats-ID: 09Mq7G84n - 030ab66651f3 - 20140714 X-Antispam-Training-Forget: https://canit.sunet.se/canit/b.php?i=09Mq7G84n&m=030ab66651f3&t=20140714&c=f X-Antispam-Training-Nonspam: https://canit.sunet.se/canit/b.php?i=09Mq7G84n&m=030ab66651f3&t=20140714&c=n X-Antispam-Training-Spam: https://canit.sunet.se/canit/b.php?i=09Mq7G84n&m=030ab66651f3&t=20140714&c=s X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: http://mailarchive.ietf.org/arch/msg/core/Io18oAIQTSEbcR8npU8L_4D_4Ik Subject: Re: [core] CoAP Option for Authentication Token X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 14 Jul 2014 07:42:14 -0000 This is a cryptographically signed message in MIME format. --------------ms050002040609070902080400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 07/11/2014 12:03 AM, Patrick Barrett wrote: > Our company is currently in the process of porting our HTTP API over > to CoAP. With our current API we use an HTTP header (X-Exosite-CIK) > for sending an auth token and in our current CoAP implementation we're > just sending this as a query parameter. Since we'd like the option of > sending it in a raw binary value from to save bytes, it's my > understanding that this actually violates the protocol since it isn't > guaranteed to be valid UTF-8. The only two options in the main RFC > that allow opaque byte strings (If-Match and ETag) don't seem > appropriate and don't allow long enough values. I looked through the > other drafts and didn't see any that added options that seemed more > appropriate. I also looked at the IANA registry, but that seems to > only have the options from the RFC. > > Is there an existing option that would be appropriate for this use? If > not what is the process for proposing one? I'm not fimilar with what > the terms "IETF Review or IESG Approval", "Specification Required", or > "Expert Review" mean. I'm willing to help in any way I can. > > Thanks > Hello Patrick, we considered a similar thing a while ago: sending autorization tokens=20 via CoAP options. One issue seems to be that fragmentation only works=20 for payload, not for options, so depending on the length of your token=20 you might run into trouble. Regards, Ludwig Shameless plug: If you are interested in authentication and=20 authorization for CoRE, I invite you to join the discussion of the ACE=20 working group (https://datatracker.ietf.org/wg/ace). I'm sure the WG=20 would very much like to hear about your usecase. --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelev=E4gen 17 SE-223 70 Lund Phone +46(0)70-349 92 51 http://www.sics.se --------------ms050002040609070902080400 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMVDCC BhgwggUAoAMCAQICAwiRTjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTE0MDEwNzA3MjgzNVoXDTE1MDEwNzEyNTgyMlowODEXMBUGA1UE AwwObHVkd2lnQHNpY3Muc2UxHTAbBgkqhkiG9w0BCQEWDmx1ZHdpZ0BzaWNzLnNlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnLm1tc30QxHa9wtdVjC3NgxjLJicnccm0HD+ 1X16kPMKGvwps8F1oDhYn7jXIe46p1AuJMzLK0GIioE4JwxCFGdvpz7cg2xyTyrdBVUzSqez Dfqt4FOJq6hrdrIMS8MHEzl7Jk02gv9cTn/pHQvDpkiThRpbSLU5mlMqtEQ8gDQY5YyBX0Mv 5qculV08I2JU8HEeTt1oeqhvBImgQfOVYMDatHlWHUVVrmYd6iIo+cuiUGd5kiA0XuaLYX0E oCoao/z5Wg9U0sQlx0hl4r96Q+NdoZZ1prfts3qtyBzJ2hu135aikigzJ6sueWHv/jbISUek tOMm0xkx1GOqqWtEAwIDAQABo4IC1DCCAtAwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBRZmjjBh8N3klra+mVQgC00 pl68ZTAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAZBgNVHREEEjAQgQ5sdWR3 aWdAc2ljcy5zZTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsG AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcC AjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0 aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5 aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0 YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzAB hi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN AQELBQADggEBAHqEYmtWr83S+iLXE97KBnHJZiMr6PMuLKxmh0o6UJJwKgf+KTP2czxRnPSI +whuqfQZdmz6g3A2K8AooMU0RXrzncnX1c4826APdnXkRxnGQxtZXI1wuhPn4z7iDKZ6ij9u K5Pfn10JL/ERDig2qJQbqvhtIAx0RY7y7r+hLMvgXVq9mf3WRJYmGQeFW+N9t5Z1eEwG4m9R KAZm0fnfeDn/Ai4kmxTckBH7dZwW2lTtwQqQ4su+PGCJ0e9ndBLpvTqaYGSAl+L7PO7vxPhS /cS67Xa6BtnYJLTr3MaGXaN+CEUFSfwQHa9DKcAqh3kldErI3kCvnot0CigBl4aILOEwggY0 MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEw MjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0d Lep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiU fsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5Dp IpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuC YKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/ MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0j BBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUFBzAB hhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nm c2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9 eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukD FUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyi kfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8Cnykh ExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b 970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCD z+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqA SfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076khXO7cNb BIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8J7GCUBth HSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRXun0NbeY+ UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAwiRTjAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA3MTQwNzQyMDNaMCMGCSqGSIb3DQEJBDEW BBT3inYRRfZacealO0RqBTAssZRSsDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDCJFOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMIkU4wDQYJKoZIhvcNAQEBBQAE ggEAlN/wJVIDamY7NS6W02kPzz5Fa8/AstoqOgyY7bHzdPvZMEcDixzJMYiYa7jaSSxo46mi QYy7EUTicXatQk3nGHnYsv1fPEde1j7NyR99VoezV0wtb94P6645N+DO3LHRK4JsXwg/dgGa 6DdmOsVmXxy3w9ca8lPOKTGaJkXVOrBGMGDe1wI1iPbnQ5HTkhFPD6q6hzIhEx8vVvpSiF66 K3nnO6UWVQZTJ+bEmTEWiEtE+s55oIWqstO6yEOCyDFlWCoFD4n2IUSzOBBQ9REU0WeRyIVy O27Xd0jPLts/mDb6g/AkTt8ZKW/+x2/UXAOoJuzOf2xk78VlRUCWSaaA0gAAAAAAAA== --------------ms050002040609070902080400-- From nobody Mon Jul 14 03:11:47 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD901A038F for ; Mon, 14 Jul 2014 03:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gI8oEtDjfjgf for ; Mon, 14 Jul 2014 03:11:37 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8850D1A038D for ; Mon, 14 Jul 2014 03:11: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.5/8.14.5) with ESMTP id s6EABJKK022678; Mon, 14 Jul 2014 12:11:20 +0200 (CEST) Received: from aung.tzi.org (dynamic-218-6.informatik.uni-bremen.de [134.102.218.236]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 84124153; Mon, 14 Jul 2014 12:11:19 +0200 (CEST) From: Olaf Bergmann To: "weigengyu" Date: Mon, 14 Jul 2014 12:10:48 +0200 References: <2A1C1F2703194C0F968CD839505116C0@WeiGengyuPC> Message-ID: <87vbr0w8qg.fsf@tzi.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/core/0p8AmMXB1VnzXyH_JstO3c6N7yM Cc: core@ietf.org Subject: Re: [core] Considering how to use Token X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 14 Jul 2014 10:11:40 -0000 Hi, "weigengyu" writes: > I have a question about using token when considering implementation of > CoAP.=20 > My question is whether the Token is needed in=C2=A0 a message of Empty? > =C2=A0 > In RFC7252, Page 21,=20 > =E2=80=9CSeparate from the message type, a message may carry a request, a > response, or be Empty.=20 > This is signaled by the Request/Response Code field in the CoAP Header=20 > and is relevant to the request/response model.=20 > Possible values for the field are maintained in the CoAP Code > Registries (Section 12.1). > An Empty message has the Code field set to 0.00.=20 > The Token Length field MUST be set to 0 and bytes of data MUST NOT be > present after the Message ID field.=20 > If there are any bytes, they MUST be processed as a message format > error. =E2=80=9C > =C2=A0 > According to RFC7252, > the message of Empty is used to acknowlege the CON message by MID,=C2=A0 > and Token is meaningless. > Could the token be omitted in the message of Empty?=20 The text you are referring to clearly states that an Empty message contains no token. If there is data after the 4-byte header, the recipient will treat this as an error. Gruesse Olaf From nobody Mon Jul 14 06:25:26 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7A5C1A0426 for ; Mon, 14 Jul 2014 06:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.214 X-Spam-Level: X-Spam-Status: No, score=-0.214 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHLXXrfa2ml6 for ; Mon, 14 Jul 2014 06:25:22 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6961A042D for ; Mon, 14 Jul 2014 06:25:21 -0700 (PDT) Received: from WeiGengyuPC (unknown [222.131.13.74]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 80C1C19F383; Mon, 14 Jul 2014 21:25:19 +0800 (HKT) Message-ID: <2E1FB43AEC944A1A888A2B900274DE12@WeiGengyuPC> From: "weigengyu" To: "Olaf Bergmann" References: <2A1C1F2703194C0F968CD839505116C0@WeiGengyuPC> <87vbr0w8qg.fsf@tzi.org> In-Reply-To: <87vbr0w8qg.fsf@tzi.org> Date: Mon, 14 Jul 2014 21:25:12 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3522.110 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3522.110 Archived-At: http://mailarchive.ietf.org/arch/msg/core/DJPM2WCQw5IHmrzvy4WKp3ccFp4 Cc: core@ietf.org Subject: Re: [core] Considering how to use Token X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 14 Jul 2014 13:25:25 -0000 Hi Olaf, > The text you are referring to clearly states that an Empty message > contains no token. If there is data after the 4-byte header, the > recipient will treat this as an error. The RFC7252'text are " The Token Length field MUST be set to 0 ". As I understand that it means there is Token option but the token length field is ZERO. It does not means there is no Token option. If there is no Token option, there is no necessary to set the token length field. Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: Olaf Bergmann Sent: Monday, July 14, 2014 6:10 PM To: weigengyu Cc: core@ietf.org Subject: Re: [core] Considering how to use Token Hi, "weigengyu" writes: > I have a question about using token when considering implementation of > CoAP. > My question is whether the Token is needed in a message of Empty? > > In RFC7252, Page 21, > “Separate from the message type, a message may carry a request, a > response, or be Empty. > This is signaled by the Request/Response Code field in the CoAP Header > and is relevant to the request/response model. > Possible values for the field are maintained in the CoAP Code > Registries (Section 12.1). > An Empty message has the Code field set to 0.00. > The Token Length field MUST be set to 0 and bytes of data MUST NOT be > present after the Message ID field. > If there are any bytes, they MUST be processed as a message format > error. “ > > According to RFC7252, > the message of Empty is used to acknowlege the CON message by MID, > and Token is meaningless. > Could the token be omitted in the message of Empty? The text you are referring to clearly states that an Empty message contains no token. If there is data after the 4-byte header, the recipient will treat this as an error. Gruesse Olaf From nobody Mon Jul 14 06:43:28 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74B171A059F for ; Mon, 14 Jul 2014 06:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.348 X-Spam-Level: X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcoqkivTc2Qs for ; Mon, 14 Jul 2014 06:43:25 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21FA91A0552 for ; Mon, 14 Jul 2014 06:43: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.5/8.14.5) with ESMTP id s6EDhCGN027407; Mon, 14 Jul 2014 15:43:13 +0200 (CEST) Received: from aung.tzi.org (dynamic-218-6.informatik.uni-bremen.de [134.102.218.236]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B87B1356; Mon, 14 Jul 2014 15:43:12 +0200 (CEST) From: Olaf Bergmann To: "weigengyu" References: <2A1C1F2703194C0F968CD839505116C0@WeiGengyuPC> <87vbr0w8qg.fsf@tzi.org> <2E1FB43AEC944A1A888A2B900274DE12@WeiGengyuPC> Date: Mon, 14 Jul 2014 15:43:12 +0200 In-Reply-To: <2E1FB43AEC944A1A888A2B900274DE12@WeiGengyuPC> (weigengyu@bupt.edu.cn's message of "Mon, 14 Jul 2014 21:25:12 +0800") Message-ID: <87egxovyxb.fsf@tzi.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/core/SKd5FcC-VI2m9qP1txsCdNATR2g Cc: core@ietf.org Subject: Re: [core] Considering how to use Token X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 14 Jul 2014 13:43:26 -0000 "weigengyu" writes: > Hi Olaf, > >> The text you are referring to clearly states that an Empty message >> contains no token. If there is data after the 4-byte header, the >> recipient will treat this as an error. > > The RFC7252'text are " The Token Length field MUST be set to 0 ". > As I understand that it means there is Token option but the token > length field is ZERO. > It does not means there is no Token option. > If there is no Token option, there is no necessary to set the token > length field. There is no Token option at all in any message. In RFC 7252, a token is a sequence of 0--8 bytes. The header field TKL which is always present gives the actual length of the token included after the base header. As a consequence, you cannot distinguish between a token of length 0 and no token because both have TKL == 0 and nothing else. Gruesse Olaf From nobody Mon Jul 14 07:25:28 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F71A1A04B7 for ; Mon, 14 Jul 2014 07:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.575 X-Spam-Level: ** X-Spam-Status: No, score=2.575 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWh8iFzWa7rz for ; Mon, 14 Jul 2014 07:25:21 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9004B1A04A1 for ; Mon, 14 Jul 2014 07:25:20 -0700 (PDT) Received: from WeiGengyuPC (unknown [222.131.13.74]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 65CEE19F383; Mon, 14 Jul 2014 22:25:18 +0800 (HKT) Message-ID: <7F296DADC3094D9BBF3D1DB01200133B@WeiGengyuPC> From: "weigengyu" To: "Olaf Bergmann" References: <2A1C1F2703194C0F968CD839505116C0@WeiGengyuPC><87vbr0w8qg.fsf@tzi.org><2E1FB43AEC944A1A888A2B900274DE12@WeiGengyuPC> <87egxovyxb.fsf@tzi.org> In-Reply-To: <87egxovyxb.fsf@tzi.org> Date: Mon, 14 Jul 2014 22:25:10 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="gb2312"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3522.110 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3522.110 Archived-At: http://mailarchive.ietf.org/arch/msg/core/arkdjhOUE710Sp2GxTw51_499Wk Cc: core@ietf.org Subject: Re: [core] Considering how to use Token X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 14 Jul 2014 14:25:24 -0000 Hi, Olaf, The difference is clear. No Token option is there no any fields about token. Zero length token is a kind of token only the token length is set to Zero. When a token length is set to Zero, that means there is a token. An Empty message with a Zero length token works the same as No token option. Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----ԭʼÓʼþ----- From: Olaf Bergmann Sent: Monday, July 14, 2014 9:43 PM To: weigengyu Cc: core@ietf.org Subject: Re: [core] Considering how to use Token "weigengyu" writes: > Hi Olaf, > >> The text you are referring to clearly states that an Empty message >> contains no token. If there is data after the 4-byte header, the >> recipient will treat this as an error. > > The RFC7252'text are " The Token Length field MUST be set to 0 ". > As I understand that it means there is Token option but the token > length field is ZERO. > It does not means there is no Token option. > If there is no Token option, there is no necessary to set the token > length field. There is no Token option at all in any message. In RFC 7252, a token is a sequence of 0--8 bytes. The header field TKL which is always present gives the actual length of the token included after the base header. As a consequence, you cannot distinguish between a token of length 0 and no token because both have TKL == 0 and nothing else. Gruesse Olaf From nobody Mon Jul 14 09:13:43 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C741A0ACA for ; Mon, 14 Jul 2014 09:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQYwjBPLCgd0 for ; Mon, 14 Jul 2014 09:13:38 -0700 (PDT) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAFD11A0AB4 for ; Mon, 14 Jul 2014 09:13:37 -0700 (PDT) Received: by mail-pd0-f182.google.com with SMTP id fp1so2645084pdb.27 for ; Mon, 14 Jul 2014 09:13:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=MzV6mR7FOPQQzGr3JsmiAVEDHheKCp5tghmkPqhFeyw=; b=RXal8eJCiOSDeABay2mk1i08Yj2BFbiDBK9ER1UsSN1nvqz5O8J+K4J8AUpZrgQf4z nsGRBmc7PLtqWP7JpBlzpQzIfLuNLTAQH9FekPQCA9jiLtAX/ofxIBAzJCnJTkbY5TXu 5xsQv4TYjJn6Wusfw20yTbjT2Bj7TDlsyCed0kVJEGcDGHi9j0jXt2KH1OzkgoU87q4t kfYjbtqePY6m1dwmrjX4CCiwaJWhJisQRxHYLrLgbDil5h07Fw9RCrBlEKLnTPm8Jv89 TrDTphAkYqZzuHeq3fa48VsNjKKQMEHxOHcXPv/6tmJYkLZGDQ8OpGn7i5FxjIboB10W 9dkQ== X-Received: by 10.68.68.234 with SMTP id z10mr17198369pbt.59.1405354417501; Mon, 14 Jul 2014 09:13:37 -0700 (PDT) Received: from [192.168.0.102] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by mx.google.com with ESMTPSA id pl3sm2965357pbc.20.2014.07.14.09.13.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Jul 2014 09:13:36 -0700 (PDT) From: Michael Koster Content-Type: multipart/alternative; boundary="Apple-Mail=_407ED6B9-B52C-4EF6-93AC-A4432A5B40E4" Message-Id: <9FE7F579-1354-4AF5-8A12-34A6669893F1@gmail.com> Date: Mon, 14 Jul 2014 09:13:46 -0700 To: core@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/core/VNwg0eC9GW62SsDeWtvOm7MXMoI Subject: [core] CoRE RD update registration: replace links or update and add to existing links? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 14 Jul 2014 16:13:40 -0000 --Apple-Mail=_407ED6B9-B52C-4EF6-93AC-A4432A5B40E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 See the CoRE RD draft: http://tools.ietf.org/html/draft-ietf-core-resource-directory-01 Sec. 5.3: Parameters that have not changed SHOULD NOT be included in an update. I take this to mean that, if I include link-format data in the payload = of an RD update request, the links will be used to replace existing = links that match the part, and add new links to the existing = registration. IOW, I expect to be able to add and update links without = re-registering links that I=92m not updating. Does anyone have a different interpretation of this?=20 I would like to add text to the next update (overdue BTW) of the = document to make the update link behavior explicit as a point of = interoperability. Cheers, Michael --Apple-Mail=_407ED6B9-B52C-4EF6-93AC-A4432A5B40E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 See = the CoRE RD draft:= 

Sec. =
5.3:
Parameters that =
have not changed SHOULD NOT be included in an =
update.

I take this to mean that, if I = include link-format data in the payload of an RD update request, the = links will be used to replace existing links that match the <URL> = part, and add new links to the existing registration. IOW, I expect to = be able to add and update links without re-registering links that I=92m = not updating.

Does anyone have a = different interpretation of this? 

I would = like to add text to the next update (overdue BTW) of the document to = make the update link behavior explicit as a point of = interoperability.

Cheers,

Michael


= --Apple-Mail=_407ED6B9-B52C-4EF6-93AC-A4432A5B40E4-- From nobody Mon Jul 14 21:05:16 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC7C1B2807 for ; Mon, 14 Jul 2014 21:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3H6CvONIe3l for ; Mon, 14 Jul 2014 21:05:12 -0700 (PDT) Received: from service88.mimecast.com (service88.mimecast.com [195.130.217.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7D86E1A029F for ; Mon, 14 Jul 2014 21:05:12 -0700 (PDT) Received: from usa-sjc-gw2.usa.Arm.com (fw-tnat.snv.arm.com [217.140.100.22]) (Using TLS) by service88.mimecast.com; Tue, 15 Jul 2014 05:05:10 +0100 Received: from Spock.usa.Arm.com ([fe80::4116:859a:65b1:2f84]) by usa-sjc-gw2.usa.Arm.com ([::1]) with mapi; Mon, 14 Jul 2014 21:05:06 -0700 From: Zach Shelby To: Michael Koster Date: Mon, 14 Jul 2014 21:05:04 -0700 Thread-Topic: [core] CoRE RD update registration: replace links or update and add to existing links? Thread-Index: Ac+f4fXoBFSe5IKZQZ2Ugiu+ybATtQ== Message-ID: <727E4E32-E9D2-4B60-B678-B473406F338A@arm.com> References: <9FE7F579-1354-4AF5-8A12-34A6669893F1@gmail.com> In-Reply-To: <9FE7F579-1354-4AF5-8A12-34A6669893F1@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-MC-Unique: 114071505051000702 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/core/NaA26ISvMRJX02hNOvCFlBsSAew Cc: "core@ietf.org" Subject: Re: [core] CoRE RD update registration: replace links or update and add to existing links? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 15 Jul 2014 04:05:15 -0000 Hi, Actually, the update mechanism does not even include a payload, and thus li= nks can not be updated with this mechanism. Instead, if your links change, = you need to register again. The reason for this, is that registration updat= e processing needs to be very efficient considering they are performed much= more often than registration. Painfully aware I missed the update deadline for Toronto, and will submit w= hen that opens up on site. Zach On Jul 14, 2014, at 9:13 AM, Michael Koster w= rote: > See the CoRE RD draft: > http://tools.ietf.org/html/draft-ietf-core-resource-directory-01 > > Sec. 5.3: > Parameters that have not changed SHOULD NOT be included in an update. > > I take this to mean that, if I include link-format data in the payload of= an RD update request, the links will be used to replace existing links tha= t match the part, and add new links to the existing registration. IOW= , I expect to be able to add and update links without re-registering links = that I=92m not updating. > > Does anyone have a different interpretation of this? > > I would like to add text to the next update (overdue BTW) of the document= to make the update link behavior explicit as a point of interoperability. > > Cheers, > > Michael > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core Zach Shelby Director of Technical Marketing ARM Internet of Things BU www.arm.com mobile: +1 (408) 203-9434 Skype: zdshelby LinkedIn: fi.linkedin.com/in/zachshelby/ -- IMPORTANT NOTICE: The contents of this email and any attachments are con= fidential and may also be privileged. If you are not the intended recipient= , please notify the sender immediately and do not disclose the contents to = any other person, use it for any purpose, or store or copy the information = in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Regist= ered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, R= egistered in England & Wales, Company No: 2548782 From nobody Mon Jul 14 22:26:39 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D77A1A02F8 for ; Mon, 14 Jul 2014 22:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMl3kOt3nMnv for ; Mon, 14 Jul 2014 22:26:34 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90EE81A02E8 for ; Mon, 14 Jul 2014 22:26: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.5/8.14.5) with ESMTP id s6F5QUax006024; Tue, 15 Jul 2014 07:26:30 +0200 (CEST) Received: from [192.168.217.145] (p54891C02.dip0.t-ipconnect.de [84.137.28.2]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id DECA4593; Tue, 15 Jul 2014 07:26:29 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: <727E4E32-E9D2-4B60-B678-B473406F338A@arm.com> Date: Tue, 15 Jul 2014 07:26:28 +0200 X-Mao-Original-Outgoing-Id: 427094788.693721-29c83e4a49386661f73e1cfe7f8a3d84 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9FE7F579-1354-4AF5-8A12-34A6669893F1@gmail.com> <727E4E32-E9D2-4B60-B678-B473406F338A@arm.com> To: Zach Shelby X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/core/sLOypsoj7oWezW8tAsDD84_hh_s Cc: "core@ietf.org" Subject: Re: [core] CoRE RD update registration: replace links or update and add to existing links? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 15 Jul 2014 05:26:36 -0000 On 15 Jul 2014, at 06:05, Zach Shelby wrote: > the update mechanism does not even include a payload Maybe =93refresh=94 would be a less confusing name for this function. Gr=FC=DFe, Carsten From nobody Tue Jul 15 10:41:54 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1180B1A0AD5 for ; Tue, 15 Jul 2014 10:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIJN8iooxg6s for ; Tue, 15 Jul 2014 10:41:51 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9EA91A0AC0 for ; Tue, 15 Jul 2014 10:41:51 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id lf10so7331442pab.30 for ; Tue, 15 Jul 2014 10:41:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=esmG1g36ii3/GnKL+DAHAOBuXtGqISRfoHFseDRfX8o=; b=S7JuQ2ycnDHxizX3Wf6wS+tSUIyS3e5aHfPa5WhVgpQFPFN7BxaWdCKEHFdvHyKw5i ha9vVsclJSrkvMGEA488d3o6KFW9Gg25yP7/0iVYjmktZFdG7gUAF22M7VyGIRgVR2ZK Yuj1vp/kjfrSYunUFST3u4+Rfdx73tLMxUOzsSlH3p7fh6sU7eK/Dx+9HEk5FnvzI5I6 jdK8kunpyHq22tcZhkqq5KQgbwh1x6g3Z2eil3Ht9b6Y5prV8eM8o7vaCIFYjhjoZqpA 3X8XC4zDvnOdYILUjI+ZvhOPd0IMXLmM841Dg+zAhJp3qqRgVM7GNncKmLGaUSzBkOTI WwPg== X-Received: by 10.70.43.132 with SMTP id w4mr24432784pdl.42.1405446111559; Tue, 15 Jul 2014 10:41:51 -0700 (PDT) Received: from [10.0.0.11] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by mx.google.com with ESMTPSA id mj9sm60402104pab.20.2014.07.15.10.41.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jul 2014 10:41:50 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Koster In-Reply-To: Date: Tue, 15 Jul 2014 10:41:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9FE7F579-1354-4AF5-8A12-34A6669893F1@gmail.com> <727E4E32-E9D2-4B60-B678-B473406F338A@arm.com> To: Carsten Bormann , Zach Shelby X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/core/Tvc-87ecpoZoEvsJgZu0X18wLs4 Cc: "core@ietf.org" Subject: Re: [core] CoRE RD update registration: replace links or update and add to existing links? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 15 Jul 2014 17:41:53 -0000 The use case I have in mind is adding additional descriptive links to = existing resources after an endpoint registers, which would be based on = context and other late binding factors. Also it will be useful to = dynamically add objects and resources, which would require registering = more links to an EP. It=92s not as important to change existing links. Reg update could include a payload only when links are to be added, and = be empty when only refreshing, or a POST to the location might be = defined to add more links to an EP, but maybe registration update isn=92t = the best place to think about adding or updating links. For adding links to point to an EP, could we register another EP and set = the context to the already-registered EP? That way, there would be = separate management locations but the links would all point to the same = EP.=20 For changing links or relation values, it would be unregister and = re-register the EP with the new links.=20 Does this make sense? Thanks, Michael On Jul 14, 2014, at 10:26 PM, Carsten Bormann wrote: > On 15 Jul 2014, at 06:05, Zach Shelby wrote: >=20 >> the update mechanism does not even include a payload >=20 > Maybe =93refresh=94 would be a less confusing name for this function. >=20 > Gr=FC=DFe, Carsten >=20 From nobody Tue Jul 15 22:32:37 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4FE21B2A95 for ; Tue, 15 Jul 2014 22:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86VC1_K0UgmM for ; Tue, 15 Jul 2014 22:32:33 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 866081A0306 for ; Tue, 15 Jul 2014 22:32:33 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id u56so342725wes.14 for ; Tue, 15 Jul 2014 22:32:32 -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=/QbUxFvTSFHBHXvH8L/apaNPDrWyAZFCrel7h/Wjkz4=; b=ksxiw1Uia43L+69VQVJ//doFJ3R6PYXGnfzF3bGVgIv8aOIS2aUum3izGQNW7KuPEb cDYdPHTu9Ztn5/4k4TGaKLP2Sgj3Dn9BDFTncEyy0B6r8sZTsrbsn8gOpWiLX+UAXL24 VG5/K7SoFUaQxk0C4E6fUvOchSuaxkakRaiHdFol2nHEwSSDPEO9QkWjcw9aqBvNEaEG QkYKAcFECA4nWxqF6VSRlZUoXHS8QcNoH+C7zz0D7PGrRIn/VcjuFJmD9iYNbU6lfkQe sT5BaZfC1lJxQAPga0HznLPKWmV9YEk29ytrYA0eZa/QICUZblTORQIGz9pHMwP6qBm6 xPSg== MIME-Version: 1.0 X-Received: by 10.194.121.6 with SMTP id lg6mr17150949wjb.116.1405488752240; Tue, 15 Jul 2014 22:32:32 -0700 (PDT) Received: by 10.216.26.68 with HTTP; Tue, 15 Jul 2014 22:32:32 -0700 (PDT) Date: Wed, 16 Jul 2014 11:02:32 +0530 Message-ID: From: Indtiny S To: core@ietf.org Content-Type: multipart/alternative; boundary=089e01176b15d037c004fe48d9e3 Archived-At: http://mailarchive.ietf.org/arch/msg/core/55q3ktpbEDG1-0OAlRiZpi0BChA Subject: [core] date and time format in CoAP optional header X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 16 Jul 2014 05:32:35 -0000 --089e01176b15d037c004fe48d9e3 Content-Type: text/plain; charset=UTF-8 Hi, I have a requirment where I need to send a time of the data generated as part of header in CoAP optional field . But none of the current defined coap optional header supports a provision to fill the time .. Can some body suggest proper way to provide the time information ..? or is it possible to add a new header field ..? Due to some restrictions I can not add in the payload .. the features like observe also would need time during re-orderig .. Rgds Indra --089e01176b15d037c004fe48d9e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I have a requirment where I need to= send a time of the data generated as part of header in CoAP optional field= . But none of the current defined coap optional header supports a provisio= n to fill the time ..

Can some body suggest proper way to provide the time in= formation ..?=C2=A0

or is it possible to add a new= header field ..?

Due to some restrictions I can n= ot add in the payload ..=C2=A0

the features like observe also would need time during r= e-orderig ..


Rgds
Indra
--089e01176b15d037c004fe48d9e3-- From nobody Tue Jul 15 23:12:06 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4441B2AAD for ; Tue, 15 Jul 2014 23:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T_92jph_RK1O for ; Tue, 15 Jul 2014 23:11:43 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B1EB1B2AAF for ; Tue, 15 Jul 2014 23:11:42 -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.5/8.14.5) with ESMTP id s6G6BevE026882; Wed, 16 Jul 2014 08:11:40 +0200 (CEST) Received: from [192.168.217.145] (p54891A6B.dip0.t-ipconnect.de [84.137.26.107]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 79D9BC42; Wed, 16 Jul 2014 08:11:39 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: Date: Wed, 16 Jul 2014 08:11:37 +0200 X-Mao-Original-Outgoing-Id: 427183897.426295-7039b0deb35a66620b848ff36bacf671 Content-Transfer-Encoding: quoted-printable Message-Id: <2A2D8E3B-68F6-45A5-A8A2-F192D1E0E97D@tzi.org> References: To: Indtiny S X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/core/hprZfCnfC5fPFoPHBRCxJCvfVIc Cc: core@ietf.org Subject: Re: [core] date and time format in CoAP optional header X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 16 Jul 2014 06:11:49 -0000 On 16 Jul 2014, at 07:32, Indtiny S wrote: > Hi, >=20 > I have a requirment where I need to send a time of the data generated = as part of header in CoAP optional field . But none of the current = defined coap optional header supports a provision to fill the time .. What kind of time do you need? Absolute time? Monotonic vs. UTC? What resolution? What is the semantics that the time has? (E.g., time of measurement, expiry time, =85)? How does it relate to the request/response? > Can some body suggest proper way to provide the time information ..?=20= CBOR (RFC 7049) has a number of time formats you could use. > or is it possible to add a new header field ..? CoAP allows defining new options (what would be called header fields in = HTTP). See section 12.2. > Due to some restrictions I can not add in the payload ..=20 Please explain some more. This is the place where I would expect to = carry time information. You could use a container such as CBOR to package the time together with = some existing format. > the features like observe also would need time during re-orderig .. Observe has a specialized 24-bit =93timestamp=94 (in some virtual time). Is that what you need? Gr=FC=DFe, Carsten From nobody Wed Jul 16 03:31:36 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2961B2B21 for ; Wed, 16 Jul 2014 03:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oaLxUt6lmiRd for ; Wed, 16 Jul 2014 03:31:33 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 704BD1B2B1F for ; Wed, 16 Jul 2014 03:31:33 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id f8so5001239wiw.12 for ; Wed, 16 Jul 2014 03:31:32 -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=tg48063xswQBvZ7KjpTEfiJL8gLLT39Jr5/zKVEHQzw=; b=VMZQkvBc90YO+dFxXb7v6i/ef2kOBTteoSofYN3O7TIT/gwr467BRWRidWDGULsl9L uwTfTXw8VfjW9e5LLu+olRh6PBmGk+gWclJ7nErO2yCQEL0woOdSuOZIxu11GVv6SRjN vjKB4rzy01wZ00MjYNKna+s3jNWqXM9ULgcry5RUF/X75ZqJfw+fPfxFOQC5zU83hIee kHdCh5X1up+a1Jcml/VmepVX8M+1bwr50bkOuBg+PbvuvH840DWmdodI/5IDsW2yEeIs lCe6DCpP89nRgyypbqAmwTVdk3xAiJMxj51nY3xYC9jRRCN8tkhbd9E76rWilSdzy71J uU4Q== MIME-Version: 1.0 X-Received: by 10.180.13.230 with SMTP id k6mr12592035wic.1.1405506691910; Wed, 16 Jul 2014 03:31:31 -0700 (PDT) Received: by 10.216.26.68 with HTTP; Wed, 16 Jul 2014 03:31:31 -0700 (PDT) In-Reply-To: <2A2D8E3B-68F6-45A5-A8A2-F192D1E0E97D@tzi.org> References: <2A2D8E3B-68F6-45A5-A8A2-F192D1E0E97D@tzi.org> Date: Wed, 16 Jul 2014 16:01:31 +0530 Message-ID: From: Indtiny S To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a11c2291a19d38b04fe4d0731 Archived-At: http://mailarchive.ietf.org/arch/msg/core/wMgHnjpRcnqfpqazaMQl5E8g8ng Cc: core@ietf.org Subject: Re: [core] date and time format in CoAP optional header X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 16 Jul 2014 10:31:35 -0000 --001a11c2291a19d38b04fe4d0731 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > Hi, > > I have a requirment where I need to send a time of the data generated as part of header in CoAP optional field . But none of the current defined coap optional header supports a provision to fill the time .. What kind of time do you need? Absolute time? Monotonic vs. UTC? What resolution? I have to use UTC format What is the semantics that the time has? (E.g., time of measurement, expiry time, =E2=80=A6)? How does it relate to the request/response? its realted to the time of data generated ( like similar to httpdate and time ) > Can some body suggest proper way to provide the time information ..? CBOR (RFC 7049) has a number of time formats you could use. > or is it possible to add a new header field ..? CoAP allows defining new options (what would be called header fields in HTTP). See section 12.2. Currently I am adding my option field 256 .. > Due to some restrictions I can not add in the payload .. Please explain some more. This is the place where I would expect to carry time information. You could use a container such as CBOR to package the time together with some existing format. payload is in compeltly binary format , at the client side whenever it gets any data it checkw timestamp before converting from binary to standard format. > the features like observe also would need time during re-orderig .. Observe has a specialized 24-bit =E2=80=9Ctimestamp=E2=80=9D (in some virtu= al time). Is that what you need? This is used to provide sequence number rite ..? Rgds Indra --001a11c2291a19d38b04fe4d0731 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

> Hi,>
> I have a requirment where I need to send a time of the data g= enerated as part of header in CoAP optional field . But none of the current= defined coap optional header supports a provision to fill the time ..

What kind of time do you need?
Absolute time? =C2=A0Monotonic = vs. UTC?
What resolution?

I have to use UTC format

What is the semantics that the time has?
(E.g., time of measurement,= expiry time, =E2=80=A6)?

How does it r= elate to the request/response?

its realted to the time of data generated ( like si= milar to httpdate and time )

> Can some bo= dy suggest proper way to provide the time information ..?

CBOR= (RFC 7049) has a number of time formats you could use.

> or is it possible to add a new header field ..?
CoAP allows defining new options (what would be called header fi= elds in HTTP). =C2=A0See section 12.2.
Currently I am adding my option field 256 ..=C2=A0

> Due to some restrictions I can not add in the payl= oad ..

Please explain some more. =C2=A0This is the place where= I would expect to carry time information.
You could use a container suc= h as CBOR to package the time together with some existing format.
=C2=A0payload is in comp= eltly binary format , at the client side whenever it gets any data it check= w timestamp before converting from binary to standard format.


> the features like observe also would need time= during re-orderig ..

Observe has a specialized 24-bit =E2=80= =9Ctimestamp=E2=80=9D (in some virtual time).
Is that what you need?

This is used t= o provide sequence number rite ..?
<= br>
Rgds
In= dra

--001a11c2291a19d38b04fe4d0731-- From nobody Wed Jul 16 23:45:58 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA9B1A0645 for ; Wed, 16 Jul 2014 23:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.937 X-Spam-Level: ** X-Spam-Status: No, score=2.937 tagged_above=-999 required=5 tests=[BAYES_50=0.8, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRhBrUlrz1GH for ; Wed, 16 Jul 2014 23:45:54 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 59B9B1A07A1 for ; Wed, 16 Jul 2014 23:45:52 -0700 (PDT) Received: from WeiGengyuPC (unknown [221.218.42.41]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id EFEA519F374 for ; Thu, 17 Jul 2014 14:45:49 +0800 (HKT) Message-ID: <7AC1487E2E81455997C665D6FB739B09@WeiGengyuPC> From: "weigengyu" To: References: <2A1C1F2703194C0F968CD839505116C0@WeiGengyuPC><87vbr0w8qg.fsf@tzi.org><2E1FB43AEC944A1A888A2B900274DE12@WeiGengyuPC> <87egxovyxb.fsf@tzi.org> <7F296DADC3094D9BBF3D1DB01200133B@WeiGengyuPC> In-Reply-To: <7F296DADC3094D9BBF3D1DB01200133B@WeiGengyuPC> Date: Thu, 17 Jul 2014 14:45:38 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="gb2312"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3522.110 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3522.110 Archived-At: http://mailarchive.ietf.org/arch/msg/core/AsMinWBKyba-q4HphWVvEvA6bBA Subject: Re: [core] Considering how to use Token X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 17 Jul 2014 06:45:57 -0000 Hi, Thanks Olaf and Kepeng for your explainationgs. There is question of implemetation of CoAP Empty message and ZLT. Why the empty message must use Zero length token? In RFC7252 page 21, "An Empty message has the Code field set to 0.00. The Token Length field MUST be set to 0 and bytes of data MUST NOT be present after the Message ID field. As the Zero length token in the Empty message does not index any request and response, the client should keep the relation between MID and the REQUEST's Token as long as to send each message of REQUEST. when it receives an Empty message, the client can see which request the Empty Code belongs to only by the relation between MID and the REQUEST's Token instead of ZLT. Is it possbile to use the REQUEST's Token in the Empty message? If yes, the client can get directly from the received Empty message that which request will has a separate response by Token. And the client will not need to keep the relation between MID and the request's Token for every REQUESTs. Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----ԭʼÓʼþ----- From: weigengyu Sent: Monday, July 14, 2014 10:25 PM To: Olaf Bergmann Cc: core@ietf.org Subject: Re: [core] Considering how to use Token Hi, Olaf, The difference is clear. No Token option is there no any fields about token. Zero length token is a kind of token only the token length is set to Zero. When a token length is set to Zero, that means there is a token. An Empty message with a Zero length token works the same as No token option. Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----ԭʼÓʼþ----- From: Olaf Bergmann Sent: Monday, July 14, 2014 9:43 PM To: weigengyu Cc: core@ietf.org Subject: Re: [core] Considering how to use Token "weigengyu" writes: > Hi Olaf, > >> The text you are referring to clearly states that an Empty message >> contains no token. If there is data after the 4-byte header, the >> recipient will treat this as an error. > > The RFC7252'text are " The Token Length field MUST be set to 0 ". > As I understand that it means there is Token option but the token > length field is ZERO. > It does not means there is no Token option. > If there is no Token option, there is no necessary to set the token > length field. There is no Token option at all in any message. In RFC 7252, a token is a sequence of 0--8 bytes. The header field TKL which is always present gives the actual length of the token included after the base header. As a consequence, you cannot distinguish between a token of length 0 and no token because both have TKL == 0 and nothing else. Gruesse Olaf _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Thu Jul 17 00:16:03 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747C01A0A95 for ; Thu, 17 Jul 2014 00:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.063 X-Spam-Level: X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvD4xXC23zFj for ; Thu, 17 Jul 2014 00:16:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 804041A0A96 for ; Thu, 17 Jul 2014 00:15:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHG93294; Thu, 17 Jul 2014 07:15:55 +0000 (GMT) Received: from SZXEMA407-HUB.china.huawei.com (10.82.72.39) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 17 Jul 2014 08:15:51 +0100 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.128]) by SZXEMA407-HUB.china.huawei.com ([10.82.72.39]) with mapi id 14.03.0158.001; Thu, 17 Jul 2014 15:15:49 +0800 From: Likepeng To: weigengyu , "core@ietf.org" Thread-Topic: [core] Considering how to use Token Thread-Index: AQHPnwEcrtUc3bL8YkuEzmcvW4y7RZufWiox//+vzACAAItOdf//hXMAgAQ2mgCAAI2wcA== Date: Thu, 17 Jul 2014 07:15:48 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F258178D42@SZXEMA501-MBS.china.huawei.com> References: <2A1C1F2703194C0F968CD839505116C0@WeiGengyuPC><87vbr0w8qg.fsf@tzi.org><2E1FB43AEC944A1A888A2B900274DE12@WeiGengyuPC> <87egxovyxb.fsf@tzi.org> <7F296DADC3094D9BBF3D1DB01200133B@WeiGengyuPC> <7AC1487E2E81455997C665D6FB739B09@WeiGengyuPC> In-Reply-To: <7AC1487E2E81455997C665D6FB739B09@WeiGengyuPC> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.167.122] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/core/cslR_nG-dghYEuOJd14hWfSvnuE Subject: Re: [core] Considering how to use Token X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 17 Jul 2014 07:16:02 -0000 PiBJcyBpdCBwb3NzaWJsZSB0byB1c2UgdGhlIFJFUVVFU1QncyBUb2tlbiBpbiB0aGUgRW1wdHkg bWVzc2FnZT8NCg0KSW4gbXkgdW5kZXJzdGFuZGluZywgaWYgdGhlIHJlcXVlc3QgaGFzIHplcm8g bGVuZ3RoIHRva2VuLCB0aGUgcmVzcG9uc2Ugc2hvdWxkIGFsc28gaGF2ZSB6ZXJvIGxlbmd0aCB0 b2tlbi4NCg0KVGhleSBjYW4gYmUgbWF0Y2hlZC4NCg0KS2luZCBSZWdhcmRzDQpLZXBlbmcNCg0K PiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gt6K8/sjLOiBjb3JlIFttYWlsdG86Y29yZS1ib3VuY2Vz QGlldGYub3JnXSC0+rHtIHdlaWdlbmd5dQ0KPiC3osvNyrG85DogMjAxNMTqN9TCMTfI1SAxNDo0 Ng0KPiDK1bz+yMs6IGNvcmVAaWV0Zi5vcmcNCj4g1vfM4jogUmU6IFtjb3JlXSBDb25zaWRlcmlu ZyBob3cgdG8gdXNlIFRva2VuDQo+IA0KPiBIaSwNCj4gDQo+IFRoYW5rcyBPbGFmIGFuZCBLZXBl bmcgZm9yIHlvdXIgZXhwbGFpbmF0aW9uZ3MuDQo+IA0KPiBUaGVyZSBpcyBxdWVzdGlvbiBvZiBp bXBsZW1ldGF0aW9uIG9mIENvQVAgRW1wdHkgbWVzc2FnZSBhbmQgWkxULg0KPiBXaHkgdGhlIGVt cHR5IG1lc3NhZ2UgbXVzdCB1c2UgWmVybyBsZW5ndGggdG9rZW4/DQo+IA0KPiBJbiBSRkM3MjUy IHBhZ2UgMjEsDQo+ICJBbiBFbXB0eSBtZXNzYWdlIGhhcyB0aGUgQ29kZSBmaWVsZCBzZXQgdG8g MC4wMC4gVGhlIFRva2VuIExlbmd0aCBmaWVsZA0KPiBNVVNUIGJlIHNldCB0byAwIGFuZCBieXRl cyBvZiBkYXRhIE1VU1QgTk9UIGJlIHByZXNlbnQgYWZ0ZXIgdGhlIE1lc3NhZ2UNCj4gSUQgZmll bGQuDQo+IA0KPiBBcyB0aGUgWmVybyBsZW5ndGggdG9rZW4gaW4gdGhlIEVtcHR5IG1lc3NhZ2Ug ZG9lcyBub3QgaW5kZXggYW55IHJlcXVlc3QgYW5kDQo+IHJlc3BvbnNlLCB0aGUgY2xpZW50IHNo b3VsZCBrZWVwIHRoZSByZWxhdGlvbiBiZXR3ZWVuIE1JRCBhbmQgdGhlIFJFUVVFU1Qncw0KPiBU b2tlbiBhcyBsb25nIGFzIHRvIHNlbmQgZWFjaCBtZXNzYWdlIG9mIFJFUVVFU1QuDQo+IHdoZW4g aXQgcmVjZWl2ZXMgYW4gRW1wdHkgbWVzc2FnZSwgdGhlIGNsaWVudCBjYW4gc2VlIHdoaWNoIHJl cXVlc3QgdGhlDQo+IEVtcHR5IENvZGUgYmVsb25ncyB0byBvbmx5IGJ5IHRoZSByZWxhdGlvbiBi ZXR3ZWVuIE1JRCBhbmQgdGhlIFJFUVVFU1Qncw0KPiBUb2tlbiBpbnN0ZWFkIG9mIFpMVC4NCj4g DQo+IElzIGl0IHBvc3NiaWxlIHRvIHVzZSB0aGUgUkVRVUVTVCdzIFRva2VuIGluIHRoZSBFbXB0 eSBtZXNzYWdlPw0KPiBJZiB5ZXMsIHRoZSBjbGllbnQgY2FuIGdldCBkaXJlY3RseSBmcm9tIHRo ZSByZWNlaXZlZCBFbXB0eSBtZXNzYWdlIHRoYXQgd2hpY2gNCj4gcmVxdWVzdCB3aWxsIGhhcyBh IHNlcGFyYXRlIHJlc3BvbnNlIGJ5IFRva2VuLg0KPiBBbmQgdGhlIGNsaWVudCB3aWxsIG5vdCBu ZWVkIHRvIGtlZXAgdGhlIHJlbGF0aW9uIGJldHdlZW4gTUlEIGFuZCB0aGUNCj4gcmVxdWVzdCdz IFRva2VuIGZvciBldmVyeSBSRVFVRVNUcy4NCj4gDQo+IFJlZ2FyZHMsDQo+IA0KPiBHZW5neXUg V0VJDQo+IE5ldHdvcmsgVGVjaG5vbG9neSBDZW50ZXINCj4gU2Nob29sIG9mIENvbXB1dGVyDQo+ IEJlaWppbmcgVW5pdmVyc2l0eSBvZiBQb3N0cyBhbmQgVGVsZWNvbW11bmljYXRpb25zDQo+IC0t LS0t1K3KvNPKvP4tLS0tLQ0KPiBGcm9tOiB3ZWlnZW5neXUNCj4gU2VudDogTW9uZGF5LCBKdWx5 IDE0LCAyMDE0IDEwOjI1IFBNDQo+IFRvOiBPbGFmIEJlcmdtYW5uDQo+IENjOiBjb3JlQGlldGYu b3JnDQo+IFN1YmplY3Q6IFJlOiBbY29yZV0gQ29uc2lkZXJpbmcgaG93IHRvIHVzZSBUb2tlbg0K PiANCj4gSGksIE9sYWYsDQo+IA0KPiBUaGUgZGlmZmVyZW5jZSBpcyBjbGVhci4NCj4gDQo+IE5v IFRva2VuIG9wdGlvbiBpcyB0aGVyZSBubyBhbnkgZmllbGRzIGFib3V0IHRva2VuLg0KPiBaZXJv IGxlbmd0aCB0b2tlbiBpcyBhIGtpbmQgb2YgdG9rZW4gb25seSB0aGUgdG9rZW4gbGVuZ3RoIGlz IHNldCB0byBaZXJvLg0KPiBXaGVuIGEgdG9rZW4gbGVuZ3RoIGlzIHNldCB0byBaZXJvLCB0aGF0 IG1lYW5zIHRoZXJlIGlzIGEgdG9rZW4uDQo+IA0KPiBBbiBFbXB0eSBtZXNzYWdlIHdpdGggYSBa ZXJvIGxlbmd0aCB0b2tlbiB3b3JrcyB0aGUgc2FtZSBhcyBObyB0b2tlbg0KPiBvcHRpb24uDQo+ IA0KPiBSZWdhcmRzLA0KPiANCj4gR2VuZ3l1IFdFSQ0KPiBOZXR3b3JrIFRlY2hub2xvZ3kgQ2Vu dGVyDQo+IFNjaG9vbCBvZiBDb21wdXRlcg0KPiBCZWlqaW5nIFVuaXZlcnNpdHkgb2YgUG9zdHMg YW5kIFRlbGVjb21tdW5pY2F0aW9ucw0KPiAtLS0tLdStyrzTyrz+LS0tLS0NCj4gRnJvbTogT2xh ZiBCZXJnbWFubg0KPiBTZW50OiBNb25kYXksIEp1bHkgMTQsIDIwMTQgOTo0MyBQTQ0KPiBUbzog d2VpZ2VuZ3l1DQo+IENjOiBjb3JlQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbY29yZV0gQ29u c2lkZXJpbmcgaG93IHRvIHVzZSBUb2tlbg0KPiANCj4gIndlaWdlbmd5dSIgPHdlaWdlbmd5dUBi dXB0LmVkdS5jbj4gd3JpdGVzOg0KPiANCj4gPiBIaSBPbGFmLA0KPiA+DQo+ID4+IFRoZSB0ZXh0 IHlvdSBhcmUgcmVmZXJyaW5nIHRvIGNsZWFybHkgc3RhdGVzIHRoYXQgYW4gRW1wdHkgbWVzc2Fn ZQ0KPiA+PiBjb250YWlucyBubyB0b2tlbi4gSWYgdGhlcmUgaXMgZGF0YSBhZnRlciB0aGUgNC1i eXRlIGhlYWRlciwgdGhlDQo+ID4+IHJlY2lwaWVudCB3aWxsIHRyZWF0IHRoaXMgYXMgYW4gZXJy b3IuDQo+ID4NCj4gPiBUaGUgUkZDNzI1Mid0ZXh0IGFyZSAiIFRoZSBUb2tlbiBMZW5ndGggZmll bGQgTVVTVCBiZSBzZXQgdG8gMCAiLg0KPiA+IEFzIEkgdW5kZXJzdGFuZCB0aGF0IGl0IG1lYW5z IHRoZXJlIGlzIFRva2VuIG9wdGlvbiBidXQgdGhlIHRva2VuDQo+ID4gbGVuZ3RoIGZpZWxkIGlz IFpFUk8uDQo+ID4gSXQgZG9lcyBub3QgbWVhbnMgdGhlcmUgaXMgbm8gVG9rZW4gb3B0aW9uLg0K PiA+IElmIHRoZXJlIGlzIG5vIFRva2VuIG9wdGlvbiwgdGhlcmUgaXMgbm8gbmVjZXNzYXJ5IHRv IHNldCB0aGUgdG9rZW4NCj4gPiBsZW5ndGggZmllbGQuDQo+IA0KPiBUaGVyZSBpcyBubyBUb2tl biBvcHRpb24gYXQgYWxsIGluIGFueSBtZXNzYWdlLiBJbiBSRkMgNzI1MiwgYSB0b2tlbiBpcyBh DQo+IHNlcXVlbmNlIG9mIDAtLTggYnl0ZXMuIFRoZSBoZWFkZXIgZmllbGQgVEtMIHdoaWNoIGlz IGFsd2F5cyBwcmVzZW50IGdpdmVzIHRoZQ0KPiBhY3R1YWwgbGVuZ3RoIG9mIHRoZSB0b2tlbiBp bmNsdWRlZCBhZnRlciB0aGUgYmFzZSBoZWFkZXIuIEFzIGEgY29uc2VxdWVuY2UsDQo+IHlvdSBj YW5ub3QgZGlzdGluZ3Vpc2ggYmV0d2VlbiBhIHRva2VuIG9mIGxlbmd0aCAwIGFuZCBubyB0b2tl biBiZWNhdXNlIGJvdGgNCj4gaGF2ZSBUS0wgPT0gMCBhbmQgbm90aGluZyBlbHNlLg0KPiANCj4g R3J1ZXNzZQ0KPiBPbGFmDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBjb3JlIG1haWxpbmcgbGlzdA0KPiBjb3JlQGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KPiANCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gY29yZSBtYWlsaW5nIGxp c3QNCj4gY29yZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2NvcmUNCg== From nobody Thu Jul 17 01:49:03 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B06A1A0109 for ; Thu, 17 Jul 2014 01:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.676 X-Spam-Level: X-Spam-Status: No, score=0.676 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmKydVNyogjg for ; Thu, 17 Jul 2014 01:48:57 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 120581A010E for ; Thu, 17 Jul 2014 01:48:55 -0700 (PDT) Received: from WeiGengyuPC (unknown [221.218.42.41]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 03F8B19F372; Thu, 17 Jul 2014 16:48:53 +0800 (HKT) Message-ID: From: "weigengyu" To: "Likepeng" , References: <2A1C1F2703194C0F968CD839505116C0@WeiGengyuPC><87vbr0w8qg.fsf@tzi.org><2E1FB43AEC944A1A888A2B900274DE12@WeiGengyuPC> <87egxovyxb.fsf@tzi.org> <7F296DADC3094D9BBF3D1DB01200133B@WeiGengyuPC> <7AC1487E2E81455997C665D6FB739B09@WeiGengyuPC> <34966E97BE8AD64EAE9D3D6E4DEE36F258178D42@SZXEMA501-MBS.china.huawei.com> In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F258178D42@SZXEMA501-MBS.china.huawei.com> Date: Thu, 17 Jul 2014 16:47:22 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="gb2312"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3522.110 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3522.110 Archived-At: http://mailarchive.ietf.org/arch/msg/core/c60j7hs17wgqYwTH9GlJ3-Kq_E4 Subject: Re: [core] Considering how to use Token X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 17 Jul 2014 08:49:00 -0000 HI Kepeng, Yes. The client may send a message with a ZTL. But the Zero Length Token in REQUEST is different from the ZLT in an Empty message. The former is used to match a response with a request. The latter is meaningless. And most of the messages carring REQUEST should have tokens not to be ZLT. The Empty message as ACK will have a ZLT which is meaningless. Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----ԭʼÓʼþ----- From: Likepeng Sent: Thursday, July 17, 2014 3:15 PM To: weigengyu ; core@ietf.org Subject: Re: [core] Considering how to use Token > Is it possible to use the REQUEST's Token in the Empty message? In my understanding, if the request has zero length token, the response should also have zero length token. They can be matched. Kind Regards Kepeng > -----ÓʼþÔ­¼þ----- > ·¢¼þÈË: core [mailto:core-bounces@ietf.org] ´ú±í weigengyu > ·¢ËÍʱ¼ä: 2014Äê7ÔÂ17ÈÕ 14:46 > ÊÕ¼þÈË: core@ietf.org > Ö÷Ìâ: Re: [core] Considering how to use Token > > Hi, > > Thanks Olaf and Kepeng for your explainationgs. > > There is question of implemetation of CoAP Empty message and ZLT. > Why the empty message must use Zero length token? > > In RFC7252 page 21, > "An Empty message has the Code field set to 0.00. The Token Length field > MUST be set to 0 and bytes of data MUST NOT be present after the Message > ID field. > > As the Zero length token in the Empty message does not index any request > and > response, the client should keep the relation between MID and the > REQUEST's > Token as long as to send each message of REQUEST. > when it receives an Empty message, the client can see which request the > Empty Code belongs to only by the relation between MID and the REQUEST's > Token instead of ZLT. > > Is it possbile to use the REQUEST's Token in the Empty message? > If yes, the client can get directly from the received Empty message that > which > request will has a separate response by Token. > And the client will not need to keep the relation between MID and the > request's Token for every REQUESTs. > > Regards, > > Gengyu WEI > Network Technology Center > School of Computer > Beijing University of Posts and Telecommunications > -----ԭʼÓʼþ----- > From: weigengyu > Sent: Monday, July 14, 2014 10:25 PM > To: Olaf Bergmann > Cc: core@ietf.org > Subject: Re: [core] Considering how to use Token > > Hi, Olaf, > > The difference is clear. > > No Token option is there no any fields about token. > Zero length token is a kind of token only the token length is set to Zero. > When a token length is set to Zero, that means there is a token. > > An Empty message with a Zero length token works the same as No token > option. > > Regards, > > Gengyu WEI > Network Technology Center > School of Computer > Beijing University of Posts and Telecommunications > -----ԭʼÓʼþ----- > From: Olaf Bergmann > Sent: Monday, July 14, 2014 9:43 PM > To: weigengyu > Cc: core@ietf.org > Subject: Re: [core] Considering how to use Token > > "weigengyu" writes: > > > Hi Olaf, > > > >> The text you are referring to clearly states that an Empty message > >> contains no token. If there is data after the 4-byte header, the > >> recipient will treat this as an error. > > > > The RFC7252'text are " The Token Length field MUST be set to 0 ". > > As I understand that it means there is Token option but the token > > length field is ZERO. > > It does not means there is no Token option. > > If there is no Token option, there is no necessary to set the token > > length field. > > There is no Token option at all in any message. In RFC 7252, a token is a > sequence of 0--8 bytes. The header field TKL which is always present gives > the > actual length of the token included after the base header. As a > consequence, > you cannot distinguish between a token of length 0 and no token because > both > have TKL == 0 and nothing else. > > Gruesse > Olaf > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Thu Jul 17 02:02:08 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83B351A01D0 for ; Thu, 17 Jul 2014 02:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.063 X-Spam-Level: X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xg0jMUFa6ln0 for ; Thu, 17 Jul 2014 02:01:59 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CABD1A01A9 for ; Thu, 17 Jul 2014 02:01:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHH05258; Thu, 17 Jul 2014 09:01:56 +0000 (GMT) Received: from SZXEMA407-HUB.china.huawei.com (10.82.72.39) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 17 Jul 2014 10:01:07 +0100 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.128]) by SZXEMA407-HUB.china.huawei.com ([10.82.72.39]) with mapi id 14.03.0158.001; Thu, 17 Jul 2014 17:01:03 +0800 From: Likepeng To: weigengyu , "core@ietf.org" Thread-Topic: [core] Considering how to use Token Thread-Index: AQHPnwEcrtUc3bL8YkuEzmcvW4y7RZufWiox//+vzACAAItOdf//hXMAgAQ2mgCAAI2wcP//lFMAABEv1UA= Date: Thu, 17 Jul 2014 09:01:02 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F258178DBD@SZXEMA501-MBS.china.huawei.com> References: <2A1C1F2703194C0F968CD839505116C0@WeiGengyuPC><87vbr0w8qg.fsf@tzi.org><2E1FB43AEC944A1A888A2B900274DE12@WeiGengyuPC> <87egxovyxb.fsf@tzi.org> <7F296DADC3094D9BBF3D1DB01200133B@WeiGengyuPC> <7AC1487E2E81455997C665D6FB739B09@WeiGengyuPC> <34966E97BE8AD64EAE9D3D6E4DEE36F258178D42@SZXEMA501-MBS.china.huawei.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.66.167.122] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/core/4BcHuKkQCJ3kfWC7s4kbMa4KD0o Subject: Re: [core] Considering how to use Token X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 17 Jul 2014 09:02:05 -0000 PiBCdXQgdGhlIFplcm8gTGVuZ3RoIFRva2VuIGluIFJFUVVFU1QgaXMgZGlmZmVyZW50IGZyb20g dGhlIFpMVCBpbiBhbiBFbXB0eSBtZXNzYWdlLg0KDQpJbiBteSB1bmRlcnN0YW5kaW5nLCB0aGV5 IGFyZSB0aGUgc2FtZS4gVGhlcmUgaXMgbm8gZGlmZmVyZW5jZS4NCg0KQnV0IGxldKGvcyBoZWFy IG90aGVyJ3Mgb3Bpbmlvbi4NCg0KS2luZCBSZWdhcmRzDQpLZXBlbmcNCg0KPiAtLS0tLdPKvP7U rbz+LS0tLS0NCj4gt6K8/sjLOiB3ZWlnZW5neXUgW21haWx0bzp3ZWlnZW5neXVAYnVwdC5lZHUu Y25dDQo+ILeiy83KsbzkOiAyMDE0xOo31MIxN8jVIDE2OjQ3DQo+IMrVvP7IyzogTGlrZXBlbmc7 IGNvcmVAaWV0Zi5vcmcNCj4g1vfM4jogUmU6IFtjb3JlXSBDb25zaWRlcmluZyBob3cgdG8gdXNl IFRva2VuDQo+IA0KPiBISSBLZXBlbmcsDQo+IA0KPiBZZXMuDQo+IA0KPiBUaGUgY2xpZW50IG1h eSBzZW5kIGEgbWVzc2FnZSB3aXRoIGEgWlRMLg0KPiBCdXQgdGhlIFplcm8gTGVuZ3RoIFRva2Vu IGluIFJFUVVFU1QgaXMgZGlmZmVyZW50IGZyb20gdGhlIFpMVCBpbiBhbiBFbXB0eQ0KPiBtZXNz YWdlLg0KPiBUaGUgZm9ybWVyIGlzIHVzZWQgdG8gbWF0Y2ggYSByZXNwb25zZSB3aXRoIGEgcmVx dWVzdC4NCj4gVGhlIGxhdHRlciBpcyBtZWFuaW5nbGVzcy4NCj4gDQo+IEFuZCBtb3N0IG9mIHRo ZSBtZXNzYWdlcyBjYXJyaW5nIFJFUVVFU1Qgc2hvdWxkIGhhdmUgdG9rZW5zIG5vdCB0byBiZSBa TFQuDQo+IFRoZSBFbXB0eSBtZXNzYWdlIGFzIEFDSyB3aWxsIGhhdmUgYSBaTFQgd2hpY2ggaXMg bWVhbmluZ2xlc3MuDQo+IA0KPiBSZWdhcmRzLA0KPiANCj4gR2VuZ3l1IFdFSQ0KPiBOZXR3b3Jr IFRlY2hub2xvZ3kgQ2VudGVyDQo+IFNjaG9vbCBvZiBDb21wdXRlcg0KPiBCZWlqaW5nIFVuaXZl cnNpdHkgb2YgUG9zdHMgYW5kIFRlbGVjb21tdW5pY2F0aW9ucw0KPiAtLS0tLdStyrzTyrz+LS0t LS0NCj4gRnJvbTogTGlrZXBlbmcNCj4gU2VudDogVGh1cnNkYXksIEp1bHkgMTcsIDIwMTQgMzox NSBQTQ0KPiBUbzogd2VpZ2VuZ3l1IDsgY29yZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW2Nv cmVdIENvbnNpZGVyaW5nIGhvdyB0byB1c2UgVG9rZW4NCj4gDQo+ID4gSXMgaXQgcG9zc2libGUg dG8gdXNlIHRoZSBSRVFVRVNUJ3MgVG9rZW4gaW4gdGhlIEVtcHR5IG1lc3NhZ2U/DQo+IA0KPiBJ biBteSB1bmRlcnN0YW5kaW5nLCBpZiB0aGUgcmVxdWVzdCBoYXMgemVybyBsZW5ndGggdG9rZW4s IHRoZSByZXNwb25zZSBzaG91bGQNCj4gYWxzbyBoYXZlIHplcm8gbGVuZ3RoIHRva2VuLg0KPiAN Cj4gVGhleSBjYW4gYmUgbWF0Y2hlZC4NCj4gDQo+IEtpbmQgUmVnYXJkcw0KPiBLZXBlbmcNCj4g DQo+ID4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ID4gt6K8/sjLOiBjb3JlIFttYWlsdG86Y29yZS1i b3VuY2VzQGlldGYub3JnXSC0+rHtIHdlaWdlbmd5dQ0KPiA+ILeiy83KsbzkOiAyMDE0xOo31MIx N8jVIDE0OjQ2DQo+ID4gytW8/sjLOiBjb3JlQGlldGYub3JnDQo+ID4g1vfM4jogUmU6IFtjb3Jl XSBDb25zaWRlcmluZyBob3cgdG8gdXNlIFRva2VuDQo+ID4NCj4gPiBIaSwNCj4gPg0KPiA+IFRo YW5rcyBPbGFmIGFuZCBLZXBlbmcgZm9yIHlvdXIgZXhwbGFpbmF0aW9uZ3MuDQo+ID4NCj4gPiBU aGVyZSBpcyBxdWVzdGlvbiBvZiBpbXBsZW1ldGF0aW9uIG9mIENvQVAgRW1wdHkgbWVzc2FnZSBh bmQgWkxULg0KPiA+IFdoeSB0aGUgZW1wdHkgbWVzc2FnZSBtdXN0IHVzZSBaZXJvIGxlbmd0aCB0 b2tlbj8NCj4gPg0KPiA+IEluIFJGQzcyNTIgcGFnZSAyMSwNCj4gPiAiQW4gRW1wdHkgbWVzc2Fn ZSBoYXMgdGhlIENvZGUgZmllbGQgc2V0IHRvIDAuMDAuIFRoZSBUb2tlbiBMZW5ndGgNCj4gPiBm aWVsZCBNVVNUIGJlIHNldCB0byAwIGFuZCBieXRlcyBvZiBkYXRhIE1VU1QgTk9UIGJlIHByZXNl bnQgYWZ0ZXIgdGhlDQo+ID4gTWVzc2FnZSBJRCBmaWVsZC4NCj4gPg0KPiA+IEFzIHRoZSBaZXJv IGxlbmd0aCB0b2tlbiBpbiB0aGUgRW1wdHkgbWVzc2FnZSBkb2VzIG5vdCBpbmRleCBhbnkNCj4g PiByZXF1ZXN0IGFuZCByZXNwb25zZSwgdGhlIGNsaWVudCBzaG91bGQga2VlcCB0aGUgcmVsYXRp b24gYmV0d2VlbiBNSUQNCj4gPiBhbmQgdGhlIFJFUVVFU1QncyBUb2tlbiBhcyBsb25nIGFzIHRv IHNlbmQgZWFjaCBtZXNzYWdlIG9mIFJFUVVFU1QuDQo+ID4gd2hlbiBpdCByZWNlaXZlcyBhbiBF bXB0eSBtZXNzYWdlLCB0aGUgY2xpZW50IGNhbiBzZWUgd2hpY2ggcmVxdWVzdA0KPiA+IHRoZSBF bXB0eSBDb2RlIGJlbG9uZ3MgdG8gb25seSBieSB0aGUgcmVsYXRpb24gYmV0d2VlbiBNSUQgYW5k IHRoZQ0KPiA+IFJFUVVFU1QncyBUb2tlbiBpbnN0ZWFkIG9mIFpMVC4NCj4gPg0KPiA+IElzIGl0 IHBvc3NiaWxlIHRvIHVzZSB0aGUgUkVRVUVTVCdzIFRva2VuIGluIHRoZSBFbXB0eSBtZXNzYWdl Pw0KPiA+IElmIHllcywgdGhlIGNsaWVudCBjYW4gZ2V0IGRpcmVjdGx5IGZyb20gdGhlIHJlY2Vp dmVkIEVtcHR5IG1lc3NhZ2UNCj4gPiB0aGF0IHdoaWNoIHJlcXVlc3Qgd2lsbCBoYXMgYSBzZXBh cmF0ZSByZXNwb25zZSBieSBUb2tlbi4NCj4gPiBBbmQgdGhlIGNsaWVudCB3aWxsIG5vdCBuZWVk IHRvIGtlZXAgdGhlIHJlbGF0aW9uIGJldHdlZW4gTUlEIGFuZCB0aGUNCj4gPiByZXF1ZXN0J3Mg VG9rZW4gZm9yIGV2ZXJ5IFJFUVVFU1RzLg0KPiA+DQo+ID4gUmVnYXJkcywNCj4gPg0KPiA+IEdl bmd5dSBXRUkNCj4gPiBOZXR3b3JrIFRlY2hub2xvZ3kgQ2VudGVyDQo+ID4gU2Nob29sIG9mIENv bXB1dGVyDQo+ID4gQmVpamluZyBVbml2ZXJzaXR5IG9mIFBvc3RzIGFuZCBUZWxlY29tbXVuaWNh dGlvbnMNCj4gPiAtLS0tLdStyrzTyrz+LS0tLS0NCj4gPiBGcm9tOiB3ZWlnZW5neXUNCj4gPiBT ZW50OiBNb25kYXksIEp1bHkgMTQsIDIwMTQgMTA6MjUgUE0NCj4gPiBUbzogT2xhZiBCZXJnbWFu bg0KPiA+IENjOiBjb3JlQGlldGYub3JnDQo+ID4gU3ViamVjdDogUmU6IFtjb3JlXSBDb25zaWRl cmluZyBob3cgdG8gdXNlIFRva2VuDQo+ID4NCj4gPiBIaSwgT2xhZiwNCj4gPg0KPiA+IFRoZSBk aWZmZXJlbmNlIGlzIGNsZWFyLg0KPiA+DQo+ID4gTm8gVG9rZW4gb3B0aW9uIGlzIHRoZXJlIG5v IGFueSBmaWVsZHMgYWJvdXQgdG9rZW4uDQo+ID4gWmVybyBsZW5ndGggdG9rZW4gaXMgYSBraW5k IG9mIHRva2VuIG9ubHkgdGhlIHRva2VuIGxlbmd0aCBpcyBzZXQgdG8gWmVyby4NCj4gPiBXaGVu IGEgdG9rZW4gbGVuZ3RoIGlzIHNldCB0byBaZXJvLCB0aGF0IG1lYW5zIHRoZXJlIGlzIGEgdG9r ZW4uDQo+ID4NCj4gPiBBbiBFbXB0eSBtZXNzYWdlIHdpdGggYSBaZXJvIGxlbmd0aCB0b2tlbiB3 b3JrcyB0aGUgc2FtZSBhcyBObyB0b2tlbg0KPiA+IG9wdGlvbi4NCj4gPg0KPiA+IFJlZ2FyZHMs DQo+ID4NCj4gPiBHZW5neXUgV0VJDQo+ID4gTmV0d29yayBUZWNobm9sb2d5IENlbnRlcg0KPiA+ IFNjaG9vbCBvZiBDb21wdXRlcg0KPiA+IEJlaWppbmcgVW5pdmVyc2l0eSBvZiBQb3N0cyBhbmQg VGVsZWNvbW11bmljYXRpb25zDQo+ID4gLS0tLS3Urcq808q8/i0tLS0tDQo+ID4gRnJvbTogT2xh ZiBCZXJnbWFubg0KPiA+IFNlbnQ6IE1vbmRheSwgSnVseSAxNCwgMjAxNCA5OjQzIFBNDQo+ID4g VG86IHdlaWdlbmd5dQ0KPiA+IENjOiBjb3JlQGlldGYub3JnDQo+ID4gU3ViamVjdDogUmU6IFtj b3JlXSBDb25zaWRlcmluZyBob3cgdG8gdXNlIFRva2VuDQo+ID4NCj4gPiAid2VpZ2VuZ3l1IiA8 d2VpZ2VuZ3l1QGJ1cHQuZWR1LmNuPiB3cml0ZXM6DQo+ID4NCj4gPiA+IEhpIE9sYWYsDQo+ID4g Pg0KPiA+ID4+IFRoZSB0ZXh0IHlvdSBhcmUgcmVmZXJyaW5nIHRvIGNsZWFybHkgc3RhdGVzIHRo YXQgYW4gRW1wdHkgbWVzc2FnZQ0KPiA+ID4+IGNvbnRhaW5zIG5vIHRva2VuLiBJZiB0aGVyZSBp cyBkYXRhIGFmdGVyIHRoZSA0LWJ5dGUgaGVhZGVyLCB0aGUNCj4gPiA+PiByZWNpcGllbnQgd2ls bCB0cmVhdCB0aGlzIGFzIGFuIGVycm9yLg0KPiA+ID4NCj4gPiA+IFRoZSBSRkM3MjUyJ3RleHQg YXJlICIgVGhlIFRva2VuIExlbmd0aCBmaWVsZCBNVVNUIGJlIHNldCB0byAwICIuDQo+ID4gPiBB cyBJIHVuZGVyc3RhbmQgdGhhdCBpdCBtZWFucyB0aGVyZSBpcyBUb2tlbiBvcHRpb24gYnV0IHRo ZSB0b2tlbg0KPiA+ID4gbGVuZ3RoIGZpZWxkIGlzIFpFUk8uDQo+ID4gPiBJdCBkb2VzIG5vdCBt ZWFucyB0aGVyZSBpcyBubyBUb2tlbiBvcHRpb24uDQo+ID4gPiBJZiB0aGVyZSBpcyBubyBUb2tl biBvcHRpb24sIHRoZXJlIGlzIG5vIG5lY2Vzc2FyeSB0byBzZXQgdGhlIHRva2VuDQo+ID4gPiBs ZW5ndGggZmllbGQuDQo+ID4NCj4gPiBUaGVyZSBpcyBubyBUb2tlbiBvcHRpb24gYXQgYWxsIGlu IGFueSBtZXNzYWdlLiBJbiBSRkMgNzI1MiwgYSB0b2tlbg0KPiA+IGlzIGEgc2VxdWVuY2Ugb2Yg MC0tOCBieXRlcy4gVGhlIGhlYWRlciBmaWVsZCBUS0wgd2hpY2ggaXMgYWx3YXlzDQo+ID4gcHJl c2VudCBnaXZlcyB0aGUgYWN0dWFsIGxlbmd0aCBvZiB0aGUgdG9rZW4gaW5jbHVkZWQgYWZ0ZXIg dGhlIGJhc2UNCj4gPiBoZWFkZXIuIEFzIGEgY29uc2VxdWVuY2UsIHlvdSBjYW5ub3QgZGlzdGlu Z3Vpc2ggYmV0d2VlbiBhIHRva2VuIG9mDQo+ID4gbGVuZ3RoIDAgYW5kIG5vIHRva2VuIGJlY2F1 c2UgYm90aCBoYXZlIFRLTCA9PSAwIGFuZCBub3RoaW5nIGVsc2UuDQo+ID4NCj4gPiBHcnVlc3Nl DQo+ID4gT2xhZg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gPiBjb3JlIG1haWxpbmcgbGlzdA0KPiA+IGNvcmVAaWV0Zi5vcmcNCj4g PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCj4gPg0KPiA+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gY29yZSBt YWlsaW5nIGxpc3QNCj4gPiBjb3JlQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9jb3JlDQoNCg== From nobody Thu Jul 17 02:08:32 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22D91A0194 for ; Thu, 17 Jul 2014 02:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.276 X-Spam-Level: * X-Spam-Status: No, score=1.276 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, J_CHICKENPOX_75=0.6, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahCtoHZwsrDh for ; Thu, 17 Jul 2014 02:08:27 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id C48041A0160 for ; Thu, 17 Jul 2014 02:08:26 -0700 (PDT) Received: from WeiGengyuPC (unknown [221.218.42.41]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 7310C19F36F; Thu, 17 Jul 2014 17:08:25 +0800 (HKT) Message-ID: <7A0E91CA723B40C6ABCC8950BDC067B6@WeiGengyuPC> From: "weigengyu" To: "Likepeng" , References: <2A1C1F2703194C0F968CD839505116C0@WeiGengyuPC><87vbr0w8qg.fsf@tzi.org><2E1FB43AEC944A1A888A2B900274DE12@WeiGengyuPC> <87egxovyxb.fsf@tzi.org> <7F296DADC3094D9BBF3D1DB01200133B@WeiGengyuPC> <7AC1487E2E81455997C665D6FB739B09@WeiGengyuPC> <34966E97BE8AD64EAE9D3D6E4DEE36F258178D42@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F258178DBD@SZXEMA501-MBS.china.huawei.com> In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F258178DBD@SZXEMA501-MBS.china.huawei.com> Date: Thu, 17 Jul 2014 17:08:14 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="gb2312"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3522.110 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3522.110 Archived-At: http://mailarchive.ietf.org/arch/msg/core/mHsSFveIpKTTLF3qefxO85sdF6s Subject: Re: [core] Considering how to use Token X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 17 Jul 2014 09:08:30 -0000 OK! A client may choose to use a ZLT in a REQUEST. The responder is forced to use ZLT in an Empty message no matter what the REQUEST'token is. Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----ԭʼÓʼþ----- From: Likepeng Sent: Thursday, July 17, 2014 5:01 PM To: weigengyu ; core@ietf.org Subject: Re: [core] Considering how to use Token > But the Zero Length Token in REQUEST is different from the ZLT in an Empty > message. In my understanding, they are the same. There is no difference. But let¡¯s hear other's opinion. Kind Regards Kepeng > -----ÓʼþÔ­¼þ----- > ·¢¼þÈË: weigengyu [mailto:weigengyu@bupt.edu.cn] > ·¢ËÍʱ¼ä: 2014Äê7ÔÂ17ÈÕ 16:47 > ÊÕ¼þÈË: Likepeng; core@ietf.org > Ö÷Ìâ: Re: [core] Considering how to use Token > > HI Kepeng, > > Yes. > > The client may send a message with a ZTL. > But the Zero Length Token in REQUEST is different from the ZLT in an Empty > message. > The former is used to match a response with a request. > The latter is meaningless. > > And most of the messages carring REQUEST should have tokens not to be ZLT. > The Empty message as ACK will have a ZLT which is meaningless. > > Regards, > > Gengyu WEI > Network Technology Center > School of Computer > Beijing University of Posts and Telecommunications > -----ԭʼÓʼþ----- > From: Likepeng > Sent: Thursday, July 17, 2014 3:15 PM > To: weigengyu ; core@ietf.org > Subject: Re: [core] Considering how to use Token > > > Is it possible to use the REQUEST's Token in the Empty message? > > In my understanding, if the request has zero length token, the response > should > also have zero length token. > > They can be matched. > > Kind Regards > Kepeng > > > -----ÓʼþÔ­¼þ----- > > ·¢¼þÈË: core [mailto:core-bounces@ietf.org] ´ú±í weigengyu > > ·¢ËÍʱ¼ä: 2014Äê7ÔÂ17ÈÕ 14:46 > > ÊÕ¼þÈË: core@ietf.org > > Ö÷Ìâ: Re: [core] Considering how to use Token > > > > Hi, > > > > Thanks Olaf and Kepeng for your explainationgs. > > > > There is question of implemetation of CoAP Empty message and ZLT. > > Why the empty message must use Zero length token? > > > > In RFC7252 page 21, > > "An Empty message has the Code field set to 0.00. The Token Length > > field MUST be set to 0 and bytes of data MUST NOT be present after the > > Message ID field. > > > > As the Zero length token in the Empty message does not index any > > request and response, the client should keep the relation between MID > > and the REQUEST's Token as long as to send each message of REQUEST. > > when it receives an Empty message, the client can see which request > > the Empty Code belongs to only by the relation between MID and the > > REQUEST's Token instead of ZLT. > > > > Is it possbile to use the REQUEST's Token in the Empty message? > > If yes, the client can get directly from the received Empty message > > that which request will has a separate response by Token. > > And the client will not need to keep the relation between MID and the > > request's Token for every REQUESTs. > > > > Regards, > > > > Gengyu WEI > > Network Technology Center > > School of Computer > > Beijing University of Posts and Telecommunications > > -----ԭʼÓʼþ----- > > From: weigengyu > > Sent: Monday, July 14, 2014 10:25 PM > > To: Olaf Bergmann > > Cc: core@ietf.org > > Subject: Re: [core] Considering how to use Token > > > > Hi, Olaf, > > > > The difference is clear. > > > > No Token option is there no any fields about token. > > Zero length token is a kind of token only the token length is set to > > Zero. > > When a token length is set to Zero, that means there is a token. > > > > An Empty message with a Zero length token works the same as No token > > option. > > > > Regards, > > > > Gengyu WEI > > Network Technology Center > > School of Computer > > Beijing University of Posts and Telecommunications > > -----ԭʼÓʼþ----- > > From: Olaf Bergmann > > Sent: Monday, July 14, 2014 9:43 PM > > To: weigengyu > > Cc: core@ietf.org > > Subject: Re: [core] Considering how to use Token > > > > "weigengyu" writes: > > > > > Hi Olaf, > > > > > >> The text you are referring to clearly states that an Empty message > > >> contains no token. If there is data after the 4-byte header, the > > >> recipient will treat this as an error. > > > > > > The RFC7252'text are " The Token Length field MUST be set to 0 ". > > > As I understand that it means there is Token option but the token > > > length field is ZERO. > > > It does not means there is no Token option. > > > If there is no Token option, there is no necessary to set the token > > > length field. > > > > There is no Token option at all in any message. In RFC 7252, a token > > is a sequence of 0--8 bytes. The header field TKL which is always > > present gives the actual length of the token included after the base > > header. As a consequence, you cannot distinguish between a token of > > length 0 and no token because both have TKL == 0 and nothing else. > > > > Gruesse > > Olaf > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core From nobody Thu Jul 17 07:35:22 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E00A1ABB25 for ; Thu, 17 Jul 2014 07:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.187 X-Spam-Level: **** X-Spam-Status: No, score=4.187 tagged_above=-999 required=5 tests=[BAYES_50=0.8, CN_BODY_35=0.339, J_CHICKENPOX_75=0.6, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrp4xv5APcD4 for ; Thu, 17 Jul 2014 07:35:16 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 153B41A8BB1 for ; Thu, 17 Jul 2014 07:35:15 -0700 (PDT) Received: from WeiGengyuPC (unknown [221.218.42.41]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 971C419F3B9 for ; Thu, 17 Jul 2014 22:35:11 +0800 (HKT) Message-ID: <0F03FBF052ED46F0A4044657E82955E7@WeiGengyuPC> From: "weigengyu" To: References: <2A1C1F2703194C0F968CD839505116C0@WeiGengyuPC><87vbr0w8qg.fsf@tzi.org><2E1FB43AEC944A1A888A2B900274DE12@WeiGengyuPC> <87egxovyxb.fsf@tzi.org> <7F296DADC3094D9BBF3D1DB01200133B@WeiGengyuPC> <7AC1487E2E81455997C665D6FB739B09@WeiGengyuPC> <34966E97BE8AD64EAE9D3D6E4DEE36F258178D42@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F258178DBD@SZXEMA501-MBS.china.huawei.com> <7A0E91CA723B40C6ABCC8950BDC067B6@WeiGengyuPC> In-Reply-To: <7A0E91CA723B40C6ABCC8950BDC067B6@WeiGengyuPC> Date: Thu, 17 Jul 2014 22:34:59 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="gb2312"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: http://mailarchive.ietf.org/arch/msg/core/UpLsfDoRCIosSgNuVE_sD-WxIVM Subject: Re: [core] Considering how to use Token X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 17 Jul 2014 14:35:20 -0000 Hi all, I put another question of how to use token for block-wise transfer. The question is what is one REQUEST in block-wise transfer. When there is a large payload to transfer, does it belong to one request, or does it is partiioned into multiple request. Understanding what is one request is for using token adquate. 1. In the Abstract of draft-ietf-core-block-14, " Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options, for transferring multiple blocks of information from a resource representation in multiple request-response pairs. " The multiple request-response pairs imply that there are many requests for transfering the large data. 2. In page 10 of draft-ietf-core-block-14, "Using one or both Block options, a single REST operation can be split into multiple CoAP message exchanges. As specified in [I-D.ietf-core-coap], each of these message exchanges uses their own CoAP Message ID." this statement implys to transfer a large payload of single REST operation into many messages. It is one request including the large data. It is not clear in draft-ietf-core-block-14 that it is 1, or 2, or both for tranfering large data. By 1, each block is a request. Each message carrying the block should has an unique token. By 2, every block belongs to one request. Every message carrying the block should use the same token. There have been some discussions by which tokens could be different or the same. In the Abstract of draft-ietf-core-block-14, "the Block options provide a minimal way to transfer larger representations in a block-wise fashion." The Block option over-controls the block request and the block response by ignoring tokens. But it is unclear how to assign the token. Or always using the ZLT. Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----ԭʼÓʼþ----- From: weigengyu Sent: Thursday, July 17, 2014 5:08 PM To: Likepeng ; core@ietf.org Subject: Re: [core] Considering how to use Token OK! A client may choose to use a ZLT in a REQUEST. The responder is forced to use ZLT in an Empty message no matter what the REQUEST'token is. Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----ԭʼÓʼþ----- From: Likepeng Sent: Thursday, July 17, 2014 5:01 PM To: weigengyu ; core@ietf.org Subject: Re: [core] Considering how to use Token > But the Zero Length Token in REQUEST is different from the ZLT in an Empty > message. In my understanding, they are the same. There is no difference. But let¡¯s hear other's opinion. Kind Regards Kepeng > -----ÓʼþÔ­¼þ----- > ·¢¼þÈË: weigengyu [mailto:weigengyu@bupt.edu.cn] > ·¢ËÍʱ¼ä: 2014Äê7ÔÂ17ÈÕ 16:47 > ÊÕ¼þÈË: Likepeng; core@ietf.org > Ö÷Ìâ: Re: [core] Considering how to use Token > > HI Kepeng, > > Yes. > > The client may send a message with a ZTL. > But the Zero Length Token in REQUEST is different from the ZLT in an Empty > message. > The former is used to match a response with a request. > The latter is meaningless. > > And most of the messages carring REQUEST should have tokens not to be ZLT. > The Empty message as ACK will have a ZLT which is meaningless. > > Regards, > > Gengyu WEI > Network Technology Center > School of Computer > Beijing University of Posts and Telecommunications > -----ԭʼÓʼþ----- > From: Likepeng > Sent: Thursday, July 17, 2014 3:15 PM > To: weigengyu ; core@ietf.org > Subject: Re: [core] Considering how to use Token > > > Is it possible to use the REQUEST's Token in the Empty message? > > In my understanding, if the request has zero length token, the response > should > also have zero length token. > > They can be matched. > > Kind Regards > Kepeng > > > -----ÓʼþÔ­¼þ----- > > ·¢¼þÈË: core [mailto:core-bounces@ietf.org] ´ú±í weigengyu > > ·¢ËÍʱ¼ä: 2014Äê7ÔÂ17ÈÕ 14:46 > > ÊÕ¼þÈË: core@ietf.org > > Ö÷Ìâ: Re: [core] Considering how to use Token > > > > Hi, > > > > Thanks Olaf and Kepeng for your explainationgs. > > > > There is question of implemetation of CoAP Empty message and ZLT. > > Why the empty message must use Zero length token? > > > > In RFC7252 page 21, > > "An Empty message has the Code field set to 0.00. The Token Length > > field MUST be set to 0 and bytes of data MUST NOT be present after the > > Message ID field. > > > > As the Zero length token in the Empty message does not index any > > request and response, the client should keep the relation between MID > > and the REQUEST's Token as long as to send each message of REQUEST. > > when it receives an Empty message, the client can see which request > > the Empty Code belongs to only by the relation between MID and the > > REQUEST's Token instead of ZLT. > > > > Is it possbile to use the REQUEST's Token in the Empty message? > > If yes, the client can get directly from the received Empty message > > that which request will has a separate response by Token. > > And the client will not need to keep the relation between MID and the > > request's Token for every REQUESTs. > > > > Regards, > > > > Gengyu WEI > > Network Technology Center > > School of Computer > > Beijing University of Posts and Telecommunications > > -----ԭʼÓʼþ----- > > From: weigengyu > > Sent: Monday, July 14, 2014 10:25 PM > > To: Olaf Bergmann > > Cc: core@ietf.org > > Subject: Re: [core] Considering how to use Token > > > > Hi, Olaf, > > > > The difference is clear. > > > > No Token option is there no any fields about token. > > Zero length token is a kind of token only the token length is set to > > Zero. > > When a token length is set to Zero, that means there is a token. > > > > An Empty message with a Zero length token works the same as No token > > option. > > > > Regards, > > > > Gengyu WEI > > Network Technology Center > > School of Computer > > Beijing University of Posts and Telecommunications > > -----ԭʼÓʼþ----- > > From: Olaf Bergmann > > Sent: Monday, July 14, 2014 9:43 PM > > To: weigengyu > > Cc: core@ietf.org > > Subject: Re: [core] Considering how to use Token > > > > "weigengyu" writes: > > > > > Hi Olaf, > > > > > >> The text you are referring to clearly states that an Empty message > > >> contains no token. If there is data after the 4-byte header, the > > >> recipient will treat this as an error. > > > > > > The RFC7252'text are " The Token Length field MUST be set to 0 ". > > > As I understand that it means there is Token option but the token > > > length field is ZERO. > > > It does not means there is no Token option. > > > If there is no Token option, there is no necessary to set the token > > > length field. > > > > There is no Token option at all in any message. In RFC 7252, a token > > is a sequence of 0--8 bytes. The header field TKL which is always > > present gives the actual length of the token included after the base > > header. As a consequence, you cannot distinguish between a token of > > length 0 and no token because both have TKL == 0 and nothing else. > > > > Gruesse > > Olaf > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Thu Jul 17 18:15:07 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 162B61A0151 for ; Thu, 17 Jul 2014 18:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.587 X-Spam-Level: X-Spam-Status: No, score=0.587 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, CN_BODY_35=0.339, J_CHICKENPOX_75=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFlmH82KCyIz for ; Thu, 17 Jul 2014 18:15:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0949E1A033A for ; Thu, 17 Jul 2014 18:14:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHH69533; Fri, 18 Jul 2014 01:14:57 +0000 (GMT) Received: from SZXEMA406-HUB.china.huawei.com (10.82.72.38) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 18 Jul 2014 02:14:56 +0100 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.128]) by SZXEMA406-HUB.china.huawei.com ([10.82.72.38]) with mapi id 14.03.0158.001; Fri, 18 Jul 2014 09:14:51 +0800 From: Likepeng To: weigengyu , "core@ietf.org" Thread-Topic: [core] Considering how to use Token Thread-Index: AQHPnwEcrtUc3bL8YkuEzmcvW4y7RZufWiox//+vzACAAItOdf//hXMAgAQ2mgCAAI2wcP//lFMAABEv1UD//3xWAIAAW0uA//7NurA= Date: Fri, 18 Jul 2014 01:14:50 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F258179221@SZXEMA501-MBS.china.huawei.com> References: <2A1C1F2703194C0F968CD839505116C0@WeiGengyuPC><87vbr0w8qg.fsf@tzi.org><2E1FB43AEC944A1A888A2B900274DE12@WeiGengyuPC> <87egxovyxb.fsf@tzi.org> <7F296DADC3094D9BBF3D1DB01200133B@WeiGengyuPC> <7AC1487E2E81455997C665D6FB739B09@WeiGengyuPC> <34966E97BE8AD64EAE9D3D6E4DEE36F258178D42@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F258178DBD@SZXEMA501-MBS.china.huawei.com> <7A0E91CA723B40C6ABCC8950BDC067B6@WeiGengyuPC> <0F03FBF052ED46F0A4044657E82955E7@WeiGengyuPC> In-Reply-To: <0F03FBF052ED46F0A4044657E82955E7@WeiGengyuPC> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.167.122] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/core/qare_5gy5TTJgb1xwJB-TxoVbiQ Subject: Re: [core] Considering how to use Token X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 18 Jul 2014 01:15:03 -0000 Pkl0IGlzIG5vdCBjbGVhciBpbiBkcmFmdC1pZXRmLWNvcmUtYmxvY2stMTQgdGhhdCBpdCBpcyAx LCBvciAyLCBvciBib3RoIGZvciB0cmFuc2ZlcnJpbmcgbGFyZ2UgZGF0YS4NCj5CeSAxLCBlYWNo IGJsb2NrIGlzIGEgcmVxdWVzdC4gRWFjaCBtZXNzYWdlIGNhcnJ5aW5nIHRoZSBibG9jayBzaG91 bGQgaGFzIGFuIHVuaXF1ZSB0b2tlbi4NCg0KQ2Fyc3RlbiBleHBsYWluZWQgdGhhdCB0aGUgdG9r ZW4gY2FuIGJlIHRoZSBzYW1lIG9yIGRpZmZlcmVudC4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFp bC1hcmNoaXZlL3dlYi9jb3JlL2N1cnJlbnQvbXNnMDU0NDEuaHRtbA0KDQo+IEJ5IDIsIGV2ZXJ5 IGJsb2NrIGJlbG9uZ3MgdG8gb25lIHJlcXVlc3QuIEV2ZXJ5IG1lc3NhZ2UgY2FycnlpbmcgdGhl IGJsb2NrDQo+IHNob3VsZCB1c2UgdGhlIHNhbWUgdG9rZW4uDQoNClRoZSBzcGVjIHNheXMgImEg c2luZ2xlIFJFU1Qgb3BlcmF0aW9uIiwgaXQgZG9lcyBub3Qgc2F5IGl0IGlzICJvbmUgcmVxdWVz dCIuDQoNCktpbmQgUmVnYXJkcw0KS2VwZW5nDQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILei vP7IyzogY29yZSBbbWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SB3ZWlnZW5neXUN Cj4gt6LLzcqxvOQ6IDIwMTTE6jfUwjE3yNUgMjI6MzUNCj4gytW8/sjLOiBjb3JlQGlldGYub3Jn DQo+INb3zOI6IFJlOiBbY29yZV0gQ29uc2lkZXJpbmcgaG93IHRvIHVzZSBUb2tlbg0KPiANCj4g SGkgYWxsLA0KPiANCj4gSSBwdXQgYW5vdGhlciBxdWVzdGlvbiBvZiBob3cgdG8gdXNlIHRva2Vu IGZvciBibG9jay13aXNlIHRyYW5zZmVyLg0KPiANCj4gVGhlIHF1ZXN0aW9uIGlzIHdoYXQgaXMg b25lIFJFUVVFU1QgaW4gYmxvY2std2lzZSB0cmFuc2Zlci4NCj4gV2hlbiB0aGVyZSBpcyBhIGxh cmdlIHBheWxvYWQgdG8gdHJhbnNmZXIsIGRvZXMgaXQgYmVsb25nIHRvIG9uZSByZXF1ZXN0LCBv cg0KPiBkb2VzIGl0IGlzIHBhcnRpaW9uZWQgaW50byBtdWx0aXBsZSByZXF1ZXN0Lg0KPiBVbmRl cnN0YW5kaW5nIHdoYXQgaXMgb25lIHJlcXVlc3QgaXMgZm9yIHVzaW5nIHRva2VuIGFkcXVhdGUu DQo+IA0KPiAxLiBJbiB0aGUgQWJzdHJhY3Qgb2YgZHJhZnQtaWV0Zi1jb3JlLWJsb2NrLTE0LCAi IEluc3RlYWQgb2YgcmVseWluZyBvbiBJUA0KPiBmcmFnbWVudGF0aW9uLCB0aGlzIHNwZWNpZmlj YXRpb24gZXh0ZW5kcyBiYXNpYyBDb0FQIHdpdGggYSBwYWlyIG9mICJCbG9jayINCj4gb3B0aW9u cywgZm9yIHRyYW5zZmVycmluZyBtdWx0aXBsZSBibG9ja3Mgb2YgaW5mb3JtYXRpb24gZnJvbSBh IHJlc291cmNlDQo+IHJlcHJlc2VudGF0aW9uIGluIG11bHRpcGxlIHJlcXVlc3QtcmVzcG9uc2Ug cGFpcnMuICINCj4gDQo+IFRoZSBtdWx0aXBsZSByZXF1ZXN0LXJlc3BvbnNlIHBhaXJzIGltcGx5 IHRoYXQgdGhlcmUgYXJlIG1hbnkgcmVxdWVzdHMgZm9yDQo+IHRyYW5zZmVyaW5nIHRoZSBsYXJn ZSBkYXRhLg0KPiANCj4gMi4gSW4gcGFnZSAxMCBvZiBkcmFmdC1pZXRmLWNvcmUtYmxvY2stMTQs ICJVc2luZyBvbmUgb3IgYm90aCBCbG9jayBvcHRpb25zLCBhDQo+IHNpbmdsZSBSRVNUIG9wZXJh dGlvbiBjYW4gYmUgc3BsaXQgaW50byBtdWx0aXBsZSBDb0FQIG1lc3NhZ2UgZXhjaGFuZ2VzLg0K PiBBcyBzcGVjaWZpZWQgaW4gW0ktRC5pZXRmLWNvcmUtY29hcF0sIGVhY2ggb2YgdGhlc2UgbWVz c2FnZSBleGNoYW5nZXMgdXNlcw0KPiB0aGVpciBvd24gQ29BUCBNZXNzYWdlIElELiINCj4gDQo+ IHRoaXMgc3RhdGVtZW50IGltcGx5cyB0byB0cmFuc2ZlciBhIGxhcmdlIHBheWxvYWQgb2Ygc2lu Z2xlIFJFU1Qgb3BlcmF0aW9uIGludG8NCj4gbWFueSBtZXNzYWdlcy4NCj4gSXQgaXMgb25lIHJl cXVlc3QgaW5jbHVkaW5nIHRoZSBsYXJnZSBkYXRhLg0KPiANCj4gSXQgaXMgbm90IGNsZWFyIGlu IGRyYWZ0LWlldGYtY29yZS1ibG9jay0xNCB0aGF0IGl0IGlzIDEsIG9yIDIsIG9yIGJvdGggZm9y IHRyYW5mZXJpbmcNCj4gbGFyZ2UgZGF0YS4NCj4gQnkgMSwgZWFjaCBibG9jayBpcyBhIHJlcXVl c3QuIEVhY2ggbWVzc2FnZSBjYXJyeWluZyB0aGUgYmxvY2sgc2hvdWxkIGhhcyBhbg0KPiB1bmlx dWUgdG9rZW4uDQo+IEJ5IDIsIGV2ZXJ5IGJsb2NrIGJlbG9uZ3MgdG8gb25lIHJlcXVlc3QuIEV2 ZXJ5IG1lc3NhZ2UgY2FycnlpbmcgdGhlIGJsb2NrDQo+IHNob3VsZCB1c2UgdGhlIHNhbWUgdG9r ZW4uDQo+IA0KPiBUaGVyZSBoYXZlIGJlZW4gc29tZSBkaXNjdXNzaW9ucyBieSB3aGljaCB0b2tl bnMgY291bGQgYmUgZGlmZmVyZW50IG9yIHRoZQ0KPiBzYW1lLg0KPiBJbiB0aGUgQWJzdHJhY3Qg b2YgZHJhZnQtaWV0Zi1jb3JlLWJsb2NrLTE0LCAidGhlIEJsb2NrIG9wdGlvbnMgcHJvdmlkZSBh DQo+IG1pbmltYWwgd2F5IHRvIHRyYW5zZmVyIGxhcmdlciByZXByZXNlbnRhdGlvbnMgaW4gYSBi bG9jay13aXNlIGZhc2hpb24uIg0KPiBUaGUgQmxvY2sgb3B0aW9uIG92ZXItY29udHJvbHMgdGhl IGJsb2NrIHJlcXVlc3QgYW5kIHRoZSBibG9jayByZXNwb25zZSBieQ0KPiBpZ25vcmluZyAgdG9r ZW5zLg0KPiANCj4gQnV0IGl0IGlzIHVuY2xlYXIgaG93IHRvIGFzc2lnbiB0aGUgdG9rZW4uDQo+ IE9yIGFsd2F5cyB1c2luZyB0aGUgWkxULg0KPiANCj4gUmVnYXJkcywNCj4gDQo+IEdlbmd5dSBX RUkNCj4gTmV0d29yayBUZWNobm9sb2d5IENlbnRlcg0KPiBTY2hvb2wgb2YgQ29tcHV0ZXINCj4g QmVpamluZyBVbml2ZXJzaXR5IG9mIFBvc3RzIGFuZCBUZWxlY29tbXVuaWNhdGlvbnMNCj4gLS0t LS3Urcq808q8/i0tLS0tDQo+IEZyb206IHdlaWdlbmd5dQ0KPiBTZW50OiBUaHVyc2RheSwgSnVs eSAxNywgMjAxNCA1OjA4IFBNDQo+IFRvOiBMaWtlcGVuZyA7IGNvcmVAaWV0Zi5vcmcNCj4gU3Vi amVjdDogUmU6IFtjb3JlXSBDb25zaWRlcmluZyBob3cgdG8gdXNlIFRva2VuDQo+IA0KPiBPSyEN Cj4gDQo+IEEgY2xpZW50IG1heSBjaG9vc2UgdG8gdXNlIGEgWkxUIGluIGEgUkVRVUVTVC4NCj4g VGhlIHJlc3BvbmRlciBpcyBmb3JjZWQgdG8gdXNlIFpMVCBpbiBhbiBFbXB0eSBtZXNzYWdlIG5v IG1hdHRlciB3aGF0IHRoZQ0KPiBSRVFVRVNUJ3Rva2VuIGlzLg0KPiANCj4gUmVnYXJkcywNCj4g DQo+IEdlbmd5dSBXRUkNCj4gTmV0d29yayBUZWNobm9sb2d5IENlbnRlcg0KPiBTY2hvb2wgb2Yg Q29tcHV0ZXINCj4gQmVpamluZyBVbml2ZXJzaXR5IG9mIFBvc3RzIGFuZCBUZWxlY29tbXVuaWNh dGlvbnMNCj4gLS0tLS3Urcq808q8/i0tLS0tDQo+IEZyb206IExpa2VwZW5nDQo+IFNlbnQ6IFRo dXJzZGF5LCBKdWx5IDE3LCAyMDE0IDU6MDEgUE0NCj4gVG86IHdlaWdlbmd5dSA7IGNvcmVAaWV0 Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtjb3JlXSBDb25zaWRlcmluZyBob3cgdG8gdXNlIFRva2Vu DQo+IA0KPiA+IEJ1dCB0aGUgWmVybyBMZW5ndGggVG9rZW4gaW4gUkVRVUVTVCBpcyBkaWZmZXJl bnQgZnJvbSB0aGUgWkxUIGluIGFuDQo+ID4gRW1wdHkgbWVzc2FnZS4NCj4gDQo+IEluIG15IHVu ZGVyc3RhbmRpbmcsIHRoZXkgYXJlIHRoZSBzYW1lLiBUaGVyZSBpcyBubyBkaWZmZXJlbmNlLg0K PiANCj4gQnV0IGxldKGvcyBoZWFyIG90aGVyJ3Mgb3Bpbmlvbi4NCj4gDQo+IEtpbmQgUmVnYXJk cw0KPiBLZXBlbmcNCj4gDQo+ID4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ID4gt6K8/sjLOiB3ZWln ZW5neXUgW21haWx0bzp3ZWlnZW5neXVAYnVwdC5lZHUuY25dDQo+ID4gt6LLzcqxvOQ6IDIwMTTE 6jfUwjE3yNUgMTY6NDcNCj4gPiDK1bz+yMs6IExpa2VwZW5nOyBjb3JlQGlldGYub3JnDQo+ID4g 1vfM4jogUmU6IFtjb3JlXSBDb25zaWRlcmluZyBob3cgdG8gdXNlIFRva2VuDQo+ID4NCj4gPiBI SSBLZXBlbmcsDQo+ID4NCj4gPiBZZXMuDQo+ID4NCj4gPiBUaGUgY2xpZW50IG1heSBzZW5kIGEg bWVzc2FnZSB3aXRoIGEgWlRMLg0KPiA+IEJ1dCB0aGUgWmVybyBMZW5ndGggVG9rZW4gaW4gUkVR VUVTVCBpcyBkaWZmZXJlbnQgZnJvbSB0aGUgWkxUIGluIGFuDQo+ID4gRW1wdHkgbWVzc2FnZS4N Cj4gPiBUaGUgZm9ybWVyIGlzIHVzZWQgdG8gbWF0Y2ggYSByZXNwb25zZSB3aXRoIGEgcmVxdWVz dC4NCj4gPiBUaGUgbGF0dGVyIGlzIG1lYW5pbmdsZXNzLg0KPiA+DQo+ID4gQW5kIG1vc3Qgb2Yg dGhlIG1lc3NhZ2VzIGNhcnJpbmcgUkVRVUVTVCBzaG91bGQgaGF2ZSB0b2tlbnMgbm90IHRvIGJl DQo+IFpMVC4NCj4gPiBUaGUgRW1wdHkgbWVzc2FnZSBhcyBBQ0sgd2lsbCBoYXZlIGEgWkxUIHdo aWNoIGlzIG1lYW5pbmdsZXNzLg0KPiA+DQo+ID4gUmVnYXJkcywNCj4gPg0KPiA+IEdlbmd5dSBX RUkNCj4gPiBOZXR3b3JrIFRlY2hub2xvZ3kgQ2VudGVyDQo+ID4gU2Nob29sIG9mIENvbXB1dGVy DQo+ID4gQmVpamluZyBVbml2ZXJzaXR5IG9mIFBvc3RzIGFuZCBUZWxlY29tbXVuaWNhdGlvbnMN Cj4gPiAtLS0tLdStyrzTyrz+LS0tLS0NCj4gPiBGcm9tOiBMaWtlcGVuZw0KPiA+IFNlbnQ6IFRo dXJzZGF5LCBKdWx5IDE3LCAyMDE0IDM6MTUgUE0NCj4gPiBUbzogd2VpZ2VuZ3l1IDsgY29yZUBp ZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBbY29yZV0gQ29uc2lkZXJpbmcgaG93IHRvIHVzZSBU b2tlbg0KPiA+DQo+ID4gPiBJcyBpdCBwb3NzaWJsZSB0byB1c2UgdGhlIFJFUVVFU1QncyBUb2tl biBpbiB0aGUgRW1wdHkgbWVzc2FnZT8NCj4gPg0KPiA+IEluIG15IHVuZGVyc3RhbmRpbmcsIGlm IHRoZSByZXF1ZXN0IGhhcyB6ZXJvIGxlbmd0aCB0b2tlbiwgdGhlDQo+ID4gcmVzcG9uc2Ugc2hv dWxkIGFsc28gaGF2ZSB6ZXJvIGxlbmd0aCB0b2tlbi4NCj4gPg0KPiA+IFRoZXkgY2FuIGJlIG1h dGNoZWQuDQo+ID4NCj4gPiBLaW5kIFJlZ2FyZHMNCj4gPiBLZXBlbmcNCj4gPg0KPiA+ID4gLS0t LS3Tyrz+1K28/i0tLS0tDQo+ID4gPiC3orz+yMs6IGNvcmUgW21haWx0bzpjb3JlLWJvdW5jZXNA aWV0Zi5vcmddILT6se0gd2VpZ2VuZ3l1DQo+ID4gPiC3osvNyrG85DogMjAxNMTqN9TCMTfI1SAx NDo0Ng0KPiA+ID4gytW8/sjLOiBjb3JlQGlldGYub3JnDQo+ID4gPiDW98ziOiBSZTogW2NvcmVd IENvbnNpZGVyaW5nIGhvdyB0byB1c2UgVG9rZW4NCj4gPiA+DQo+ID4gPiBIaSwNCj4gPiA+DQo+ ID4gPiBUaGFua3MgT2xhZiBhbmQgS2VwZW5nIGZvciB5b3VyIGV4cGxhaW5hdGlvbmdzLg0KPiA+ ID4NCj4gPiA+IFRoZXJlIGlzIHF1ZXN0aW9uIG9mIGltcGxlbWV0YXRpb24gb2YgQ29BUCBFbXB0 eSBtZXNzYWdlIGFuZCBaTFQuDQo+ID4gPiBXaHkgdGhlIGVtcHR5IG1lc3NhZ2UgbXVzdCB1c2Ug WmVybyBsZW5ndGggdG9rZW4/DQo+ID4gPg0KPiA+ID4gSW4gUkZDNzI1MiBwYWdlIDIxLA0KPiA+ ID4gIkFuIEVtcHR5IG1lc3NhZ2UgaGFzIHRoZSBDb2RlIGZpZWxkIHNldCB0byAwLjAwLiBUaGUg VG9rZW4gTGVuZ3RoDQo+ID4gPiBmaWVsZCBNVVNUIGJlIHNldCB0byAwIGFuZCBieXRlcyBvZiBk YXRhIE1VU1QgTk9UIGJlIHByZXNlbnQgYWZ0ZXINCj4gPiA+IHRoZSBNZXNzYWdlIElEIGZpZWxk Lg0KPiA+ID4NCj4gPiA+IEFzIHRoZSBaZXJvIGxlbmd0aCB0b2tlbiBpbiB0aGUgRW1wdHkgbWVz c2FnZSBkb2VzIG5vdCBpbmRleCBhbnkNCj4gPiA+IHJlcXVlc3QgYW5kIHJlc3BvbnNlLCB0aGUg Y2xpZW50IHNob3VsZCBrZWVwIHRoZSByZWxhdGlvbiBiZXR3ZWVuDQo+ID4gPiBNSUQgYW5kIHRo ZSBSRVFVRVNUJ3MgVG9rZW4gYXMgbG9uZyBhcyB0byBzZW5kIGVhY2ggbWVzc2FnZSBvZg0KPiBS RVFVRVNULg0KPiA+ID4gd2hlbiBpdCByZWNlaXZlcyBhbiBFbXB0eSBtZXNzYWdlLCB0aGUgY2xp ZW50IGNhbiBzZWUgd2hpY2ggcmVxdWVzdA0KPiA+ID4gdGhlIEVtcHR5IENvZGUgYmVsb25ncyB0 byBvbmx5IGJ5IHRoZSByZWxhdGlvbiBiZXR3ZWVuIE1JRCBhbmQgdGhlDQo+ID4gPiBSRVFVRVNU J3MgVG9rZW4gaW5zdGVhZCBvZiBaTFQuDQo+ID4gPg0KPiA+ID4gSXMgaXQgcG9zc2JpbGUgdG8g dXNlIHRoZSBSRVFVRVNUJ3MgVG9rZW4gaW4gdGhlIEVtcHR5IG1lc3NhZ2U/DQo+ID4gPiBJZiB5 ZXMsIHRoZSBjbGllbnQgY2FuIGdldCBkaXJlY3RseSBmcm9tIHRoZSByZWNlaXZlZCBFbXB0eSBt ZXNzYWdlDQo+ID4gPiB0aGF0IHdoaWNoIHJlcXVlc3Qgd2lsbCBoYXMgYSBzZXBhcmF0ZSByZXNw b25zZSBieSBUb2tlbi4NCj4gPiA+IEFuZCB0aGUgY2xpZW50IHdpbGwgbm90IG5lZWQgdG8ga2Vl cCB0aGUgcmVsYXRpb24gYmV0d2VlbiBNSUQgYW5kDQo+ID4gPiB0aGUgcmVxdWVzdCdzIFRva2Vu IGZvciBldmVyeSBSRVFVRVNUcy4NCj4gPiA+DQo+ID4gPiBSZWdhcmRzLA0KPiA+ID4NCj4gPiA+ IEdlbmd5dSBXRUkNCj4gPiA+IE5ldHdvcmsgVGVjaG5vbG9neSBDZW50ZXINCj4gPiA+IFNjaG9v bCBvZiBDb21wdXRlcg0KPiA+ID4gQmVpamluZyBVbml2ZXJzaXR5IG9mIFBvc3RzIGFuZCBUZWxl Y29tbXVuaWNhdGlvbnMNCj4gPiA+IC0tLS0t1K3KvNPKvP4tLS0tLQ0KPiA+ID4gRnJvbTogd2Vp Z2VuZ3l1DQo+ID4gPiBTZW50OiBNb25kYXksIEp1bHkgMTQsIDIwMTQgMTA6MjUgUE0NCj4gPiA+ IFRvOiBPbGFmIEJlcmdtYW5uDQo+ID4gPiBDYzogY29yZUBpZXRmLm9yZw0KPiA+ID4gU3ViamVj dDogUmU6IFtjb3JlXSBDb25zaWRlcmluZyBob3cgdG8gdXNlIFRva2VuDQo+ID4gPg0KPiA+ID4g SGksIE9sYWYsDQo+ID4gPg0KPiA+ID4gVGhlIGRpZmZlcmVuY2UgaXMgY2xlYXIuDQo+ID4gPg0K PiA+ID4gTm8gVG9rZW4gb3B0aW9uIGlzIHRoZXJlIG5vIGFueSBmaWVsZHMgYWJvdXQgdG9rZW4u DQo+ID4gPiBaZXJvIGxlbmd0aCB0b2tlbiBpcyBhIGtpbmQgb2YgdG9rZW4gb25seSB0aGUgdG9r ZW4gbGVuZ3RoIGlzIHNldCB0bw0KPiA+ID4gWmVyby4NCj4gPiA+IFdoZW4gYSB0b2tlbiBsZW5n dGggaXMgc2V0IHRvIFplcm8sIHRoYXQgbWVhbnMgdGhlcmUgaXMgYSB0b2tlbi4NCj4gPiA+DQo+ ID4gPiBBbiBFbXB0eSBtZXNzYWdlIHdpdGggYSBaZXJvIGxlbmd0aCB0b2tlbiB3b3JrcyB0aGUg c2FtZSBhcyBObyB0b2tlbg0KPiA+ID4gb3B0aW9uLg0KPiA+ID4NCj4gPiA+IFJlZ2FyZHMsDQo+ ID4gPg0KPiA+ID4gR2VuZ3l1IFdFSQ0KPiA+ID4gTmV0d29yayBUZWNobm9sb2d5IENlbnRlcg0K PiA+ID4gU2Nob29sIG9mIENvbXB1dGVyDQo+ID4gPiBCZWlqaW5nIFVuaXZlcnNpdHkgb2YgUG9z dHMgYW5kIFRlbGVjb21tdW5pY2F0aW9ucw0KPiA+ID4gLS0tLS3Urcq808q8/i0tLS0tDQo+ID4g PiBGcm9tOiBPbGFmIEJlcmdtYW5uDQo+ID4gPiBTZW50OiBNb25kYXksIEp1bHkgMTQsIDIwMTQg OTo0MyBQTQ0KPiA+ID4gVG86IHdlaWdlbmd5dQ0KPiA+ID4gQ2M6IGNvcmVAaWV0Zi5vcmcNCj4g PiA+IFN1YmplY3Q6IFJlOiBbY29yZV0gQ29uc2lkZXJpbmcgaG93IHRvIHVzZSBUb2tlbg0KPiA+ ID4NCj4gPiA+ICJ3ZWlnZW5neXUiIDx3ZWlnZW5neXVAYnVwdC5lZHUuY24+IHdyaXRlczoNCj4g PiA+DQo+ID4gPiA+IEhpIE9sYWYsDQo+ID4gPiA+DQo+ID4gPiA+PiBUaGUgdGV4dCB5b3UgYXJl IHJlZmVycmluZyB0byBjbGVhcmx5IHN0YXRlcyB0aGF0IGFuIEVtcHR5DQo+ID4gPiA+PiBtZXNz YWdlIGNvbnRhaW5zIG5vIHRva2VuLiBJZiB0aGVyZSBpcyBkYXRhIGFmdGVyIHRoZSA0LWJ5dGUN Cj4gPiA+ID4+IGhlYWRlciwgdGhlIHJlY2lwaWVudCB3aWxsIHRyZWF0IHRoaXMgYXMgYW4gZXJy b3IuDQo+ID4gPiA+DQo+ID4gPiA+IFRoZSBSRkM3MjUyJ3RleHQgYXJlICIgVGhlIFRva2VuIExl bmd0aCBmaWVsZCBNVVNUIGJlIHNldCB0byAwICIuDQo+ID4gPiA+IEFzIEkgdW5kZXJzdGFuZCB0 aGF0IGl0IG1lYW5zIHRoZXJlIGlzIFRva2VuIG9wdGlvbiBidXQgdGhlIHRva2VuDQo+ID4gPiA+ IGxlbmd0aCBmaWVsZCBpcyBaRVJPLg0KPiA+ID4gPiBJdCBkb2VzIG5vdCBtZWFucyB0aGVyZSBp cyBubyBUb2tlbiBvcHRpb24uDQo+ID4gPiA+IElmIHRoZXJlIGlzIG5vIFRva2VuIG9wdGlvbiwg dGhlcmUgaXMgbm8gbmVjZXNzYXJ5IHRvIHNldCB0aGUNCj4gPiA+ID4gdG9rZW4gbGVuZ3RoIGZp ZWxkLg0KPiA+ID4NCj4gPiA+IFRoZXJlIGlzIG5vIFRva2VuIG9wdGlvbiBhdCBhbGwgaW4gYW55 IG1lc3NhZ2UuIEluIFJGQyA3MjUyLCBhIHRva2VuDQo+ID4gPiBpcyBhIHNlcXVlbmNlIG9mIDAt LTggYnl0ZXMuIFRoZSBoZWFkZXIgZmllbGQgVEtMIHdoaWNoIGlzIGFsd2F5cw0KPiA+ID4gcHJl c2VudCBnaXZlcyB0aGUgYWN0dWFsIGxlbmd0aCBvZiB0aGUgdG9rZW4gaW5jbHVkZWQgYWZ0ZXIg dGhlIGJhc2UNCj4gPiA+IGhlYWRlci4gQXMgYSBjb25zZXF1ZW5jZSwgeW91IGNhbm5vdCBkaXN0 aW5ndWlzaCBiZXR3ZWVuIGEgdG9rZW4gb2YNCj4gPiA+IGxlbmd0aCAwIGFuZCBubyB0b2tlbiBi ZWNhdXNlIGJvdGggaGF2ZSBUS0wgPT0gMCBhbmQgbm90aGluZyBlbHNlLg0KPiA+ID4NCj4gPiA+ IEdydWVzc2UNCj4gPiA+IE9sYWYNCj4gPiA+DQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gY29yZSBtYWlsaW5nIGxpc3QNCj4gPiA+ IGNvcmVAaWV0Zi5vcmcNCj4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vY29yZQ0KPiA+ID4NCj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+ID4gPiBjb3JlIG1haWxpbmcgbGlzdA0KPiA+ID4gY29yZUBpZXRmLm9y Zw0KPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQo+IA0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBjb3Jl IG1haWxpbmcgbGlzdA0KPiBjb3JlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vY29yZQ0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gY29yZSBtYWlsaW5nIGxpc3QNCj4gY29yZUBpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCg== From nobody Sat Jul 19 15:51:48 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 709A81B2A8A for ; Sat, 19 Jul 2014 15:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzKkmPMGSLft for ; Sat, 19 Jul 2014 15:51:44 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F7451B2A7D for ; Sat, 19 Jul 2014 15:51:44 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id kx10so7357038pab.20 for ; Sat, 19 Jul 2014 15:51:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=BWvJfi1T6XVG/XkfRHbZiogaV3oninnqiUrd27fn5Mc=; b=wO3ePCBA5+fRinuXR5MC4AY5m0ZzaqQW70GpdDjPxPkzEPGRzpiWpnpQBbuzM4uvoG l8EODARERZ9EV7j2Qsl5rZavfuLrzH5k3aBb/nmwSDIXY2lCQS696Fl5GAQcCMg1vbrd TH0OuMNS+tlm7FPHbbzvcku8RvkQUoYpKp4ws5w9VAfC4Ju1D8DHyfv9WpA74VE7wAgR QIvqlgxySUZgEsSoYB4pYEej6Q/HOn5tVe1C+gTpvxlB5NjlZsWqqylnJSf/77CxMx+c 4iv6PEC4ER/B7qlfve1ic2JMWjjtPrp2Cl2QgDimraxoJkjWqJwgQdWHeT4eVUKqPjly cEmg== X-Received: by 10.68.103.98 with SMTP id fv2mr14600740pbb.18.1405810303969; Sat, 19 Jul 2014 15:51:43 -0700 (PDT) Received: from [10.0.0.11] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by mx.google.com with ESMTPSA id or10sm8086399pdb.26.2014.07.19.15.51.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 19 Jul 2014 15:51:42 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_9003FD93-2BF4-48FC-9FC2-D82E570A27E9" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Koster In-Reply-To: <727E4E32-E9D2-4B60-B678-B473406F338A@arm.com> Date: Sat, 19 Jul 2014 15:51:31 -0700 Message-Id: <02F8D4B5-C243-4E74-97E7-65F013B3334B@gmail.com> References: <9FE7F579-1354-4AF5-8A12-34A6669893F1@gmail.com> <727E4E32-E9D2-4B60-B678-B473406F338A@arm.com> To: Zach Shelby X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/core/rYFbz1PKLXSZRZnDrwT3MMo5r_8 Cc: "core@ietf.org" Subject: Re: [core] CoRE RD update registration: replace links or update and add to existing links? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 19 Jul 2014 22:51:46 -0000 --Apple-Mail=_9003FD93-2BF4-48FC-9FC2-D82E570A27E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Zach, Thanks for the reply. I appreciate the need to make updates efficient, = but maybe some less frequent updates can carry payloads. The update description in the current RD draft doesn't say anything at = all about the payload, which may have left an opening for the definition = in LWM2M implying a payload of =93objects and object instances=94. I may = be misunderstanding the following table in the OMA LWM2M specification = section 5.2.2 (Update) which implies that objects and object instances = can be updated: Parameter Required Lifetime No Binding Mode No SMS Number No Objects and Object Instances No This plus the text=20 "This =93Update=94 operation MUST contain only the parameters listed in = Table 5 which have changed compared to the last registration parameters = sent to the LWM2M Server.=94 strongly implies that new objects and instances can be registered as = part of the update registration operation. This could be specific to = LWM2M implementations of RD, but I believe it may be a useful extension. ref: = http://openmobilealliance.hs-sites.com/lightweight-m2m-specification-from-= oma On Jul 14, 2014, at 9:05 PM, Zach Shelby wrote: > Hi, >=20 > Actually, the update mechanism does not even include a payload, and = thus links can not be updated with this mechanism. Instead, if your = links change, you need to register again. The reason for this, is that = registration update processing needs to be very efficient considering = they are performed much more often than registration. >=20 > Painfully aware I missed the update deadline for Toronto, and will = submit when that opens up on site. >=20 > Zach >=20 > On Jul 14, 2014, at 9:13 AM, Michael Koster = wrote: >=20 >> See the CoRE RD draft: >> http://tools.ietf.org/html/draft-ietf-core-resource-directory-01 >>=20 >> Sec. 5.3: >> Parameters that have not changed SHOULD NOT be included in an update. >>=20 >> I take this to mean that, if I include link-format data in the = payload of an RD update request, the links will be used to replace = existing links that match the part, and add new links to the = existing registration. IOW, I expect to be able to add and update links = without re-registering links that I=92m not updating. >>=20 >> Does anyone have a different interpretation of this? >>=20 >> I would like to add text to the next update (overdue BTW) of the = document to make the update link behavior explicit as a point of = interoperability. >>=20 >> Cheers, >>=20 >> Michael >>=20 >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 > Zach Shelby > Director of Technical Marketing > ARM Internet of Things BU > www.arm.com > mobile: +1 (408) 203-9434 > Skype: zdshelby > LinkedIn: fi.linkedin.com/in/zachshelby/ >=20 >=20 > -- IMPORTANT NOTICE: The contents of this email and any attachments = are confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you. >=20 > ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, = Registered in England & Wales, Company No: 2557590 > ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 = 9NJ, Registered in England & Wales, Company No: 2548782 >=20 --Apple-Mail=_9003FD93-2BF4-48FC-9FC2-D82E570A27E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Zach,

Thanks for the reply. I appreciate the need to = make updates efficient, but maybe some less frequent updates can carry = payloads.

The update description in the current = RD draft doesn't say anything at all about the payload, which may have = left an opening for the definition in LWM2M implying a payload of = =93objects and object instances=94. I may be misunderstanding the = following table in the OMA LWM2M specification section 5.2.2 (Update) = which implies that objects and object instances can be = updated:

Parameter

Required

Lifetime

No

Binding Mode

No

SMS Number

No

Objects and Object Instances

No

This plus the = text 

"This = =93Update=94 = operation MUST contain only the parameters listed in Table = 5 which have changed compared to the last registration parameters sent to the LWM2M = Server.=94

strongly implies that new objects  and = instances can be registered as part of the update registration = operation. This could be specific to LWM2M implementations of RD, but I = believe it may be a useful = extension.



On Jul 14, 2014, at 9:05 PM, = Zach Shelby <Zach.Shelby@arm.com> = wrote:

Hi,

Actually, the update mechanism does not even = include a payload, and thus links can not be updated with this = mechanism. Instead, if your links change, you need to register again. = The reason for this, is that registration update processing needs to be = very efficient considering they are performed much more often than = registration.

Painfully aware I missed the update deadline for = Toronto, and will submit when that opens up on = site.

Zach

On Jul 14, 2014, at 9:13 AM, Michael Koster = <michaeljohnkoster@gmail.com> wrote:

See the CoRE RD = draft:
= http://tools.ietf.org/html/draft-ietf-core-resource-directory-01
Sec. 5.3:
Parameters that have not changed SHOULD NOT be included = in an update.

I take this to mean that, if I include link-format = data in the payload of an RD update request, the links will be used to = replace existing links that match the <URL> part, and add new = links to the existing registration. IOW, I expect to be able to add and = update links without re-registering links that I=92m not = updating.

Does anyone have a different interpretation of = this?

I would like to add text to the next update (overdue BTW) = of the document to make the update link behavior explicit as a point of = interoperability.

Cheers,

Michael


_______________= ________________________________
core mailing list
core@ietf.org
https://www.ietf.org/ma= ilman/listinfo/core

Zach Shelby
Director of = Technical Marketing
ARM Internet of Things BU
www.arm.com
mobile: +1 (408) = 203-9434
Skype: zdshelby
LinkedIn: fi.linkedin.com/in/zachshel= by/


-- IMPORTANT NOTICE: The contents of this email and = any attachments are confidential and may also be privileged. If you are = not the intended recipient, please notify the sender immediately and do = not disclose the contents to any other person, use it for any purpose, = or store or copy the information in any medium.  Thank = you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge = CB1 9NJ, Registered in England & Wales, Company No: =  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, = Cambridge CB1 9NJ, Registered in England & Wales, Company No: =  2548782


= --Apple-Mail=_9003FD93-2BF4-48FC-9FC2-D82E570A27E9-- From nobody Sun Jul 20 09:11:01 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2A2C1B2C76 for ; Sun, 20 Jul 2014 09:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQ6R98d8Sl7A; Sun, 20 Jul 2014 09:10:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 614551B2C7A; Sun, 20 Jul 2014 09:10:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: core-chairs@tools.ietf.org, draft-ietf-core-observe@tools.ietf.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140720161047.17510.74091.idtracker@ietfa.amsl.com> Date: Sun, 20 Jul 2014 09:10:47 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/core/FOOWD3axzjiay4SMDMvq_PDKeFI Subject: [core] ID Tracker State Update Notice: X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 16:11:00 -0000 IESG state changed to AD Evaluation from Publication Requested ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-core-observe/ From nobody Sun Jul 20 09:15:16 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7C001B2C76 for ; Sun, 20 Jul 2014 09:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ci0JFdSD9Iti for ; Sun, 20 Jul 2014 09:15:12 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 552BD1ACAD6 for ; Sun, 20 Jul 2014 09:15:12 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id v6so3907784lbi.11 for ; Sun, 20 Jul 2014 09:15:10 -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:message-id:subject :from:to:content-type; bh=uLKHzHCBzfPUOc14RhU23t/wilrFsusPoLTJZ+JNgd8=; b=uyRgY3ILap89MCFDpeOmP8nXBpcrJrh8vgHyK7yO3J9FCsKcLDMahAHkDLtUpzMqwC 92TA7rAn0qXDYsJiLXhD+L6bQT9t4+KX/3ekE45Z1m9GRBKPB6YvaJ1y0tf3qiuC6oXF MRLA9fR+PY8+dC6L5k+bmA7qvx1o2eTfW2rqnGKQsWJ122y/njdu28chwICQpZNeubGl q3xhasPDqQn8H37m2hQo+1F+0p6ScvW1EaPrhQJQeEDKPf3TufC7vdid/SNc1Ehld9Fd hdBsVEsbVV6VrKoWBWbAP+ySM2nutq9tXDFYf8Mihvubo++XIfEKp5G3kim4Lcx0tZHT /Dbw== MIME-Version: 1.0 X-Received: by 10.152.43.17 with SMTP id s17mr4201134lal.81.1405872909441; Sun, 20 Jul 2014 09:15:09 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.123.10 with HTTP; Sun, 20 Jul 2014 09:15:09 -0700 (PDT) In-Reply-To: <20140720155016.32120.85490.idtracker@ietfa.amsl.com> References: <20140720155016.32120.85490.idtracker@ietfa.amsl.com> Date: Sun, 20 Jul 2014 12:15:09 -0400 X-Google-Sender-Auth: wVNmq_dx0eT_UJuwJv6Ofp52a-I Message-ID: From: Barry Leiba To: core WG Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/core/mNIOkMz5llybK187AL20NOcEFWo Subject: Re: [core] Publication has been requested for draft-ietf-core-observe-14 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 20 Jul 2014 16:15:14 -0000 > Carsten Bormann has requested publication of > draft-ietf-core-observe-14 as Proposed Standard on behalf of > the CORE working group. > > Please verify the document's state at > http://datatracker.ietf.org/doc/draft-ietf-core-observe/ I've received the publication request and changed the document state to AD Evaluation. I can't promise to get to that during IETF week, but I'll plan on doing it next week. Barry, responsible AD From nobody Sun Jul 20 16:08:59 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6CD11B2A3B for ; Sun, 20 Jul 2014 16:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Je3k3d4bXiBV for ; Sun, 20 Jul 2014 16:08:56 -0700 (PDT) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC7841B27AB for ; Sun, 20 Jul 2014 16:08:55 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id w7so5121326qcr.34 for ; Sun, 20 Jul 2014 16:08:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=4e9xNSCLQKQu0GHlQrbg/RBsx/Mv4prOUPEk90P0Ld0=; b=Hc6+lDmvfS0TrS9PWhwPvDvojZkdfJhtqh0S5Q/YBMWu8GYktPFoLLCzAGBcZ/NqFu XxD9QTjeyiUGRd8BiD7NJ8jLpzQHG1JB4WVKZGyGPF+jG9q3+ARH6F4IWIdDsx7EK610 vS3pzdXmGeRVAe9b/ip66LPLh1fodIUmSEZ2TIDyvgja49TkbwSEfB6x7mPNGCAlj9Sa FYAFV81eX4GAUI2vy272raI8rXo5CyDUvcofeMwUUh52Kv2VHZeZxo8RfAvVUekDvPcQ KMJQF+yEMpjQKQLlOw836w4Hay4h9KG021SpZ8I1rGIOqmt5E4DVknigC80bRIE5ucV+ Z0Wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=4e9xNSCLQKQu0GHlQrbg/RBsx/Mv4prOUPEk90P0Ld0=; b=k70YBT5eI2CpD8P/23POvO/A4P2vnk/WTnBTpvh5fWxF/D1ny0T3IRwG8VDSzC/3jD eZwZUGmU3eRgAePGVS96SCgLV3d+bVsk2zwUqRt065hMFwIG0JLCa55KJgvxh/aXJv1O SSFSWmkZDrdjq4u7oIfuZg1UiaVDRdsbKa857iQxa0jszyiKkmwkPrwu1N3nn41Gs06/ v5ufO8sXSfoxEsWYETI4Jm1RuZxA5IRqCwgCMj7bSwzCiLXqKobNKnkc6i99FbUEyCc8 sj7rtal5uxaUMyWYMyDAONC9rhmnlbj4MeqHvxHdZ8tv7XLvOVDQrauwU10xk2uM6pfd cudg== X-Gm-Message-State: ALoCoQnjILSZUD7BN/wdz0OdjAM6LqV0CjmxXlMA3xaa60dxXUWJmcLbuXjBQWUPZ2vFEGTRGq2M MIME-Version: 1.0 X-Received: by 10.224.69.202 with SMTP id a10mr35709495qaj.100.1405897735049; Sun, 20 Jul 2014 16:08:55 -0700 (PDT) Received: by 10.224.201.2 with HTTP; Sun, 20 Jul 2014 16:08:54 -0700 (PDT) Date: Sun, 20 Jul 2014 16:08:54 -0700 Message-ID: From: Andrew Mcgregor To: Core , "core-chairs@tools.ietf.org" , Barry Leiba Content-Type: multipart/alternative; boundary=001a11c2e8f016c70604fea813a4 Archived-At: http://mailarchive.ietf.org/arch/msg/core/sJOF6kG4jT3-bGa5-u3BX6K99vg Subject: [core] Completed: WGLC for draft-ietf-core-block-15 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 20 Jul 2014 23:08:56 -0000 --001a11c2e8f016c70604fea813a4 Content-Type: text/plain; charset=UTF-8 This last call is now complete. The draft will be on the agenda for our meeting slot on Wednesday, final comments can be received then. We expect a -16 version to be available on Tuesday, incorporating all the updates from last call. -- Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 1071 2221 --001a11c2e8f016c70604fea813a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This last call is now complete. =C2=A0The draft will be on= the agenda for our meeting slot on Wednesday, final comments can be receiv= ed then. =C2=A0We expect a -16 version to be available on Tuesday, incorpor= ating all the updates from last call.

--
Andrew McGregor=C2=A0|=C2=A0SRE=C2=A0|=C2=A0andrew= mcgr@google.com=C2=A0|=C2=A0+61 4 1071 2221
--001a11c2e8f016c70604fea813a4-- From nobody Sun Jul 20 21:21:46 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6534C1B2D4F; Sun, 20 Jul 2014 21:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id an0jr4GfVqPC; Sun, 20 Jul 2014 21:21:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F2B1B2D53; Sun, 20 Jul 2014 21:21:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140721042143.15228.25006.idtracker@ietfa.amsl.com> Date: Sun, 20 Jul 2014 21:21:43 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/core/OOCE5VQA2_LbYzxJvWsIMa8acoE Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-groupcomm-20.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 04:21:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments Working Group of the IETF. Title : Group Communication for CoAP Authors : Akbar Rahman Esko Dijk Filename : draft-ietf-core-groupcomm-20.txt Pages : 50 Date : 2014-07-20 Abstract: CoAP is a specialized web transfer protocol for constrained devices and constrained networks. It is anticipated that constrained devices will often naturally operate in groups (e.g., in a building automation scenario all lights in a given room may need to be switched on/off as a group). This document provides guidance for how the CoAP protocol should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed. Also, various use cases and corresponding protocol flows are provided to illustrate important concepts. Finally, guidance is provided for deployment in various network topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-groupcomm-20 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-core-groupcomm-20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 20 21:25:47 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82A061B2CDA for ; Sun, 20 Jul 2014 21:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8P0-_g_jJiDO for ; Sun, 20 Jul 2014 21:25:43 -0700 (PDT) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DB3E1B2A49 for ; Sun, 20 Jul 2014 21:25:43 -0700 (PDT) X-ASG-Debug-ID: 1405916738-06daaa5088288930001-aa7cYp Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id VpGjJsxAyFqKD1L6 for ; Mon, 21 Jul 2014 00:25:38 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 Jul 2014 00:25:37 -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: Mon, 21 Jul 2014 00:25:35 -0400 X-ASG-Orig-Subj: RE: [core] I-D Action: draft-ietf-core-groupcomm-20.txt Message-ID: In-Reply-To: <20140721042143.15228.25006.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] I-D Action: draft-ietf-core-groupcomm-20.txt Thread-Index: Ac+km0qhuAiWgScqTIi606FjYi/jcQAAAzAw References: <20140721042143.15228.25006.idtracker@ietfa.amsl.com> From: "Rahman, Akbar" To: X-OriginalArrivalTime: 21 Jul 2014 04:25:37.0653 (UTC) FILETIME=[D28F5A50:01CFA49B] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1405916738 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.7666 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: http://mailarchive.ietf.org/arch/msg/core/4D3ZtHTKi3h4ny3mVPnW-3izACA Subject: Re: [core] I-D Action: draft-ietf-core-groupcomm-20.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 21 Jul 2014 04:25:45 -0000 Hi All, We submitted a new version of the groupcomm draft to correct/clarify some of the references as per the off-line review of Carsten. Specifically: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Changes from ietf-19 to ietf-20: o Replaced obsolete reference [RFC 2616] by [RFC 7230]. o Replaced outdated reference draft-ietf-appsawg-uri-get-off-my-lawn by [RFC 7320] and moved to Normative reference. o Replaced outdated reference draft-ietf-core-coap by [RFC 7252]. o Moved [RFC 1033] to Informative reference. o Updated to latest revision numbers for informative draft references by regenerating file through xml2rfc tool. o Re-ran IETF spell check tool and corrected some minor spelling errors. o Various minor editorial updates. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Best Regards, Akbar & Esko -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Monday, July 21, 2014 12:22 AM To: i-d-announce@ietf.org Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-groupcomm-20.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments Working Group of the IETF. Title : Group Communication for CoAP Authors : Akbar Rahman Esko Dijk Filename : draft-ietf-core-groupcomm-20.txt Pages : 50 Date : 2014-07-20 Abstract: CoAP is a specialized web transfer protocol for constrained devices and constrained networks. It is anticipated that constrained devices will often naturally operate in groups (e.g., in a building automation scenario all lights in a given room may need to be switched on/off as a group). This document provides guidance for how the CoAP protocol should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed. Also, various use cases and corresponding protocol flows are provided to illustrate important concepts. Finally, guidance is provided for deployment in various network topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-groupcomm-20 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-groupcomm-20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Mon Jul 21 07:23:26 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADC551A0034 for ; Mon, 21 Jul 2014 07:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bALx89RePaYv; Mon, 21 Jul 2014 07:23:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF131A010A; Mon, 21 Jul 2014 07:23:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: core-chairs@tools.ietf.org, draft-ietf-core-groupcomm@tools.ietf.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140721142305.18024.93978.idtracker@ietfa.amsl.com> Date: Mon, 21 Jul 2014 07:23:05 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/core/PdOjfmCiRnqgQwYZLVg4p0Z_mL4 Subject: [core] ID Tracker State Update Notice: X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 14:23:23 -0000 IESG state changed to AD Evaluation from Publication Requested ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ From nobody Mon Jul 21 08:05:37 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D2F1A0243 for ; Mon, 21 Jul 2014 08:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1uTqmJIpM1N for ; Mon, 21 Jul 2014 08:05:32 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 298D11A020B for ; Mon, 21 Jul 2014 08:05: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.5/8.14.5) with ESMTP id s6LF5Q18003715 for ; Mon, 21 Jul 2014 17:05:26 +0200 (CEST) Received: from dhcp-9c03.meeting.ietf.org (dhcp-9c03.meeting.ietf.org [31.133.156.3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3D4B24C1; Mon, 21 Jul 2014 17:05:24 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann Date: Mon, 21 Jul 2014 11:05:23 -0400 X-Mao-Original-Outgoing-Id: 427647923.802134-5ca31b55579cc8604e9c385eac617834 Content-Transfer-Encoding: quoted-printable Message-Id: <2698435C-5404-4EC7-9400-3562701AB737@tzi.org> To: core X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/core/0Y0vkib99CZca8j_8NU8RJAXLUQ Subject: [core] CoRE @ IETF90 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 21 Jul 2014 15:05:33 -0000 I have uploaded the 0.1 agenda for the CoRE meetings at IETF90. http://www.ietf.org/proceedings/90/agenda/agenda-90-core If you have requested a slot (or think you should have had), please = check. I=92ll need the slides for both slots (we=92ll try to be flexible) by = Tue 12:00 EDT (i.e., in 33 h), please. Gr=FC=DFe, Carsten From nobody Mon Jul 21 12:59:02 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E38E91A03B7 for ; Mon, 21 Jul 2014 12:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHLNiLhRh2pO for ; Mon, 21 Jul 2014 12:58:57 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAE4F1A03AA for ; Mon, 21 Jul 2014 12:58:56 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id hr17so5209136lab.30 for ; Mon, 21 Jul 2014 12:58:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=ohy7sXoPsFL//cV+S+r49/aOZpRerS9l+DVGNbLLJuY=; b=iDynkXFa5Ajsi4XiYOByVF3Gl3yubfrjmFk7fr1z88ugxx3z4vYlRpaBG2QBx39nwY TNtqHVbmSpfSNG3fWRnssJcTVDDvHw/nXztO5KgtjW+T+yfkyEhWmv0wlvcmZAEYXY2O Vigs14DPRSI7ZlKqxxLFb81tI9wM28iDNtEKkELLO1tRIUFJfK0I7KU+sOP3Eg3KwT1A l8aPaN/oo/zSwiDD9MFuzbgfGeFViRa1kHOnXV2EX0e/GKksdRUFu6fTiStjLpcBMaC+ oIQxiQqznnXTYe4LiEsC1VnNj2r9rk9wiYGetOpTooJsjBdjV8C9aNIpJHeiJMPPdDIg Ewdg== MIME-Version: 1.0 X-Received: by 10.152.43.34 with SMTP id t2mr28663829lal.28.1405972734489; Mon, 21 Jul 2014 12:58:54 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.46 with HTTP; Mon, 21 Jul 2014 12:58:54 -0700 (PDT) Date: Mon, 21 Jul 2014 15:58:54 -0400 X-Google-Sender-Auth: 5y1JrIFUwLzve1kHkAE__K5KboU Message-ID: From: Barry Leiba To: core WG Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/core/KTqX6_Apmin5HqvzA6wi-sLxgKk Subject: [core] AD review of draft-ietf-core-observe-14 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 21 Jul 2014 19:59:00 -0000 I've gotten my review of the Observe document done, despite IETF week. My comments are below. They're all minor, and there's no need to hold up last call for them, but I'm not going to request last call until Friday, just for timing purposes. If you want to post a revised version that addresses my comments, please do that before then. Otherwise, you can address my comments later. And, of course, feel free to argue with me about anything I say below. Barry -------------------------------------------------------------- -- Section 1.2 -- Notification: Whenever the state of a resource changes, the server notifies each client in the list of observers of the resource. Each notification is an additional CoAP response sent by the server in reply to the GET request and includes a complete, updated representation of the new resource state. I think it'd be a useful clarification to say this: NEW Notification: Whenever the state of a resource changes, the server notifies each client in the list of observers of the resource. Each notification is an additional CoAP response sent by the server in reply to the single extended GET request that was made at registration, and includes a complete, updated representation of the new resource state. END -- Section 2 -- Is it the case that when the server is unwilling ot unable to add the request to the observer list, and it falls back to a normal GET request, the response does not have the Observe Option? Assuming so, I think it could be made clearer this way: OLD The Observe Option is not critical for processing the request. If the server is unwilling or unable to add a new entry to the list of observers, then the request falls back to a normal GET request. In a response, the Observe Option identifies the message as a notification. This implies that the server has added an entry with the client endpoint and request token to the list of observers and that it will notify the client of changes to the resource state. The option value is a 24-bit sequence number for reordering detection (see Section 3.4 and Section 4.4). NEW In a response, the Observe Option identifies the message as a notification. This implies that the server has added an entry with the client endpoint and request token to the list of observers and that it will notify the client of changes to the resource state. The option value is a 24-bit sequence number for reordering detection (see Section 3.4 and Section 4.4). The Observe Option is not critical for processing the request. If the server is unwilling or unable to add a new entry to the list of observers, then the request falls back to a normal GET request, and the response does not include the Observe Option. END -- Section 3.1 -- The target resource SHALL be identified for this purpose by all options in the request that are part of the cache-key, such as the full request URI and the Accept Option. I think the SHALL is unncessary here, and that the sentence is a bit confusingly worded. This addresses that: NEW For this purpose, all requests in which all options that are part of the cache-key match are considered requests for the same target resource. Options that are part of the cache-key include, for example, the full request URI and the Accept Option. END I would also make that a separate paragraph. -- Section 3.2 -- As above (comment to Section 1.2), I would make this change: OLD Notifications are additional responses sent by the server in reply to the GET request. NEW Notifications are additional responses sent by the server in reply to the GET request that created the registration. END -- Section 3.3.1 -- Additionally, the client SHOULD at least wait for a random amount of time between 5 and 15 seconds after Max-Age expired to avoid synchronicity with other clients. I think "synchronicity" is not the right word here: it has a particular connotation that you don't intend. I suggest "to reduce collisions with other clients," or some such. -- Section 3.4 -- Messages with notifications can arrive in a different order than they were sent. Since the goal is to keep the observed state as closely in sync with the actual state as possible, a client MUST NOT consider a notification fresh that arrives later than a newer notification. That's a bit convoluted. I suggest wording it positively, rather than negatively, like this: NEW Messages with notifications can arrive in a different order than they were sent. Since the goal is to keep the observed state as closely in sync with the actual state as possible, a client MUST consider the notification that was sent most recently as the freshest, regardless of the order of arrival. END -- Section 3.5 -- Just a minor English issue: OLD A notification can be confirmable or non-confirmable, i.e., it can be sent in a confirmable or a non-confirmable message. The message type used for a notification is independent from the type used for the request or for any previous notification. NEW A notification can be confirmable or non-confirmable, i.e., it can be sent in a confirmable or a non-confirmable message. The message type used for a notification is independent of the type used for the request and of any previous notification. END -- Section 4.1 -- Upon success, the server returns a current representation of the resource and MUST notify the client of subsequent changes to the state as long as the client is on the list of observers. But we've already said it's OK for the server not to send *every* state change, so the MUST isn't quite right. I actually think you don't need MUST here, and that this will explain the situation just fine, allowing for what was said earlier: Upon success, the server returns a current representation of the resource, and notifies the client of subsequent changes to the state as long as the client is on the list of observers. -- Section 4.5 -- The "MAY" in the first paragraph doesn't need to be a 2119 key word. -- Section 6 -- The "obs" attribute MUST NOT appear more than once in a given link-value; occurrences after the first MUST be ignored by parsers. I see where you're going with this, but as "obs" has no value, if there are multiple occurrences they're all the same. In this case, I'd say it this way (putting the second part in active voice while I'm at it): NEW The "obs" attribute MUST NOT appear more than once in a given link-value, and parsers MUST ignore any extra occurrences. END -- Section 7 -- The security considerations in Section 11 of RFC 7252 [RFC7252] apply. I think it would be helpful to be more up front about what that is, rather than saying "7252" twice: NEW The security considerations in Section 11 of the CoAP specification [RFC7252] apply. END Servers may want to access- control this creation of state. Please don't make a verb out of "access control": NEW Servers may want to apply access controls to this creation of state. END -- Section 9 -- We have at our disposal the option of a "Contributors" section, which would go ahead of the "Acknowledgments" section, and which would be used for contributors who had a particularly significant contribution. We normally use that for additional or original authors, who are no longer listed as current authors. It sounds like Carsten might be listed in such a section, rather than in this one. I'll leave it entirely up to you, but I wanted to make sure you were aware of the option. -- References -- I think RFCs 1982 and 5405 are informative references, not normative ones. Please think about it again: is it necessary to understand those RFCs in order to do what this document is telling you to? If, after thinking about it again, you disagree with me, then leave one or both of them as they are. -------------------------------------------------------------- From nobody Mon Jul 21 13:01:46 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB41A1A039C for ; Mon, 21 Jul 2014 13:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsWC2VflE1ZL; Mon, 21 Jul 2014 13:01:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B49E1A043D; Mon, 21 Jul 2014 13:01:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: core-chairs@tools.ietf.org, draft-ietf-core-observe@tools.ietf.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140721200131.8190.68415.idtracker@ietfa.amsl.com> Date: Mon, 21 Jul 2014 13:01:31 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/core/lV-zZJrWXiLEulF2_tDb5cQs4rU Subject: [core] ID Tracker State Update Notice: X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 20:01:43 -0000 IESG state changed to AD Evaluation::AD Followup from AD Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-core-observe/ From nobody Mon Jul 21 15:00:45 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 821291A0290 for ; Mon, 21 Jul 2014 15:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBg2e1iM_Fym for ; Mon, 21 Jul 2014 15:00:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 941851A02A3 for ; Mon, 21 Jul 2014 15:00:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140721220035.29579.3338.idtracker@ietfa.amsl.com> Date: Mon, 21 Jul 2014 15:00:35 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/core/vHmhzTHhM0WaaXASpxgnYuhMebs Subject: [core] Milestones changed for core WG X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 22:00:42 -0000 Changed milestone "Observing Resources in CoAP submitted to IESG", resolved as "Done". Changed milestone "Group Communication for CoAP submitted to IESG", resolved as "Done". URL: http://datatracker.ietf.org/wg/core/charter/ From nobody Mon Jul 21 17:35:36 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 431371A020B for ; Mon, 21 Jul 2014 17:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.026 X-Spam-Level: X-Spam-Status: No, score=-0.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hunjUB4tuoyf for ; Mon, 21 Jul 2014 17:35:34 -0700 (PDT) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15CEA1A0114 for ; Mon, 21 Jul 2014 17:35:34 -0700 (PDT) Received: by mail-yk0-f179.google.com with SMTP id 142so4447090ykq.10 for ; Mon, 21 Jul 2014 17:35:33 -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:cc:content-type; bh=H0wWdqGcL1En8ev6jp0VRrbqJjHNPQRQaJ0yOlJd3j8=; b=VqU/vWJVKwsKKhDiYV5kZFY8ZXL+RGwj/piIBmSSg97/ORMZYxBX8aKakLWWR/djVA /KGixzZ6fi9nfL3BCpj6trzhrA5qG2pK7SObYwF5FNPv0CuLzJyzNgLN+XkmWMDe4N4h Ls9ZcFKKDT5PplI1+/ZqiHFOmGTioJqDVYjnBzTP9VImYoRgbMWkhj7kNnCDEJnWilc0 AGaBnZzQnJ2TrJl8AlwKxkniVEF8EFRxVlBox5mkhYEOr+CcMpSvDwVlcT7OjwxS7Yji 5eFe1AH+6lC+TyyUIIW9pnrwDHo90BKJo6krIQjo8Z0OoEPaWX2dRLyc7LX/bAYS72R5 ztRg== MIME-Version: 1.0 X-Received: by 10.236.108.147 with SMTP id q19mr45059089yhg.27.1405989333357; Mon, 21 Jul 2014 17:35:33 -0700 (PDT) Received: by 10.170.219.10 with HTTP; Mon, 21 Jul 2014 17:35:33 -0700 (PDT) Date: Tue, 22 Jul 2014 02:35:33 +0200 Message-ID: From: Pascal Urien To: Carsten Bormann Content-Type: multipart/alternative; boundary=089e0160b5a8c5e97d04febd66a4 Archived-At: http://mailarchive.ietf.org/arch/msg/core/AQe0L_u7-K4QvlubVr5lcKR2Q7E Cc: core Subject: Re: [core] CoRE @ IETF90 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 22 Jul 2014 00:35:35 -0000 --089e0160b5a8c5e97d04febd66a4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear sir If you have a couple of minutes in the flex time on wednesday, i will be happy to shortly introduce the RACS protocol http://tools.ietf.org/html/draft-urien-core-racs-03 which have today several implementations The target of RACS is to allow the deployment of secure elements in the internet at a huge scale Regards Pascal Urien 2014-07-21 17:05 GMT+02:00 Carsten Bormann : > I have uploaded the 0.1 agenda for the CoRE meetings at IETF90. > > http://www.ietf.org/proceedings/90/agenda/agenda-90-core > > If you have requested a slot (or think you should have had), please check= . > I=E2=80=99ll need the slides for both slots (we=E2=80=99ll try to be flex= ible) by Tue > 12:00 EDT (i.e., in 33 h), please. > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --089e0160b5a8c5e97d04febd66a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear sir

If you have a couple of minute= s in the flex time on wednesday, i will be happy to shortly introduce the R= ACS protocol=C2=A0


which have today several implementations

=
The target of =C2=A0RACS is to allow the deployment of secure el= ements in the internet at a huge scale

Regards

Pascal Urien




2014-07-21 17:05 GMT= +02:00 Carsten Bormann <cabo@tzi.org>:
I have uploaded the 0.1 agenda for the CoRE = meetings at IETF90.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ietf.org/proceedings/90/= agenda/agenda-90-core

If you have requested a slot (or think you should have had), please check.<= br> I=E2=80=99ll need the slides for both slots (we=E2=80=99ll try to be flexib= le) by Tue 12:00 EDT (i.e., in 33 h), please.

Gr=C3=BC=C3=9Fe, Carsten

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

--089e0160b5a8c5e97d04febd66a4-- From nobody Mon Jul 21 18:34:01 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D121A028A for ; Mon, 21 Jul 2014 18:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.424 X-Spam-Level: X-Spam-Status: No, score=0.424 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bs4l2rXgORXr for ; Mon, 21 Jul 2014 18:33:58 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D14E11A0154 for ; Mon, 21 Jul 2014 18:33: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.5/8.14.5) with ESMTP id s6M1XpFS026580; Tue, 22 Jul 2014 03:33:51 +0200 (CEST) Received: from [10.148.17.223] (199-7-156-143.eng.wind.ca [199.7.156.143]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A727C63D; Tue, 22 Jul 2014 03:33:50 +0200 (CEST) Content-Type: multipart/alternative; boundary=Apple-Mail-6C92DE7A-FBF6-4811-AB07-79099BDDA98A Mime-Version: 1.0 (1.0) From: Carsten Bormann X-Mailer: iPad Mail (11D257) In-Reply-To: Date: Mon, 21 Jul 2014 21:33:48 -0400 Content-Transfer-Encoding: 7bit Message-Id: <2D1554BC-11C9-49F0-BB89-F243BDDC0057@tzi.org> References: To: Pascal Urien Archived-At: http://mailarchive.ietf.org/arch/msg/core/hjslz2P4U_a7dLMbeYZsOqShMGw Cc: Hannes Tschofenig , Kepeng Li <1095318589@qq.com>, core Subject: Re: [core] CoRE @ IETF90 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 22 Jul 2014 01:33:59 -0000 --Apple-Mail-6C92DE7A-FBF6-4811-AB07-79099BDDA98A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Pascal, Thank you for the pointer.=20 I'm not quite sure how this connects to the CoRE work. More importantly, since we are moving security-related issues to the new ACE= WG, maybe this is a better fit there. I'm CCing the ACE chairs. Sent from my iPad > On 21.07.2014, at 20:35, Pascal Urien wrote: >=20 > Dear sir >=20 > If you have a couple of minutes in the flex time on wednesday, i will be h= appy to shortly introduce the RACS protocol=20 >=20 > http://tools.ietf.org/html/draft-urien-core-racs-03 >=20 > which have today several implementations >=20 > The target of RACS is to allow the deployment of secure elements in the i= nternet at a huge scale >=20 > Regards >=20 > Pascal Urien >=20 >=20 >=20 >=20 > 2014-07-21 17:05 GMT+02:00 Carsten Bormann : >> I have uploaded the 0.1 agenda for the CoRE meetings at IETF90. >>=20 >> http://www.ietf.org/proceedings/90/agenda/agenda-90-core >>=20 >> If you have requested a slot (or think you should have had), please check= . >> I=E2=80=99ll need the slides for both slots (we=E2=80=99ll try to be flex= ible) by Tue 12:00 EDT (i.e., in 33 h), please. >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 --Apple-Mail-6C92DE7A-FBF6-4811-AB07-79099BDDA98A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Pascal,

Th= ank you for the pointer. 
I'm not quite sure how this connect= s to the CoRE work.
More importantly, since we are moving security= -related issues to the new ACE WG, maybe this is a better fit there.  I= 'm CCing the ACE chairs.

Sent from my iPad

On 21.07.201= 4, at 20:35, Pascal Urien <pasc= al.urien@gmail.com> wrote:

Dear sir

If you have a couple of minut= es in the flex time on wednesday, i will be happy to shortly introduce the R= ACS protocol 


which have today several implementations

<= /div>
The target of  RACS is to allow the deployment of secure elem= ents in the internet at a huge scale

Regards

Pascal Urien




2014-07-21 17:05 GMT+0= 2:00 Carsten Bormann <cabo@tzi.org>:
I have uploaded the 0.1 agenda for the CoRE me= etings at IETF90.

        http://www.ietf.org/proceedings/90/ag= enda/agenda-90-core

If you have requested a slot (or think you should have had), please check. I=E2=80=99ll need the slides for both slots (we=E2=80=99ll try to be flexibl= e) by Tue 12:00 EDT (i.e., in 33 h), please.

Gr=C3=BC=C3=9Fe, Carsten

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

= --Apple-Mail-6C92DE7A-FBF6-4811-AB07-79099BDDA98A-- From nobody Mon Jul 21 19:45:15 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA881A039A for ; Mon, 21 Jul 2014 19:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jmc1hUJn0Fy6 for ; Mon, 21 Jul 2014 19:45:13 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BC4B1A03A6 for ; Mon, 21 Jul 2014 19:45: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.5/8.14.5) with ESMTP id s6M2j8kK019483; Tue, 22 Jul 2014 04:45:08 +0200 (CEST) Received: from [172.20.10.3] (199-7-156-143.eng.wind.ca [199.7.156.143]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4102E642; Tue, 22 Jul 2014 04:45:05 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: Date: Mon, 21 Jul 2014 22:45:03 -0400 X-Mao-Original-Outgoing-Id: 427689903.173594-44ff50bdc45dc2a7b212a8557653e47b Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Barry Leiba X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/core/ZFkmIzq2b9ZwVRPQXu1MGIjkCgw Cc: core WG Subject: Re: [core] AD review of draft-ietf-core-observe-14 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 22 Jul 2014 02:45:14 -0000 Good suggestions. I have a bit of a reservation on this one: On 21 Jul 2014, at 15:58, Barry Leiba wrote: > -- Section 4.1 -- >=20 > Upon success, the server returns a current representation > of the resource and MUST notify the client of subsequent changes to > the state as long as the client is on the list of observers. >=20 > But we've already said it's OK for the server not to send *every* > state change, so the MUST isn't quite right. I actually think you > don't need MUST here, and that this will explain the situation just > fine, allowing for what was said earlier: >=20 > Upon success, the server returns a current representation > of the resource, and notifies the client of subsequent changes to > the state as long as the client is on the list of observers. I think this is trying to make the point that, while a specific = intermediate state can be lost, there is a promise of eventual = consistency. So a server cannot e.g. update the state, even keep the resource stable = in the new state, and never update its observers. It MUST notify at some point. I trust Klaus can find a better way to phrase this without losing this = MUST when he returns from his vacation at the end of next week. Gr=FC=DFe, Carsten From nobody Tue Jul 22 06:48:16 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE5801B2817 for ; Tue, 22 Jul 2014 06:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FBj4wWWS3Mn for ; Tue, 22 Jul 2014 06:48:11 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8FC51B2809 for ; Tue, 22 Jul 2014 06:48:10 -0700 (PDT) Received: from [192.168.10.130] ([31.133.166.25]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Lb5Tp-1WhM9Z2N9l-00kgwq; Tue, 22 Jul 2014 15:48:09 +0200 Message-ID: <53CE6B95.70708@gmx.net> Date: Tue, 22 Jul 2014 15:48:05 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: core@ietf.org References: <53CE6B26.1030100@gmx.net> In-Reply-To: <53CE6B26.1030100@gmx.net> X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 X-Forwarded-Message-Id: <53CE6B26.1030100@gmx.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ex9NxL8SIN8joJL1pkwd9KjR4VS6tOWS1" X-Provags-ID: V03:K0:uS6/LK/8urILmFNK7YXkIxUUvFdxp6Jww7/Eqh+y0H4erez1k+A mnZQcc1waq40NgwyIh8LExUYgjd+Pe2yuyvpdIRXQAVyYJk8k0ZHGUAT113pNWXpXo6po38 y8IH0yiMKSiFsgF525QOqem792PzzMSvPkjYr6U/pjRrBk54WGtI3Bu11zJdxdrdiHeLadK dfCE8OeL5FVk45ql42VZA== Archived-At: http://mailarchive.ietf.org/arch/msg/core/fDrAWzWyE2gcIZ4Ykrygu7KuAWA Cc: Michael.Koster@arm.com Subject: [core] ARM Hackaton (Today) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 22 Jul 2014 13:48:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ex9NxL8SIN8joJL1pkwd9KjR4VS6tOWS1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, in case you are not planning to attend the social event tonight and want to play around with ARM-based Internet of Things gear please come to "Confederation 3" at 7pm today. Michael and I will will show you some of our ARM-based development boards, our online development platform (mbed.org), and write code to upload sensor data to a CoAP server. Ciao Hannes & Michael --ex9NxL8SIN8joJL1pkwd9KjR4VS6tOWS1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTzmuVAAoJEGhJURNOOiAt/GIH/jimApfkVHc1QWfpeBIybboY zvDWaUh5fHCXb20kYiwFsMpmC/C2u+Gatw1paJx/f9j4+naod8CLpgGa76d3bNT2 RLtoDu6sRLt3u5a9uBSkrGda/SmjhD4hiRUIH0h8WnVaL3ERKkbqq1LJjrNOGjSG mhmWT+TeP29h3NINbnKX157quZj33mrBcr/Q0uATvmFW81PKpm4aBMnSpoDMc2+p DcpYCKR0gNvZMhwYjuZiRRHNvayRgp75tMrHuHQtvKFv/soCZXRyDltaqWeY1NKH iuL6+FFhRBk48EavbhjsVcGg/OADbSsr3uiKz5S0dmsTSkJ7S5GvwAheL/dvcI8= =XBYo -----END PGP SIGNATURE----- --ex9NxL8SIN8joJL1pkwd9KjR4VS6tOWS1-- From nobody Tue Jul 22 21:21:24 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F621B291A for ; Tue, 22 Jul 2014 21:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfdzuNtnyupV for ; Tue, 22 Jul 2014 21:21:21 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EBCF1B2907 for ; Tue, 22 Jul 2014 21:21: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.5/8.14.5) with ESMTP id s6N4LI0p006418 for ; Wed, 23 Jul 2014 06:21:18 +0200 (CEST) Received: from [172.20.10.3] (unknown [199.119.232.208]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 74B54D96 for ; Wed, 23 Jul 2014 06:21:17 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=windows-1252 X-Mao-Original-Outgoing-Id: 427782070.950919-66c17b898410e8962a2754f63dbe81de Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Message-Id: <1056B586-D333-4D9A-B087-FF687198D46E@tzi.org> Date: Wed, 23 Jul 2014 00:21:11 -0400 To: "core@ietf.org WG" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/core/97CD1IbikeGW_5V_4jmWX1drQsM Subject: [core] Slides for IETF90... X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 23 Jul 2014 04:21:22 -0000 =85 have been uploaded at = http://www.ietf.org/proceedings/90/slides/slides-90-core-0.pdf Please also note the slightly updated agenda at = http://www.ietf.org/proceedings/90/agenda/agenda-90-core Speakers: Please do the usual checks whether I bungled it. Gr=FC=DFe, Carsten From nobody Wed Jul 23 10:44:08 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69D371B2BAD; Wed, 23 Jul 2014 10:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYOJVctfPp86; Wed, 23 Jul 2014 10:44:05 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A7A51B2BE9; Wed, 23 Jul 2014 10:43:56 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s6NHhsLb017854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 23 Jul 2014 17:43:54 GMT Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s6NHhs50026143 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jul 2014 19:43:54 +0200 Received: from DEMUHTC009.nsn-intra.net (10.159.42.40) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 23 Jul 2014 19:43:54 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.198]) by DEMUHTC009.nsn-intra.net ([10.159.42.40]) with mapi id 14.03.0181.006; Wed, 23 Jul 2014 19:43:54 +0200 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "lwip@ietf.org" , "core@ietf.org" , "6lo@ietf.org" <6lo@ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org> Thread-Topic: WGLC of Coman Drafts v02 Thread-Index: Ac+Xyyub/7oQlmAhQP2V4Qmsi3MlFADD4cuAAMmpF+ABUyhIgAAe+/aAALSdhpA= Date: Wed, 23 Jul 2014 17:43:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.99] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 3513 X-purgate-ID: 151667::1406137434-00007A71-D9C7D156/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/core/Vn-LIgVYK0SHmdU9zXpaqN55lBQ Subject: [core] WGLC of Coman Drafts v02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 23 Jul 2014 17:44:07 -0000 Hi All, a WGLC has been started for the Coman drafts on the "Management of Networks= with Constrained Devices" and=20 is running until July 29, 2014. Please comment on the drafts below on the OPSAWG maillist. Please state also if you think the documents are ready to publish. http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-probstate-reqs/ http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-use-cases/=20 Thanks,=20 Mehmet=20 -----Original Message----- From: coman [mailto:coman-bounces@ietf.org] On Behalf Of ext Ersue, Mehmet = (NSN - DE/Munich) Sent: Sunday, July 20, 2014 5:23 AM To: coman@ietf.org Subject: [coman] FW: FW: [OPSAWG] Coman Drafts v02 -----Original Message----- From: ext Warren Kumari [mailto:warren@kumari.net]=20 Sent: Saturday, July 19, 2014 4:36 PM To: Ersue, Mehmet (NSN - DE/Munich) Cc: coman@ietf.org; opsawg-chairs@tools.ietf.org Subject: Re: FW: [OPSAWG] Coman Drafts v02 A reminder to everyone to please review these documents and provide feedbac= k. We may be unable to proceed without any feedback... W On Sat, Jul 12, 2014 at 2:47 PM, Ersue, Mehmet (NSN - DE/Munich) wrote: > For those who are not on the opsawg maillist, > WGLC has been started for the two Coman drafts in OPSAWG WG (see below). > > Please send your comments to the OPSAWG maillist. > > Thank you. > > Cheers, > Mehmet > > -----Original Message----- > From: ext Warren Kumari [mailto:warren@kumari.net] > Sent: Tuesday, July 08, 2014 10:31 PM > To: Ersue, Mehmet (NSN - DE/Munich) > Cc: opsawg@ietf.org; a.sehgal@jacobs-university.de; opsawg-chairs@tools.i= etf.org > Subject: Re: [OPSAWG] Coman Drafts v02 > > Dear OpsAWG WG, > > The authors of draft-ietf-opsawg-coman-probstate-reqs-02 and > draft-ietf-opsawg-coman-use-cases-02 have indicated that they believe > that the document is > ready, and have asked for Working Group Last Call. > > The draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-probstate-reqs-0= 2/ > and here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-use-ca= ses/ > > Please review this draft to see if you think it is ready for publication > and send comments to the list, **clearly** stating your view. > > IETF90 is Toronto is nearly upon us, and so folk are busy / may have > questions about this document. Because of this we are doing an > extended (3 week) WGLC - It ends Tue 29-Jul-2014. > > > Thanks, > Warren Kumari > (as OpsAWG WG co-chair) > > On Fri, Jul 4, 2014 at 5:01 PM, Ersue, Mehmet (NSN - DE/Munich) > wrote: >> Dear OPSAWG Chairs, >> >> we submitted v02 of the Coman drafts. >> >> As discussed in IETF #89, the authors think that the two documents are r= eady >> for WGLC. >> Please consider to start the WGLC procedure. Thank you. >> >> Management of Networks with Constrained Devices: Problem Statement and >> Requirements >> http://tools.ietf.org/html/draft-ietf-opsawg-coman-probstate-reqs-02 >> >> Management of Networks with Constrained Devices: Use Cases >> http://tools.ietf.org/html/draft-ietf-opsawg-coman-use-cases-02 >> >> Regards, >> Mehmet >> >> >> >> >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg >> _______________________________________________ coman mailing list coman@ietf.org https://www.ietf.org/mailman/listinfo/coman From nobody Wed Jul 23 11:22:44 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 879291B2C10 for ; Wed, 23 Jul 2014 11:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49DQ4m23F-XA for ; Wed, 23 Jul 2014 11:22:39 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 253FF1B2BB1 for ; Wed, 23 Jul 2014 11:22:37 -0700 (PDT) Received: from localhost ([::1]:50709 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XA1BL-0006go-Vh; Wed, 23 Jul 2014 11:22:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-resource-directory@tools.ietf.org, zach@sensinode.com X-Trac-Project: core Date: Wed, 23 Jul 2014 18:22:27 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/369 Message-ID: <057.b46cf6744929bebb46803c866d11b1d0@trac.tools.ietf.org> X-Trac-Ticket-ID: 369 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-resource-directory@tools.ietf.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, srdjan.krco@ericsson.com, zach.shelby@arm.com Archived-At: http://mailarchive.ietf.org/arch/msg/core/nYFp2pCRsxKPLuj4C5Miq290hcY Cc: core@ietf.org Subject: [core] #369 (resource-directory): Semantic Catalogue use case addition X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Reply-To: trac+core@zinfandel.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, 23 Jul 2014 18:22:41 -0000 #369: Semantic Catalogue use case addition As discussed on the mailing list, it was proposed to add a semantic catalogue use case to the RD specification. The proposed text from Michael Koster is as follows: Resources may be shared through data brokers that have no knowledge beforehand of who is going to consume the data. Resource Directory can be used to hold links about resources and services hosted anywhere to make them discoverable by a general class of applications. For example, environmental and weather sensors that generate data for public consumption may provide the data to an intermediary server, or broker. Sensor data are published to the intermediary upon changes or at regular intervals. Descriptions of the sensors that resolve to links to sensor data may be published to a Resource Directory. Applications wishing to consume the data can use the Resource Directory lookup function set to discover and resolve links to the desired resources and endpoints. The Resource Directory service need not be coupled with the data intermediary service. Mapping of Resource Directories to data intermediaries may be many-to-many. Metadata in link-format or link-format+json representations are supplied by Resource Directories, which may be internally stored as semantic triples, or relation/attribute pairs providing metadata about resource links. External catalogs that are represented in other formats may be converted to link-format or link-format+json for storage and access by Resource Directories. Since it is common practice for these to be URN encoded, simple and lossless structural transforms will generally be sufficient to store external metadata in Resource Directories. The additional features of Resource Directory allow domains to be defined to enable access to a particular set of resources from particular applications. this provides isolation and protection of sensitive data when needed. Resource groups may defined to allow batched reads from multiple resources. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-resource- zach@sensinode.com | directory@tools.ietf.org Type: editorial | Status: new Priority: minor | Milestone: Component: resource- | Version: directory | Keywords: Severity: - | -------------------------+------------------------------------------------- Ticket URL: core From nobody Wed Jul 23 11:25:05 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 224B01B27A8 for ; Wed, 23 Jul 2014 11:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXAJT_31Qltq for ; Wed, 23 Jul 2014 11:25:02 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEF361ABD17 for ; Wed, 23 Jul 2014 11:25:02 -0700 (PDT) Received: from localhost ([::1]:50886 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XA1Dj-0001N3-Ii; Wed, 23 Jul 2014 11:24:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-resource-directory@tools.ietf.org, zach@sensinode.com X-Trac-Project: core Date: Wed, 23 Jul 2014 18:24:55 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/370 Message-ID: <057.cd8c89deadfdd946c0ce9b786e500868@trac.tools.ietf.org> X-Trac-Ticket-ID: 370 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-resource-directory@tools.ietf.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, srdjan.krco@ericsson.com, zach.shelby@arm.com Archived-At: http://mailarchive.ietf.org/arch/msg/core/hFOLlel7Er8gAmGTdmsmFVjeOtk Cc: core@ietf.org Subject: [core] #370 (resource-directory): Integrate the DNS-SD mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Reply-To: trac+core@zinfandel.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, 23 Jul 2014 18:25:04 -0000 #370: Integrate the DNS-SD mapping A discussion on the exporting of RD information for use in DNS-SD is to be added, based on the previous work in draft-lynn-core-discovery-mapping-02. Section 9 in -01 is the placeholder for this addition. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-resource- zach@sensinode.com | directory@tools.ietf.org Type: task | Status: new Priority: major | Milestone: Component: resource- | Version: directory | Keywords: Severity: - | -------------------------+------------------------------------------------- Ticket URL: core From nobody Wed Jul 23 11:26:59 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3E71A02F0 for ; Wed, 23 Jul 2014 11:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uz2_N4QMcsoN for ; Wed, 23 Jul 2014 11:26:55 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9837C1A01A5 for ; Wed, 23 Jul 2014 11:26:55 -0700 (PDT) Received: from localhost ([::1]:51005 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XA1FZ-0001Bc-J4; Wed, 23 Jul 2014 11:26:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-resource-directory@tools.ietf.org, zach@sensinode.com X-Trac-Project: core Date: Wed, 23 Jul 2014 18:26:49 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/371 Message-ID: <057.e17d33b0f25c13497bad6895c0b8378b@trac.tools.ietf.org> X-Trac-Ticket-ID: 371 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-resource-directory@tools.ietf.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, srdjan.krco@ericsson.com, zach.shelby@arm.com Archived-At: http://mailarchive.ietf.org/arch/msg/core/9zsAeqW6W77n8ICSyhnsYP5fqrs Cc: core@ietf.org Subject: [core] #371 (resource-directory): DDoS security consideration X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Reply-To: trac+core@zinfandel.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, 23 Jul 2014 18:26:56 -0000 #371: DDoS security consideration Add a security consideration with regard to DDoS and resource directories, proposed text from Mohit Sethi is as follows: Services that run over UDP unprotected are vulnerable to unknowingly become part of a DDoS attack as UDP does not require return routability check. Therefore, an attacker can easily spoof the source IP of the target entity and send requests to such a service which would then respond to the target entity. This can be used for large-scale DDoS attacks on the target. Especially, if the service returns a response that is order of magnitudes larger than the request, the situation becomes even worse as now the attack can be amplified. DNS servers have been widely used for DDoS amplification attacks. Recently, it has been observed that NTP Servers, that also run on unprotected UDP have been used for DDoS attacks (http:// tools.cisco.com/security/center/content/CiscoSecurityNotice/ CVE-2013-5211) [TODO: Ref] since there is no return routability check and can have a large amplification factor. The responses from the NTP server were found to be 19 times larger than the request. A Resource Directory (RD) which responds to wild-card lookups is potentially vulnerable if run with CoAP over UDP. Since there is no return routability check and the responses can be significantly larger than requests, RDs can unknowingly become part of a DDoS amplification attack. Therefore, it is recommended that implementations must ensure return routability. This can be done, for example by responding to wild card lookups only over DTLS or TLS or TCP. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-resource- zach@sensinode.com | directory@tools.ietf.org Type: task | Status: new Priority: minor | Milestone: Component: resource- | Version: directory | Keywords: Severity: - | -------------------------+------------------------------------------------- Ticket URL: core From nobody Wed Jul 23 11:28:57 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2E61B2B04 for ; Wed, 23 Jul 2014 11:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bO7bybThA1wn for ; Wed, 23 Jul 2014 11:28:53 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BB5D1A02F0 for ; Wed, 23 Jul 2014 11:28:53 -0700 (PDT) Received: from localhost ([::1]:51107 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XA1HR-0000AP-Nb; Wed, 23 Jul 2014 11:28:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-resource-directory@tools.ietf.org, zach@sensinode.com X-Trac-Project: core Date: Wed, 23 Jul 2014 18:28:45 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/372 Message-ID: <057.0e8e70b4bea3da54bccebacfdd88b92d@trac.tools.ietf.org> X-Trac-Ticket-ID: 372 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-resource-directory@tools.ietf.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, srdjan.krco@ericsson.com, zach.shelby@arm.com Archived-At: http://mailarchive.ietf.org/arch/msg/core/aSk-QCtxJRvid59QyIsExAJhQ-0 Cc: core@ietf.org Subject: [core] #372 (resource-directory): Examples section with use cases X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Reply-To: trac+core@zinfandel.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, 23 Jul 2014 18:28:54 -0000 #372: Examples section with use cases A dedicated example section should be added, with a focus on more complex use cases. The current examples are in-line and focused on highlighting the use of individual features. An example of a use case is the storing of link relations that are not simple hosts relations for semantic catalogues. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-resource- zach@sensinode.com | directory@tools.ietf.org Type: task | Status: new Priority: minor | Milestone: Component: resource- | Version: directory | Keywords: Severity: - | -------------------------+------------------------------------------------- Ticket URL: core From nobody Wed Jul 23 11:38:14 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581E41B29A7 for ; Wed, 23 Jul 2014 11:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOKwJg4W68nZ for ; Wed, 23 Jul 2014 11:38:03 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DC781B299B for ; Wed, 23 Jul 2014 11:38:00 -0700 (PDT) Received: from localhost ([::1]:51623 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XA1QG-0002xO-4B; Wed, 23 Jul 2014 11:37:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-resource-directory@tools.ietf.org, zach@sensinode.com X-Trac-Project: core Date: Wed, 23 Jul 2014 18:37:52 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/373 Message-ID: <057.ce12f57512efcbd1b1311e8fc126139b@trac.tools.ietf.org> X-Trac-Ticket-ID: 373 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-resource-directory@tools.ietf.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, srdjan.krco@ericsson.com, zach.shelby@arm.com Archived-At: http://mailarchive.ietf.org/arch/msg/core/Aow4ESGaOmBzvhGowUbdC4Yy86M Cc: core@ietf.org Subject: [core] #373 (resource-directory): Fix the registration update interface X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Reply-To: trac+core@zinfandel.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, 23 Jul 2014 18:38:05 -0000 #373: Fix the registration update interface The registration update interface has been in need of a final update for some time proposed as follows: - Change to a POST for better REST semantics - Removal of Endpoint Type update - Links can be included, and such links are either added or modify an existing link (NOTE: Section needed on when a link matches for such an update) With these proposed changes, the section would look like: 5.3. Update The update interface is used by an endpoint to refresh or update its registration with an RD. To use the interface, the endpoint sends a POST request to the resource returned in the Location option in the response to the first registration. An update MAY update the lifetime or context parameters if they have changed since the last registration or update. Parameters that have not changed SHOULD NOT be included in an update. Upon receiving an update request, the RD resets the timeout for that endpoint and updates the scheme, IP address and port of the endpoint (using the source address of the update, or the context parameter if present). An update MAY optionally add or replace links for the endpoint by including those links in the payload of the update as a CoRE Link Format document. Including links in an update message greatly increases the load on an RD and SHOULD be done infrequently. A link is replaced only if both the target URI and relation type match (TODO: Section on what is a unique link in an RD needed.) The update request interface is specified as follows: Interaction: EP -> RD Method: POST URI Template: /{+location}{?lt,con} URI Template Variables: location := This is the Location path returned by the RD as a result of a successful registration. lt := Lifetime (optional). Lifetime of the registration in seconds. Range of 60-4294967295. If no lifetime is included, a default value of 86400 (24 hours) SHOULD be assumed. con := Context (optional). This parameter sets the scheme, address and port at which this server is available in the form scheme://host:port. Optional. In the absence of this parameter the scheme of the protocol, source IP address and source port used to register are assumed. Content-Type: application/link-format (optional) Content-Type: application/link-format+json (optional) The following response codes are defined for this interface: Success: 2.04 "Changed" in the update was successfully processed. Failure: 4.00 "Bad Request". Malformed request. Failure: 5.03 "Service Unavailable". Service could not perform the operation. The following example shows an endpoint updating a new set of resources to an RD using this interface. EP RD | | | --- POST /rd/4521 --------------------------> | | | | | | <-- 2.04 Changed ---------------------------- | | | Req: POST /rd/4521 Res: 2.04 Changed -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-resource- zach@sensinode.com | directory@tools.ietf.org Type: protocol | Status: new enhancement | Milestone: Priority: major | Version: Component: resource- | Keywords: directory | Severity: - | -------------------------+------------------------------------------------- Ticket URL: core From nobody Wed Jul 23 12:29:18 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6096A1B2C10 for ; Wed, 23 Jul 2014 12:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WE6_RULO3lpr for ; Wed, 23 Jul 2014 12:29:16 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 282FE1B2C07 for ; Wed, 23 Jul 2014 12:29:16 -0700 (PDT) Received: from localhost ([::1]:54646 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XA2Dw-00064Q-38; Wed, 23 Jul 2014 12:29:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-interfaces@tools.ietf.org, zach@sensinode.com X-Trac-Project: core Date: Wed, 23 Jul 2014 19:29:12 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/374 Message-ID: <057.9e5d86d763642b8b7fdbf48acb4a7f1d@trac.tools.ietf.org> X-Trac-Ticket-ID: 374 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-interfaces@tools.ietf.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: matthieu.vial@schneider-electric.com, zach.shelby@arm.com Archived-At: http://mailarchive.ietf.org/arch/msg/core/sEBWzTizZVHnigUKYrksSY6mst8 Cc: core@ietf.org Subject: [core] #374 (interfaces): Expand function set and OMA Object discussion X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Reply-To: trac+core@zinfandel.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, 23 Jul 2014 19:29:17 -0000 #374: Expand function set and OMA Object discussion Section 3 currently discusses an example of the use of a function set (RD interfaces) and OMA Objects. These should be expanded into their own sub- sections with more details and discussion. OMA references need to be updated to the final specification and registry. When does it make sense to use a standard object vs. standardise a function set in a spec vs. create a custom function set for a device? -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- zach@sensinode.com | interfaces@tools.ietf.org Type: editorial | Status: new Priority: minor | Milestone: Component: interfaces | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: core From nobody Wed Jul 23 14:49:20 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B69521B2827 for ; Wed, 23 Jul 2014 14:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.393 X-Spam-Level: X-Spam-Status: No, score=-4.393 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYKduZeHkl5i for ; Wed, 23 Jul 2014 14:49:17 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D813A1A030B for ; Wed, 23 Jul 2014 14:49:16 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id s6NLnFCn028455 for ; Thu, 24 Jul 2014 06:49:15 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id s6NLnFQc018241 for core@ietf.org; Thu, 24 Jul 2014 06:49:15 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id GAA18240; Thu, 24 Jul 2014 06:49:15 +0900 Received: from mx12.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id s6NLnFsH000100 for ; Thu, 24 Jul 2014 06:49:15 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id s6NLnELO002987; Thu, 24 Jul 2014 06:49:14 +0900 (JST) Received: from [133.199.16.148] (ivpn-1-148.mobile.toshiba.co.jp [133.199.16.148]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id 5335897D84 for ; Thu, 24 Jul 2014 06:49:13 +0900 (JST) Message-ID: <53D02DAD.3070005@toshiba.co.jp> Date: Thu, 24 Jul 2014 06:48:29 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: core@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/core/cRzM5MQxUQO4Wbtm_6BGyZySnR8 Subject: [core] On Content Transcode X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 23 Jul 2014 21:49:19 -0000 Hi, With regards to content transcoding of core-http mapping, let me describe (expected) use case on SEP2 (now IEEEP2030.5). http://tools.ietf.org/html/draft-ietf-core-http-mapping-04#section-6.3.3 [Background] Unlike CBOR, EXI does not have one-to-one mapping with XML instance. EXI can encode XML document in various ways: schemaless, schema-informed, bunch of options, profiles... etc. In particular, schema-informed encoding make use of a XML schema as a grammar. Thus, even a slightest difference in the schema may break interoperability in EXI. So, something like footype+exi is not sufficient if the content is expected to be encoded in schema-informed EXI. (It is reasonable to use schemaless EXI in that case). To deal with the issue, SEP2 defined two media types: sep-exi and sep+xml. http://www.iana.org/assignments/media-types/application/sep-exi http://www.iana.org/assignments/media-types/application/sep+xml So, if some node try to speak SEP2 over CoAP (though, SEP2 spec is defined in HTTP), a trancoder should be aware of the schema as part of media type. -- What I'd appreciate if the document can mention such specific case are out of the scope of the document and the implementor should be responsible and be aware of the side-effect (may not specific to EXI cases). In particular, schema-informed EXI will be mapped to application/exi without any schema information OR application/octet-stream. In-band metadata is lost in the case and the proxy should be aware of the metadata required to manage the metadata (schema, or any other application-specific data). If I need to implement a transcoding proxy (though I have no plan to make it by myself), I'd add per-path(regexp) configuration of transcoding rule with such metadata. Regards, Yusuke From nobody Thu Jul 24 16:23:49 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3332E1A052E for ; Thu, 24 Jul 2014 16:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QoPiJ01DvZ_q for ; Thu, 24 Jul 2014 16:23:46 -0700 (PDT) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 859391A03E1 for ; Thu, 24 Jul 2014 16:23:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,727,1400005800"; d="scan'208";a="560842477" Received: from INKOLSALDLPMTA1.india.tcs.com (unknown [127.0.0.1]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id CC050DAC12 for ; Fri, 25 Jul 2014 04:53:38 +0530 (IST) Received: from InKolM02.tcs.com (unknown [172.18.18.104]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id A87A8DAC02 for ; Fri, 25 Jul 2014 04:53:37 +0530 (IST) MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: From: Abhijan Bhattacharyya To: core@ietf.org Message-ID: Date: Fri, 25 Jul 2014 04:53:35 +0530 X-Mailer: Lotus Domino Web Server Release 9.0.1HF198 January 23, 2014 X-MIMETrack: Serialize by Notes Server on InKolM02/TCS(Release 9.0.1HF198 | January 23, 2014) at 07/25/2014 04:53:35, Serialize complete at 07/25/2014 04:53:35, Itemize by Notes Server on InKolM02/TCS(Release 9.0.1HF198 | January 23, 2014) at 07/25/2014 04:53:35, Serialize by Notes Server on InKolM02/TCS(Release 9.0.1HF198 | January 23, 2014) at 07/25/2014 04:53:37, Serialize complete at 07/25/2014 04:53:37, Serialize by Router on InKolM02/TCS(Release 9.0.1HF198 | January 23, 2014) at 07/25/2014 04:53:37 Content-Type: multipart/alternative; boundary="=_alternative 008080A265257D1F_=" Archived-At: http://mailarchive.ietf.org/arch/msg/core/qqHw6Xc0nAP382bW5JRuJeL0Gm0 Subject: [core] Opinion on No-Response X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 24 Jul 2014 23:23:48 -0000 --=_alternative 008080A265257D1F_= MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear list, As decided in the WG meeting today, let me put this question to the mailing= list : Does the WG think that the proposal in the current form is good enough to b= e considered for adaptation by the WG? Please share your views on this. The present draft is available at:=A0 http://tools.ietf.org/html/draft-tcs-coap-no-response-option-06=A0 Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Limited Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D Notice: The information contained in this e-mail message and/or attachments to it may contain = confidential or privileged information. If you are = not the intended recipient, any dissemination, use, = review, distribution, printing or copying of the = information contained in this e-mail message = and/or attachments to it are strictly prohibited. If = you have received this communication in error, = please notify us by reply e-mail or telephone and = immediately and permanently delete the message = and any attachments. Thank you --=_alternative 008080A265257D1F_= Content-ID: <> MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear list,
As decided in the WG meeting today, let me= put this question to the mailing list :
Does the WG think that t= he proposal in the current form is good enough to be considered for adaptat= ion by the WG? Please share your views on this.
The present draft= is available at: 
http://tools.ietf.org/html/draft-tcs-coap= -no-response-option-06 

Regards
Abhijan Bhattacharyya
Assoc= iate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consul= tancy Services Limited
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
_______________________________________= _____
Experience certainty. IT Services
Business Solutions
C= onsulting
____________________________________________

= =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you

--=_alternative 008080A265257D1F_=-- From nobody Fri Jul 25 06:54:19 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47FE01B28FB for ; Fri, 25 Jul 2014 06:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0ylnrKCln1T; Fri, 25 Jul 2014 06:54:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC4E1B2913; Fri, 25 Jul 2014 06:54:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: core-chairs@tools.ietf.org, draft-ietf-core-observe@tools.ietf.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140725135408.18026.89536.idtracker@ietfa.amsl.com> Date: Fri, 25 Jul 2014 06:54:08 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/core/NkfISvB50TVTKmCjNCBYmbaOnnQ Subject: [core] ID Tracker State Update Notice: X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 13:54:18 -0000 IESG state changed to Last Call Requested from AD Evaluation::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-core-observe/ From nobody Fri Jul 25 07:03:43 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0A571B2864; Fri, 25 Jul 2014 07:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwkiV3MOiBQz; Fri, 25 Jul 2014 07:03:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0BD1B2916; Fri, 25 Jul 2014 07:02:50 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140725140250.27823.55232.idtracker@ietfa.amsl.com> Date: Fri, 25 Jul 2014 07:02:50 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/core/CsoMAJxmcwU6CUTmYFgZvaT5HvM Cc: core@ietf.org Subject: [core] Last Call: (Observing Resources in CoAP) to Proposed Standard X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@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, 25 Jul 2014 14:03:41 -0000 The IESG has received a request from the Constrained RESTful Environments WG (core) to consider the following document: - 'Observing Resources in CoAP' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-08-08. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract CoAP is a RESTful application protocol for constrained nodes and networks. The state of a resource on a CoAP server can change over time. This document specifies a simple protocol extension for CoAP that enables CoAP clients to "observe" resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time. The protocol follows a best- effort approach for sending new representations to clients and provides eventual consistency between the state observed by each client and the actual resource state at the server. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-core-observe/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-core-observe/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Jul 25 07:04:03 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56261B294E for ; Fri, 25 Jul 2014 07:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogSz-Jzdhvx4; Fri, 25 Jul 2014 07:03:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D34951B2952; Fri, 25 Jul 2014 07:02:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: core-chairs@tools.ietf.org, draft-ietf-core-observe@tools.ietf.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140725140251.27823.30947.idtracker@ietfa.amsl.com> Date: Fri, 25 Jul 2014 07:02:51 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/core/W8dxZrG-dAM0xaGHv1BBvW6Td7w Subject: [core] ID Tracker State Update Notice: X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 14:04:01 -0000 Last call has been made for draft-ietf-core-observe and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-core-observe/ From nobody Fri Jul 25 12:48:42 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC1B1A03BA; Fri, 25 Jul 2014 12:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trhNm9wvHXCK; Fri, 25 Jul 2014 12:48:37 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 607BD1A03F1; Fri, 25 Jul 2014 12:48: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.5/8.14.5) with ESMTP id s6PJmV4u019289; Fri, 25 Jul 2014 21:48:31 +0200 (CEST) Received: from dhcp-9b7d.meeting.ietf.org (dhcp-9b7d.meeting.ietf.org [31.133.155.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 19C19255; Fri, 25 Jul 2014 21:48:29 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann Date: Fri, 25 Jul 2014 15:48:27 -0400 X-Mao-Original-Outgoing-Id: 428010507.749584-ea9f71a6f2f26583158f0fdbd8863655 Content-Transfer-Encoding: quoted-printable Message-Id: <40150BD2-20E1-4D17-8AFD-2709CDF3829F@tzi.org> References: <20140725193748.19491.10472.idtracker@ietfa.amsl.com> To: "core@ietf.org WG" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/core/W1CNAC10RbzzTpp6DKYo9jiL6Ns Cc: tsv-area@ietf.org Subject: [core] Fwd: I-D Action: draft-bormann-core-cc-qq-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 25 Jul 2014 19:48:39 -0000 I wrote down some of the input on what should be examined when defining = a CoAP Advanced Congestion Control Scheme. I=92m calling the resulting = checklist the =93qualifying questions=94. Comments more than welcome. And many thanks to Richard and Carles for = helping me write this up (and Richard and Lars and the other commenters = in the WG meeting for supplying the questions in the first place). All errors are, of course, mine. Gr=FC=DFe, Carsten Begin forwarded message: > From: internet-drafts@ietf.org > Subject: I-D Action: draft-bormann-core-cc-qq-00.txt > Date: 25 Jul 2014 15:37:48 -0400 > To: i-d-announce@ietf.org > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : Qualifying Questions for a CoAP Advanced = Congestion Control Scheme > Author : Carsten Bormann > Filename : draft-bormann-core-cc-qq-00.txt > Pages : 6 > Date : 2014-07-25 >=20 > Abstract: > CoAP (RFC7252) comes with a conservative base congestion control > scheme. Advanced congestion control schemes can be defined where > better performance is desired for a certain area of application. >=20 > This document is a strawman for a set of questions that could be = used > in qualifying a CoAP advanced congestion control scheme. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-bormann-core-cc-qq/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-bormann-core-cc-qq-00 From nobody Fri Jul 25 19:18:54 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70EF91A019B for ; Fri, 25 Jul 2014 19:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.022 X-Spam-Level: * X-Spam-Status: No, score=1.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MANGLED_NAIL=2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x50B4MUV-m1m for ; Fri, 25 Jul 2014 19:18:50 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA6AB1A017E for ; Fri, 25 Jul 2014 19:18:49 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id hr17so3599511lab.2 for ; Fri, 25 Jul 2014 19:18:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=hPON2WGlQ5ATndZkVXl/xYw2NKaaHj6AYpheCIKmQYw=; b=OFJ0tfsJQZlvqeq72KBRuF5X0pToMi0+TmYeKb828yOBuhdAkogDnqdJ+HSOqi4kf8 ho4WUJfMMsOcmL88d0qorbYxTYZ/ntLPuSGlx8bvYaMORX35U/kowR2CTH/hKiESzwko 4YIFhnjf/MlkGFTlFT35uMf/y+QmPiAEINKK7SvCenUePRd+6sEGPOMFfg0/yJbWzBDD NMXcC8CUED1bLdg6itVaCfKviWMTgqgQpodZahWL8BC0cHRFoBB0kkluR4pCV5LLFjKs KSBg7GGAGhllPevWdAxeGMrac3qVr9flRMcbxB8r1X1jQCkmwyOE/ZhvqotmnBhnZKVq 0DwQ== MIME-Version: 1.0 X-Received: by 10.153.5.44 with SMTP id cj12mr20419350lad.36.1406341127986; Fri, 25 Jul 2014 19:18:47 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.46 with HTTP; Fri, 25 Jul 2014 19:18:47 -0700 (PDT) Date: Fri, 25 Jul 2014 22:18:47 -0400 X-Google-Sender-Auth: 3Vb2O2nRtaMactDpjxafAI2aKtI Message-ID: From: Barry Leiba To: draft-ietf-core-groupcomm.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/core/LrX5UNQz4zUqwBegy4viw0CnYG8 Cc: core WG Subject: [core] AD review of draft-ietf-core-groupcomm-20, part 1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 26 Jul 2014 02:18:53 -0000 I have reviewed Sections 1 and 2 of draft-ietf-core-groupcomm-20, and I have a lot of comments, so I wanted to get them to you now, while I work on the rest of the document. Please discuss these with me if you need to (and some of them specifically ask you to), and tell me that you think I'm wrong about any that you think that way about. Barry, as AD ========================== -- Section 1.3 -- The above key words are used to establish a set of guidelines for CoAP group communication. An implementation of CoAP group communication MAY implement these guidelines; an implementation claiming compliance to this document MUST implement the set of guidelines. We don't do compliance, so let's please avoid saying this sort of thing. I think you can remove that whole paragraph. If you want to keep any of it, only the first sentence is appropriate. -- Section 2.3 -- A CoAP server that is a member of a group listens for CoAP messages on the group's IP multicast address, on a specified UDP port. The default UDP port is the CoAP default port 5683 but a non-default UDP port MAY be specified for the group; in which case implementers MUST ensure that all group members are configured to use this same port. These rules imply that different ports (for the same IP multicast address) cannot be used to specify different CoAP groups. This sounds to me like rather affected and unnecessary 2119 usage. CoAP can always use a non-default port, and I don't see the point of the MAY and the MUST. Also, if the port defaults, it's because it's *not* specified, so "specified UDP port" isn't right. NEW A CoAP server that is a member of a group listens for CoAP messages on the group's IP multicast address, usually on the CoAP default UDP port, 5683. If the group uses a specified non-default UDP port, be careful to ensure that all group members are configured to use that same port. These rules imply that different ports for the same IP multicast address cannot be used to specify different CoAP groups. END 1. A pre-configured port number. The pre-configuration mechanism MUST ensure that the same port number is pre-configured across all endpoints in a group and across all CoAP clients performing the group requests. Isn't that second sentence true for cases 2 and 3 as well (without the "pre-configuration mechanism" bit)? Shouldn't it be factored out? NEW 1. A pre-configured port number. 2. If the client is configured to use service discovery including port discovery, it uses a port number obtained via a service discovery lookup operation for the targeted CoAP group. 3. Use the default CoAP UDP port (5683). For a CoAP server node that supports resource discovery, the default port 5683 MUST be supported (Section 7.1 of [RFC7252]) for the "All CoAP Nodes" group. However the port number is selected, the same port MUST be used across all endpoints in a group and across all CoAP clients performing the group requests. END (That also adds a missing ")".) The similar statement about using the same URI paths in the next numbered list should probably be similarly factored out. While I don't object to it, I don't see why you need to cite RFC 7320 here. Maybe you should explain the second list item 1 to me more. It's my understanding that the URI paths are *used* by the clients, but that they don't represent resources in the clients -- they represent resources in the servers. Is that correct? -- Section 2.4 -- Idempotent CoAP RESTful methods (i.e., GET, PUT, and DELETE) SHOULD be used for group communication, with one exception as follows. A non-idempotent CoAP method (i.e., POST) MAY be used for group communication if the resource being POSTed to has been designed to cope with the unreliable and lossy nature of IP multicast. The term "idempotent" is used only here, and you give an exhaustive list of the methods anyway. Why distract readers, rather than just focusing on the methods? Also, is that really a SHOULD there? Or have you listed the *only* exception? Remember that SHOULD is close to MUST, but gives the implementation some discretion. There's a difference between "You MUST do X except in case Q, where you do Y," and the same sentence with SHOULD (which allows the implementation to choose not do X in other cases as well). And really, I would personally word this without the 2119 language: NEW Group communication uses the CoAP methods GET, PUT, and DELETE in most cases. POST may only be used for group communication if the resource being POSTed to has been designed to cope with the unreliable and lossy nature of IP multicast. END -- Section 2.5 -- Re-using a Token value too early could lead to protocol error i.e. a wrong response/request matching in the client. Therefore the time between re-use of Token values (for Token values used in multicast requests) must be at least: I really find that awkward, mostly because of the poor use of "i.e." there. How about this?: NEW Re-using a Token value too early could lead to incorrect response/request matching in the client, which is a protocol error. Therefore the time between re-use of Token values used in multicast requests must be at least: END Using the CoAP default protocol parameters the re-use time becomes at least 250 seconds, but may need to be much longer in practice since there is no time limit defined in CoAP for generation of responses by a server. This concerns me, as it gives no reasonable upper bound as guidance. Given that the consequence of falling afoul of it is a potocol error, we really should try to scope it better. Can you provide any upper bound for the length of time, even if it comes with some warning? -- Section 2.6 -- CoAP Groups, and the membership of these groups, can be discovered via the lookup interfaces in the Resource Directory (RD) defined in [I-D.ietf-core-resource-directory]. Given this statement and the second case in 2.7.1, I don't see how that document is not a normative reference. Can you explain your thinking about that? Or can you re-word this so it's clearer that the Resource Directory document is optional reading, and doesn't need to be understood here? -- Section 2.7.2 -- To access this interface a client MUST use unicast CoAP methods (GET/PUT/POST/DELETE) only as it is a method of configuring group information in individual endpoints. I had trouble parsing this and understanding it, until I realized that you need a comma after "only". Also, a form of authorization (making use of DTLS-secured CoAP [RFC7252]) SHOULD be used such that only authorized controllers are allowed by an endpoint to configure its group membership. Authorization SHOULD be used? "SHOULD", really, not "MUST"? How is this not "MUST"? These alternate approaches may support Nit: "alternative" is the correct word here. -- Section 2.7.2.1 -- The resource includes zero or more group membership JSON objects You should add a normative reference to RFC 7159 for JSON. group membership JSON object contains one or more key/value pairs as defined below. Your "key/value pairs" are actually JSON object members, where the member name is they key and the member value is the value. It would probably be better to explain that explicitly, because JSON has no concept of "key/value pairs" by that name. Perhaps this works: NEW A group membership JSON object contains one or more key/value pairs as defined below, and represents a single IP multicast group membership for the CoAP endpoint. Each key/value pair is encoded as a member of the JSON object, where the key is the member name and the value is the member's value. END The following ABNF rule can be used for parsing the address, referring to the definitions in Section 6 of [RFC7252] and [RFC3986]. It's hard to tell what the scope of "Section 6" is. Ty this: NEW The following ABNF rule can be used for parsing the address, referring to the definitions in Section 6 of [RFC7252] and Section 3.2.2 of [RFC3986]. END But what definition in 7252 are you referring to? I don't see one. In a response, the "a" key/value pair SHOULD be included if the IP address is known at the time of generating the response, and MUST NOT be included if unknown. If the "a" value is not provided in a request, the "n" value in the same group membership object SHOULD be a valid hostname with optional port number that can be translated to an IP multicast address via DNS More 2119 follies... The first SHOULD: Why is it a SHOULD? What happens to the protocol if you don't? The MUST NOT: Really? How *would* you include it if it's unknown? The second SHOULD: This is very clearly a MUST, according to the following paragraph (if you don't have an "a", you MUST have an "n"). In addition: I suggest that you move the "at least one of" sentence to the beginning of this paragraph (and change "group object" to "group membership object" for consistency). I also think it's important for you to explain what happens when both "a" and "n" are included. And I don't think you have to have the sentence about the default port number twice. -- Section 2.7.2.2 -- index - Group index, SHOULD be a string of 1 or 2 alphanumerical characters. It MUST be generated as locally unique. What is the scope of "locally"? Unique on the server? Unique in the group? Something else? 1 or 2 alphanumeric characters: (we don't usually put "al" at the end) What characters are valid? In what character set? Do you mean ASCII alphanumeric characters? If so, please say that. Are they case-sensitive (are "a1" and "A1" the same, or different)? Why is this a SHOULD? What happens if it's not 1 or 2 alphanumeric characters? How does a locally unique two-character string scale? Even if we're talking about case-sensitive ASCII, that still seems to limit you to 3844 unique strings. Is that enough? For the 'gp' variable it is recommended to use the path "coap-group" by default. If the "a" key/value pair is given, this takes priority and the "n" pair becomes informational. What does it mean for it to be informational? What should the server do with it? If only the "n" pair is given, the CoAP endpoint may perform DNS resolution (if supported) to obtain the IP multicast address from the hostname. What can it do other than performing DNS resolution? What happens if DNS resolution isn't supported? -- Sction 2.7.2.4 -- A (unicast) GET on the CoAP-group resource returns a JSON object containing multiple keys and values, the keys being group indices and the values the corresponding group objects. Each group object is a group membership JSON object that indicates one IP multicast group membership. Again, let's be clear how the keys and values map to JSON. Let's also fix terminilogy consistency, "group objects" -> "group membership objects", and as the term has been defined before, you don't have to do it again: NEW A (unicast) GET on the CoAP-group resource returns a JSON object containing multiple keys and values. The keys (member names) are group indices and the values (member values) are the corresponding group membership objects. Each group membership object describes one IP multicast group membership. END URI Template Variables: gp - see earlier definition I think it would be better to point to exactly where the earlier definition is. Happily, xml2rfc makes that easy, with an element (and make similar changes below, in sections 2.7.2.5, .6, and .7). NEW URI Template Variables: gp - see definition in Section 2.7.2.2 END Note: the returned IPv6 address may be a different string from the one originally submitted in group membership creation, due to different choices in IPv6 string representation formatting that may be allowed for the same address (see [RFC5952]). I think it would help to be explicit, just to avoid any confusion, that even though it might not be the same character string, it represents the same IPv6 address. Maybe this: NEW Note: the returned IPv6 address string will represent the same IPv6 address that was originally submitted in group membership creation, though it might be a different string because of different choices in IPv6 string representation formatting that may be allowed for the same address (see [RFC5952]). END What happens if the requested index doesn't exist? Do you get an error? Or do you get the empty JSON object? (Same question for Section 2.7.2.5.) -- Section 2.7.2.5 -- Just a comment, to take or leave as you see fit (no need to respond): It seems to me that there might be an advantage in having both GET methods return the same structure, so they can be parsed the same way. If you did that, the example in this section would read this way: Example: Req: GET /coap-group/12 Res: 2.05 Content Content-Format: application/coap-group+json { "12" :{"n": "All-Devices.floor1.west.bldg6.example.com", "a": "[ff15::4200:f7fe:ed37:abcd]:4567"} } -- Section 2.7.2.6 -- This operation SHOULD only be used to delete or update group membership objects for which the CoAP client, invoking this operation, is responsible. The responsibility is based on application level knowledge. Again: Why "SHOULD"? When it is safe to ignore the SHOULD? What happens if I ignore it? And: Are there no access controls here? Isn't an entity that shouldn't be fiddling with group membership *prevented* from doing so? Or could a faulty (or malicious) device or tool really clear out all the group memberships? Example: (replacing all existing group memberships with two new groups) Two new *groups*? Or two new *members*? I'm also confused here: When I use POST to create a group membership, the server returns the index -- the server tells the client the index. In this case, the client selects the indicies. Is that really what you want? And if so, are there any constraints on that? In the example, you show them as sequential numbers starting at 1. If they can be arbitrary, it might be better to change the example to make them, say "QX" and "5", just to be clear that it doesn't matter. -- Section 2.8 -- For IP multicast request acceptance, the REQUIRED behaviors are: I don't understand how "REQUIRED" applies when the first three items say "SHOULD NOT". Please explain what you mean here, from a protocol requirements point of view, so we can figure out how you should really say it. The same goes for the next list in this section, though that's probably even worse, because you say that the sever MAY choose not to respond, and then you say the server responds. That seems like bad 2119 usage. For the part about response configuration options, why is that a 2119 "SHOULD"? How does it affect protocol interoperability? My guess is that all this will be better said without trying to cram 2119 key words into it, but let's first understand your intent. Note that in this case the client implements a "reliable group communication" (as defined in Section 1.3) function using additional, non- standardized functions above the CoAP layer. I'm not sure what this means (so maybe you can explain it to me), but I'll point out that *this* protocol (groupcomm) is non-standardized as well. -- Section 2.9 -- o A response to an IP multicast request SHOULD be Non-confirmable (Section 5.2.3 of [RFC7252]). I take from the reference to Sec 5.2.3 that what you're really saying here is that responses follow the normal CoAP rules, and you're not giving advice that differs from that at all. Do you mean otherwise? You should probably say that, as, "As is usual with Non-confirmable requests, a response to...." o A server does not respond immediately to an IP multicast request, but SHOULD first wait for a time that is randomly picked within a predetermined time interval called the Leisure. Unfortunately, in English, "but" has two different meanings: contradiction (as Spanish "pero") and alternative (as Spanish "sino"). You mean the Spanish "sino" here, but it will likely be read as the Spanish "pero" (sorry to refer to Spanish, but this is hard to explain). I suggest changing "but" to "and" or "but rather", to make the sense clear (I prefer "and"). o A server in an LLN should only support group communication GET for resources that are small. For example, the payload of the response is limited to approximately 5% of the IP Maximum Transmit Unit (MTU) size so it fits into a single link-layer frame in case 6LoWPAN [RFC4944] is used. What's the purpose of the 6LoWPAN reference? If it's to talk about the MTU, then 4944 is a fine reference, but I would give a section reference to make it clear: "in case 6LoWPAN is used (see Section 4 of [RFC4944])." But if the purpose is to have a more general explanation of what 6LoWPAN is, I think RFC 4919 is a better reference for this case. Up to you; I just wanted to raise the question. o A server can also minimize the payload length of a response to a group communication GET (e.g., on "/.well-known/core") using CoAP blockwise transfers [I-D.ietf-core-block], returning only a first block of the CoRE Link Format description. For this reason, a CoAP client sending an IP multicast CoAP request to "/.well-known/ core" SHOULD support core-block. I believe the "SHOULD support" makes core-block a normative reference. More guidelines specific to use of CoAP in 6LoWPAN networks [RFC4944] are given in Section 4.5. I'm pretty certain that for this reference, 4919 is better than 4944. -- Section 2.10 -- Due to above issues, a guideline is defined here that a CoAP Proxy SHOULD NOT support processing an IP multicast CoAP request but rather return a 501 (Not Implemented) response in such case. The exception case here (i.e., to process it) is allowed under following conditions: It's not clear whether *all* of the following conditions must be met, or whether *any* of the following conditions must be met. ========================== From nobody Sat Jul 26 09:49:49 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 919DC1A0332 for ; Sat, 26 Jul 2014 09:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hfo3QgQoFAvk for ; Sat, 26 Jul 2014 09:49:47 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 491C21A02F3 for ; Sat, 26 Jul 2014 09:49:47 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id el20so4035127lab.38 for ; Sat, 26 Jul 2014 09:49:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=bdabb/5EIhWiCPsuRl278f6VFwTb9fSZcCFs0Io0PBw=; b=hUdjJ+r9mGQVe2xUhof42gD4UMjPyNwlQpzabLxQWK1n5yrv7ltv+zMg+6A/chOv/k 72Y838K+HTrrBiTvJr0p8x6NT7ZEOg2qem8mFZ+ninX+YuB6Y/cvx33idkqpkpqO9DiI XKD9LOBVz/lj2c3i7yHboV201I9sk/mbz3Il+QkRg0xESGMzvHTo942+kfm+O5D2TYg9 GVEpCg+Rn6//auPouEnc9Z3Ho+MDiM/RnHmDVhDe9iYYLM9NtSBbQ2ng+5cS4izmAV9L vDb22i5mA/R9r+jUAfH++YjmRcfKwGE1Y+jWvAfKYJv7QGyISR49kyZyHr5/6pHvfbaq +5Bg== MIME-Version: 1.0 X-Received: by 10.152.36.135 with SMTP id q7mr19372304laj.42.1406393385397; Sat, 26 Jul 2014 09:49:45 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.46 with HTTP; Sat, 26 Jul 2014 09:49:45 -0700 (PDT) Date: Sat, 26 Jul 2014 12:49:45 -0400 X-Google-Sender-Auth: gRBY_FrPw9-9k0fKxZyKoKvg6MA Message-ID: From: Barry Leiba To: draft-ietf-core-groupcomm.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/core/JQKQQQ7h9PaZ6Lhz5Qd7kp-XbI8 Cc: core WG Subject: [core] AD review of draft-ietf-core-groupcomm-20, part 2 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 26 Jul 2014 16:49:48 -0000 And here's the rest of my review, Section 3 and beyond. As with the others, please discuss these with me if you need to, and tell me that you think I'm wrong about any that you think that way about. I'm going to put the document into "Revised I-D Needed" substate while you work on addressing these reviews. Barry, as AD ========================== General: The RFC Editor will probably get this, but as long as you're making changes, note that correct use of "for example" and "e.g." has them set off by commas. Wherever you have "xxx, for example due to yyy", it should be "xxx, due, for example, to yyy". -- Section 3.2 -- o A large room (Room-A) with three lights (Light-1, Light-2, Light- 3) controlled by a Light Switch. The devices are organized into two subnets. In reality, there could be more lights (up to several hundreds) but these are not shown for clarity. Nit: make it, "but, for clarity, only three are shown." -- Section 3.4 -- Nit: I would make items 3 and 4 in the numbered list be 3a and 3b, to make it clearer that the second is an alternative to the first. -- Section 3.6 -- In our particular use case, a group of three lights is defined with one IP multicast address and hostname "Room- A-Lights.floor1.west.bldg6.example.com". The commissioning tool has The FQDN should not be split on multiple lines. If you use xml2rfc, I suggest coding it this way, to put it on a line by itself, indented: Room-A-Lights.floor1.west.bldg6.example.com -- Section 4.3 -- It requires the RPL Mode of Operation (MOP) to be 3 (Storing Mode with multicast Nit: As this is the only place you use MOP, there's no reason to abbreviate it. On the other hand, you do need to expand DAO on first use. -- Section 4.4 -- 2. Manual configuration of edge router(s) as MPL Seed(s) for specific IP multicast traffic. E.g. in above example, first configure Rtr-1 and Rtr-2 to act as MLD Address Listeners for the Room-A-Lights IP multicast group. "E.g. in above example" is awkward (and you have that in another paragraph, too). Also, the paragraph is complicated. I think it would be clearer this way: NEW 2. Manual configuration of edge router(s) as MPL Seed(s) for specific IP multicast traffic. In the above example, this could be done through the following three steps: First, configure Rtr-1 and Rtr-2 to act as MLD Address Listeners for the Room-A-Lights IP multicast group. END -- Section 5 -- I really think the security aspects of this are horrid, and it's not clear to me that this should be advanced, especially not at Proposed Standard, as long as that's the case. With questionable authentication, questionable confidentiality, and apparently no access control, I don't know that we should be proposing it now. But is the working group has consensus on doing so, I will send it to the community and the IESG. Were I you, I'd expect to get lambasted in the SecDir review and by the Sec ADs. Just a warning. -- Section 6.2 -- The registration template changed in RFC 6838; please make sure your filled-in template is aligned with that version. ========================== From nobody Sat Jul 26 09:50:58 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A535C1B2854 for ; Sat, 26 Jul 2014 09:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIvXNscSqy20; Sat, 26 Jul 2014 09:50:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 55D8C1B2858; Sat, 26 Jul 2014 09:50:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: core-chairs@tools.ietf.org, draft-ietf-core-groupcomm@tools.ietf.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140726165054.25055.19372.idtracker@ietfa.amsl.com> Date: Sat, 26 Jul 2014 09:50:54 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/core/wMs0urRVL4EtCig0Vs91tbnEb5s Subject: [core] ID Tracker State Update Notice: X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 16:50:57 -0000 IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation Revised I-D needed to address AD review comments. ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ From nobody Sat Jul 26 22:48:41 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A47531A0073 for ; Sat, 26 Jul 2014 22:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.099 X-Spam-Level: *** X-Spam-Status: No, score=3.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MANGLED_NAIL=2.3, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L305v6cUI4Yh for ; Sat, 26 Jul 2014 22:48:33 -0700 (PDT) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 151BB1A0068 for ; Sat, 26 Jul 2014 22:48:33 -0700 (PDT) X-ASG-Debug-ID: 1406440107-06daaa3f0027bc0001-aa7cYp Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id lcPk6VgC0EKkfBvZ for ; Sun, 27 Jul 2014 01:48:27 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 27 Jul 2014 01:48:26 -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: Sun, 27 Jul 2014 01:48:07 -0400 X-ASG-Orig-Subj: RE: [core] AD review of draft-ietf-core-groupcomm-20, part 1 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] AD review of draft-ietf-core-groupcomm-20, part 1 Thread-Index: Ac+od/SV7nLOY00RRp6AQ9l5wjUMRgAov7xw References: From: "Rahman, Akbar" To: "Barry Leiba" X-OriginalArrivalTime: 27 Jul 2014 05:48:26.0000 (UTC) FILETIME=[62677100:01CFA95E] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1406440107 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.7855 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Archived-At: http://mailarchive.ietf.org/arch/msg/core/26QHNx8em7_jwAkyOePnamf5ZcY Cc: draft-ietf-core-groupcomm.all@tools.ietf.org, core WG Subject: Re: [core] AD review of draft-ietf-core-groupcomm-20, part 1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 27 Jul 2014 05:48:36 -0000 Hi Barry, 1) First, thank you very much for your thorough review. I agree with many of your suggestions. I have given point by point feedback inline below (identified by: **[Akbar-x]). =20 2) Can you please specifically look and respond to the proposals in:=20 [Akbar-5], [Akbar-6], [Akbar-10], [Akbar-11], [Akbar-16], [Akbar-17], [Akbar-24], [Akbar-25], [Akbar-26], [Akbar-32], [Akbar-34], [Akbar-35], [Akbar-36] and [Akbar-39]. 3) We will do a fast update of the draft once we have agreement with you on all your comments in this and your second email. Best Regards, Akbar -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Barry Leiba Sent: Friday, July 25, 2014 10:19 PM To: draft-ietf-core-groupcomm.all@tools.ietf.org Cc: core WG Subject: [core] AD review of draft-ietf-core-groupcomm-20, part 1 I have reviewed Sections 1 and 2 of draft-ietf-core-groupcomm-20, and I have a lot of comments, so I wanted to get them to you now, while I work on the rest of the document. Please discuss these with me if you need to (and some of them specifically ask you to), and tell me that you think I'm wrong about any that you think that way about. Barry, as AD =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D -- Section 1.3 -- The above key words are used to establish a set of guidelines for CoAP group communication. An implementation of CoAP group communication MAY implement these guidelines; an implementation claiming compliance to this document MUST implement the set of guidelines. We don't do compliance, so let's please avoid saying this sort of thing. I think you can remove that whole paragraph. If you want to keep any of it, only the first sentence is appropriate. **[Akbar-1] - Ok. Then it is probably cleanest to just delete the whole paragraph as the preceding RFC2119 paragraph is the standard requirements terminology. -- Section 2.3 -- A CoAP server that is a member of a group listens for CoAP messages on the group's IP multicast address, on a specified UDP port. The default UDP port is the CoAP default port 5683 but a non-default UDP port MAY be specified for the group; in which case implementers MUST ensure that all group members are configured to use this same port. These rules imply that different ports (for the same IP multicast address) cannot be used to specify different CoAP groups. This sounds to me like rather affected and unnecessary 2119 usage. CoAP can always use a non-default port, and I don't see the point of the MAY and the MUST. Also, if the port defaults, it's because it's *not* specified, so "specified UDP port" isn't right. NEW A CoAP server that is a member of a group listens for CoAP messages on the group's IP multicast address, usually on the CoAP default UDP port, 5683. If the group uses a specified non-default UDP port, be careful to ensure that all group members are configured to use that same port. These rules imply that different ports for the same IP multicast address cannot be used to specify different CoAP groups. END **[Akbar-2] - Ok. Your re-wording definitely captures our original intent. I am fine with it if you think that the RFC2119 usage is not necessary. We will update as you suggested. 1. A pre-configured port number. The pre-configuration mechanism MUST ensure that the same port number is pre-configured across all endpoints in a group and across all CoAP clients performing the group requests. Isn't that second sentence true for cases 2 and 3 as well (without the "pre-configuration mechanism" bit)? Shouldn't it be factored out? NEW 1. A pre-configured port number. 2. If the client is configured to use service discovery including port discovery, it uses a port number obtained via a service discovery lookup operation for the targeted CoAP group. 3. Use the default CoAP UDP port (5683). For a CoAP server node that supports resource discovery, the default port 5683 MUST be supported (Section 7.1 of [RFC7252]) for the "All CoAP Nodes" group. However the port number is selected, the same port MUST be used across all endpoints in a group and across all CoAP clients performing the group requests. END (That also adds a missing ")".) **[Akbar-3] - Ok. Our original thinking was that case 2 was slightly different as the assumption was that all clients would use the same service discovery mechanism so that the "pre-configuration mechanism" would be enforced in a slightly different way. But if we remove that term, then your proposal is good. We will update as you suggested. The similar statement about using the same URI paths in the next numbered list should probably be similarly factored out. **[Akbar-4] - Ok. We will update as you suggested. While I don't object to it, I don't see why you need to cite RFC 7320 here. Maybe you should explain the second list item 1 to me more. It's my understanding that the URI paths are *used* by the clients, but that they don't represent resources in the clients -- they represent resources in the servers. Is that correct? **[Akbar-5] - Yes, the URIs (authority/path) represent resources in the servers (and not the sending client). The RFC7320 reference was added because at one time we had discussions in the WG regarding if we should hardcode a path name for group communications. Meaning that we should take the "/.well-known/core" idea for discovery and try to hardcode something similar for group communications (e.g. "/groupcomm/core" or "/core/groupcomm"). However, RFC7320 (http://tools.ietf.org/html/rfc7320#section-2.3) specifically advises against this approach. So, we would prefer to leave the RFC7320 reference in (and point it to specifically section 2.3 if that helps clarify). Is that ok with you? -- Section 2.4 -- Idempotent CoAP RESTful methods (i.e., GET, PUT, and DELETE) SHOULD be used for group communication, with one exception as follows. A non-idempotent CoAP method (i.e., POST) MAY be used for group communication if the resource being POSTed to has been designed to cope with the unreliable and lossy nature of IP multicast. The term "idempotent" is used only here, and you give an exhaustive list of the methods anyway. Why distract readers, rather than just focusing on the methods? =20 **[Akbar-6] - The term "idempotent" is clearly defined in RFC7252 (http://tools.ietf.org/html/rfc7252#section-5.1), and is an important concept in REST in general. So we wanted to use the term because it helps draws the reader's attention to the potential complications of using group communications for non-idempotent methods. So we would prefer to leave the term there. Is that ok with you? Also, is that really a SHOULD there? Or have you listed the *only* exception? Remember that SHOULD is close to MUST, but gives the implementation some discretion. There's a difference between "You MUST do X except in case Q, where you do Y," and the same sentence with SHOULD (which allows the implementation to choose not do X in other cases as well). And really, I would personally word this without the 2119 language: NEW Group communication uses the CoAP methods GET, PUT, and DELETE in most cases. POST may only be used for group communication if the resource being POSTed to has been designed to cope with the unreliable and lossy nature of IP multicast. END **[Akbar-7] - I am okay with this (i.e. in removing the RFC2119 language). We will update as you suggested. (Note that the text may change based on how you answer [Akbar-6] above). -- Section 2.5 -- Re-using a Token value too early could lead to protocol error i.e. a wrong response/request matching in the client. Therefore the time between re-use of Token values (for Token values used in multicast requests) must be at least: I really find that awkward, mostly because of the poor use of "i.e." there. How about this?: NEW Re-using a Token value too early could lead to incorrect response/request matching in the client, which is a protocol error. Therefore the time between re-use of Token values used in multicast requests must be at least: END **[Akbar-8] - Ok. We will update as you suggested. Using the CoAP default protocol parameters the re-use time becomes at least 250 seconds, but may need to be much longer in practice since there is no time limit defined in CoAP for generation of responses by a server. This concerns me, as it gives no reasonable upper bound as guidance. Given that the consequence of falling afoul of it is a potocol error, we really should try to scope it better. Can you provide any upper bound for the length of time, even if it comes with some warning? **[Akbar-9] - Okay. We will think about an upper bound number and add it to the draft. -- Section 2.6 -- CoAP Groups, and the membership of these groups, can be discovered via the lookup interfaces in the Resource Directory (RD) defined in [I-D.ietf-core-resource-directory]. Given this statement and the second case in 2.7.1, I don't see how that document is not a normative reference. Can you explain your thinking about that? Or can you re-word this so it's clearer that the Resource Directory document is optional reading, and doesn't need to be understood here? **[Akbar-10] - The main reason that we do not think that the core-resource-directory is normative is because you can build and run a system implementing CoAP group communications without a resource directory (RD) endpoint in the system. So the RD concept is useful (and complementary) but not mandatory for implementing group communications. For example, to implement the functionality in the rest of section 2.7.2 does not require an RD at all (i.e. the reference to RD in section 2.7.1 was purely for background). So I would prefer to leave the document informative. Is that okay with you? -- Section 2.7.2 -- To access this interface a client MUST use unicast CoAP methods (GET/PUT/POST/DELETE) only as it is a method of configuring group information in individual endpoints. I had trouble parsing this and understanding it, until I realized that you need a comma after "only". **[Akbar-11] - How about rephrasing as follows to make it more readable: NEW To access this interface a client MUST use unicast CoAP methods (GET/PUT/POST/DELETE).=20 This interface is a method of configuring group information in individual endpoints. END Also, a form of authorization (making use of DTLS-secured CoAP [RFC7252]) SHOULD be used such that only authorized controllers are allowed by an endpoint to configure its group membership. Authorization SHOULD be used? "SHOULD", really, not "MUST"? How is this not "MUST"? **[Akbar-12] - Ok. We will update as you suggested. These alternate approaches may support Nit: "alternative" is the correct word here. **[Akbar-13] -Ok. We will update as you suggested. -- Section 2.7.2.1 -- The resource includes zero or more group membership JSON objects You should add a normative reference to RFC 7159 for JSON. **[Akbar-14] - Ok. We will update as you suggested. group membership JSON object contains one or more key/value pairs as defined below. Your "key/value pairs" are actually JSON object members, where the member name is they key and the member value is the value. It would probably be better to explain that explicitly, because JSON has no concept of "key/value pairs" by that name. Perhaps this works: NEW A group membership JSON object contains one or more key/value pairs as defined below, and represents a single IP multicast group membership for the CoAP endpoint. Each key/value pair is encoded as a member of the JSON object, where the key is the member name and the value is the member's value. END **[Akbar-15] - Ok. We will update as you suggested. The following ABNF rule can be used for parsing the address, referring to the definitions in Section 6 of [RFC7252] and [RFC3986]. It's hard to tell what the scope of "Section 6" is. Ty this: NEW The following ABNF rule can be used for parsing the address, referring to the definitions in Section 6 of [RFC7252] and Section 3.2.2 of [RFC3986]. END But what definition in 7252 are you referring to? I don't see one. **[Akbar-16] - Ok. We will update as you suggested. The definition in 7252 that we were referring to was in the second paragraph of section 6. Do you agree? In a response, the "a" key/value pair SHOULD be included if the IP address is known at the time of generating the response, and MUST NOT be included if unknown. If the "a" value is not provided in a request, the "n" value in the same group membership object SHOULD be a valid hostname with optional port number that can be translated to an IP multicast address via DNS More 2119 follies... The first SHOULD: Why is it a SHOULD? What happens to the protocol if you don't? **[Akbar-17] - The "a" is optional. So that is why it is stated that it SHOULD be returned if known. It cannot be a MUST because it may not be there as it is optional. Is that clear The MUST NOT: Really? How *would* you include it if it's unknown? **[Akbar-18] - Ok. Will just delete the phrase "... and MUST NOT be included if unknown" as it is not required. The second SHOULD: This is very clearly a MUST, according to the following paragraph (if you don't have an "a", you MUST have an "n"). **[Akbar-19] - Ok. We will update as you suggested. In addition: I suggest that you move the "at least one of" sentence to the beginning of this paragraph (and change "group object" to "group membership object" for consistency). I also think it's important for you to explain what happens when both "a" and "n" are included. And I don't think you have to have the sentence about the default port number twice. **[Akbar-20] - Ok. We will update as you suggested. -- Section 2.7.2.2 -- index - Group index, SHOULD be a string of 1 or 2 alphanumerical characters. It MUST be generated as locally unique. What is the scope of "locally"? Unique on the server? Unique in the group? Something else? **[Akbar-21] - Locally means unique to the server. We will clarify to: "It MUST be generated as locally unique to the server". 1 or 2 alphanumeric characters: (we don't usually put "al" at the end) What characters are valid? In what character set? Do you mean ASCII alphanumeric characters? If so, please say that. Are they case-sensitive (are "a1" and "A1" the same, or different)? **[Akbar-22] -Yes, we meant case insensitive ASCII alphanumeric characters. We will update to clarify. Why is this a SHOULD? What happens if it's not 1 or 2 alphanumeric characters? **[Akbar-23] -We can make it a MUST. How does a locally unique two-character string scale? Even if we're talking about case-sensitive ASCII, that still seems to limit you to 3844 unique strings. Is that enough? **[Akbar-24] -It is representing the number of IP multicast groups that the endpoint is taking part in. Practically this should be in the order of a few tens of groups at most. So 3844 should be more than enough. For the 'gp' variable it is recommended to use the path "coap-group" by default. If the "a" key/value pair is given, this takes priority and the "n" pair becomes informational. What does it mean for it to be informational? What should the server do with it? **[Akbar-25] -In effect, it means that the "n" can be ignored. Should we say that instead of saying it becomes informational? (This is because if the IP address ("a") is given, then the name ("n") becomes unnecessary.) If only the "n" pair is given, the CoAP endpoint may perform DNS resolution (if supported) to obtain the IP multicast address from the hostname. What can it do other than performing DNS resolution? What happens if DNS resolution isn't supported? **[Akbar-26] - If DNS resolution of a multicast name is not supported then nothing else can be done. We used the "if supported" phrase throughout as there is not guarantee that there is even a DNS infrastructure setup in many constrained networks (e.g. in a building lighting scenario). We will explicitly state this assumption in the text for clarity. -- Sction 2.7.2.4 -- A (unicast) GET on the CoAP-group resource returns a JSON object containing multiple keys and values, the keys being group indices and the values the corresponding group objects. Each group object is a group membership JSON object that indicates one IP multicast group membership. Again, let's be clear how the keys and values map to JSON. Let's also fix terminilogy consistency, "group objects" -> "group membership objects", and as the term has been defined before, you don't have to do it again: NEW A (unicast) GET on the CoAP-group resource returns a JSON object containing multiple keys and values. The keys (member names) are group indices and the values (member values) are the corresponding group membership objects. Each group membership object describes one IP multicast group membership. END **[Akbar-27] -Ok. Will update as you suggested. URI Template Variables: gp - see earlier definition I think it would be better to point to exactly where the earlier definition is. Happily, xml2rfc makes that easy, with an element (and make similar changes below, in sections 2.7.2.5, .6, and .7). NEW URI Template Variables: gp - see definition in Section 2.7.2.2=20 END **[Akbar-28] -Ok. Will update as you suggested. Note: the returned IPv6 address may be a different string from the one originally submitted in group membership creation, due to different choices in IPv6 string representation formatting that may be allowed for the same address (see [RFC5952]). I think it would help to be explicit, just to avoid any confusion, that even though it might not be the same character string, it represents the same IPv6 address. Maybe this: NEW Note: the returned IPv6 address string will represent the same IPv6 address that was originally submitted in group membership creation, though it might be a different string because of different choices in IPv6 string representation formatting that may be allowed for the same address (see [RFC5952]). END **[Akbar-29] -Ok. Will update as you suggested. What happens if the requested index doesn't exist? Do you get an error? Or do you get the empty JSON object? (Same question for Section 2.7.2.5.) **[Akbar-30] -Probably best to return an empty JSON object. We can clarify this in the text. -- Section 2.7.2.5 -- Just a comment, to take or leave as you see fit (no need to respond): It seems to me that there might be an advantage in having both GET methods return the same structure, so they can be parsed the same way. If you did that, the example in this section would read this way: Example: Req: GET /coap-group/12 Res: 2.05 Content Content-Format: application/coap-group+json { "12" :{"n": "All-Devices.floor1.west.bldg6.example.com", "a": "[ff15::4200:f7fe:ed37:abcd]:4567"} } **[Akbar-31] -Ok. This is a good idea. Will update as you suggested. -- Section 2.7.2.6 -- This operation SHOULD only be used to delete or update group membership objects for which the CoAP client, invoking this operation, is responsible. The responsibility is based on application level knowledge. Again: Why "SHOULD"? When it is safe to ignore the SHOULD? What happens if I ignore it? And: Are there no access controls here? Isn't an entity that shouldn't be fiddling with group membership *prevented* from doing so? Or could a faulty (or malicious) device or tool really clear out all the group memberships? **[Akbar-32] -First, as per reply [Akbar-12] the transaction will be DTLS protected. Secondly, we can change the "SHOULD" to "MUST" to make it mandatory. Example: (replacing all existing group memberships with two new groups) Two new *groups*? Or two new *members*? **[Akbar-33] - We can clarify to two new "group memberships". I'm also confused here: When I use POST to create a group membership, the server returns the index -- the server tells the client the index. In this case, the client selects the indicies. Is that really what you want? And if so, are there any constraints on that? In the example, you show them as sequential numbers starting at 1. If they can be arbitrary, it might be better to change the example to make them, say "QX" and "5", just to be clear that it doesn't matter. **[Akbar-34] -We used the given approach just to keep everything simple. As we discussed in reply [Akbar-21], the index is unique to the server. We can change the example to make non-sequential index numbers as you suggest. -- Section 2.8 -- For IP multicast request acceptance, the REQUIRED behaviors are: I don't understand how "REQUIRED" applies when the first three items say "SHOULD NOT". Please explain what you mean here, from a protocol requirements point of view, so we can figure out how you should really say it. The same goes for the next list in this section, though that's probably even worse, because you say that the sever MAY choose not to respond, and then you say the server responds. That seems like bad 2119 usage. For the part about response configuration options, why is that a 2119 "SHOULD"? How does it affect protocol interoperability? My guess is that all this will be better said without trying to cram 2119 key words into it, but let's first understand your intent. Note that in this case the client implements a "reliable group communication" (as defined in Section 1.3) function using additional, non- standardized functions above the CoAP layer. I'm not sure what this means (so maybe you can explain it to me), but I'll point out that *this* protocol (groupcomm) is non-standardized as well. **[Akbar-35] - Please first note that this document (groupcomm) is Informational. As we stated in section 1.2 (Scope), the normative aspects of group communications is specified in RFC7252 (e.g. http://tools.ietf.org/html/rfc7252#section-8 and some of the congestion control guidance scattered elsewhere in RFC7252). The intent of this groupcomm draft is just to explain/illustrate the normative rules of RFC7252 which is fairly terse and sometimes a bit hard to understand without a lot of background knowledge. Assuming that you agree with this, perhaps the best resolution will be to remove RFC2119 language from this section. Do you agree? We just wanted to recap all the request acceptance and response suppression rules in one place to make for a quick summary read for implementers). -- Section 2.9 -- o A response to an IP multicast request SHOULD be Non-confirmable (Section 5.2.3 of [RFC7252]). I take from the reference to Sec 5.2.3 that what you're really saying here is that responses follow the normal CoAP rules, and you're not giving advice that differs from that at all. Do you mean otherwise? You should probably say that, as, "As is usual with Non-confirmable requests, a response to...." **[Akbar-36] - Yes, we are not differing from normal CoAP rules anywhere in this document in fact. That is why the document is Informational. The only really "new" functionality we are introducing is in section 2.7.2 (Membership Configuration RESTful Interface). This functionality for setting the group membership is not covered in any other CoAP document. Can you please confirm that an Informational document can define the functionality included in section 2.7.2. We have brought this up in the WG several times and the answer was always positive. But we would like to ask you again. o A server does not respond immediately to an IP multicast request, but SHOULD first wait for a time that is randomly picked within a predetermined time interval called the Leisure. Unfortunately, in English, "but" has two different meanings: contradiction (as Spanish "pero") and alternative (as Spanish "sino"). You mean the Spanish "sino" here, but it will likely be read as the Spanish "pero" (sorry to refer to Spanish, but this is hard to explain). I suggest changing "but" to "and" or "but rather", to make the sense clear (I prefer "and"). **[Akbar-37] - Ok. Will do as you suggest. (If you used French examples it would have been easier for me to follow!). o A server in an LLN should only support group communication GET for resources that are small. For example, the payload of the response is limited to approximately 5% of the IP Maximum Transmit Unit (MTU) size so it fits into a single link-layer frame in case 6LoWPAN [RFC4944] is used. What's the purpose of the 6LoWPAN reference? If it's to talk about the MTU, then 4944 is a fine reference, but I would give a section reference to make it clear: "in case 6LoWPAN is used (see Section 4 of [RFC4944])." But if the purpose is to have a more general explanation of what 6LoWPAN is, I think RFC 4919 is a better reference for this case. Up to you; I just wanted to raise the question. **[Akbar-38] - The main reason was to talk about MTU. We can add the section reference as you suggested. o A server can also minimize the payload length of a response to a group communication GET (e.g., on "/.well-known/core") using CoAP blockwise transfers [I-D.ietf-core-block], returning only a first block of the CoRE Link Format description. For this reason, a CoAP client sending an IP multicast CoAP request to "/.well-known/ core" SHOULD support core-block. I believe the "SHOULD support" makes core-block a normative reference. **[Akbar-39] - Since that was not our intent, we will change the text to use non-RFC2119 language. More guidelines specific to use of CoAP in 6LoWPAN networks [RFC4944] are given in Section 4.5. I'm pretty certain that for this reference, 4919 is better than 4944. **[Akbar-40] - Ok. Will change as you suggested. -- Section 2.10 -- Due to above issues, a guideline is defined here that a CoAP Proxy SHOULD NOT support processing an IP multicast CoAP request but rather return a 501 (Not Implemented) response in such case. The exception case here (i.e., to process it) is allowed under following conditions: It's not clear whether *all* of the following conditions must be met, or whether *any* of the following conditions must be met. **[Akbar-41] - Should be "all" the conditions. We will clarify the text to reflect this. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Sat Jul 26 23:12:51 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5711A00A9 for ; Sat, 26 Jul 2014 23:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h_J_6Gx-JSzw for ; Sat, 26 Jul 2014 23:12:46 -0700 (PDT) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 434A81A009C for ; Sat, 26 Jul 2014 23:12:46 -0700 (PDT) X-ASG-Debug-ID: 1406441564-06daaa3efd27d50001-aa7cYp Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id MlUmj1uWWsSVRU6v for ; Sun, 27 Jul 2014 02:12:44 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 27 Jul 2014 02:12:43 -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: Sun, 27 Jul 2014 02:12:24 -0400 X-ASG-Orig-Subj: RE: [core] AD review of draft-ietf-core-groupcomm-20, part 2 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] AD review of draft-ietf-core-groupcomm-20, part 2 Thread-Index: Ac+o8Z90mBph5bA7SYmEyriDbDM2nQAbapJw References: From: "Rahman, Akbar" To: "Barry Leiba" , X-OriginalArrivalTime: 27 Jul 2014 06:12:43.0916 (UTC) FILETIME=[C763C4C0:01CFA961] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1406441564 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.7855 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: http://mailarchive.ietf.org/arch/msg/core/K7jy2Tt0ISiNW_U0mlR9N5wHk7A Cc: core WG Subject: Re: [core] AD review of draft-ietf-core-groupcomm-20, part 2 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 27 Jul 2014 06:12:48 -0000 Hi Barry, Thank you again. I have given point by point feedback inline below (identified by: **[Akbar-x]). Please especially see [Akbar-7] and tell us if you agree with our response. As I mentioned previously, we will do a fast update of the draft once we have agreement with you on all your comments in this and your first email. Best Regards, Akbar -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Barry Leiba Sent: Saturday, July 26, 2014 12:50 PM To: draft-ietf-core-groupcomm.all@tools.ietf.org Cc: core WG Subject: [core] AD review of draft-ietf-core-groupcomm-20, part 2 And here's the rest of my review, Section 3 and beyond. As with the others, please discuss these with me if you need to, and tell me that you think I'm wrong about any that you think that way about. I'm going to put the document into "Revised I-D Needed" substate while you work on addressing these reviews. Barry, as AD =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D General: The RFC Editor will probably get this, but as long as you're making changes, note that correct use of "for example" and "e.g." has them set off by commas. Wherever you have "xxx, for example due to yyy", it should be "xxx, due, for example, to yyy". **[Akbar-1] - Ok. Will make these global changes. -- Section 3.2 -- o A large room (Room-A) with three lights (Light-1, Light-2, Light- 3) controlled by a Light Switch. The devices are organized into two subnets. In reality, there could be more lights (up to several hundreds) but these are not shown for clarity. Nit: make it, "but, for clarity, only three are shown." **[Akbar-2] - Ok, will update as you suggested. -- Section 3.4 -- Nit: I would make items 3 and 4 in the numbered list be 3a and 3b, to make it clearer that the second is an alternative to the first. **[Akbar-3] - Ok, will update as you suggested. -- Section 3.6 -- In our particular use case, a group of three lights is defined with one IP multicast address and hostname "Room- A-Lights.floor1.west.bldg6.example.com". The commissioning tool has The FQDN should not be split on multiple lines. If you use xml2rfc, I suggest coding it this way, to put it on a line by itself, indented: Room-A-Lights.floor1.west.bldg6.example.com **[Akbar-4] - Ok, will update as you suggested. -- Section 4.3 -- It requires the RPL Mode of Operation (MOP) to be 3 (Storing Mode with multicast Nit: As this is the only place you use MOP, there's no reason to abbreviate it. On the other hand, you do need to expand DAO on first use. **[Akbar-5] - Ok, will update as you suggested. -- Section 4.4 -- 2. Manual configuration of edge router(s) as MPL Seed(s) for specific IP multicast traffic. E.g. in above example, first configure Rtr-1 and Rtr-2 to act as MLD Address Listeners for the Room-A-Lights IP multicast group. "E.g. in above example" is awkward (and you have that in another paragraph, too). Also, the paragraph is complicated. I think it would be clearer this way: NEW 2. Manual configuration of edge router(s) as MPL Seed(s) for specific IP multicast traffic. In the above example, this could be done through the following three steps: First, configure Rtr-1 and Rtr-2 to act as MLD Address Listeners for the Room-A-Lights IP multicast group. END **[Akbar-6] - Ok, will update as you suggested. -- Section 5 -- I really think the security aspects of this are horrid, and it's not clear to me that this should be advanced, especially not at Proposed Standard, as long as that's the case. With questionable authentication, questionable confidentiality, and apparently no access control, I don't know that we should be proposing it now. But is the working group has consensus on doing so, I will send it to the community and the IESG. Were I you, I'd expect to get lambasted in the SecDir review and by the Sec ADs. Just a warning. **[Akbar-7] - First, please note that this document (groupcomm) is proposed to be Informational and not Proposed Standard. As we stated in section 1.2 (Scope), the normative aspects of group communications is specified in RFC7252 (e.g. basic rules for multicast are in http://tools.ietf.org/html/rfc7252#section-8 and for security in http://tools.ietf.org/html/rfc7252#section-9.1 ). The intent of this groupcomm draft is just to explain/illustrate the normative rules of RFC7252 which is fairly terse and sometimes a bit hard to understand without a lot of background knowledge. The only really "new" functionality we are introducing is in section 2.7.2 (Membership Configuration RESTful Interface). This functionality for setting the group membership is not covered in any other CoAP document. Can you please confirm that an Informational document can define the functionality included in section 2.7.2. We have brought this up in the WG several times and the answer was always positive. But we would like to ask you again. -- Section 6.2 -- The registration template changed in RFC 6838; please make sure your filled-in template is aligned with that version. **[Akbar-8] - Ok, will update as you suggested. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Mon Jul 28 11:17:15 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866461A0AC2 for ; Mon, 28 Jul 2014 11:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4Z4QihNZXnq for ; Mon, 28 Jul 2014 11:17:10 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDB931A0AC1 for ; Mon, 28 Jul 2014 11:17:09 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id mc6so5695009lab.20 for ; Mon, 28 Jul 2014 11:17:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=L8dWeGUngmj5WC8+aUZthmfY+NNOG/1Zp9MgcsFCL78=; b=mmBcxeRM0VIe/MhIG8XnQ6RV7wfJEInBcbFrEter2MUcrN6e+B+A5j83fUyZnA1zrs Ug1mKgTz2gvOuQ/oPqzBsMHEoG6/Q9gYHEqLq5x5jSBASVq8hcqXTn6iap7uezAf9xGl 6Rrb6otmRFCq3mehw6DwH7//A5t+uS9uyBNo0hpqC24UCCoM+JsSr4efQ2W75cnBpfTo vxe81B8/08c/CEN7eE6zD7Fxi3KwFbKxy3tdWXAi2bCNeK3bQ9/eQINOX9A+93rkWJzx XUtiHygZLcXxGLDOe5N5kLxyoJp9RTfWmkzxgE9U2rQV1la29nJ2A8HFtnJdqM7RwDP6 pecg== MIME-Version: 1.0 X-Received: by 10.152.36.135 with SMTP id q7mr33075316laj.42.1406571428160; Mon, 28 Jul 2014 11:17:08 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.46 with HTTP; Mon, 28 Jul 2014 11:17:08 -0700 (PDT) Date: Mon, 28 Jul 2014 14:17:08 -0400 X-Google-Sender-Auth: G5ypVSqhkozPqFBdjbHWcIT9OI8 Message-ID: From: Barry Leiba To: "Rahman, Akbar" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/core/ZxBDBigUzp9wCQjjXWfrHLJCT68 Cc: draft-ietf-core-groupcomm.all@tools.ietf.org, core WG Subject: Re: [core] AD review of draft-ietf-core-groupcomm-20 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 28 Jul 2014 18:17:13 -0000 Hi, Akbar. Thanks for the quick response. I'm merging the two reviews and replying in one message. I'm also eliminating everything that needs no further comment. If you don't see it here, it means your response is fine. The most important bit first: > -- Section 5 -- > I really think the security aspects of this are horrid, and it's not > clear to me that this should be advanced, especially not at Proposed > Standard, as long as that's the case. With questionable authentication, > questionable confidentiality, and apparently no access control, I don't > know that we should be proposing it now. But is the working group has > consensus on doing so, I will send it to the community and the IESG. > Were I you, I'd expect to get lambasted in the SecDir review and by the > Sec ADs. Just a warning. > > **[Akbar-7] - First, please note that this document (groupcomm) is > proposed to be Informational and not Proposed Standard. As we stated in > section 1.2 (Scope), the normative aspects of group communications is > specified in RFC7252 (e.g. basic rules for multicast are in > http://tools.ietf.org/html/rfc7252#section-8 and for security in > http://tools.ietf.org/html/rfc7252#section-9.1 ). The intent of this > groupcomm draft is just to explain/illustrate the normative rules of > RFC7252 which is fairly terse and sometimes a bit hard to understand > without a lot of background knowledge. The only really "new" > functionality we are introducing is in section > 2.7.2 (Membership Configuration RESTful Interface). This functionality > for setting the group membership is not covered in any other CoAP > document. Can you please confirm that an Informational document can > define the functionality included in section 2.7.2. We have brought > this up in the WG several times and the answer was always positive. But > we would like to ask you again. And, gee, yes, I knew when I started the review that this was Informational. And I forgot by the time I got here. That does make a difference. That said, I think you *are* specifying a protocol here: the protocol is the group management that's wrapped around the already-standard use of CoAP with multicast, and the way to use requests and responses with groups -- you're layering a group protocol over CoAP. Let's go ahead and continue this as Informational, and see whether other ADs think it's a protocol that should be Standards Track. Let's also try to avoid having this shredded by the Sec ADs, though. See if you can come up with a paragraph to put into Section 1.2 that talks about how there's no authentication, confidentiality, or access control available in CoAP over multicast, and that group communication does nothing to change that. Say something about the work that's in progress to address this, and what still might have to be done to ensure that the right security, including access controls, is available. Then put a backward reference to Section 1.2 into the Security Considerations. > While I don't object to it, I don't see why you need to cite RFC 7320 > here. Maybe you should explain the second list item 1 to me more. > It's my understanding that the URI paths are *used* by the clients, but > that they don't represent resources in the clients -- they represent > resources in the servers. Is that correct? > > **[Akbar-5] - Yes, the URIs (authority/path) represent resources in the > servers (and not the sending client). The RFC7320 reference was added > because at one time we had discussions in the WG regarding if we should > hardcode a path name for group communications. Meaning that we should > take the "/.well-known/core" idea for discovery and try to hardcode > something similar for group communications (e.g. "/groupcomm/core" or > "/core/groupcomm"). However, RFC7320 > (http://tools.ietf.org/html/rfc7320#section-2.3) specifically advises > against this approach. So, we would prefer to leave the RFC7320 > reference in (and point it to specifically section 2.3 if that helps > clarify). Is that ok with you? As I said, I don't object to your citing 7320 if you think you need to (I think it doesn't need to be normative, if you're just explaining a rationale for the way you're doing something). But I still don't think you explain enough in the last sentence for me to understand why you're saying that: "Note that ([RFC7320]). prescribes that any specification must not constrain, define structure or semantics for any path component." (There's an extra "." in that sentence, by the way.) If you want to say this, I think you should say "we did X instead of Y, because 7320 precludes Y when it says Z." And, again, I'd have to see the final text to be sure, but my guess is that the reference can go back to Informative. > -- Section 2.4 -- > > Idempotent CoAP RESTful methods (i.e., GET, PUT, and DELETE) SHOULD > be used for group communication, with one exception as follows. A > non-idempotent CoAP method (i.e., POST) MAY be used for group > communication if the resource being POSTed to has been designed to > cope with the unreliable and lossy nature of IP multicast. > > The term "idempotent" is used only here, and you give an exhaustive list > of the methods anyway. Why distract readers, rather than just focusing > on the methods? > > **[Akbar-6] - The term "idempotent" is clearly defined in RFC7252 > (http://tools.ietf.org/html/rfc7252#section-5.1), and is an important > concept in REST in general. So we wanted to use the term because it > helps draws the reader's attention to the potential complications of > using group communications for non-idempotent methods. So we would > prefer to leave the term there. Is that ok with you? OK, that makes sense. In that case, merging "idempotent" back into my suggested change: NEW Group communication uses the idempotent CoAP RESTful methods, GET, PUT, and DELETE, in most cases. The non-idempotent CoAP method, POST, may only be used for group communication if the resource being POSTed to has been designed to cope with the unreliable and lossy nature of IP multicast. END > Using the CoAP > default protocol parameters the re-use time becomes at least 250 > seconds, but may need to be much longer in practice since there is no > time limit defined in CoAP for generation of responses by a server. > > This concerns me, as it gives no reasonable upper bound as guidance. > Given that the consequence of falling afoul of it is a potocol error, we > really should try to scope it better. Can you provide any upper bound > for the length of time, even if it comes with some warning? > > **[Akbar-9] - Okay. We will think about an upper bound number and add > it to the draft. Thanks. I'm not expecting anything cast in concrete... just guidance, so implementers can have a sense of what to do. > -- Section 2.6 -- > > CoAP Groups, and the membership of these groups, can be discovered > via the lookup interfaces in the Resource Directory (RD) defined in > [I-D.ietf-core-resource-directory]. > > Given this statement and the second case in 2.7.1, I don't see how that > document is not a normative reference. Can you explain your thinking > about that? Or can you re-word this so it's clearer that the Resource > Directory document is optional reading, and doesn't need to be > understood here? > > **[Akbar-10] - The main reason that we do not think that the > core-resource-directory is normative is because you can build and run a > system implementing CoAP group communications without a resource > directory (RD) endpoint in the system. So the RD concept is useful (and > complementary) but not mandatory for implementing group communications. > For example, to implement the functionality in the rest of section 2.7.2 > does not require an RD at all (i.e. the reference to RD in section 2.7.1 > was purely for background). So I would prefer to leave the document > informative. Is that okay with you? Not on this basis. Things that are required for optional features are still normative references, in general. Consider that CoAP itself does not have to use DTLS; it's an option. Yet RFC 6347 is a normative reference. It's possible you could convince me that RD is not a normative reference, but the "optional feature" argument isn't going to do it. > The following ABNF rule can be > used for parsing the address, referring to the definitions in > Section 6 of [RFC7252] and [RFC3986]. > > It's hard to tell what the scope of "Section 6" is. Ty this: > > NEW > The following ABNF rule can be > used for parsing the address, referring to the definitions in > Section 6 of [RFC7252] and Section 3.2.2 of [RFC3986]. > END > > But what definition in 7252 are you referring to? I don't see one. > > **[Akbar-16] - Ok. We will update as you suggested. The definition in > 7252 that we were referring to was in the second paragraph of section 6. > Do you agree? Well, all that paragraph says is "go see 3986," and you already cite 3986. I found it confusing to have the 7252 citation, because I was looking for something else. Maybe this sort of thing would make you happy?: NEW The following ABNF rule can be used for parsing the address, as in the base CoAP protocol, referring to the definitions in Section 3.2.2 of [RFC3986]. END > In a response, the "a" key/value pair > SHOULD be included if the IP address is known at the time of > generating the response, and MUST NOT be included if unknown. If the > "a" value is not provided in a request, the "n" value in the same > group membership object SHOULD be a valid hostname with optional port > number that can be translated to an IP multicast address via DNS > > More 2119 follies... > The first SHOULD: Why is it a SHOULD? What happens to the protocol if > you don't? > > **[Akbar-17] - The "a" is optional. So that is why it is stated that it > SHOULD be returned if known. It cannot be a MUST because it may not be > there as it is optional. Is that clear Right, so we have a disconnect on the meaning of SHOULD in 2119. SHOULD doesn't mean it's optional. SHOULD means that it's important for interoperability, but it's possible not to do it if you understand the situation and have carefully thought it out. You give no guidance for thinking it out, so I asked. This might just be another case where 2119 key words aren't necessary. But let's put this together with the other comments on the same list. I still need to understand how important it is to have "a" there. There could be three cases: a. It's preferable to use "a", but "n" is available as a less-preferred option. b. It's preferable to use "n", but "a" is available as a less-preferred option. c. You can use "a" or "n", with equal preference. In addition, there's the question of whether there's value added by having both "a" and "n" at the same time (one of my comments below goes to this part). I think case (a) is correct, yes? Assuming that: NEW In any group membership object, if the IP address is known when the object is created, it is included in the "a" key/value pair. If the "a" value cannot be provided, the "n" value MUST be included, containing a valid hostname with optional port number that can be translated to an IP multicast address via DNS END That says that you include "a" if you can, and if you can't, you MUST include "n". Does that work for you? > How does a locally unique two-character string scale? Even if we're > talking about case-sensitive ASCII, that still seems to limit you to > 3844 unique strings. Is that enough? > > **[Akbar-24] -It is representing the number of IP multicast groups that > the endpoint is taking part in. Practically this should be in the order > of a few tens of groups at most. So 3844 should be more than enough. Ah! I had it backward (or sideways, or something): I thought it was the endpoint's index in the group, and so it limited group size. But you're saying that it's the group's index in the endpoint's list of groups, so it limits the number of groups an endpoint can belong to. It's probably worth saying a sentence or two about that, so it's clear. > For the 'gp' variable it is recommended to use the path "coap-group" > by default. If the "a" key/value pair is given, this takes priority > and the "n" pair becomes informational. > > What does it mean for it to be informational? What should the server do > with it? > > **[Akbar-25] -In effect, it means that the "n" can be ignored. Should > we say that instead of saying it becomes informational? (This is > because if the IP address ("a") is given, then the name ("n") becomes > unnecessary.) Yes. I would say it this way: NEW The "a" key/value pair is always used if it is given. The "n" pair is only used when there is no "a" pair. END > If only the "n" pair is > given, the CoAP endpoint may perform DNS resolution (if supported) to > obtain the IP multicast address from the hostname. > > What can it do other than performing DNS resolution? What happens if > DNS resolution isn't supported? > > **[Akbar-26] - If DNS resolution of a multicast name is not supported > then nothing else can be done. We used the "if supported" phrase > throughout as there is not guarantee that there is even a DNS > infrastructure setup in many constrained networks (e.g. in a building > lighting scenario). We will explicitly state this assumption in the > text for clarity. Actually, I understand that, so, while it will be fine to highlight that here, it's not sufficient. The text here needs to say what to do if you have no "a", are therefore relying on the "n", and DNS resolution isn't available. So: NEW If only the "n" pair is given, the CoAP endpoint performs DNS resolution to obtain the IP multicast address from the hostname in the "n" pair. If DNS resolution is not available, [TELL ME]. END > -- Section 2.8 -- > > For IP multicast request acceptance, the REQUIRED behaviors are: > > I don't understand how "REQUIRED" applies when the first three items say > "SHOULD NOT". Please explain what you mean here, from a protocol > requirements point of view, so we can figure out how you should really > say it. The same goes for the next list in this section, though that's > probably even worse, because you say that the sever MAY choose not to > respond, and then you say the server responds. That seems like bad 2119 > usage. > > For the part about response configuration options, why is that a 2119 > "SHOULD"? How does it affect protocol interoperability? > > My guess is that all this will be better said without trying to cram > 2119 key words into it, but let's first understand your intent. > > Note that in this > case the client implements a "reliable group communication" (as > defined in Section 1.3) function using additional, non- > standardized functions above the CoAP layer. > > I'm not sure what this means (so maybe you can explain it to me), but > I'll point out that *this* protocol (groupcomm) is non-standardized as > well. > > **[Akbar-35] ... > perhaps the best resolution will be to remove RFC2119 language > from this section. Do you agree? We just wanted to recap all the > request acceptance and response suppression rules in one place to make > for a quick summary read for implementers). The recap makes sense. Yes, please re-word this bit in clear English, without worrying about 2119 key words, and let's see what it looks like then. I bet it comes out better. Sometimes we really hurt our text by trying to put too many MUSTs and SHOULDs and MAYs in. > **[Akbar-37] - Ok. Will do as you suggest. (If you used French > examples it would have been easier for me to follow!). :-) OK, that's it... it looks like we should be able to sort all this out with one document revision, and get last call started soon. Barry From nobody Tue Jul 29 02:06:48 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E65C01A0145 for ; Tue, 29 Jul 2014 02:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qx1NzyQdFmmR for ; Tue, 29 Jul 2014 02:06:44 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3D5F1A02C2 for ; Tue, 29 Jul 2014 02:06:43 -0700 (PDT) Received: from localhost ([::1]:60180 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XC3Me-0002EQ-EC; Tue, 29 Jul 2014 02:06:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Tue, 29 Jul 2014 09:06:32 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/375 Message-ID: <060.57742d50691ea88699e0826ea2600aad@trac.tools.ietf.org> X-Trac-Ticket-ID: 375 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, angelo@castellani.net, esko.dijk@philips.com, salvatore.loreto@ericsson.com, thomas.fossati@alcatel-lucent.com Archived-At: http://mailarchive.ietf.org/arch/msg/core/3XqT54I9_9aXQmMT3rgN3dbfCqg Cc: core@ietf.org Subject: [core] #375 (http-mapping): Add requirement on mapping of CoAP diagnostic payload X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Reply-To: trac+core@zinfandel.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: Tue, 29 Jul 2014 09:06:47 -0000 #375: Add requirement on mapping of CoAP diagnostic payload To add text in section 6.3/6.3.x (Media Type mapping) that any CoAP payload in an error response (the diagnostic payload) should be converted to HTTP Reason-Phrase, and MUST NOT be returned as regular HTTP body/content. (This is something a developer of a proxy might overlook initially.) -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-http- esko.dijk@philips.com | mapping@tools.ietf.org Type: protocol | Status: new enhancement | Milestone: Priority: minor | Version: Component: http- | Keywords: mapping | Severity: - | -------------------------+------------------------------------------------- Ticket URL: core From nobody Tue Jul 29 21:38:08 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1D1B1A002A for ; Tue, 29 Jul 2014 21:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LoDHSWjMY5aW for ; Tue, 29 Jul 2014 21:38:01 -0700 (PDT) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11D5E1A0016 for ; Tue, 29 Jul 2014 21:38:00 -0700 (PDT) X-ASG-Debug-ID: 1406695078-06daaa5f0d1be30001-aa7cYp Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id D2NxYgwFntZh1PHC for ; Wed, 30 Jul 2014 00:37:58 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Jul 2014 00:37:56 -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: Wed, 30 Jul 2014 00:37:36 -0400 X-ASG-Orig-Subj: RE: [core] AD review of draft-ietf-core-groupcomm-20 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] AD review of draft-ietf-core-groupcomm-20 Thread-Index: Ac+qkCbv/OJwCSBeRhi+ZQ06MUCS4gA0yDWA References: From: "Rahman, Akbar" To: "Barry Leiba" X-OriginalArrivalTime: 30 Jul 2014 04:37:56.0497 (UTC) FILETIME=[08A9C010:01CFABB0] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1406695078 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.7948 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Archived-At: http://mailarchive.ietf.org/arch/msg/core/K3AtFGdIPox6s6nJv0Cm1196cSo Cc: draft-ietf-core-groupcomm.all@tools.ietf.org, core WG Subject: Re: [core] AD review of draft-ietf-core-groupcomm-20 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 30 Jul 2014 04:38:05 -0000 Hi Barry, Thank you for the revised feedback and clarifications. My co-author, Esko, and I have discussed them off line and following are our consolidated responses (identified as "**[Authors-Response-x]"). Once you have approved our final answers, we will aim to do a quick update of the draft to incorporate all your comments. Best Regards, Esko & Akbar -----Original Message----- From: barryleiba@gmail.com [mailto:barryleiba@gmail.com] On Behalf Of Barry Leiba Sent: Monday, July 28, 2014 2:17 PM To: Rahman, Akbar Cc: core WG; draft-ietf-core-groupcomm.all@tools.ietf.org Subject: Re: [core] AD review of draft-ietf-core-groupcomm-20 Hi, Akbar. Thanks for the quick response. I'm merging the two reviews and replying in one message. I'm also eliminating everything that needs no further comment. If you don't see it here, it means your response is fine. The most important bit first: > -- Section 5 -- > I really think the security aspects of this are horrid, and it's not=20 > clear to me that this should be advanced, especially not at Proposed=20 > Standard, as long as that's the case. With questionable=20 > authentication, questionable confidentiality, and apparently no access > control, I don't know that we should be proposing it now. But is the=20 > working group has consensus on doing so, I will send it to the community and the IESG. > Were I you, I'd expect to get lambasted in the SecDir review and by=20 > the Sec ADs. Just a warning. > > **[Akbar-7] - First, please note that this document (groupcomm) is=20 > proposed to be Informational and not Proposed Standard. As we stated=20 > in section 1.2 (Scope), the normative aspects of group communications=20 > is specified in RFC7252 (e.g. basic rules for multicast are in > http://tools.ietf.org/html/rfc7252#section-8 and for security in > http://tools.ietf.org/html/rfc7252#section-9.1 ). The intent of this=20 > groupcomm draft is just to explain/illustrate the normative rules of > RFC7252 which is fairly terse and sometimes a bit hard to understand=20 > without a lot of background knowledge. The only really "new" > functionality we are introducing is in section > 2.7.2 (Membership Configuration RESTful Interface). This=20 > functionality for setting the group membership is not covered in any=20 > other CoAP document. Can you please confirm that an Informational=20 > document can define the functionality included in section 2.7.2. We=20 > have brought this up in the WG several times and the answer was always > positive. But we would like to ask you again. And, gee, yes, I knew when I started the review that this was Informational. And I forgot by the time I got here. That does make a difference. That said, I think you *are* specifying a protocol here: the protocol is the group management that's wrapped around the already-standard use of CoAP with multicast, and the way to use requests and responses with groups -- you're layering a group protocol over CoAP. Let's go ahead and continue this as Informational, and see whether other ADs think it's a protocol that should be Standards Track. Let's also try to avoid having this shredded by the Sec ADs, though. See if you can come up with a paragraph to put into Section 1.2 that talks about how there's no authentication, confidentiality, or access control available in CoAP over multicast, and that group communication does nothing to change that. Say something about the work that's in progress to address this, and what still might have to be done to ensure that the right security, including access controls, is available. Then put a backward reference to Section 1.2 into the Security Considerations. **[Authors-Response-1] - Ok. We propose adding the following new paragraph to the end of Section 1.2 (Scope): NEW While [RFC7252] supports various modes of DTLS based security for CoAP over unicast IP, it does not specify any security modes for CoAP over IP multicast. That is, [RFC7252] assumes that CoAP over IP multicast is not encrypted, nor authenticated, nor access controlled. This document assumes the same security model (see http://tools.ietf.org/html/draft-ietf-core-groupcomm-20#section-5.1) . However, there are several promising security solutions being developed that should be considered in the future for protecting CoAP group communications (see http://tools.ietf.org/html/draft-ietf-core-groupcomm-20#section-5.3.3).=20 END And we propose updating Section 5.3.3 (Future Security Evolution) as follows: NEW In the future, to further mitigate the threats, one or more of the following security enhancements should be considered for group communications once the enhancements mature. This will allow introduction of a secure mode of CoAP group communication, and use of the "coaps" scheme for that purpose. For example, http://datatracker.ietf.org/doc/draft-keoh-dice-multicast-security/ proposes a DTLS-based IP multicast security, and http://datatracker.ietf.org/doc/draft-mglt-dice-ipsec-for-application-pa yload/ proposes an IPSec based IP multicast security. Also, there is some early work in developing group authentication such as described in http://datatracker.ietf.org/doc/draft-zhu-ace-groupauth/.=20 END Does the above two changes address your comment? > While I don't object to it, I don't see why you need to cite RFC 7320=20 > here. Maybe you should explain the second list item 1 to me more. > It's my understanding that the URI paths are *used* by the clients,=20 > but that they don't represent resources in the clients -- they=20 > represent resources in the servers. Is that correct? > > **[Akbar-5] - Yes, the URIs (authority/path) represent resources in the > servers (and not the sending client). The RFC7320 reference was added > because at one time we had discussions in the WG regarding if we=20 > should hardcode a path name for group communications. Meaning that we > should take the "/.well-known/core" idea for discovery and try to=20 > hardcode something similar for group communications (e.g. "/groupcomm/core" or > "/core/groupcomm"). However, RFC7320 > (http://tools.ietf.org/html/rfc7320#section-2.3) specifically advises > against this approach. So, we would prefer to leave the RFC7320 > reference in (and point it to specifically section 2.3 if that helps=20 > clarify). Is that ok with you? As I said, I don't object to your citing 7320 if you think you need to (I think it doesn't need to be normative, if you're just explaining a rationale for the way you're doing something). But I still don't think you explain enough in the last sentence for me to understand why you're saying that: "Note that ([RFC7320]). prescribes that any specification must not constrain, define structure or semantics for any path component." (There's an extra "." in that sentence, by the way.) If you want to say this, I think you should say "we did X instead of Y, because 7320 precludes Y when it says Z." And, again, I'd have to see the final text to be sure, but my guess is that the reference can go back to Informative. **[Authors-Response-2] - Ok. We propose changing the bullet in question in Section 2.3 to the following: NEW 1. Pre-configured group URI paths, if available. The pre-configuration mechanism SHOULD ensure that these (identical) paths are pre-configured across all CoAP servers in a group and all CoAP clients performing the group requests. Implementers are free to define the paths as they see fit. However, note that ([RFC7320]) prescribes that any specification must not constrain, define structure or semantics for any URI path component. So for this reason, a pre-defined URI path is not defined in this document. END Also, we agree that we change [RFC7320] to be informational. Do these changes address your comment? > -- Section 2.4 -- > > Idempotent CoAP RESTful methods (i.e., GET, PUT, and DELETE) SHOULD > be used for group communication, with one exception as follows. A > non-idempotent CoAP method (i.e., POST) MAY be used for group > communication if the resource being POSTed to has been designed to > cope with the unreliable and lossy nature of IP multicast. > > The term "idempotent" is used only here, and you give an exhaustive=20 > list of the methods anyway. Why distract readers, rather than just=20 > focusing on the methods? > > **[Akbar-6] - The term "idempotent" is clearly defined in RFC7252=20 > (http://tools.ietf.org/html/rfc7252#section-5.1), and is an important=20 > concept in REST in general. So we wanted to use the term because it=20 > helps draws the reader's attention to the potential complications of=20 > using group communications for non-idempotent methods. So we would=20 > prefer to leave the term there. Is that ok with you? OK, that makes sense. In that case, merging "idempotent" back into my suggested change: NEW Group communication uses the idempotent CoAP RESTful methods, GET, PUT, and DELETE, in most cases. The non-idempotent CoAP method, POST, may only be used for group communication if the resource being POSTed to has been designed to cope with the unreliable and lossy nature of IP multicast. END **[Authors-Response-3] - Ok. We agree with your proposal, except we suggest deleting the phrase "in most cases". This is because DELETE for example is not expected to be as commonly used as GET (i.e. if we use the history of HTTP requests as a guideline). Is that okay with you? > Using the CoAP > default protocol parameters the re-use time becomes at least 250 > seconds, but may need to be much longer in practice since there is no > time limit defined in CoAP for generation of responses by a server. > > This concerns me, as it gives no reasonable upper bound as guidance. > Given that the consequence of falling afoul of it is a potocol error,=20 > we really should try to scope it better. Can you provide any upper=20 > bound for the length of time, even if it comes with some warning? > > **[Akbar-9] - Okay. We will think about an upper bound number and add > it to the draft. Thanks. I'm not expecting anything cast in concrete... just guidance, so implementers can have a sense of what to do. **[Authors-Response-4] - Ok.=20 > -- Section 2.6 -- > > CoAP Groups, and the membership of these groups, can be discovered > via the lookup interfaces in the Resource Directory (RD) defined in > [I-D.ietf-core-resource-directory]. > > Given this statement and the second case in 2.7.1, I don't see how=20 > that document is not a normative reference. Can you explain your=20 > thinking about that? Or can you re-word this so it's clearer that the > Resource Directory document is optional reading, and doesn't need to=20 > be understood here? > > **[Akbar-10] - The main reason that we do not think that the=20 > core-resource-directory is normative is because you can build and run=20 > a system implementing CoAP group communications without a resource=20 > directory (RD) endpoint in the system. So the RD concept is useful=20 > (and > complementary) but not mandatory for implementing group communications. > For example, to implement the functionality in the rest of section=20 > 2.7.2 does not require an RD at all (i.e. the reference to RD in=20 > section 2.7.1 was purely for background). So I would prefer to leave=20 > the document informative. Is that okay with you? Not on this basis. Things that are required for optional features are still normative references, in general. Consider that CoAP itself does not have to use DTLS; it's an option. Yet RFC 6347 is a normative reference. It's possible you could convince me that RD is not a normative reference, but the "optional feature" argument isn't going to do it. **[Authors-Response-5] - Ok. It looks like we should consider to make the RD reference as normative. But before we close this issue, could you point us to any RFC that defines the criteria for making the decision between Informative vs Normative reference? > The following ABNF rule can be > used for parsing the address, referring to the definitions in > Section 6 of [RFC7252] and [RFC3986]. > > It's hard to tell what the scope of "Section 6" is. Ty this: > > NEW > The following ABNF rule can be > used for parsing the address, referring to the definitions in > Section 6 of [RFC7252] and Section 3.2.2 of [RFC3986]. > END > > But what definition in 7252 are you referring to? I don't see one. > > **[Akbar-16] - Ok. We will update as you suggested. The definition=20 > in > 7252 that we were referring to was in the second paragraph of section 6. > Do you agree? Well, all that paragraph says is "go see 3986," and you already cite 3986. I found it confusing to have the 7252 citation, because I was looking for something else. Maybe this sort of thing would make you happy?: NEW The following ABNF rule can be used for parsing the address, as in the base CoAP protocol, referring to the definitions in Section 3.2.2 of [RFC3986]. END **[Authors-Response-6] - Ok. We may slightly wordsmith it but that looks good. > In a response, the "a" key/value pair > SHOULD be included if the IP address is known at the time of > generating the response, and MUST NOT be included if unknown. If the > "a" value is not provided in a request, the "n" value in the same > group membership object SHOULD be a valid hostname with optional port > number that can be translated to an IP multicast address via DNS > > More 2119 follies... > The first SHOULD: Why is it a SHOULD? What happens to the protocol if > you don't? > > **[Akbar-17] - The "a" is optional. So that is why it is stated that=20 > it SHOULD be returned if known. It cannot be a MUST because it may=20 > not be there as it is optional. Is that clear Right, so we have a disconnect on the meaning of SHOULD in 2119. SHOULD doesn't mean it's optional. SHOULD means that it's important for interoperability, but it's possible not to do it if you understand the situation and have carefully thought it out. You give no guidance for thinking it out, so I asked. This might just be another case where 2119 key words aren't necessary. But let's put this together with the other comments on the same list. I still need to understand how important it is to have "a" there. There could be three cases: a. It's preferable to use "a", but "n" is available as a less-preferred option. b. It's preferable to use "n", but "a" is available as a less-preferred option. c. You can use "a" or "n", with equal preference. In addition, there's the question of whether there's value added by having both "a" and "n" at the same time (one of my comments below goes to this part). I think case (a) is correct, yes? **[Authors-Response-7] - Yes, that is correct. Assuming that: NEW In any group membership object, if the IP address is known when the object is created, it is included in the "a" key/value pair. If the "a" value cannot be provided, the "n" value MUST be included, containing a valid hostname with optional port number that can be translated to an IP multicast address via DNS=20 END That says that you include "a" if you can, and if you can't, you MUST include "n". Does that work for you? **[Authors-Response-8] - Yes. That is what we meant. So we will use your wording. > How does a locally unique two-character string scale? Even if we're=20 > talking about case-sensitive ASCII, that still seems to limit you to > 3844 unique strings. Is that enough? > > **[Akbar-24] -It is representing the number of IP multicast groups=20 > that the endpoint is taking part in. Practically this should be in=20 > the order of a few tens of groups at most. So 3844 should be more than enough. Ah! I had it backward (or sideways, or something): I thought it was the endpoint's index in the group, and so it limited group size. But you're saying that it's the group's index in the endpoint's list of groups, so it limits the number of groups an endpoint can belong to. It's probably worth saying a sentence or two about that, so it's clear. **[Authors-Response-9] - Ok. We can change the definition of the "index" in section 2.7.2.2 as follows: NEW Index - Group index. Index SHOULD be a string of 2 alphanumeric ASCII characters (case insensitive). It MUST be locally unique to the endpoint server. It indexes the particular endpoint's list of group memberships. END > For the 'gp' variable it is recommended to use the path "coap-group" > by default. If the "a" key/value pair is given, this takes priority > and the "n" pair becomes informational. > > What does it mean for it to be informational? What should the server=20 > do with it? > > **[Akbar-25] -In effect, it means that the "n" can be ignored. Should > we say that instead of saying it becomes informational? (This is=20 > because if the IP address ("a") is given, then the name ("n") becomes > unnecessary.) Yes. I would say it this way: NEW The "a" key/value pair is always used if it is given. The "n" pair is only used when there is no "a" pair. END **[Authors-Response-10] - Yes. That is what we meant. So we will use your wording. > If only the "n" pair is > given, the CoAP endpoint may perform DNS resolution (if supported) to > obtain the IP multicast address from the hostname. > > What can it do other than performing DNS resolution? What happens if=20 > DNS resolution isn't supported? > > **[Akbar-26] - If DNS resolution of a multicast name is not supported=20 > then nothing else can be done. We used the "if supported" phrase=20 > throughout as there is not guarantee that there is even a DNS=20 > infrastructure setup in many constrained networks (e.g. in a building=20 > lighting scenario). We will explicitly state this assumption in the=20 > text for clarity. Actually, I understand that, so, while it will be fine to highlight that here, it's not sufficient. The text here needs to say what to do if you have no "a", are therefore relying on the "n", and DNS resolution isn't available. So: NEW If only the "n" pair is given, the CoAP endpoint performs DNS resolution to obtain the IP multicast address from the hostname in the "n" pair. If DNS resolution is not available, [TELL ME]. END **[Authors-Response-11] - Ok, good point, so we propose the following wording: NEW If only the "n" pair is given, the CoAP endpoint performs DNS resolution to obtain the IP multicast address from the hostname in the "n" pair. If DNS resolution is not successful, then the endpoint does not attempt joining or listening to any multicast group for this case since the IP multicast address is unknown. END Do this address your comment? > -- Section 2.8 -- > > For IP multicast request acceptance, the REQUIRED behaviors are: > > I don't understand how "REQUIRED" applies when the first three items=20 > say "SHOULD NOT". Please explain what you mean here, from a protocol=20 > requirements point of view, so we can figure out how you should really > say it. The same goes for the next list in this section, though=20 > that's probably even worse, because you say that the sever MAY choose=20 > not to respond, and then you say the server responds. That seems like > bad 2119 usage. > > For the part about response configuration options, why is that a 2119=20 > "SHOULD"? How does it affect protocol interoperability? > > My guess is that all this will be better said without trying to cram > 2119 key words into it, but let's first understand your intent. > > Note that in this > case the client implements a "reliable group communication" (as > defined in Section 1.3) function using additional, non- > standardized functions above the CoAP layer. > > I'm not sure what this means (so maybe you can explain it to me), but=20 > I'll point out that *this* protocol (groupcomm) is non-standardized as > well. > > **[Akbar-35] ... > perhaps the best resolution will be to remove RFC2119 language from=20 > this section. Do you agree? We just wanted to recap all the request=20 > acceptance and response suppression rules in one place to make for a=20 > quick summary read for implementers). The recap makes sense. Yes, please re-word this bit in clear English, without worrying about 2119 key words, and let's see what it looks like then. I bet it comes out better. Sometimes we really hurt our text by trying to put too many MUSTs and SHOULDs and MAYs in. **[Authors-Response-12] - Ok, we will re-write the entire section 2.8 without any RFC2119 language as you suggested. Also, perhaps we should also re-write section 2.9 without any RFC2119 language as it is a similar section. What do you think? > **[Akbar-37] - Ok. Will do as you suggest. (If you used French=20 > examples it would have been easier for me to follow!). :-) OK, that's it... it looks like we should be able to sort all this out with one document revision, and get last call started soon. **[Authors-Response-13] - Thank you! Barry From nobody Tue Jul 29 23:20:24 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE04A1A03D4 for ; Tue, 29 Jul 2014 23:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwO1THRk36BT for ; Tue, 29 Jul 2014 23:20:20 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FAD01A0418 for ; Tue, 29 Jul 2014 23:20:19 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id hz20so515226lab.8 for ; Tue, 29 Jul 2014 23:20:18 -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:message-id:subject :from:to:cc:content-type; bh=vg8ByZvTUCeYVbshWjsDErzXcPJfGw+vfyUW+QfVaBc=; b=KBmty+UA1TF6yNUOx6iEsmgtx4GYjtkl+POtxM1Lr7aEiC1UHV/2wOaamvPmPqJF5I F7l38A8dgii7jf3lSsKWU8AGYPVxE0YnZGq4W3bmeCh3ujhBT4EFsFc/xBXWk7mTmrCb XXmKW2tXQdkEhLJ2QPQAYKo6EmDaPpEyPsm9SdYtbb14jhUjPNDMI0W4E1eBJxwN3yxa u3JlmvXIxjCBarUQHjxMkrcoZsFxj/CY3519s4xBo+VBhIOn9ReNtZMojWle2AauswHb iHJ0lGjZ7CP9DLn4J9x+uGZQaJBy1BBgydj/UaQhgZbtCvRYB4002o5HqlYtQ0MT/68T +EDA== MIME-Version: 1.0 X-Received: by 10.112.181.74 with SMTP id du10mr1883276lbc.40.1406701218375; Tue, 29 Jul 2014 23:20:18 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.46 with HTTP; Tue, 29 Jul 2014 23:20:18 -0700 (PDT) In-Reply-To: References: Date: Wed, 30 Jul 2014 02:20:18 -0400 X-Google-Sender-Auth: DjvBKjhzy0xJUYcmTHew9dYELsE Message-ID: From: Barry Leiba To: "Rahman, Akbar" Content-Type: multipart/alternative; boundary=001a11c36fe46d2f8004ff63261a Archived-At: http://mailarchive.ietf.org/arch/msg/core/4ZBo-XDnksXUphkT4gPNDZfUa6k Cc: "draft-ietf-core-groupcomm.all@tools.ietf.org" , core WG Subject: Re: [core] AD review of draft-ietf-core-groupcomm-20 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 30 Jul 2014 06:20:21 -0000 --001a11c36fe46d2f8004ff63261a Content-Type: text/plain; charset=ISO-8859-1 > > Thank you for the revised feedback and clarifications. My co-author, > Esko, and I have discussed them off line and following are our > consolidated responses (identified as "**[Authors-Response-x]"). Once > you have approved our final answers, we will aim to do a quick update of > the draft to incorporate all your comments. Great, thanks. I think we're all set. All your responses are OK with me. **[Authors-Response-5] - Ok. It looks like we should consider to make > the RD reference as normative. But before we close this issue, could > you point us to any RFC that defines the criteria for making the > decision between Informative vs Normative reference? There is no RFC, but there is an IESG Statement: http://www.ietf.org/iesg/statement/normative-informative.html Look at the second paragraph and the first note. **[Authors-Response-12] - Ok, we will re-write the entire section 2.8 > without any RFC2119 language as you suggested. Also, perhaps we should > also re-write section 2.9 without any RFC2119 language as it is a > similar section. What do you think? That seems sensible. Personally I think it's just as good to say things like "IP multicasts requests are always Non-confirmable," instead of "An IP multicast request MUST be Non-confirmable," though both are OK. I don't think the capitalized key words add anything there. Barry --001a11c36fe46d2f8004ff63261a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thank you for the revised feedback and clari= fications. =A0My co-author,
Esko, and I have discussed them off line and following =A0are our
consolidated responses (identified as "**[Authors-Response-x]"). = =A0Once
you have approved our final answers, we will aim to do a quick update of the draft to incorporate all your comments.

Great, thanks. =A0I think we're all set. =A0All your responses are OK = with me.

**[Authors-Response-5] - Ok. =A0It looks like we should consider to make the RD reference as normative. =A0But before we close this issue, could
you point us to any RFC that defines the criteria for making the
decision between Informative vs Normative reference?

<= /div>
There is no RFC, but there is an IESG Statement:
Look at the second paragraph and the first note.

<= /div>
**[Authors-Response-12] - Ok= , we will re-write the entire section 2.8
without any RFC2119 language as you suggested. =A0Also, perhaps we should also re-write section 2.9 without any RFC2119 language as it is a
similar section. =A0What do you think?

That= seems sensible. =A0Personally I think it's just as good to say things = like "IP multicasts requests are always Non-confirmable," instead= of "An IP multicast request MUST be Non-confirmable," though bot= h are OK. =A0I=A0don't think the capitalized key words add anything the= re.

Barry
--001a11c36fe46d2f8004ff63261a-- From nobody Wed Jul 30 03:30:53 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9ACF1A02F1 for ; Wed, 30 Jul 2014 03:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJpGwe--z5QJ for ; Wed, 30 Jul 2014 03:30:47 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0077.outbound.protection.outlook.com [213.199.154.77]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85A881B2A35 for ; Wed, 30 Jul 2014 03:30:43 -0700 (PDT) Received: from AM3PR04MB0631.eurprd04.prod.outlook.com (10.255.133.152) by AM3PR04MB0679.eurprd04.prod.outlook.com (25.160.3.17) with Microsoft SMTP Server (TLS) id 15.0.995.14; Wed, 30 Jul 2014 10:30:41 +0000 Received: from DB3PR04CA006.eurprd04.prod.outlook.com (10.242.134.26) by AM3PR04MB0631.eurprd04.prod.outlook.com (10.255.133.152) with Microsoft SMTP Server (TLS) id 15.0.995.14; Wed, 30 Jul 2014 10:30:39 +0000 Received: from AM1FFO11FD023.protection.gbl (2a01:111:f400:7e00::161) by DB3PR04CA006.outlook.office365.com (2a01:111:e400:9814::26) with Microsoft SMTP Server (TLS) id 15.0.995.14 via Frontend Transport; Wed, 30 Jul 2014 10:30:38 +0000 Received: from mail.philips.com (206.191.242.68) by AM1FFO11FD023.mail.protection.outlook.com (10.174.64.212) with Microsoft SMTP Server (TLS) id 15.0.980.11 via Frontend Transport; Wed, 30 Jul 2014 10:30:38 +0000 Received: from AMSPRD9003MB066.MGDPHG.emi.philips.com ([169.254.5.122]) by AMSPRD9003HT001.MGDPHG.emi.philips.com ([141.251.33.78]) with mapi id 14.16.0459.000; Wed, 30 Jul 2014 10:30:38 +0000 From: "Dijk, Esko" To: Barry Leiba , "Rahman, Akbar" Thread-Topic: [core] AD review of draft-ietf-core-groupcomm-20 Thread-Index: AQHPqpAseQerMW+gRECZB6herPpJipu4CtgAgAAcsgCAADW6AA== Date: Wed, 30 Jul 2014 10:30:38 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED61836E04BB2@AMSPRD9003MB066.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.104] Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED61836E04BB2AMSPRD9003MB066_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:206.191.242.68; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(428002)(76104003)(85714005)(189002)(199002)(66654002)(374574003)(55846006)(106466001)(84326002)(74662001)(15975445006)(95666004)(46102001)(76482001)(21056001)(85852003)(512954002)(6806004)(44976005)(19580405001)(83322001)(19580395003)(84676001)(15202345003)(74502001)(66066001)(83072002)(99396002)(64706001)(80022001)(68736004)(20776003)(77982001)(50986999)(54356999)(2656002)(79102001)(92566001)(69596002)(76176999)(81542001)(31966008)(4396001)(16236675004)(19625215002)(87936001)(97736001)(85306003)(104016003)(107046002)(81342001)(106116001)(81156004)(86362001)(19300405004)(77096002)(71186001)(92726001)(101416001)(19617315012)(33656002)(105586002)(567094001); DIR:OUT; SFP:; SCL:1; SRVR:AM3PR04MB0631; H:mail.philips.com; FPR:; MLV:sfv; PTR:ErrorRetry; MX:1; A:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 0288CD37D9 Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is 206.191.242.68) smtp.mailfrom=esko.dijk@philips.com; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-OriginatorOrg: philips.com Archived-At: http://mailarchive.ietf.org/arch/msg/core/wcDNnX4DS88NJTyr1PPYMowYxC4 Cc: "draft-ietf-core-groupcomm.all@tools.ietf.org" , core WG Subject: Re: [core] AD review of draft-ietf-core-groupcomm-20 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 30 Jul 2014 10:30:51 -0000 --_000_031DD135F9160444ABBE3B0C36CED61836E04BB2AMSPRD9003MB066_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Barry, Many thanks for your thorough review! Below additional comments from my sid= e that I think are important to mention. 1- on the use of RFC2119 language in section 2.8 and 2.9: for some instance= s where this language is used, there is the same normative language in RFC7= 252 or RFC6690. So the text is there to recap these requirements to the rea= der. Of course we can remove the capitals "SHOULD"->"should" but it may be= less clear to the reader that there exists an RFC2119-level requirement on= the topic. I agree that the "REQUIRED" keywords can be removed in these s= ections since they can confuse. (But perhaps there's a better way to say for certain bullet items that they= are not merely our recommendation but there are protocol requirements on i= t.) 2- on the upper bound for Token re-use ([Akbar-9] item): I remember discuss= ions in CoRE in the past, always coming to the conclusion that there is no = upper bound for server response time (similar to HTTP). We could say we put= the Token re-use time for a client at (NON_LIFETIME + MAX_LATENCY + 10 min= utes), just as a default for the case that the max response latency of any = of the CoAP servers is unknown. (I.e. we don't impose a limit onto CoAP whe= re there is none currently.) Then at the same time we could e.g. recommend = that a CoAP server by default responds to multicast requests within MAX_SER= VER_RESPONSE_DELAY =3D 5 minutes, again without forcing a limit for those c= ases where longer is needed. Would that work for you? Esko From: barryleiba@gmail.com [mailto:barryleiba@gmail.com] On Behalf Of Barry= Leiba Sent: Wednesday, July 30, 2014 08:20 To: Rahman, Akbar Cc: core WG; draft-ietf-core-groupcomm.all@tools.ietf.org; Dijk, Esko Subject: Re: [core] AD review of draft-ietf-core-groupcomm-20 Thank you for the revised feedback and clarifications. My co-author, Esko, and I have discussed them off line and following are our consolidated responses (identified as "**[Authors-Response-x]"). Once you have approved our final answers, we will aim to do a quick update of the draft to incorporate all your comments. Great, thanks. I think we're all set. All your responses are OK with me. **[Authors-Response-5] - Ok. It looks like we should consider to make the RD reference as normative. But before we close this issue, could you point us to any RFC that defines the criteria for making the decision between Informative vs Normative reference? There is no RFC, but there is an IESG Statement: http://www.ietf.org/iesg/statement/normative-informative.html Look at the second paragraph and the first note. **[Authors-Response-12] - Ok, we will re-write the entire section 2.8 without any RFC2119 language as you suggested. Also, perhaps we should also re-write section 2.9 without any RFC2119 language as it is a similar section. What do you think? That seems sensible. Personally I think it's just as good to say things li= ke "IP multicasts requests are always Non-confirmable," instead of "An IP m= ulticast request MUST be Non-confirmable," though both are OK. I don't thi= nk the capitalized key words add anything there. Barry ________________________________ 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_031DD135F9160444ABBE3B0C36CED61836E04BB2AMSPRD9003MB066_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Barry,

 <= /p>

Many thanks for your thor= ough review! Below additional comments from my side that I think are import= ant to mention.

 <= /p>

1- on the use of RFC2119 = language in section 2.8 and 2.9: for some instances where this language is = used, there is the same normative language in RFC7252 or RFC6690. So the text is there to recap these requirements to the reader. &= nbsp;Of course we can remove the capitals “SHOULD”->”s= hould” but it may be less clear to the reader that there exists an RF= C2119-level requirement on the topic.  I agree that the “REQUIRE= D” keywords can be removed in these sections since they can confuse.

(But perhaps there’= s a better way to say for certain bullet items that they are not merely our= recommendation but there are protocol requirements on it.)

 <= /p>

2- on the upper bound for= Token re-use ([Akbar-9] item): I remember discussions in CoRE in the past,= always coming to the conclusion that there is no upper bound for server response time (similar to HTTP). We could say we put the = Token re-use time for a client at (NON_LIFETIME + MAX_LATENCY + 10 = minutes), just as a default for the case that the max response latency of a= ny of the CoAP servers is unknown. (I.e. we don’t impose a limit onto CoAP where there is none currently.) Th= en at the same time we could e.g. recommend that a CoAP server by default r= esponds to multicast requests within MAX_SERVER_RESPONSE_DELAY =3D 5 minute= s, again without forcing a limit for those cases where longer is needed.

Would that work for you?<= o:p>

 <= /p>

Esko

 <= /p>

 <= /p>

From: barrylei= ba@gmail.com [mailto:barryleiba@gmail.com] On Behalf Of Barry Leiba
Sent: Wednesday, July 30, 2014 08:20
To: Rahman, Akbar
Cc: core WG; draft-ietf-core-groupcomm.all@tools.ietf.org; Dijk, Esk= o
Subject: Re: [core] AD review of draft-ietf-core-groupcomm-20

 

Thank you for the revised feedback and clarification= s.  My co-author,
Esko, and I have discussed them off line and following  are our
consolidated responses (identified as "**[Authors-Response-x]"). =  Once
you have approved our final answers, we will aim to do a quick update of the draft to incorporate all your comments.

 

Great, thanks.  I think we're all set.  Al= l your responses are OK with me.

 

**[Authors-Response-5] - Ok.  It looks like we = should consider to make
the RD reference as normative.  But before we close this issue, could<= br> you point us to any RFC that defines the criteria for making the
decision between Informative vs Normative reference?

 

There is no RFC, but there is an IESG Statement:

Look at the second paragraph and the first note.

 

**[Authors-Response-12] - Ok, we will re-write the e= ntire section 2.8
without any RFC2119 language as you suggested.  Also, perhaps we shoul= d
also re-write section 2.9 without any RFC2119 language as it is a
similar section.  What do you think?

 

That seems sensible.  Personally I think it's j= ust as good to say things like "IP multicasts requests are always Non-= confirmable," instead of "An IP multicast request MUST be Non-con= firmable," though both are OK.  I don't think the capitalize= d key words add anything there.

 

Barry


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_031DD135F9160444ABBE3B0C36CED61836E04BB2AMSPRD9003MB066_-- From nobody Wed Jul 30 04:19:51 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 380E91A00FA for ; Wed, 30 Jul 2014 04:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPV_tQCT7Ujv for ; Wed, 30 Jul 2014 04:19:43 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E5801B2873 for ; Wed, 30 Jul 2014 04:19:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKS34708; Wed, 30 Jul 2014 11:19:40 +0000 (GMT) Received: from SZXEMA408-HUB.china.huawei.com (10.82.72.40) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 30 Jul 2014 12:19:38 +0100 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.128]) by SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id 14.03.0158.001; Wed, 30 Jul 2014 19:19:35 +0800 From: Likepeng To: "Dijk, Esko" , Barry Leiba , "Rahman, Akbar" Thread-Topic: [core] AD review of draft-ietf-core-groupcomm-20 Thread-Index: AQHPqpAvfUZBdqPRSE2pN6I21Hu2B5u3hLwAgAAcsQCAAEXyAIAAksYQ Date: Wed, 30 Jul 2014 11:19:35 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F25817CFB9@SZXEMA501-MBS.china.huawei.com> References: <031DD135F9160444ABBE3B0C36CED61836E04BB2@AMSPRD9003MB066.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED61836E04BB2@AMSPRD9003MB066.MGDPHG.emi.philips.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.167.122] Content-Type: multipart/alternative; boundary="_000_34966E97BE8AD64EAE9D3D6E4DEE36F25817CFB9SZXEMA501MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/core/KAhrqoI6_HuJhdz1zXsSo69eMKg Cc: "draft-ietf-core-groupcomm.all@tools.ietf.org" , core WG Subject: Re: [core] AD review of draft-ietf-core-groupcomm-20 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 30 Jul 2014 11:19:45 -0000 --_000_34966E97BE8AD64EAE9D3D6E4DEE36F25817CFB9SZXEMA501MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 PldlIGNvdWxkIHNheSB3ZSBwdXQgdGhlIFRva2VuIHJlLXVzZSB0aW1lIGZvciBhIGNsaWVudCBh dCAoTk9OX0xJRkVUSU1FICsgTUFYX0xBVEVOQ1kgKyAxMCBtaW51dGVzKSwganVzdCBhcyBhIGRl ZmF1bHQgZm9yIHRoZSBjYXNlIHRoYXQgdGhlIG1heCByZXNwb25zZSBsYXRlbmN5IG9mIGFueSBv ZiB0aGUgQ29BUCBzZXJ2ZXJzIGlzIHVua25vd24uIChJLmUuIHdlIGRvbqGvdCBpbXBvc2UgYSBs aW1pdCBvbnRvIENvQVAgd2hlcmUgdGhlcmUgaXMgbm9uZSBjdXJyZW50bHkuKQ0KDQoxMCBtaW51 dGVzPyBJcyBpdCB0b28gbG9uZz8NCg0KPlRoZW4gYXQgdGhlIHNhbWUgdGltZSB3ZSBjb3VsZCBl LmcuIHJlY29tbWVuZCB0aGF0IGEgQ29BUCBzZXJ2ZXIgYnkgZGVmYXVsdCByZXNwb25kcyB0byBt dWx0aWNhc3QgcmVxdWVzdHMgd2l0aGluIE1BWF9TRVJWRVJfUkVTUE9OU0VfREVMQVkgPSA1IG1p bnV0ZXMsIGFnYWluIHdpdGhvdXQgZm9yY2luZyBhIGxpbWl0IGZvciB0aG9zZSBjYXNlcyB3aGVy ZSBsb25nZXIgaXMgbmVlZGVkLg0KDQpXaHkgZG8gd2UgdXNlIDUgbWludXRlcyBmb3IgbXVsdGlj YXN0IHJlcXVlc3RzIHdoaWxlIG1vcmUgdGhhbiAxMCBtaW51dGVzIGZvciBUb2tlbiByZXVzZT8N Cg0KVGhhbmtzLA0KDQpLaW5kIFJlZ2FyZHMNCktlcGVuZw0KDQq3orz+yMs6IGNvcmUgW21haWx0 bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gRGlqaywgRXNrbw0Kt6LLzcqxvOQ6IDIwMTTE 6jfUwjMwyNUgMTg6MzENCsrVvP7IyzogQmFycnkgTGVpYmE7IFJhaG1hbiwgQWtiYXINCrOty806 IGRyYWZ0LWlldGYtY29yZS1ncm91cGNvbW0uYWxsQHRvb2xzLmlldGYub3JnOyBjb3JlIFdHDQrW 98ziOiBSZTogW2NvcmVdIEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLWNvcmUtZ3JvdXBjb21tLTIw DQoNCkhlbGxvIEJhcnJ5LA0KDQpNYW55IHRoYW5rcyBmb3IgeW91ciB0aG9yb3VnaCByZXZpZXch IEJlbG93IGFkZGl0aW9uYWwgY29tbWVudHMgZnJvbSBteSBzaWRlIHRoYXQgSSB0aGluayBhcmUg aW1wb3J0YW50IHRvIG1lbnRpb24uDQoNCjEtIG9uIHRoZSB1c2Ugb2YgUkZDMjExOSBsYW5ndWFn ZSBpbiBzZWN0aW9uIDIuOCBhbmQgMi45OiBmb3Igc29tZSBpbnN0YW5jZXMgd2hlcmUgdGhpcyBs YW5ndWFnZSBpcyB1c2VkLCB0aGVyZSBpcyB0aGUgc2FtZSBub3JtYXRpdmUgbGFuZ3VhZ2UgaW4g UkZDNzI1MiBvciBSRkM2NjkwLiBTbyB0aGUgdGV4dCBpcyB0aGVyZSB0byByZWNhcCB0aGVzZSBy ZXF1aXJlbWVudHMgdG8gdGhlIHJlYWRlci4gIE9mIGNvdXJzZSB3ZSBjYW4gcmVtb3ZlIHRoZSBj YXBpdGFscyChsFNIT1VMRKGxLT6hsXNob3VsZKGxIGJ1dCBpdCBtYXkgYmUgbGVzcyBjbGVhciB0 byB0aGUgcmVhZGVyIHRoYXQgdGhlcmUgZXhpc3RzIGFuIFJGQzIxMTktbGV2ZWwgcmVxdWlyZW1l bnQgb24gdGhlIHRvcGljLiAgSSBhZ3JlZSB0aGF0IHRoZSChsFJFUVVJUkVEobEga2V5d29yZHMg Y2FuIGJlIHJlbW92ZWQgaW4gdGhlc2Ugc2VjdGlvbnMgc2luY2UgdGhleSBjYW4gY29uZnVzZS4N CihCdXQgcGVyaGFwcyB0aGVyZaGvcyBhIGJldHRlciB3YXkgdG8gc2F5IGZvciBjZXJ0YWluIGJ1 bGxldCBpdGVtcyB0aGF0IHRoZXkgYXJlIG5vdCBtZXJlbHkgb3VyIHJlY29tbWVuZGF0aW9uIGJ1 dCB0aGVyZSBhcmUgcHJvdG9jb2wgcmVxdWlyZW1lbnRzIG9uIGl0LikNCg0KMi0gb24gdGhlIHVw cGVyIGJvdW5kIGZvciBUb2tlbiByZS11c2UgKFtBa2Jhci05XSBpdGVtKTogSSByZW1lbWJlciBk aXNjdXNzaW9ucyBpbiBDb1JFIGluIHRoZSBwYXN0LCBhbHdheXMgY29taW5nIHRvIHRoZSBjb25j bHVzaW9uIHRoYXQgdGhlcmUgaXMgbm8gdXBwZXIgYm91bmQgZm9yIHNlcnZlciByZXNwb25zZSB0 aW1lIChzaW1pbGFyIHRvIEhUVFApLiBXZSBjb3VsZCBzYXkgd2UgcHV0IHRoZSBUb2tlbiByZS11 c2UgdGltZSBmb3IgYSBjbGllbnQgYXQgKE5PTl9MSUZFVElNRSArIE1BWF9MQVRFTkNZICsgMTAg bWludXRlcyksIGp1c3QgYXMgYSBkZWZhdWx0IGZvciB0aGUgY2FzZSB0aGF0IHRoZSBtYXggcmVz cG9uc2UgbGF0ZW5jeSBvZiBhbnkgb2YgdGhlIENvQVAgc2VydmVycyBpcyB1bmtub3duLiAoSS5l LiB3ZSBkb26hr3QgaW1wb3NlIGEgbGltaXQgb250byBDb0FQIHdoZXJlIHRoZXJlIGlzIG5vbmUg Y3VycmVudGx5LikgVGhlbiBhdCB0aGUgc2FtZSB0aW1lIHdlIGNvdWxkIGUuZy4gcmVjb21tZW5k IHRoYXQgYSBDb0FQIHNlcnZlciBieSBkZWZhdWx0IHJlc3BvbmRzIHRvIG11bHRpY2FzdCByZXF1 ZXN0cyB3aXRoaW4gTUFYX1NFUlZFUl9SRVNQT05TRV9ERUxBWSA9IDUgbWludXRlcywgYWdhaW4g d2l0aG91dCBmb3JjaW5nIGEgbGltaXQgZm9yIHRob3NlIGNhc2VzIHdoZXJlIGxvbmdlciBpcyBu ZWVkZWQuDQpXb3VsZCB0aGF0IHdvcmsgZm9yIHlvdT8NCg0KRXNrbw0KDQoNCkZyb206IGJhcnJ5 bGVpYmFAZ21haWwuY29tPG1haWx0bzpiYXJyeWxlaWJhQGdtYWlsLmNvbT4gW21haWx0bzpiYXJy eWxlaWJhQGdtYWlsLmNvbV0gT24gQmVoYWxmIE9mIEJhcnJ5IExlaWJhDQpTZW50OiBXZWRuZXNk YXksIEp1bHkgMzAsIDIwMTQgMDg6MjANClRvOiBSYWhtYW4sIEFrYmFyDQpDYzogY29yZSBXRzsg ZHJhZnQtaWV0Zi1jb3JlLWdyb3VwY29tbS5hbGxAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0 LWlldGYtY29yZS1ncm91cGNvbW0uYWxsQHRvb2xzLmlldGYub3JnPjsgRGlqaywgRXNrbw0KU3Vi amVjdDogUmU6IFtjb3JlXSBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1jb3JlLWdyb3VwY29tbS0y MA0KDQpUaGFuayB5b3UgZm9yIHRoZSByZXZpc2VkIGZlZWRiYWNrIGFuZCBjbGFyaWZpY2F0aW9u cy4gIE15IGNvLWF1dGhvciwNCkVza28sIGFuZCBJIGhhdmUgZGlzY3Vzc2VkIHRoZW0gb2ZmIGxp bmUgYW5kIGZvbGxvd2luZyAgYXJlIG91cg0KY29uc29saWRhdGVkIHJlc3BvbnNlcyAoaWRlbnRp ZmllZCBhcyAiKipbQXV0aG9ycy1SZXNwb25zZS14XSIpLiAgT25jZQ0KeW91IGhhdmUgYXBwcm92 ZWQgb3VyIGZpbmFsIGFuc3dlcnMsIHdlIHdpbGwgYWltIHRvIGRvIGEgcXVpY2sgdXBkYXRlIG9m DQp0aGUgZHJhZnQgdG8gaW5jb3Jwb3JhdGUgYWxsIHlvdXIgY29tbWVudHMuDQoNCkdyZWF0LCB0 aGFua3MuICBJIHRoaW5rIHdlJ3JlIGFsbCBzZXQuICBBbGwgeW91ciByZXNwb25zZXMgYXJlIE9L IHdpdGggbWUuDQoNCioqW0F1dGhvcnMtUmVzcG9uc2UtNV0gLSBPay4gIEl0IGxvb2tzIGxpa2Ug d2Ugc2hvdWxkIGNvbnNpZGVyIHRvIG1ha2UNCnRoZSBSRCByZWZlcmVuY2UgYXMgbm9ybWF0aXZl LiAgQnV0IGJlZm9yZSB3ZSBjbG9zZSB0aGlzIGlzc3VlLCBjb3VsZA0KeW91IHBvaW50IHVzIHRv IGFueSBSRkMgdGhhdCBkZWZpbmVzIHRoZSBjcml0ZXJpYSBmb3IgbWFraW5nIHRoZQ0KZGVjaXNp b24gYmV0d2VlbiBJbmZvcm1hdGl2ZSB2cyBOb3JtYXRpdmUgcmVmZXJlbmNlPw0KDQpUaGVyZSBp cyBubyBSRkMsIGJ1dCB0aGVyZSBpcyBhbiBJRVNHIFN0YXRlbWVudDoNCmh0dHA6Ly93d3cuaWV0 Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvbm9ybWF0aXZlLWluZm9ybWF0aXZlLmh0bWwNCkxvb2sgYXQg dGhlIHNlY29uZCBwYXJhZ3JhcGggYW5kIHRoZSBmaXJzdCBub3RlLg0KDQoqKltBdXRob3JzLVJl c3BvbnNlLTEyXSAtIE9rLCB3ZSB3aWxsIHJlLXdyaXRlIHRoZSBlbnRpcmUgc2VjdGlvbiAyLjgN CndpdGhvdXQgYW55IFJGQzIxMTkgbGFuZ3VhZ2UgYXMgeW91IHN1Z2dlc3RlZC4gIEFsc28sIHBl cmhhcHMgd2Ugc2hvdWxkDQphbHNvIHJlLXdyaXRlIHNlY3Rpb24gMi45IHdpdGhvdXQgYW55IFJG QzIxMTkgbGFuZ3VhZ2UgYXMgaXQgaXMgYQ0Kc2ltaWxhciBzZWN0aW9uLiAgV2hhdCBkbyB5b3Ug dGhpbms/DQoNClRoYXQgc2VlbXMgc2Vuc2libGUuICBQZXJzb25hbGx5IEkgdGhpbmsgaXQncyBq dXN0IGFzIGdvb2QgdG8gc2F5IHRoaW5ncyBsaWtlICJJUCBtdWx0aWNhc3RzIHJlcXVlc3RzIGFy ZSBhbHdheXMgTm9uLWNvbmZpcm1hYmxlLCIgaW5zdGVhZCBvZiAiQW4gSVAgbXVsdGljYXN0IHJl cXVlc3QgTVVTVCBiZSBOb24tY29uZmlybWFibGUsIiB0aG91Z2ggYm90aCBhcmUgT0suICBJIGRv bid0IHRoaW5rIHRoZSBjYXBpdGFsaXplZCBrZXkgd29yZHMgYWRkIGFueXRoaW5nIHRoZXJlLg0K DQpCYXJyeQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVGhlIGluZm9ybWF0 aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3NhZ2UgbWF5IGJlIGNvbmZpZGVudGlhbCBhbmQgbGVn YWxseSBwcm90ZWN0ZWQgdW5kZXIgYXBwbGljYWJsZSBsYXcuIFRoZSBtZXNzYWdlIGlzIGludGVu ZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZShzKS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgdXNlLCBmb3J3 YXJkaW5nLCBkaXNzZW1pbmF0aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyBtZXNzYWdlIGlz IHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGFyZSBub3Qg dGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBieSByZXR1 cm4gZS1tYWlsIGFuZCBkZXN0cm95IGFsbCBjb3BpZXMgb2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2Uu DQo= --_000_34966E97BE8AD64EAE9D3D6E4DEE36F25817CFB9SZXEMA501MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

>We cou= ld say we put the Token re-use time for a client at (NON_LIFETIME + MAX= _LATENCY + 10 minutes), just as a default for the case that the max response latency of any of the CoAP servers is unknown. (I.e. we don=A1=AF= t impose a limit onto CoAP where there is none currently.)

 = ;

10 minutes= ? Is it too long?

 = ;

>Then a= t the same time we could e.g. recommend that a CoAP server by default respo= nds to multicast requests within MAX_SERVER_RESPONSE_DELAY =3D 5 minutes, again without forcing a limit for those cases where longer is n= eeded.

 = ;

Why do we = use 5 minutes for multicast requests while more than 10 minutes for Token r= euse?

 = ;

Thanks,

 = ;

Kind Regar= ds

Kepeng

 = ;

=B7=A2=BC=FE=C8=CB: core [mailto:core-bou= nces@ietf.org] =B4=FA=B1=ED = Dijk, Esko
=B7=A2=CB=CD= =CA=B1=BC=E4: 2014=C4=EA7=D4=C2<= span lang=3D"EN-US">30=C8=D5 18:31
=CA=D5=BC=FE=C8=CB: Barry Leiba; Rahman, Akbar
=B3=AD=CB=CD: draft-ietf-core-groupcomm.all@tools.ietf.org; core WG
=D6=F7=CC=E2: Re: [core] AD review of draft-ietf-core-groupcomm-20

 

Hello Barr= y,

 = ;

Many thank= s for your thorough review! Below additional comments from my side that I t= hink are important to mention.

 = ;

1- on the = use of RFC2119 language in section 2.8 and 2.9: for some instances where th= is language is used, there is the same normative language in RFC7252 or RFC6690. So the text is there to recap these requirements to= the reader.  Of course we can remove the capitals =A1=B0SHOULD=A1=B1-= >=A1=B1should=A1=B1 but it may be less clear to the reader that there ex= ists an RFC2119-level requirement on the topic.  I agree that the =A1=B0REQUIRED=A1=B1 keywords can be removed in these sections since t= hey can confuse.

(But perha= ps there=A1=AFs a better way to say for certain bullet items that they are = not merely our recommendation but there are protocol requirements on it.)

 = ;

2- on the = upper bound for Token re-use ([Akbar-9] item): I remember discussions in Co= RE in the past, always coming to the conclusion that there is no upper bound for server response time (similar to HTTP). We could say= we put the Token re-use time for a client at (NON_LIFETIME + MAX_LATEN= CY + 10 minutes), just as a default for the case that the max response = latency of any of the CoAP servers is unknown. (I.e. we don=A1=AFt impose a limit onto CoAP where there is none currently= .) Then at the same time we could e.g. recommend that a CoAP server by defa= ult responds to multicast requests within MAX_SERVER_RESPONSE_DELAY =3D 5 m= inutes, again without forcing a limit for those cases where longer is needed.

Would that= work for you?

 = ;

Esko<= /o:p>

 = ;

 = ;

From: barryleiba@gmail.com [mailto:barryleiba@gmail.com] On Behalf Of Barry Leiba
Sent: Wednesday, July 30, 2014 08:20
To: Rahman, Akbar
Cc: core WG; draft-ietf-core-groupcomm.all@tools.ietf.org; Dijk, Esko
Subject: Re: [core] AD review of draft-ietf-core-groupcomm-20

 

Thank you for the revised feedb= ack and clarifications.  My co-author,
Esko, and I have discussed them off line and following  are our
consolidated responses (identified as "**[Authors-Response-x]"). =  Once
you have approved our final answers, we will aim to do a quick update of the draft to incorporate all your comments.

 

Great, thanks.  I think we= 're all set.  All your responses are OK with me.

 

**[Authors-Response-5] - Ok. &n= bsp;It looks like we should consider to make
the RD reference as normative.  But before we close this issue, could<= br> you point us to any RFC that defines the criteria for making the
decision between Informative vs Normative reference?

 

There is no RFC, but there is a= n IESG Statement:

Look at the second paragraph an= d the first note.

 

**[Authors-Response-12] - Ok, w= e will re-write the entire section 2.8
without any RFC2119 language as you suggested.  Also, perhaps we shoul= d
also re-write section 2.9 without any RFC2119 language as it is a
similar section.  What do you think?

 

That seems sensible.  Pers= onally I think it's just as good to say things like "IP multicasts req= uests are always Non-confirmable," instead of "An IP multicast re= quest MUST be Non-confirmable," though both are OK.  I don't think the capitalized key words add anything there.

 

Barry

 

The information = contained in this message may be confidential and legally protected under a= pplicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any us= e, forwarding, dissemination, or reproduction of this message is strictly p= rohibited and may be unlawful. If you are not the intended recipient, pleas= e contact the sender by return e-mail and destroy all copies of the original message.

--_000_34966E97BE8AD64EAE9D3D6E4DEE36F25817CFB9SZXEMA501MBSchi_-- From nobody Wed Jul 30 04:51:02 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4868B1B278F for ; Wed, 30 Jul 2014 04:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.15 X-Spam-Level: X-Spam-Status: No, score=-0.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8UqzQXktl4D for ; Wed, 30 Jul 2014 04:50:57 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lrp0013.outbound.protection.outlook.com [213.199.154.13]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 648081A0378 for ; Wed, 30 Jul 2014 04:50:56 -0700 (PDT) Received: from DBXPR04CA010.eurprd04.prod.outlook.com (10.255.191.158) by DB4PR04MB0639.eurprd04.prod.outlook.com (10.242.221.151) with Microsoft SMTP Server (TLS) id 15.0.995.14; Wed, 30 Jul 2014 11:50:52 +0000 Received: from DB3FFO11FD035.protection.gbl (2a01:111:f400:7e04::170) by DBXPR04CA010.outlook.office365.com (2a01:111:e400:9800::30) with Microsoft SMTP Server (TLS) id 15.0.995.14 via Frontend Transport; Wed, 30 Jul 2014 11:50:52 +0000 Received: from mail.philips.com (206.191.242.68) by DB3FFO11FD035.mail.protection.outlook.com (10.47.217.66) with Microsoft SMTP Server (TLS) id 15.0.980.11 via Frontend Transport; Wed, 30 Jul 2014 11:50:51 +0000 Received: from AMSPRD9003MB066.MGDPHG.emi.philips.com ([169.254.5.122]) by AMSPRD9003HT003.MGDPHG.emi.philips.com ([141.251.33.80]) with mapi id 14.16.0459.000; Wed, 30 Jul 2014 11:50:51 +0000 From: "Dijk, Esko" To: Likepeng , Barry Leiba , "Rahman, Akbar" Thread-Topic: [core] AD review of draft-ietf-core-groupcomm-20 Thread-Index: AQHPqpAseQerMW+gRECZB6herPpJipu4CtgAgAAcsgCAADW6AIAAHeSAgAAHrvA= Date: Wed, 30 Jul 2014 11:50:50 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED61836E04C55@AMSPRD9003MB066.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED61836E04BB2@AMSPRD9003MB066.MGDPHG.emi.philips.com> <34966E97BE8AD64EAE9D3D6E4DEE36F25817CFB9@SZXEMA501-MBS.china.huawei.com> In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F25817CFB9@SZXEMA501-MBS.china.huawei.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.104] Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED61836E04C55AMSPRD9003MB066_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:206.191.242.68; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(428002)(189002)(199002)(164054003)(76104003)(52314003)(71364002)(85714005)(66654002)(374574003)(66066001)(84676001)(84326002)(93886003)(512914005)(71186001)(20776003)(81342001)(31966008)(55846006)(16236675004)(77982001)(64706001)(15975445006)(79102001)(68736004)(97736001)(76482001)(4396001)(21056001)(80022001)(46102001)(81542001)(104016003)(19617315012)(83072002)(85852003)(106116001)(19625215002)(101416001)(105586002)(74662001)(106466001)(86362001)(6806004)(81156004)(107046002)(99396002)(2656002)(85306003)(19580395003)(16234385003)(15202345003)(77096002)(33656002)(76176999)(69596002)(50986999)(74502001)(92726001)(92566001)(54356999)(83322001)(19580405001)(19300405004)(44976005)(87936001)(95666004)(567094001); DIR:OUT; SFP:; SCL:1; SRVR:DB4PR04MB0639; H:mail.philips.com; FPR:; MLV:sfv; PTR:ErrorRetry; MX:1; A:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 0288CD37D9 Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is 206.191.242.68) smtp.mailfrom=esko.dijk@philips.com; X-OriginatorOrg: philips.com Archived-At: http://mailarchive.ietf.org/arch/msg/core/Xl7HMdaQiyWgZ2u1YkrpYFm9Td8 Cc: "draft-ietf-core-groupcomm.all@tools.ietf.org" , core WG Subject: Re: [core] AD review of draft-ietf-core-groupcomm-20 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 30 Jul 2014 11:51:00 -0000 --_000_031DD135F9160444ABBE3B0C36CED61836E04C55AMSPRD9003MB066_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgS2VwZW5nLA0KDQo+IDEwIG1pbnV0ZXM/IElzIGl0IHRvbyBsb25nPw0KDQpUaGUgTk9OX0xJ RkVUSU1FICsgTUFYX0xBVEVOQ1kgaXMgYWxyZWFkeSB+NCBtaW51dGVzIGFueXdheSwgc28gaXQg Y291bGQgYmUgYXQgbGVhc3Qgc29tZXRoaW5nIGluIHRoZSBzYW1lIG9yZGVyIEkgdGhpbmsuIElu IHRoZSAxLTEwIG1pbnV0ZXMgcmFuZ2U/DQoNCj4gV2h5IGRvIHdlIHVzZSA1IG1pbnV0ZXMgZm9y IG11bHRpY2FzdCByZXF1ZXN0cyB3aGlsZSBtb3JlIHRoYW4gMTAgbWludXRlcyBmb3IgVG9rZW4g cmV1c2U/DQoNClRoZSBUb2tlbiByZS11c2UgdGltZSBoYXMgdG8gYmUgbG9uZ2VyIHRoYW4gdGhl IE1BWF9TRVJWRVJfUkVTUE9OU0VfREVMQVkgYXQgbGVhc3QsIHdpdGggc29tZSBzYWZldHkgbWFy Z2luLiBPdGhlciBwcm9wb3NhbHMgYXJlIHdlbGNvbWUhDQoNCkVza28NCg0KDQoNCkZyb206IExp a2VwZW5nIFttYWlsdG86bGlrZXBlbmdAaHVhd2VpLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgSnVs eSAzMCwgMjAxNCAxMzoyMA0KVG86IERpamssIEVza287IEJhcnJ5IExlaWJhOyBSYWhtYW4sIEFr YmFyDQpDYzogZHJhZnQtaWV0Zi1jb3JlLWdyb3VwY29tbS5hbGxAdG9vbHMuaWV0Zi5vcmc7IGNv cmUgV0cNClN1YmplY3Q6IFJlOiBbY29yZV0gQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtY29yZS1n cm91cGNvbW0tMjANCg0KPldlIGNvdWxkIHNheSB3ZSBwdXQgdGhlIFRva2VuIHJlLXVzZSB0aW1l IGZvciBhIGNsaWVudCBhdCAoTk9OX0xJRkVUSU1FICsgTUFYX0xBVEVOQ1kgKyAxMCBtaW51dGVz KSwganVzdCBhcyBhIGRlZmF1bHQgZm9yIHRoZSBjYXNlIHRoYXQgdGhlIG1heCByZXNwb25zZSBs YXRlbmN5IG9mIGFueSBvZiB0aGUgQ29BUCBzZXJ2ZXJzIGlzIHVua25vd24uIChJLmUuIHdlIGRv bqGvdCBpbXBvc2UgYSBsaW1pdCBvbnRvIENvQVAgd2hlcmUgdGhlcmUgaXMgbm9uZSBjdXJyZW50 bHkuKQ0KDQoxMCBtaW51dGVzPyBJcyBpdCB0b28gbG9uZz8NCg0KPlRoZW4gYXQgdGhlIHNhbWUg dGltZSB3ZSBjb3VsZCBlLmcuIHJlY29tbWVuZCB0aGF0IGEgQ29BUCBzZXJ2ZXIgYnkgZGVmYXVs dCByZXNwb25kcyB0byBtdWx0aWNhc3QgcmVxdWVzdHMgd2l0aGluIE1BWF9TRVJWRVJfUkVTUE9O U0VfREVMQVkgPSA1IG1pbnV0ZXMsIGFnYWluIHdpdGhvdXQgZm9yY2luZyBhIGxpbWl0IGZvciB0 aG9zZSBjYXNlcyB3aGVyZSBsb25nZXIgaXMgbmVlZGVkLg0KDQpXaHkgZG8gd2UgdXNlIDUgbWlu dXRlcyBmb3IgbXVsdGljYXN0IHJlcXVlc3RzIHdoaWxlIG1vcmUgdGhhbiAxMCBtaW51dGVzIGZv ciBUb2tlbiByZXVzZT8NCg0KVGhhbmtzLA0KDQpLaW5kIFJlZ2FyZHMNCktlcGVuZw0KDQq3orz+ yMs6IGNvcmUgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gRGlqaywgRXNrbw0K t6LLzcqxvOQ6IDIwMTTE6jfUwjMwyNUgMTg6MzENCsrVvP7IyzogQmFycnkgTGVpYmE7IFJhaG1h biwgQWtiYXINCrOty806IGRyYWZ0LWlldGYtY29yZS1ncm91cGNvbW0uYWxsQHRvb2xzLmlldGYu b3JnPG1haWx0bzpkcmFmdC1pZXRmLWNvcmUtZ3JvdXBjb21tLmFsbEB0b29scy5pZXRmLm9yZz47 IGNvcmUgV0cNCtb3zOI6IFJlOiBbY29yZV0gQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtY29yZS1n cm91cGNvbW0tMjANCg0KSGVsbG8gQmFycnksDQoNCk1hbnkgdGhhbmtzIGZvciB5b3VyIHRob3Jv dWdoIHJldmlldyEgQmVsb3cgYWRkaXRpb25hbCBjb21tZW50cyBmcm9tIG15IHNpZGUgdGhhdCBJ IHRoaW5rIGFyZSBpbXBvcnRhbnQgdG8gbWVudGlvbi4NCg0KMS0gb24gdGhlIHVzZSBvZiBSRkMy MTE5IGxhbmd1YWdlIGluIHNlY3Rpb24gMi44IGFuZCAyLjk6IGZvciBzb21lIGluc3RhbmNlcyB3 aGVyZSB0aGlzIGxhbmd1YWdlIGlzIHVzZWQsIHRoZXJlIGlzIHRoZSBzYW1lIG5vcm1hdGl2ZSBs YW5ndWFnZSBpbiBSRkM3MjUyIG9yIFJGQzY2OTAuIFNvIHRoZSB0ZXh0IGlzIHRoZXJlIHRvIHJl Y2FwIHRoZXNlIHJlcXVpcmVtZW50cyB0byB0aGUgcmVhZGVyLiAgT2YgY291cnNlIHdlIGNhbiBy ZW1vdmUgdGhlIGNhcGl0YWxzIKGwU0hPVUxEobEtPqGxc2hvdWxkobEgYnV0IGl0IG1heSBiZSBs ZXNzIGNsZWFyIHRvIHRoZSByZWFkZXIgdGhhdCB0aGVyZSBleGlzdHMgYW4gUkZDMjExOS1sZXZl bCByZXF1aXJlbWVudCBvbiB0aGUgdG9waWMuICBJIGFncmVlIHRoYXQgdGhlIKGwUkVRVUlSRUSh sSBrZXl3b3JkcyBjYW4gYmUgcmVtb3ZlZCBpbiB0aGVzZSBzZWN0aW9ucyBzaW5jZSB0aGV5IGNh biBjb25mdXNlLg0KKEJ1dCBwZXJoYXBzIHRoZXJloa9zIGEgYmV0dGVyIHdheSB0byBzYXkgZm9y IGNlcnRhaW4gYnVsbGV0IGl0ZW1zIHRoYXQgdGhleSBhcmUgbm90IG1lcmVseSBvdXIgcmVjb21t ZW5kYXRpb24gYnV0IHRoZXJlIGFyZSBwcm90b2NvbCByZXF1aXJlbWVudHMgb24gaXQuKQ0KDQoy LSBvbiB0aGUgdXBwZXIgYm91bmQgZm9yIFRva2VuIHJlLXVzZSAoW0FrYmFyLTldIGl0ZW0pOiBJ IHJlbWVtYmVyIGRpc2N1c3Npb25zIGluIENvUkUgaW4gdGhlIHBhc3QsIGFsd2F5cyBjb21pbmcg dG8gdGhlIGNvbmNsdXNpb24gdGhhdCB0aGVyZSBpcyBubyB1cHBlciBib3VuZCBmb3Igc2VydmVy IHJlc3BvbnNlIHRpbWUgKHNpbWlsYXIgdG8gSFRUUCkuIFdlIGNvdWxkIHNheSB3ZSBwdXQgdGhl IFRva2VuIHJlLXVzZSB0aW1lIGZvciBhIGNsaWVudCBhdCAoTk9OX0xJRkVUSU1FICsgTUFYX0xB VEVOQ1kgKyAxMCBtaW51dGVzKSwganVzdCBhcyBhIGRlZmF1bHQgZm9yIHRoZSBjYXNlIHRoYXQg dGhlIG1heCByZXNwb25zZSBsYXRlbmN5IG9mIGFueSBvZiB0aGUgQ29BUCBzZXJ2ZXJzIGlzIHVu a25vd24uIChJLmUuIHdlIGRvbqGvdCBpbXBvc2UgYSBsaW1pdCBvbnRvIENvQVAgd2hlcmUgdGhl cmUgaXMgbm9uZSBjdXJyZW50bHkuKSBUaGVuIGF0IHRoZSBzYW1lIHRpbWUgd2UgY291bGQgZS5n LiByZWNvbW1lbmQgdGhhdCBhIENvQVAgc2VydmVyIGJ5IGRlZmF1bHQgcmVzcG9uZHMgdG8gbXVs dGljYXN0IHJlcXVlc3RzIHdpdGhpbiBNQVhfU0VSVkVSX1JFU1BPTlNFX0RFTEFZID0gNSBtaW51 dGVzLCBhZ2FpbiB3aXRob3V0IGZvcmNpbmcgYSBsaW1pdCBmb3IgdGhvc2UgY2FzZXMgd2hlcmUg bG9uZ2VyIGlzIG5lZWRlZC4NCldvdWxkIHRoYXQgd29yayBmb3IgeW91Pw0KDQpFc2tvDQoNCg0K RnJvbTogYmFycnlsZWliYUBnbWFpbC5jb208bWFpbHRvOmJhcnJ5bGVpYmFAZ21haWwuY29tPiBb bWFpbHRvOmJhcnJ5bGVpYmFAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgQmFycnkgTGVpYmENClNl bnQ6IFdlZG5lc2RheSwgSnVseSAzMCwgMjAxNCAwODoyMA0KVG86IFJhaG1hbiwgQWtiYXINCkNj OiBjb3JlIFdHOyBkcmFmdC1pZXRmLWNvcmUtZ3JvdXBjb21tLmFsbEB0b29scy5pZXRmLm9yZzxt YWlsdG86ZHJhZnQtaWV0Zi1jb3JlLWdyb3VwY29tbS5hbGxAdG9vbHMuaWV0Zi5vcmc+OyBEaWpr LCBFc2tvDQpTdWJqZWN0OiBSZTogW2NvcmVdIEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLWNvcmUt Z3JvdXBjb21tLTIwDQoNClRoYW5rIHlvdSBmb3IgdGhlIHJldmlzZWQgZmVlZGJhY2sgYW5kIGNs YXJpZmljYXRpb25zLiAgTXkgY28tYXV0aG9yLA0KRXNrbywgYW5kIEkgaGF2ZSBkaXNjdXNzZWQg dGhlbSBvZmYgbGluZSBhbmQgZm9sbG93aW5nICBhcmUgb3VyDQpjb25zb2xpZGF0ZWQgcmVzcG9u c2VzIChpZGVudGlmaWVkIGFzICIqKltBdXRob3JzLVJlc3BvbnNlLXhdIikuICBPbmNlDQp5b3Ug aGF2ZSBhcHByb3ZlZCBvdXIgZmluYWwgYW5zd2Vycywgd2Ugd2lsbCBhaW0gdG8gZG8gYSBxdWlj ayB1cGRhdGUgb2YNCnRoZSBkcmFmdCB0byBpbmNvcnBvcmF0ZSBhbGwgeW91ciBjb21tZW50cy4N Cg0KR3JlYXQsIHRoYW5rcy4gIEkgdGhpbmsgd2UncmUgYWxsIHNldC4gIEFsbCB5b3VyIHJlc3Bv bnNlcyBhcmUgT0sgd2l0aCBtZS4NCg0KKipbQXV0aG9ycy1SZXNwb25zZS01XSAtIE9rLiAgSXQg bG9va3MgbGlrZSB3ZSBzaG91bGQgY29uc2lkZXIgdG8gbWFrZQ0KdGhlIFJEIHJlZmVyZW5jZSBh cyBub3JtYXRpdmUuICBCdXQgYmVmb3JlIHdlIGNsb3NlIHRoaXMgaXNzdWUsIGNvdWxkDQp5b3Ug cG9pbnQgdXMgdG8gYW55IFJGQyB0aGF0IGRlZmluZXMgdGhlIGNyaXRlcmlhIGZvciBtYWtpbmcg dGhlDQpkZWNpc2lvbiBiZXR3ZWVuIEluZm9ybWF0aXZlIHZzIE5vcm1hdGl2ZSByZWZlcmVuY2U/ DQoNClRoZXJlIGlzIG5vIFJGQywgYnV0IHRoZXJlIGlzIGFuIElFU0cgU3RhdGVtZW50Og0KaHR0 cDovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9ub3JtYXRpdmUtaW5mb3JtYXRpdmUuaHRt bA0KTG9vayBhdCB0aGUgc2Vjb25kIHBhcmFncmFwaCBhbmQgdGhlIGZpcnN0IG5vdGUuDQoNCioq W0F1dGhvcnMtUmVzcG9uc2UtMTJdIC0gT2ssIHdlIHdpbGwgcmUtd3JpdGUgdGhlIGVudGlyZSBz ZWN0aW9uIDIuOA0Kd2l0aG91dCBhbnkgUkZDMjExOSBsYW5ndWFnZSBhcyB5b3Ugc3VnZ2VzdGVk LiAgQWxzbywgcGVyaGFwcyB3ZSBzaG91bGQNCmFsc28gcmUtd3JpdGUgc2VjdGlvbiAyLjkgd2l0 aG91dCBhbnkgUkZDMjExOSBsYW5ndWFnZSBhcyBpdCBpcyBhDQpzaW1pbGFyIHNlY3Rpb24uICBX aGF0IGRvIHlvdSB0aGluaz8NCg0KVGhhdCBzZWVtcyBzZW5zaWJsZS4gIFBlcnNvbmFsbHkgSSB0 aGluayBpdCdzIGp1c3QgYXMgZ29vZCB0byBzYXkgdGhpbmdzIGxpa2UgIklQIG11bHRpY2FzdHMg cmVxdWVzdHMgYXJlIGFsd2F5cyBOb24tY29uZmlybWFibGUsIiBpbnN0ZWFkIG9mICJBbiBJUCBt dWx0aWNhc3QgcmVxdWVzdCBNVVNUIGJlIE5vbi1jb25maXJtYWJsZSwiIHRob3VnaCBib3RoIGFy ZSBPSy4gIEkgZG9uJ3QgdGhpbmsgdGhlIGNhcGl0YWxpemVkIGtleSB3b3JkcyBhZGQgYW55dGhp bmcgdGhlcmUuDQoNCkJhcnJ5DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpU aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWVzc2FnZSBtYXkgYmUgY29uZmlkZW50 aWFsIGFuZCBsZWdhbGx5IHByb3RlY3RlZCB1bmRlciBhcHBsaWNhYmxlIGxhdy4gVGhlIG1lc3Nh Z2UgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgYWRkcmVzc2VlKHMpLiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFu eSB1c2UsIGZvcndhcmRpbmcsIGRpc3NlbWluYXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlz IG1lc3NhZ2UgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2Vu ZGVyIGJ5IHJldHVybiBlLW1haWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0aGUgb3JpZ2lu YWwgbWVzc2FnZS4NCg== --_000_031DD135F9160444ABBE3B0C36CED61836E04C55AMSPRD9003MB066_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Kepeng,

 <= /p>

> 10 minutes? Is it to= o long?

 <= /p>

The NON_LIFETIME + MA= X_LATENCY is already ~4 minutes anyway, so it could be at least something i= n the same order I think. In the 1-10 minutes range?

 <= /p>

> Why do we use 5 minu= tes for multicast requests while more than 10 minutes for Token reuse?=

 <= /p>

The Token re-use time has= to be longer than the MAX_SERVER_RESPONSE_DELAY at least, with some safety= margin. Other proposals are welcome!

 <= /p>

Esko

 <= /p>

 <= /p>

 <= /p>

From: Likepeng= [mailto:likepeng@huawei.com]
Sent: Wednesday, July 30, 2014 13:20
To: Dijk, Esko; Barry Leiba; Rahman, Akbar
Cc: draft-ietf-core-groupcomm.all@tools.ietf.org; core WG
Subject: Re: [core] AD review of draft-ietf-core-groupcomm-20

 

>We could say we put t= he Token re-use time for a client at (NON_LIFETIME + MAX_LATENCY + = 10 minutes), just as a default for the case that the max response latency of any of the CoAP servers is unknown. (I.e. we don=A1=AFt impose a limit = onto CoAP where there is none currently.)

 <= /p>

10 minutes? Is it too lon= g?

 <= /p>

>Then at the same time= we could e.g. recommend that a CoAP server by default responds to multicas= t requests within MAX_SERVER_RESPONSE_DELAY =3D 5 minutes, again without forcing a limit for those cases where longer is needed.

 <= /p>

Why do we use 5 minutes f= or multicast requests while more than 10 minutes for Token reuse?

 <= /p>

Thanks,=

 <= /p>

Kind Regards<= /o:p>

Kepeng<= /p>

 <= /p>

=B7=A2=BC=FE=C8=CB: core [mailto:core= -bounces@ietf.org] =B4=FA=B1=ED Dijk, Esko
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA7=D4=C230=C8=D5 18:31
=CA=D5=BC=FE=C8=CB: Barry Leiba; Rahman,= Akbar
=B3=AD=CB=CD: draft-ietf-core-groupcomm.all@tools.ietf.org; core WG
=D6=F7=CC=E2: Re: [core] AD review of dr= aft-ietf-core-groupcomm-20

 

Hello Barry,<= /o:p>

 <= /p>

Many thanks for your thor= ough review! Below additional comments from my side that I think are import= ant to mention.

 <= /p>

1- on the use of RFC2119 = language in section 2.8 and 2.9: for some instances where this language is = used, there is the same normative language in RFC7252 or RFC6690. So the text is there to recap these requirements to the reader. &= nbsp;Of course we can remove the capitals =A1=B0SHOULD=A1=B1->=A1=B1shou= ld=A1=B1 but it may be less clear to the reader that there exists an RFC211= 9-level requirement on the topic.  I agree that the =A1=B0REQUIRED=A1= =B1 keywords can be removed in these sections since they can confuse.

(But perhaps there=A1=AFs= a better way to say for certain bullet items that they are not merely our = recommendation but there are protocol requirements on it.)

 <= /p>

2- on the upper bound for= Token re-use ([Akbar-9] item): I remember discussions in CoRE in the past,= always coming to the conclusion that there is no upper bound for server response time (similar to HTTP). We could say we put the = Token re-use time for a client at (NON_LIFETIME + MAX_LATENCY + 10 = minutes), just as a default for the case that the max response latency of a= ny of the CoAP servers is unknown. (I.e. we don=A1=AFt impose a limit onto CoAP where there is none currently.) The= n at the same time we could e.g. recommend that a CoAP server by default re= sponds to multicast requests within MAX_SERVER_RESPONSE_DELAY =3D 5 minutes= , again without forcing a limit for those cases where longer is needed.

Would that work for you?<= /span>

 <= /p>

Esko

 <= /p>

 <= /p>

From: barryleiba@gmail.com [mailto:barryleiba@gmail.com] On Behalf Of Barry Leiba
Sent: Wednesday, July 30, 2014 08:20
To: Rahman, Akbar
Cc: core WG; draft-ietf-core-groupcomm.all@tools.ietf.org; Dijk, Esko
Subject: Re: [core] AD review of draft-ietf-core-groupcomm-20=

 

Thank you for the revised feedback and clarification= s.  My co-author,
Esko, and I have discussed them off line and following  are our
consolidated responses (identified as "**[Authors-Response-x]"). =  Once
you have approved our final answers, we will aim to do a quick update of the draft to incorporate all your comments.

 

Great, thanks.  I think we're all set.  Al= l your responses are OK with me.

 

**[Authors-Response-5] - Ok.  It looks like we = should consider to make
the RD reference as normative.  But before we close this issue, could<= br> you point us to any RFC that defines the criteria for making the
decision between Informative vs Normative reference?

 

There is no RFC, but there is an IESG Statement:

Look at the second paragraph and the first note.

 

**[Authors-Response-12] - Ok, we will re-write the e= ntire section 2.8
without any RFC2119 language as you suggested.  Also, perhaps we shoul= d
also re-write section 2.9 without any RFC2119 language as it is a
similar section.  What do you think?

 

That seems sensible.  Personally I think it's j= ust as good to say things like "IP multicasts requests are always Non-= confirmable," instead of "An IP multicast request MUST be Non-con= firmable," though both are OK.  I don't think the capitalize= d key words add anything there.

 

Barry

 

The information contained in th= is 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 proh= ibited and may be unlawful. If you are not the intended recipient, please c= ontact the sender by return e-mail and destroy all copies of the original message.

--_000_031DD135F9160444ABBE3B0C36CED61836E04C55AMSPRD9003MB066_-- From nobody Wed Jul 30 17:02:26 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0C71A016D for ; Wed, 30 Jul 2014 17:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMLF3Mx9JCxt for ; Wed, 30 Jul 2014 17:02:23 -0700 (PDT) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2ED51A0163 for ; Wed, 30 Jul 2014 17:02:22 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id hy10so3081771vcb.4 for ; Wed, 30 Jul 2014 17:02:22 -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:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=FbGqig4Bgayp1BQn7//Vcxq5Ji0cF1eWzRla3LAHadU=; b=qqGTqrGxshlyzPQkqlsXqlmcABgFV0NGpFBBkA6JOW16qX3rInq155O6PVcc2lZ53b 8VawxsIR4cLsLRH+rBeYi81hrV4lDNxvKRmMVPSR6oi8Unyg0Z0ZfnUBNfXXqrgzyDjK 63xu4S330cJzG5XyxjdKXPWmJIMguxg0EZM08ePK0cR2weO5aHZcw5McboNmwrmS5crH ti4OIgirxCUCuxyWYbMqVEr86IAxekucSqtWE76lscDqgjz4Qbm7GdH22YVOzG2JNxBP tcPNreHj2PfjAvdfgNe+5ku/pF96ds7VV8pPJAw92mx4oDlzt2RbuclepEXuRQQex0RD wCew== MIME-Version: 1.0 X-Received: by 10.52.164.11 with SMTP id ym11mr5966912vdb.74.1406764942183; Wed, 30 Jul 2014 17:02:22 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.181.71 with HTTP; Wed, 30 Jul 2014 17:02:22 -0700 (PDT) In-Reply-To: <031DD135F9160444ABBE3B0C36CED61836E04BB2@AMSPRD9003MB066.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED61836E04BB2@AMSPRD9003MB066.MGDPHG.emi.philips.com> Date: Wed, 30 Jul 2014 20:02:22 -0400 X-Google-Sender-Auth: 1XiJJrzk413x6vNH1pOcaZ5gBXc Message-ID: From: Barry Leiba To: "Dijk, Esko" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/core/L1AXy-lLyhMyY-DcHbiYK_5niEI Cc: "draft-ietf-core-groupcomm.all@tools.ietf.org" , core WG Subject: Re: [core] AD review of draft-ietf-core-groupcomm-20 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 31 Jul 2014 00:02:24 -0000 Hey, Esko. > 1- on the use of RFC2119 language in section 2.8 and 2.9: for some instan= ces > where this language is used, there is the same normative language in RFC7= 252 > or RFC6690. So the text is there to recap these requirements to the reade= r. > Of course we can remove the capitals =E2=80=9CSHOULD=E2=80=9D->=E2=80=9Ds= hould=E2=80=9D but it may be less > clear to the reader that there exists an RFC2119-level requirement on the > topic. I agree that the =E2=80=9CREQUIRED=E2=80=9D keywords can be remov= ed in these > sections since they can confuse. I'm OK with your deciding what to keep and what not to, with respect to the 2119 language in both of those sections. What I'm asking is that you look carefully at it, and address anything that's inconsistent or unclear because of how the 2119 key words are used. As I've pointed out, the traps usually come in using SHOULD when it's not an issue of protocol interop, using combinations of key words that wind up conflicting, and that sort of thing. If you think it's best to leave some 2119 language in there, and what you leave in is clear, consistent, and unambiguous, I'm fine with that. > 2- on the upper bound for Token re-use ([Akbar-9] item): I remember > discussions in CoRE in the past, always coming to the conclusion that the= re > is no upper bound for server response time (similar to HTTP). We could sa= y > we put the Token re-use time for a client at (NON_LIFETIME + MAX_LATENCY = + > 10 minutes), just as a default for the case that the max response latency= of > any of the CoAP servers is unknown. (I.e. we don=E2=80=99t impose a limit= onto CoAP > where there is none currently.) Then at the same time we could e.g. > recommend that a CoAP server by default responds to multicast requests > within MAX_SERVER_RESPONSE_DELAY =3D 5 minutes, again without forcing a l= imit > for those cases where longer is needed. > > Would that work for you? Again, as I said, I'm looking for whatever guidance you can give implementors, so they're not flying blind. Even an explicit statement that no guidance can be given is OK, I think, if that's really the case. So if you think that what you say above is reasonable guidance, and it's the best you can give... let's go with it. I appreciate that discussions have been had, and I'm not trying to make the working group revisit those incessantly. Barry From nobody Wed Jul 30 17:42:40 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B9B1A03C2 for ; Wed, 30 Jul 2014 17:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id teJ6njkcbbA6 for ; Wed, 30 Jul 2014 17:42:34 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 865671A037C for ; Wed, 30 Jul 2014 17:42:32 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKS79535; Thu, 31 Jul 2014 00:42:30 +0000 (GMT) Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 31 Jul 2014 01:42:29 +0100 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.128]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0158.001; Thu, 31 Jul 2014 08:42:23 +0800 From: Likepeng To: "Dijk, Esko" , Barry Leiba , "Rahman, Akbar" Thread-Topic: [core] AD review of draft-ietf-core-groupcomm-20 Thread-Index: AQHPqpAvfUZBdqPRSE2pN6I21Hu2B5u3hLwAgAAcsQCAAEXyAIAAksYQ//+DogCAAV0CoA== Date: Thu, 31 Jul 2014 00:42:22 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F25817D371@SZXEMA501-MBS.china.huawei.com> References: <031DD135F9160444ABBE3B0C36CED61836E04BB2@AMSPRD9003MB066.MGDPHG.emi.philips.com> <34966E97BE8AD64EAE9D3D6E4DEE36F25817CFB9@SZXEMA501-MBS.china.huawei.com> <031DD135F9160444ABBE3B0C36CED61836E04C55@AMSPRD9003MB066.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED61836E04C55@AMSPRD9003MB066.MGDPHG.emi.philips.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.167.122] Content-Type: multipart/alternative; boundary="_000_34966E97BE8AD64EAE9D3D6E4DEE36F25817D371SZXEMA501MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/core/8ownK6LmEKYKKEc3gkio8BHnllA Cc: "draft-ietf-core-groupcomm.all@tools.ietf.org" , core WG Subject: Re: [core] AD review of draft-ietf-core-groupcomm-20 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 31 Jul 2014 00:42:38 -0000 --_000_34966E97BE8AD64EAE9D3D6E4DEE36F25817D371SZXEMA501MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Pk90aGVyIHByb3Bvc2FscyBhcmUgd2VsY29tZSENCg0KSG93IGFib3V0IDQgYW5kIDQ/DQoNCk5P Tl9MSUZFVElNRSArIE1BWF9MQVRFTkNZICsgNCBtaW51dGVzIGZvciB0b2tlbiByZXVzZSwgYW5k IDQgbWludXRlcyBmb3IgbXVsdGljYXN0IHJlcXVlc3RzLg0KDQpLaW5kIFJlZ2FyZHMNCktlcGVu Zw0KDQq3orz+yMs6IERpamssIEVza28gW21haWx0bzplc2tvLmRpamtAcGhpbGlwcy5jb21dDQq3 osvNyrG85DogMjAxNMTqN9TCMzDI1SAxOTo1MQ0KytW8/sjLOiBMaWtlcGVuZzsgQmFycnkgTGVp YmE7IFJhaG1hbiwgQWtiYXINCrOty806IGRyYWZ0LWlldGYtY29yZS1ncm91cGNvbW0uYWxsQHRv b2xzLmlldGYub3JnOyBjb3JlIFdHDQrW98ziOiBSRTogW2NvcmVdIEFEIHJldmlldyBvZiBkcmFm dC1pZXRmLWNvcmUtZ3JvdXBjb21tLTIwDQoNCkhpIEtlcGVuZywNCg0KPiAxMCBtaW51dGVzPyBJ cyBpdCB0b28gbG9uZz8NCg0KVGhlIE5PTl9MSUZFVElNRSArIE1BWF9MQVRFTkNZIGlzIGFscmVh ZHkgfjQgbWludXRlcyBhbnl3YXksIHNvIGl0IGNvdWxkIGJlIGF0IGxlYXN0IHNvbWV0aGluZyBp biB0aGUgc2FtZSBvcmRlciBJIHRoaW5rLiBJbiB0aGUgMS0xMCBtaW51dGVzIHJhbmdlPw0KDQo+ IFdoeSBkbyB3ZSB1c2UgNSBtaW51dGVzIGZvciBtdWx0aWNhc3QgcmVxdWVzdHMgd2hpbGUgbW9y ZSB0aGFuIDEwIG1pbnV0ZXMgZm9yIFRva2VuIHJldXNlPw0KDQpUaGUgVG9rZW4gcmUtdXNlIHRp bWUgaGFzIHRvIGJlIGxvbmdlciB0aGFuIHRoZSBNQVhfU0VSVkVSX1JFU1BPTlNFX0RFTEFZIGF0 IGxlYXN0LCB3aXRoIHNvbWUgc2FmZXR5IG1hcmdpbi4gT3RoZXIgcHJvcG9zYWxzIGFyZSB3ZWxj b21lIQ0KDQpFc2tvDQoNCg0KDQpGcm9tOiBMaWtlcGVuZyBbbWFpbHRvOmxpa2VwZW5nQGh1YXdl aS5jb21dDQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMzAsIDIwMTQgMTM6MjANClRvOiBEaWprLCBF c2tvOyBCYXJyeSBMZWliYTsgUmFobWFuLCBBa2Jhcg0KQ2M6IGRyYWZ0LWlldGYtY29yZS1ncm91 cGNvbW0uYWxsQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWNvcmUtZ3JvdXBjb21t LmFsbEB0b29scy5pZXRmLm9yZz47IGNvcmUgV0cNClN1YmplY3Q6IFJlOiBbY29yZV0gQUQgcmV2 aWV3IG9mIGRyYWZ0LWlldGYtY29yZS1ncm91cGNvbW0tMjANCg0KPldlIGNvdWxkIHNheSB3ZSBw dXQgdGhlIFRva2VuIHJlLXVzZSB0aW1lIGZvciBhIGNsaWVudCBhdCAoTk9OX0xJRkVUSU1FICsg TUFYX0xBVEVOQ1kgKyAxMCBtaW51dGVzKSwganVzdCBhcyBhIGRlZmF1bHQgZm9yIHRoZSBjYXNl IHRoYXQgdGhlIG1heCByZXNwb25zZSBsYXRlbmN5IG9mIGFueSBvZiB0aGUgQ29BUCBzZXJ2ZXJz IGlzIHVua25vd24uIChJLmUuIHdlIGRvbqGvdCBpbXBvc2UgYSBsaW1pdCBvbnRvIENvQVAgd2hl cmUgdGhlcmUgaXMgbm9uZSBjdXJyZW50bHkuKQ0KDQoxMCBtaW51dGVzPyBJcyBpdCB0b28gbG9u Zz8NCg0KPlRoZW4gYXQgdGhlIHNhbWUgdGltZSB3ZSBjb3VsZCBlLmcuIHJlY29tbWVuZCB0aGF0 IGEgQ29BUCBzZXJ2ZXIgYnkgZGVmYXVsdCByZXNwb25kcyB0byBtdWx0aWNhc3QgcmVxdWVzdHMg d2l0aGluIE1BWF9TRVJWRVJfUkVTUE9OU0VfREVMQVkgPSA1IG1pbnV0ZXMsIGFnYWluIHdpdGhv dXQgZm9yY2luZyBhIGxpbWl0IGZvciB0aG9zZSBjYXNlcyB3aGVyZSBsb25nZXIgaXMgbmVlZGVk Lg0KDQpXaHkgZG8gd2UgdXNlIDUgbWludXRlcyBmb3IgbXVsdGljYXN0IHJlcXVlc3RzIHdoaWxl IG1vcmUgdGhhbiAxMCBtaW51dGVzIGZvciBUb2tlbiByZXVzZT8NCg0KVGhhbmtzLA0KDQpLaW5k IFJlZ2FyZHMNCktlcGVuZw0KDQq3orz+yMs6IGNvcmUgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0 Zi5vcmddILT6se0gRGlqaywgRXNrbw0Kt6LLzcqxvOQ6IDIwMTTE6jfUwjMwyNUgMTg6MzENCsrV vP7IyzogQmFycnkgTGVpYmE7IFJhaG1hbiwgQWtiYXINCrOty806IGRyYWZ0LWlldGYtY29yZS1n cm91cGNvbW0uYWxsQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWNvcmUtZ3JvdXBj b21tLmFsbEB0b29scy5pZXRmLm9yZz47IGNvcmUgV0cNCtb3zOI6IFJlOiBbY29yZV0gQUQgcmV2 aWV3IG9mIGRyYWZ0LWlldGYtY29yZS1ncm91cGNvbW0tMjANCg0KSGVsbG8gQmFycnksDQoNCk1h bnkgdGhhbmtzIGZvciB5b3VyIHRob3JvdWdoIHJldmlldyEgQmVsb3cgYWRkaXRpb25hbCBjb21t ZW50cyBmcm9tIG15IHNpZGUgdGhhdCBJIHRoaW5rIGFyZSBpbXBvcnRhbnQgdG8gbWVudGlvbi4N Cg0KMS0gb24gdGhlIHVzZSBvZiBSRkMyMTE5IGxhbmd1YWdlIGluIHNlY3Rpb24gMi44IGFuZCAy Ljk6IGZvciBzb21lIGluc3RhbmNlcyB3aGVyZSB0aGlzIGxhbmd1YWdlIGlzIHVzZWQsIHRoZXJl IGlzIHRoZSBzYW1lIG5vcm1hdGl2ZSBsYW5ndWFnZSBpbiBSRkM3MjUyIG9yIFJGQzY2OTAuIFNv IHRoZSB0ZXh0IGlzIHRoZXJlIHRvIHJlY2FwIHRoZXNlIHJlcXVpcmVtZW50cyB0byB0aGUgcmVh ZGVyLiAgT2YgY291cnNlIHdlIGNhbiByZW1vdmUgdGhlIGNhcGl0YWxzIKGwU0hPVUxEobEtPqGx c2hvdWxkobEgYnV0IGl0IG1heSBiZSBsZXNzIGNsZWFyIHRvIHRoZSByZWFkZXIgdGhhdCB0aGVy ZSBleGlzdHMgYW4gUkZDMjExOS1sZXZlbCByZXF1aXJlbWVudCBvbiB0aGUgdG9waWMuICBJIGFn cmVlIHRoYXQgdGhlIKGwUkVRVUlSRUShsSBrZXl3b3JkcyBjYW4gYmUgcmVtb3ZlZCBpbiB0aGVz ZSBzZWN0aW9ucyBzaW5jZSB0aGV5IGNhbiBjb25mdXNlLg0KKEJ1dCBwZXJoYXBzIHRoZXJloa9z IGEgYmV0dGVyIHdheSB0byBzYXkgZm9yIGNlcnRhaW4gYnVsbGV0IGl0ZW1zIHRoYXQgdGhleSBh cmUgbm90IG1lcmVseSBvdXIgcmVjb21tZW5kYXRpb24gYnV0IHRoZXJlIGFyZSBwcm90b2NvbCBy ZXF1aXJlbWVudHMgb24gaXQuKQ0KDQoyLSBvbiB0aGUgdXBwZXIgYm91bmQgZm9yIFRva2VuIHJl LXVzZSAoW0FrYmFyLTldIGl0ZW0pOiBJIHJlbWVtYmVyIGRpc2N1c3Npb25zIGluIENvUkUgaW4g dGhlIHBhc3QsIGFsd2F5cyBjb21pbmcgdG8gdGhlIGNvbmNsdXNpb24gdGhhdCB0aGVyZSBpcyBu byB1cHBlciBib3VuZCBmb3Igc2VydmVyIHJlc3BvbnNlIHRpbWUgKHNpbWlsYXIgdG8gSFRUUCku IFdlIGNvdWxkIHNheSB3ZSBwdXQgdGhlIFRva2VuIHJlLXVzZSB0aW1lIGZvciBhIGNsaWVudCBh dCAoTk9OX0xJRkVUSU1FICsgTUFYX0xBVEVOQ1kgKyAxMCBtaW51dGVzKSwganVzdCBhcyBhIGRl ZmF1bHQgZm9yIHRoZSBjYXNlIHRoYXQgdGhlIG1heCByZXNwb25zZSBsYXRlbmN5IG9mIGFueSBv ZiB0aGUgQ29BUCBzZXJ2ZXJzIGlzIHVua25vd24uIChJLmUuIHdlIGRvbqGvdCBpbXBvc2UgYSBs aW1pdCBvbnRvIENvQVAgd2hlcmUgdGhlcmUgaXMgbm9uZSBjdXJyZW50bHkuKSBUaGVuIGF0IHRo ZSBzYW1lIHRpbWUgd2UgY291bGQgZS5nLiByZWNvbW1lbmQgdGhhdCBhIENvQVAgc2VydmVyIGJ5 IGRlZmF1bHQgcmVzcG9uZHMgdG8gbXVsdGljYXN0IHJlcXVlc3RzIHdpdGhpbiBNQVhfU0VSVkVS X1JFU1BPTlNFX0RFTEFZID0gNSBtaW51dGVzLCBhZ2FpbiB3aXRob3V0IGZvcmNpbmcgYSBsaW1p dCBmb3IgdGhvc2UgY2FzZXMgd2hlcmUgbG9uZ2VyIGlzIG5lZWRlZC4NCldvdWxkIHRoYXQgd29y ayBmb3IgeW91Pw0KDQpFc2tvDQoNCg0KRnJvbTogYmFycnlsZWliYUBnbWFpbC5jb208bWFpbHRv OmJhcnJ5bGVpYmFAZ21haWwuY29tPiBbbWFpbHRvOmJhcnJ5bGVpYmFAZ21haWwuY29tXSBPbiBC ZWhhbGYgT2YgQmFycnkgTGVpYmENClNlbnQ6IFdlZG5lc2RheSwgSnVseSAzMCwgMjAxNCAwODoy MA0KVG86IFJhaG1hbiwgQWtiYXINCkNjOiBjb3JlIFdHOyBkcmFmdC1pZXRmLWNvcmUtZ3JvdXBj b21tLmFsbEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1jb3JlLWdyb3VwY29tbS5h bGxAdG9vbHMuaWV0Zi5vcmc+OyBEaWprLCBFc2tvDQpTdWJqZWN0OiBSZTogW2NvcmVdIEFEIHJl dmlldyBvZiBkcmFmdC1pZXRmLWNvcmUtZ3JvdXBjb21tLTIwDQoNClRoYW5rIHlvdSBmb3IgdGhl IHJldmlzZWQgZmVlZGJhY2sgYW5kIGNsYXJpZmljYXRpb25zLiAgTXkgY28tYXV0aG9yLA0KRXNr bywgYW5kIEkgaGF2ZSBkaXNjdXNzZWQgdGhlbSBvZmYgbGluZSBhbmQgZm9sbG93aW5nICBhcmUg b3VyDQpjb25zb2xpZGF0ZWQgcmVzcG9uc2VzIChpZGVudGlmaWVkIGFzICIqKltBdXRob3JzLVJl c3BvbnNlLXhdIikuICBPbmNlDQp5b3UgaGF2ZSBhcHByb3ZlZCBvdXIgZmluYWwgYW5zd2Vycywg d2Ugd2lsbCBhaW0gdG8gZG8gYSBxdWljayB1cGRhdGUgb2YNCnRoZSBkcmFmdCB0byBpbmNvcnBv cmF0ZSBhbGwgeW91ciBjb21tZW50cy4NCg0KR3JlYXQsIHRoYW5rcy4gIEkgdGhpbmsgd2UncmUg YWxsIHNldC4gIEFsbCB5b3VyIHJlc3BvbnNlcyBhcmUgT0sgd2l0aCBtZS4NCg0KKipbQXV0aG9y cy1SZXNwb25zZS01XSAtIE9rLiAgSXQgbG9va3MgbGlrZSB3ZSBzaG91bGQgY29uc2lkZXIgdG8g bWFrZQ0KdGhlIFJEIHJlZmVyZW5jZSBhcyBub3JtYXRpdmUuICBCdXQgYmVmb3JlIHdlIGNsb3Nl IHRoaXMgaXNzdWUsIGNvdWxkDQp5b3UgcG9pbnQgdXMgdG8gYW55IFJGQyB0aGF0IGRlZmluZXMg dGhlIGNyaXRlcmlhIGZvciBtYWtpbmcgdGhlDQpkZWNpc2lvbiBiZXR3ZWVuIEluZm9ybWF0aXZl IHZzIE5vcm1hdGl2ZSByZWZlcmVuY2U/DQoNClRoZXJlIGlzIG5vIFJGQywgYnV0IHRoZXJlIGlz IGFuIElFU0cgU3RhdGVtZW50Og0KaHR0cDovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9u b3JtYXRpdmUtaW5mb3JtYXRpdmUuaHRtbA0KTG9vayBhdCB0aGUgc2Vjb25kIHBhcmFncmFwaCBh bmQgdGhlIGZpcnN0IG5vdGUuDQoNCioqW0F1dGhvcnMtUmVzcG9uc2UtMTJdIC0gT2ssIHdlIHdp bGwgcmUtd3JpdGUgdGhlIGVudGlyZSBzZWN0aW9uIDIuOA0Kd2l0aG91dCBhbnkgUkZDMjExOSBs YW5ndWFnZSBhcyB5b3Ugc3VnZ2VzdGVkLiAgQWxzbywgcGVyaGFwcyB3ZSBzaG91bGQNCmFsc28g cmUtd3JpdGUgc2VjdGlvbiAyLjkgd2l0aG91dCBhbnkgUkZDMjExOSBsYW5ndWFnZSBhcyBpdCBp cyBhDQpzaW1pbGFyIHNlY3Rpb24uICBXaGF0IGRvIHlvdSB0aGluaz8NCg0KVGhhdCBzZWVtcyBz ZW5zaWJsZS4gIFBlcnNvbmFsbHkgSSB0aGluayBpdCdzIGp1c3QgYXMgZ29vZCB0byBzYXkgdGhp bmdzIGxpa2UgIklQIG11bHRpY2FzdHMgcmVxdWVzdHMgYXJlIGFsd2F5cyBOb24tY29uZmlybWFi bGUsIiBpbnN0ZWFkIG9mICJBbiBJUCBtdWx0aWNhc3QgcmVxdWVzdCBNVVNUIGJlIE5vbi1jb25m aXJtYWJsZSwiIHRob3VnaCBib3RoIGFyZSBPSy4gIEkgZG9uJ3QgdGhpbmsgdGhlIGNhcGl0YWxp emVkIGtleSB3b3JkcyBhZGQgYW55dGhpbmcgdGhlcmUuDQoNCkJhcnJ5DQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMg bWVzc2FnZSBtYXkgYmUgY29uZmlkZW50aWFsIGFuZCBsZWdhbGx5IHByb3RlY3RlZCB1bmRlciBh cHBsaWNhYmxlIGxhdy4gVGhlIG1lc3NhZ2UgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgYWRk cmVzc2VlKHMpLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJl IGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB1c2UsIGZvcndhcmRpbmcsIGRpc3NlbWluYXRpb24s IG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIG1lc3NhZ2UgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBh bmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwgYW5kIGRlc3Ryb3kg YWxsIGNvcGllcyBvZiB0aGUgb3JpZ2luYWwgbWVzc2FnZS4NCg== --_000_34966E97BE8AD64EAE9D3D6E4DEE36F25817D371SZXEMA501MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

>Other = proposals are welcome!

 = ;

How about = 4 and 4?

 = ;

NON_LIFETI= ME + MAX_LATENCY + 4 minutes for token reuse, and 4 minutes for multicast requests.

 = ;

Kind Regar= ds

Kepeng

 = ;

=B7=A2=BC=FE=C8=CB: Dijk, E= sko [mailto:esko.dijk@philips.com]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA7=D4=C230=C8=D5 19:51
=CA=D5=BC=FE=C8=CB: Likepeng; Barry Leiba; Rahman, Akbar
=B3=AD=CB=CD: draft-ietf-core-groupcomm.all@tools.ietf.org; core WG
=D6=F7=CC=E2: RE: [core] AD review of draft-ietf-core-groupcomm-20

 

Hi Kepeng,=

 = ;

> 10 mi= nutes? Is it too long?

 = ;

The NON_LI= FETIME + MAX_LATENCY is already ~4 minutes anyway, so it could be at le= ast something in the same order I think. In the 1-10 minutes range?

 = ;

> Why d= o we use 5 minutes for multicast requests while more than 10 minutes for To= ken reuse?

 = ;

The Token = re-use time has to be longer than the MAX_SERVER_RESPONSE_DELAY at least, w= ith some safety margin. Other proposals are welcome!

 = ;

Esko

 = ;

 = ;

 = ;

From: Likepeng [mail= to:likepeng@huawei.com]
Sent: Wednesday, July 30, 2014 13:20
To: Dijk, Esko; Barry Leiba; Rahman, Akbar
Cc: = draft-ietf-core-groupcomm.all@tools.ietf.org; core WG
Subject: Re: [core] AD review of draft-ietf-core-groupcomm-20

 

>We cou= ld say we put the Token re-use time for a client at (NON_LIFETIME + MAX= _LATENCY + 10 minutes), just as a default for the case that the max response latency of any of the CoAP servers is unknown. (I.e. we don=A1=AF= t impose a limit onto CoAP where there is none currently.)

 

10 minutes= ? Is it too long?

 

>Then a= t the same time we could e.g. recommend that a CoAP server by default respo= nds to multicast requests within MAX_SERVER_RESPONSE_DELAY =3D 5 minutes, again without forcing a limit for those cases where longer is n= eeded.

 

Why do we = use 5 minutes for multicast requests while more than 10 minutes for Token r= euse?

 

Thanks,

 

Kind Regar= ds

Kepeng

 

=B7=A2=BC=FE=C8=CB: core [<= a href=3D"mailto:core-bounces@ietf.org">mailto:core-bounces@ietf.org] =B4=FA= =B1=ED Dijk, Esko
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA7=D4=C230=C8=D5 18:31
=CA=D5=BC=FE=C8=CB: Barry Leiba; Rahman, Akbar
=B3=AD=CB=CD: draft-ietf-core-groupcomm.all@tools.ietf.org; core WG
=D6=F7=CC=E2: Re: [core] AD review of draft-ietf-core-groupcomm-20

 

Hello Barr= y,

 

Many thank= s for your thorough review! Below additional comments from my side that I t= hink are important to mention.

 

1- on the = use of RFC2119 language in section 2.8 and 2.9: for some instances where th= is language is used, there is the same normative language in RFC7252 or RFC6690. So the text is there to recap these requirements to= the reader.  Of course we can remove the capitals =A1=B0SHOULD=A1=B1-= >=A1=B1should=A1=B1 but it may be less clear to the reader that there ex= ists an RFC2119-level requirement on the topic.  I agree that the =A1=B0REQUIRED=A1=B1 keywords can be removed in these sections since t= hey can confuse.

(But perha= ps there=A1=AFs a better way to say for certain bullet items that they are = not merely our recommendation but there are protocol requirements on it.)

 

2- on the = upper bound for Token re-use ([Akbar-9] item): I remember discussions in Co= RE in the past, always coming to the conclusion that there is no upper bound for server response time (similar to HTTP). We could say= we put the Token re-use time for a client at (NON_LIFETIME + MAX_LATEN= CY + 10 minutes), just as a default for the case that the max response = latency of any of the CoAP servers is unknown. (I.e. we don=A1=AFt impose a limit onto CoAP where there is none currently= .) Then at the same time we could e.g. recommend that a CoAP server by defa= ult responds to multicast requests within MAX_SERVER_RESPONSE_DELAY =3D 5 m= inutes, again without forcing a limit for those cases where longer is needed.=

Would that= work for you?

 

Esko

 

 

From: barryleiba@gmail.com [mailto:barryleiba@gmail.com] On Behalf Of Barry Leiba
Sent: Wednesday, July 30, 2014 08:20
To: Rahman, Akbar
Cc: core WG; draft-ietf-core-groupcomm.all@tools.ietf.org; Dijk, Esko
Subject: Re: [core] AD review of draft-ietf-core-groupcomm-20=

 

Thank you for the revised feedb= ack and clarifications.  My co-author,
Esko, and I have discussed them off line and following  are our
consolidated responses (identified as "**[Authors-Response-x]"). =  Once
you have approved our final answers, we will aim to do a quick update of the draft to incorporate all your comments.

 

Great, thanks.  I think we= 're all set.  All your responses are OK with me.

 

**[Authors-Response-5] - Ok. &n= bsp;It looks like we should consider to make
the RD reference as normative.  But before we close this issue, could<= br> you point us to any RFC that defines the criteria for making the
decision between Informative vs Normative reference?

 

There is no RFC, but there is a= n IESG Statement:

Look at the second paragraph an= d the first note.

 

**[Authors-Response-12] - Ok, w= e will re-write the entire section 2.8
without any RFC2119 language as you suggested.  Also, perhaps we shoul= d
also re-write section 2.9 without any RFC2119 language as it is a
similar section.  What do you think?

 

That seems sensible.  Pers= onally I think it's just as good to say things like "IP multicasts req= uests are always Non-confirmable," instead of "An IP multicast re= quest MUST be Non-confirmable," though both are OK.  I don't think the capitalized key words add anything there.

 

Barry

 

The information = contained in this message may be confidential and legally protected under a= pplicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any us= e, forwarding, dissemination, or reproduction of this message is strictly p= rohibited and may be unlawful. If you are not the intended recipient, pleas= e contact the sender by return e-mail and destroy all copies of the original message.

--_000_34966E97BE8AD64EAE9D3D6E4DEE36F25817D371SZXEMA501MBSchi_-- From nobody Wed Jul 30 18:17:08 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C061A016D for ; Wed, 30 Jul 2014 18:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.929 X-Spam-Level: X-Spam-Status: No, score=-0.929 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrLwrWwZpwh5 for ; Wed, 30 Jul 2014 18:17:05 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C8DA1A0076 for ; Wed, 30 Jul 2014 18:17: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.5/8.14.5) with ESMTP id s6V1H1JY009595 for ; Thu, 31 Jul 2014 03:17:01 +0200 (CEST) Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D18A23F3 for ; Thu, 31 Jul 2014 03:17:00 +0200 (CEST) Received: by mail-vc0-f173.google.com with SMTP id hy10so3166068vcb.32 for ; Wed, 30 Jul 2014 18:16:59 -0700 (PDT) X-Received: by 10.220.5.138 with SMTP id 10mr7469656vcv.67.1406769419423; Wed, 30 Jul 2014 18:16:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.68.98 with HTTP; Wed, 30 Jul 2014 18:16:19 -0700 (PDT) In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F25817D371@SZXEMA501-MBS.china.huawei.com> References: <031DD135F9160444ABBE3B0C36CED61836E04BB2@AMSPRD9003MB066.MGDPHG.emi.philips.com> <34966E97BE8AD64EAE9D3D6E4DEE36F25817CFB9@SZXEMA501-MBS.china.huawei.com> <031DD135F9160444ABBE3B0C36CED61836E04C55@AMSPRD9003MB066.MGDPHG.emi.philips.com> <34966E97BE8AD64EAE9D3D6E4DEE36F25817D371@SZXEMA501-MBS.china.huawei.com> From: Klaus Hartke Date: Thu, 31 Jul 2014 03:16:19 +0200 Message-ID: To: core WG Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/core/VPDvSEcVFe3ZeAgDgaMkeO33E6o Subject: Re: [core] AD review of draft-ietf-core-groupcomm-20 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 31 Jul 2014 01:17:06 -0000 A token cannot be reused as long as it's in use by either the client or the server. CoAP does not include a mechanism for a client to determine if a token is still in use by a server. (There are some heuristics possible, but I don't trust them.) Simple solution to this problem: Don't reuse tokens. An implementation has to generate nonces for the security layer anyway, so generating a new token for each request shouldn't be a problem. - Klaus From nobody Thu Jul 31 06:41:01 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFCC11B27FF for ; Thu, 31 Jul 2014 06:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WkZ0t7Ztskfa for ; Thu, 31 Jul 2014 06:40:57 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lrp0081.outbound.protection.outlook.com [213.199.154.81]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F8751A0032 for ; Thu, 31 Jul 2014 06:40:57 -0700 (PDT) Received: from DB3PR04CA001.eurprd04.prod.outlook.com (10.242.134.21) by DB3PR04MB0635.eurprd04.prod.outlook.com (25.160.45.149) with Microsoft SMTP Server (TLS) id 15.0.995.14; Thu, 31 Jul 2014 13:40:53 +0000 Received: from DB3FFO11FD049.protection.gbl (2a01:111:f400:7e04::138) by DB3PR04CA001.outlook.office365.com (2a01:111:e400:9814::21) with Microsoft SMTP Server (TLS) id 15.0.995.14 via Frontend Transport; Thu, 31 Jul 2014 13:40:53 +0000 Received: from mail.philips.com (206.191.242.68) by DB3FFO11FD049.mail.protection.outlook.com (10.47.217.80) with Microsoft SMTP Server (TLS) id 15.0.980.11 via Frontend Transport; Thu, 31 Jul 2014 13:40:53 +0000 Received: from AMSPRD9003MB066.MGDPHG.emi.philips.com ([169.254.5.122]) by AMSPRD9003HT001.MGDPHG.emi.philips.com ([141.251.33.78]) with mapi id 14.16.0466.000; Thu, 31 Jul 2014 13:40:52 +0000 From: "Dijk, Esko" To: Klaus Hartke , core WG Thread-Topic: [core] AD review of draft-ietf-core-groupcomm-20 Thread-Index: AQHPqpAseQerMW+gRECZB6herPpJipu4CtgAgAAcsgCAADW6AIAAHeSAgAAHrvCAANieAIAACXyAgACiNGA= Date: Thu, 31 Jul 2014 13:40:52 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED61836E05105@AMSPRD9003MB066.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED61836E04BB2@AMSPRD9003MB066.MGDPHG.emi.philips.com> <34966E97BE8AD64EAE9D3D6E4DEE36F25817CFB9@SZXEMA501-MBS.china.huawei.com> <031DD135F9160444ABBE3B0C36CED61836E04C55@AMSPRD9003MB066.MGDPHG.emi.philips.com> <34966E97BE8AD64EAE9D3D6E4DEE36F25817D371@SZXEMA501-MBS.china.huawei.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.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:206.191.242.68; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(428002)(13464003)(52314003)(85714005)(189002)(199002)(374574003)(77982001)(76176999)(79102001)(54356999)(4396001)(81342001)(105586002)(46406003)(85306003)(55846006)(107046002)(86362001)(50466002)(107886001)(93886003)(81542001)(81156004)(76482001)(84676001)(106466001)(46102001)(50986999)(97756001)(83322001)(31966008)(23726002)(74502001)(74662001)(92726001)(44976005)(19580395003)(101416001)(47776003)(20776003)(69596002)(64706001)(92566001)(33656002)(85852003)(104016003)(80022001)(6806004)(15975445006)(83072002)(77096002)(19580405001)(95666004)(87936001)(106116001)(66066001)(97736001)(21056001)(68736004)(2656002)(567094001); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR04MB0635; H:mail.philips.com; FPR:; MLV:sfv; PTR:ErrorRetry; MX:1; A:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 0289B6431E Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is 206.191.242.68) smtp.mailfrom=esko.dijk@philips.com; X-OriginatorOrg: philips.com Archived-At: http://mailarchive.ietf.org/arch/msg/core/VF2u19EfYLAP3zZIlNFtf38Hi_k Subject: Re: [core] AD review of draft-ietf-core-groupcomm-20 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 31 Jul 2014 13:41:00 -0000 Agree this is the simplest / safest solution in case the generation is not = a problem. We can mention this solution in the draft as preferred solution = that satisfies the requirement no matter what the latency is. Esko -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Klaus Hartke Sent: Thursday, July 31, 2014 03:16 To: core WG Subject: Re: [core] AD review of draft-ietf-core-groupcomm-20 A token cannot be reused as long as it's in use by either the client or the= server. CoAP does not include a mechanism for a client to determine if a t= oken is still in use by a server. (There are some heuristics possible, but = I don't trust them.) Simple solution to this problem: Don't reuse tokens. An implementation has to generate nonces for the security layer anyway, so = generating a new token for each request shouldn't be a problem. - 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 nobody Thu Jul 31 11:22:50 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2BC1A0316 for ; Thu, 31 Jul 2014 11:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F_xyjzCrA03A for ; Thu, 31 Jul 2014 11:22:37 -0700 (PDT) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C181B1A0271 for ; Thu, 31 Jul 2014 11:22:37 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id lf12so4870922vcb.15 for ; Thu, 31 Jul 2014 11:22:37 -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:message-id:subject :from:to:cc:content-type; bh=JhZLo4iRt8FzRM5qcFgtok2vh+/w+KSo0xCP8ydXH+8=; b=E1EWoiXhjHKHTegFSqCHlTzSo7Ur0qb59acn10HEjbNljHar4pHR9Jbq3fwPto7tL7 k/5lXes35pdRw+AkE+tFit3NPVlQeIbjRYEXa4yT4XwjvvCdwAjsKYnMYArT+jgSS4Yt jyDz7H8xqvLkGMQPlFQVwobRP53v4feNiVPeWApdXGpzf7AkwBQ3AX4tS0GstAlnn0dN YwVfKkEX8bunfDTaYehzPGFYZb5ptDEqTpAKxzrL+83rD+l6NZsVgNlgXVrwR8oWf77l Zs3KJHq7zpSa/hAssQswWL3/QE1aK9qi4fVVN0HgqSCHGsraWrIG2kWlsvXZxN+CX9Z5 14lg== MIME-Version: 1.0 X-Received: by 10.53.10.65 with SMTP id dy1mr3856013vdd.92.1406830956997; Thu, 31 Jul 2014 11:22:36 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.181.71 with HTTP; Thu, 31 Jul 2014 11:22:36 -0700 (PDT) In-Reply-To: <031DD135F9160444ABBE3B0C36CED61836E05105@AMSPRD9003MB066.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED61836E04BB2@AMSPRD9003MB066.MGDPHG.emi.philips.com> <34966E97BE8AD64EAE9D3D6E4DEE36F25817CFB9@SZXEMA501-MBS.china.huawei.com> <031DD135F9160444ABBE3B0C36CED61836E04C55@AMSPRD9003MB066.MGDPHG.emi.philips.com> <34966E97BE8AD64EAE9D3D6E4DEE36F25817D371@SZXEMA501-MBS.china.huawei.com> <031DD135F9160444ABBE3B0C36CED61836E05105@AMSPRD9003MB066.MGDPHG.emi.philips.com> Date: Thu, 31 Jul 2014 14:22:36 -0400 X-Google-Sender-Auth: 0hYtn6atmiXbGJETCqkOMnRmYeA Message-ID: From: Barry Leiba To: "Dijk, Esko" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/core/zlVS4TRjJ2qIvBkr9XCxVDRoUe4 Cc: core WG , Klaus Hartke Subject: Re: [core] AD review of draft-ietf-core-groupcomm-20 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 31 Jul 2014 18:22:39 -0000 > Agree this is the simplest / safest solution in case the generation is > not a problem. We can mention this solution in the draft as preferred > solution that satisfies the requirement no matter what the latency is. I think a statement such as that would be exactly the kind of guidance I'm looking for, and I'd be happy with it. b From nobody Thu Jul 31 11:51:37 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6661A0328; Thu, 31 Jul 2014 11:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YazC-MVFLEZ; Thu, 31 Jul 2014 11:51:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 704D71B293F; Thu, 31 Jul 2014 11:51:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140731185122.11292.37810.idtracker@ietfa.amsl.com> Date: Thu, 31 Jul 2014 11:51:22 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/core/flUQjsuqZBWEDnv3YBEgpdBduZs Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-groupcomm-21.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 18:51:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments Working Group of the IETF. Title : Group Communication for CoAP Authors : Akbar Rahman Esko Dijk Filename : draft-ietf-core-groupcomm-21.txt Pages : 52 Date : 2014-07-31 Abstract: CoAP is a specialized web transfer protocol for constrained devices and constrained networks. It is anticipated that constrained devices will often naturally operate in groups (e.g., in a building automation scenario all lights in a given room may need to be switched on/off as a group). This document provides guidance for how the CoAP protocol should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed. Also, various use cases and corresponding protocol flows are provided to illustrate important concepts. Finally, guidance is provided for deployment in various network topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-groupcomm-21 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-core-groupcomm-21 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 31 11:51:42 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1211A0329 for ; Thu, 31 Jul 2014 11:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sda6grjtnp0c; Thu, 31 Jul 2014 11:51:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8326A1B2941; Thu, 31 Jul 2014 11:51:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: core-chairs@tools.ietf.org, draft-ietf-core-groupcomm@tools.ietf.org, core@ietf.org, barryleiba@computer.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140731185122.11292.74117.idtracker@ietfa.amsl.com> Date: Thu, 31 Jul 2014 11:51:22 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/core/vIhK-VT70w0y1Aruk0vH3yqlV-g Subject: [core] New Version Notification - draft-ietf-core-groupcomm-21.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 18:51:36 -0000 A new version (-21) has been submitted for draft-ietf-core-groupcomm: http://www.ietf.org/internet-drafts/draft-ietf-core-groupcomm-21.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-core-groupcomm-21 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Thu Jul 31 11:56:19 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 990111A0316 for ; Thu, 31 Jul 2014 11:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Iw0uscr8Ouc for ; Thu, 31 Jul 2014 11:56:10 -0700 (PDT) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E9711A01B0 for ; Thu, 31 Jul 2014 11:56:10 -0700 (PDT) X-ASG-Debug-ID: 1406832968-06daaa5dbc155d0001-aa7cYp Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id ATn8pEKxGmI0T7lk for ; Thu, 31 Jul 2014 14:56:08 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 31 Jul 2014 14:56:07 -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, 31 Jul 2014 14:56:05 -0400 X-ASG-Orig-Subj: FW: [core] I-D Action: draft-ietf-core-groupcomm-21.txt Message-ID: In-Reply-To: <20140731185122.11292.37810.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] I-D Action: draft-ietf-core-groupcomm-21.txt Thread-Index: Ac+s8HYg6AGWRrhLTqm9ySyfaKsQHQAAA7GA References: <20140731185122.11292.37810.idtracker@ietfa.amsl.com> From: "Rahman, Akbar" To: "Barry Leiba" X-OriginalArrivalTime: 31 Jul 2014 18:56:07.0483 (UTC) FILETIME=[161870B0:01CFACF1] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1406832968 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.8005 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Archived-At: http://mailarchive.ietf.org/arch/msg/core/iFMdlih7SjfUiwa_PFNzonX5V5w Cc: core WG Subject: [core] FW: I-D Action: draft-ietf-core-groupcomm-21.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 31 Jul 2014 18:56:13 -0000 Hi Barry, Esko and I have updated the draft pretty extensively based on your review. We tried to follow the agreements in our emails as closely as possible but in some cases did some slight adjustments when we looked at the overall document. Please review to tell us if you want us to do any other changes. Best Regards, Akbar & Esko -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Thursday, July 31, 2014 2:51 PM To: i-d-announce@ietf.org Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-groupcomm-21.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments Working Group of the IETF. Title : Group Communication for CoAP Authors : Akbar Rahman Esko Dijk Filename : draft-ietf-core-groupcomm-21.txt Pages : 52 Date : 2014-07-31 Abstract: CoAP is a specialized web transfer protocol for constrained devices and constrained networks. It is anticipated that constrained devices will often naturally operate in groups (e.g., in a building automation scenario all lights in a given room may need to be switched on/off as a group). This document provides guidance for how the CoAP protocol should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed. Also, various use cases and corresponding protocol flows are provided to illustrate important concepts. Finally, guidance is provided for deployment in various network topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-groupcomm-21 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-groupcomm-21 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Thu Jul 31 13:21:04 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A47141A00DF for ; Thu, 31 Jul 2014 13:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2phAwGISsT0; Thu, 31 Jul 2014 13:20:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E067B1A010E; Thu, 31 Jul 2014 13:20:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: core-chairs@tools.ietf.org, draft-ietf-core-groupcomm@tools.ietf.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140731202055.12053.86745.idtracker@ietfa.amsl.com> Date: Thu, 31 Jul 2014 13:20:55 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/core/RGxdZmAQxeptj_LegcTmsxhUc3w Subject: [core] ID Tracker State Update Notice: X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 20:21:01 -0000 IESG state changed to Last Call Requested from AD Evaluation::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ From nobody Thu Jul 31 13:39:33 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2A61A0188; Thu, 31 Jul 2014 13:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id riUWgpgbnX66; Thu, 31 Jul 2014 13:39:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6222D1A0108; Thu, 31 Jul 2014 13:39:29 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140731203929.25740.87264.idtracker@ietfa.amsl.com> Date: Thu, 31 Jul 2014 13:39:29 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/core/Rk5pMoGVI5AvbR8174U1vOTU8to Cc: core@ietf.org Subject: [core] Last Call: (Group Communication for CoAP) to Informational RFC X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@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, 31 Jul 2014 20:39:31 -0000 The IESG has received a request from the Constrained RESTful Environments WG (core) to consider the following document: - 'Group Communication for CoAP' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-08-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract CoAP is a specialized web transfer protocol for constrained devices and constrained networks. It is anticipated that constrained devices will often naturally operate in groups (e.g., in a building automation scenario all lights in a given room may need to be switched on/off as a group). This document provides guidance for how the CoAP protocol should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed. Also, various use cases and corresponding protocol flows are provided to illustrate important concepts. Finally, guidance is provided for deployment in various network topologies. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Jul 31 13:39:52 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12AE11A01B0 for ; Thu, 31 Jul 2014 13:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6LZZ77x_1gaK; Thu, 31 Jul 2014 13:39:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 352BF1A0173; Thu, 31 Jul 2014 13:39:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: core-chairs@tools.ietf.org, draft-ietf-core-groupcomm@tools.ietf.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140731203930.25740.86862.idtracker@ietfa.amsl.com> Date: Thu, 31 Jul 2014 13:39:30 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/core/PaZAfB-j6e30HqiFxe17SOzIUIY Subject: [core] ID Tracker State Update Notice: X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 20:39:46 -0000 Last call has been made for draft-ietf-core-groupcomm and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ From nobody Thu Jul 31 22:07:16 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B091A040C for ; Thu, 31 Jul 2014 22:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XONZ9P47I5xs; Thu, 31 Jul 2014 22:07:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 039C81A0411; Thu, 31 Jul 2014 22:07:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: core-chairs@tools.ietf.org, draft-ietf-core-observe@tools.ietf.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140801050706.32565.68103.idtracker@ietfa.amsl.com> Date: Thu, 31 Jul 2014 22:07:06 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/core/ULRzhYgz7EUoInLiHHnfOq6P6gs Subject: [core] ID Tracker State Update Notice: X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 05:07:13 -0000 IANA review state changed to IANA OK - Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-core-observe/ From nobody Thu Jul 31 22:38:47 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A930E1A040B; Thu, 31 Jul 2014 21:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.18 X-Spam-Level: X-Spam-Status: No, score=-3.18 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mA86Iv39Kq5N; Thu, 31 Jul 2014 21:42:55 -0700 (PDT) Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B5CC1A03FE; Thu, 31 Jul 2014 21:42:55 -0700 (PDT) Received: from request1.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id s714gtJR005997; Fri, 1 Aug 2014 04:42:55 GMT Received: by request1.lax.icann.org (Postfix, from userid 48) id 3C1C25604D6; Fri, 1 Aug 2014 04:42:55 +0000 (UTC) RT-Owner: pearl.liang From: "Pearl Liang via RT" In-Reply-To: <20140725140250.27823.45115.idtracker@ietfa.amsl.com> References: <20140725140250.27823.45115.idtracker@ietfa.amsl.com> Message-ID: Precedence: bulk X-RT-Loop-Prevention: IANA RT-Ticket: IANA #773750 Managed-BY: RT 4.0.8 (http://www.bestpractical.com/rt/) RT-Originator: pearl.liang@icann.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Fri, 1 Aug 2014 04:42:55 +0000 Archived-At: http://mailarchive.ietf.org/arch/msg/core/TrVT_OoMS7Pqw0h8IgFoPBdRhd8 X-Mailman-Approved-At: Thu, 31 Jul 2014 22:38:46 -0700 Cc: draft-ietf-core-observe@tools.ietf.org, core-chairs@tools.ietf.org, iesg@ietf.org, core@ietf.org Subject: [core] [IANA #773750] Last Call: (Observing Resources in CoAP) to Proposed Standard X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-lastcall@iana.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, 01 Aug 2014 04:43:01 -0000 (BEGIN IANA LAST CALL COMMENTS) IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-core-observe-14. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. We received the following comments/questions from the IANA's reviewer: IANA understands that, upon approval of this document, there is a single action which IANA must complete. In the CoAP Option Numbers subregistry of the Constrained RESTful Environments (CoRE) Parameters registry located at: http://www.iana.org/assignments/core-parameters/ a new option number will be registered as follows: Number: 6 Name: Observe Reference: [ RFC-to-be ] Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120. IANA understands that this is the only action required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. Thanks, Name Title ICANN (END IANA LAST CALL COMMENTS) On Fri Jul 25 14:04:05 2014, iesg-secretary@ietf.org wrote: > > The IESG has received a request from the Constrained RESTful Environments > WG (core) to consider the following document: > - 'Observing Resources in CoAP' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2014-08-08. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > CoAP is a RESTful application protocol for constrained nodes and > networks. The state of a resource on a CoAP server can change over > time. This document specifies a simple protocol extension for CoAP > that enables CoAP clients to "observe" resources, i.e., to retrieve > a representation of a resource and keep this representation updated > by the server over a period of time. The protocol follows a best- > effort approach for sending new representations to clients and > provides eventual consistency between the state observed by each > client and the actual resource state at the server. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-core-observe/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-core-observe/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > >