From esko.dijk@philips.com Mon Sep 2 02:29:02 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7FDA11E81D4 for ; Mon, 2 Sep 2013 02:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.75 X-Spam-Level: X-Spam-Status: No, score=-0.75 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZScxA0XPNZCn for ; Mon, 2 Sep 2013 02:28:57 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id DEEAA11E8125 for ; Mon, 2 Sep 2013 02:28:49 -0700 (PDT) Received: from mail7-co1-R.bigfish.com (10.243.78.236) by CO1EHSOBE028.bigfish.com (10.243.66.91) with Microsoft SMTP Server id 14.1.225.22; Mon, 2 Sep 2013 09:28:49 +0000 Received: from mail7-co1 (localhost [127.0.0.1]) by mail7-co1-R.bigfish.com (Postfix) with ESMTP id 1A4C78C028A; Mon, 2 Sep 2013 09:28:49 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -30 X-BigFish: VPS-30(zz15d6Oc89bh1b0bI542I1432I9251I14ffI217bIdd85kzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah186068h8275dh1de097hz2dh2a8h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h1155h) Received: from mail7-co1 (localhost.localdomain [127.0.0.1]) by mail7-co1 (MessageSwitch) id 1378114126723817_32313; Mon, 2 Sep 2013 09:28:46 +0000 (UTC) Received: from CO1EHSMHS030.bigfish.com (unknown [10.243.78.238]) by mail7-co1.bigfish.com (Postfix) with ESMTP id AC4E46A008A; Mon, 2 Sep 2013 09:28:46 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO1EHSMHS030.bigfish.com (10.243.66.40) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 2 Sep 2013 09:28:46 +0000 Received: from 011-DB3MMR1-019.MGDPHG.emi.philips.com (10.128.28.106) by 011-DB3MMR1-006.MGDPHG.emi.philips.com (10.128.28.56) with Microsoft SMTP Server (TLS) id 14.3.146.2; Mon, 2 Sep 2013 09:28:34 +0000 Received: from 011-DB3MPN2-083.MGDPHG.emi.philips.com ([169.254.3.104]) by 011-DB3MMR1-019.MGDPHG.emi.philips.com ([10.128.28.106]) with mapi id 14.03.0146.002; Mon, 2 Sep 2013 09:28:21 +0000 From: "Dijk, Esko" To: Bert Greevenbosch , Carsten Bormann , Abhijan Bhattacharyya Thread-Topic: [core] Fw: New Version Notification for draft-tcs-coap-no-response-option-00.txt Thread-Index: AQHOphNh0kzaEPAkgE+hsPrcVQWgKJmyLcsQ Date: Mon, 2 Sep 2013 09:28:20 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618D07749@011-DB3MPN2-083.MGDPHG.emi.philips.com> References: <46A1DF3F04371240B504290A071B4DB63D83A5F6@szxeml558-mbs.china.huawei.com> In-Reply-To: <46A1DF3F04371240B504290A071B4DB63D83A5F6@szxeml558-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.103] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%INTERDIGITAL.COM$RO%1$TLS%0$FQDN%$TlsDn% Cc: "core@ietf.org" Subject: Re: [core] Fw: New Version Notification for draft-tcs-coap-no-response-option-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 09:29:03 -0000 SGkgYWxsLA0KDQpzb21lIEZZSSBpbnB1dCBiZWxvdywgc2luY2UgcGFydCBvZiB0aGlzIGRpc2N1 c3Npb24gaXMgYWxyZWFkeSBkb2N1bWVudGVkIGluIEktRHMuDQoNCj4gSSB0aGluayBpdCBpcyBl c3BlY2lhbGx5IHVzZWZ1bCBpbiBjb21iaW5hdGlvbiB3aXRoIG11bHRpY2FzdCwgZS5nLiB3aGVu IGEgc2luZ2xlIGNsaWVudCBzZW5kcyBhIFBPU1QgdG8gYSBncm91cCBvZiBhY3R1YXRvcnMsIHdo aWNoIGp1c3QgbmVlZCB0byBhY3QsIG5vdCB0byByZXNwb25kLiBIb3dldmVyLCBhY2NvcmRpbmcg dG8gQ29BUC0xOCwgdGhlID8NCj4gc2VydmVyIG5vdyBpcyBhbHNvIGFsbG93ZWQgdG8gc3VwcHJl c3MgYSByZXNwb25zZSB0byBhIG11bHRpY2FzdCByZXF1ZXN0IHdoZW4gaXQgZGVlbXMgdGhhdCBh cHByb3ByaWF0ZS4gQnV0IHRoaXMgd291bGQgYWxsb3cgdGhlIGNsaWVudCB0byBleHBsaWNpdGx5 IGluZGljYXRlIGl0cyBkaXNpbnRlcmVzdCBpbiB0aGUgcmVzcG9uc2VzLg0KQWdyZWUsIHNlZSBo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNvcmUtZ3JvdXBjb21tLTEyI3Nl Y3Rpb24tMy43IGZvciBtb3JlIGRldGFpbGVkIGFuYWx5c2lzIGZvciB0aGUgbXVsdGljYXN0IHVz ZSBjYXNlIQ0KVGhpcyBzZWN0aW9uIGFsc28gc2hvd3MgdGhhdCBpbiBmYWN0IG1vcmUgZ3JhbnVs YXJpdHkgaW4gcmVzcG9uc2Ugc3VwcHJlc3Npb24gd291bGQgYmUgdXNlZnVsLCBub3QganVzdCAi cmVzcG9uc2U6IHllcy9ubyIuIEZvciBleGFtcGxlOiBzdXBwcmVzcyAyLnh4IHJlc3BvbnNlIGJ1 dCBub3QgNC54eC81Lnh4LiBOb3RlIHRoYXQgdGhlIGN1cnJlbnQgZ3JvdXBjb21tIHNvbHV0aW9u IHRvIHNvbHZlIHRoaXMgaXMgdG8gaGF2ZSB0aGUgc2VydmVyJ3MgYmVoYXZpb3VyIGZvciBtdWx0 aWNhc3QgcmVzcG9uc2VzIGNvbmZpZ3VyZWQgYXQgYSBwZXItcmVzb3VyY2UgbGV2ZWwuIEhhdmlu ZyBhIGdyYW51bGFyIHJlc3BvbnNlIHN1cHByZXNzaW9uIG9wdGlvbiB3b3VsZCBiZSBuaWNlIHRv IGF2b2lkIHN1Y2ggJ2hhcmRjb2RpbmcnLg0KDQo+IHRoZSBvcHRpb24gaGFzIHRoZSBhZHZhbnRh Z2UgdGhhdCBpdCBjYW4gYmUgZWxlY3RpdmUuIC4uLiBVc2luZyBhIHNlcGFyYXRlIFVQT1NUL1VQ VVQgbWV0aG9kIHdvdWxkIG1pc3MgdGhhdCBhZHZhbnRhZ2UuDQpZZXMsIGFncmVlLg0KDQo+IEJU VywgdGhlIHVzZSBjYXNlIGluIHRoZSBkcmFmdCBhc3N1bWVzIHRoZSBzZW5zb3IgdG8gaW4gdGhl IHZlaGljbGUgdG8gYmUgQ29BUCBjbGllbnQsIGFuZCB0aGUgY2VudHJhbCB0cmFja2VyIHRoZSBD b0FQIHNlcnZlci4gVGhpcyBjb3VsZCBiZSBkb25lIGRpZmZlcmVudGx5LCBpLmUuIGxldCB0aGUg dmVoaWNsZSBzZW5zb3IgYmUgdGhlIENvQVANCj4gc2VydmVyIGFuZCB0aGUgY2VudHJhbCB0cmFj a2VyIGJlIHRoZSBDb0FQIGNsaWVudC4gVGhlbiB0aGlzIHBhcnRpY3VsYXIgdXNlIGNhc2UgY2Fu IGluZGVlZCBiZSBhY2hpZXZlZCB3aXRoIG9ic2VydmUuDQpBZ3JlZSBhZ2Fpbjsgbm90ZSB0aGF0 IGluIGEgdHlwaWNhbCBkZXNpZ24gZm9yIHNsZWVweSwgYmF0dGVyeS1wb3dlcmVkIHNlbnNvcnMg dGhlIHNlbnNvcnMgd291bGQgaW5kZWVkIGFsd2F5cyBhY3QgYXMgdGhlIENvQVAgY2xpZW50cyAo aW5pdGlhdG9yIG9mIHRoZSBjb21tdW5pY2F0aW9uKS4gKEZvciBiYWNrZ3JvdW5kIHNlZSBodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1kaWprLWNvcmUtc2xlZXB5LXNvbHV0aW9ucy0w MSNzZWN0aW9uLTMuMy4xIGFuZCBpdHMgZm9sbG93aW5nIHNlY3Rpb25zLCBvciB0aGUgTWlycm9y IFNlcnZlciBJLUQuKQ0KDQpFc2tvDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBCZXJ0IEdyZWV2ZW5ib3NjaA0KU2VudDogU2F0dXJkYXksIEF1Z3VzdCAzMSwg MjAxMyAwODoyOQ0KVG86IENhcnN0ZW4gQm9ybWFubjsgQWJoaWphbiBCaGF0dGFjaGFyeXlhDQpD YzogY29yZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtjb3JlXSBGdzogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC10Y3MtY29hcC1uby1yZXNwb25zZS1vcHRpb24tMDAudHh0DQoN CkhpIEFiaGlqYW4sIENhcnN0ZW4sIGFsbCwNCg0KSW50ZXJlc3RpbmcgZHJhZnQgaW5kZWVkLiBU aGUgc2VydmVyIHdhcyBhbHJlYWR5IGFsbG93ZWQgdG8gc2VuZCB1bmlkaXJlY3Rpb25hbCBtZXNz YWdlcyB0aHJvdWdoIE5PTi1yZXNwb25zZXMsIHRoaXMgZHJhZnQgd291bGQgYWxsb3cgdW5pZGly ZWN0aW9uYWwgbWVzc2FnZXMgaW4gdGhlIG90aGVyIGRpcmVjdGlvbiB0b28uDQoNCkkgdGhpbmsg aXQgaXMgZXNwZWNpYWxseSB1c2VmdWwgaW4gY29tYmluYXRpb24gd2l0aCBtdWx0aWNhc3QsIGUu Zy4gd2hlbiBhIHNpbmdsZSBjbGllbnQgc2VuZHMgYSBQT1NUIHRvIGEgZ3JvdXAgb2YgYWN0dWF0 b3JzLCB3aGljaCBqdXN0IG5lZWQgdG8gYWN0LCBub3QgdG8gcmVzcG9uZC4gSG93ZXZlciwgYWNj b3JkaW5nIHRvIENvQVAtMTgsIHRoZSBzZXJ2ZXIgbm93IGlzIGFsc28gYWxsb3dlZCB0byBzdXBw cmVzcyBhIHJlc3BvbnNlIHRvIGEgbXVsdGljYXN0IHJlcXVlc3Qgd2hlbiBpdCBkZWVtcyB0aGF0 IGFwcHJvcHJpYXRlLiBCdXQgdGhpcyB3b3VsZCBhbGxvdyB0aGUgY2xpZW50IHRvIGV4cGxpY2l0 bHkgaW5kaWNhdGUgaXRzIGRpc2ludGVyZXN0IGluIHRoZSByZXNwb25zZXMuDQoNClVuaWRpcmVj dGlvbmFsIHJlcXVlc3RzIGNhbiBhbHNvIHNhdmUgZW5lcmd5IGZvciB0cmFuc21pc3Npb24gb24g dGhlIHNlcnZlciBzaWRlLiBJIGNvdWxkIGV2ZW4gaW1hZ2luZSB2ZXJ5IHNpbXBsZSBhY3R1YXRv cnMgdGhhdCBvbmx5IGhhdmUgYSByZWNlaXZpbmcgbW9kdWxlLiBTaW1pbGFybHkgdG8gY2xpZW50 cyB3aXRoIG9ubHkgYSBzZW5kaW5nIG1vZHVsZS4gTm93IHRoaXMgaXMgYWxyZWFkeSBwb3NzaWJs ZSAtIHRoZSBjbGllbnQgZG9lc24ndCBuZWVkIHRvIHByb2Nlc3MgYSBOT04tcmVzcG9uc2UgYW5k IGNhbiBjaG9vc2UgdG8gbm90IGV2ZW4gcmVjZWl2ZSBpdCAtIGJ1dCwgYXMgYWxyZWFkeSBtZW50 aW9uZWQsIHRoaXMgd291bGQgYWxsb3cgdGhlIGNsaWVudCB0byBleHBsaWNpdGx5IGluZGljYXRl IGl0cyBkaXNpbnRlcmVzdCBpbiB0aGUgcmVzcG9uc2UuDQoNCkNvbmNlcm5pbmcgdGhlIG9wdGlv biB2cy4gc2VwYXJhdGUgc3VpdGUgaXNzdWUsIHRoZSBvcHRpb24gaGFzIHRoZSBhZHZhbnRhZ2Ug dGhhdCBpdCBjYW4gYmUgZWxlY3RpdmUuIEluIHRoaXMgY2FzZSwgdW5kZXJzdGFuZGluZyBkZXZp Y2VzIHdpbGwgYWN0IGFjY29yZGluZyB0byB0aGUgb3B0aW9uLCBidXQgbGVnYWN5IGRldmljZXMg d2lsbCBzdGlsbCBiZSBhYmxlIHRvIHVzZSB0aGUgbWVzc2FnZSBhbHRob3VnaCB0aGV5IG1pZ2h0 IHNlbmQgdGhlIHJlc3BvbnNlLiBVc2luZyBhIHNlcGFyYXRlIFVQT1NUL1VQVVQgbWV0aG9kIHdv dWxkIG1pc3MgdGhhdCBhZHZhbnRhZ2UuDQoNCkJUVywgdGhlIHVzZSBjYXNlIGluIHRoZSBkcmFm dCBhc3N1bWVzIHRoZSBzZW5zb3IgdG8gaW4gdGhlIHZlaGljbGUgdG8gYmUgQ29BUCBjbGllbnQs IGFuZCB0aGUgY2VudHJhbCB0cmFja2VyIHRoZSBDb0FQIHNlcnZlci4gVGhpcyBjb3VsZCBiZSBk b25lIGRpZmZlcmVudGx5LCBpLmUuIGxldCB0aGUgdmVoaWNsZSBzZW5zb3IgYmUgdGhlIENvQVAg c2VydmVyIGFuZCB0aGUgY2VudHJhbCB0cmFja2VyIGJlIHRoZSBDb0FQIGNsaWVudC4gVGhlbiB0 aGlzIHBhcnRpY3VsYXIgdXNlIGNhc2UgY2FuIGluZGVlZCBiZSBhY2hpZXZlZCB3aXRoIG9ic2Vy dmUuDQoNCkJlc3QgcmVnYXJkcywNCkJlcnQNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IGNvcmUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNvcmUtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmDQo+IE9mIENhcnN0ZW4gQm9ybWFubg0KPiBTZW50OiAyMDEz5bm0 OOaciDMw5pelIDE5OjA2DQo+IFRvOiBBYmhpamFuIEJoYXR0YWNoYXJ5eWENCj4gQ2M6IGNvcmVA aWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtjb3JlXSBGdzogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvcg0KPiBkcmFmdC10Y3MtY29hcC1uby0gcmVzcG9uc2Utb3B0aW9uLTAwLnR4dA0KPg0K PiBIaSBBYmhpamFuLA0KPg0KPiB0aGFuayB5b3UgZm9yIHN1Ym1pdHRpbmcgdGhpcyBkcmFmdC4N Cj4NCj4gVGhlIGlkZWEgdG8gaGFuZGxlIHVuaWRpcmVjdGlvbmFsIHJlcXVlc3RzIGhhcyBjb21l IHVwIGluIHRoZSBwYXN0OyB3ZQ0KPiBqdXN0IGRpZG4ndCBzZWVtIHRvIGhhdmUgdGhlIGVuZXJn eSB0byB3b3JrIG9uIGl0Lg0KPg0KPiBRdWVzdGlvbnMgdGhhdCBJIHJlbWVtYmVyIGNvbWluZyB1 cCBpbmNsdWRlOg0KPg0KPiAtLSBJcyB0aGlzIGJlc3QgaGFuZGxlZCBhcyBhbiBvcHRpb24gKHRo YXQgd291bGQgYXBwbHkgdG8gbXVsdGlwbGUNCj4gcmVxdWVzdHMpIG9yIGFzIGEgc2VwYXJhdGUg c3VpdGUgb2YgcmVxdWVzdCBtZXRob2RzIChzYXksIFVQVVQsIFVQT1NUKT8NCj4gQ2xlYXJseSwg dW5pZGlyZWN0aW9uYWwgZG9lc24ndCBtYWtlIHNlbnNlIGZvciBHRVQgOi0pDQo+IC0tIFdoYXQg aXMgdGhlIGJvdW5kYXJ5IGJldHdlZW4gdGhlIHVzZSBjYXNlcyBiZXN0IGhhbmRsZWQgYnkgb2Jz ZXJ2ZQ0KPiBhbmQgdGhvc2UgYmVzdCBoYW5kbGVkIGJ5IHVuaWRpcmVjdGlvbmFsIHJlcXVlc3Rz Pw0KPiAtLSBXaGF0IGFyZSB0aGUgY29uZ2VzdGlvbiBjb250cm9sIGltcGxpY2F0aW9ucyBvZiB1 bmlkaXJlY3Rpb25hbA0KPiByZXF1ZXN0cz8gIEkgdGhpbmsgd2Ugbm93IHVuZGVyc3RhbmQgaG93 IHRvIGhhbmRsZSB0aGlzIHdpdGggb2JzZXJ2ZTsNCj4gdGhlIHNvbHV0aW9ucyBtYXkgYmUgdHJh bnNmZXJyYWJsZS4NCj4NCj4gU28sIHdoYXQgYXBwbGljYXRpb25zIG9mIHVuaWRpcmVjdGlvbmFs IHJlcXVlc3RzIGRvIG90aGVycyBoYXZlIGluIG1pbmQ/DQo+IE90aGVyIHRoaW5ncyB3ZSBuZWVk IHRvIHRoaW5rIGFib3V0Pw0KPg0KPiBHcsO8w59lLCBDYXJzdGVuDQo+DQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGNvcmUgbWFpbGluZyBsaXN0 DQo+IGNvcmVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9jb3JlDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Y29yZSBtYWlsaW5nIGxpc3QNCmNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vY29yZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3NhZ2UgbWF5IGJlIGNvbmZpZGVu dGlhbCBhbmQgbGVnYWxseSBwcm90ZWN0ZWQgdW5kZXIgYXBwbGljYWJsZSBsYXcuIFRoZSBtZXNz YWdlIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZShzKS4gSWYgeW91IGFyZSBu b3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBh bnkgdXNlLCBmb3J3YXJkaW5nLCBkaXNzZW1pbmF0aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhp cyBtZXNzYWdlIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYg eW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNl bmRlciBieSByZXR1cm4gZS1tYWlsIGFuZCBkZXN0cm95IGFsbCBjb3BpZXMgb2YgdGhlIG9yaWdp bmFsIG1lc3NhZ2UuDQo= From Bert.Greevenbosch@huawei.com Fri Sep 6 04:00:00 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E5C21E8087 for ; Fri, 6 Sep 2013 04:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.942 X-Spam-Level: X-Spam-Status: No, score=-5.942 tagged_above=-999 required=5 tests=[AWL=0.657, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTkE-ioJpvJj for ; Fri, 6 Sep 2013 03:59:56 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7702611E829E for ; Fri, 6 Sep 2013 03:59:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVC65286; Fri, 06 Sep 2013 10:59:52 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 6 Sep 2013 11:59:12 +0100 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 6 Sep 2013 11:59:33 +0100 Received: from szxeml558-mbx.china.huawei.com ([169.254.7.243]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Fri, 6 Sep 2013 18:59:27 +0800 From: Bert Greevenbosch To: "core@ietf.org" Thread-Topic: Draft with use cases and requirements for authentication and authorisation. Thread-Index: Ac6q8CUwy4xQTKCDSXaYBG5Y8W1PbQ== Date: Fri, 6 Sep 2013 10:59:26 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63D87D0EB@szxeml558-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AAMM BdiY BhCH C3vn DNCX DSjV Edc0 E4UR FeWW Fzma GUta H28a H8ql JdhY KSe0 KtxC; 1; YwBvAHIAZQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {8ECF18BF-A1F9-453A-BFA5-54558A72697D}; YgBlAHIAdAAuAGcAcgBlAGUAdgBlAG4AYgBvAHMAYwBoAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Fri, 06 Sep 2013 10:59:23 GMT; RAByAGEAZgB0ACAAdwBpAHQAaAAgAHUAcwBlACAAYwBhAHMAZQBzACAAYQBuAGQAIAByAGUAcQB1AGkAcgBlAG0AZQBuAHQAcwAgAGYAbwByACAAYQB1AHQAaABlAG4AdABpAGMAYQB0AGkAbwBuACAAYQBuAGQAIABhAHUAdABoAG8AcgBpAHMAYQB0AGkAbwBuAC4A x-cr-puzzleid: {8ECF18BF-A1F9-453A-BFA5-54558A72697D} x-originating-ip: [10.66.162.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [core] Draft with use cases and requirements for authentication and authorisation. X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 11:00:00 -0000 Hello all, I have just uploaded a draft with use cases and requirements for authentica= tion and authorisation in CoAP: http://www.ietf.org/id/draft-greevenbosch-core-authreq-00.txt The draft is a modified version of the earlier submitted draft for dice, ad= ding a home security and medical privacy use case and removing some other u= se cases. Requirements for more fine-grained access control have been added= too. I have understood that Steffi is also working on a use cases and requiremen= ts draft. In agreement with her, I have uploaded my draft as a separate dra= ft. We can see later whether or not to merge the two drafts. I hope this helps in the discussion! Best regards, Bert From prvs=954ef1a0f=abhijan.bhattacharyya@tcs.com Fri Sep 6 08:13:53 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7CA411E818B for ; Fri, 6 Sep 2013 08:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.59 X-Spam-Level: X-Spam-Status: No, score=-6.59 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, DRUGS_MUSCLE=0.01, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEmsCfdZEo8J for ; Fri, 6 Sep 2013 08:13:50 -0700 (PDT) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id A453411E81A4 for ; Fri, 6 Sep 2013 08:13:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,855,1371061800"; d="scan'208";a="445611182" Received: from INKOLSALDLPMTA2.india.tcs.com (unknown [127.0.0.1]) by INKOLSALDLPMTA2.india.tcs.com (Service) with ESMTP id 12307119411 for ; Fri, 6 Sep 2013 20:43:35 +0530 (IST) Received: from InKolM02.tcs.com (unknown [172.18.18.104]) by INKOLSALDLPMTA2.india.tcs.com (Service) with ESMTP id DA145119402 for ; Fri, 6 Sep 2013 20:43:34 +0530 (IST) To: core@ietf.org MIME-Version: 1.0 X-KeepSent: 2F287C3A:006E7190-65257BDE:00533E93; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: Abhijan Bhattacharyya Message-ID: Date: Fri, 6 Sep 2013 20:43:33 +0530 X-MIMETrack: Serialize by Notes Server on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 09/06/2013 20:43:34, Serialize complete at 09/06/2013 20:43:34, Serialize by Router on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 09/06/2013 20:43:34 Content-Type: multipart/alternative; boundary="=_alternative 0053A26065257BDE_=" Cc: Soma Bandyopadhyay , Arpan Pal Subject: [core] Fw: New Version Notification for draft-tcs-coap-no-response-option-01 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 15:13:54 -0000 This is a multipart message in MIME format. --=_alternative 0053A26065257BDE_= Content-Type: text/plain; charset="US-ASCII" Carsten, Esko, Bert and all, Thanks for the responses on the first version of this draft. We have incorporated the comments we received and enhanced the draft. The details are below. Would like your views on this one please. 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 ____________________________________________ ----- Forwarded by Abhijan Bhattacharyya/KOL/TCS on 09/06/2013 08:39 PM ----- From: internet-drafts@ietf.org To: Abhijan Bhattacharyya , Soma Bandyopadhyay , Arpan Pal Date: 09/06/2013 08:38 PM Subject: New Version Notification for draft-tcs-coap-no-response-option-01.txt A new version of I-D, draft-tcs-coap-no-response-option-01.txt has been successfully submitted by Abhijan Bhattacharyya and posted to the IETF repository. Filename: draft-tcs-coap-no-response-option Revision: 01 Title: CoAP option for no server-response Creation date: 2013-09-06 Group: Individual Submission Number of pages: 10 URL: http://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-option-01.txt Status: http://datatracker.ietf.org/doc/draft-tcs-coap-no-response-option Htmlized: http://tools.ietf.org/html/draft-tcs-coap-no-response-option-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-tcs-coap-no-response-option-01 Abstract: The server end-point does not respond with acknowledgment (ACK) in non-confirmable (NON) mode of CoAP. However, the server responds the client with a status code indicating "the result of the attempt to understand and satisfy the request". But there may be typical scenarios, while updating resources in NON mode, where any kind of response from the server may be considered redundant. Thus, in this case, the transaction becomes completely open-loop with no reverse path from the server to the client. This kind of exchange may be useful in constrained systems looking for maximized throughput with minimized resource consumption. This draft introduces a header option: 'No-Resp' to suppress responses from the server and discusses an exemplary but practical use case which actually motivated this proposition based on real experience. This option not only allows suppressing any kind of responses but allows suppressing a typical class or a combination of classes of responses. This option is applicable for both request/ response as well as resource- observe mode and may be effective for both unicast and multicast scenarios. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat =====-----=====-----===== 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 0053A26065257BDE_= Content-Type: text/html; charset="US-ASCII" Carsten, Esko, Bert and all,
Thanks for the responses on the first version of this draft. We have incorporated the comments we received and enhanced the draft. The details are below. Would like your views on this one please.

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
____________________________________________
----- Forwarded by Abhijan Bhattacharyya/KOL/TCS on 09/06/2013 08:39 PM -----
From: internet-drafts@ietf.org
To: Abhijan Bhattacharyya <abhijan.bhattacharyya@tcs.com>, Soma Bandyopadhyay <soma.bandyopadhyay@tcs.com>, Arpan Pal <arpan.pal@tcs.com>
Date: 09/06/2013 08:38 PM
Subject: New Version Notification for draft-tcs-coap-no-response-option-01.txt





A new version of I-D, draft-tcs-coap-no-response-option-01.txt
has been successfully submitted by Abhijan Bhattacharyya and posted to the
IETF repository.

Filename:                  draft-tcs-coap-no-response-option
Revision:                  01
Title:                                   CoAP option for no server-response
Creation date:                  2013-09-06
Group:                                   Individual Submission
Number of pages: 10
URL:             http://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-option-01.txt
Status:          http://datatracker.ietf.org/doc/draft-tcs-coap-no-response-option
Htmlized:        http://tools.ietf.org/html/draft-tcs-coap-no-response-option-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-tcs-coap-no-response-option-01

Abstract:
  The server end-point does not respond with acknowledgment (ACK) in
  non-confirmable (NON) mode of CoAP. However, the server responds the
  client with a status code indicating "the result of the attempt to
  understand and satisfy the request". But there may be typical
  scenarios, while updating resources in NON mode, where any kind of
  response from the server may be considered redundant. Thus, in this
  case, the transaction becomes completely open-loop with no reverse
  path from the server to the client. This kind of exchange may be
  useful in constrained systems looking for maximized throughput with
  minimized resource consumption. This draft introduces a header
  option: 'No-Resp' to suppress responses from the server and
  discusses an exemplary but practical use case which actually
  motivated this proposition based on real experience. This option not
  only allows suppressing any kind of responses but allows suppressing
  a typical class or a combination of classes of responses. This
  option is applicable for both request/ response as well as resource-
  observe mode and may be effective for both unicast and multicast
  scenarios.

                                                                                 


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

=====-----=====-----=====
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 0053A26065257BDE_=-- From wasilak@gmail.com Tue Sep 10 10:32:19 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC9ED11E80A2 for ; Tue, 10 Sep 2013 10:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FB421RfSLidH for ; Tue, 10 Sep 2013 10:32:19 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 3C46921F8721 for ; Tue, 10 Sep 2013 10:32:19 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id b12so898530wgh.3 for ; Tue, 10 Sep 2013 10:32:18 -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=b62KiBkX9X1MjRm9zjUsW9/1b2Z52MRlBSimBkfqPFg=; b=WUafPb9g2r5mWZQewAs2ntvYbblvmmNm0PMQl/sS/HnoeQgNj/ezM9JUDRg1YVt8wy 5eBe+geLNFCePZLC6/inLxNKTJevwJS0W3irgCvK/fTR5Y4G3FUqpu6ABqw3Hk1YM8Zz aoNcNKGwcvn/Oj5fmMmXT2Bv6XmqBsi2PFNBhrtqcE2SJm8fFDZ0SQmB90eva4ue1yrB qoAznDMx3CqLDG5NmcxxAi5iwmAvlq1W0vf5kBomgsxnnyyTrVWPEhmxYDpilHg9pn59 jjIqjTL1ocRboW19uGrwtO0873qlT7QH1UtPYPNhBIVZh4oicyanlJyOIjAsoWh17+XI 3r5w== MIME-Version: 1.0 X-Received: by 10.180.211.111 with SMTP id nb15mr13643544wic.55.1378834338422; Tue, 10 Sep 2013 10:32:18 -0700 (PDT) Received: by 10.216.30.81 with HTTP; Tue, 10 Sep 2013 10:32:18 -0700 (PDT) In-Reply-To: <059.81d71d56fda0c3256a7adc71ea711349@trac.tools.ietf.org> References: <059.81d71d56fda0c3256a7adc71ea711349@trac.tools.ietf.org> Date: Tue, 10 Sep 2013 19:32:18 +0200 Message-ID: From: Maciej Wasilak To: trac+core@trac.tools.ietf.org Content-Type: multipart/alternative; boundary=001a11c34854f228ab04e60ae25f Cc: draft-ietf-core-block@tools.ietf.org, core WG Subject: Re: [core] #334: MUST for in-order block transfer X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 17:32:20 -0000 --001a11c34854f228ab04e60ae25f Content-Type: text/plain; charset=UTF-8 Hello, assuming that the server is stateful, and doesn't want to answer non-sequential blockwise GET requests (because of limited memory etc.), what error response should be sent to client? Is it okay to use 5.01 "Not Implemented" with proper explanation in payload? Best Regards Maciej Wasilak --001a11c34854f228ab04e60ae25f Content-Type: text/html; charset=UTF-8
Hello,

assuming that the server is stateful, and doesn't want to answer non-sequential blockwise GET requests (because of limited memory etc.), what error response should be sent to client? Is it okay to use 5.01 "Not Implemented" with proper explanation in payload?

Best Regards
Maciej Wasilak
--001a11c34854f228ab04e60ae25f-- From cabo@tzi.org Wed Sep 11 06:24:55 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5CCF11E8117; Wed, 11 Sep 2013 06:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCsnS1IzbuGx; Wed, 11 Sep 2013 06:24:50 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 0670921E80AA; Wed, 11 Sep 2013 06:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r8BDOhZN007410; Wed, 11 Sep 2013 15:24:44 +0200 (CEST) Received: from [10.0.1.4] (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 904C13AA; Wed, 11 Sep 2013 15:24:43 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Carsten Bormann Date: Wed, 11 Sep 2013 15:24:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8896EFF2-BD1E-4634-8195-34580E1096F0@tzi.org> To: "core@ietf.org WG" X-Mailer: Apple Mail (2.1508) Cc: IETF Security Area Advisory Group Subject: [core] Travel planning: some CoRE-AA work on Sunday, Nov 3rd X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 13:24:56 -0000 (CoRE =3D Constrained RESTful Environments, the application protocol = work for the "Internet of Things".) For those that are interested in the CoRE Authorization work that = started in Berlin, and that haven't already booked their Vancouver = flights: We are planning some informal technical discussion in Vancouver on = Sunday, Nov 3rd, starting about noon. The objective is to achieve mutual understanding of the technical = approaches and maybe some merging/taxonomizing of those. The objective is expressly not to discuss how to do this work in the = IETF (rechartering? BOF?), that must come after understanding what it is = that we want to achieve. This informal meeting will have a strong "we assume you have read the = drafts" component, but otherwise open to all interested attendees. I'm = CCing SAAG because this isn't strictly an applications area subject. = (There sure will be a lot of interest in other aspects of applications = area security in Vancouver, as well...) Details of the meeting (drafts to read, agenda, room, etc.) will emerge = soon. Gr=FC=DFe, Carsten From hannes.tschofenig@gmx.net Wed Sep 11 07:50:05 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1408721E80B6 for ; Wed, 11 Sep 2013 07:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.924 X-Spam-Level: X-Spam-Status: No, score=-101.924 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18G1xeX6JpEz for ; Wed, 11 Sep 2013 07:50:00 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id E786321E80CE for ; Wed, 11 Sep 2013 07:49:59 -0700 (PDT) Received: from [10.255.135.49] ([194.251.119.201]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Lw285-1W0w8p2RZd-017lQa for ; Wed, 11 Sep 2013 16:49:58 +0200 Message-ID: <52308315.2070505@gmx.net> Date: Wed, 11 Sep 2013 17:49:57 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Carsten Bormann References: <8896EFF2-BD1E-4634-8195-34580E1096F0@tzi.org> In-Reply-To: <8896EFF2-BD1E-4634-8195-34580E1096F0@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:082EUeVG/MOYELHCY+KFyBJmuW4kL3vl8aAMwQM6xaZjFOeIiZY klxqzgIUCvADnAsyWY5qYHIiHuCvi2QueXZE8UHXVAIBXDgX/IaNNfhSLlAe3Q7m3WsA6Tw DKRnveIvLtr1qGTo1uDGrztA83/zJSK9zOTxGcNhhPMVoZtLx6YJuyJLKHarIUq97Bxbjqu VTRjUbIOCYN+o2I5iI25A== Cc: "core@ietf.org WG" Subject: Re: [core] [saag] Travel planning: some CoRE-AA work on Sunday, Nov 3rd X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 14:50:05 -0000 FYI: Using the Sunday afternoon rules out anyone from the IESG/IAB... On 11.09.2013 16:24, Carsten Bormann wrote: > (CoRE = Constrained RESTful Environments, the application protocol work for the "Internet of Things".) > > For those that are interested in the CoRE Authorization work that started in Berlin, and that haven't already booked their Vancouver flights: > > We are planning some informal technical discussion in Vancouver on Sunday, Nov 3rd, starting about noon. > The objective is to achieve mutual understanding of the technical approaches and maybe some merging/taxonomizing of those. > The objective is expressly not to discuss how to do this work in the IETF (rechartering? BOF?), that must come after understanding what it is that we want to achieve. > > This informal meeting will have a strong "we assume you have read the drafts" component, but otherwise open to all interested attendees. I'm CCing SAAG because this isn't strictly an applications area subject. (There sure will be a lot of interest in other aspects of applications area security in Vancouver, as well...) > > Details of the meeting (drafts to read, agenda, room, etc.) will emerge soon. > > Grüße, Carsten > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From schmitt@ifi.uzh.ch Thu Sep 12 01:35:10 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3333D21E8187 for ; Thu, 12 Sep 2013 01:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vigDhRuQ5JkS for ; Thu, 12 Sep 2013 01:35:06 -0700 (PDT) Received: from ladislav.ifi.uzh.ch (ladislav.ifi.uzh.ch [130.60.156.19]) by ietfa.amsl.com (Postfix) with ESMTP id EA22821E8184 for ; Thu, 12 Sep 2013 01:35:05 -0700 (PDT) Received: from authenticated sender schmitt by ladislav.ifi.uzh.ch (postfix) with ESMTPSA id SA; <5A8F976070> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 12 Sep 2013 10:35:03 +0200 From: schmitt To: core@ietf.org In-Reply-To: <8896EFF2-BD1E-4634-8195-34580E1096F0@tzi.org> References: <8896EFF2-BD1E-4634-8195-34580E1096F0@tzi.org> Message-ID: <8e82caef8ab3c2a0fc78083b11e42652@ifi.uzh.ch> X-Sender: schmitt@ifi.uzh.ch User-Agent: Roundcube Webmail/0.9.4 X-Virus-Scanned: clamav-milter 0.97.6 at ladislav X-Virus-Status: Clean Cc: Burkhard Stiller Subject: Re: [core] Travel planning: some CoRE-AA work on Sunday, Nov 3rd X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 08:35:10 -0000 Dear Carsten, the meeting is a great idea in order to discuss the drafts and pushing forward our work started in Berlin. I will arrive in Vancouver on Friday November 1st, 2013 and will join the meeting on Sunday. Regards, Corinna Am 2013-09-11 15:24, schrieb Carsten Bormann: > (CoRE = Constrained RESTful Environments, the application protocol > work for the "Internet of Things".) > > For those that are interested in the CoRE Authorization work that > started in Berlin, and that haven't already booked their Vancouver > flights: > > We are planning some informal technical discussion in Vancouver on > Sunday, Nov 3rd, starting about noon. > The objective is to achieve mutual understanding of the technical > approaches and maybe some merging/taxonomizing of those. > The objective is expressly not to discuss how to do this work in the > IETF (rechartering? BOF?), that must come after understanding what it > is that we want to achieve. > > This informal meeting will have a strong "we assume you have read the > drafts" component, but otherwise open to all interested attendees. > I'm CCing SAAG because this isn't strictly an applications area > subject. (There sure will be a lot of interest in other aspects of > applications area security in Vancouver, as well...) > > Details of the meeting (drafts to read, agenda, room, etc.) will emerge > soon. > > Grüße, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From Bert.Greevenbosch@huawei.com Fri Sep 13 19:12:08 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9AD011E813F; Fri, 13 Sep 2013 19:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZHPaT70ATkH; Fri, 13 Sep 2013 19:12:04 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8FAF521E80C9; Fri, 13 Sep 2013 19:12:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AXH63254; Sat, 14 Sep 2013 02:12:00 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 14 Sep 2013 03:11:42 +0100 Received: from SZXEML449-HUB.china.huawei.com (10.82.67.192) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 14 Sep 2013 03:11:58 +0100 Received: from szxeml558-mbx.china.huawei.com ([169.254.7.3]) by szxeml449-hub.china.huawei.com ([10.82.67.192]) with mapi id 14.01.0323.007; Sat, 14 Sep 2013 10:11:53 +0800 From: Bert Greevenbosch To: Carsten Bormann , "core@ietf.org WG" Thread-Topic: [core] Travel planning: some CoRE-AA work on Sunday, Nov 3rd Thread-Index: AQHOrvJbdKBymvrM00mMl/392ngwX5nDCXvg Date: Sat, 14 Sep 2013 02:11:52 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63D8E1F63@szxeml558-mbx.china.huawei.com> References: <8896EFF2-BD1E-4634-8195-34580E1096F0@tzi.org> In-Reply-To: <8896EFF2-BD1E-4634-8195-34580E1096F0@tzi.org> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.162.63] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: IETF Security Area Advisory Group Subject: Re: [core] Travel planning: some CoRE-AA work on Sunday, Nov 3rd X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 02:12:08 -0000 Hi Carsten, Indeed I look forward to discuss the scope about the authorisation/authenti= cation work during the Sunday meeting. I think we should not a priori say that the discussion on how to do the wor= k (recharter or BoF) is off-topic. I don't think we need to allocate much t= ime for that discussion, but having it is important in order to move on and= do the work. So I prefer to keep the "how" part in the discussion. Best regards, Bert > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of > Carsten Bormann > Sent: 11 September 2013 21:25 > To: core@ietf.org WG > Cc: IETF Security Area Advisory Group > Subject: [core] Travel planning: some CoRE-AA work on Sunday, Nov 3rd >=20 > (CoRE =3D Constrained RESTful Environments, the application protocol work > for the "Internet of Things".) >=20 > For those that are interested in the CoRE Authorization work that > started in Berlin, and that haven't already booked their Vancouver > flights: >=20 > We are planning some informal technical discussion in Vancouver on > Sunday, Nov 3rd, starting about noon. > The objective is to achieve mutual understanding of the technical > approaches and maybe some merging/taxonomizing of those. > The objective is expressly not to discuss how to do this work in the > IETF (rechartering? BOF?), that must come after understanding what it > is that we want to achieve. >=20 > This informal meeting will have a strong "we assume you have read the > drafts" component, but otherwise open to all interested attendees. > I'm CCing SAAG because this isn't strictly an applications area subject. > (There sure will be a lot of interest in other aspects of applications > area security in Vancouver, as well...) >=20 > Details of the meeting (drafts to read, agenda, room, etc.) will emerge > soon. >=20 > Gr=FC=DFe, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From ludwig@sics.se Mon Sep 16 07:11:45 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D95FF11E80EF for ; Mon, 16 Sep 2013 07:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHoMsiaDTqnR for ; Mon, 16 Sep 2013 07:11:41 -0700 (PDT) Received: from fsmsg2.sics.se (fsmsg2.sics.se [IPv6:2001:6b0:3a:1:250:56ff:fea9:52ad]) by ietfa.amsl.com (Postfix) with ESMTP id 8299511E8124 for ; Mon, 16 Sep 2013 07:11:40 -0700 (PDT) Received: from pps.filterd (fsmsg2 [127.0.0.1]) by fsmsg2.sics.se (8.14.5/8.14.5) with SMTP id r8GDodu0011192 for ; Mon, 16 Sep 2013 16:11:39 +0200 Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by fsmsg2.sics.se with ESMTP id 1esndkf3k0-1 for ; Mon, 16 Sep 2013 16:11:38 +0200 Received: from [192.168.0.103] (unknown [85.235.11.178]) (Authenticated sender: ludwig@sics.se) by letter.sics.se (Postfix) with ESMTPSA id DC34540116 for ; Mon, 16 Sep 2013 16:11:38 +0200 (CEST) Message-ID: <5237119A.8020809@sics.se> Date: Mon, 16 Sep 2013 16:11:38 +0200 From: Ludwig Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: core@ietf.org References: <20130916140830.26313.93692.idtracker@ietfa.amsl.com> In-Reply-To: <20130916140830.26313.93692.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130916140830.26313.93692.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040402030608000401000808" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-16_03:2013-09-16, 2013-09-15, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=15 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1309160060 Subject: [core] Fwd: New Version Notification for draft-seitz-core-sec-usecases-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 14:11:46 -0000 This is a cryptographically signed message in MIME format. --------------ms040402030608000401000808 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Dear all, I have just submitted a draft on use cases for security measures in=20 constrained environments. The idea is to start a discussion on this=20 topic before the November meeting. Regards, Ludwig Seitz -------- Original Message -------- Subject: New Version Notification for draft-seitz-core-sec-usecases-00.tx= t Date: Mon, 16 Sep 2013 07:08:30 -0700 From: internet-drafts@ietf.org To: Ludwig Seitz , Goeran Selander=20 , Stefanie Gerdes , Goran=20 Selander A new version of I-D, draft-seitz-core-sec-usecases-00.txt has been successfully submitted by Ludwig Seitz and posted to the IETF repository. Filename: draft-seitz-core-sec-usecases Revision: 00 Title: Use cases for CoRE security Creation date: 2013-09-16 Group: Individual Submission Number of pages: 19 URL:=20 http://www.ietf.org/internet-drafts/draft-seitz-core-sec-usecases-00.txt Status:=20 http://datatracker.ietf.org/doc/draft-seitz-core-sec-usecases Htmlized: http://tools.ietf.org/html/draft-seitz-core-sec-usecases= -00 Abstract: This document presents use cases for security measures in scenarios involving constrained RESTful devices. Special focus is placed on access control and authentication. Where specific details are relevant, it is assumed that the devices use CoAP as communication protocol, however most conclusions apply generally. A number of security requirements are derived from the use cases, which are intended as a guideline for developing a comprehensive authentication and authorization approach for this class of scenarios. =20 Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------ms040402030608000401000808 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 BhgwggUAoAMCAQICAwW1izANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTEzMDExNTAyMDUwNloXDTE0MDExNTE0Mzc0OFowODEXMBUGA1UE AwwObHVkd2lnQHNpY3Muc2UxHTAbBgkqhkiG9w0BCQEWDmx1ZHdpZ0BzaWNzLnNlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqm5Fq+vazAJCxhLsrE6yZ4Fcjf22HECMhhoH QAVWMuk61UnFAxiiKnsGb2iRrw9fFD2ZZP+VVKiojuMaNzlnyrULh84UwJhmkm6Ab2olLQ4x XZqNDvFe7djMtMMgqD8Erf35WuK8mrRjqHPX/imDEw4Ub6XvL5+rnhBKQozCm5FoIHOcol5H EbAO+F4XZA3pgQFyUWpWGlyIMZ3na9fkCBspupWZ68ytytxgB0poqbqJMSZtge6bkP/gZo6e dnbAydjkSkqHHGbpKzMJVI12TyJlJTN70Zg/OF4EMgcwN0tmJvrNqhH3oXlkKkTWk94ojP8M J3eQv6del7mB1tJcuwIDAQABo4IC1DCCAtAwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTAO/qDJzu5Icr9AFUhmI3z qGMpbjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAZBgNVHREEEjAQgQ5sdWR3 aWdAc2ljcy5zZTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsG AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcC AjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0 aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5 aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0 YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzAB hi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN AQELBQADggEBADhtqCPIvc8t6La1swQso5U7FF3Is5txWrQWPzcttJMyPo1LzdNT/jHEKF93 nOqiKm50NISmDFkBSxKOTTYPFJ4thgFcTZf+K57ucvxL/c+MLj3PlmCMNmtciCa8gxpldYz4 aob7CT02KQZvX+yGUmOTdHkoLd9FaxRq0ei43EAxjGIsU7vliaAoKCSO0pRsdtSrOYNV3fSd ZB6xd8KBjAJsC8P/Q2BfeMT5+fJPvX5pfj8h+qyGkJCPx2RHhkf5tSIrnOAoYkvrUZFk1JJx H+v1KrX2QRCu3fx7L9D3S1QNSCD3d3nDcM2sXdtGg6/KynBtw31O4YqQWgU9XQp+NoYwggY0 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 bWVkaWF0ZSBDbGllbnQgQ0ECAwW1izAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA5MTYxNDExMzhaMCMGCSqGSIb3DQEJBDEW BBQIJ/C6alXSiLQsFw7oNqhR+teYyzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBbWLMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMFtYswDQYJKoZIhvcNAQEBBQAE ggEAQbvJ/AIB3nKdNkBp0THBTrnfFx+WkNKhVQguFXk33tpvT42bov+8wavCDjhErKaO1OJi dbj6tyY+XP8zZ6a9yPftcJol20y2aXBYHeTEBoru7JbYvH5Idz9K9q+VtLQgMbNBEA60fzrz rwx3vS8dvqFTvzw41gwedFDN6dLykqCKTT0taZ2ruh8Ky632b48/gvZfLWne5R4oW7FxCneG W2koDRPYiRCss0xgUbunYn8bsu/C6zQV2FlLsPb9B8wtU74tM3y0oqLnXX8psCWCVBEpmjnW IDwt3DyX8T66kQuvgennzR646clntjB5VcsNvYO2InnDT+cqK5MqQZd5AgAAAAAAAA== --------------ms040402030608000401000808-- From trac+core@trac.tools.ietf.org Tue Sep 17 18:27:28 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06F3E11E8172 for ; Tue, 17 Sep 2013 18:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VogNS0kcnnO for ; Tue, 17 Sep 2013 18:27:27 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 53C2911E8264 for ; Tue, 17 Sep 2013 18:27:23 -0700 (PDT) Received: from localhost ([127.0.0.1]:56508 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VM6Y6-0005M1-AN; Wed, 18 Sep 2013 03:27:22 +0200 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-observe@tools.ietf.org, hartke@tzi.org X-Trac-Project: core Date: Wed, 18 Sep 2013 01:27:22 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/333#comment:1 Message-ID: <068.768891141b7ccd2d1cadd163d3bf0ed8@trac.tools.ietf.org> References: <053.eaebf2584c86124636dd01b28b3dcfbc@trac.tools.ietf.org> X-Trac-Ticket-ID: 333 In-Reply-To: <053.eaebf2584c86124636dd01b28b3dcfbc@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-observe@tools.ietf.org, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: hartke@tzi.org Resent-Message-Id: <20130918012727.53C2911E8264@ietfa.amsl.com> Resent-Date: Tue, 17 Sep 2013 18:27:23 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #333: Consistent sequence numbers across requests X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 01:27:28 -0000 #333: Consistent sequence numbers across requests Changes (by hartke@tzi.org): * status: new => closed * resolution: => fixed Comment: Done in -10. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- hartke@tzi.org | observe@tools.ietf.org Type: protocol | Status: closed defect | Milestone: post-WGLC-1 Priority: minor | Version: Component: observe | Resolution: fixed Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From esko.dijk@philips.com Tue Sep 17 23:59:50 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B879611E81A2 for ; Tue, 17 Sep 2013 23:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[AWL=-1.208, BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6WdU+cyLlv6 for ; Tue, 17 Sep 2013 23:59:44 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id E66E611E8197 for ; Tue, 17 Sep 2013 23:59:41 -0700 (PDT) Received: from mail16-am1-R.bigfish.com (10.3.201.239) by AM1EHSOBE016.bigfish.com (10.3.207.138) with Microsoft SMTP Server id 14.1.225.22; Wed, 18 Sep 2013 06:59:40 +0000 Received: from mail16-am1 (localhost [127.0.0.1]) by mail16-am1-R.bigfish.com (Postfix) with ESMTP id 79AE240147 for ; Wed, 18 Sep 2013 06:59:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VPS-26(zz217bI15d6Oc85fh9251Idd85kzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah18c673h1de097h186068h8275bh8275dhz2dh2a8h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1bceh1fb3h1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h20f0h1155h) Received: from mail16-am1 (localhost.localdomain [127.0.0.1]) by mail16-am1 (MessageSwitch) id 1379487577672486_25766; Wed, 18 Sep 2013 06:59:37 +0000 (UTC) Received: from AM1EHSMHS021.bigfish.com (unknown [10.3.201.229]) by mail16-am1.bigfish.com (Postfix) with ESMTP id 9396E4400BF for ; Wed, 18 Sep 2013 06:59:37 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by AM1EHSMHS021.bigfish.com (10.3.207.150) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 18 Sep 2013 06:59:37 +0000 Received: from 011-DB3MMR1-021.MGDPHG.emi.philips.com (10.128.28.103) by 011-DB3MMR1-005.MGDPHG.emi.philips.com (10.128.28.55) with Microsoft SMTP Server (TLS) id 14.3.146.2; Wed, 18 Sep 2013 06:59:37 +0000 Received: from 011-DB3MPN2-083.MGDPHG.emi.philips.com ([169.254.3.178]) by 011-DB3MMR1-021.MGDPHG.emi.philips.com ([fe80::f066:9203:e7da:3658%11]) with mapi id 14.03.0146.002; Wed, 18 Sep 2013 06:59:36 +0000 From: "Dijk, Esko" To: "core (core@ietf.org)" Thread-Topic: http-mapping: selection of a default HTTP to CoAP URI mapping Thread-Index: Ac60OsOV2dEwi2WCRIqr26yEuU2TpQ== Date: Wed, 18 Sep 2013 06:59:35 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618016D45F3@011-DB3MPN2-083.MGDPHG.emi.philips.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.106] Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED618016D45F3011DB3MPN2083MG_" MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [core] http-mapping: selection of a default HTTP to CoAP URI mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 06:59:50 -0000 --_000_031DD135F9160444ABBE3B0C36CED618016D45F3011DB3MPN2083MG_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, at the last CoRE meeting in Berlin it was discussed that we need to make a = selection for a default HTTP to CoAP URI mapping. The options for this are = currently presented in the http-mapping I-D, http://tools.ietf.org/html/dra= ft-ietf-core-http-mapping-01#section-4.2 . Note that other (non-default) ma= ppings are also possible; this is just about selection of a sensible defaul= t configuration. Based on the analysis, solution #2 scores best and #5 second-best. Any inpu= t on these options (or other options/extensions/etc.) is now requested by t= he authors - please respond to the list if you have feedback! We would like= to consolidate to one option for the http-mapping I-D around October 10th = and then do an update to -02. Example HTTP URI for solution #2: http://mappingproxy.example.com/.well-known/core-translate/server.coap.e= xample.com:4567/foo/bar?a=3D3 Example HTTP URI for solution #5: http://mappingproxy.example.com/.well-known/core-translate/coap/server.c= oap.example.com/4567/foo%2Fbar/a=3D3 Both map to a CoAP URI: coap://server.coap.example.com:4567/foo/bar?a=3D3 best regards, (on behalf of the http-mapping authors) Esko ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_031DD135F9160444ABBE3B0C36CED618016D45F3011DB3MPN2083MG_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

at the last CoRE meeting in Berlin it was discussed = that we need to make a selection for a default HTTP to CoAP URI mapping. Th= e options for this are currently presented in the http-mapping I-D, http://tools.ietf.org/html/draft-ietf-core= -http-mapping-01#section-4.2 . Note that other (non-default) map= pings are also possible; this is just about selection of a sensible default= configuration.

 

Based on the analysis, solution #2 scores best and #= 5 second-best. Any input on these options (or other options/extensions= /etc.) is now requested by the authors – please respond to the l= ist if you have feedback! We would like to consolidate to one option for the http-mapping I-D around October 10th  and then do an update to -02.

 

Example HTTP URI for solution #2:

   http://mappingproxy.example.com/.w= ell-known/core-translate/server.coap.example.com:4567/foo/bar?a=3D3

 

Example HTTP URI for solution #5:

   http://mappingproxy.example.com/.well-k= nown/core-translate/coap/server.coap.example.com/4567/foo%2Fbar/a=3D3

 

Both map to a CoAP URI:

   coap://server.coap.example.com:4567/foo= /bar?a=3D3

 

best regards,

(on behalf of the http-mapping authors)

 

Esko

 

 


The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
 --_000_031DD135F9160444ABBE3B0C36CED618016D45F3011DB3MPN2083MG_-- From zach@sensinode.com Wed Sep 18 20:12:24 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8011811E80E2 for ; Wed, 18 Sep 2013 20:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHFfyJyaEOCO for ; Wed, 18 Sep 2013 20:12:19 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 757D411E80D7 for ; Wed, 18 Sep 2013 20:12:18 -0700 (PDT) Received: from [10.0.0.4] (c-50-131-146-123.hsd1.ca.comcast.net [50.131.146.123]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r8J3C96H022463 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 19 Sep 2013 06:12:16 +0300 X-Authenticated-User: sensinodecom From: Zach Shelby Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <065674C3-461E-4305-8E8C-5E8D91059A60@sensinode.com> Date: Wed, 18 Sep 2013 20:12:09 -0700 To: " WG" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [core] CoAP Plugtest Nov 19-22 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 03:12:24 -0000 We have had two really successful Plugtests on CoAP in the past, and now = that CoAP has been finalised, this is the ideal time for all = implementers to get together and verify the correctness and = interoperability of their implementation.=20 ETSI Plugtests=99, the IPSO Alliance and the Open Mobile Alliance (OMA), = are pleased to invite you to participate in the next CoAP and OMA = Lightweight M2M Interop Test event taking place from 19-22 November 2013 = in Las Vegas, USA.=20 =20 This 3rd Plugtests event on Constrained Application Protocol (CoAP) will = assess the interoperability of multivendor CoAP implementations = including also the coverage of OMA LWM2M and DTLS. Interoperability test = scenarios based on the IETF CoRE and OMA standards for M2M will be = proposed to participants. The test scenarios will focus on server and = client CoAP end-point implementations and products focusing on the base = CoAP specification, CoAP Block Transfer, CoAP Observation and the CoRE = Link Format.=20 =20 The testing includes an improvement of scenarios performed at previous = CoAP events, with brand new tests on CoAP standards, OMA Lightweight M2M = and Security DTLS. =20 Participation at this interoperability event is open to everyone with an = implementation to test and is free of charge. =20 If you need to be sure your products and implementations are fit for the = growing M2M market, this is an event not to be missed! Please register = as soon as possible and find more details on this website = www.etsi.org/coap-oma-lightweight-m2m =20 If you would like to know more or have any questions, please contact us = at plugtests@etsi.org. --=20 Zach Shelby From internet-drafts@ietf.org Thu Sep 19 14:47:17 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52AEF21F8B12; Thu, 19 Sep 2013 14:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukgKhMyM4SlZ; Thu, 19 Sep 2013 14:47:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F50321F89FF; Thu, 19 Sep 2013 14:47:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130919214716.12701.52624.idtracker@ietfa.amsl.com> Date: Thu, 19 Sep 2013 14:47:16 -0700 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-groupcomm-13.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 21:47:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments Working = Group of the IETF. Title : Group Communication for CoAP Author(s) : Akbar Rahman Esko Dijk Filename : draft-ietf-core-groupcomm-13.txt Pages : 38 Date : 2013-09-19 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-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-groupcomm-13 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 Akbar.Rahman@InterDigital.com Thu Sep 19 14:54:50 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A6321F83EF for ; Thu, 19 Sep 2013 14:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6ZP9FlfkM0A for ; Thu, 19 Sep 2013 14:54:43 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFDF21F84D0 for ; Thu, 19 Sep 2013 14:54:40 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Sep 2013 17:54:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Sep 2013 17:54:39 -0400 Message-ID: In-Reply-To: <20130919214716.12701.52624.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] I-D Action: draft-ietf-core-groupcomm-13.txt Thread-Index: Ac61ggiGw0+GNbGjSRWROTv4K8r4awAAHtnQ References: <20130919214716.12701.52624.idtracker@ietfa.amsl.com> From: "Rahman, Akbar" To: X-OriginalArrivalTime: 19 Sep 2013 21:54:39.0808 (UTC) FILETIME=[D7044400:01CEB582] Subject: Re: [core] I-D Action: draft-ietf-core-groupcomm-13.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 21:54:50 -0000 Hi, We have submitted an update of the Group Communication as follows: o Extensive editorial updates due to comments from the Chair's review (by Carsten Bormann) of the draft. The best way to see the changes will be to do a -Diff with Rev. 12. o The technical comments from the Chair's review will be addressed in a future revision after tickets are generated and the solutions are agreed to on the WG E-mail list. Comments are welcome. Best Regards, Akbar & Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Thursday, September 19, 2013 5:47 PM To: i-d-announce@ietf.org Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-groupcomm-13.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 Author(s) : Akbar Rahman Esko Dijk Filename : draft-ietf-core-groupcomm-13.txt Pages : 38 Date : 2013-09-19 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-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-groupcomm-13 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 Akbar.Rahman@InterDigital.com Fri Sep 20 07:43:01 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC3E21F9A72 for ; Fri, 20 Sep 2013 07:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqgsRF4jI17i for ; Fri, 20 Sep 2013 07:42:57 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 05D5721F9A96 for ; Fri, 20 Sep 2013 07:42:56 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 20 Sep 2013 10:42:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CEB60F.B1A9EA1C" Date: Fri, 20 Sep 2013 10:42:55 -0400 Message-ID: In-Reply-To: <031DD135F9160444ABBE3B0C36CED618016D45F3@011-DB3MPN2-083.MGDPHG.emi.philips.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] http-mapping: selection of a default HTTP to CoAP URI mapping Thread-Index: Ac60OsOV2dEwi2WCRIqr26yEuU2TpQB07kPw References: <031DD135F9160444ABBE3B0C36CED618016D45F3@011-DB3MPN2-083.MGDPHG.emi.philips.com> From: "Rahman, Akbar" To: "Dijk, Esko" X-OriginalArrivalTime: 20 Sep 2013 14:42:56.0264 (UTC) FILETIME=[B1B6E080:01CEB60F] Cc: core@ietf.org Subject: Re: [core] http-mapping: selection of a default HTTP to CoAP URI mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 14:43:01 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CEB60F.B1A9EA1C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Esko, =20 =20 Thanks. Also, perhaps we could consider changing the title of the draft as Andrew pointed out previously: =20 "We can discuss if a non-BCP should have "Best Practices" in the title, but the objective is to provide examples of good usage for implementers, not to give strong recommendations." http://www.ietf.org/mail-archive/web/core/current/msg04461.html =20 =20 =20 How about changing the title to: "Guidelines for HTTP-CoAP Mapping Implementation"? Any objections to this? (Note - the file name could be left as is, i.e. draft-ietf-core-http-mapping) =20 =20 Best Regards, =20 =20 Akbar =20 =20 =20 From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Dijk, Esko Sent: Wednesday, September 18, 2013 3:00 AM To: core (core@ietf.org) Subject: [core] http-mapping: selection of a default HTTP to CoAP URI mapping =20 Dear all, =20 at the last CoRE meeting in Berlin it was discussed that we need to make a selection for a default HTTP to CoAP URI mapping. The options for this are currently presented in the http-mapping I-D, http://tools.ietf.org/html/draft-ietf-core-http-mapping-01#section-4.2 . Note that other (non-default) mappings are also possible; this is just about selection of a sensible default configuration. =20 Based on the analysis, solution #2 scores best and #5 second-best. Any input on these options (or other options/extensions/etc.) is now requested by the authors - please respond to the list if you have feedback! We would like to consolidate to one option for the http-mapping I-D around October 10th and then do an update to -02. =20 Example HTTP URI for solution #2:=20 =20 http://mappingproxy.example.com/.well-known/core-translate/server.coap.e xample.com:4567/foo/bar?a=3D3 =20 Example HTTP URI for solution #5: =20 http://mappingproxy.example.com/.well-known/core-translate/coap/server.c oap.example.com/4567/foo%2Fbar/a=3D3 =20 Both map to a CoAP URI: coap://server.coap.example.com:4567/foo/bar?a=3D3 =20 best regards, (on behalf of the http-mapping authors) =20 Esko =20 =20 =20 ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. ------_=_NextPart_001_01CEB60F.B1A9EA1C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Esko,

 

 

Thanks.  Also, = perhaps we could consider changing the title of the draft as Andrew = pointed out previously:

 

“We can = discuss if a non-BCP should have "Best Practices" in = the
title, but the objective is to provide examples of good usage = for
implementers, not to give strong = recommendations.”

= http://www.ietf.org/mail-archive/web/core/current/msg04461.html<= /o:p>

 

 

 

How about changing the = title to: “Guidelines for HTTP-CoAP Mapping = Implementation”?  Any objections to = this?

(Note – = the file name could be left as is, i.e. draft-ietf-core-http-mapping)

 

 

Best = Regards,

 

 

Akbar

 

 

 

From:= = core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = Dijk, Esko
Sent: Wednesday, September 18, 2013 3:00 = AM
To: core (core@ietf.org)
Subject: [core] = http-mapping: selection of a default HTTP to CoAP URI = mapping

 

Dear = all,

 

at the last CoRE meeting in Berlin it was discussed = that we need to make a selection for a default HTTP to CoAP URI mapping. = The options for this are currently presented in the http-mapping I-D, http://tools.ietf.org/html/draft-ietf-core-htt= p-mapping-01#section-4.2 . Note that other (non-default) = mappings are also possible; this is just about selection of a sensible = default configuration.

 

Based on the = analysis, solution #2 scores best and #5 second-best. Any input on = these options (or other options/extensions/etc.) is now = requested by the authors – please respond to the list if you = have feedback! We would like to consolidate to one option for the = http-mapping I-D around October 10th  and then do an = update to -02.

 

Example HTTP = URI for solution #2:

   http://mappingproxy.example.com/.we= ll-known/core-translate/server.coap.example.com:4567/foo/bar?a=3D3

 

Example HTTP URI for solution #5:

   http://mappingproxy.example.= com/.well-known/core-translate/coap/server.coap.example.com/4567/foo%2Fba= r/a=3D3

 

Both map to a CoAP URI:

   = coap://server.coap.example.com:4567/foo/bar?a=3D3

 

best = regards,

(on behalf of the = http-mapping authors)

 

Esko

 

 

 

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

------_=_NextPart_001_01CEB60F.B1A9EA1C-- From cabo@tzi.org Mon Sep 23 04:51:52 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C4F21F9D5D; Mon, 23 Sep 2013 04:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.905 X-Spam-Level: X-Spam-Status: No, score=-104.905 tagged_above=-999 required=5 tests=[AWL=-1.256, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMxI-F5ZNGGr; Mon, 23 Sep 2013 04:51:43 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF5321F8C20; Mon, 23 Sep 2013 04:50: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.4/8.14.4) with ESMTP id r8NBoAE5004901; Mon, 23 Sep 2013 13:50:10 +0200 (CEST) Received: from [192.168.217.105] (p548903C6.dip0.t-ipconnect.de [84.137.3.198]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 0475881A; Mon, 23 Sep 2013 13:50:09 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Carsten Bormann Date: Mon, 23 Sep 2013 13:50:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8BB4E7F6-BB71-46AF-9F29-1C9EBFBEA377@tzi.org> References: <6C9B460C0D0DA64698B802EFA5860453B1527DFA51@XMSCLUSTER-MBX.etsihq.org> To: "core@ietf.org WG" , "dtls-iot@ietf.org" X-Mailer: Apple Mail (2.1510) Subject: [core] next Interop Test Event on CoAP, DTLS, and OMA Lightweight M2M X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 11:51:57 -0000 CoAP was finally approved on July 11, 2013, and our way of using DTLS = has stabilized (at least until we optimize it some more), so -- as = mentioned at IETF87 -- it is time for another interop. =20 As with the last two formal CoAP interops, ETSI will organize a = "plugtest"; participation is free of charge. Colocation is with OMA, this time, from 19th to 22nd November 2013 in = Las Vegas, USA. (This leaves one week between IETF88 and the plugtest.) I will be there, as will be a few other people that have been involved = in the IETF work. So if you want to hone the interoperability of your CoAP, DTLS, and of = course OMA LWM2M implementations, you want to be there, too. The event planners will be able to do their best if you register as = early as possible: see the green button on = http://www.etsi.org/coap-oma-lightweight-m2m where you also find more = information. (If you have any questions or issues, feel free to send me personal = mail.) Please forward this info to implementers who might not be on these = mailing lists. Gr=FC=DFe, Carsten Begin forwarded message: > ETSI Plugtests=99, the IPSO Alliance and the Open Mobile Alliance = (OMA), are pleased to invite you to participate in the next CoAP and OMA = Lightweight M2M Interop Test event taking place from 19-22 November 2013 = in Las Vegas, USA. The event is co-located with the OMA AGM, Public = Seminar/Webinar, Board, Technical Plenary and Working Group meetings. > =20 > This 3rd Plugtests event on Constrained Application Protocol (CoAP) = will assess the interoperability of multivendor CoAP implementations = including also the coverage of OMA LWM2M and DTLS. > Interoperability test scenarios based on the IETF CoRE and OMA = standards for M2M will be proposed to participants. The test scenarios = will focus on server and client CoAP end-point implementations and = products focusing on the base CoAP specification, CoAP Block Transfer, = CoAP Observation and the CoRE Link Format.=20 > =20 > The testing includes an improvement of scenarios performed at previous = CoAP events, with brand new tests on CoAP standards, OMA Lightweight M2M = and Security DTLS. > =20 > Participation at this interoperability event is open to everyone with = an implementation to test and is free of charge. > =20 > If you need to be sure your products and implementations are fit for = the growing M2M market, this is an event not to be missed! > Please register as soon as possible and find more details on this = website www.etsi.org/coap-oma-lightweight-m2m > =20 > If you would like to know more or have any questions, please contact = us at plugtests@etsi.org. > =20 > Yours faithfully, > =20 > Laurent VELEZ > ETSI Technical Expert > Centre for Testing and Interoperability (CTI) > European Telecommunication Standards Institute (ETSI) > Tel: +33 (0)4 92 94 43 21 > Mob: +33 (0)6 07 59 08 58 From trac+core@trac.tools.ietf.org Mon Sep 23 07:45:49 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E9721F9AA2 for ; Mon, 23 Sep 2013 07:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oH21kayTJFDY for ; Mon, 23 Sep 2013 07:45:48 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 82DB521F8E51 for ; Mon, 23 Sep 2013 07:45:48 -0700 (PDT) Received: from localhost ([127.0.0.1]:39346 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VO7OR-0005Hu-Dm; Mon, 23 Sep 2013 16:45:43 +0200 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-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Mon, 23 Sep 2013 14:45:43 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/337 Message-ID: <060.8762ad3a0453b584751467d309547d07@trac.tools.ietf.org> X-Trac-Ticket-ID: 337 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@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 grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20130923144548.82DB521F8E51@ietfa.amsl.com> Resent-Date: Mon, 23 Sep 2013 07:45:48 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #337: Rename "ip" key to "a" in sec. 2.6 (Configuring Group Membership in Endpoints) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 14:45:49 -0000 #337: Rename "ip" key to "a" in sec. 2.6 (Configuring Group Membership in Endpoints) Rename "ip" key to "a" in section 2.6 (Configuring Group Membership in Endpoints): since the value of the "ip" key refers to the IP address, using the "a" of address seems more appropriate. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: protocol | Status: new enhancement | Milestone: Priority: minor | Version: Component: groupcomm | Keywords: Severity: - | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Sep 23 07:59:51 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4568021F91AB for ; Mon, 23 Sep 2013 07:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIdnKmBN0HKJ for ; Mon, 23 Sep 2013 07:59:50 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3B421F9360 for ; Mon, 23 Sep 2013 07:59:50 -0700 (PDT) Received: from localhost ([127.0.0.1]:40065 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VO7c3-0006zM-IF; Mon, 23 Sep 2013 16:59:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 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-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Mon, 23 Sep 2013 14:59:47 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/338 Message-ID: <060.4e9d8359b433df809eb0e0e0b29e907c@trac.tools.ietf.org> X-Trac-Ticket-ID: 338 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@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 grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20130923145950.7F3B421F9360@ietfa.amsl.com> Resent-Date: Mon, 23 Sep 2013 07:59:50 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #338: Do not include the "ip" key/value when its value is unknown X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 14:59:51 -0000 #338: Do not include the "ip" key/value when its value is unknown Section 2.6: Do not include the "ip" key/value when its value is unknown. Currently the value is always required even when it's empty. Proposal: FROM: “The REQUIRED "ip" key/value pair specifies the IP multicast address of the group. Its value can be empty if unknown at the time of generating the response.†TO: "The "ip" key/value pair specifies the IP multicast address of the group. The “ip†key/value pair MUST be included if the IP address is known at the time of generating the response, and SHOULD NOT be included if unknown." -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: protocol | Status: new enhancement | Milestone: Priority: minor | Version: Component: groupcomm | Keywords: Severity: - | -------------------------+------------------------------------------------- Ticket URL: core From internet-drafts@ietf.org Mon Sep 23 08:57:45 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA57E21F9FBC; Mon, 23 Sep 2013 08:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.497 X-Spam-Level: X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGFlIomatK1t; Mon, 23 Sep 2013 08:57:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 133E321F9FB5; Mon, 23 Sep 2013 08:57:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130923155743.32168.81225.idtracker@ietfa.amsl.com> Date: Mon, 23 Sep 2013 08:57:43 -0700 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-groupcomm-14.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 15:57:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments Working = Group of the IETF. Title : Group Communication for CoAP Author(s) : Akbar Rahman Esko Dijk Filename : draft-ietf-core-groupcomm-14.txt Pages : 39 Date : 2013-09-23 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-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-groupcomm-14 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 Akbar.Rahman@InterDigital.com Mon Sep 23 09:03:10 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4AAE21F866E for ; Mon, 23 Sep 2013 09:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEqA5-Vq+p1r for ; Mon, 23 Sep 2013 09:03:06 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 945EB21F91F2 for ; Mon, 23 Sep 2013 09:03:06 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Sep 2013 12:03:05 -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, 23 Sep 2013 12:03:05 -0400 Message-ID: In-Reply-To: <20130923155743.32168.81225.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] I-D Action: draft-ietf-core-groupcomm-14.txt Thread-Index: Ac64deOB+q2JMsFXRLaCOubo0onPAgAAANlA References: <20130923155743.32168.81225.idtracker@ietfa.amsl.com> From: "Rahman, Akbar" To: X-OriginalArrivalTime: 23 Sep 2013 16:03:05.0595 (UTC) FILETIME=[6389CCB0:01CEB876] Subject: Re: [core] I-D Action: draft-ietf-core-groupcomm-14.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 16:03:10 -0000 Hi, We have updated the Groupcomm I-D to address the final 2 editorial comments from Carsten, and also have tackled one of his technical comments. In summary: Changes from ietf-13 to ietf-14: o Update to address final editorial comments from the Chair's review (by Carsten Bormann) of the draft. This included restructuring of Section 2.6 (Configuring Group Memberships) and Section 4 (Deployment Guidelines) to make it easier to read. Also various other editorial changes. o Changed "ip" field to "a" in Section 2.6 (#337) We plan to address the remaining 5 technical comments from Carsten (via Tickets) in the coming days. All comment are welcome. Best Regards, Akbar & Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Monday, September 23, 2013 11:58 AM To: i-d-announce@ietf.org Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-groupcomm-14.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 Author(s) : Akbar Rahman Esko Dijk Filename : draft-ietf-core-groupcomm-14.txt Pages : 39 Date : 2013-09-23 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-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-groupcomm-14 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 internet-drafts@ietf.org Mon Sep 23 15:47:44 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82E7021F9CA9; Mon, 23 Sep 2013 15:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUZvDmOGLKai; Mon, 23 Sep 2013 15:47:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BD12B21F9D71; Mon, 23 Sep 2013 15:47:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130923224743.32168.97627.idtracker@ietfa.amsl.com> Date: Mon, 23 Sep 2013 15:47:43 -0700 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-observe-10.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 22:47:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments Working = Group of the IETF. Title : Observing Resources in CoAP Author(s) : Klaus Hartke Filename : draft-ietf-core-observe-10.txt Pages : 31 Date : 2013-09-23 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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-observe There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-observe-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-observe-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From trac+core@trac.tools.ietf.org Tue Sep 24 01:49:34 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7C3421F99ED for ; Tue, 24 Sep 2013 01:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyeXxx-WXFCr for ; Tue, 24 Sep 2013 01:49:34 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 56CC221F94FA for ; Tue, 24 Sep 2013 01:49:33 -0700 (PDT) Received: from localhost ([127.0.0.1]:47541 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VOOJ8-0006Ef-IR; Tue, 24 Sep 2013 10:49:22 +0200 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-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Tue, 24 Sep 2013 08:49:22 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/339 Message-ID: <060.e83f7eaa357018c90e2c0dc7bd21f565@trac.tools.ietf.org> X-Trac-Ticket-ID: 339 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@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 grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20130924084934.56CC221F94FA@ietfa.amsl.com> Resent-Date: Tue, 24 Sep 2013 01:49:33 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #339: Rephrase incorrect "group URI used in a CoAP request" X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 08:49:35 -0000 #339: Rephrase incorrect "group URI used in a CoAP request" Section 3.2 states "To initiate CoAP group communication, a Group URI is used as the request URI in a CoAP request." This is incorrect, as the request URI is not included in a CoAP request. Proposal to rephrase; as an advice to CoAP implementers - for CoAP implementations that accept a CoAP URI as input in the API that is used to generate requests, we recommend to use the section 6.4 (CoAP-18) parsing method, in such way that for CoAP group URIs a CoAP multicast request is generated. This would allow users of a CoAP implementation to provide a CoAP group URI as input and know that a multicast request would be created. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: protocol | Status: new defect | Milestone: Priority: major | Version: Component: groupcomm | Keywords: Severity: - | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Tue Sep 24 01:55:42 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03AD921F8E1F for ; Tue, 24 Sep 2013 01:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxqkH53Zz7GF for ; Tue, 24 Sep 2013 01:55:41 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 6580E21F8443 for ; Tue, 24 Sep 2013 01:55:41 -0700 (PDT) Received: from localhost ([127.0.0.1]:48075 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VOOPC-0000Jo-Ku; Tue, 24 Sep 2013 10:55:38 +0200 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-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Tue, 24 Sep 2013 08:55:38 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/340 Message-ID: <060.5301f132aaff468a538510e7c46d69b0@trac.tools.ietf.org> X-Trac-Ticket-ID: 340 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@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 grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20130924085541.6580E21F8443@ietfa.amsl.com> Resent-Date: Tue, 24 Sep 2013 01:55:41 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #340: Support for configuration of port in group membership configuration X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 08:55:42 -0000 #340: Support for configuration of port in group membership configuration Currently (groupcomm-14), setting a port number is not supported in the mechanism defined in section 2.6. Also it is not stated that the server has to listen on the default CoAP port 5683. Proposal: add support for port number configuration in section 2.6.2. There are two ways to do this: 1) add an extra OPTIONAL "p" key/value pair with the port number. If absent, default CoAP port is assumed. 2) adopt the notation of RFC 5952 (recommended IPv6 Address Text Representation), e.g. [ff15::42:f7fe:ed37:ca]:8081 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: protocol | Status: new enhancement | Milestone: Priority: minor | Version: Component: groupcomm | Keywords: Severity: - | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Tue Sep 24 03:14:37 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B009421F9DC7 for ; Tue, 24 Sep 2013 03:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMHEYy9J98sq for ; Tue, 24 Sep 2013 03:14:37 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id DE81D11E80D5 for ; Tue, 24 Sep 2013 03:14:36 -0700 (PDT) Received: from localhost ([127.0.0.1]:52814 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VOPdR-0000kq-2v; Tue, 24 Sep 2013 12:14:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 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-observe@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Tue, 24 Sep 2013 10:14:25 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/core/trac/ticket/341 Message-ID: <051.c5b3d824bbd2bd475ffc6e62c86da194@trac.tools.ietf.org> X-Trac-Ticket-ID: 341 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-observe@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: hartke@tzi.org Resent-Message-Id: <20130924101436.DE81D11E80D5@ietfa.amsl.com> Resent-Date: Tue, 24 Sep 2013 03:14:36 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #341: Observe sequence number specification not robust against imprecise clocks X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 10:14:37 -0000 #341: Observe sequence number specification not robust against imprecise clocks The specification of sequence number arithmetic in observe-10 appears to assume that the clocks of clients and servers are perfectly in sync. However, constrained nodes often have rather imprecise clocks. (In particular, they may want to fall back to RC clocks during low-power idle times. These are often accurate only to ± 5 %, if that.) Inaccuracies of the client and server side may cancel out or add in effect. It is not hard to add robustness to the existing scheme, by reducing the maximum notification rate. Section 4.4 notes that the current scheme can support a notification rate of up to 64 KiHz. Reducing this to 32 KiHz is still well beyond the highest known design objective of around 1 kHz (most CoAP applications will be several orders of magnitude below that), but allows total clock inaccuracies of up to -50/+100 %. New language should point out that client and server clocks may differ in their realization of the SI second, and that staying at a sequence number increase rate of less than 32 KiHz (enabling the same notification rate if there is a strict relationship between sequence number increases and notificatione) should still be safe in most real-world cases. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | observe@tools.ietf.org Type: other | Status: new technical | Milestone: post-WGLC-1 Priority: major | Version: observe-10 Component: observe | Keywords: Severity: Active WG | Document | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Tue Sep 24 03:36:56 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA0D21F9635 for ; Tue, 24 Sep 2013 03:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQFI9zp8R0KF for ; Tue, 24 Sep 2013 03:36:56 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id EE56011E80DE for ; Tue, 24 Sep 2013 03:36:55 -0700 (PDT) Received: from localhost ([127.0.0.1]:54076 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VOPz5-0000Ch-Dv; Tue, 24 Sep 2013 12:36:47 +0200 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-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Tue, 24 Sep 2013 10:36:47 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/342 Message-ID: <060.cc050320858f531c711a89d46c5b0c92@trac.tools.ietf.org> X-Trac-Ticket-ID: 342 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@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 grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20130924103655.EE56011E80DE@ietfa.amsl.com> Resent-Date: Tue, 24 Sep 2013 03:36:55 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #342: Specify notation of IPv6 address in group membership configuration interface X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 10:36:56 -0000 #342: Specify notation of IPv6 address in group membership configuration interface Currently (groupcomm-14), the format for the IPv6 address in the "a" values in section 2.6.2 is not clearly defined. This may lead to differences in implementation and mutual incompatibility. Proposal: define the string format for the "a" value exactly. One solution is to adopt the notation of RFC 5952 (recommended IPv6 Address Text Representation), e.g. [ff15::42:f7fe:ed37:ca]:8081 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: protocol | Status: new defect | Milestone: Priority: major | Version: Component: groupcomm | Keywords: Severity: - | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Tue Sep 24 03:42:48 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CDE711E8114 for ; Tue, 24 Sep 2013 03:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPUJ+iG3b1iG for ; Tue, 24 Sep 2013 03:42:47 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD1711E810B for ; Tue, 24 Sep 2013 03:42:47 -0700 (PDT) Received: from localhost ([127.0.0.1]:54465 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VOQ4q-0002wU-7O; Tue, 24 Sep 2013 12:42:44 +0200 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-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Tue, 24 Sep 2013 10:42:44 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/343 Message-ID: <060.1913f024a7b2eb29a80a65f21516c1a9@trac.tools.ietf.org> X-Trac-Ticket-ID: 343 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@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 grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20130924104247.7FD1711E810B@ietfa.amsl.com> Resent-Date: Tue, 24 Sep 2013 03:42:47 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #343: Filtering discussion 6LBR in sect. 4.3 assumes wrong forwarding model X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 10:42:48 -0000 #343: Filtering discussion 6LBR in sect. 4.3 assumes wrong forwarding model Section 4.3 (of groupcomm-13) discusses filtering in 6LoWPAN Border Routers. The current text gives the impression that the 6LBR acts like an L2 switch by default, forwarding all multicast traffic onto the 6LoWPAN subnet. This is not the case, it should rather forward multicast traffic that recipients on the 6LoWPAN subnet have interest in (want to listen to). Proposal: clarify and rewrite using the assumption that by default multicast traffic is not routed onto the 6LoWPAN subnet. Explain those cases in which this leads to problems (e.g. if MLD is not implemented on 6LoWPAN nodes, no multicast traffic will ever be forwarded onto the 6LoWPAN subnet.) -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: editorial | Status: new Priority: major | Milestone: Component: groupcomm | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Tue Sep 24 03:49:08 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1133621F9D33 for ; Tue, 24 Sep 2013 03:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbgwnCffZauD for ; Tue, 24 Sep 2013 03:49:07 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE7621F9CF3 for ; Tue, 24 Sep 2013 03:49:04 -0700 (PDT) Received: from localhost ([127.0.0.1]:55023 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VOQAw-0007ch-DH; Tue, 24 Sep 2013 12:49:02 +0200 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-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Tue, 24 Sep 2013 10:49:01 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/344 Message-ID: <060.358e889f8937b2022b7c895bdc543757@trac.tools.ietf.org> X-Trac-Ticket-ID: 344 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@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 grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20130924104905.1BE7621F9CF3@ietfa.amsl.com> Resent-Date: Tue, 24 Sep 2013 03:49:04 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #344: coap-group+json Media Type encoding can be simplified to UTF-8 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 10:49:08 -0000 #344: coap-group+json Media Type encoding can be simplified to UTF-8 Section 6.2 (groupcomm-14) describes the support for UTF-8, UTF-16 and UTF-32 support. However, for resource constrained implementations it is expected that only UTF-8 would be used. Thus supporting multiple encodings introduces needless complexity or potential interoperability issues. Proposal: only support UTF-8, 8bit compatible [RFC6839] JSON encoding. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: protocol | Status: new enhancement | Milestone: Priority: major | Version: Component: groupcomm | Keywords: Severity: - | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Tue Sep 24 03:52:39 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC63911E8104 for ; Tue, 24 Sep 2013 03:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POYNqsFmLNg3 for ; Tue, 24 Sep 2013 03:52:27 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 15AAE21F9323 for ; Tue, 24 Sep 2013 03:52:27 -0700 (PDT) Received: from localhost ([127.0.0.1]:55244 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VOQEB-0003Qj-Sr; Tue, 24 Sep 2013 12:52:23 +0200 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-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Tue, 24 Sep 2013 10:52:23 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/343#comment:1 Message-ID: <075.9dfeb26820a897fef782bb0ccb1f7188@trac.tools.ietf.org> References: <060.1913f024a7b2eb29a80a65f21516c1a9@trac.tools.ietf.org> X-Trac-Ticket-ID: 343 In-Reply-To: <060.1913f024a7b2eb29a80a65f21516c1a9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@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 grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20130924105227.15AAE21F9323@ietfa.amsl.com> Resent-Date: Tue, 24 Sep 2013 03:52:27 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #343: Filtering discussion 6LBR in sect. 4.3 assumes wrong forwarding model X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 10:52:39 -0000 #343: Filtering discussion 6LBR in sect. 4.3 assumes wrong forwarding model Changes (by esko.dijk@philips.com): * status: new => closed * resolution: => fixed Comment: Closed by the editorial rewrite of Section 4 in groupcomm-14. http://tools.ietf.org/html/draft-ietf-core-groupcomm-14#section-4 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: editorial | Status: closed Priority: major | Milestone: Component: groupcomm | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Tue Sep 24 07:50:06 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 694EF11E80F3 for ; Tue, 24 Sep 2013 07:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTwLH-GdB84t for ; Tue, 24 Sep 2013 07:50:06 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 663C321F9C52 for ; Tue, 24 Sep 2013 07:49:59 -0700 (PDT) Received: from localhost ([127.0.0.1]:40857 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VOTw2-0000sn-Sd; Tue, 24 Sep 2013 16:49:54 +0200 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-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Tue, 24 Sep 2013 14:49:54 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/337#comment:1 Message-ID: <075.209b8a5cd3e6fb4655414afc66cdea44@trac.tools.ietf.org> References: <060.8762ad3a0453b584751467d309547d07@trac.tools.ietf.org> X-Trac-Ticket-ID: 337 In-Reply-To: <060.8762ad3a0453b584751467d309547d07@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@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 grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20130924145005.663C321F9C52@ietfa.amsl.com> Resent-Date: Tue, 24 Sep 2013 07:49:59 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #337: Rename "ip" key to "a" in sec. 2.6 (Configuring Group Membership in Endpoints) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 14:50:06 -0000 #337: Rename "ip" key to "a" in sec. 2.6 (Configuring Group Membership in Endpoints) Changes (by esko.dijk@philips.com): * status: new => closed * resolution: => fixed Comment: Done in groupcomm-14, section 2.6.2 http://tools.ietf.org/html/draft-ietf-core-groupcomm-14#section-2.6.2 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: protocol | Status: closed enhancement | Milestone: Priority: minor | Version: Component: groupcomm | Resolution: fixed Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From Akbar.Rahman@InterDigital.com Tue Sep 24 07:59:44 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0DA11E8145 for ; Tue, 24 Sep 2013 07:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0eUz3xspBRK9 for ; Tue, 24 Sep 2013 07:59:39 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id F3CB511E813F for ; Tue, 24 Sep 2013 07:59:38 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Sep 2013 10:59:33 -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: Tue, 24 Sep 2013 10:59:32 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] I-D Action: draft-ietf-core-groupcomm-14.txt Thread-Index: Ac64deOB+q2JMsFXRLaCOubo0onPAgAAANlAAC/8w/A= References: <20130923155743.32168.81225.idtracker@ietfa.amsl.com> From: "Rahman, Akbar" To: X-OriginalArrivalTime: 24 Sep 2013 14:59:33.0533 (UTC) FILETIME=[ADC90CD0:01CEB936] Subject: Re: [core] I-D Action: draft-ietf-core-groupcomm-14.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 14:59:44 -0000 Hi All, Esko has just generated the tickets that arose out of the technical comments from Carsten's review. These are: * #344: coap-group+json Media Type encoding can be simplified to UTF-8 * #342: Specify notation of IPv6 address in group membership configuration interface * #340: Support for configuration of port in group membership configuration * #339: Rephrase incorrect "group URI used in a CoAP request" * #338: Do not include the "ip" key/value when its value is unknown Please write back if you have any feedback to the proposed solutions that were included in the ticket description. We are aiming to close the tickets by this Friday (Sept. 27) and generate groupcomm-15 after that. Thanks, Akbar and Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Rahman, Akbar Sent: Monday, September 23, 2013 12:03 PM To: core@ietf.org Subject: Re: [core] I-D Action: draft-ietf-core-groupcomm-14.txt Hi, We have updated the Groupcomm I-D to address the final 2 editorial comments from Carsten, and also have tackled one of his technical comments. In summary: Changes from ietf-13 to ietf-14: o Update to address final editorial comments from the Chair's review (by Carsten Bormann) of the draft. This included restructuring of Section 2.6 (Configuring Group Memberships) and Section 4 (Deployment Guidelines) to make it easier to read. Also various other editorial changes. o Changed "ip" field to "a" in Section 2.6 (#337) We plan to address the remaining 5 technical comments from Carsten (via Tickets) in the coming days. All comment are welcome. Best Regards, Akbar & Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Monday, September 23, 2013 11:58 AM To: i-d-announce@ietf.org Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-groupcomm-14.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 Author(s) : Akbar Rahman Esko Dijk Filename : draft-ietf-core-groupcomm-14.txt Pages : 39 Date : 2013-09-23 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-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-groupcomm-14 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 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From fluffy@iii.ca Thu Sep 26 07:17:26 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACDFC11E80E7 for ; Thu, 26 Sep 2013 07:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hu6S9w2blmrR for ; Thu, 26 Sep 2013 07:17:20 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 87E3211E8101 for ; Thu, 26 Sep 2013 07:17:02 -0700 (PDT) Received: from [10.21.75.133] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0E3BE22E253 for ; Thu, 26 Sep 2013 10:16:55 -0400 (EDT) From: Cullen Jennings Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <2A4D2B85-0D0C-4EAC-A9F1-77DFF21E9B2F@iii.ca> Date: Thu, 26 Sep 2013 07:17:18 -0700 To: core WG Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [core] Test 1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 14:17:26 -0000 No need to reply - Just seeing if this mail lists works. Sorry for the = noise=85. From pab@pabigot.com Thu Sep 26 07:50:12 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11CCE21F9EB5 for ; Thu, 26 Sep 2013 07:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqF8ojnpN78c for ; Thu, 26 Sep 2013 07:49:55 -0700 (PDT) Received: from p3plsmtpa08-08.prod.phx3.secureserver.net (p3plsmtpa08-08.prod.phx3.secureserver.net [173.201.193.109]) by ietfa.amsl.com (Postfix) with ESMTP id 85BEE21F9FED for ; Thu, 26 Sep 2013 07:49:52 -0700 (PDT) Received: from [192.168.65.10] ([66.41.60.82]) by p3plsmtpa08-08.prod.phx3.secureserver.net with id Vqpq1m00Y1mTNtu01qprri; Thu, 26 Sep 2013 07:49:52 -0700 Message-ID: <5244498E.3050202@pabigot.com> Date: Thu, 26 Sep 2013 09:49:50 -0500 From: "Peter A. Bigot" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: core Content-Type: multipart/alternative; boundary="------------020500070704070602040106" Subject: [core] Comments on draft-ietf-core-observe-10 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 14:50:12 -0000 This is a multi-part message in MIME format. --------------020500070704070602040106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I've got some spare time and happened across an opportunity to play with some CoAP implementations. To support that I've been trying to catch up on what's happened in CoRE since I was last here in 2011. First issue: In section 4.5 of draft-ietf-core-observe-10 there is the text: The server MUST limit the number of confirmable notifications for which an acknowledgement has not been received yet to NSTART (1 by default; see Section 4.7 of RFC XXXX [I-D.ietf-core-coap]). As I read Section 4.7 of draft-ietf-core-18 it is a MUST that a Client (in this case "the server") limit exactly this type of message to NSTART instances for each end-point (observer). What additional constraint is this sentence intended to provide? Naively it might extend the limit to apply across all observers, but that would be counter-productive to the purpose of distributing observations. It might relax the limit to refer to each single observable (rather than across all to which a given observer has subscribed), but I don't think draft-ietf-core-observe should be permitted to relax the underlying CoAP constraint that way. Second issue: In section 4.4 of draft-ietf-core-observe-10 there is the text: The sequence number selected for a notification MUST be greater than that of any preceding notification sent to the same client with the same token for the same resource. The value of the Observe Option MUST be current at the time of transmission; if a notification is retransmitted, the server MUST update the value of the option to the sequence number that is current at that time before sending the message. The sequence numbers generated for a resource MUST provide an order among all notifications resulting from all requests from the same client endpoint. This was revelatory, since it mandates that the transmission layer be able to validate and potentially update the (option) content of a message before (re-)transmitting it. (A similar issue for Max-Age is consequent to Section 5.10.5 of draft-ietf-core-18, though it is a SHOULD there, and the requirement could be met without interacting with an upper layer.) Since the value corresponding to the updated sequence number probably also changed, this implies the entire content of the un(re-)transmitted message would need to be replaced too. Is this intentional? Does it implicitly sanction the same sort of update for arbitrary messages in base CoAP? I had thought this was agreed to be undesirable by the working group back in 2010 and the expectation was retransmissions at the CoAP layer could never change the message content, though I can't locate the reference. The consequences if NSTART is greater than one are unclear but worrisome to me. Wouldn't it be simpler to solve this by modifying the text in Section 4.5 to cancel any unacknowledged Con or untransmitted Non-Con notification if the underlying resource changed? Or, if that's too disruptive in situations of rapid change, doing so when a new notification for the same resource to the same endpoint is generated? That may be what the steps in Section 4.5 are intended to require, though I don't understand step one: 1. Wait for the current transmission attempt to complete. I don't know if "current transmission attempt" is just an active radio transmission that takes a few milliseconds, or a step of the backoff/retransmit/wait algorithm which might take a minute or more. The referenced to "completed transmission attempt timed out" in step 4 suggests this step may take a relatively long time. I think if there's any waiting going on the cancellation should occur immediately. Regardless I think all this should be done relative to one notification, not NSTART, again because things get messy if NSTART is greater than one: there would legitimately be multiple active notifications to the same observer for the same resource with either conflicting or duplicate content. Hope I'm not too confused about all this having been gone for so long. Peter --------------020500070704070602040106 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
I've got some spare time and happened across an opportunity to play with some CoAP implementations.  To support that I've been trying to catch up on what's happened in CoRE since I was last here in 2011.

First issue:

In section 4.5 of draft-ietf-core-observe-10 there is the text:

   The server MUST limit the number of confirmable notifications for
   which an acknowledgement has not been received yet to NSTART (1 by
   default; see Section 4.7 of RFC XXXX [I-D.ietf-core-coap]).

As I read Section 4.7 of draft-ietf-core-18 it is a MUST that a Client (in this case "the server") limit exactly this type of message to NSTART instances for each end-point (observer).

What additional constraint is this sentence intended to provide?

Naively it might extend the limit to apply across all observers, but that would be counter-productive to the purpose of distributing observations.  It might relax the limit to refer to each single observable (rather than across all to which a given observer has subscribed), but I don't think draft-ietf-core-observe should be permitted to relax the underlying CoAP constraint that way.

Second issue:

In section 4.4 of draft-ietf-core-observe-10 there is the text:

   The sequence number selected for a notification MUST be greater than
   that of any preceding notification sent to the same client with the
   same token for the same resource.  The value of the Observe Option
   MUST be current at the time of transmission; if a notification is
   retransmitted, the server MUST update the value of the option to the
   sequence number that is current at that time before sending the
   message.

   The sequence numbers generated for a resource MUST provide an order
   among all notifications resulting from all requests from the same
   client endpoint.

This was revelatory, since it mandates that the transmission layer be able to validate and potentially update the (option) content of a message before (re-)transmitting it.  (A similar issue for Max-Age is consequent to Section 5.10.5 of draft-ietf-core-18, though it is a SHOULD there, and the requirement could be met without interacting with an upper layer.)  Since the value corresponding to the updated sequence number probably also changed, this implies the entire content of the un(re-)transmitted message would need to be replaced too.  Is this intentional?  Does it implicitly sanction the same sort of update for arbitrary messages in base CoAP?  I had thought this was agreed to be undesirable by the working group back in 2010 and the expectation was retransmissions at the CoAP layer could never change the message content, though I can't locate the reference.

The consequences if NSTART is greater than one are unclear but worrisome to me.

Wouldn't it be simpler to solve this by modifying the text in Section 4.5 to cancel any unacknowledged Con or untransmitted Non-Con notification if the underlying resource changed?  Or, if that's too disruptive in situations of rapid change, doing so when a new notification for the same resource to the same endpoint is generated?

That may be what the steps in Section 4.5 are intended to require, though I don't understand step one:

   1.  Wait for the current transmission attempt to complete.

I don't know if "current transmission attempt" is just an active radio transmission that takes a few milliseconds, or a step of the backoff/retransmit/wait algorithm which might take a minute or more.  The referenced to "completed transmission attempt timed out" in step 4 suggests this step may take a relatively long time.  I think if there's any waiting going on the cancellation should occur immediately.

Regardless I think all this should be done relative to one notification, not NSTART, again because things get messy if NSTART is greater than one: there would legitimately be multiple active notifications to the same observer for the same resource with either conflicting or duplicate content.

Hope I'm not too confused about all this having been gone for so long.

Peter

--------------020500070704070602040106-- From trac+core@trac.tools.ietf.org Thu Sep 26 12:23:28 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAB6C21E8084 for ; Thu, 26 Sep 2013 12:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.292 X-Spam-Level: X-Spam-Status: No, score=-102.292 tagged_above=-999 required=5 tests=[AWL=-0.293, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhfj2l+1rR29 for ; Thu, 26 Sep 2013 12:23:25 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4C111E80F3 for ; Thu, 26 Sep 2013 12:23:19 -0700 (PDT) Received: from localhost ([127.0.0.1]:40286 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VPH9d-0000mD-SV; Thu, 26 Sep 2013 21:23:13 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 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-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Thu, 26 Sep 2013 19:23:13 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/342#comment:1 Message-ID: <075.fdeeb3d0c8259371891b58c65d9aa80c@trac.tools.ietf.org> References: <060.cc050320858f531c711a89d46c5b0c92@trac.tools.ietf.org> X-Trac-Ticket-ID: 342 In-Reply-To: <060.cc050320858f531c711a89d46c5b0c92@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@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 grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20130926192320.4C4C111E80F3@ietfa.amsl.com> Resent-Date: Thu, 26 Sep 2013 12:23:19 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #342: Specify notation of IPv6 address in group membership configuration interface X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 19:23:28 -0000 #342: Specify notation of IPv6 address in group membership configuration interface Comment (by esko.dijk@philips.com): In line with the rest of the I-D, IPv4 should also be supported besides IPv6. Proposal is to add text like the following: “... contains an IPv6 address or an IPv4 address in dotted decimal notation. The following ABNF rule can be used for parsing the address, referring to the definitions in Section 6 of [core-coap] and [RFC3986]: group-address = IPv4address [ “:†port ] / IPv6address / “[“ IPv6address “]†[“:†port ] “ Then there's also no need to mention RFC 5952 about textual representation of IPv6. Also this would solve ticket #340 due to inclusion of port number. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: protocol | Status: new defect | Milestone: Priority: major | Version: Component: groupcomm | Resolution: Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From hartke@tzi.org Thu Sep 26 18:40:53 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4074821E80D8 for ; Thu, 26 Sep 2013 18:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5PGDDEhKxAmB for ; Thu, 26 Sep 2013 18:40:48 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 895C121E80D4 for ; Thu, 26 Sep 2013 18:40: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.4/8.14.4) with ESMTP id r8R1eS2l007538 for ; Fri, 27 Sep 2013 03:40:28 +0200 (CEST) Received: from mail-vb0-f45.google.com (mail-vb0-f45.google.com [209.85.212.45]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 96102C1F for ; Fri, 27 Sep 2013 03:40:28 +0200 (CEST) Received: by mail-vb0-f45.google.com with SMTP id e15so1401019vbg.4 for ; Thu, 26 Sep 2013 18:40:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=MezWUk5UJngL7PijvRa1WUIokqOh5kt6AB1IafRTN5s=; b=XsFvehJy5pBmDmZciPLEdz0ruS3M3x8LUTh+NsdYiza7aBVyPHCR+EyiCcFGJ+CkOd 7FrwtYqF+B3c1rqxwFxjppvhoB6J7AA6i4rOjcwCFC/oLPQtsx+F1WL6p7McNqb/MoBJ rVQueFk6hRSFp+h5AF8fP8vTdtXYTBlvbdmkjfcMW73Cawlx9/GekMOGcMKa12gH+j+n XYpzBQ4ht0oxMOJI7hzHcql26tVZEjEqXA3JGjQuWqJX3Exx58I3mpknkYl+I1yyYdjg kk/ranqkvjKxfJLGuA4bbOok2O8LqQ43Di0bhWiFRAvzdNpQoPfW8OitmybQ2mrepHLL rR6A== X-Received: by 10.58.100.144 with SMTP id ey16mr3604417veb.25.1380246027105; Thu, 26 Sep 2013 18:40:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.24.83 with HTTP; Thu, 26 Sep 2013 18:39:47 -0700 (PDT) In-Reply-To: <5244498E.3050202@pabigot.com> References: <5244498E.3050202@pabigot.com> From: Klaus Hartke Date: Fri, 27 Sep 2013 04:39:47 +0300 Message-ID: To: "Peter A. Bigot" Content-Type: text/plain; charset=ISO-8859-1 Cc: core Subject: Re: [core] Comments on draft-ietf-core-observe-10 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 01:40:53 -0000 Hi Peter, welcome back and thanks for the feedback! > In section 4.5 of draft-ietf-core-observe-10 there is the text: > > The server MUST limit the number of confirmable notifications for > which an acknowledgement has not been received yet to NSTART (1 by > default; see Section 4.7 of RFC XXXX [I-D.ietf-core-coap]). > > As I read Section 4.7 of draft-ietf-core-18 it is a MUST that a Client (in > this case "the server") limit exactly this type of message to NSTART > instances for each end-point (observer). > > What additional constraint is this sentence intended to provide? Section 4.7 of -coap-18 limits the client (the initiator of requests) to NSTART, but actually states no requirements for the CoAP server (the responder). This is iirc because in the normal request/response case, the server only ever transmits something in reaction to the client. In the observe case, though, the server does not only react to the client but transmits notifications over a long period of time on its own initiative. So this sentence is intended to put the same requirements on the server for notifications as -coap-18 puts on the client for requests. > Naively it might extend the limit to apply across all observers, but that > would be counter-productive to the purpose of distributing observations. It > might relax the limit to refer to each single observable (rather than across > all to which a given observer has subscribed), but I don't think > draft-ietf-core-observe should be permitted to relax the underlying CoAP > constraint that way. The whole text is written in the scope of one client observing one resource. But, of course, when a client observes two or more resources on the same server, the server must perform congestion control over the aggregate traffic. > Second issue: > > In section 4.4 of draft-ietf-core-observe-10 there is the text: > > The sequence number selected for a notification MUST be greater than > that of any preceding notification sent to the same client with the > same token for the same resource. The value of the Observe Option > MUST be current at the time of transmission; if a notification is > retransmitted, the server MUST update the value of the option to the > sequence number that is current at that time before sending the > message. > > The sequence numbers generated for a resource MUST provide an order > among all notifications resulting from all requests from the same > client endpoint. > > This was revelatory, since it mandates that the transmission layer be able > to validate and potentially update the (option) content of a message before > (re-)transmitting it. (A similar issue for Max-Age is consequent to Section > 5.10.5 of draft-ietf-core-18, though it is a SHOULD there, and the > requirement could be met without interacting with an upper layer.) The difference between Max-Age and the sequence number is that it's only slightly less correct if Max-Age isn't updated on retransmission, but things actually break if the sequence number isn't updated. There are multiple possible implementations that fit the requirements. If you use an implementation where the sequence number doesn't change between retransmissions of the same notification, then you don't need your transmission layer to update the option content. > Since > the value corresponding to the updated sequence number probably also > changed, this implies the entire content of the un(re-)transmitted message > would need to be replaced too. Is this intentional? Does it implicitly > sanction the same sort of update for arbitrary messages in base CoAP? I had > thought this was agreed to be undesirable by the working group back in 2010 > and the expectation was retransmissions at the CoAP layer could never change > the message content, though I can't locate the reference. Section 4.4 of -observe-10 only says the the sequence number must be up-to-date. When the value changes (i.e., the representation of the current resource state), then that's a new transmission, as described at the of Section 4.5. > The consequences if NSTART is greater than one are unclear but worrisome to > me. > > Wouldn't it be simpler to solve this by modifying the text in Section 4.5 to > cancel any unacknowledged Con or untransmitted Non-Con notification if the > underlying resource changed? Or, if that's too disruptive in situations of > rapid change, doing so when a new notification for the same resource to the > same endpoint is generated? > > That may be what the steps in Section 4.5 are intended to require, though I > don't understand step one: > > 1. Wait for the current transmission attempt to complete. > > I don't know if "current transmission attempt" is just an active radio > transmission that takes a few milliseconds, or a step of the > backoff/retransmit/wait algorithm which might take a minute or more. The > referenced to "completed transmission attempt timed out" in step 4 suggests > this step may take a relatively long time. I think if there's any waiting > going on the cancellation should occur immediately. I've clarified the text in SVN as follows: When the state of an observed resource changes while the number of outstanding acknowledgements is greater than or equal to NSTART, or while the waiting time for a non-confirmable notification has not elapsed yet, the server MUST proceed as follows: 1. Wait for the current transmission attempt to be acknowledged, rejected or to time out (confirmable transmission), or the waiting time to elapse (non-confirmable transmission). It is necessary to wait for the transmission attempt to complete first. Because otherwise, if the transmission is canceled and a new transmission is started immediately, there are two problems when notifications are generated more quickly than can be consumed (for example, at a proxy located at the boundary between a fast network and a constrained network): * the client and/or network could be overloaded; and * transmissions would never time out and therefore a dead client would never be removed from the list of observers. > Regardless I think all this should be done relative to one notification, not > NSTART, again because things get messy if NSTART is greater than one: there > would legitimately be multiple active notifications to the same observer for > the same resource with either conflicting or duplicate content. One of the goals of -observe is that Clients should see the new state after a state change as soon as possible, and they should see as many states as possible. (draft-ietf-core-observe-10#section-1.4) So if it's possible to let a client see more intermediate state changes by having more than one active notification at the same time, that would help that goal. The notifications aren't conflicting -- they provide more detail; each notification has a sequence number that lets the client put the messages back into order. How and if NSTART may be allowed a value greater than one is an open question at this time: Further congestion control optimizations and considerations are expected in the future, which may for example provide automatic initialization of the CoAP transmission parameters defined in Section 4.8, and thus may allow a value for NSTART greater than one. (draft-ietf-core-coap-18#section-4.7) Best regards, Klaus PS: You can see the full changes I've made in SVN based on your comments here: From trac+core@trac.tools.ietf.org Thu Sep 26 19:35:38 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A76321F923D for ; Thu, 26 Sep 2013 19:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmEVKyIG5nOL for ; Thu, 26 Sep 2013 19:35:37 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id B0B1711E80A2 for ; Thu, 26 Sep 2013 19:35:37 -0700 (PDT) Received: from localhost ([127.0.0.1]:39648 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VPNu2-0001Rs-Hw; Fri, 27 Sep 2013 04:35:34 +0200 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-observe@tools.ietf.org, hartke@tzi.org X-Trac-Project: core Date: Fri, 27 Sep 2013 02:35:34 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/341#comment:1 Message-ID: <066.4fc61e05260c237f5263d1e9e739c1bb@trac.tools.ietf.org> References: <051.c5b3d824bbd2bd475ffc6e62c86da194@trac.tools.ietf.org> X-Trac-Ticket-ID: 341 In-Reply-To: <051.c5b3d824bbd2bd475ffc6e62c86da194@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-observe@tools.ietf.org, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: hartke@tzi.org Resent-Message-Id: <20130927023537.B0B1711E80A2@ietfa.amsl.com> Resent-Date: Thu, 26 Sep 2013 19:35:37 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #341: Observe sequence number specification not robust against imprecise clocks X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 02:35:38 -0000 #341: Observe sequence number specification not robust against imprecise clocks Changes (by hartke@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1503]: Close #341 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | observe@tools.ietf.org Type: other | Status: closed technical | Milestone: post-WGLC-1 Priority: major | Version: observe-10 Component: observe | Resolution: fixed Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From pab@pabigot.com Thu Sep 26 21:54:53 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 221D821F9A65 for ; Thu, 26 Sep 2013 21:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pY+NYPt4VQdw for ; Thu, 26 Sep 2013 21:54:48 -0700 (PDT) Received: from p3plsmtpa09-08.prod.phx3.secureserver.net (p3plsmtpa09-08.prod.phx3.secureserver.net [173.201.193.237]) by ietfa.amsl.com (Postfix) with ESMTP id 9F43911E80E6 for ; Thu, 26 Sep 2013 21:54:44 -0700 (PDT) Received: from [192.168.65.10] ([66.41.60.82]) by p3plsmtpa09-08.prod.phx3.secureserver.net with id W4ug1m0011mTNtu014ug4C; Thu, 26 Sep 2013 21:54:43 -0700 Message-ID: <52450F90.8020202@pabigot.com> Date: Thu, 26 Sep 2013 23:54:40 -0500 From: "Peter A. Bigot" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: Klaus Hartke References: <5244498E.3050202@pabigot.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010401050103000406040802" Cc: core Subject: Re: [core] Comments on draft-ietf-core-observe-10 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 04:54:53 -0000 This is a multi-part message in MIME format. --------------010401050103000406040802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 09/26/2013 08:39 PM, Klaus Hartke wrote: > Hi Peter, > > welcome back and thanks for the feedback! > >> In section 4.5 of draft-ietf-core-observe-10 there is the text: >> >> The server MUST limit the number of confirmable notifications for >> which an acknowledgement has not been received yet to NSTART (1 by >> default; see Section 4.7 of RFC XXXX [I-D.ietf-core-coap]). >> >> As I read Section 4.7 of draft-ietf-core-18 it is a MUST that a Client (in >> this case "the server") limit exactly this type of message to NSTART >> instances for each end-point (observer). >> >> What additional constraint is this sentence intended to provide? > Section 4.7 of -coap-18 limits the client (the initiator of requests) > to NSTART, but actually states no requirements for the CoAP server > (the responder). OK, I can see that now. Aside: If there's another edit opportunity before draft-ietf-core-coap becomes an RFC, the first line of the second paragraph of 4.7: In order not to cause congestion, Clients (including proxies) MUST should not capitalize Clients. No similar use within a sentence is capitalized. > This is iirc because in the normal request/response > case, the server only ever transmits something in reaction to the > client. In the observe case, though, the server does not only react to > the client but transmits notifications over a long period of time on > its own initiative. So this sentence is intended to put the same > requirements on the server for notifications as -coap-18 puts on the > client for requests. > >> Naively it might extend the limit to apply across all observers, but that >> would be counter-productive to the purpose of distributing observations. It >> might relax the limit to refer to each single observable (rather than across >> all to which a given observer has subscribed), but I don't think >> draft-ietf-core-observe should be permitted to relax the underlying CoAP >> constraint that way. > The whole text is written in the scope of one client observing one > resource. But, of course, when a client observes two or more resources > on the same server, the server must perform congestion control over > the aggregate traffic. There is no "of course" if the specification isn't clear. I can still read the text as disallowing more than NSTART notifications over all clients and/or resources, or I could read it as allowing more than NSTART notifications to a single client observing multiple resources. I believe the intent is to allow the first, and disallow the second. The wording should be clarified. > >> Second issue: >> >> In section 4.4 of draft-ietf-core-observe-10 there is the text: >> >> The sequence number selected for a notification MUST be greater than >> that of any preceding notification sent to the same client with the >> same token for the same resource. The value of the Observe Option >> MUST be current at the time of transmission; if a notification is >> retransmitted, the server MUST update the value of the option to the >> sequence number that is current at that time before sending the >> message. >> >> The sequence numbers generated for a resource MUST provide an order >> among all notifications resulting from all requests from the same >> client endpoint. >> >> This was revelatory, since it mandates that the transmission layer be able >> to validate and potentially update the (option) content of a message before >> (re-)transmitting it. (A similar issue for Max-Age is consequent to Section >> 5.10.5 of draft-ietf-core-18, though it is a SHOULD there, and the >> requirement could be met without interacting with an upper layer.) > The difference between Max-Age and the sequence number is that it's > only slightly less correct if Max-Age isn't updated on retransmission, > but things actually break if the sequence number isn't updated. > > There are multiple possible implementations that fit the requirements. > If you use an implementation where the sequence number doesn't change > between retransmissions of the same notification, then you don't need > your transmission layer to update the option content. I believe I see how you're thinking about the relationship between sequence numbers, resource updates, and notifications, but I can't respond until the issue below is clarified. > >> Since >> the value corresponding to the updated sequence number probably also >> changed, this implies the entire content of the un(re-)transmitted message >> would need to be replaced too. Is this intentional? Does it implicitly >> sanction the same sort of update for arbitrary messages in base CoAP? I had >> thought this was agreed to be undesirable by the working group back in 2010 >> and the expectation was retransmissions at the CoAP layer could never change >> the message content, though I can't locate the reference. > Section 4.4 of -observe-10 only says the the sequence number must be > up-to-date. When the value changes (i.e., the representation of the > current resource state), then that's a new transmission, as described > at the of Section 4.5. > >> The consequences if NSTART is greater than one are unclear but worrisome to >> me. >> >> Wouldn't it be simpler to solve this by modifying the text in Section 4.5 to >> cancel any unacknowledged Con or untransmitted Non-Con notification if the >> underlying resource changed? Or, if that's too disruptive in situations of >> rapid change, doing so when a new notification for the same resource to the >> same endpoint is generated? >> >> That may be what the steps in Section 4.5 are intended to require, though I >> don't understand step one: >> >> 1. Wait for the current transmission attempt to complete. >> >> I don't know if "current transmission attempt" is just an active radio >> transmission that takes a few milliseconds, or a step of the >> backoff/retransmit/wait algorithm which might take a minute or more. The >> referenced to "completed transmission attempt timed out" in step 4 suggests >> this step may take a relatively long time. I think if there's any waiting >> going on the cancellation should occur immediately. > I've clarified the text in SVN as follows: > > When the state of an observed resource changes while the number of > outstanding acknowledgements is greater than or equal to NSTART, or > while the waiting time for a non-confirmable notification has not > elapsed yet, the server MUST proceed as follows: > > 1. Wait for the current transmission attempt to be acknowledged, > rejected or to time out (confirmable transmission), or the > waiting time to elapse (non-confirmable transmission). I need to fix my understanding of what transmission and retransmission mean. For comparison, Section 5.10.5 (Max-Age) of draft-ietf-core-coap-18 has: The value is intended to be current at the time of transmission. Servers that provide resources with strict tolerances on the value of Max-Age SHOULD update the value before each retransmission. (See also Section 5.7.1.) Though this certainly applies to proxies, the wording suggests it also applies to origin servers. With the default transmission parameters, a CON message with maximum initial timeout will be transmitted at most five times at offsets of 0, 3, 6, 12, and 24 seconds, with a 48 second wait after the fourth retransmission, resulting in a MAX_TRANSMIT_WAIT of 93 seconds. If the CON message has a Max-Age option with value 30, does the above text mean that the server SHOULD update the value in the Max-Age option per the following table while waiting for the reliable transmission to be completed? OffsetTime Transmission# Transmitted Max-Age 0 1 30 3 2 27 9 3 21 21 4 9 45 5 0 In the context of Section 4.5 of observe-10: If this confirmable message were a notification (and did not have Max-Age), would a change in the value of the underlying resource at T=15 while this notification is outstanding force the server to execute the five step process? At what time would step 1 of that process complete: 15 seconds, 21 seconds, 93 seconds, or some other time? > It is necessary to wait for the transmission attempt to complete > first. Because otherwise, if the transmission is canceled and a new > transmission is started immediately, there are two problems when > notifications are generated more quickly than can be consumed (for > example, at a proxy located at the boundary between a fast network and > a constrained network): > > * the client and/or network could be overloaded; and > > * transmissions would never time out and therefore a dead client would > never be removed from the list of observers. > >> Regardless I think all this should be done relative to one notification, not >> NSTART, again because things get messy if NSTART is greater than one: there >> would legitimately be multiple active notifications to the same observer for >> the same resource with either conflicting or duplicate content. > One of the goals of -observe is that > > Clients should see the new state after a state change as soon > as possible, and they should see as many states as possible. > (draft-ietf-core-observe-10#section-1.4) > > So if it's possible to let a client see more intermediate state > changes by having more than one active notification at the same time, > that would help that goal. The notifications aren't conflicting -- > they provide more detail; each notification has a sequence number that > lets the client put the messages back into order. > > How and if NSTART may be allowed a value greater than one is an open > question at this time: > > Further congestion control optimizations and considerations are > expected in the future, which may for example provide automatic > initialization of the CoAP transmission parameters defined in > Section 4.8, and thus may allow a value for NSTART greater than one. > (draft-ietf-core-coap-18#section-4.7) Yes. We need to resolve what Section 4.5 really requires of an implementation for NSTART=1 before assessing what it requires when NSTART>1 . > Best regards, > Klaus > > PS: You can see the full changes I've made in SVN based on your > comments here: Thanks. Peter --------------010401050103000406040802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 09/26/2013 08:39 PM, Klaus Hartke wrote:
Hi Peter,

welcome back and thanks for the feedback!


In section 4.5 of draft-ietf-core-observe-10 there is the text:

   The server MUST limit the number of confirmable notifications for
   which an acknowledgement has not been received yet to NSTART (1 by
   default; see Section 4.7 of RFC XXXX [I-D.ietf-core-coap]).

As I read Section 4.7 of draft-ietf-core-18 it is a MUST that a Client (in
this case "the server") limit exactly this type of message to NSTART
instances for each end-point (observer).

What additional constraint is this sentence intended to provide?

Section 4.7 of -coap-18 limits the client (the initiator of requests)
to NSTART, but actually states no requirements for the CoAP server
(the responder).

OK, I can see that now.

Aside: If there's another edit opportunity before draft-ietf-core-coap becomes an RFC, the first line of the second paragraph of 4.7:

   In order not to cause congestion, Clients (including proxies) MUST

should not capitalize Clients.  No similar use within a sentence is capitalized.

 This is iirc because in the normal request/response
case, the server only ever transmits something in reaction to the
client. In the observe case, though, the server does not only react to
the client but transmits notifications over a long period of time on
its own initiative. So this sentence is intended to put the same
requirements on the server for notifications as -coap-18 puts on the
client for requests.


Naively it might extend the limit to apply across all observers, but that
would be counter-productive to the purpose of distributing observations. It
might relax the limit to refer to each single observable (rather than across
all to which a given observer has subscribed), but I don't think
draft-ietf-core-observe should be permitted to relax the underlying CoAP
constraint that way.

The whole text is written in the scope of one client observing one
resource. But, of course, when a client observes two or more resources
on the same server, the server must perform congestion control over
the aggregate traffic.

There is no "of course" if the specification isn't clear.  I can still read the text as disallowing more than NSTART notifications over all clients and/or resources, or I could read it as allowing more than NSTART notifications to a single client observing multiple resources.  I believe the intent is to allow the first, and disallow the second.  The wording should be clarified.


Second issue:

In section 4.4 of draft-ietf-core-observe-10 there is the text:

   The sequence number selected for a notification MUST be greater than
   that of any preceding notification sent to the same client with the
   same token for the same resource.  The value of the Observe Option
   MUST be current at the time of transmission; if a notification is
   retransmitted, the server MUST update the value of the option to the
   sequence number that is current at that time before sending the
   message.

   The sequence numbers generated for a resource MUST provide an order
   among all notifications resulting from all requests from the same
   client endpoint.

This was revelatory, since it mandates that the transmission layer be able
to validate and potentially update the (option) content of a message before
(re-)transmitting it.  (A similar issue for Max-Age is consequent to Section
5.10.5 of draft-ietf-core-18, though it is a SHOULD there, and the
requirement could be met without interacting with an upper layer.)

The difference between Max-Age and the sequence number is that it's
only slightly less correct if Max-Age isn't updated on retransmission,
but things actually break if the sequence number isn't updated.

There are multiple possible implementations that fit the requirements.
If you use an implementation where the sequence number doesn't change
between retransmissions of the same notification, then you don't need
your transmission layer to update the option content.

I believe I see how you're thinking about the relationship between sequence numbers, resource updates, and notifications, but I can't respond until the issue below is clarified.


Since
the value corresponding to the updated sequence number probably also
changed, this implies the entire content of the un(re-)transmitted message
would need to be replaced too.  Is this intentional?  Does it implicitly
sanction the same sort of update for arbitrary messages in base CoAP?  I had
thought this was agreed to be undesirable by the working group back in 2010
and the expectation was retransmissions at the CoAP layer could never change
the message content, though I can't locate the reference.

Section 4.4 of -observe-10 only says the the sequence number must be
up-to-date. When the value changes (i.e., the representation of the
current resource state), then that's a new transmission, as described
at the of Section 4.5.


The consequences if NSTART is greater than one are unclear but worrisome to
me.

Wouldn't it be simpler to solve this by modifying the text in Section 4.5 to
cancel any unacknowledged Con or untransmitted Non-Con notification if the
underlying resource changed?  Or, if that's too disruptive in situations of
rapid change, doing so when a new notification for the same resource to the
same endpoint is generated?

That may be what the steps in Section 4.5 are intended to require, though I
don't understand step one:

   1.  Wait for the current transmission attempt to complete.

I don't know if "current transmission attempt" is just an active radio
transmission that takes a few milliseconds, or a step of the
backoff/retransmit/wait algorithm which might take a minute or more.  The
referenced to "completed transmission attempt timed out" in step 4 suggests
this step may take a relatively long time.  I think if there's any waiting
going on the cancellation should occur immediately.

I've clarified the text in SVN as follows:

   When the state of an observed resource changes while the number of
   outstanding acknowledgements is greater than or equal to NSTART, or
   while the waiting time for a non-confirmable notification has not
   elapsed yet, the server MUST proceed as follows:

   1.  Wait for the current transmission attempt to be acknowledged,
       rejected or to time out (confirmable transmission), or the
       waiting time to elapse (non-confirmable transmission).

I need to fix my understanding of what transmission and retransmission mean.

For comparison, Section 5.10.5 (Max-Age) of draft-ietf-core-coap-18 has:

   The value is intended to be current at the time of transmission.
   Servers that provide resources with strict tolerances on the value of
   Max-Age SHOULD update the value before each retransmission.  (See
   also Section 5.7.1.)

Though this certainly applies to proxies, the wording suggests it also applies to origin servers.

With the default transmission parameters, a CON message with maximum initial timeout will be transmitted at most five times at offsets of 0, 3, 6, 12, and 24 seconds, with a 48 second wait after the fourth retransmission, resulting in a MAX_TRANSMIT_WAIT of 93 seconds.

If the CON message has a Max-Age option with value 30, does the above text mean that the server SHOULD update the value in the Max-Age option per the following table while waiting for the reliable transmission to be completed?

   OffsetTime   Transmission#   Transmitted Max-Age
       0             1            30
       3             2            27
       9             3            21
      21             4             9
      45             5             0

In the context of Section 4.5 of observe-10: If this confirmable message were a notification (and did not have Max-Age), would a change in the value of the underlying resource at T=15 while this notification is outstanding force the server to execute the five step process?  At what time would step 1 of that process complete: 15 seconds, 21 seconds, 93 seconds, or some other time?

It is necessary to wait for the transmission attempt to complete
first. Because otherwise, if the transmission is canceled and a new
transmission is started immediately, there are two problems when
notifications are generated more quickly than can be consumed (for
example, at a proxy located at the boundary between a fast network and
a constrained network):

* the client and/or network could be overloaded; and

* transmissions would never time out and therefore a dead client would
never be removed from the list of observers.


Regardless I think all this should be done relative to one notification, not
NSTART, again because things get messy if NSTART is greater than one: there
would legitimately be multiple active notifications to the same observer for
the same resource with either conflicting or duplicate content.

One of the goals of -observe is that

      Clients should see the new state after a state change as soon
      as possible, and they should see as many states as possible.
      (draft-ietf-core-observe-10#section-1.4)

So if it's possible to let a client see more intermediate state
changes by having more than one active notification at the same time,
that would help that goal. The notifications aren't conflicting --
they provide more detail; each notification has a sequence number that
lets the client put the messages back into order.

How and if NSTART may be allowed a value greater than one is an open
question at this time:

   Further congestion control optimizations and considerations are
   expected in the future, which may for example provide automatic
   initialization of the CoAP transmission parameters defined in
   Section 4.8, and thus may allow a value for NSTART greater than one.
   (draft-ietf-core-coap-18#section-4.7)

Yes.  We need to resolve what Section 4.5 really requires of an implementation for NSTART=1 before assessing what it requires when NSTART>1 .

Best regards,
Klaus

PS: You can see the full changes I've made in SVN based on your
comments here: <http://trac.tools.ietf.org/wg/core/trac/changeset/1502>

Thanks.

Peter
--------------010401050103000406040802-- From hartke@tzi.org Thu Sep 26 22:30:38 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9092C11E8121 for ; Thu, 26 Sep 2013 22:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tr5AuuoXx1XY for ; Thu, 26 Sep 2013 22:30:32 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 72BA111E810F for ; Thu, 26 Sep 2013 22:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r8R5UToT029870 for ; Fri, 27 Sep 2013 07:30:29 +0200 (CEST) Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C28CDC36 for ; Fri, 27 Sep 2013 07:30:28 +0200 (CEST) Received: by mail-vc0-f175.google.com with SMTP id ia10so1525459vcb.34 for ; Thu, 26 Sep 2013 22:30:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=BDyXnOar8M4rYSS0h8z7AlGyRV6ECIWPcNdcz0B3dlM=; b=XbEjZYDClDTwD296cwjHuEcet9vIbRlaB4I98fajGoth8v8GGyNmG5gEmktWPm2zRR 2DPTwXCYKSbliucmF4FjW81ZliPIFLjb9aX8bv6lQKO7xhBvzTZrzsdU/BKnfZkjZaHU lu9EqledOJZj5ukVJPiRaJPMSL6sf9kc4pzHm4eqSa2p7k8GRn7iq+gfUh5QrZ8SD43X NrAZBavSnG/0SHWb+waEPPR8BIOendrhlP4zCDwmmFsQwk/AHKxfLgRwGIEhBW5ny1wW tsnFBfKLUQevNr19bt8bB/+Q9Ta1q1beXeyJjjdHcKatuMdZ03w3oYa/z+Zj3IuqwBzT eTbA== X-Received: by 10.221.64.17 with SMTP id xg17mr4447033vcb.5.1380259827381; Thu, 26 Sep 2013 22:30:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.24.83 with HTTP; Thu, 26 Sep 2013 22:29:47 -0700 (PDT) In-Reply-To: <52450F90.8020202@pabigot.com> References: <5244498E.3050202@pabigot.com> <52450F90.8020202@pabigot.com> From: Klaus Hartke Date: Fri, 27 Sep 2013 08:29:47 +0300 Message-ID: To: "Peter A. Bigot" Content-Type: text/plain; charset=ISO-8859-1 Cc: core Subject: Re: [core] Comments on draft-ietf-core-observe-10 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 05:30:38 -0000 Peter A. Bigot wrote: >> The whole text is written in the scope of one client observing one >> resource. But, of course, when a client observes two or more resources >> on the same server, the server must perform congestion control over >> the aggregate traffic. > > There is no "of course" if the specification isn't clear. I can still read > the text as disallowing more than NSTART notifications over all clients > and/or resources, or I could read it as allowing more than NSTART > notifications to a single client observing multiple resources. I believe > the intent is to allow the first, and disallow the second. That's indeed what is intended. > The wording should be clarified. Could you provide some text? > I need to fix my understanding of what transmission and retransmission mean. > > For comparison, Section 5.10.5 (Max-Age) of draft-ietf-core-coap-18 has: > > The value is intended to be current at the time of transmission. > Servers that provide resources with strict tolerances on the value of > Max-Age SHOULD update the value before each retransmission. (See > also Section 5.7.1.) > > Though this certainly applies to proxies, the wording suggests it also > applies to origin servers. Yes. > With the default transmission parameters, a CON message with maximum initial > timeout will be transmitted at most five times at offsets of 0, 3, 6, 12, > and 24 seconds, with a 48 second wait after the fourth retransmission, > resulting in a MAX_TRANSMIT_WAIT of 93 seconds. Yes. > If the CON message has a Max-Age option with value 30, does the above text > mean that the server SHOULD update the value in the Max-Age option per the > following table while waiting for the reliable transmission to be completed? Yes. > In the context of Section 4.5 of observe-10: If this confirmable message > were a notification (and did not have Max-Age), would a change in the value > of the underlying resource at T=15 while this notification is outstanding > force the server to execute the five step process? At what time would step > 1 of that process complete: 15 seconds, 21 seconds, 93 seconds, or some > other time? Each row in the table is one transmission attempt. So if the server sends a confirmable notification for resource state X and the state changes to Y at T=15, then the example would look as follows: OffsetTime Transmission# Transmitted State Message ID 0 1 X 1230 3 2 X 1230 9 3 X 1230 21 4 Y 1231 45 5 Y 1231 That is, the server waits until the transmission attempt that is current at T=15 (transmission #3) completes (here: times out; this is step 1) and then starts a new transmission at T=21 (step 3) while it keeps increasing the transmission counter and doubling the timer (step 4), so the overall transmission process ultimately times out at T=93. Best regards, Klaus From internet-drafts@ietf.org Fri Sep 27 04:34:32 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 964E411E814B; Fri, 27 Sep 2013 04:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rm0+Q+R7W66C; Fri, 27 Sep 2013 04:34:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 08CD911E80AD; Fri, 27 Sep 2013 04:34:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130927113432.11230.19851.idtracker@ietfa.amsl.com> Date: Fri, 27 Sep 2013 04:34:32 -0700 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-groupcomm-15.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 11:34:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments Working = Group of the IETF. Title : Group Communication for CoAP Author(s) : Akbar Rahman Esko Dijk Filename : draft-ietf-core-groupcomm-15.txt Pages : 41 Date : 2013-09-27 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-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-groupcomm-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 Akbar.Rahman@InterDigital.com Fri Sep 27 04:40:17 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A46321F9C20 for ; Fri, 27 Sep 2013 04:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-YjangplQyB for ; Fri, 27 Sep 2013 04:40:12 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id BF03821F9B4B for ; Fri, 27 Sep 2013 04:40:12 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.12]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Sep 2013 07:40:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Sep 2013 07:40:11 -0400 Message-ID: In-Reply-To: <20130927113432.11230.19851.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] I-D Action: draft-ietf-core-groupcomm-15.txt Thread-Index: Ac67dcH5gPbgUTmPTfCpeiP0sbc9VgAAA/Bw References: <20130927113432.11230.19851.idtracker@ietfa.amsl.com> From: "Rahman, Akbar" To: X-OriginalArrivalTime: 27 Sep 2013 11:40:12.0131 (UTC) FILETIME=[53793330:01CEBB76] Subject: Re: [core] I-D Action: draft-ietf-core-groupcomm-15.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 11:40:17 -0000 Hi All, We have just submitted Groupcomm-15. This version closes the remainder of Carsten's review comments on the draft. Thank you, Carsten, for the excellent and thorough review! Akbar and Esko -------------------------------------------------------------------- The specific updates in this version were: Changes from ietf-14 to ietf-15: o In section 2.2, provided guidance on how implementers should parse URIs for group communication (#339). o In section 2.6.2.1, specified that for group membership configuration interface the "ip" (i.e. "a" parameter) key/value is not required when it is unknown (#338). o In section 2.6.2.1, specified that for group membership configuration interface the port configuration be defaulted to standard CoAP port 5683, and if not default then should follow standard notation (#340). o In section 2.6.2.1, specified that notation of IP address in group membership configuration interface should follow standard notation (#342). o In section 6.2, "coap-group+json" Media Type encoding simplified to just support UTF-8 (and not UTF-16 and UTF-32) (#344). o Various editorial updates for improved readability. -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Friday, September 27, 2013 7:35 AM To: i-d-announce@ietf.org Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-groupcomm-15.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 Author(s) : Akbar Rahman Esko Dijk Filename : draft-ietf-core-groupcomm-15.txt Pages : 41 Date : 2013-09-27 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-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-groupcomm-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/ _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From pab@pabigot.com Fri Sep 27 06:28:54 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0347A21F92CD for ; Fri, 27 Sep 2013 06:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJOP3cVG6TcI for ; Fri, 27 Sep 2013 06:28:48 -0700 (PDT) Received: from p3plsmtpa11-09.prod.phx3.secureserver.net (p3plsmtpa11-09.prod.phx3.secureserver.net [68.178.252.110]) by ietfa.amsl.com (Postfix) with ESMTP id DF5BB11E80F8 for ; Fri, 27 Sep 2013 06:28:45 -0700 (PDT) Received: from [192.168.65.10] ([66.41.60.82]) by p3plsmtpa11-09.prod.phx3.secureserver.net with id WDUj1m00N1mTNtu01DUkgM; Fri, 27 Sep 2013 06:28:45 -0700 Message-ID: <5245880B.2000601@pabigot.com> Date: Fri, 27 Sep 2013 08:28:43 -0500 From: "Peter A. Bigot" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: Klaus Hartke References: <5244498E.3050202@pabigot.com> <52450F90.8020202@pabigot.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090305070502080402050804" Cc: core Subject: Re: [core] Comments on draft-ietf-core-observe-10 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 13:28:54 -0000 This is a multi-part message in MIME format. --------------090305070502080402050804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit So you understand my perspective, in my mental model of CoAP architectural layers an application at an endpoint creates a message and hands it off to a message layer for transmission. With the exception of Max-Age, which can be handled within the message layer, nothing until now has *required* interaction with the higher layers (transaction or application/resource) during the process of reliable (re-)transmission by the message layer. By coap-18 section 4.2 the higher layers may cancel the transmission sequence if something happens that allows the server to know that the receiver got the message, but calls in the other direction are not necessary. On 09/27/2013 12:29 AM, Klaus Hartke wrote: > Peter A. Bigot wrote: >>> The whole text is written in the scope of one client observing one >>> resource. But, of course, when a client observes two or more resources >>> on the same server, the server must perform congestion control over >>> the aggregate traffic. >> There is no "of course" if the specification isn't clear. I can still read >> the text as disallowing more than NSTART notifications over all clients >> and/or resources, or I could read it as allowing more than NSTART >> notifications to a single client observing multiple resources. I believe >> the intent is to allow the first, and disallow the second. > That's indeed what is intended. > >> The wording should be clarified. > Could you provide some text? I'll try, but this is taking way too much time for something I'm doing on the side. >> I need to fix my understanding of what transmission and retransmission mean. >> >> For comparison, Section 5.10.5 (Max-Age) of draft-ietf-core-coap-18 has: >> >> The value is intended to be current at the time of transmission. >> Servers that provide resources with strict tolerances on the value of >> Max-Age SHOULD update the value before each retransmission. (See >> also Section 5.7.1.) >> >> Though this certainly applies to proxies, the wording suggests it also >> applies to origin servers. > Yes. > >> With the default transmission parameters, a CON message with maximum initial >> timeout will be transmitted at most five times at offsets of 0, 3, 6, 12, >> and 24 seconds, with a 48 second wait after the fourth retransmission, >> resulting in a MAX_TRANSMIT_WAIT of 93 seconds. > Yes. > >> If the CON message has a Max-Age option with value 30, does the above text >> mean that the server SHOULD update the value in the Max-Age option per the >> following table while waiting for the reliable transmission to be completed? > Yes. Excellent. In this case, the message layer is capable of doing this update without interacting with higher layers, since it can record when it received the message. I expect that, when it does this, it does *not* update any other part of the message, including the message ID. True? > >> In the context of Section 4.5 of observe-10: If this confirmable message >> were a notification (and did not have Max-Age), would a change in the value >> of the underlying resource at T=15 while this notification is outstanding >> force the server to execute the five step process? At what time would step >> 1 of that process complete: 15 seconds, 21 seconds, 93 seconds, or some >> other time? > Each row in the table is one transmission attempt. So if the server > sends a confirmable notification for resource state X and the state > changes to Y at T=15, then the example would look as follows: > > OffsetTime Transmission# Transmitted State Message ID > 0 1 X 1230 > 3 2 X 1230 > 9 3 X 1230 > 21 4 Y 1231 > 45 5 Y 1231 > > That is, the server waits until the transmission attempt that is > current at T=15 (transmission #3) completes (here: times out; this is > step 1) and then starts a new transmission at T=21 (step 3) while it > keeps increasing the transmission counter and doubling the timer (step > 4), so the overall transmission process ultimately times out at T=93. Thanks. That's clear, but I don't think it's the best solution. (I do agree that, to satisfy congestion control, a new retransmission sequence cannot start until 93 seconds have elapsed or the sender can tell the receiver got the message, and we need to preserve that behavior.) You're showing Message ID changing during the transmission of a confirmable message, and you don't have a column for the sequence number. If you meant this as: OffsetTime Transmission# Transmitted State Message ID Observe 0 1 X 1230 1000 3 2 X 1230 1000 9 3 X 1230 1000 21 4 Y 1231 1001 45 5 Y 1231 1001 then this is just weird because if the client got transmissions 3 and 4 it has to send two confirmations, one for message ID 1230 and one for message ID 1231, to something that is essentially one confirmable message. When the value of Max-Age changes in base CoAP nobody has said the Message ID also needs to change (unless you did in a response to that question above). Is there any other case where CoAP has required the Message ID to change during a reliable transmission of a single message? Or is this sequence to be conceived as a new message that starts part-way through the retransmission process, with transmission parameters not in their initial state? Both of these interpretations seem to be creating new concepts unnecessarily and bother me. You might have meant: OffsetTime Transmission# Transmitted State Message ID Observe 0 1 X 1230 1000 3 2 X 1230 1000 9 3 X 1230 1000 21 4 Y 1230 1001 45 5 Y 1230 1001 which keep one message ID for the entire retransmission process. It is unusual, since it changes the content of the message during the retransmissions, but it still satisfies congestion limits and correct correlation of the resource state with a sequence number for ordering. It's also consistent with the pre-existing case of Max-Age. Since the semantics of the notification is eventual consistency and the sequence number is paired with the state, it just works. I have no problem with this version as a valid sequence. Getting back to the context of the original text from section 4.4 of observe-10: The sequence number selected for a notification MUST be greater than that of any preceding notification sent to the same client with the same token for the same resource. The value of the Observe Option MUST be current at the time of transmission; if a notification is retransmitted, the server MUST update the value of the option to the sequence number that is current at that time before sending the message. The question now is whether each of these retransmissions is a notification that, because of this clause, must be modified. I propose the answer should be No because it is *not* necessary for correctness. Changing the content of the notification because it is out of date is an optimization. Is there anything in observe (other than this text) that *requires* the server to send the new state immediately? The Freshness section allows the server to skip whole notifications to prevent congestion. If NSTART>1, is there anything wrong with the following sequence? OffsetTime Transmission# Transmitted State Message ID Observe 0 1 X 1230 1000 3 2 X 1230 1000 9 3 X 1230 1000 15 1 Y 1231 1001 18 2 Y 1231 1001 21 4 X 1230 1000 24 3 Y 1231 1001 36 4 Y 1231 1001 45 5 X 1230 1000 60 5 Y 1231 1001 Here we have interleaved outdated and current values. The sequence number still allows the client to re-order the content, and as you noted there is value in allowing the client to see the older value. Each notification remains essentially unchanged throughout its retransmission cycle (modulo Max-Age), and the CoAP layers remain decoupled. I think the optimization can be permitted without requiring it with text something like: The sequence number selected for a notification MUST be greater than that of any preceding notification sent to the same client with the same token for the same resource. If a confirmable notification must be retransmitted or a non-confirmable notification has been delayed, the server MAY update the option value and content of the message to reflect the sequence number and resource state that is current at the time of retransmission. (This is not a new notification, and the Message ID does not change.) Then the series of steps in 4.5 can remain with "MUST proceed" changed to "MAY", removing the text that suggests that the modifications produce a new notification, and adding the option of cancelling an older notification if its content has been updated to be redundant with a newer notification. I think that if left as MUST it (a) couples the message layer with the service application to re-validate the content before transmission, and (b) introduces complexity and waste if NSTART>1 since it would mandate that multiple outstanding transmissions all update to have the same content except message ID. Peter --------------090305070502080402050804 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
So you understand my perspective, in my mental model of CoAP architectural layers an application at an endpoint creates a message and hands it off to a message layer for transmission.  With the exception of Max-Age, which can be handled within the message layer, nothing until now has *required* interaction with the higher layers (transaction or application/resource) during the process of reliable (re-)transmission by the message layer.  By coap-18 section 4.2 the higher layers may cancel the transmission sequence if something happens that allows the server to know that the receiver got the message, but calls in the other direction are not necessary.

On 09/27/2013 12:29 AM, Klaus Hartke wrote:
Peter A. Bigot wrote:

The whole text is written in the scope of one client observing one
resource. But, of course, when a client observes two or more resources
on the same server, the server must perform congestion control over
the aggregate traffic.

There is no "of course" if the specification isn't clear.  I can still read
the text as disallowing more than NSTART notifications over all clients
and/or resources, or I could read it as allowing more than NSTART
notifications to a single client observing multiple resources.  I believe
the intent is to allow the first, and disallow the second.

That's indeed what is intended.


The wording should be clarified.

Could you provide some text?

I'll try, but this is taking way too much time for something I'm doing on the side.

I need to fix my understanding of what transmission and retransmission mean.

For comparison, Section 5.10.5 (Max-Age) of draft-ietf-core-coap-18 has:

   The value is intended to be current at the time of transmission.
   Servers that provide resources with strict tolerances on the value of
   Max-Age SHOULD update the value before each retransmission.  (See
   also Section 5.7.1.)

Though this certainly applies to proxies, the wording suggests it also
applies to origin servers.

Yes.


With the default transmission parameters, a CON message with maximum initial
timeout will be transmitted at most five times at offsets of 0, 3, 6, 12,
and 24 seconds, with a 48 second wait after the fourth retransmission,
resulting in a MAX_TRANSMIT_WAIT of 93 seconds.

Yes.


If the CON message has a Max-Age option with value 30, does the above text
mean that the server SHOULD update the value in the Max-Age option per the
following table while waiting for the reliable transmission to be completed?

Yes.

Excellent.  In this case, the message layer is capable of doing this update without interacting with higher layers, since it can record when it received the message.  I expect that, when it does this, it does *not* update any other part of the message, including the message ID.  True?


In the context of Section 4.5 of observe-10: If this confirmable message
were a notification (and did not have Max-Age), would a change in the value
of the underlying resource at T=15 while this notification is outstanding
force the server to execute the five step process?  At what time would step
1 of that process complete: 15 seconds, 21 seconds, 93 seconds, or some
other time?

Each row in the table is one transmission attempt. So if the server
sends a confirmable notification for resource state X and the state
changes to Y at T=15, then the example would look as follows:

    OffsetTime   Transmission#   Transmitted State   Message ID
        0             1                  X              1230
        3             2                  X              1230
        9             3                  X              1230
       21             4                  Y              1231
       45             5                  Y              1231

That is, the server waits until the transmission attempt that is
current at T=15 (transmission #3) completes (here: times out; this is
step 1) and then starts a new transmission at T=21 (step 3) while it
keeps increasing the transmission counter and doubling the timer (step
4), so the overall transmission process ultimately times out at T=93.

Thanks.  That's clear, but I don't think it's the best solution.  (I do agree that, to satisfy congestion control, a new retransmission sequence cannot start until 93 seconds have elapsed or the sender can tell the receiver got the message, and we need to preserve that behavior.)

You're showing Message ID changing during the transmission of a confirmable message, and you don't have a column for the sequence number.  If you meant this as:

  OffsetTime   Transmission#   Transmitted State   Message ID  Observe
      0             1                  X              1230       1000
      3             2                  X              1230       1000
      9             3                  X              1230       1000
     21             4                  Y              1231       1001
     45             5                  Y              1231       1001

then this is just weird because if the client got transmissions 3 and 4 it has to send two confirmations, one for message ID 1230 and one for message ID 1231, to something that is essentially one confirmable message.  When the value of Max-Age changes in base CoAP nobody has said the Message ID also needs to change (unless you did in a response to that question above).

Is there any other case where CoAP has required the Message ID to change during a reliable transmission of a single message?

Or is this sequence to be conceived as a new message that starts part-way through the retransmission process, with transmission parameters not in their initial state?

Both of these interpretations seem to be creating new concepts unnecessarily and bother me.

You might have meant:

  OffsetTime   Transmission#   Transmitted State   Message ID  Observe
      0             1                  X              1230       1000
      3             2                  X              1230       1000
      9             3                  X              1230       1000
     21             4                  Y              1230       1001
     45             5                  Y              1230       1001

which keep one message ID for the entire retransmission process.  It is unusual, since it changes the content of the message during the retransmissions, but it still satisfies congestion limits and correct correlation of the resource state with a sequence number for ordering.  It's also consistent with the pre-existing case of Max-Age.  Since the semantics of the notification is eventual consistency and the sequence number is paired with the state, it just works.

I have no problem with this version as a valid sequence.

Getting back to the context of the original text from section 4.4 of observe-10:

   The sequence number selected for a notification MUST be greater than
   that of any preceding notification sent to the same client with the
   same token for the same resource.  The value of the Observe Option
   MUST be current at the time of transmission; if a notification is
   retransmitted, the server MUST update the value of the option to the
   sequence number that is current at that time before sending the
   message.

The question now is whether each of these retransmissions is a notification that, because of this clause, must be modified.  I propose the answer should be No because it is *not* necessary for correctness.

Changing the content of the notification because it is out of date is an optimization.  Is there anything in observe (other than this text) that *requires* the server to send the new state immediately?  The Freshness section allows the server to skip whole notifications to prevent congestion.

If NSTART>1, is there anything wrong with the following sequence?

    OffsetTime   Transmission#   Transmitted State   Message ID  Observe
        0             1                  X              1230       1000
        3             2                  X              1230       1000
        9             3                  X              1230       1000
       15             1                  Y              1231       1001
       18             2                  Y              1231       1001
       21             4                  X              1230       1000
       24             3                  Y              1231       1001
       36             4                  Y              1231       1001
       45             5                  X              1230       1000
       60             5                  Y              1231       1001

Here we have interleaved outdated and current values.  The sequence number still allows the client to re-order the content, and as you noted there is value in allowing the client to see the older value.  Each notification remains essentially unchanged throughout its retransmission cycle (modulo Max-Age), and the CoAP layers remain decoupled.

I think the optimization can be permitted without requiring it with text something like:

   The sequence number selected for a notification MUST be greater than that
   of any preceding notification sent to the same client with the same token
   for the same resource.  If a confirmable notification must be
   retransmitted or a non-confirmable notification has been delayed, the
   server MAY update the option value and content of the message to reflect the
   sequence number and resource state that is current at the time of
   retransmission.  (This is not a new notification, and the Message ID does
   not change.)

Then the series of steps in 4.5 can remain with "MUST proceed" changed to "MAY", removing the text that suggests that the modifications produce a new notification, and adding the option of cancelling an older notification if its content has been updated to be redundant with a newer notification.

I think that if left as MUST it (a) couples the message layer with the service application to re-validate the content before transmission, and (b) introduces complexity and waste if NSTART>1 since it would mandate that multiple outstanding transmissions all update to have the same content except message ID.

Peter

--------------090305070502080402050804-- From prvs=976761765=abhijan.bhattacharyya@tcs.com Sat Sep 28 00:29:53 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8099B11E817D for ; Sat, 28 Sep 2013 00:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.588 X-Spam-Level: X-Spam-Status: No, score=-6.588 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DRUGS_MUSCLE=0.01, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNSx9lR09pYI for ; Sat, 28 Sep 2013 00:29:49 -0700 (PDT) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 61B8711E8121 for ; Sat, 28 Sep 2013 00:29:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,998,1371061800"; d="scan'208";a="454190299" Received: from INKOLSALDLPMTA1.india.tcs.com (unknown [127.0.0.1]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id E6764DAC12 for ; Sat, 28 Sep 2013 12:59:33 +0530 (IST) Received: from InKolM02.tcs.com (unknown [172.18.18.104]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id B772FDAC02 for ; Sat, 28 Sep 2013 12:59:32 +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: Sat, 28 Sep 2013 12:59:31 +0530 X-Mailer: Lotus Domino Web Server Release 9.0HF507 August 20, 2013 X-MIMETrack: Serialize by Notes Server on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 09/28/2013 12:59:31, Serialize complete at 09/28/2013 12:59:31, Itemize by Notes Server on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 09/28/2013 12:59:31, Serialize by Notes Server on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 09/28/2013 12:59:32, Serialize complete at 09/28/2013 12:59:32, Serialize by Router on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 09/28/2013 12:59:32 Content-Type: multipart/alternative; boundary="=_alternative 002927A065257BF4_=" Cc: Soma Bandyopadhyay , Arpan Pal Subject: [core] Fw: New Version Notification for draft-tcs-coap-no-response-option-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 07:29:53 -0000 --=_alternative 002927A065257BF4_= MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, We have submitted a new draft on the No-Resp option. This draft contains si= gnificant changes than the previous versions. Thanks to the comments from C= arsten, Esko and Bert. This draft incorporates few user scenarios before di= scussing the technical details. The user scenarios are described in the lig= ht of how application of this option might benefit resource constrained env= ironments. Taking clue from the comments we received, this draft enhances t= his option to allow 'optional' granularity so that one can choose to suppre= ss a particular class or a combination of classes of responses. Please share your comments.=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 ____________________________________________ -----Forwarded by Abhijan Bhattacharyya/KOL/TCS on 09/28/2013 12:49PM ----- To: Abhijan Bhattacharyya , Soma Bandyopadhy= ay , Arpan Pal From: internet-drafts@ietf.org Date: 09/28/2013 12:48PM Subject: New Version Notification for draft-tcs-coap-no-response-option-02.= txt A new version of I-D, draft-tcs-coap-no-response-option-02.txt has been successfully submitted by Abhijan Bhattacharyya and posted to the IETF repository. Filename: draft-tcs-coap-no-response-option Revision: 02 Title: CoAP option for no server-response Creation date: 2013-09-28 Group: Individual Submission Number of pages: 12 URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/internet-drafts/draft-tcs-= coap-no-response-option-02.txt Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft-tcs-coap-n= o-response-option Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-tcs-coap-no-respo= nse-option-02 Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/rfcdiff?url2=3Ddraft-tcs-c= oap-no-response-option-02 Abstract: =A0=A0 There can be typical M2M scenarios where responses from the data =A0=A0 sink to the data source against request/ notification from the =A0=A0 source might be considered redundant. This kind of open-loop =A0=A0 exchange (with no reverse path from the sink to the source) may be =A0=A0 desired while updating resources or notifying about the updated =A0=A0 status of a resource in constrained systems looking for maximized =A0=A0 throughput with minimized resource consumption. CoAP already =A0=A0 provides a non-confirmable (NON) mode of exchange where The =A0=A0 receiving end-point does not respond with ACK. However, the =A0=A0 receiving end-point responds the sender with a status code =A0=A0 indicating "the result of the attempt to understand and satisfy the =A0=A0 request". =A0=A0 This draft introduces a header option: 'No-Resp' to suppress =A0=A0 responses from the receiver and discusses exemplary use cases which =A0=A0 motivated this proposition based on real experience. This option =A0=A0 also provides granularity by allowing suppression of a particular =A0=A0 class or a combination of classes of responses. This option is =A0=A0 applicable for both request/ response as well as resource-observe =A0=A0 mode and may be effective for both unicast and multicast scenarios. =A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat =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 002927A065257BF4_= Content-ID: <> MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
We have submitted a new draft on the No-Resp = option. This draft contains significant changes than the previous versions.= Thanks to the comments from Carsten, Esko and Bert. This draft incorporate= s few user scenarios before discussing the technical details. The user scen= arios are described in the light of how application of this option might be= nefit resource constrained environments. Taking clue from the comments we r= eceived, this draft enhances this option to allow 'optional' granularity so= that one can choose to suppress a particular class or a combination of cla= sses of responses.

Please share your comments.&nbs= p;


Regards
Abhijan Bhattacharyya
Associate Consultant
S= cientist, Innovation Lab, Kolkata, India
Tata Consultancy Services Limit= ed
Mailto: abhijan.bhat= tacharyya@tcs.com
Website: http://www= .tcs.com
____________________________________________
Experience = certainty. IT Services
Business Solutions
Consulting
_______= _____________________________________


= -----Forwarded by Abhijan Bhattacharyya/KOL/TCS on 09/28/2013 12:49PM -----=
To: Abhijan Bhattacharyya <abhijan.bhattacharyya@tcs.com>, Som= a Bandyopadhyay <soma.bandyopadhyay@tcs.com>, Arpan Pal <arpan.pal= @tcs.com>
From: internet-drafts@ietf.org
Date: 09/28/2013 12:48PM<= br>Subject: New Version Notification for draft-tcs-coap-no-response-option-= 02.txt

= A new version of I-D, draft-tcs-coap-no-response-option-02.txt
has been = successfully submitted by Abhijan Bhattacharyya and posted to the
IETF r= epository.

Filename: draft-tcs-coap-no-response-option
Revision:= 02
Title: CoAP option for no server-response
Creation date: 2013= -09-28
Group: Individual Submission
Number of pages: 12
URL: &nb= sp;           http://www.ietf.org/in= ternet-drafts/draft-tcs-coap-no-response-option-02.txt
Status:  = ;        http://datatracker.ietf.org/doc/draft-tcs-c= oap-no-response-option
Htmlized:        http:/= /tools.ietf.org/html/draft-tcs-coap-no-response-option-02
Diff: &nbs= p;          http://www.ietf.org/rfcdiff?u= rl2=3Ddraft-tcs-coap-no-response-option-02

Abstract:
 &n= bsp; There can be typical M2M scenarios where responses from the data
&n= bsp;  sink to the data source against request/ notification from the   source might be considered redundant. This kind of open-loop=
   exchange (with no reverse path from the sink to the source= ) may be
   desired while updating resources or notifying abou= t the updated
   status of a resource in constrained systems l= ooking for maximized
   throughput with minimized resource con= sumption. CoAP already
   provides a non-confirmable (NON) mod= e of exchange where The
   receiving end-point does not respon= d with ACK. However, the
   receiving end-point responds the s= ender with a status code
   indicating "the result of the atte= mpt to understand and satisfy the
   request".

 &n= bsp; This draft introduces a header option: 'No-Resp' to suppress
 =   responses from the receiver and discusses exemplary use cases which<= br>   motivated this proposition based on real experience. This o= ption
   also provides granularity by allowing suppression of = a particular
   class or a combination of classes of responses= . This option is
   applicable for both request/ response as w= ell as resource-observe
   mode and may be effective for both = unicast and multicast scenarios.

         &= nbsp;                    =                     &nbs= p;                     &n= bsp;        


Please note that it may take a = couple of minutes from the time of submission
until the htmlized version= and diff are available at tools.ietf.org.

The IETF Secretariat
<= br>

=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 002927A065257BF4_=-- From hartke@tzi.org Sun Sep 29 23:08:40 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 682C721F9D0C for ; Sun, 29 Sep 2013 23:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKKIC6N79CO2 for ; Sun, 29 Sep 2013 23:08:32 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 7641121F9D05 for ; Sun, 29 Sep 2013 23:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r8U68LKs012380 for ; Mon, 30 Sep 2013 08:08:26 +0200 (CEST) Received: from mail-vb0-f48.google.com (mail-vb0-f48.google.com [209.85.212.48]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C1D0C473 for ; Mon, 30 Sep 2013 08:08:20 +0200 (CEST) Received: by mail-vb0-f48.google.com with SMTP id w16so3368647vbf.21 for ; Sun, 29 Sep 2013 23:08:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=M7S9+XT/VqtWk1G9MULa2rugKi8TXrHofNFqTs19jsc=; b=fNXf/lFSvCdtMcEWYhCUYE45xAzvixbl8JM+FF0lmS5wSas30tv+nOM6xQid1YvM5l 1RbEuhQv1ZJTWYInQ/2BvXiADD4cuctt8lGuzXgOGMewdp3NK47juLaroig3aapX//a3 98TtmlJ5a0pPKwXCIuWBro+RJ/QxF/hfYasSJj0ZpqMkp8v2GDAHyaEjXV9BBUh4+RMC JkKdL/6X5+TSQWqJMPY2VF0g066WufMxLdT7dRRuGfT/hruO3VgRFFGBwJAeIeHfOvU3 Z4XYqgP4F/6D5y6M+nwiOPQhtR11oSEzP2QB78jaW8PVuPMMAXxkniSMVHO0bouB7zTU MvoA== X-Received: by 10.220.10.194 with SMTP id q2mr20608802vcq.2.1380521299263; Sun, 29 Sep 2013 23:08:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.24.83 with HTTP; Sun, 29 Sep 2013 23:07:39 -0700 (PDT) In-Reply-To: <5245880B.2000601@pabigot.com> References: <5244498E.3050202@pabigot.com> <52450F90.8020202@pabigot.com> <5245880B.2000601@pabigot.com> From: Klaus Hartke Date: Mon, 30 Sep 2013 09:07:39 +0300 Message-ID: To: "Peter A. Bigot" Content-Type: text/plain; charset=ISO-8859-1 Cc: core Subject: Re: [core] Comments on draft-ietf-core-observe-10 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 06:08:40 -0000 Peter A. Bigot wrote: > Or is this sequence to be conceived as a new message that starts part-way > through the retransmission process, with transmission parameters not in > their initial state? This. > Excellent. In this case, the message layer is capable of doing this update > without interacting with higher layers, since it can record when it received > the message. I expect that, when it does this, it does *not* update any > other part of the message, including the message ID. True? When retransmitting a notification message, all parts of the message stay the same, including the message ID, except that Max-Age SHOULD and the Observe sequence number MUST be up-to-date at the time of each transmission attempt, which may or may not require an update to the message. Section 4.4 of observe-10 describes two implementation techniques to satisfy the 'MUST': one where, in your terms, the sequence numbers are generated by the message layer. This can be done without communicating with any higher layer, but requires a change to the message at each transmission attempt. And one where the sequence numbers are generated by a higher layer. This requires the higher layer to perform some bookkeeping, but no changes to the message are required at the message layer. > With the exception of Max-Age, which can be > handled within the message layer, nothing until now has *required* > interaction with the higher layers (transaction or application/resource) > during the process of reliable (re-)transmission by the message layer. For supporting observe-10, the message layer should just be able to inform the higher layer of a client that is gone, and to replace an ongoing transmission process with a new transmission process that inherits the current transmission parameters. Both can be implemented without requiring the message layer to start an interaction with a higher layer. > Changing the content of the notification because it is out of date is an > optimization. Is there anything in observe (other than this text) that > *requires* the server to send the new state immediately? Section 1.4 of observe-10 states that one of the goals of the protocol is that Clients should see the new state after a state change as soon as possible [...] So it's not merely an optimization that a server tries to get a representation of the the latest resource state to the client, but the very purpose of the protocol. Best regards, Klaus From qiminpeng@chinamobile.com Mon Sep 30 00:01:36 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 634F021F9BC1 for ; Mon, 30 Sep 2013 00:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_221=2.222] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxy4my1uRSsV for ; Mon, 30 Sep 2013 00:01:31 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 47B2A21F9BB6 for ; Mon, 30 Sep 2013 00:01:29 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.12]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee15249216df54-acf54; Mon, 30 Sep 2013 14:59:59 +0800 (CST) X-RM-TRANSID: 2ee15249216df54-acf54 Received: from RonPC (unknown[10.2.46.58]) by rmsmtp-oa_rmapp02-12002 (RichMail) with SMTP id 2ee25249216a091-13d83; Mon, 30 Sep 2013 14:59:59 +0800 (CST) X-RM-TRANSID: 2ee25249216a091-13d83 From: "QiMinpeng" To: Date: Mon, 30 Sep 2013 15:02:21 +0800 Message-ID: <006401cebdab$02865b60$07931220$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac69qEiRjLF71WKSRAK4VOvAg2XCigAAQlog Content-Language: zh-cn Subject: [core] Fw: New Version Notification for draft-zhu-core-groupauth-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 07:01:36 -0000 Hi all, We have submitted a revised version of our group authentication draft. = All your comments are welcome. The details of the draft can be found = below. The main changes are: 1. Adding some terminology definition for better understanding 2. Adding more detailed description for use cases 3. Updating solution BRs, Minpeng -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2013=E5=B9=B49=E6=9C=8830=E6=97=A5 = 14:31 =E6=94=B6=E4=BB=B6=E4=BA=BA: Minpeng Qi; Judy Zhu =E4=B8=BB=E9=A2=98: New Version Notification for = draft-zhu-core-groupauth-01.txt A new version of I-D, draft-zhu-core-groupauth-01.txt has been successfully submitted by Judy Zhu and posted to the IETF repository. Filename: draft-zhu-core-groupauth Revision: 01 Title: Group Authentication Creation date: 2013-09-29 Group: Individual Submission Number of pages: 12 URL: = http://www.ietf.org/internet-drafts/draft-zhu-core-groupauth-01.txt Status: = http://datatracker.ietf.org/doc/draft-zhu-core-groupauth Htmlized: http://tools.ietf.org/html/draft-zhu-core-groupauth-01 Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-zhu-core-groupauth-01 Abstract: The group communication is designed for the communication of Internet of Things. A threat is identified in [I-D.ietf-core-groupcomm] that current DTLS based approach is unicast oriented and there is no supporting on group authentication feature. Unicast oriented authentication will causing serious burden when a large number of terminal nodes will be involved inevitably. In another aspect, some terminals will own the same characteristics, such as owning same features, in the same place, working in the same time, etc. With this mechanism, all terminals can be authenticated together with little signaling and calculation at the same time. It will reduce the network burden and save time. This draft describes the security of group authentication and an group authentication implementation method for the Internet of things. = =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. The IETF Secretariat From trac+core@trac.tools.ietf.org Mon Sep 30 00:57:39 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B67B021F9BEF for ; Mon, 30 Sep 2013 00:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nx6U7N924seU for ; Mon, 30 Sep 2013 00:57:39 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 759B321F9C9B for ; Mon, 30 Sep 2013 00:57:34 -0700 (PDT) Received: from localhost ([127.0.0.1]:35795 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VQYMD-0006JA-Eu; Mon, 30 Sep 2013 09:57:29 +0200 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-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Mon, 30 Sep 2013 07:57:29 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/339#comment:1 Message-ID: <075.5b0b7dfc1cccab23e4799b88dad7ed26@trac.tools.ietf.org> References: <060.e83f7eaa357018c90e2c0dc7bd21f565@trac.tools.ietf.org> X-Trac-Ticket-ID: 339 In-Reply-To: <060.e83f7eaa357018c90e2c0dc7bd21f565@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@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 grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20130930075734.759B321F9C9B@ietfa.amsl.com> Resent-Date: Mon, 30 Sep 2013 00:57:34 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #339: Rephrase incorrect "group URI used in a CoAP request" X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 07:57:39 -0000 #339: Rephrase incorrect "group URI used in a CoAP request" Changes (by esko.dijk@philips.com): * status: new => closed * resolution: => fixed Comment: Done in groupcomm-15 http://tools.ietf.org/html/draft-ietf-core-groupcomm-15 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: protocol | Status: closed defect | Milestone: Priority: major | Version: Component: groupcomm | Resolution: fixed Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Sep 30 00:58:03 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14E121F9C05 for ; Mon, 30 Sep 2013 00:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnoJKA6fOg8E for ; Mon, 30 Sep 2013 00:58:03 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id DD26021F9C00 for ; Mon, 30 Sep 2013 00:58:02 -0700 (PDT) Received: from localhost ([127.0.0.1]:35811 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VQYMh-0004uF-O5; Mon, 30 Sep 2013 09:57:59 +0200 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-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Mon, 30 Sep 2013 07:57:59 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/342#comment:2 Message-ID: <075.949b1deca0ba1eebd7feac2b95f0904a@trac.tools.ietf.org> References: <060.cc050320858f531c711a89d46c5b0c92@trac.tools.ietf.org> X-Trac-Ticket-ID: 342 In-Reply-To: <060.cc050320858f531c711a89d46c5b0c92@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@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 grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20130930075802.DD26021F9C00@ietfa.amsl.com> Resent-Date: Mon, 30 Sep 2013 00:58:02 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #342: Specify notation of IPv6 address in group membership configuration interface X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 07:58:03 -0000 #342: Specify notation of IPv6 address in group membership configuration interface Changes (by esko.dijk@philips.com): * status: new => closed * resolution: => fixed Comment: Done in groupcomm-15 http://tools.ietf.org/html/draft-ietf-core-groupcomm-15 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: protocol | Status: closed defect | Milestone: Priority: major | Version: Component: groupcomm | Resolution: fixed Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Sep 30 00:58:19 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01B1221F9C0E for ; Mon, 30 Sep 2013 00:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxZVO-RZfTbs for ; Mon, 30 Sep 2013 00:58:18 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 05EDB21F9CCC for ; Mon, 30 Sep 2013 00:58:16 -0700 (PDT) Received: from localhost ([127.0.0.1]:35816 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VQYMw-0004uS-7w; Mon, 30 Sep 2013 09:58:14 +0200 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-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Mon, 30 Sep 2013 07:58:14 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/344#comment:1 Message-ID: <075.163bc35d046357e133b24846df6ec09b@trac.tools.ietf.org> References: <060.358e889f8937b2022b7c895bdc543757@trac.tools.ietf.org> X-Trac-Ticket-ID: 344 In-Reply-To: <060.358e889f8937b2022b7c895bdc543757@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@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 grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20130930075816.05EDB21F9CCC@ietfa.amsl.com> Resent-Date: Mon, 30 Sep 2013 00:58:16 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #344: coap-group+json Media Type encoding can be simplified to UTF-8 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 07:58:19 -0000 #344: coap-group+json Media Type encoding can be simplified to UTF-8 Changes (by esko.dijk@philips.com): * status: new => closed * resolution: => fixed Comment: Done in groupcomm-15 http://tools.ietf.org/html/draft-ietf-core-groupcomm-15 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: protocol | Status: closed enhancement | Milestone: Priority: major | Version: Component: groupcomm | Resolution: fixed Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Sep 30 00:58:39 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12EBB21F9D05 for ; Mon, 30 Sep 2013 00:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jXIHAsT+4yx for ; Mon, 30 Sep 2013 00:58:38 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 3C97521F9CFB for ; Mon, 30 Sep 2013 00:58:38 -0700 (PDT) Received: from localhost ([127.0.0.1]:35820 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VQYNI-0004uj-Qm; Mon, 30 Sep 2013 09:58:36 +0200 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-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Mon, 30 Sep 2013 07:58:36 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/338#comment:1 Message-ID: <075.55117ed72b9ae6a4085fb2fbaed1246c@trac.tools.ietf.org> References: <060.4e9d8359b433df809eb0e0e0b29e907c@trac.tools.ietf.org> X-Trac-Ticket-ID: 338 In-Reply-To: <060.4e9d8359b433df809eb0e0e0b29e907c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@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 grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20130930075838.3C97521F9CFB@ietfa.amsl.com> Resent-Date: Mon, 30 Sep 2013 00:58:38 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #338: Do not include the "ip" key/value when its value is unknown X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 07:58:39 -0000 #338: Do not include the "ip" key/value when its value is unknown Changes (by esko.dijk@philips.com): * status: new => closed * resolution: => fixed Comment: Done in groupcomm-15 http://tools.ietf.org/html/draft-ietf-core-groupcomm-15 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: protocol | Status: closed enhancement | Milestone: Priority: minor | Version: Component: groupcomm | Resolution: fixed Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Sep 30 00:59:46 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E23921F859C for ; Mon, 30 Sep 2013 00:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4R2XXRHgu-13 for ; Mon, 30 Sep 2013 00:59:45 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 1988021F90AF for ; Mon, 30 Sep 2013 00:59:43 -0700 (PDT) Received: from localhost ([127.0.0.1]:35834 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VQYOK-00053a-VR; Mon, 30 Sep 2013 09:59:40 +0200 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-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Mon, 30 Sep 2013 07:59:40 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/340#comment:1 Message-ID: <075.8e2001a936f826cc0725d846a5f71500@trac.tools.ietf.org> References: <060.5301f132aaff468a538510e7c46d69b0@trac.tools.ietf.org> X-Trac-Ticket-ID: 340 In-Reply-To: <060.5301f132aaff468a538510e7c46d69b0@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@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 grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20130930075943.1988021F90AF@ietfa.amsl.com> Resent-Date: Mon, 30 Sep 2013 00:59:43 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #340: Support for configuration of port in group membership configuration X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 07:59:46 -0000 #340: Support for configuration of port in group membership configuration Changes (by esko.dijk@philips.com): * status: new => closed * resolution: => fixed Comment: Done in groupcomm-15 http://tools.ietf.org/html/draft-ietf-core-groupcomm-15, solution 2 was chosen and reference to the required ABNF made. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: protocol | Status: closed enhancement | Milestone: Priority: minor | Version: Component: groupcomm | Resolution: fixed Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From pab@pabigot.com Mon Sep 30 02:10:43 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A78521F8F07 for ; Mon, 30 Sep 2013 02:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwPdf03qiiD4 for ; Mon, 30 Sep 2013 02:10:36 -0700 (PDT) Received: from m1plsmtpa01-06.prod.mesa1.secureserver.net (m1plsmtpa01-06.prod.mesa1.secureserver.net [64.202.165.34]) by ietfa.amsl.com (Postfix) with ESMTP id 9569C21F9C4A for ; Mon, 30 Sep 2013 02:10:27 -0700 (PDT) Received: from [192.168.65.10] ([66.41.60.82]) by m1plsmtpa01-06.prod.mesa1.secureserver.net with id XMAP1m00J1mTNtu01MAQY7; Mon, 30 Sep 2013 02:10:26 -0700 Message-ID: <52494000.8060104@pabigot.com> Date: Mon, 30 Sep 2013 04:10:24 -0500 From: "Peter A. Bigot" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Klaus Hartke References: <5244498E.3050202@pabigot.com> <52450F90.8020202@pabigot.com> <5245880B.2000601@pabigot.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: core Subject: Re: [core] Comments on draft-ietf-core-observe-10 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 09:10:44 -0000 On 09/30/2013 01:07 AM, Klaus Hartke wrote: > Peter A. Bigot wrote: >> Or is this sequence to be conceived as a new message that starts part-way >> through the retransmission process, with transmission parameters not in >> their initial state? > > This. You removed too much context: "This" was the one where the message ID changed for the third and fourth "retransmission", which to me says it's a new message. > >> Excellent. In this case, the message layer is capable of doing this update >> without interacting with higher layers, since it can record when it received >> the message. I expect that, when it does this, it does *not* update any >> other part of the message, including the message ID. True? > > When retransmitting a notification message, all parts of the message > stay the same, including the message ID, except that Max-Age SHOULD And here you say the message ID stays the same. Which is it? > and the Observe sequence number MUST be up-to-date at the time of each > transmission attempt, which may or may not require an update to the > message. If the sequence number is managed by the application and is a one-up counter incremented when the representation changes, then not only the sequence number but also the payload needs to change in order to satisfy this MUST. > > Section 4.4 of observe-10 describes two implementation techniques to > satisfy the 'MUST': one where, in your terms, the sequence numbers are > generated by the message layer. This can be done without communicating > with any higher layer, but requires a change to the message at each > transmission attempt. And one where the sequence numbers are generated > by a higher layer. This requires the higher layer to perform some > bookkeeping, but no changes to the message are required at the message > layer. > >> With the exception of Max-Age, which can be >> handled within the message layer, nothing until now has *required* >> interaction with the higher layers (transaction or application/resource) >> during the process of reliable (re-)transmission by the message layer. > > For supporting observe-10, the message layer should just be able to > inform the higher layer of a client that is gone, and to replace an > ongoing transmission process with a new transmission process that > inherits the current transmission parameters. Both can be implemented > without requiring the message layer to start an interaction with a > higher layer. Yes, but the second is a new expectation placed on layer interactions by observe that is not required by the underlying protocol (CoAP). CoAP base permits (but does not require) an implementation where the upper layer can notify the message layer that it can stop retransmitting a confirmable message (because confirmation of receipt was detected through other means not visible to the message layer). observe is now proposing that implementations allow higher layers to replace the content of an in-progress transmission. You've not made clear the limits of this replacement. Option values can change (this is not new). Message ID may? may not? change (if it does, this is new). Can payload change, as it must if sequence numbers aren't simply clock readings? Can the response code change, as it must if the resource was deleted? Replacing message content isn't necessary if the message layer generates sequence numbers itself, just as it manages Max-Age, but this means the implementation where the sequence number changes in lock-step with resource representation change is no longer conformant and should be removed from section 4.4. > >> Changing the content of the notification because it is out of date is an >> optimization. Is there anything in observe (other than this text) that >> *requires* the server to send the new state immediately? > > Section 1.4 of observe-10 states that one of the goals of the protocol is that > > Clients should see the new state after a state change > as soon as possible [...] > > So it's not merely an optimization that a server tries to get a > representation of the the latest resource state to the client, but the > very purpose of the protocol. I think this is a matter of judgement. observe disallows additional notifications when they would cause the server to violate congestion limitations already imposed on clients, and allows the server to postpone a notification if a new one is expected to occur soon. So there are clearly limits to what "as soon as possible" permits and requires. The consequence of your MUST violates either the association between a message-ID and the message content, or that between the message-ID and the process of transmitting a single confirmable message, or eliminates the second "valid implementation" in section 4.4. The first two would be bad precedent for a protocol extension. The third would add complexity to the message layer. Better to simply accept that sometimes notifications will be out of date, and their information will be updated with a new notification "as soon as possible". Peter From hartke@tzi.org Mon Sep 30 08:14:04 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F01B221F8495 for ; Mon, 30 Sep 2013 08:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUsdWvIC6GX3 for ; Mon, 30 Sep 2013 08:13:59 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id CE8C621F9C7B for ; Mon, 30 Sep 2013 08:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r8UFDr5Z019303 for ; Mon, 30 Sep 2013 17:13:53 +0200 (CEST) Received: from mail-ve0-f171.google.com (mail-ve0-f171.google.com [209.85.128.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id CA8388E6 for ; Mon, 30 Sep 2013 17:13:52 +0200 (CEST) Received: by mail-ve0-f171.google.com with SMTP id pa12so4147586veb.16 for ; Mon, 30 Sep 2013 08:13:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ueBiR8fU/1NNCSZDNMz2aSTqwd1vJL+9t5hcTLmfAn4=; b=bpOiDripfazwpDjGeOmhyMyWmiSrIqYUe/SvaSVI4gzX2EHGZbojHk2/r7Q4f5Snpu uBBTwEmb0ozz8C+g8fTdPKdgsULH/+hUHPIZfjuaPZCQQJf45pDMguChCJIxMYq9N5V4 sqx7xdpo8PoajiHTXFkNrYAmv/QJwJZca759pHJfZ7FqT79PyfdNV2hCM1h1uYCnKaNw izsBdWomS3EckkILNNyypOdX7EQKw8GtvFkBDqKAdPZVzBBevRF/n+DGHq9Uzbo177QQ Fe+2+cX3UqtqbduYZPEzs8EtKEUMQkW19hMPuHKLbgem+l8A5hdIcNQzSvu7RAy/4+W2 gSrA== X-Received: by 10.220.110.6 with SMTP id l6mr46532vcp.28.1380554031406; Mon, 30 Sep 2013 08:13:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.24.83 with HTTP; Mon, 30 Sep 2013 08:13:11 -0700 (PDT) In-Reply-To: <52494000.8060104@pabigot.com> References: <5244498E.3050202@pabigot.com> <52450F90.8020202@pabigot.com> <5245880B.2000601@pabigot.com> <52494000.8060104@pabigot.com> From: Klaus Hartke Date: Mon, 30 Sep 2013 18:13:11 +0300 Message-ID: To: "Peter A. Bigot" Content-Type: text/plain; charset=ISO-8859-1 Cc: core Subject: Re: [core] Comments on draft-ietf-core-observe-10 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 15:14:04 -0000 Peter, draft-ietf-core-coap defines a protocol for request-response interactions. draft-ietf-core-observe defines interactions where one request can yield multiple notifications. This alone makes it clear that -observe is not just an application of -coap, but an extension of the core protocol. Section 4.2 of coap-18 specifies the process for transmitting a separate response. It involves one or more transmission attempts, a retransmission counter and a retransmission timer. The transmitted message does not change between transmission attempts, except for the value of the Max-Age option. Section 4.5 of observe-10 extends this slightly: if a server generates a new notification while the transmission process for a previous notification is still active, then -- to meet the goals of the protocol, the demands of congestion control and the requirement to detect clients that are gone -- the server aborts the transmission process for the old notification (but not before the current transmission attempt completes) and starts a new transmission process for the new notification (but with the retransmission counter and retransmission timer of the aborted process instead of the default values). During each transmission process, the transmitted message does not change between transmission attempts, except for the value of the Max-Age option and potentially the sequence number in the Observe option. I'm not sure what's so difficult about this. Best regards, Klaus On 30 September 2013 12:10, Peter A. Bigot wrote: > On 09/30/2013 01:07 AM, Klaus Hartke wrote: >> >> Peter A. Bigot wrote: >>> >>> Or is this sequence to be conceived as a new message that starts part-way >>> through the retransmission process, with transmission parameters not in >>> their initial state? >> >> >> This. > > > You removed too much context: "This" was the one where the message ID > changed for the third and fourth "retransmission", which to me says it's a > new message. > > >> >>> Excellent. In this case, the message layer is capable of doing this >>> update >>> without interacting with higher layers, since it can record when it >>> received >>> the message. I expect that, when it does this, it does *not* update any >>> other part of the message, including the message ID. True? >> >> >> When retransmitting a notification message, all parts of the message >> stay the same, including the message ID, except that Max-Age SHOULD > > > And here you say the message ID stays the same. > > Which is it? > > >> and the Observe sequence number MUST be up-to-date at the time of each >> transmission attempt, which may or may not require an update to the >> message. > > > If the sequence number is managed by the application and is a one-up counter > incremented when the representation changes, then not only the sequence > number but also the payload needs to change in order to satisfy this MUST. > > >> >> Section 4.4 of observe-10 describes two implementation techniques to >> satisfy the 'MUST': one where, in your terms, the sequence numbers are >> generated by the message layer. This can be done without communicating >> with any higher layer, but requires a change to the message at each >> transmission attempt. And one where the sequence numbers are generated >> by a higher layer. This requires the higher layer to perform some >> bookkeeping, but no changes to the message are required at the message >> layer. >> >>> With the exception of Max-Age, which can be >>> handled within the message layer, nothing until now has *required* >>> interaction with the higher layers (transaction or application/resource) >>> during the process of reliable (re-)transmission by the message layer. >> >> >> For supporting observe-10, the message layer should just be able to >> inform the higher layer of a client that is gone, and to replace an >> ongoing transmission process with a new transmission process that >> inherits the current transmission parameters. Both can be implemented >> without requiring the message layer to start an interaction with a >> higher layer. > > > Yes, but the second is a new expectation placed on layer interactions by > observe that is not required by the underlying protocol (CoAP). > > CoAP base permits (but does not require) an implementation where the upper > layer can notify the message layer that it can stop retransmitting a > confirmable message (because confirmation of receipt was detected through > other means not visible to the message layer). > > observe is now proposing that implementations allow higher layers to replace > the content of an in-progress transmission. You've not made clear the > limits of this replacement. Option values can change (this is not new). > Message ID may? may not? change (if it does, this is new). Can payload > change, as it must if sequence numbers aren't simply clock readings? Can > the response code change, as it must if the resource was deleted? > > Replacing message content isn't necessary if the message layer generates > sequence numbers itself, just as it manages Max-Age, but this means the > implementation where the sequence number changes in lock-step with resource > representation change is no longer conformant and should be removed from > section 4.4. > > >> >>> Changing the content of the notification because it is out of date is an >>> optimization. Is there anything in observe (other than this text) that >>> *requires* the server to send the new state immediately? >> >> >> Section 1.4 of observe-10 states that one of the goals of the protocol is >> that >> >> Clients should see the new state after a state change >> as soon as possible [...] >> >> So it's not merely an optimization that a server tries to get a >> representation of the the latest resource state to the client, but the >> very purpose of the protocol. > > > I think this is a matter of judgement. observe disallows additional > notifications when they would cause the server to violate congestion > limitations already imposed on clients, and allows the server to postpone a > notification if a new one is expected to occur soon. So there are clearly > limits to what "as soon as possible" permits and requires. > > The consequence of your MUST violates either the association between a > message-ID and the message content, or that between the message-ID and the > process of transmitting a single confirmable message, or eliminates the > second "valid implementation" in section 4.4. > > The first two would be bad precedent for a protocol extension. The third > would add complexity to the message layer. Better to simply accept that > sometimes notifications will be out of date, and their information will be > updated with a new notification "as soon as possible". > > Peter > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From pab@pabigot.com Mon Sep 30 09:06:42 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A57521F99B0 for ; Mon, 30 Sep 2013 09:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SORwgSb9C1a0 for ; Mon, 30 Sep 2013 09:06:36 -0700 (PDT) Received: from m1plsmtpa01-02.prod.mesa1.secureserver.net (m1plsmtpa01-02.prod.mesa1.secureserver.net [64.202.165.174]) by ietfa.amsl.com (Postfix) with ESMTP id 008DE21F9048 for ; Mon, 30 Sep 2013 09:06:34 -0700 (PDT) Received: from [192.168.65.10] ([66.41.60.82]) by m1plsmtpa01-02.prod.mesa1.secureserver.net with id XU6X1m0091mTNtu01U6XVN; Mon, 30 Sep 2013 09:06:34 -0700 Message-ID: <5249A188.10200@pabigot.com> Date: Mon, 30 Sep 2013 11:06:32 -0500 From: "Peter A. Bigot" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Klaus Hartke References: <5244498E.3050202@pabigot.com> <52450F90.8020202@pabigot.com> <5245880B.2000601@pabigot.com> <52494000.8060104@pabigot.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: core Subject: Re: [core] Comments on draft-ietf-core-observe-10 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 16:06:42 -0000 On 09/30/2013 10:13 AM, Klaus Hartke wrote: > Peter, > > draft-ietf-core-coap defines a protocol for request-response > interactions. draft-ietf-core-observe defines interactions where one > request can yield multiple notifications. This alone makes it clear > that -observe is not just an application of -coap, but an extension of > the core protocol. > > Section 4.2 of coap-18 specifies the process for transmitting a > separate response. It involves one or more transmission attempts, a > retransmission counter and a retransmission timer. The transmitted > message does not change between transmission attempts, except for the > value of the Max-Age option. I certainly had this immutability expectation; but is there something in coap-18 that requires it, or was it simply assumed with the rather subtle SHOULD down in coap-18 section 5.10.5 permitting a single exception? > > Section 4.5 of observe-10 extends this slightly: if a server generates > a new notification while the transmission process for a previous > notification is still active, then -- to meet the goals of the > protocol, the demands of congestion control and the requirement to > detect clients that are gone -- the server aborts the transmission > process for the old notification (but not before the current > transmission attempt completes) and starts a new transmission process > for the new notification (but with the retransmission counter and > retransmission timer of the aborted process instead of the default > values). During each transmission process, the transmitted message > does not change between transmission attempts, except for the value of > the Max-Age option and potentially the sequence number in the Observe > option. > > I'm not sure what's so difficult about this. Mostly that nothing in the documents told me as clearly as you just did that observe was intending to make such a significant change in an implementer's expectations regarding content changes within or process of a confirmable CoAP transmission. In my opinion, this is not a "slight change" to these concepts. My last comment: please make clear that when the steps in observe 4.5 occur the message ID is (or is not) expected to be one of the things that changes when the new transmission starts with the retransmission state left over from the superseded transmission. That clarity is absolutely lacking in the current draft for anybody who hasn't been actively involved in observe over the last three years. Even after this long exchange I still don't know the answer. Peter From Akbar.Rahman@InterDigital.com Mon Sep 30 10:55:31 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87B9C21F9433 for ; Mon, 30 Sep 2013 10:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, DRUGS_MUSCLE=0.01, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlArTHI7JQ1p for ; Mon, 30 Sep 2013 10:55:27 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0426521F90FD for ; Mon, 30 Sep 2013 10:55:26 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.12]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Sep 2013 13:55:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CEBE06.3DB8B16F" Date: Mon, 30 Sep 2013 13:55:25 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Fw: New Version Notification fordraft-tcs-coap-no-response-option-02.txt Thread-Index: Ac68HMFVPjoFBEpYQv24i3QWIgkZagB6DIKg References: From: "Rahman, Akbar" To: "Abhijan Bhattacharyya" X-OriginalArrivalTime: 30 Sep 2013 17:55:26.0126 (UTC) FILETIME=[3E1974E0:01CEBE06] Cc: Arpan Pal , core@ietf.org Subject: Re: [core] Fw: New Version Notification fordraft-tcs-coap-no-response-option-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 17:55:31 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CEBE06.3DB8B16F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Abhijan, =20 Thank you for the interesting draft. I took a quick look at it and had two comments for now: =20 1) Editorial - You should re-title your draft name to be in the form "draft-Bhattacharyya-core-no-response". If you do not have the word "core" in the draft name then it does not show up on the CORE document page (http://datatracker.ietf.org/wg/core/). =20 2) In your Exemplary scenarios (Section 3) you refer to the use of your proposal for "PUT or POST". I can see how it may work with PUT. But I do not think it makes sense with POST. This is because if your read the base CoAP spec, you will see that a POST typically results in a new URI (resource) created for the data sent with the POST (see http://tools.ietf.org/html/draft-ietf-core-coap-18#section-5.8.2). So I cannot easily envision sending a POST with a "No-Response" header. That is, then the client would never know the URI that it caused to be created by the POST, and therefore is not logical. Am I missing something? =20 =20 Akbar =20 =20 =20 From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Abhijan Bhattacharyya Sent: Saturday, September 28, 2013 3:30 AM To: core@ietf.org Cc: Soma Bandyopadhyay; Arpan Pal Subject: [core] Fw: New Version Notification fordraft-tcs-coap-no-response-option-02.txt =20 Hi all, We have submitted a new draft on the No-Resp option. This draft contains significant changes than the previous versions. Thanks to the comments from Carsten, Esko and Bert. This draft incorporates few user scenarios before discussing the technical details. The user scenarios are described in the light of how application of this option might benefit resource constrained environments. Taking clue from the comments we received, this draft enhances this option to allow 'optional' granularity so that one can choose to suppress a particular class or a combination of classes of responses. =20 Please share your comments.=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 ____________________________________________ -----Forwarded by Abhijan Bhattacharyya/KOL/TCS on 09/28/2013 12:49PM ----- To: Abhijan Bhattacharyya , Soma Bandyopadhyay , Arpan Pal From: internet-drafts@ietf.org Date: 09/28/2013 12:48PM Subject: New Version Notification for draft-tcs-coap-no-response-option-02.txt A new version of I-D, draft-tcs-coap-no-response-option-02.txt has been successfully submitted by Abhijan Bhattacharyya and posted to the IETF repository. Filename: draft-tcs-coap-no-response-option Revision: 02 Title: CoAP option for no server-response Creation date: 2013-09-28 Group: Individual Submission Number of pages: 12 URL: http://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-option-02 .txt Status: http://datatracker.ietf.org/doc/draft-tcs-coap-no-response-option Htmlized: http://tools.ietf.org/html/draft-tcs-coap-no-response-option-02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-tcs-coap-no-response-option-02 Abstract: There can be typical M2M scenarios where responses from the data sink to the data source against request/ notification from the source might be considered redundant. This kind of open-loop exchange (with no reverse path from the sink to the source) may be desired while updating resources or notifying about the updated status of a resource in constrained systems looking for maximized throughput with minimized resource consumption. CoAP already provides a non-confirmable (NON) mode of exchange where The receiving end-point does not respond with ACK. However, the receiving end-point responds the sender with a status code indicating "the result of the attempt to understand and satisfy the request". This draft introduces a header option: 'No-Resp' to suppress responses from the receiver and discusses exemplary use cases which motivated this proposition based on real experience. This option also provides granularity by allowing suppression of a particular class or a combination of classes of responses. This option is applicable for both request/ response as well as resource-observe mode and may be effective for both unicast and multicast scenarios. =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. The IETF Secretariat =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 ------_=_NextPart_001_01CEBE06.3DB8B16F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Abhijan,

 

Thank you for the interesting draft.  I took a quick look at it = and had two comments for now:

 

1)      = Editorial - You should re-title your draft name to be in the form = “draft-Bhattacharyya-core-no-response”.  If you do not = have the word “core” in the draft name then it does not show = up on the CORE document page (http://datatracker.ietf.org= /wg/core/).

 

2)      = In your Exemplary scenarios (Section 3) you refer to the use of  = your proposal for “PUT or POST”.  I can see how it may = work with PUT.  But I do not think it makes sense with POST.  = This is because if your read the base CoAP spec, you will see that a = POST typically results in a new URI (resource) created for the data sent = with the POST (see http://tools.ietf.org/html/draft-ietf-core-coap-18#section-5.8.2).&n= bsp; So I cannot easily envision sending a POST with a = “No-Response” header.   That is, then the client = would never know the URI that it caused to be created by the POST, and = therefore is not logical.  Am I missing = something?

 

 

Akbar

 

 

 

From:= = core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = Abhijan Bhattacharyya
Sent: Saturday, September 28, 2013 = 3:30 AM
To: core@ietf.org
Cc: Soma Bandyopadhyay; = Arpan Pal
Subject: [core] Fw: New Version Notification = fordraft-tcs-coap-no-response-option-02.txt

 

Hi = all,

We have = submitted a new draft on the No-Resp option. This draft contains = significant changes than the previous versions. Thanks to the comments = from Carsten, Esko and Bert. This draft incorporates few user scenarios = before discussing the technical details. The user scenarios are = described in the light of how application of this option might benefit = resource constrained environments. Taking clue from the comments we = received, this draft enhances this option to allow 'optional' = granularity so that one can choose to suppress a particular class or a = combination of classes of responses.

 =

Please = share your comments. 


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



-----Forwarded by Abhijan = Bhattacharyya/KOL/TCS on 09/28/2013 12:49PM = -----

To: = Abhijan Bhattacharyya <abhijan.bhattacharyya@tcs.c= om>, Soma Bandyopadhyay <soma.bandyopadhyay@tcs.com= >, Arpan Pal <arpan.pal@tcs.com>
From: internet-drafts@ietf.org
= Date: 09/28/2013 12:48PM
Subject: New Version Notification for = draft-tcs-coap-no-response-option-02.txt

A new version of I-D, = draft-tcs-coap-no-response-option-02.txt
has been successfully = submitted by Abhijan Bhattacharyya and posted to the
IETF = repository.

Filename: = draft-tcs-coap-no-response-option
Revision: 02
Title: CoAP option = for no server-response
Creation date: 2013-09-28
Group: Individual = Submission
Number of pages: 12
URL:         =     http://www.ietf.org/internet-drafts/draft-tcs-coap-no-respon= se-option-02.txt
Status:          http://datatracker.ietf.org/doc/draft-tcs-coap-no-response-optionHtmlized:        = http://tools.ietf.org/html/draft-tcs-coap-no-response-option-02
Di= ff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-tcs-coap-no-response-opt= ion-02

Abstract:
   There can be typical M2M = scenarios where responses from the data
   sink to the data = source against request/ notification from the
   source = might be considered redundant. This kind of open-loop
   = exchange (with no reverse path from the sink to the source) may = be
   desired while updating resources or notifying about = the updated
   status of a resource in constrained systems = looking for maximized
   throughput with minimized resource = consumption. CoAP already
   provides a non-confirmable = (NON) mode of exchange where The
   receiving end-point = does not respond with ACK. However, the
   receiving = end-point responds the sender with a status code
   = indicating "the result of the attempt to understand and satisfy = the
   request".

   This draft = introduces a header option: 'No-Resp' to suppress
   = responses from the receiver and discusses exemplary use cases = which
   motivated this proposition based on real = experience. This option
   also provides granularity by = allowing suppression of a particular
   class or a = combination of classes of responses. This option is
   = applicable for both request/ response as well as = resource-observe
   mode and may be effective for both = unicast and multicast scenarios.

       =                     =                     =                     =               =  


Please note that it may take a couple of minutes from = the time of submission
until the htmlized version and diff are = available at tools.ietf.org.

The IETF Secretariat=

=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

------_=_NextPart_001_01CEBE06.3DB8B16F-- From cabo@tzi.org Mon Sep 30 11:10:05 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F14521F8E70 for ; Mon, 30 Sep 2013 11:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.184 X-Spam-Level: X-Spam-Status: No, score=-106.184 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GVOZ0-y3PRT for ; Mon, 30 Sep 2013 11:10:00 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 7B48F21F8EA8 for ; Mon, 30 Sep 2013 11:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r8UI9tDs012582; Mon, 30 Sep 2013 20:09:55 +0200 (CEST) Received: from [192.168.217.105] (p54890DAD.dip0.t-ipconnect.de [84.137.13.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 3965A9B7; Mon, 30 Sep 2013 20:09:55 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: Date: Mon, 30 Sep 2013 20:09:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Rahman, Akbar" X-Mailer: Apple Mail (2.1510) Cc: Abhijan Bhattacharyya , Arpan Pal , core@ietf.org Subject: Re: [core] Fw: New Version Notification fordraft-tcs-coap-no-response-option-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 18:10:05 -0000 > 1) Editorial - You should re-title your draft name to be in the = form =93draft-Bhattacharyya-core-no-response=94. If you do not have the = word =93core=94 in the draft name then it does not show up on the CORE = document page (http://datatracker.ietf.org/wg/core/). While using the WG name as the third word in the draft name is always a = good idea, in this case at least the tools page for CoRE, = http://tools.ietf.org/wg/core/, does show the draft. (I made special arrangements a while ago to have documents with "coap" = in the name show up there.) Changing the name always causes some confusion. > 2) In your Exemplary scenarios (Section 3) you refer to the use = of your proposal for =93PUT or POST=94. I can see how it may work with = PUT. But I do not think it makes sense with POST. This is because if = your read the base CoAP spec, you will see that a POST typically results = in a new URI (resource) created for the data sent with the POST = (seehttp://tools.ietf.org/html/draft-ietf-core-coap-18#section-5.8.2). = So I cannot easily envision sending a POST with a =93No-Response=94 = header. That is, then the client would never know the URI that it = caused to be created by the POST, and therefore is not logical. Am I = missing something? Indeed, without a response the client would not know the URI selected by = the server for the new resource created. There may still be applications where this is acceptable, e.g. if no = further client access is required, or if the new resources are later = picked up by a different client that finds them using a collection = resource. The draft probably should give an example for this. One other comment I have is that the option uses uint in a way that is = sensitive to the length. It would be much better if the zero-byte version and any one-byte = version of a zero had the same semantics. To do this, the bits set (1/2/4 for 2.xx, 4.xx, 5.xx) could be defined = to re-enable, not suppress, the response. More generally speaking, I have a bit of trouble imagining how a client = implementation would handle a response in one of these cases, as it no = longer knows whether a response is to be expected and when it can stop = expecting one (which also means the token can be re-used for another = request). Gr=FC=DFe, Carsten From Akbar.Rahman@InterDigital.com Mon Sep 30 11:54:58 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF08921F9983 for ; Mon, 30 Sep 2013 11:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LC2VEWwztjx for ; Mon, 30 Sep 2013 11:54:53 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7733321F958A for ; Mon, 30 Sep 2013 11:54:53 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.12]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Sep 2013 14:54:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Sep 2013 14:54:51 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Fw: New Version Notification fordraft-tcs-coap-no-response-option-02.txt Thread-Index: Ac6+CFrp/dGvRknoTF+3Zh3i32TqMAABW8Iw References: From: "Rahman, Akbar" To: "Carsten Bormann" X-OriginalArrivalTime: 30 Sep 2013 18:54:52.0806 (UTC) FILETIME=[8C01A260:01CEBE0E] Cc: Abhijan Bhattacharyya , Arpan Pal , core@ietf.org Subject: Re: [core] Fw: New Version Notification fordraft-tcs-coap-no-response-option-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 18:54:59 -0000 > There may still be applications where this is acceptable, e.g. if no further client access is required, or if the new resources are later picked up by a different client that finds them using a collection resource. The draft probably should give an example for this. Yes, I agree this is possible. I just got an impression from the existing I-D examples that the "No Response" feature was mostly targeted towards high frequency updates (i.e. PUT) for which a response was not required (to reduce congestion, reduce BW usage, etc). But perhaps a new class of examples showing how this would benefit POST can change this perception.