From Bert.Greevenbosch@huawei.com Sun Dec 1 17:15:17 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C431AE2C7 for ; Sun, 1 Dec 2013 17:15:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4X4XlTzdrrf for ; Sun, 1 Dec 2013 17:15:14 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 432321AE2A7 for ; Sun, 1 Dec 2013 17:15:13 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYN09764; Mon, 02 Dec 2013 01:15:10 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Dec 2013 01:14:29 +0000 Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Dec 2013 01:15:09 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.164]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Mon, 2 Dec 2013 09:15:06 +0800 From: Bert Greevenbosch To: "Dijk, Esko" , weigengyu , Carsten Bormann Thread-Topic: [core] How to correlate request and responses in group communication Thread-Index: AQHO7Oiz+A3LWPVfgEqJHOHgP4iyl5pAFpOQ Date: Mon, 2 Dec 2013 01:15:04 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63E3AEFD5@SZXEMA510-MBX.china.huawei.com> References: <34966E97BE8AD64EAE9D3D6E4DEE36F252ABFCC5@SZXEMA501-MBS.china.huawei.com> <031DD135F9160444ABBE3B0C36CED6180CC4102C@011-DB3MPN2-082.MGDPHG.emi.philips.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252ABFFA4@SZXEMA501-MBS.china.huawei.com> <031DD135F9160444ABBE3B0C36CED6180CC422AA@011-DB3MPN2-082.MGDPHG.emi.philips.com> <72478E14D297435C8430474E749919F7@WeiGengyuPC> <031DD135F9160444ABBE3B0C36CED6180CC43638@011-DB3MPN2-082.MGDPHG.emi.philips.com> <2E5E0631-C787-47AA-90F4-9ECA6A205B56@tzi.org> <031DD135F9160444ABBE3B0C36CED6180CC439B1@011-DB3MPN2-082.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED6180CC439B1@011-DB3MPN2-082.MGDPHG.emi.philips.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.162.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "core@ietf.org" Subject: Re: [core] How to correlate request and responses in group communication X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 01:15:17 -0000 Concerning the two option solutions "Location-Host" and re-use of "Uri-Host= ": do we care that the "Uri-*" options are critical, whereas the "Location-= *" options are not? It seems that an elective option might be more appropri= ate, especially given that non-supporting devices may be interested in send= ing multicast requests (esp. PUTs and POSTs) without being interested in th= e responses. When would such a "?-Host" option be included in the response? Does the res= ponder need to inspect the UDP layer to indicate that the request is a mult= icast request? Then for this we are also mixing the layers. Just some thoughts about this... > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Dijk, Esko > Sent: 29 November 2013 17:52 > To: weigengyu; Carsten Bormann > Cc: core@ietf.org > Subject: Re: [core] How to correlate request and responses in group > communication >=20 > If I understand correctly, the proposed idea is to use the Location-* > Options in a response to indicate the identity/source of a response. In > a response to a multicast, the identity/source of a response is not > visible at the CoAP layer. (Only below it, in the UDP layer.) >=20 > However, there is no "Location-Host" option defined, only the relative > Location-Path and Location-Query options. So this would not help in > identifying the source of the response! Unless we define an option > like "Location-Host". >=20 > Perhaps a better solution is to allow the existing "Uri-Host" option in > a response (optionally) to identify the source of the response. This is > quite close to the current meaning of Uri-Host, but then applied to a > CoAP response situation. The contents of Uri-Host may be an IP literal > or a hostname (which I assume to be the most stable identifier). In > terms of standardization, this looks like an easy thing to add, but > there could be impact on implementations. >=20 > Any thoughts - do we need server identification as a standardized CoAP > Option? Are there any transports other than UDP/TCP - that allow > multicast - but somehow don't provide the source IP address of the > response in the layer below COAP? >=20 > Esko >=20 > -----Original Message----- > From: weigengyu [mailto:weigengyu@bupt.edu.cn] > Sent: Friday, November 29, 2013 05:04 > To: Carsten Bormann > Cc: Dijk, Esko; core@ietf.org > Subject: Re: [core] How to correlate request and responses in group > communication >=20 > Hi Carsten, >=20 > Thank you for your explanations. > > I'm not sure I understand what you are trying to achieve with this > set > > of options. > I would like to use the CoAP already defined mechanisms to resolve > umbiguity locations. > Using CoAP-defined mechanisms is better than leaving it to applications. >=20 > The CoAP -18 gives descriptions about Location options are used by POST. > And in CoAP -18 "5.10.6 ETag" is defined as a request option and a > response option, and ETag may contain Location Options. > In "5.10.6.1. ETag as a Response Option, > If one or more Location-* options are present and thus a location > URI is indicated (Section 5.10.7), the tagged > representation is the representation that would be retrieved by a > GET request to the location URI. > In CoAP -18 6. CoAP URIs > CoAP uses the "coap" and "coaps" URI schemes for identifying CoAP > resources and providing a means of locating the resource. > Based on above texts, I see that the URI from Location options could be > used "by a GET request to the location URI." >=20 > Current CoAP -18 has not given descriptions whether the GET is > prohibited from Location options. > So, GET request could use the URI, or Etag, or Location options. > Then the responese(s) might use URI, or Etag, or Location options even > though caches are existed. >=20 > When Location option(s) is in GET, the client can use the standard > means to see the different responses from multiple locations. > I believe this CoAP Location facility could be beneficial to a number > of location-based applicatons. >=20 >=20 > Regards, >=20 > Gengyu >=20 > Network Technology Center > School of Computer > Beijing University of Posts & Telecommunications >=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. >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From internet-drafts@ietf.org Mon Dec 2 11:32:38 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4270A1ADBFF; Mon, 2 Dec 2013 11:32:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lg8HVVYCG69; Mon, 2 Dec 2013 11:32:36 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A88C71ADDD3; Mon, 2 Dec 2013 11:32:33 -0800 (PST) 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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131202193233.18226.97273.idtracker@ietfa.amsl.com> Date: Mon, 02 Dec 2013 11:32:33 -0800 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-links-json-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 19:32:38 -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 : Representing CoRE Link Collections in JSON Author(s) : Carsten Bormann Filename : draft-ietf-core-links-json-01.txt Pages : 6 Date : 2013-12-02 Abstract: Web Linking (RFC5988) provides a way to represent links between Web resources as well as the relations expressed by them and attributes of such a link. In constrained networks, a collection of Web links can be exchanged in the CoRE link format (RFC6690). Outside of constrained environments, it may be useful to represent these collections of Web links in JSON format (RFC4627). This specification defines a common format for representing Web links in JSON format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-links-json There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-links-json-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-links-json-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From cabo@tzi.org Mon Dec 2 11:36:21 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 100561AD8F3 for ; Mon, 2 Dec 2013 11:36:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhO21lznCmTX for ; Mon, 2 Dec 2013 11:36:19 -0800 (PST) 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 955411AD68D for ; Mon, 2 Dec 2013 11:36:19 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rB2JaAdZ010215 for ; Mon, 2 Dec 2013 20:36:10 +0100 (CET) Received: from [192.168.217.105] (p548932CA.dip0.t-ipconnect.de [84.137.50.202]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 11C07899; Mon, 2 Dec 2013 20:36:09 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Carsten Bormann In-Reply-To: <20131202193233.18226.97273.idtracker@ietfa.amsl.com> Date: Mon, 2 Dec 2013 20:36:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0B07D56C-D9E5-436F-BE94-FCEC0824B3DC@tzi.org> References: <20131202193233.18226.97273.idtracker@ietfa.amsl.com> To: "core (core@ietf.org)" X-Mailer: Apple Mail (2.1822) Subject: Re: [core] I-D Action: draft-ietf-core-links-json-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 19:36:21 -0000 This is a resubmit to avoid expiration of the draft, with a reference = update and a small editorial fix. (We said we were waiting for some more implementation experience before = advancing this.) Gr=FC=DFe, Carsten > Title : Representing CoRE Link Collections in JSON > Author(s) : Carsten Bormann > Filename : draft-ietf-core-links-json-01.txt > Pages : 6 > Date : 2013-12-02 >=20 > Abstract: > Web Linking (RFC5988) provides a way to represent links between Web > resources as well as the relations expressed by them and attributes > of such a link. In constrained networks, a collection of Web links > can be exchanged in the CoRE link format (RFC6690). Outside of > constrained environments, it may be useful to represent these > collections of Web links in JSON format (RFC4627). >=20 > This specification defines a common format for representing Web = links > in JSON format. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-core-links-json >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-core-links-json-01 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-links-json-01 From likepeng@huawei.com Tue Dec 3 23:33:06 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0981AE057 for ; Tue, 3 Dec 2013 23:33:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ab0_MSFo9jRc for ; Tue, 3 Dec 2013 23:33:03 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 766B31ADF47 for ; Tue, 3 Dec 2013 23:33:03 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAZ56546; Wed, 04 Dec 2013 07:32:59 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Dec 2013 07:32:06 +0000 Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Dec 2013 07:32:57 +0000 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.45]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Wed, 4 Dec 2013 15:32:50 +0800 From: Likepeng To: "core@ietf.org" Thread-Topic: New Version Notification for draft-li-core-coap-patience-option-03.txt Thread-Index: AQHO8MKVE2LvlE6lMEGU5KOafw0lCZpDo97w Date: Wed, 4 Dec 2013 07:32:50 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F252AC2D66@SZXEMA501-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.167.122] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [core] Fw: New Version Notification for draft-li-core-coap-patience-option-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 07:33:06 -0000 SGVsbG8gYWxsLA0KDQpUaGlzIGRyYWZ0IGlzIHJlbGF0ZWQgdG8gdGhlIHJlY2VudCBkaXNjdXNz aW9uIGFib3V0IENvQVAgJ2luZmluaXRlIHRpbWVvdXQnIHVzZSBjYXNlLg0KDQpIb3BlIHlvdSBj YW4gZmluZCBzb21lIHRpbWUgdG8gcmV2aWV3IGl0IGFuZCBnaXZlIHVzIGZlZWRiYWNrLg0KDQpU aGFua3MsDQpLaW5kIFJlZ2FyZHMNCktlcGVuZw0KDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrl j5Hku7bkuro6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZ10gDQrlj5HpgIHml7bpl7Q6IDIwMTPlubQxMuaciDTml6UgMTU6MjkNCuaUtuS7 tuS6ujogTGlrZXBlbmc7IEJlcnQgR3JlZXZlbmJvc2NoOyBTYWx2YXRvcmUgTG9yZXRvOyBTYWx2 YXRvcmUgTG9yZXRvOyBFc2tvIERpamsNCuS4u+mimDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u IGZvciBkcmFmdC1saS1jb3JlLWNvYXAtcGF0aWVuY2Utb3B0aW9uLTAzLnR4dA0KDQoNCkEgbmV3 IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1saS1jb3JlLWNvYXAtcGF0aWVuY2Utb3B0aW9uLTAzLnR4 dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBLZXBlbmcgTGkgYW5kIHBvc3Rl ZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LWxpLWNvcmUtY29h cC1wYXRpZW5jZS1vcHRpb24NClJldmlzaW9uOgkgMDMNClRpdGxlOgkJIENvQVAgT3B0aW9uIEV4 dGVuc2lvbjogUGF0aWVuY2UNCkNyZWF0aW9uIGRhdGU6CSAyMDEzLTEyLTA0DQpHcm91cDoJCSBJ bmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMTANClVSTDogICAgICAgICAg ICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbGktY29yZS1jb2Fw LXBhdGllbmNlLW9wdGlvbi0wMy50eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1saS1jb3JlLWNvYXAtcGF0aWVuY2Utb3B0aW9uDQpIdG1s aXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxpLWNvcmUtY29h cC1wYXRpZW5jZS1vcHRpb24tMDMNCkRpZmY6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9y Zy9yZmNkaWZmP3VybDI9ZHJhZnQtbGktY29yZS1jb2FwLXBhdGllbmNlLW9wdGlvbi0wMw0KDQpB YnN0cmFjdDoNCiAgIENvQVAgaXMgYSBSRVNUZnVsIGFwcGxpY2F0aW9uIHByb3RvY29sIGZvciBj b25zdHJhaW5lZCBub2RlcyBhbmQNCiAgIG5ldHdvcmtzLiAgVGhpcyBzcGVjaWZpY2F0aW9uIHBy b3ZpZGVzIGEgc2ltcGxlIGV4dGVuc2lvbiBmb3IgQ29BUCwNCiAgIHRoZSBQYXRpZW5jZSBvcHRp b24uICBUaGlzIG9wdGlvbiBpbmZvcm1zIGEgcmVjaXBpZW50IG9mIHRoZQ0KICAgcHJlZmVycmVk IHRpbWUgZnJhbWUgZm9yIGEgcmVxdWVzdCBvciByZXNwb25zZSBkZXBlbmRpbmcgb24gdXNhZ2UN CiAgIGNvbnRleHQuICBJbiBhIHVuaWNhc3QgcmVxdWVzdCwgaXQgaW5kaWNhdGVzIHRoZSBwYXRp ZW5jZSBhIGNsaWVudA0KICAgaGFzIGluIHdhaXRpbmcgZm9yIGEgcmVzcG9uc2UuICBUaGUgQ29B UCBzZXJ2ZXIgdHJpZXMgdG8gcmV0dXJuIHRoZQ0KICAgcmVzcG9uc2Ugd2l0aGluIHRoZSBzcGVj aWZpZWQgdGltZSBmcmFtZS4gIEluIGEgbXVsdGljYXN0IHJlcXVlc3QsIGl0DQogICBpbmRpY2F0 ZXMgdGhlIHBhdGllbmNlIGEgc2VydmVyIHNob3VsZCBoYXZlIGluIHNlbmRpbmcgaXRzIHJlc3Bv bnNlLg0KICAgVGhlIHJlY2lwaWVudCB3b3VsZCB0aGVuIHRyeSB0byByYW5kb21seSBkZWxheSBp dHMgcmVzcG9uc2Ugd2l0aGluDQogICB0aGUgdGltZSBmcmFtZSB0aGF0IHRoZSByZXF1ZXN0ZXIg aW5kaWNhdGVkIG9yIGNvbXB1dGVkIGJ5IHRoZQ0KICAgcmVjaXBpZW50IGl0c2VsZi4gIEluIGEg Q29BUCBvYnNlcnZlIG5vdGlmaWNhdGlvbiwgaXQgaW5kaWNhdGVzIHRoZQ0KICAgcGF0aWVuY2Ug YW4gb2JzZXJ2ZXIgc2hvdWxkIGhhdmUgaW4gYm90aCB3YWl0aW5nIGZvciBhIHN1YnNlcXVlbnQN CiAgIG5vdGlmaWNhdGlvbiBhbmQgaW4gcmUtZXN0YWJsaXNoaW5nIGFuIG9ic2VydmF0aW9uIHJl bGF0aW9uLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlz c2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0 IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From esko.dijk@philips.com Wed Dec 4 03:28:55 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4586B1AE0F9 for ; Wed, 4 Dec 2013 03:28:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVsTSdvSQ92v for ; Wed, 4 Dec 2013 03:28:52 -0800 (PST) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0189.outbound.messaging.microsoft.com [213.199.154.189]) by ietfa.amsl.com (Postfix) with ESMTP id 6DAD11AE0FA for ; Wed, 4 Dec 2013 03:28:52 -0800 (PST) Received: from mail179-db8-R.bigfish.com (10.174.8.240) by DB8EHSOBE015.bigfish.com (10.174.4.78) with Microsoft SMTP Server id 14.1.225.22; Wed, 4 Dec 2013 11:28:48 +0000 Received: from mail179-db8 (localhost [127.0.0.1]) by mail179-db8-R.bigfish.com (Postfix) with ESMTP id C877F4C09EE; Wed, 4 Dec 2013 11:28:48 +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: -27 X-BigFish: VPS-27(z579ehz217bI15d6O542I9251Idd85kzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzd9hz1de098h1033IL8275dh1de097hz2dh109h2a8h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh2222h224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h1155h) Received: from mail179-db8 (localhost.localdomain [127.0.0.1]) by mail179-db8 (MessageSwitch) id 1386156525447671_18444; Wed, 4 Dec 2013 11:28:45 +0000 (UTC) Received: from DB8EHSMHS031.bigfish.com (unknown [10.174.8.246]) by mail179-db8.bigfish.com (Postfix) with ESMTP id 5E1A3A80040; Wed, 4 Dec 2013 11:28:45 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by DB8EHSMHS031.bigfish.com (10.174.4.41) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 4 Dec 2013 11:28:45 +0000 Received: from 011-DB3MMR1-020.MGDPHG.emi.philips.com (10.128.28.101) by 011-DB3MMR1-001.MGDPHG.emi.philips.com (10.128.28.51) with Microsoft SMTP Server (TLS) id 14.3.158.2; Wed, 4 Dec 2013 11:28:44 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.40]) by 011-DB3MMR1-020.MGDPHG.emi.philips.com ([fe80::65e7:4d4c:4c67:daa9%11]) with mapi id 14.03.0158.002; Wed, 4 Dec 2013 11:28:44 +0000 From: "Dijk, Esko" To: Bert Greevenbosch , weigengyu , Carsten Bormann Thread-Topic: [core] How to correlate request and responses in group communication Thread-Index: Ac7rG1cGT4fNhozCS7KwdPTKZ1kSxwAIgb/gAAIa26AADwLsQAAmFA0AAABYPeAAA6/RAAAHIpYAABxKaYAAC3jlIACFhEMAAHnWFrA= Date: Wed, 4 Dec 2013 11:28:43 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED6180CC454F2@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <34966E97BE8AD64EAE9D3D6E4DEE36F252ABFCC5@SZXEMA501-MBS.china.huawei.com> <031DD135F9160444ABBE3B0C36CED6180CC4102C@011-DB3MPN2-082.MGDPHG.emi.philips.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252ABFFA4@SZXEMA501-MBS.china.huawei.com> <031DD135F9160444ABBE3B0C36CED6180CC422AA@011-DB3MPN2-082.MGDPHG.emi.philips.com> <72478E14D297435C8430474E749919F7@WeiGengyuPC> <031DD135F9160444ABBE3B0C36CED6180CC43638@011-DB3MPN2-082.MGDPHG.emi.philips.com> <2E5E0631-C787-47AA-90F4-9ECA6A205B56@tzi.org> <031DD135F9160444ABBE3B0C36CED6180CC439B1@011-DB3MPN2-082.MGDPHG.emi.philips.com> <46A1DF3F04371240B504290A071B4DB63E3AEFD5@SZXEMA510-MBX.china.huawei.com> In-Reply-To: <46A1DF3F04371240B504290A071B4DB63E3AEFD5@SZXEMA510-MBX.china.huawei.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.138.225.97] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "core@ietf.org" Subject: Re: [core] How to correlate request and responses in group communication X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 11:28:55 -0000 > It seems that an elective option might be more appropriate, Fully agree, that would be more appropriate. In terms of its semantics thou= gh, the Uri-Host Option still is a better fit than Location-Host. So a new = type of option similar to Uri-Host would be needed to get the best solution= . > Does the responder need to inspect the UDP layer to indicate that the req= uest is a multicast request? Yes, it's certainly assumed that the server at CoAP layer is aware of this = fact. Hence all the rules about being allowed (or even, advised) to ignore = certain multicast requests for security/congestion reasons. "Cross-layer op= timization" is at the heart of 6LoWPAN's design and also CoAP's, if you ask= me. Esko -----Original Message----- From: Bert Greevenbosch [mailto:Bert.Greevenbosch@huawei.com] Sent: Monday, December 02, 2013 02:15 To: Dijk, Esko; weigengyu; Carsten Bormann Cc: core@ietf.org Subject: RE: [core] How to correlate request and responses in group communi= cation Concerning the two option solutions "Location-Host" and re-use of "Uri-Host= ": do we care that the "Uri-*" options are critical, whereas the "Location-= *" options are not? It seems that an elective option might be more appropri= ate, especially given that non-supporting devices may be interested in send= ing multicast requests (esp. PUTs and POSTs) without being interested in th= e responses. When would such a "?-Host" option be included in the response? Does the res= ponder need to inspect the UDP layer to indicate that the request is a mult= icast request? Then for this we are also mixing the layers. Just some thoughts about this... ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From weigengyu@bupt.edu.cn Wed Dec 4 07:24:13 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2D41AE2A8 for ; Wed, 4 Dec 2013 07:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.063 X-Spam-Level: X-Spam-Status: No, score=-0.063 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R664CzyQkVNy for ; Wed, 4 Dec 2013 07:24:10 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5F31AE2A3 for ; Wed, 4 Dec 2013 07:24:08 -0800 (PST) Received: from WeiGengyuPC (unknown [222.131.10.0]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 4532B19F36A; Wed, 4 Dec 2013 23:24:01 +0800 (HKT) Message-ID: <7D43817BD4C04B22B8CF3000F2A5BE64@WeiGengyuPC> From: "weigengyu" To: "Likepeng" References: <34966E97BE8AD64EAE9D3D6E4DEE36F252AC2D66@SZXEMA501-MBS.china.huawei.com> In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F252AC2D66@SZXEMA501-MBS.china.huawei.com> Date: Wed, 4 Dec 2013 10:24:03 -0500 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3505.912 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912 Cc: core@ietf.org Subject: Re: [core] Fw: New Version Notification for draft-li-core-coap-patience-option-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 15:24:13 -0000 Hi Kepeng, After reading through the draft, I have a question. By the Patience option the recipient of the message knows the Patience time of the requster and calculates the Leisure time. The recipient should consider the RTT (round trip time ) between requester and recipient when doing calculation. In order to facilitate the recipient's calculation, the requester could put a timestamp in the message. The recipient would have the half transmission delays, and used as reference of the half of RTT. Based on above description, the Leisure time equals to the Patience time - RTT. I believe that the RTT needs to take care when the order of RTT and Patience time are near. Maybe RTT calculation requires the same algorithms as TCP RTT calculation. Regards, Gengyu Network Technology Center School of Computer Beijing University of Posts & Telecommunications -----原始邮件----- From: Likepeng Sent: Wednesday, December 04, 2013 2:32 AM To: core@ietf.org Subject: [core] Fw: New Version Notification for draft-li-core-coap-patience-option-03.txt Hello all, This draft is related to the recent discussion about CoAP 'infinite timeout' use case. Hope you can find some time to review it and give us feedback. Thanks, Kind Regards Kepeng -----邮件原件----- 发件人: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 发送时间: 2013年12月4日 15:29 收件人: Likepeng; Bert Greevenbosch; Salvatore Loreto; Salvatore Loreto; Esko Dijk 主题: New Version Notification for draft-li-core-coap-patience-option-03.txt A new version of I-D, draft-li-core-coap-patience-option-03.txt has been successfully submitted by Kepeng Li and posted to the IETF repository. Filename: draft-li-core-coap-patience-option Revision: 03 Title: CoAP Option Extension: Patience Creation date: 2013-12-04 Group: Individual Submission Number of pages: 10 URL: http://www.ietf.org/internet-drafts/draft-li-core-coap-patience-option-03.txt Status: http://datatracker.ietf.org/doc/draft-li-core-coap-patience-option Htmlized: http://tools.ietf.org/html/draft-li-core-coap-patience-option-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-li-core-coap-patience-option-03 Abstract: CoAP is a RESTful application protocol for constrained nodes and networks. This specification provides a simple extension for CoAP, the Patience option. This option informs a recipient of the preferred time frame for a request or response depending on usage context. In a unicast request, it indicates the patience a client has in waiting for a response. The CoAP server tries to return the response within the specified time frame. In a multicast request, it indicates the patience a server should have in sending its response. The recipient would then try to randomly delay its response within the time frame that the requester indicated or computed by the recipient itself. In a CoAP observe notification, it indicates the patience an observer should have in both waiting for a subsequent notification and in re-establishing an observation relation. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From carlesgo@entel.upc.edu Wed Dec 4 07:54:26 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 385C31AE2B9 for ; Wed, 4 Dec 2013 07:54:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fn-uw5O47z7b for ; Wed, 4 Dec 2013 07:54:22 -0800 (PST) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by ietfa.amsl.com (Postfix) with ESMTP id AD8F51AE05E for ; Wed, 4 Dec 2013 07:54:21 -0800 (PST) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id rB4Fs5hN030505; Wed, 4 Dec 2013 16:54:06 +0100 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id E667A2CBD0E; Wed, 4 Dec 2013 16:54:04 +0100 (CET) Received: from 95.120.62.102 by webmail.entel.upc.edu with HTTP; Wed, 4 Dec 2013 16:54:05 +0100 Message-ID: <65e092d52cef43d42aa6cfc215405749.squirrel@webmail.entel.upc.edu> In-Reply-To: <7D43817BD4C04B22B8CF3000F2A5BE64@WeiGengyuPC> References: <34966E97BE8AD64EAE9D3D6E4DEE36F252AC2D66@SZXEMA501-MBS.china.huawei.com> <7D43817BD4C04B22B8CF3000F2A5BE64@WeiGengyuPC> Date: Wed, 4 Dec 2013 16:54:05 +0100 From: "Carles Gomez Montenegro" To: "weigengyu" User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: ACL matched, not delayed by milter-greylist-4.4.3 (violet.upc.es [147.83.2.51]); Wed, 04 Dec 2013 16:54:06 +0100 (CET) Cc: core@ietf.org Subject: Re: [core] Fw: New Version Notification for draft-li-core-coap-patience-option-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 15:54:26 -0000 Hi Gengyu, > Maybe RTT calculation requires the same algorithms as TCP RTT calculation. draft-bormann-core-cocoa proposes RTO/RTT estimation mechanisms for CoAP. These mechanisms are partially based on the RFC 6298 algorithm. Best regards, Carles > Hi Kepeng, > > After reading through the draft, I have a question. > > By the Patience option the recipient of the message knows the Patience > time > of the requster and calculates the Leisure time. > The recipient should consider the RTT (round trip time ) between > requester > and recipient when doing calculation. > > In order to facilitate the recipient's calculation, the requester could > put > a timestamp in the message. > The recipient would have the half transmission delays, and used as > reference > of the half of RTT. > Based on above description, the Leisure time equals to the Patience time - > RTT. > > I believe that the RTT needs to take care when the order of RTT and > Patience > time are near. > Maybe RTT calculation requires the same algorithms as TCP RTT calculation. > > Regards, > > Gengyu > > Network Technology Center > School of Computer > Beijing University of Posts & Telecommunications > > -----原始邮件----- > From: Likepeng > Sent: Wednesday, December 04, 2013 2:32 AM > To: core@ietf.org > Subject: [core] Fw: New Version Notification for > draft-li-core-coap-patience-option-03.txt > > Hello all, > > This draft is related to the recent discussion about CoAP 'infinite > timeout' > use case. > > Hope you can find some time to review it and give us feedback. > > Thanks, > Kind Regards > Kepeng > > -----邮件原件----- > 发件人: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > 发送时间: 2013年12月4日 15:29 > 收件人: Likepeng; Bert Greevenbosch; Salvatore Loreto; Salvatore > Loreto; > Esko Dijk > 主题: New Version Notification for > draft-li-core-coap-patience-option-03.txt > > > A new version of I-D, draft-li-core-coap-patience-option-03.txt > has been successfully submitted by Kepeng Li and posted to the IETF > repository. > > Filename: draft-li-core-coap-patience-option > Revision: 03 > Title: CoAP Option Extension: Patience > Creation date: 2013-12-04 > Group: Individual Submission > Number of pages: 10 > URL: > http://www.ietf.org/internet-drafts/draft-li-core-coap-patience-option-03.txt > Status: > http://datatracker.ietf.org/doc/draft-li-core-coap-patience-option > Htmlized: > http://tools.ietf.org/html/draft-li-core-coap-patience-option-03 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-li-core-coap-patience-option-03 > > Abstract: > CoAP is a RESTful application protocol for constrained nodes and > networks. This specification provides a simple extension for CoAP, > the Patience option. This option informs a recipient of the > preferred time frame for a request or response depending on usage > context. In a unicast request, it indicates the patience a client > has in waiting for a response. The CoAP server tries to return the > response within the specified time frame. In a multicast request, it > indicates the patience a server should have in sending its response. > The recipient would then try to randomly delay its response within > the time frame that the requester indicated or computed by the > recipient itself. In a CoAP observe notification, it indicates the > patience an observer should have in both waiting for a subsequent > notification and in re-establishing an observation relation. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From weigengyu@bupt.edu.cn Wed Dec 4 16:49:49 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 278FE1AE1DB for ; Wed, 4 Dec 2013 16:49:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.436 X-Spam-Level: X-Spam-Status: No, score=0.436 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3YSu4pT8Nju for ; Wed, 4 Dec 2013 16:49:44 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id EE20A1AE1D5 for ; Wed, 4 Dec 2013 16:49:38 -0800 (PST) Received: from WeiGengyuPC (unknown [10.103.241.46]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 09CE519F3B7; Thu, 5 Dec 2013 08:49:34 +0800 (HKT) Message-ID: <8765F975B4DC4E49B4660D2431C993BD@WeiGengyuPC> From: "weigengyu" To: "Carles Gomez Montenegro" References: <34966E97BE8AD64EAE9D3D6E4DEE36F252AC2D66@SZXEMA501-MBS.china.huawei.com> <7D43817BD4C04B22B8CF3000F2A5BE64@WeiGengyuPC> <65e092d52cef43d42aa6cfc215405749.squirrel@webmail.entel.upc.edu> In-Reply-To: <65e092d52cef43d42aa6cfc215405749.squirrel@webmail.entel.upc.edu> Date: Thu, 5 Dec 2013 08:49:36 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3505.912 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912 Cc: core@ietf.org Subject: Re: [core] Fw: New Version Notification for draft-li-core-coap-patience-option-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 00:49:49 -0000 Hi Carles, The draft-bormann-core-cocoa is important and congestion is a big topic. But I think the issue of congestion is the problem of message sublayer of CoAP. In order to provide reliablity the message sublayer calculates RTT and RTO like TCP does. But at the transaction sublayer, i.e the time between request and response(s), there should be some kinds of timer control. regards, Gengyu -----原始邮件----- From: Carles Gomez Montenegro Sent: Wednesday, December 04, 2013 11:54 PM To: weigengyu Cc: core@ietf.org Subject: Re: [core] Fw: New Version Notification for draft-li-core-coap-patience-option-03.txt Hi Gengyu, > Maybe RTT calculation requires the same algorithms as TCP RTT calculation. draft-bormann-core-cocoa proposes RTO/RTT estimation mechanisms for CoAP. These mechanisms are partially based on the RFC 6298 algorithm. Best regards, Carles > Hi Kepeng, > > After reading through the draft, I have a question. > > By the Patience option the recipient of the message knows the Patience > time > of the requster and calculates the Leisure time. > The recipient should consider the RTT (round trip time ) between > requester > and recipient when doing calculation. > > In order to facilitate the recipient's calculation, the requester could > put > a timestamp in the message. > The recipient would have the half transmission delays, and used as > reference > of the half of RTT. > Based on above description, the Leisure time equals to the Patience time - > RTT. > > I believe that the RTT needs to take care when the order of RTT and > Patience > time are near. > Maybe RTT calculation requires the same algorithms as TCP RTT calculation. > > Regards, > > Gengyu > > Network Technology Center > School of Computer > Beijing University of Posts & Telecommunications > > -----原始邮件----- > From: Likepeng > Sent: Wednesday, December 04, 2013 2:32 AM > To: core@ietf.org > Subject: [core] Fw: New Version Notification for > draft-li-core-coap-patience-option-03.txt > > Hello all, > > This draft is related to the recent discussion about CoAP 'infinite > timeout' > use case. > > Hope you can find some time to review it and give us feedback. > > Thanks, > Kind Regards > Kepeng > > -----邮件原件----- > 发件人: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > 发送时间: 2013å¹´12月4æ—¥ 15:29 > 收件人: Likepeng; Bert Greevenbosch; Salvatore Loreto; Salvatore > Loreto; > Esko Dijk > 主题: New Version Notification for > draft-li-core-coap-patience-option-03.txt > > > A new version of I-D, draft-li-core-coap-patience-option-03.txt > has been successfully submitted by Kepeng Li and posted to the IETF > repository. > > Filename: draft-li-core-coap-patience-option > Revision: 03 > Title: CoAP Option Extension: Patience > Creation date: 2013-12-04 > Group: Individual Submission > Number of pages: 10 > URL: > http://www.ietf.org/internet-drafts/draft-li-core-coap-patience-option-03.txt > Status: > http://datatracker.ietf.org/doc/draft-li-core-coap-patience-option > Htmlized: > http://tools.ietf.org/html/draft-li-core-coap-patience-option-03 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-li-core-coap-patience-option-03 > > Abstract: > CoAP is a RESTful application protocol for constrained nodes and > networks. This specification provides a simple extension for CoAP, > the Patience option. This option informs a recipient of the > preferred time frame for a request or response depending on usage > context. In a unicast request, it indicates the patience a client > has in waiting for a response. The CoAP server tries to return the > response within the specified time frame. In a multicast request, it > indicates the patience a server should have in sending its response. > The recipient would then try to randomly delay its response within > the time frame that the requester indicated or computed by the > recipient itself. In a CoAP observe notification, it indicates the > patience an observer should have in both waiting for a subsequent > notification and in re-establishing an observation relation. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From likepeng@huawei.com Wed Dec 4 18:04:23 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 075A61AE165 for ; Wed, 4 Dec 2013 18:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uaVqxLM3lISM for ; Wed, 4 Dec 2013 18:04:20 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 672041ADFD2 for ; Wed, 4 Dec 2013 18:04:19 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYQ20814; Thu, 05 Dec 2013 02:04:14 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 5 Dec 2013 02:03:24 +0000 Received: from SZXEMA407-HUB.china.huawei.com (10.82.72.39) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 5 Dec 2013 02:04:12 +0000 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.45]) by SZXEMA407-HUB.china.huawei.com ([10.82.72.39]) with mapi id 14.03.0158.001; Thu, 5 Dec 2013 10:04:08 +0800 From: Likepeng To: weigengyu Thread-Topic: [core] Fw: New Version Notification for draft-li-core-coap-patience-option-03.txt Thread-Index: AQHO8MKVE2LvlE6lMEGU5KOafw0lCZpDo97w///+OoCAASDAwA== Date: Thu, 5 Dec 2013 02:04:08 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F252AC33C4@SZXEMA501-MBS.china.huawei.com> References: <34966E97BE8AD64EAE9D3D6E4DEE36F252AC2D66@SZXEMA501-MBS.china.huawei.com> <7D43817BD4C04B22B8CF3000F2A5BE64@WeiGengyuPC> In-Reply-To: <7D43817BD4C04B22B8CF3000F2A5BE64@WeiGengyuPC> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.167.122] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "core@ietf.org" Subject: Re: [core] Fw: New Version Notification for draft-li-core-coap-patience-option-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 02:04:23 -0000 SGkgR2VuZ3l1LA0KDQpUaGFua3MgZm9yIHJldmlld2luZyB0aGUgZHJhZnQuDQoNCkFjY29yZGlu ZyB0byBteSBleHBlcmllbmNlIGZyb20gdGhlIHByZXZpb3VzIElPUCB0ZXN0aW5nIGFjdGl2aXRp ZXMsIHVzdWFsbHkgdGhlIFJUVCB3aWxsIGJlIGxlc3MgdGhhbiAyIHNlY29uZHMuIFdlIHBlcmZv cm1lZCBzZXZlcmFsIHJlbW90ZSB0ZXN0aW5nIGJldHdlZW4gQ2hpbmEgYW5kIEV1cm9wZSwgYWxz byBiZXR3ZWVuIENoaW5hIGFuZCBVUywgUlRUIGlzIGxlc3MgdGhhbiAyIHNlY29uZHMuIEFsc28g ZnJvbSB0aGUgc3BlYywgQUNLX1RJTUVPVVQgaXMgMiBzZWNvbmRzLiBSVFQgc2hvdWxkIGJlIGxl c3MgdGhhbiB0aGF0LiANCg0KSSB3b3VsZCBhc3N1bWUgdGhhdCB1c3VhbGx5IGNsaWVudCBzaG91 bGQgd2FpdCBmb3IgdGhlIG1heGltdW0gdHJhbnNtaXNzaW9uIHRpbWUgZXhwaXJlZCBiZWZvcmUg Z2l2aW5nIHVwLiBUaGF0IG1lYW5zLCBQYXRpZW5jZSBzaG91bGQgYmUgbW9yZSB0aGFuIE1BWF9S RVRSQU5TTUlUICogQUNLX1RJTUVPVVQgPSA4IHNlY29uZHMuIA0KDQpTbywgSSBjYW4gc2F5LCBQ YXRpZW5jZSBpcyB1c3VhbGx5IG11Y2ggbG9uZ2VyIHRoYW4gUlRULiBCYXNpY2FsbHkgcGF0aWVu Y2UgaXMgbm90IG5lY2Vzc2FyaWx5IHRvIGJlIHRoYXQgYWNjdXJhdGUuIEFuZCB3ZSBkb24ndCBu ZWVkIHRvIGluY2x1ZGUgdGhlIGNhbGN1bGF0aW9uIGFsZ29yaXRobSBmb3IgUlRUIGluIHRoZSBQ YXRpZW5jZSBkcmFmdC4gQnV0IHdlIGNhbiBhZGQgc29tZSB0ZXh0cyBpbiB0aGUgZHJhZnQgdG8g c2F5LCB3aGVuIHRoZSBjbGllbnQgY2hvb3NlcyB0aGUgcGF0aWVuY2UgdmFsdWUsIGl0IHNob3Vs ZCB0YWtlIHRoZSBSVFQgaW50byBhY2NvdW50Lg0KDQpUaGFua3MsDQpLaW5kIFJlZ2FyZHMNCktl cGVuZw0KDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IHdlaWdlbmd5dSBbbWFp bHRvOndlaWdlbmd5dUBidXB0LmVkdS5jbl0gDQrlj5HpgIHml7bpl7Q6IDIwMTPlubQxMuaciDTm l6UgMjM6MjQNCuaUtuS7tuS6ujogTGlrZXBlbmcNCuaKhOmAgTogY29yZUBpZXRmLm9yZw0K5Li7 6aKYOiBSZTogW2NvcmVdIEZ3OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxp LWNvcmUtY29hcC1wYXRpZW5jZS1vcHRpb24tMDMudHh0DQoNCkhpIEtlcGVuZywNCg0KQWZ0ZXIg cmVhZGluZyB0aHJvdWdoIHRoZSBkcmFmdCwgSSBoYXZlIGEgcXVlc3Rpb24uDQoNCkJ5IHRoZSBQ YXRpZW5jZSBvcHRpb24gdGhlIHJlY2lwaWVudCBvZiB0aGUgbWVzc2FnZSBrbm93cyB0aGUgUGF0 aWVuY2UgdGltZSBvZiB0aGUgcmVxdXN0ZXIgYW5kIGNhbGN1bGF0ZXMgdGhlIExlaXN1cmUgdGlt ZS4NClRoZSByZWNpcGllbnQgc2hvdWxkIGNvbnNpZGVyIHRoZSBSVFQgKHJvdW5kIHRyaXAgdGlt ZSApICBiZXR3ZWVuIHJlcXVlc3RlciBhbmQgcmVjaXBpZW50IHdoZW4gZG9pbmcgY2FsY3VsYXRp b24uDQoNCkluIG9yZGVyIHRvIGZhY2lsaXRhdGUgdGhlIHJlY2lwaWVudCdzIGNhbGN1bGF0aW9u LCB0aGUgcmVxdWVzdGVyIGNvdWxkIHB1dCBhIHRpbWVzdGFtcCBpbiB0aGUgbWVzc2FnZS4NClRo ZSByZWNpcGllbnQgd291bGQgaGF2ZSB0aGUgaGFsZiB0cmFuc21pc3Npb24gZGVsYXlzLCBhbmQg dXNlZCBhcyByZWZlcmVuY2Ugb2YgdGhlIGhhbGYgb2YgUlRULg0KQmFzZWQgb24gYWJvdmUgZGVz Y3JpcHRpb24sIHRoZSBMZWlzdXJlIHRpbWUgZXF1YWxzIHRvIHRoZSBQYXRpZW5jZSB0aW1lIC0g UlRULg0KDQpJIGJlbGlldmUgdGhhdCB0aGUgUlRUIG5lZWRzIHRvIHRha2UgY2FyZSB3aGVuIHRo ZSBvcmRlciBvZiBSVFQgYW5kIFBhdGllbmNlIHRpbWUgYXJlIG5lYXIuDQpNYXliZSBSVFQgY2Fs Y3VsYXRpb24gcmVxdWlyZXMgdGhlIHNhbWUgYWxnb3JpdGhtcyBhcyBUQ1AgUlRUIGNhbGN1bGF0 aW9uLg0KDQpSZWdhcmRzLA0KDQpHZW5neXUNCg0KTmV0d29yayBUZWNobm9sb2d5IENlbnRlcg0K U2Nob29sIG9mIENvbXB1dGVyDQpCZWlqaW5nIFVuaXZlcnNpdHkgb2YgUG9zdHMgJiBUZWxlY29t bXVuaWNhdGlvbnMNCg0KLS0tLS3ljp/lp4vpgq7ku7YtLS0tLQ0KRnJvbTogTGlrZXBlbmcNClNl bnQ6IFdlZG5lc2RheSwgRGVjZW1iZXIgMDQsIDIwMTMgMjozMiBBTQ0KVG86IGNvcmVAaWV0Zi5v cmcNClN1YmplY3Q6IFtjb3JlXSBGdzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC1saS1jb3JlLWNvYXAtcGF0aWVuY2Utb3B0aW9uLTAzLnR4dA0KDQpIZWxsbyBhbGwsDQoNClRo aXMgZHJhZnQgaXMgcmVsYXRlZCB0byB0aGUgcmVjZW50IGRpc2N1c3Npb24gYWJvdXQgQ29BUCAn aW5maW5pdGUgdGltZW91dCcgDQp1c2UgY2FzZS4NCg0KSG9wZSB5b3UgY2FuIGZpbmQgc29tZSB0 aW1lIHRvIHJldmlldyBpdCBhbmQgZ2l2ZSB1cyBmZWVkYmFjay4NCg0KVGhhbmtzLA0KS2luZCBS ZWdhcmRzDQpLZXBlbmcNCg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQrl j5HpgIHml7bpl7Q6IDIwMTPlubQxMuaciDTml6UgMTU6MjkNCuaUtuS7tuS6ujogTGlrZXBlbmc7 IEJlcnQgR3JlZXZlbmJvc2NoOyBTYWx2YXRvcmUgTG9yZXRvOyBTYWx2YXRvcmUgTG9yZXRvOyBF c2tvIERpamsNCuS4u+mimDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1saS1j b3JlLWNvYXAtcGF0aWVuY2Utb3B0aW9uLTAzLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1E LCBkcmFmdC1saS1jb3JlLWNvYXAtcGF0aWVuY2Utb3B0aW9uLTAzLnR4dA0KaGFzIGJlZW4gc3Vj Y2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBLZXBlbmcgTGkgYW5kIHBvc3RlZCB0byB0aGUgSUVURiAN CnJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOiBkcmFmdC1saS1jb3JlLWNvYXAtcGF0aWVuY2Utb3B0 aW9uDQpSZXZpc2lvbjogMDMNClRpdGxlOiBDb0FQIE9wdGlvbiBFeHRlbnNpb246IFBhdGllbmNl DQpDcmVhdGlvbiBkYXRlOiAyMDEzLTEyLTA0DQpHcm91cDogSW5kaXZpZHVhbCBTdWJtaXNzaW9u DQpOdW1iZXIgb2YgcGFnZXM6IDEwDQpVUkw6IA0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtbGktY29yZS1jb2FwLXBhdGllbmNlLW9wdGlvbi0wMy50eHQNClN0YXR1 czogDQpodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxpLWNvcmUtY29hcC1w YXRpZW5jZS1vcHRpb24NCkh0bWxpemVkOiANCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWxpLWNvcmUtY29hcC1wYXRpZW5jZS1vcHRpb24tMDMNCkRpZmY6IA0KaHR0cDovL3d3dy5p ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbGktY29yZS1jb2FwLXBhdGllbmNlLW9wdGlvbi0w Mw0KDQpBYnN0cmFjdDoNCiAgIENvQVAgaXMgYSBSRVNUZnVsIGFwcGxpY2F0aW9uIHByb3RvY29s IGZvciBjb25zdHJhaW5lZCBub2RlcyBhbmQNCiAgIG5ldHdvcmtzLiAgVGhpcyBzcGVjaWZpY2F0 aW9uIHByb3ZpZGVzIGEgc2ltcGxlIGV4dGVuc2lvbiBmb3IgQ29BUCwNCiAgIHRoZSBQYXRpZW5j ZSBvcHRpb24uICBUaGlzIG9wdGlvbiBpbmZvcm1zIGEgcmVjaXBpZW50IG9mIHRoZQ0KICAgcHJl ZmVycmVkIHRpbWUgZnJhbWUgZm9yIGEgcmVxdWVzdCBvciByZXNwb25zZSBkZXBlbmRpbmcgb24g dXNhZ2UNCiAgIGNvbnRleHQuICBJbiBhIHVuaWNhc3QgcmVxdWVzdCwgaXQgaW5kaWNhdGVzIHRo ZSBwYXRpZW5jZSBhIGNsaWVudA0KICAgaGFzIGluIHdhaXRpbmcgZm9yIGEgcmVzcG9uc2UuICBU aGUgQ29BUCBzZXJ2ZXIgdHJpZXMgdG8gcmV0dXJuIHRoZQ0KICAgcmVzcG9uc2Ugd2l0aGluIHRo ZSBzcGVjaWZpZWQgdGltZSBmcmFtZS4gIEluIGEgbXVsdGljYXN0IHJlcXVlc3QsIGl0DQogICBp bmRpY2F0ZXMgdGhlIHBhdGllbmNlIGEgc2VydmVyIHNob3VsZCBoYXZlIGluIHNlbmRpbmcgaXRz IHJlc3BvbnNlLg0KICAgVGhlIHJlY2lwaWVudCB3b3VsZCB0aGVuIHRyeSB0byByYW5kb21seSBk ZWxheSBpdHMgcmVzcG9uc2Ugd2l0aGluDQogICB0aGUgdGltZSBmcmFtZSB0aGF0IHRoZSByZXF1 ZXN0ZXIgaW5kaWNhdGVkIG9yIGNvbXB1dGVkIGJ5IHRoZQ0KICAgcmVjaXBpZW50IGl0c2VsZi4g IEluIGEgQ29BUCBvYnNlcnZlIG5vdGlmaWNhdGlvbiwgaXQgaW5kaWNhdGVzIHRoZQ0KICAgcGF0 aWVuY2UgYW4gb2JzZXJ2ZXIgc2hvdWxkIGhhdmUgaW4gYm90aCB3YWl0aW5nIGZvciBhIHN1YnNl cXVlbnQNCiAgIG5vdGlmaWNhdGlvbiBhbmQgaW4gcmUtZXN0YWJsaXNoaW5nIGFuIG9ic2VydmF0 aW9uIHJlbGF0aW9uLg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291 cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIA0KdW50aWwgdGhlIGh0 bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4N Cg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCmNvcmUgbWFpbGluZyBsaXN0DQpjb3JlQGlldGYub3JnDQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUgDQoNCg== From weigengyu@bupt.edu.cn Wed Dec 4 19:12:58 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFE71AE263 for ; Wed, 4 Dec 2013 19:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.436 X-Spam-Level: X-Spam-Status: No, score=0.436 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rH772zGrWD4B for ; Wed, 4 Dec 2013 19:12:55 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 30FFD1AE179 for ; Wed, 4 Dec 2013 19:12:53 -0800 (PST) Received: from WeiGengyuPC (unknown [10.103.241.46]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 54DB719F374; Thu, 5 Dec 2013 11:12:49 +0800 (HKT) Message-ID: <9140584A1D46402E8B9E39A39AE16B31@WeiGengyuPC> From: "weigengyu" To: "Likepeng" , References: <34966E97BE8AD64EAE9D3D6E4DEE36F252AC2D66@SZXEMA501-MBS.china.huawei.com> <7D43817BD4C04B22B8CF3000F2A5BE64@WeiGengyuPC> <34966E97BE8AD64EAE9D3D6E4DEE36F252AC33C4@SZXEMA501-MBS.china.huawei.com> In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F252AC33C4@SZXEMA501-MBS.china.huawei.com> Date: Thu, 5 Dec 2013 11:12:51 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3505.912 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912 Cc: core@ietf.org Subject: Re: [core] Fw: New Version Notification for draft-li-core-coap-patience-option-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 03:12:58 -0000 Hi Kepeng, Carles and all, According to CoAP architechture, there are message sbulayer and transaction sublayer. As I understood, the congestion control is the message sublayer facility, and Patience option is for the transaction sublayer, i.e. tolerance time delay of response. Anything wrong? Rtt could be measured at each sublayer. They might be different. And it is easy to see that the RTT of Transaction sublayer should be larger than that of Message sublayer. I have no data about RTT at transaction sublayer between a CoRE Endpoint and a host in Internet across seas and lands, and wish the tested data can help to make default RTT. We did a work serveral years ago, " Title: MLM: A monitoring system for network QoS based on multi-level measurement. " Published in: Broadband Network & Multimedia Technology, 2009. IC-BNMT '09. 2nd IEEE International Conference. Although it is different from CoAP, the characteristics on the layered protocals are understood. Regards, Gengyu Network Technology Center School of Computers Beijing University of Posts & Telecommunications -----原始邮件----- From: Likepeng Sent: Thursday, December 05, 2013 10:04 AM To: weigengyu Cc: core@ietf.org Subject: Re: [core] Fw: New Version Notification for draft-li-core-coap-patience-option-03.txt Hi Gengyu, Thanks for reviewing the draft. According to my experience from the previous IOP testing activities, usually the RTT will be less than 2 seconds. We performed several remote testing between China and Europe, also between China and US, RTT is less than 2 seconds. Also from the spec, ACK_TIMEOUT is 2 seconds. RTT should be less than that. I would assume that usually client should wait for the maximum transmission time expired before giving up. That means, Patience should be more than MAX_RETRANSMIT * ACK_TIMEOUT = 8 seconds. So, I can say, Patience is usually much longer than RTT. Basically patience is not necessarily to be that accurate. And we don't need to include the calculation algorithm for RTT in the Patience draft. But we can add some texts in the draft to say, when the client chooses the patience value, it should take the RTT into account. Thanks, Kind Regards Kepeng -----邮件原件----- 发件人: weigengyu [mailto:weigengyu@bupt.edu.cn] 发送时间: 2013年12月4日 23:24 收件人: Likepeng 抄送: core@ietf.org 主题: Re: [core] Fw: New Version Notification for draft-li-core-coap-patience-option-03.txt Hi Kepeng, After reading through the draft, I have a question. By the Patience option the recipient of the message knows the Patience time of the requster and calculates the Leisure time. The recipient should consider the RTT (round trip time ) between requester and recipient when doing calculation. In order to facilitate the recipient's calculation, the requester could put a timestamp in the message. The recipient would have the half transmission delays, and used as reference of the half of RTT. Based on above description, the Leisure time equals to the Patience time - RTT. I believe that the RTT needs to take care when the order of RTT and Patience time are near. Maybe RTT calculation requires the same algorithms as TCP RTT calculation. Regards, Gengyu Network Technology Center School of Computer Beijing University of Posts & Telecommunications -----原始邮件----- From: Likepeng Sent: Wednesday, December 04, 2013 2:32 AM To: core@ietf.org Subject: [core] Fw: New Version Notification for draft-li-core-coap-patience-option-03.txt Hello all, This draft is related to the recent discussion about CoAP 'infinite timeout' use case. Hope you can find some time to review it and give us feedback. Thanks, Kind Regards Kepeng -----邮件原件----- 发件人: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 发送时间: 2013年12月4日 15:29 收件人: Likepeng; Bert Greevenbosch; Salvatore Loreto; Salvatore Loreto; Esko Dijk 主题: New Version Notification for draft-li-core-coap-patience-option-03.txt A new version of I-D, draft-li-core-coap-patience-option-03.txt has been successfully submitted by Kepeng Li and posted to the IETF repository. Filename: draft-li-core-coap-patience-option Revision: 03 Title: CoAP Option Extension: Patience Creation date: 2013-12-04 Group: Individual Submission Number of pages: 10 URL: http://www.ietf.org/internet-drafts/draft-li-core-coap-patience-option-03.txt Status: http://datatracker.ietf.org/doc/draft-li-core-coap-patience-option Htmlized: http://tools.ietf.org/html/draft-li-core-coap-patience-option-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-li-core-coap-patience-option-03 Abstract: CoAP is a RESTful application protocol for constrained nodes and networks. This specification provides a simple extension for CoAP, the Patience option. This option informs a recipient of the preferred time frame for a request or response depending on usage context. In a unicast request, it indicates the patience a client has in waiting for a response. The CoAP server tries to return the response within the specified time frame. In a multicast request, it indicates the patience a server should have in sending its response. The recipient would then try to randomly delay its response within the time frame that the requester indicated or computed by the recipient itself. In a CoAP observe notification, it indicates the patience an observer should have in both waiting for a subsequent notification and in re-establishing an observation relation. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From cabo@tzi.org Wed Dec 4 23:01:31 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1F61A1F06 for ; Wed, 4 Dec 2013 23:01:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77Q-m6DLCZHk for ; Wed, 4 Dec 2013 23:01:30 -0800 (PST) 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 EFB791A1F02 for ; Wed, 4 Dec 2013 23:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rB571E1m007725; Thu, 5 Dec 2013 08:01:15 +0100 (CET) Received: from [192.168.217.105] (p548901B4.dip0.t-ipconnect.de [84.137.1.180]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id BAB617D7; Thu, 5 Dec 2013 08:01:13 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann X-Priority: 3 In-Reply-To: <7D43817BD4C04B22B8CF3000F2A5BE64@WeiGengyuPC> Date: Thu, 5 Dec 2013 08:01:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <34966E97BE8AD64EAE9D3D6E4DEE36F252AC2D66@SZXEMA501-MBS.china.huawei.com> <7D43817BD4C04B22B8CF3000F2A5BE64@WeiGengyuPC> To: weigengyu X-Mailer: Apple Mail (2.1822) Cc: "core \(core@ietf.org\)" Subject: Re: [core] Fw: New Version Notification for draft-li-core-coap-patience-option-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 07:01:31 -0000 On 04 Dec 2013, at 16:24, weigengyu wrote: > the requester could put a timestamp in the message If this is meant to be a timestamp in absolute time: We cannot expect constrained nodes to have good realtime clocks. So there is no way that a recipient could make direct use of an absolute = time sent to it. (Even relative measurements might be tenuous. E.g., in -observe, we try to allow for total clock inaccuracies of up to = -50/+100 %. I would expect any Patience mechanism to be designed to similar = tolerances.) Gr=FC=DFe, Carsten From weigengyu@bupt.edu.cn Thu Dec 5 00:28:39 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32BE11AD73F for ; Thu, 5 Dec 2013 00:28:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.237 X-Spam-Level: * X-Spam-Status: No, score=1.237 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJx8btwdMTwS for ; Thu, 5 Dec 2013 00:28:36 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8221AC7F3 for ; Thu, 5 Dec 2013 00:28:33 -0800 (PST) Received: from WeiGengyuPC (unknown [10.103.241.46]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id A669219F3B1; Thu, 5 Dec 2013 16:28:27 +0800 (HKT) Message-ID: From: "weigengyu" To: "Carsten Bormann" References: <34966E97BE8AD64EAE9D3D6E4DEE36F252AC2D66@SZXEMA501-MBS.china.huawei.com> <7D43817BD4C04B22B8CF3000F2A5BE64@WeiGengyuPC> In-Reply-To: Date: Thu, 5 Dec 2013 16:28:30 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3505.912 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912 Cc: core@ietf.org Subject: Re: [core] Fw: New Version Notification for draft-li-core-coap-patience-option-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 08:28:39 -0000 Hi Carsten, I am not sure whether all servers have the timer capabilty. I have used the Sensor with Tiny OS for reseaching works, tiny os has rich timer functions. >> the requester could put a timestamp in the message > If this is meant to be a timestamp in absolute time: > We cannot expect constrained nodes to have good realtime clocks. > So there is no way that a recipient could make direct use of an absolute > time sent to it. Patience option tells how long the torlerance duration. Timestamp only informs when to start that duration. If the constrained nodes do not have "good realtime clocks" and a recipient could not make direct use of an absolute time sent to it, the reasonable process is to have the server a default value or just ignore it. And If the server has timer capability, applications might define a mechanism to tune it when CoAP has not the facility. > (Even relative measurements might be tenuous. > E.g., in -observe, we try to allow for total clock inaccuracies of up > to -50/+100 %. > I would expect any Patience mechanism to be designed to similar > tolerances.) I am interested in why "in -observe, we try to allow for total clock inaccuracies of up to -50/+100 %." regards, Gengyu Network Technology Center School of Computer Beijing University of Posts & Telecommunications -----原始邮件----- From: Carsten Bormann Sent: Thursday, December 05, 2013 3:01 PM To: weigengyu Cc: Likepeng ; core (core@ietf.org) Subject: Re: [core] Fw: New Version Notification for draft-li-core-coap-patience-option-03.txt On 04 Dec 2013, at 16:24, weigengyu wrote: > the requester could put a timestamp in the message If this is meant to be a timestamp in absolute time: We cannot expect constrained nodes to have good realtime clocks. So there is no way that a recipient could make direct use of an absolute time sent to it. (Even relative measurements might be tenuous. E.g., in -observe, we try to allow for total clock inaccuracies of up to -50/+100 %. I would expect any Patience mechanism to be designed to similar tolerances.) Grüße, Carsten From weigengyu@bupt.edu.cn Thu Dec 5 02:49:15 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A9E1ADEBF for ; Thu, 5 Dec 2013 02:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwfTUxyYnyRA for ; Thu, 5 Dec 2013 02:49:10 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 777251ADEBB for ; Thu, 5 Dec 2013 02:49:08 -0800 (PST) Received: from WeiGengyuPC (unknown [221.218.43.119]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 8851E19F374; Thu, 5 Dec 2013 18:48:59 +0800 (HKT) Message-ID: <17EC2DB49FCD4CDC96B036382B28DCDA@WeiGengyuPC> From: "weigengyu" To: "Carsten Bormann" References: <34966E97BE8AD64EAE9D3D6E4DEE36F252AC2D66@SZXEMA501-MBS.china.huawei.com> <7D43817BD4C04B22B8CF3000F2A5BE64@WeiGengyuPC> In-Reply-To: Date: Thu, 5 Dec 2013 18:49:01 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3505.912 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912 Cc: core@ietf.org Subject: Re: [core] Fw: New Version Notification fordraft-li-core-coap-patience-option-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 10:49:15 -0000 Hi Carsten, If the number of constrained nodes which have not good realtime clock is large, is it required to define a clock synchronization mechanism in CoAP? I assume that such nodes should have a local timer, no matter good or bad, the synchronization could help them to be near accurate. regards, Gengyu Network Technology Center School of Computer Beijing University of Posts & Telecommunications -----原始邮件----- From: weigengyu Sent: Thursday, December 05, 2013 4:28 PM To: Carsten Bormann Cc: core@ietf.org Subject: Re: [core] Fw: New Version Notification fordraft-li-core-coap-patience-option-03.txt Hi Carsten, I am not sure whether all servers have the timer capabilty. I have used the Sensor with Tiny OS for reseaching works, tiny os has rich timer functions. >> the requester could put a timestamp in the message > If this is meant to be a timestamp in absolute time: > We cannot expect constrained nodes to have good realtime clocks. > So there is no way that a recipient could make direct use of an absolute > time sent to it. Patience option tells how long the torlerance duration. Timestamp only informs when to start that duration. If the constrained nodes do not have "good realtime clocks" and a recipient could not make direct use of an absolute time sent to it, the reasonable process is to have the server a default value or just ignore it. And If the server has timer capability, applications might define a mechanism to tune it when CoAP has not the facility. > (Even relative measurements might be tenuous. > E.g., in -observe, we try to allow for total clock inaccuracies of up > to -50/+100 %. > I would expect any Patience mechanism to be designed to similar > tolerances.) I am interested in why "in -observe, we try to allow for total clock inaccuracies of up to -50/+100 %." regards, Gengyu Network Technology Center School of Computer Beijing University of Posts & Telecommunications -----原始邮件----- From: Carsten Bormann Sent: Thursday, December 05, 2013 3:01 PM To: weigengyu Cc: Likepeng ; core (core@ietf.org) Subject: Re: [core] Fw: New Version Notification for draft-li-core-coap-patience-option-03.txt On 04 Dec 2013, at 16:24, weigengyu wrote: > the requester could put a timestamp in the message If this is meant to be a timestamp in absolute time: We cannot expect constrained nodes to have good realtime clocks. So there is no way that a recipient could make direct use of an absolute time sent to it. (Even relative measurements might be tenuous. E.g., in -observe, we try to allow for total clock inaccuracies of up to -50/+100 %. I would expect any Patience mechanism to be designed to similar tolerances.) Grüße, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From zach.shelby@arm.com Fri Dec 6 09:23:59 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C17D1ADC03 for ; Fri, 6 Dec 2013 09:23:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GiWLVhCPZcBT for ; Fri, 6 Dec 2013 09:23:56 -0800 (PST) Received: from service88.mimecast.com (service88.mimecast.com [195.130.217.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5321AD83F for ; Fri, 6 Dec 2013 09:23:55 -0800 (PST) Received: from usa-sjc-gw2.usa.Arm.com (fw-tnat.snv.arm.com [217.140.100.22]) (Using TLS) by service88.mimecast.com; Fri, 06 Dec 2013 17:23:50 +0000 Received: from Spock.usa.Arm.com ([fe80::6066:a427:fcf0:1568]) by usa-sjc-gw2.usa.Arm.com ([::1]) with mapi; Fri, 6 Dec 2013 09:23:46 -0800 From: Zach Shelby To: Klaus Hartke Date: Fri, 6 Dec 2013 09:23:48 -0800 Thread-Topic: [core] Sleepy devices: OMA lightweight queue mode for CoAP Thread-Index: Ac7yp+t2RVAKGauWRW2hASZWsXe3VA== Message-ID: <8EFFCE25-4D91-4878-BCA5-BAE9CA3C0CC7@arm.com> References: <031DD135F9160444ABBE3B0C36CED6180CC2895D@011-DB3MPN2-082.MGDPHG.emi.philips.com> <8AD83A72-6EE4-4C77-A084-BAD5C5C87989@arm.com> <031DD135F9160444ABBE3B0C36CED6180CC40DF1@011-DB3MPN2-082.MGDPHG.emi.philips.com> <2E04C2C9-4860-499E-9CF6-C419CBFD8B0A@arm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-MC-Unique: 113120617235006502 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Cc: "core@ietf.org" Subject: Re: [core] Sleepy devices: OMA lightweight queue mode for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 17:23:59 -0000 On Nov 26, 2013, at 9:49 AM, Klaus Hartke wrote: > Zach Shelby wrote: >> Esko Dijk wrote: >>> The 'SICEP' may typically wake up once a day and the HTTP connection wo= uld be dropped long before that. (A few minutes typically?) >> >> You would need to long-poll or use a callback of course. > > I'd expect a 2.xx (Accepted)* response here with Location options > indicating a resource that the client can poll or observe to track the > progress of the request. > > (*like HTTP 202 Accepted > ; > currently not defined in CoAP) Sure. And we were talking about an HTTP interface here to such a sleeping n= ode proxy, so that works. Zach Shelby Director of Technology ARM Internet of Things BU www.arm.com mobile: +1 (408) 203-9434 Skype: zdshelby LinkedIn: fi.linkedin.com/in/zachshelby/ -- IMPORTANT NOTICE: The contents of this email and any attachments are con= fidential and may also be privileged. If you are not the intended recipient= , please notify the sender immediately and do not disclose the contents to = any other person, use it for any purpose, or store or copy the information = in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Regist= ered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, R= egistered in England & Wales, Company No: 2548782 From cabo@tzi.org Mon Dec 9 08:42:46 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2EB1ADFE2 for ; Mon, 9 Dec 2013 08:42:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXvLj0Qo0fqq for ; Mon, 9 Dec 2013 08:42:44 -0800 (PST) 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 500A41ADFD3 for ; Mon, 9 Dec 2013 08:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rB9GgYHF003113 for ; Mon, 9 Dec 2013 17:42:34 +0100 (CET) Received: from [192.168.217.144] (p54890261.dip0.t-ipconnect.de [84.137.2.97]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 74806EAB; Mon, 9 Dec 2013 17:42:33 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Dec 2013 17:42:28 +0100 To: "core (core@ietf.org)" Message-Id: <7457F6C7-9034-46BD-B194-12C726F19C49@tzi.org> Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) X-Mailer: Apple Mail (2.1822) Subject: [core] IETF88 CoRE minutes X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 16:42:46 -0000 The minutes for the Vancouver CoRE meeting are now (finally) available = for review at: http://www.ietf.org/proceedings/88/minutes/minutes-88-core (as usual not correctly marked as UTF-8 by the IETF server, but they are = working on that). Apologies that it took a long time to get these done. Please review = these as soon as possible to ensure their correctness, especially if you = were at the microphone at some point during the session. =20 As a particular concern, I was unable to retrieve useful audio to check = the record of the second session. The Secretariat will be grabbing these minutes very soon to make the = official permanent copy of the proceedings. Gr=FC=DFe, Carsten From congwang@cityu.edu.hk Mon Dec 9 09:09:34 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D12AD1AE3A0 for ; Mon, 9 Dec 2013 09:09:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.578 X-Spam-Level: X-Spam-Status: No, score=-5.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8dxJbeBihUn for ; Mon, 9 Dec 2013 09:09:32 -0800 (PST) Received: from smtp01.cityu.edu.hk (smtp01.cityu.edu.hk [144.214.4.70]) by ietfa.amsl.com (Postfix) with ESMTP id D58F71AE38F for ; Mon, 9 Dec 2013 09:09:31 -0800 (PST) Received: from smtp01.cityu.edu.hk (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7DCC93C248 for ; Tue, 10 Dec 2013 01:09:26 +0800 (HKT) Received: from lily02 (ausmtp.cityu.edu.hk [144.214.6.44]) by smtp01.cityu.edu.hk (Postfix) with ESMTP id 1EEA73C23D for ; Tue, 10 Dec 2013 01:09:25 +0800 (HKT) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by ausmtp.cityu.edu.hk (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) with ESMTPSA id <0MXJ00MBSUBN4Y50@ausmtp.cityu.edu.hk> for core@ietf.org; Tue, 10 Dec 2013 01:09:25 +0800 (HKT) Sender: congwang@cityu.edu.hk Received: by mail-wg0-f53.google.com with SMTP id k14so3739538wgh.20 for ; Mon, 09 Dec 2013 09:09:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:from:date:message-id:subject:to:content-type; bh=o8jLEXlFgLYGwWyhxyakeKLIR1SbiIjK4HkkjfR/rcc=; b=FI3J0n94TAX1dVjH84kUVsQrtv3aihap0rRc5VwBs7OYk5lz++1ahohj0n8xzg8eSy ULjoZTurQ/6iyWaZOM3HomGC6FEaP3q4LLdCD+7NBNnu0Jom0CAqJkn0gjIeHCCZF3D3 DdLjGbhxgCgUyQmNR64YLIMPLesE6aUOAneaBdJARLL98nmA94eSQACvKfK2Jd6QumzV 1iMh4agV2Nbv1B+099P5kYRGJ55uups20dvcOBbVBEun04p1rI94D8AH2OiFuT2PF9h+ SkmWungeSqo7m2jfhYfumw55TM/TN7F6s78LPtOJulbbcgD4ab6OjZBUL8dTmeuxHUSZ 4ZeA== X-Received: by 10.194.88.138 with SMTP id bg10mr7052162wjb.56.1386608962101; Mon, 09 Dec 2013 09:09:22 -0800 (PST) MIME-version: 1.0 Received: by 10.227.232.5 with HTTP; Mon, 09 Dec 2013 09:09:02 -0800 (PST) From: Cong Wang Date: Tue, 10 Dec 2013 01:09:02 +0800 Message-id: <17642_1386608966_52A5F945_17642_2037_1_CABq1=dY8_34v1LAk21fhOsRnbTbo50UF2M6iDHowD+qwxzCTcw@mail.gmail.com> To: core Content-type: multipart/alternative; boundary=047d7bfd0562a0ebe804ed1d0ec6 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.12.9.165714 Subject: [core] CFP: IEEE Internet of Things Journal, SI on Security for IoT: the State of the Art (deadline: Feb. 15th, 2014) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 17:09:35 -0000 --047d7bfd0562a0ebe804ed1d0ec6 Content-Type: text/plain; charset=ISO-8859-1 Dear Core Members, Please find below our call for paper for IEEE Internet of Things Journal Special Issue on Security for IoT: the State of the Art (deadline: Feb. 15th, 2014). Online version is available under: < http://iot-journal.weebly.com/uploads/1/8/8/0/18809834/ieee_iot_journal_si_iot_security_cfp.pdf>. We are looking forward for your submissions, and appreciate your further help in forwarding the CFP to your friends and colleagues. Thanks a lot. Regards, Cong Wang # CALL FOR PAPERS # IEEE Internet of Things Journal Special Issue on Security for IoT: the State of the Art (deadline: Feb. 15th, 2014) A PDF version of this CFP can be downloaded at: < http://iot-journal.weebly.com/uploads/1/8/8/0/18809834/ieee_iot_journal_si_iot_security_cfp.pdf > # Scope of Special Issue # The Internet is becoming more and more ubiquitous. One central element of this trend is the existence of a massive network of interconnected wired/wireless physical objects/things/sensors/devices, which can interact in a rich set of manners through a worldwide communication and information infrastructure and provide value added services. The vision of such an Internet of Things (IoT) system, supported by industrial companies and governments globally, has the potential to mark an evolution that will surely have a great impact on our environments and our lives. Yet, the realization of a ubiquitous IoT also poses a number of challenges where security is among the top concerns. The globally interconnected physical objects inevitably result in a potentially enormous attack surface that can be easily exploited if without adequate protection. To enable strong security foundations for the ubiquitous IoT, plenty of factors need to be taken into account. Examples are data security, privacy, access control, information assurance, trust management, secure services interoperability, seamless integration, system heterogeneity, scalability, and mobility. This special issue solicits high-quality original research results about IoT that pertain to state-of-the-art security and privacy issues in various pervasive and ubiquitous scenarios. We encourage submissions on theoretical, practical, as well as experimental studies, from both academia and industry, related to all aspects of security for IoT. Topics of interests include (but are not limited to) the following categories: - Secure IoT architecture - IoT access control and key management - Identification and privacy for IoT - Smart phone enabled secure smart systems - New cryptographic primitives for IoT - Manage trust for IoT service interoperability - Security on heterogeneous ecosystems - Context-aware security design - Data security and privacy in the IoT - Intrusion detection and defense for IoT - Joint security&privacy aware protocol design - Failure detection, prediction, and recovery - Secure data management within IoT - Trusted computing technology and IoT - Availability, recovery and auditing - IoT related web services security - Secure cyber-physical system - Biometrics for the IoT # Important Dates # - Submissions Deadline: February 15th, 2014 - First Reviews Due: May 15th, 2014 - Revision Due: June 15th, 2014 - Second Reviews Due/Acceptance letters: July 15th, 2014 - Final Manuscript Due: August 15th, 2014 - Publication Date: October 15th, 2014 # Submission Guidelines # The special issue seeks submission of papers that present novel original results and findings on Security for IoT. Solicited original submissions must not be currently under consideration for publication in other venues. Author guidelines and submission information can be found at < http://iot.ieee.org/journal>. All manuscripts should be submitted through Manuscript Central: # Guest Editors # - Kui Ren, University at Buffalo, SUNY - Pierangela Samarati, University of Milan - Peng Ning, NCSU, Raleigh & Samsung Mobile - Marco Gruteser, Rutgers University - Yunhao Liu, Tsinghua University SI Publicity Chair: Cong Wang, City University of Hong Kong < congwang@cityu.edu.hk> -- ~~~~~~~~~~~~~~~~~~~~~~ Cong WANG, PhD Assistant Professor Computer Science Department City University of Hong Kong Kowloon, Hong Kong Tel: +852 3442 2010; Fax: +852 3442 0503 Email: congwang@cityu.edu.hk URL: http://www.cs.cityu.edu.hk/~congwang/ ~~~~~~~~~~~~~~~~~~~~~~ Disclaimer: This email (including any attachments) is for the use of the intended recipient only and may contain confidential information and/or copyright material. If you are not the intended recipient, please notify the sender immediately and delete this email and all copies from your system. Any unauthorized use, disclosure, reproduction, copying, distribution, or other form of unauthorized dissemination of the contents is expressly prohibited. --047d7bfd0562a0ebe804ed1d0ec6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Core Members,=A0

Please find below our call f= or paper for IEEE Internet of Things Journal Special Issue on Security for = IoT: the State of the Art (deadline: Feb. 15th, 2014). Online version is av= ailable under: <http://iot-journal.weeb= ly.com/uploads/1/8/8/0/18809834/ieee_iot_journal_si_iot_security_cfp.pdf>. =A0

We are looking forward for your= submissions, and appreciate your further help in forwarding the CFP to you= r friends and colleagues. Thanks a lot.=A0

=
Regards,=A0
Cong Wang

# CALL FOR PAPERS #

IEEE Internet of Things Journal Special Issue = on=A0
Security for IoT: the State of the Art (deadline: Feb. 15th, 2014)

A PDF version of this CFP can be d= ownloaded at:


# Sc= ope of Special Issue #

The= Internet is becoming more and more ubiquitous. One central element of this= trend is the existence of a massive network of interconnected wired/wirele= ss physical objects/things/sensors/devices, which can interact in a rich se= t of manners through a worldwide communication and information infrastructu= re and provide value added services. The vision of such an Internet of Thin= gs (IoT) system, supported by industrial companies and governments globally= , has the potential to mark an evolution that will surely have a great impa= ct on our environments and our lives. Yet, the realization of a ubiquitous = IoT also poses a number of challenges where security is among the top conce= rns. The globally interconnected physical objects inevitably result in a po= tentially enormous attack surface that can be easily exploited if without a= dequate protection. To enable strong security foundations for the ubiquitou= s IoT, plenty of factors need to be taken into account. Examples are data s= ecurity, privacy, access control, information assurance, trust management, = secure services interoperability, seamless integration, system heterogeneit= y, scalability, and mobility. This special issue solicits high-quality orig= inal research results about IoT that pertain to state-of-the-art security a= nd privacy issues in various pervasive and ubiquitous scenarios. We encoura= ge submissions on theoretical, practical, as well as experimental studies, = from both academia and industry, related to all aspects of security for IoT= . Topics of interests include (but are not limited to) the following catego= ries:

- Secure IoT architecture
=
- IoT access control and key management
- Identification and privacy for IoT
- Smart phon= e enabled secure smart systems
- New cryptographic primitives for IoT
- Manage trust for IoT service interoperability
- = Security on heterogeneous ecosystems
- Context-aware = security design
- Data security and privacy in the IoT
- Intrusion detection and defense for IoT=A0
- Joi= nt security&privacy aware protocol design
- Failu= re detection, prediction, and recovery=A0
- Secure data management within IoT
= - Trusted computing technology and IoT
- Availability= , recovery and auditing
- IoT related web services se= curity=A0
- Secure cyber-physical system
- Bio= metrics for the IoT


# Important Dates #=A0

- Submissions Deadline: February 15th, 2014 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0
- First Reviews Due: May 15th, 2014
- Revision Due: June 15th, 2014 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0
- Second Reviews Due/Acceptance letters: July 15th, 2014= =A0
- Final Manuscript Due: August 15th, 2014 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0
- Pub= lication Date: October 15th, 2014=A0


# Su= bmission Guidelines #

The = special issue seeks submission of papers that present novel original result= s and findings on Security for IoT. =A0Solicited original submissions must = not be currently under consideration for publication in other venues. Autho= r guidelines and submission information can be found at <http://iot.ieee.org/journal>. All manuscrip= ts should be submitted through Manuscript Central: <http://mc.manuscriptcentral.com/iot>=A0<= /div>


# Gu= est Editors #=A0

- Kui Ren= , University at Buffalo, SUNY <kui= ren@buffalo.edu>=A0
- Pierangela Samarati, University of Milan <pierangela.samarati@unimi.it>= =A0
- Peng Ning, NCSU, Raleigh & Samsung Mobile &= lt;pning@ncsu.edu>=A0
- Marco Gruteser, Rutgers University <gruteser@winlab.rutgers.edu>=A0
<= div dir=3D"ltr">- Yunhao Liu, Tsinghua University <yunhaoliu@gmail.com>=A0


SI P= ublicity Chair: Cong Wang, City University of Hong Kong <congwang@cityu.edu.hk>

--
~~~~~~~~~~~~~~~~~~~~~~
Cong WANG, PhD
Assistant= Professor
Computer Science Department
City University of Hong KongKowloon, Hong Kong
Tel: +852 3442 2010; Fax: +852 3442 0503
Email: = congwang@cityu.e= du.hk
URL: ht= tp://www.cs.cityu.edu.hk/~congwang/
~~~~~~~~~~~~~~~~~~~~~~


Disclaimer: This email (including any attachments) is for the use of the in= tended recipient only and may contain confidential information and/or copyr= ight material. If you are not the intended recipient, please notify the sen= der immediately and delete this email and all copies from your system. Any = unauthorized use, disclosure, reproduction, copying, distribution, or other= form of unauthorized dissemination of the contents is expressly prohibited= .


--047d7bfd0562a0ebe804ed1d0ec6-- From cabo@tzi.org Mon Dec 9 09:50:01 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C37401AE317 for ; Mon, 9 Dec 2013 09:50:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jb3hozgoGGir for ; Mon, 9 Dec 2013 09:50:01 -0800 (PST) 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 A44821AE3FA for ; Mon, 9 Dec 2013 09:50:00 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rB9Hnrlu018792 for ; Mon, 9 Dec 2013 18:49:53 +0100 (CET) Received: from [192.168.217.144] (p54890261.dip0.t-ipconnect.de [84.137.2.97]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 08858F0F; Mon, 9 Dec 2013 18:49:52 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Dec 2013 18:49:50 +0100 To: "core (core@ietf.org)" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) X-Mailer: Apple Mail (2.1822) Subject: [core] WGLC of draft-ietf-core-groupcomm-17 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 17:50:02 -0000 In Vancouver, we said we were going to WGLC the groupcomm draft after some more edits, which were submitted by the authors on 2013-11-28. All outstanding tickets are closed. The recent discussion on correlating responses to multicast requests might lead to some additional explanatory text on how to handle the correlation, but this is something we can handle during the WGLC. So this starts a working group last call for -groupcomm for submission as an informational RFC, ending on 24:00 PDT on Monday, December 23, 2013. Please start a new email thread for each major issue that will need discussion and make sure the subject line includes the draft name and some sort of name for the issue. For minor issues such as typos and things that are not likely to lead to much discussion, it is probably easier to group them all in to one email but again, please make sure the subject line includes the draft name. If you read the draft and think it looks fine, please send a one line email to the list or to the chairs letting us know that so we can get a feel of how broad the review has been. If you are aware of any patent claims that might apply to systems that implement the suggestions in this draft, please review BCP 78 and BCP 79 and make any appropriate IPR declaration. If you are not sure whether you need to make a declaration or not, please talk to the chairs and we will help get you in touch with people that can provide appropriate advice. Gr=FC=DFe, Carsten From likepeng@huawei.com Tue Dec 10 01:13:37 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3501AD83F for ; Tue, 10 Dec 2013 01:13:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wQpQiiKSjua for ; Tue, 10 Dec 2013 01:13:36 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A6E561AD6BF for ; Tue, 10 Dec 2013 01:13:35 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYV28720; Tue, 10 Dec 2013 09:13:29 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 10 Dec 2013 09:13:21 +0000 Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 10 Dec 2013 09:13:28 +0000 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.66]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0158.001; Tue, 10 Dec 2013 17:13:21 +0800 From: Likepeng To: "core@ietf.org" Thread-Topic: New Version Notification for draft-li-core-coap-node-id-option-00.txt Thread-Index: AQHO9YeJqoKe63HdIEiW7bwCa+GrbppNJAeA Date: Tue, 10 Dec 2013 09:13:20 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F252AD1329@SZXEMA501-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.167.122] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [core] Fw: New Version Notification for draft-li-core-coap-node-id-option-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 09:13:38 -0000 SGVsbG8gYWxsLA0KDQpXZSBqdXN0IHN1Ym1pdHRlZCBhIG5ldyBkcmFmdCB0byBkZWZpbmUgYSBO b2RlSWQgb3B0aW9uLCB0byBpZGVudGlmeSB0aGUgbm9kZS4NCg0KVGhpcyBpcyByZWxhdGVkIHRv IG91ciByZWNlbnQgZW1haWwgZGlzY3Vzc2lvbiBhYm91dCB0aGUgY29ycmVsYXRpb24gb2YgbXVs dGljYXN0IHJlcXVlc3QgYW5kIHJlc3BvbnNlcy4NCg0KSXQgaXMgYWxzbyB1c2VmdWwgaW4gdGVy bXMgb2YgSVAgYWRkcmVzcyBjaGFuZ2UuDQoNCkl0IGlzIHF1aXRlIHNob3J0IGFuZCBzaW1wbGUs IHNvIGl0IHdpbGwgbm90IHRha2UgeW91IHRvbyBtdWNoIHRpbWUgdG8gcmVhZC4gOi0pDQoNCkhv cGUgdG8gZ2V0IHlvdXIgZmVlZGJhY2sgaW4gdGhlIGxpc3QuDQoNClRoYW5rcywNCg0KS2luZCBS ZWdhcmRzDQpLZXBlbmcgJiBHZW5neXUNCg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu2 5Lq6OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmddIA0K5Y+R6YCB5pe26Ze0OiAyMDEz5bm0MTLmnIgxMOaXpSAxNzowOQ0K5pS25Lu25Lq6 OiBHZW5neXUgV2VpOyBMaWtlcGVuZw0K5Li76aKYOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LWxpLWNvcmUtY29hcC1ub2RlLWlkLW9wdGlvbi0wMC50eHQNCg0KDQpBIG5ldyB2 ZXJzaW9uIG9mIEktRCwgZHJhZnQtbGktY29yZS1jb2FwLW5vZGUtaWQtb3B0aW9uLTAwLnR4dA0K aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBLZXBlbmcgTGkgYW5kIHBvc3RlZCB0 byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LWxpLWNvcmUtY29hcC1u b2RlLWlkLW9wdGlvbg0KUmV2aXNpb246CSAwMA0KVGl0bGU6CQkgQ29BUCBPcHRpb24gRXh0ZW5z aW9uOiBOb2RlSWQNCkNyZWF0aW9uIGRhdGU6CSAyMDEzLTEyLTEwDQpHcm91cDoJCSBJbmRpdmlk dWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogNw0KVVJMOiAgICAgICAgICAgICBodHRw Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1saS1jb3JlLWNvYXAtbm9kZS1p ZC1vcHRpb24tMDAudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtbGktY29yZS1jb2FwLW5vZGUtaWQtb3B0aW9uDQpIdG1saXplZDogICAg ICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxpLWNvcmUtY29hcC1ub2RlLWlk LW9wdGlvbi0wMA0KDQoNCkFic3RyYWN0Og0KICAgQ29BUCBpcyBhIFJFU1RmdWwgYXBwbGljYXRp b24gcHJvdG9jb2wgZm9yIGNvbnN0cmFpbmVkIG5vZGVzIGFuZA0KICAgbmV0d29ya3MuICBUaGlz IHNwZWNpZmljYXRpb24gcHJvdmlkZXMgYSBzaW1wbGUgZXh0ZW5zaW9uIGZvciBDb0FQLA0KICAg dGhlIE5vZGVJZCBPcHRpb24uICBUaGlzIE9wdGlvbiBjYW4gYmUgdXNlZCB0byBpZGVudGlmeSB0 aGUgbm9kZSwNCiAgIGVpdGhlciB0aGUgY2xpZW50IG9yIHRoZSBzZXJ2ZXIuDQoNCk5vdGUNCg0K ICAgRGlzY3Vzc2lvbiBhbmQgc3VnZ2VzdGlvbnMgZm9yIGltcHJvdmVtZW50IGFyZSByZXF1ZXN0 ZWQsIGFuZCBzaG91bGQNCiAgIGJlIHNlbnQgdG8gY29yZUBpZXRmLm9yZy4NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1p bnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJz aW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRG IFNlY3JldGFyaWF0DQoNCg== From weigengyu@bupt.edu.cn Wed Dec 11 01:36:43 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D15C41AE033 for ; Wed, 11 Dec 2013 01:36:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.237 X-Spam-Level: * X-Spam-Status: No, score=1.237 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id va2A1RyMFpDc for ; Wed, 11 Dec 2013 01:36:40 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id A2F1D1A1F5B for ; Wed, 11 Dec 2013 01:36:37 -0800 (PST) Received: from WeiGengyuPC (unknown [10.103.241.46]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 4618319F36A; Wed, 11 Dec 2013 17:36:29 +0800 (HKT) Message-ID: From: "weigengyu" To: "Carsten Bormann" References: In-Reply-To: Date: Wed, 11 Dec 2013 17:36:30 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3505.912 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912 Cc: Core Subject: Re: [core] WG interest in Sleepy Node topic X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 09:36:44 -0000 Hi Carsten and all, I think the Sleepy node problem is important, and CoAP mailing list seems to consider intermitent node currently. While, what is the sleepy node and what is the intermitent node? What network parameter are effected and what kind of networks needs concerning? I would like to give what intermitent node (or intermitent endpoint) I concern. I think the intermitent indicates the following situations of CoAP endpoint: 1. the node will be power off and on, or reboot; 2. the node will go out and into the signal coverage, so the wireless commnication could be able and inable intermitently; 3. the node is into sleep mode in order to save power. Such a node might be the sleepy node you called. Due to its inability to reponse the request, the sleepy node may be like the intermitent node. In other words, the sleepy node is an intermitent node in nature in terms of communication ability intervals. The bootup process is required in the above cases 1, but not in the cases of 2 and 3. The network parameters , such as IP address, re-allocation is determined by the networks that the node accesses. By Esko’ email, if the node is auto-configured by DHCP server, or the like, the node could get back network configured parameters whenever reboot. But this does not means that when rebooting the node saves the parameters itself enve though flash memory is embeded. The most typical network is WIFI. When the mobile PC reboots, the DHCP server's parameters (option) determines whether to change the mobile PC's IP address. The very different network is mobile 3G/4G, the mobile node will get new IP address in the case of 1 and probably 2. The node in sleepy mode closes the data sending port and/or receiving port. The smart phone usually close both ports. (As a result signalling storm is apppeared in the mobile networks) This is case 3, and the node holds its network parameters. The communication ability will be delayed until the sleepy interval is expired. Maybe the problem of configuration is out of CoAP scope, and it is not clear what the CoAP endpoint enviroments have. Only the Resource Directory Server is depicted and may function this in the given cases. There is not a systematic processes defined to tackle sleepy or intermitent node. So, the sleepy node I concerned is case 3; the intermitent node I concerned is case 1,2 and 3. Regards, Gengyu Network Technology Center School of Computer Beijing University of Posts & Telecommunications. -----原始邮件----- From: Carsten Bormann Sent: Saturday, November 09, 2013 9:25 AM To: Thomas Fossati Cc: Core Subject: Re: [core] WG interest in Sleepy Node topic On 08 Nov 2013, at 01:48, Thomas Fossati wrote: > out of CoRE scope At this stage of the discussion, I would be less concerned with the WG scope than with finding out what the industry actually needs to be standardized to foster interoperability. If there are items within this set that are outside CoRE scope, we can always try to find a home for them, either by rechartering or by finding another WG. But it is important to have a clear understanding of the items that we think need to be speced. At a level a bit more specific than we have been discussing so far. Grüße, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From gerdes@tzi.de Wed Dec 11 05:49:07 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D17641ADE7C; Wed, 11 Dec 2013 05:49:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZ-07BSEa9s7; Wed, 11 Dec 2013 05:49:05 -0800 (PST) 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 364A81ADDDA; Wed, 11 Dec 2013 05:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rBBDksGc018161; Wed, 11 Dec 2013 14:46:55 +0100 (CET) Received: from [134.102.218.230] (dynamic-218-c.informatik.uni-bremen.de [134.102.218.230]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 7D110C4B; Wed, 11 Dec 2013 14:46:54 +0100 (CET) Message-ID: <52A86CCE.3090906@tzi.de> Date: Wed, 11 Dec 2013 14:46:54 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "core@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: saag@ietf.org, dtls-iot@ietf.org, jose@ietf.org, oauth@ietf.org Subject: [core] Invitation to New Non-WG Mailing List: Authentication and Authorization for Constrained Environments (ace) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 13:49:08 -0000 Hi everybody, As a result of discussions in the CoRE WG in Berlin and Vancouver the new non-WG mailing list Authentication and Authorization for Constrained Environments (ace) was created. The purpose of this list is to organize interest in a group to define the charter for work on Authentication and Authorization for Constrained Environments. Our mailing list can be found at (1), existing work can be found at (2), and the draft charter can be found at (3). Please feel welcome to join the list and provide your feedback! Thanks, Kind Regards Kepeng & Stefanie (1)Mailing List https://www.ietf.org/mailman/listinfo/ace (2)Existing work: Use Cases: http://tools.ietf.org/id/draft-garcia-core-security http://tools.ietf.org/id/draft-greevenbosch-core-authreq http://tools.ietf.org/id/draft-seitz-core-sec-usecases Solutions http://tools.ietf.org/id/draft-gerdes-core-dcaf-authorize http://tools.ietf.org/id/draft-kang-core-secure-reconfiguration http://tools.ietf.org/id/draft-selander-core-access-control http://tools.ietf.org/id/draft-zhu-core-groupauth http://tools.ietf.org/id/draft-pporamba-dtls-certkey http://tools.ietf.org/id/draft-schmitt-two-way-authentication-for-iot http://tools.ietf.org/id/draft-seitz-core-security-modes (3)Draft Charter - Authentication and Authorization for Constrained Environment (ACE) The CoAP (Constrained Application Protocol) is a light-weight application layer protocol, especially suitable for applications such as smart energy, smart home, building automation, remote patient monitoring etc. Due to the nature of these applications, including a critical, unattended infrastructure and usage in the personal sphere, security and privacy protection are critical components. Currently, a problem with constrained devices is the realization of such secure communication. The devices only have limited resources such as memory, storage and transmission capacity. These constraints severely limit the security functions and communications the device can perform. Missing functionality includes authentication, which provides trust and ensures an entity is who it says it is, and authorization, which defines and enforces access rights for different clients. The ACE WG focuses on providing constrained devices with the necessary prerequisites to use REST operations in a secure way. Constrained devices will thus be enabled to authenticate communications from other (constrained or less-constrained) devices, to communicate securely with them and to verify their individual authorization to access specific resources. To achieve this, ACE will be able to employ an architecture with one or more trusted less-constrained devices which will relieve the constrained nodes from complex security related tasks (e.g. managing authorization policies and a large number of keys). ACE will use CoAP and employ security properties of DTLS whenever possible. The ACE WG has the following tasks: - Document the use cases and high-level requirements for secured communication between constrained devices. - Define certificate profiling (what kinds of certificates and which attributes are to be used). - Define a mechanism for authenticated and protected transfer of authorization information suitable for constrained device to constrained device communication. - Define an access ticket and authorization information format suitable for constrained devices. - Define bootstrapping for authorization information using the Resource Directory. From rstruik.ext@gmail.com Wed Dec 11 06:45:24 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C8D1ADF81; Wed, 11 Dec 2013 06:45:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_INVITATION=-2, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdY_MpxXnw2h; Wed, 11 Dec 2013 06:45:21 -0800 (PST) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 581201ADF80; Wed, 11 Dec 2013 06:45:21 -0800 (PST) Received: by mail-ig0-f179.google.com with SMTP id hk11so847716igb.0 for ; Wed, 11 Dec 2013 06:45:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=scWuz0UoFiPFuRINImNeTz68NxM7A/ZPXBXnVRbrz58=; b=ajoarEEUcuuSlhu4jc+Lmw7INGKir3YpySyrYDOd8no2qdbpDsLvPfvufjn+aILQm3 bfw/oVgUTzA9sp6u/plb//bwp0z97PMV5rqoEkxKJwVk7b6BvM1xNWhWzPlWOTlv8VvB jIULTafdkyroeMHxaGdbLkn9LjabYToAxK2t4t1bjGzod64ADaOvgOSQDvSeO8OMqKx7 YJyK4s0jUjdBfeE0giwEiapC2Y8DkLmxyXl/b2dWoSZDCcfD07XUd3ouj3Qd+aQsa97f c2acJiQmuW7reKDChnFPjoqsKeI7PHV6HMcjJ/DT2LgPFl6wnp+2VMp/YaPlxQpveDNN tXJA== X-Received: by 10.42.208.211 with SMTP id gd19mr1165897icb.15.1386773115664; Wed, 11 Dec 2013 06:45:15 -0800 (PST) Received: from [192.168.1.103] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.230.254.17]) by mx.google.com with ESMTPSA id k6sm9308420igx.8.2013.12.11.06.45.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Dec 2013 06:45:14 -0800 (PST) Message-ID: <52A87A6F.8030304@gmail.com> Date: Wed, 11 Dec 2013 09:45:03 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Stefanie Gerdes , "core@ietf.org" References: <52A86CCE.3090906@tzi.de> In-Reply-To: <52A86CCE.3090906@tzi.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: saag@ietf.org, dtls-iot@ietf.org, jose@ietf.org, oauth@ietf.org Subject: Re: [core] Invitation to New Non-WG Mailing List: Authentication and Authorization for Constrained Environments (ace) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 14:45:24 -0000 [apologies for replying to all the IETF lists in the original cc] Dear colleagues: I have some initial feedback on the potential draft charter. I believe it is really premature to write potential point solutions into = a draft charter, in casu definition of a less constrained device that can= be used to outsource computational, storage, or management functionality= to. (Does this imply one envisions to have to buy a separate box/single = point of failure to take on this task?) It would make much more sense to = look into this problem space in terms of requirements first, with an eye = towards scalability towards billion+ devices. This does not preclude this= potential solution direction, but questions as to what this entails in t= erms of usability, scalability, and communications impact need to be clea= r first. This is an ambitious undertaking and many efforts in the past ha= ve been far less successful than initially thought. There is also an unde= rcurrent in the draft charter text that there is a need for different "de= vice types", which is not a priori clear. To realize the full potential o= f constrained networks, one should reflect upon "trust" endowed upon sing= le nodes, of whatever type, and consider limiting the impact of violation= of this trust, should this occur, as an explicit design criterium. In the end, this may be an undertaking that would be suitable as an IAB w= ork item, considering potential scope. Best regards, Rene =3D=3D To achieve this, ACE will be able to employ an architecture with one or more trusted less-constrained devices which will relieve the constrained nodes from complex security related tasks (e.g. managing authorization policies and a large number of keys). ACE will use CoAP and employ security properties of DTLS whenever possible. On 12/11/2013 8:46 AM, Stefanie Gerdes wrote: > Hi everybody, > > As a result of discussions in the CoRE WG in Berlin and Vancouver the > new non-WG mailing list Authentication and Authorization for Constraine= d > Environments (ace) was created. > > The purpose of this list is to organize interest in a group to define > the charter for work on Authentication and Authorization for Constraine= d > Environments. > > Our mailing list can be found at (1), existing work can be found at (2)= , > and the draft charter can be found at (3). > > Please feel welcome to join the list and provide your feedback! > > Thanks, > > Kind Regards > Kepeng & Stefanie > > > (1)Mailing List > > https://www.ietf.org/mailman/listinfo/ace > > (2)Existing work: > > Use Cases: > http://tools.ietf.org/id/draft-garcia-core-security > http://tools.ietf.org/id/draft-greevenbosch-core-authreq > http://tools.ietf.org/id/draft-seitz-core-sec-usecases > > Solutions > http://tools.ietf.org/id/draft-gerdes-core-dcaf-authorize > http://tools.ietf.org/id/draft-kang-core-secure-reconfiguration > http://tools.ietf.org/id/draft-selander-core-access-control > http://tools.ietf.org/id/draft-zhu-core-groupauth > http://tools.ietf.org/id/draft-pporamba-dtls-certkey > http://tools.ietf.org/id/draft-schmitt-two-way-authentication-for-iot > http://tools.ietf.org/id/draft-seitz-core-security-modes > > (3)Draft Charter - Authentication and Authorization for Constrained > Environment (ACE) > > The CoAP (Constrained Application Protocol) is a light-weight > application layer protocol, especially suitable for applications such a= s > smart energy, smart home, building automation, remote patient monitorin= g > etc. Due to the nature of these applications, including a critical, > unattended infrastructure and usage in the personal sphere, security an= d > privacy protection are critical components. > > Currently, a problem with constrained devices is the realization of suc= h > secure communication. The devices only have limited resources such as > memory, storage and transmission capacity. These constraints severely > limit the security functions and communications the device can perform.= > Missing functionality includes authentication, which provides trust and= > ensures an entity is who it says it is, and authorization, which define= s > and enforces access rights for different clients. > > The ACE WG focuses on providing constrained devices with the necessary > prerequisites to use REST operations in a secure way. Constrained > devices will thus be enabled to authenticate communications from other > (constrained or less-constrained) devices, to communicate securely with= > them and to verify their individual authorization to access specific > resources. To achieve this, ACE will be able to employ an architecture > with one or more trusted less-constrained devices which will relieve th= e > constrained nodes from complex security related tasks (e.g. managing > authorization policies and a large number of keys). ACE will use CoAP > and employ security properties of DTLS whenever possible. > > The ACE WG has the following tasks: > - Document the use cases and high-level requirements for secured > communication between constrained devices. > - Define certificate profiling (what kinds of certificates and which > attributes are to be used). > - Define a mechanism for authenticated and protected transfer of > authorization information suitable for constrained device to constraine= d > device communication. > - Define an access ticket and authorization information format suitable= > for constrained devices. > - Define bootstrapping for authorization information using the Resource= > Directory. --=20 email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From pete.st.pierre@oracle.com Wed Dec 11 08:09:07 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33DCA1AE04F for ; Wed, 11 Dec 2013 08:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOXTG3jEIK2Z for ; Wed, 11 Dec 2013 08:09:04 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 27A861AE03E for ; Wed, 11 Dec 2013 08:09:04 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rBBG8f0g019915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Dec 2013 16:08:42 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rBBG8dIi009156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Dec 2013 16:08:41 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rBBG8c2L009080; Wed, 11 Dec 2013 16:08:38 GMT Received: from [192.168.1.9] (/99.57.137.67) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 11 Dec 2013 08:08:38 -0800 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_CBECDC9D-AB16-4F04-BD79-5D6250BA54FA" From: "Pete St. Pierre" X-Priority: 3 In-Reply-To: Date: Wed, 11 Dec 2013 08:08:38 -0800 Message-Id: <5E4E8105-A550-492D-85E4-A0AF283B441C@oracle.com> References: To: weigengyu X-Mailer: Apple Mail (2.1510) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: Core Subject: Re: [core] WG interest in Sleepy Node topic X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 16:09:07 -0000 --Apple-Mail=_CBECDC9D-AB16-4F04-BD79-5D6250BA54FA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I agree with your assessment of #1 & #2. However, I don't think it is = fair to assume in scenario #3 that network parameters can be assumed to = remain unchanged. I've worked with devices that were used as you = describe case #3, but when nodes awoke, they were highly likely to be in = a different place with a different network environment. In many cases, a = complete change of network was required (ie WiFi to 3G or Satellite). Similarly, isn't a laptop a sleepy node? It sleeps when the lid is = closed and doesn't reboot every time it is opened. However it frequently = comes back on the network in a place where the network environment has = changed.=20 #3 may be true, but only if the node is 'sleepy' and stationary. ...Pete On Dec 11, 2013, at 1:36 AM, weigengyu wrote: > Hi Carsten and all, >=20 > I think the Sleepy node problem is important, and CoAP mailing list = seems to consider intermitent node currently. > While, what is the sleepy node and what is the intermitent node? > What network parameter are effected and what kind of networks needs = concerning? >=20 > I would like to give what intermitent node (or intermitent endpoint) I = concern. > I think the intermitent indicates the following situations of CoAP = endpoint: > 1. the node will be power off and on, or reboot; > 2. the node will go out and into the signal coverage, so the wireless = commnication could be able and inable intermitently; > 3. the node is into sleep mode in order to save power. Such a node = might be the sleepy node you called. > Due to its inability to reponse the request, the sleepy node may be = like the intermitent node. > In other words, the sleepy node is an intermitent node in nature in = terms of communication ability intervals. >=20 > The bootup process is required in the above cases 1, but not in the = cases of 2 and 3. > The network parameters , such as IP address, re-allocation is = determined by the networks that the node accesses. >=20 > By Esko=E2=80=99 email, if the node is auto-configured by DHCP server, = or the like, > the node could get back network configured parameters whenever reboot. > But this does not means that when rebooting the node saves the = parameters itself enve though flash memory is embeded. > The most typical network is WIFI. When the mobile PC reboots, > the DHCP server's parameters (option) determines whether to change the = mobile PC's IP address. >=20 > The very different network is mobile 3G/4G, the mobile node will get = new IP address in the case of 1 and probably 2. > The node in sleepy mode closes the data sending port and/or receiving = port. > The smart phone usually close both ports. (As a result signalling = storm is apppeared in the mobile networks) > This is case 3, and the node holds its network parameters. The = communication ability will be delayed until the sleepy interval is = expired. >=20 > Maybe the problem of configuration is out of CoAP scope, and it is = not clear what the CoAP endpoint enviroments have. > Only the Resource Directory Server is depicted and may function this = in the given cases. >=20 > There is not a systematic processes defined to tackle sleepy or = intermitent node. >=20 > So, the sleepy node I concerned is case 3; the intermitent node I = concerned is case 1,2 and 3. >=20 > Regards, >=20 > Gengyu >=20 > Network Technology Center > School of Computer > Beijing University of Posts & Telecommunications. >=20 >=20 > -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- From: Carsten Bormann > Sent: Saturday, November 09, 2013 9:25 AM > To: Thomas Fossati > Cc: Core > Subject: Re: [core] WG interest in Sleepy Node topic >=20 > On 08 Nov 2013, at 01:48, Thomas Fossati wrote: >=20 >> out of CoRE scope >=20 > At this stage of the discussion, I would be less concerned with the WG = scope than with finding out what the industry actually needs to be = standardized to foster interoperability. If there are items within this = set that are outside CoRE scope, we can always try to find a home for = them, either by rechartering or by finding another WG. But it is = important to have a clear understanding of the items that we think need = to be speced. At a level a bit more specific than we have been = discussing so far. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core -- Pete St. Pierre Pete.St.Pierre@oracle.com (650) 506-2152 --Apple-Mail=_CBECDC9D-AB16-4F04-BD79-5D6250BA54FA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = agree with your assessment of #1 & #2. However, I don't think it is = fair to assume in scenario #3 that network parameters can be assumed to = remain unchanged. I've worked with devices that were used as you = describe case #3, but when nodes awoke, they were highly likely to be in = a different place with a different network environment. In many cases, a = complete change of network was required (ie WiFi to 3G or = Satellite).

Similarly, isn't a laptop a sleepy node? = It sleeps when the lid is closed and doesn't reboot every time it is = opened. However it frequently comes back on the network in a place where = the network environment has changed. 

#3 = may be true, but only if the node is 'sleepy' and = stationary.
...Pete

On Dec = 11, 2013, at 1:36 AM, weigengyu <weigengyu@bupt.edu.cn> = wrote:

Hi Carsten and all,

I think the Sleepy node problem = is important, and CoAP mailing list seems to consider intermitent node = currently.
While, what is the sleepy node and what is the intermitent = node?
What network parameter are effected and what kind of networks = needs concerning?

I would like to give what intermitent node (or = intermitent endpoint) I concern.
I think the intermitent indicates = the following situations of CoAP endpoint:
1. the node will be power = off and on, or reboot;
2. the node will go out and into the signal = coverage, so the wireless commnication could be able and inable = intermitently;
3. the node is into sleep mode in order to save power. = Such a node might be the sleepy node you called.
  Due to = its inability to reponse the request, the sleepy node may be like the = intermitent node.
 In other words, the sleepy node is an = intermitent node in nature in terms of communication ability = intervals.

The  bootup process is required in the above = cases 1, but not in the cases of 2 and 3.
The network parameters , = such as IP address, re-allocation is determined by the networks that the = node accesses.

By Esko=E2=80=99 email, if the node is = auto-configured by DHCP server, or the like,
the node could get back = network configured parameters whenever reboot.
But this does not = means that when rebooting the node saves the parameters itself enve = though flash memory is embeded.
The most typical network is WIFI. =  When the mobile PC reboots,
the DHCP server's parameters = (option) determines whether to change the mobile PC's IP = address.

The very different network is mobile 3G/4G, the mobile = node will get new IP address in the case of 1 and  probably = 2.
The node in sleepy mode closes the data sending port and/or = receiving port.
The smart phone usually close both ports. (As a = result signalling storm is apppeared in the mobile networks)
This is = case 3, and the node holds its network parameters. The communication = ability will be delayed until the sleepy interval is = expired.

Maybe the problem of configuration is out of CoAP scope, =  and it is not clear what the CoAP endpoint enviroments = have.
Only the Resource Directory Server is depicted  and may = function this in the given cases.

There is not a systematic = processes defined to tackle sleepy or intermitent node.

So, the = sleepy node I concerned is case 3; the intermitent node I concerned is = case 1,2 and 3.

Regards,

Gengyu

Network Technology = Center
School of Computer
Beijing University of Posts & = Telecommunications.


-----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6--= --- From: Carsten Bormann
Sent: Saturday, November 09, 2013 9:25 = AM
To: Thomas Fossati
Cc: Core
Subject: Re: [core] WG interest = in Sleepy Node topic

On 08 Nov 2013, at 01:48, Thomas Fossati = <tho@koanlogic.com> = wrote:

out of CoRE = scope

At this stage of the discussion, I would be = less concerned with the WG scope than with finding out what the industry = actually needs to be standardized to foster interoperability.  If = there are items within this set that are outside CoRE scope, we can = always try to find a home for them, either by rechartering or by finding = another WG.  But it is important to have a clear understanding of = the items that we think need to be speced.  At a level a bit more = specific than we have been discussing so far.

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

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

--
Pete St. Pierre
Pete.St.Pierre@oracle.com
(650) = 506-2152

= --Apple-Mail=_CBECDC9D-AB16-4F04-BD79-5D6250BA54FA-- From kovatsch@inf.ethz.ch Wed Dec 11 10:55:30 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBF41AE050 for ; Wed, 11 Dec 2013 10:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uU1MCWL2TnYI for ; Wed, 11 Dec 2013 10:55:28 -0800 (PST) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1721ADF74 for ; Wed, 11 Dec 2013 10:55:27 -0800 (PST) Received: from CAS22.d.ethz.ch (172.31.51.112) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 11 Dec 2013 19:55:18 +0100 Received: from MBX210.d.ethz.ch ([fe80::ed77:7d47:9467:69a9]) by CAS22.d.ethz.ch ([fe80::dd0e:466a:b055:c090%10]) with mapi id 14.02.0298.004; Wed, 11 Dec 2013 19:55:20 +0100 From: "Kovatsch Matthias" To: Bill Silverajan , "core@ietf.org" Thread-Topic: [core] New Version: CoAP with Alternative Transports Thread-Index: AQHOzu3GcyDXw0vYW02AV6l1Ubz1PJpPpPyg Date: Wed, 11 Dec 2013 18:55:20 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B51C171C3E@MBX210.d.ethz.ch> References: <5266173F.8050707@tut.fi> In-Reply-To: <5266173F.8050707@tut.fi> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.130.253] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [core] New Version: CoAP with Alternative Transports X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 18:55:30 -0000 Hi Bill, dear list Before I forget, here a comment on the URI format for alternative transport= s that arose during the Vancouver meeting: Since we all saw some interesting ways to encode the transport, I think we = should make sure that we can actually encode such URIs in CoAP. Luckily, th= e Proxy-Uri option is a string and can hold any format, but we also have th= e separate Proxy-Scheme and Uri-* options... Ciao Matthias From internet-drafts@ietf.org Wed Dec 11 18:26:40 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA871ADBD1; Wed, 11 Dec 2013 18:26:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBsE7eq-TnRj; Wed, 11 Dec 2013 18:26:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CDCC1ADF38; Wed, 11 Dec 2013 18:26:38 -0800 (PST) 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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131212022638.28191.71553.idtracker@ietfa.amsl.com> Date: Wed, 11 Dec 2013 18:26:38 -0800 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-resource-directory-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 02:26:40 -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 : CoRE Resource Directory Author(s) : Zach Shelby Carsten Bormann Srdjan Krco Filename : draft-ietf-core-resource-directory-01.txt Pages : 28 Date : 2013-12-11 Abstract: In many M2M applications, direct discovery of resources is not practical due to sleeping nodes, disperse networks, or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which hosts descriptions of resources held on other servers, allowing lookups to be performed for those resources. This document specifies the web interfaces that a Resource Directory supports in order for web servers to discover the RD and to register, maintain, lookup and remove resources descriptions. Furthermore, new link attributes useful in conjunction with an RD are defined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-resource-directory-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-resource-directory-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Wed Dec 11 18:27:36 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 343B31AE1AE; Wed, 11 Dec 2013 18:27:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LrWY-AgfijB; Wed, 11 Dec 2013 18:27:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 843C51AE1B1; Wed, 11 Dec 2013 18:27:34 -0800 (PST) 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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131212022734.4141.24897.idtracker@ietfa.amsl.com> Date: Wed, 11 Dec 2013 18:27:34 -0800 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-interfaces-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 02:27:36 -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 : CoRE Interfaces Author(s) : Zach Shelby Matthieu Vial Filename : draft-ietf-core-interfaces-01.txt Pages : 25 Date : 2013-12-11 Abstract: This document defines well-known REST interface descriptions for Batch, Sensor, Parameter and Actuator types for use in contrained web servers using the CoRE Link Format. A short reference is provided for each type that can be efficiently included in the interface description attribute of the CoRE Link Format. These descriptions are intended to be for general use in resource designs or for inclusion in more specific interface profiles. In addition, this document defines the concepts of Function Set and Binding. The former is the basis element to create RESTful profiles and the latter helps the configuration of links between resources located on one or more endpoints. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-interfaces There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-interfaces-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-interfaces-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From bilhanan.silverajan@tut.fi Thu Dec 12 00:00:52 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F0D1AE17F for ; Thu, 12 Dec 2013 00:00:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.431 X-Spam-Level: X-Spam-Status: No, score=-3.431 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_WEB=0.77, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxfaSX2DglL8 for ; Thu, 12 Dec 2013 00:00:49 -0800 (PST) Received: from mail.cs.tut.fi (mail.cs.tut.fi [130.230.4.42]) by ietfa.amsl.com (Postfix) with SMTP id 886851ADF46 for ; Thu, 12 Dec 2013 00:00:49 -0800 (PST) Received: from amavis1.cs.tut.fi (amavis1.cs.tut.fi [130.230.4.69]) by mail.cs.tut.fi (Postfix) with ESMTP id 5B5B32D0; Thu, 12 Dec 2013 10:00:42 +0200 (EET) Received: from mail.cs.tut.fi ([130.230.4.42]) by amavis1.cs.tut.fi (amavis1.cs.tut.fi [130.230.4.69]) (amavisd-maia, port 10024) with ESMTP id 26827-14; Thu, 12 Dec 2013 10:00:41 +0200 (EET) Received: from kali.local (unknown [192.100.124.156]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.tut.fi (Postfix) with ESMTP id D75312CF; Thu, 12 Dec 2013 10:00:40 +0200 (EET) Message-ID: <52A96D2B.7050903@tut.fi> Date: Thu, 12 Dec 2013 10:00:43 +0200 From: Bill Silverajan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Kovatsch Matthias , "core@ietf.org" References: <5266173F.8050707@tut.fi> <55877B3AFB359744BA0F2140E36F52B51C171C3E@MBX210.d.ethz.ch> In-Reply-To: <55877B3AFB359744BA0F2140E36F52B51C171C3E@MBX210.d.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.2 Subject: Re: [core] New Version: CoAP with Alternative Transports X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 08:00:52 -0000 Hi Matthias, > > Before I forget, here a comment on the URI format for alternative transports that arose during the Vancouver meeting: > Since we all saw some interesting ways to encode the transport, I think we should make sure that we can actually encode such URIs in CoAP. Luckily, the Proxy-Uri option is a string and can hold any format, but we also have the separate Proxy-Scheme and Uri-* options... > Thanks, it's a very good point regarding current (and any future) option encoding. We're taking care to ensure the syntax and encoding for the alternative transport URIs conform with RFC 3986 in terms of the scheme, host/port, path and query components. Eg in our draft -03, the last paragraphs of sections 2.2 and 2.3 highlight the encoding issues. All the options you mentioned (except uri-port) are strings without applying percent-encoding. When composing and decomposing the URI to/from options, the algorithms in sections 6.4 and 6.5 of core-coap-18 would also be helpful as a litmus test to determine which URIs for alternative transports we should settle upon. Regards, Bill From weigengyu@bupt.edu.cn Thu Dec 12 00:57:07 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 806221AE13E for ; Thu, 12 Dec 2013 00:57:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVwas6GccUXE for ; Thu, 12 Dec 2013 00:57:03 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id D04D51AE0B7 for ; Thu, 12 Dec 2013 00:57:01 -0800 (PST) Received: from WeiGengyuPC (unknown [10.103.241.46]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id AE7D519F3AE; Thu, 12 Dec 2013 16:56:53 +0800 (HKT) Message-ID: <91302396E7964EEF8A4C93B5DF46AF4C@WeiGengyuPC> From: "weigengyu" To: "Pete St. Pierre" References: <5E4E8105-A550-492D-85E4-A0AF283B441C@oracle.com> In-Reply-To: <5E4E8105-A550-492D-85E4-A0AF283B441C@oracle.com> Date: Thu, 12 Dec 2013 16:56:56 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004B_01CEF75B.2A34C8B0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3505.912 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912 Cc: Core Subject: Re: [core] WG interest in Sleepy Node topic X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 08:57:07 -0000 һ MIME ʽĶ෽ʼ ------=_NextPart_000_004B_01CEF75B.2A34C8B0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Pete,=20 You are right.=20 #3 in my email just considered the stationary case.=20 Yours is general.=20 regards, Gengyu=20 Network Technology Center=20 School of Computer Beijing University of Posts & Telecommunications From: Pete St. Pierre=20 Sent: Thursday, December 12, 2013 12:08 AM To: weigengyu=20 Cc: Carsten Bormann ; Core=20 Subject: Re: [core] WG interest in Sleepy Node topic I agree with your assessment of #1 & #2. However, I don't think it is = fair to assume in scenario #3 that network parameters can be assumed to = remain unchanged. I've worked with devices that were used as you = describe case #3, but when nodes awoke, they were highly likely to be in = a different place with a different network environment. In many cases, a = complete change of network was required (ie WiFi to 3G or Satellite).=20 Similarly, isn't a laptop a sleepy node? It sleeps when the lid is = closed and doesn't reboot every time it is opened. However it frequently = comes back on the network in a place where the network environment has = changed.=20 #3 may be true, but only if the node is 'sleepy' and stationary. ...Pete On Dec 11, 2013, at 1:36 AM, weigengyu wrote: Hi Carsten and all, I think the Sleepy node problem is important, and CoAP mailing list = seems to consider intermitent node currently. While, what is the sleepy node and what is the intermitent node? What network parameter are effected and what kind of networks needs = concerning? I would like to give what intermitent node (or intermitent endpoint) I = concern. I think the intermitent indicates the following situations of CoAP = endpoint: 1. the node will be power off and on, or reboot; 2. the node will go out and into the signal coverage, so the wireless = commnication could be able and inable intermitently; 3. the node is into sleep mode in order to save power. Such a node = might be the sleepy node you called. Due to its inability to reponse the request, the sleepy node may be = like the intermitent node. In other words, the sleepy node is an intermitent node in nature in = terms of communication ability intervals. The bootup process is required in the above cases 1, but not in the = cases of 2 and 3. The network parameters , such as IP address, re-allocation is = determined by the networks that the node accesses. By Esko=E2=80=99 email, if the node is auto-configured by DHCP server, = or the like, the node could get back network configured parameters whenever reboot. But this does not means that when rebooting the node saves the = parameters itself enve though flash memory is embeded. The most typical network is WIFI. When the mobile PC reboots, the DHCP server's parameters (option) determines whether to change the = mobile PC's IP address. The very different network is mobile 3G/4G, the mobile node will get = new IP address in the case of 1 and probably 2. The node in sleepy mode closes the data sending port and/or receiving = port. The smart phone usually close both ports. (As a result signalling = storm is apppeared in the mobile networks) This is case 3, and the node holds its network parameters. The = communication ability will be delayed until the sleepy interval is = expired. Maybe the problem of configuration is out of CoAP scope, and it is = not clear what the CoAP endpoint enviroments have. Only the Resource Directory Server is depicted and may function this = in the given cases. There is not a systematic processes defined to tackle sleepy or = intermitent node. So, the sleepy node I concerned is case 3; the intermitent node I = concerned is case 1,2 and 3. Regards, Gengyu Network Technology Center School of Computer Beijing University of Posts & Telecommunications. -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- From: Carsten Bormann Sent: Saturday, November 09, 2013 9:25 AM To: Thomas Fossati Cc: Core Subject: Re: [core] WG interest in Sleepy Node topic On 08 Nov 2013, at 01:48, Thomas Fossati wrote: out of CoRE scope At this stage of the discussion, I would be less concerned with the WG = scope than with finding out what the industry actually needs to be = standardized to foster interoperability. If there are items within this = set that are outside CoRE scope, we can always try to find a home for = them, either by rechartering or by finding another WG. But it is = important to have a clear understanding of the items that we think need = to be speced. At a level a bit more specific than we have been = discussing so far. Gr=C3=BC=C3=9Fe, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core=20 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core -- Pete St. Pierre Pete.St.Pierre@oracle.com (650) 506-2152 ------=_NextPart_000_004B_01CEF75B.2A34C8B0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Pete,
 
You are right.
#3 in my email just considered the stationary case.
Yours is general.
 
regards,
 
Gengyu
Network Technology Center =
School of Computer
Beijing University of Posts &=20 Telecommunications
 
Sent: Thursday, December 12, 2013 12:08 AM
Subject: Re: [core] WG interest in Sleepy Node=20 topic
 
I=20 agree with your assessment of #1 & #2. However, I don't think it is = fair to=20 assume in scenario #3 that network parameters can be assumed to remain=20 unchanged. I've worked with devices that were used as you describe case = #3, but=20 when nodes awoke, they were highly likely to be in a different place = with a=20 different network environment. In many cases, a complete change of = network was=20 required (ie WiFi to 3G or Satellite).=20
 
Similarly, isn't a laptop a sleepy node? It sleeps when the lid is = closed=20 and doesn't reboot every time it is opened. However it frequently comes = back on=20 the network in a place where the network environment has changed.
 
#3 may be true, but only if the node is 'sleepy' and = stationary.
...Pete
 
On Dec 11, 2013, at 1:36 AM, weigengyu <weigengyu@bupt.edu.cn>=20 wrote:

Hi Carsten and all,

I think the Sleepy = node=20 problem is important, and CoAP mailing list seems to consider = intermitent node=20 currently.
While, what is the sleepy node and what is the = intermitent=20 node?
What network parameter are effected and what kind of networks = needs=20 concerning?

I would like to give what intermitent node (or = intermitent=20 endpoint) I concern.
I think the intermitent indicates the = following=20 situations of CoAP endpoint:
1. the node will be power off and on, = or=20 reboot;
2. the node will go out and into the signal coverage, so = the=20 wireless commnication could be able and inable intermitently;
3. = the node=20 is into sleep mode in order to save power. Such a node might be the = sleepy=20 node you called.
  Due to its inability to reponse the = request, the=20 sleepy node may be like the intermitent node.
In other words, the = sleepy=20 node is an intermitent node in nature in terms of communication = ability=20 intervals.

The  bootup process is required in the above = cases 1,=20 but not in the cases of 2 and 3.
The network parameters , such as = IP=20 address, re-allocation is determined by the networks that the node=20 accesses.

By Esko=E2=80=99 email, if the node is = auto-configured by DHCP=20 server, or the like,
the node could get back network configured = parameters=20 whenever reboot.
But this does not means that when rebooting the = node saves=20 the parameters itself enve though flash memory is embeded.
The most = typical=20 network is WIFI.  When the mobile PC reboots,
the DHCP = server's=20 parameters (option) determines whether to change the mobile PC's IP=20 address.

The very different network is mobile 3G/4G, the mobile = node=20 will get new IP address in the case of 1 and  probably 2.
The = node in=20 sleepy mode closes the data sending port and/or receiving port.
The = smart=20 phone usually close both ports. (As a result signalling storm is = apppeared in=20 the mobile networks)
This is case 3, and the node holds its network = parameters. The communication ability will be delayed until the sleepy = interval is expired.

Maybe the problem of configuration is out = of CoAP=20 scope,  and it is not clear what the CoAP endpoint enviroments=20 have.
Only the Resource Directory Server is depicted  and may = function=20 this in the given cases.

There is not a systematic processes = defined to=20 tackle sleepy or intermitent node.

So, the sleepy node I = concerned is=20 case 3; the intermitent node I concerned is case 1,2 and=20 3.

Regards,

Gengyu

Network Technology = Center
School of=20 Computer
Beijing University of Posts &=20 = Telecommunications.


-----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6-= ---- From: Carsten Bormann
Sent:=20 Saturday, November 09, 2013 9:25 AM
To: Thomas Fossati
Cc:=20 Core
Subject: Re: [core] WG interest in Sleepy Node topic

On = 08 Nov=20 2013, at 01:48, Thomas Fossati <tho@koanlogic.com> = wrote:

out of CoRE scope

At = this stage of=20 the discussion, I would be less concerned with the WG scope than with = finding=20 out what the industry actually needs to be standardized to foster=20 interoperability.  If there are items within this set that are = outside=20 CoRE scope, we can always try to find a home for them, either by = rechartering=20 or by finding another WG.  But it is important to have a clear=20 understanding of the items that we think need to be speced.  At a = level a=20 bit more specific than we have been discussing so = far.

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

_______________________________________________
core = mailing=20 list
core@ietf.org
https://www.ietf.org/m= ailman/listinfo/core=20
_______________________________________________
core mailing=20 = list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
 
--
Pete=20 St. Pierre
Pete.St.Pierre@oracle.com (650)=20 506-2152
=
 
------=_NextPart_000_004B_01CEF75B.2A34C8B0-- From thomas.fossati@alcatel-lucent.com Sat Dec 14 13:28:51 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B65E81AD73E for ; Sat, 14 Dec 2013 13:28:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TgWUdzEOLAtH for ; Sat, 14 Dec 2013 13:28:35 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 61AA61AD73F for ; Sat, 14 Dec 2013 13:28:26 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id rBELSIfk026824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 14 Dec 2013 15:28:19 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id rBELSHqH012194 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 14 Dec 2013 22:28:17 +0100 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.153]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Sat, 14 Dec 2013 22:28:17 +0100 From: "FOSSATI, Thomas (Thomas)" To: "core (core@ietf.org)" Thread-Topic: WGLC comments for draft-ietf-core-groupcomm-17 Thread-Index: AQHO+RNnaMhII7lMuEy2T0VkoimTyw== Date: Sat, 14 Dec 2013 21:28:17 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="utf-8" Content-ID: <4E792C17B2B5404E94396D599B1E667E@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: [core] WGLC comments for draft-ietf-core-groupcomm-17 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Dec 2013 21:28:52 -0000 X-List-Received-Date: Sat, 14 Dec 2013 21:28:52 -0000 SGkgQWtiYXIsIEVza28uDQoNCkdvb2Qgam9iIHdpdGggdGhlIGRvY3VtZW50LiAgVGhlIOKAnFVz ZSBDYXNlc+KAnSBzZWN0aW9uIGlzIGVzcGVjaWFsbHkNCmVuam95YWJsZS4NCg0KVGhlcmUgYXJl IG5vIG1ham9yIGlzc3VlcyBvbiBteSBzaWRlOyB0aGUgZm9sbG93aW5nIGNvbW1lbnRzIGFyZSBt b3N0bHkNCmVkaXRvcmlhbC4NCg0KQ2hlZXJzLCBUaG9tYXMuDQoNClNlY3Rpb24gMS4xDQoNCi0g aHR0cGJpcyBoYXMgYmVlbiBzZW50IHRvIElFU0cgZm9yIHB1YmxpY2F0aW9uLCBJIGd1ZXNzIGl0 J3Mgb2sgdG8NCnJlZmVyZW5jZSBpdCBpbnN0ZWFkIG9mIDI2MTY7DQotIGxhc3QgcGFyYTogaXQn ZCBiZSBzdXBlciBuaWNlIHRvIGhhdmUgcG9pbnRlcnMgdG8gc2VjdGlvbnMgd2hpbGUgdG9waWNz DQphcmUgZW51bWVyYXRlZDsNCg0KU2VjdGlvbiAxLjMNCg0KLSAiSVAgbXVsdGljYXN0IiBkZWZp bml0aW9uIGNvdWxkIGJlIG1hZGUgYSBiaXQgcmljaGVyPyAgVG8gbWUgSVANCm11bHRpY2FzdCBp cyBub3QganVzdCBhIG1hdHRlciBvZiBhZGRyZXNzaW5nLCBpcyBhbHNvIHRoZSBtZW1iZXJzaGlw DQptYW5hZ2VtZW50LCB0aGUgcm91dGluZyBhbmQgZm9yd2FyZGluZywgdGhlIGFic3RyYWN0aW9u IGJ1aWx0IG9uIHRvcCBvZg0KZGlmZmVyZW50IEwyIHByb3RvY29scy4NCg0KU2VjdGlvbiAyLjIN Cg0KLSBmaXJzdCBwYXJhOiBpcyBpdCBuZWNlc3NhcnkgZm9yIHRoZSB0d28gTUFZJ3MgdG8gYmUg UkZDMjExOT8NCi0gc2Vjb25kIHBhcmEsIGxhc3Qgc2VudGVuY2U6IGlzIHRoZXJlIGFueSByZWFz b24gd2h5IHRoZSAibWF5IGFsc28gYmUNCmVuYWJsZWQiIGlzIG5vdCBSRkMyMTE5Pw0KLSBmb3Vy dGggcGFyYTogaXQncyBub3QgY2xlYXIgdG8gbWUgd2hhdCB0aGUgImdyb3VwIGNvbW11bmljYXRp b24gcmVxdWVzdA0KQVBJIiBpcw0KLSBmaWZ0aCBwYXJhOiBpcyB0aGUgIkl0IGlzIHJlY29tbWVu ZGVkIiBtZWFudCB0byBiZSBSRkMyMTE5Pw0KLSBsYXN0IHBhcmE6IG5vdCBjbGVhciB3aGF0IHRo ZSB1c2UgY2FzZSBmb3IgdGhlIHJldmVyc2UgRE5TIG1hcHBpbmcgd291bGQNCmJlLg0KDQpTZWN0 aW9uIDIuMw0KDQotIGlzbid0IGJ1bGxldCAzLiAoaS5lLiB1c2UgdGhlIGRlZmF1bHQgQ29BUCBw b3J0KSBqdXN0IGEgc3BlY2lhbCBjYXNlIG9mDQoxLiAoaS5lLiBwcmUtY29uZmlndXJlZCBwb3J0 IG51bWJlcik/DQoNClNlY3Rpb24gMi40DQoNCi0gSSBndWVzcyBpdCdzIHRoZSB1bnJlbGlhYmxl IChtb3JlIHRoZW4gdGhlIGxvc3N5KSBuYXR1cmUgb2YgSVAgbXVsdGljYXN0DQp0aGF0IG1ha2Vz IFBPU1QgdW51c2FibGU/DQoNClNlY3Rpb24gMi41DQoNCi0gc2Vjb25kIHBhcmE6IGl0IGxvb2tz IGxpa2UgdGhlIHNlcnZlciBjYW4gdW5pbGF0ZXJhbGx5IGRlY2lkZSB0bw0Kc3VwcHJlc3MgYSBy ZXNwb25zZSB0byBhIG11bHRpY2FzdCByZXF1ZXN0LiAgQnV0IHRoZXJlIGlzIG5vIG1lbnRpb24g YWJvdXQNCndoaWNoIGNvbmRpdGlvbnMgY291bGQgdHJpZ2dlciB0aGUgYWN0dWFsIHJlc3BvbnNl IHN1cHByZXNzaW9uLiAgQSBwb2ludGVyDQp0byBTZWN0aW9uIDIuOCBwZXJoYXBzPw0KDQoNClNl Y3Rpb24gMi43DQoNCi0gVGhlIHRpdGxlL25hbWUgaXMgdmVyeSBnZW5lcmljLiAgIkdyb3VwIE1l bWJlcnNoaXAgUkVTVGZ1bCBJbnRlcmZhY2UiDQoob3Igc2ltaWxhcikgd291bGQgYmUgbW9yZSBl YXNpbHkgYW5kIGNvbnNpc3RlbnRseSByZWZlcmVuY2VkIGluDQpzdWJzZXF1ZW50IHRleHQgKHdo ZXJlIGl0IGFwcGVhcnMgYXMgIlJFU1RmdWwgQ29BUCBpbnRlcmZhY2UiLCBhbmQgdGhlbiBhcw0K IlJFU1RmdWwgaW50ZXJmYWNlIikuDQotIGZpcnN0IHBhcmE6IG1pc3NpbmcgY29tbWEgIlsuLi5d IG9ubHkgYXMgWy4uLl0iIC0+ICJbLi4uXSBvbmx5LCBhcyBbLi4uXSINCi0gc2Vjb25kIHBhcmE6 IHRoZSAiVGh1cyBvbmx5IGF1dGhvcml6ZWQgY29udHJvbGxlcnMgWy4uLl0iIGlzIG5vdCBjbGVh cg0KdG8gbWU6IGl0IHNlZW1zIHRvIGltcGx5IHRoYXQgRFRMUyBwcm92aWRlcyBhdXRob3Jpc2F0 aW9uLCB3aGljaCBpdA0KZG9lc24ndC4NCg0KU2VjdGlvbiAyLjcuMi4xDQoNCi0gdGhlIGJlZ2lu bmluZyBvZiB0aGlzIHNlY3Rpb24gY291bGQgaGF2ZSBhIHNtYWxsIGRlc2NyaXB0aW9uIG9mIHRo ZQ0Kc2VtYW50aWNzLCBiZWZvcmUgZ29pbmcgZGVlcCBpbnRvIHN5bnRhY3RpYyBkZXRhaWxzPw0K LSBzZWNvbmQgcGFyYTogIkEgcmVzb3VyY2Ugb2ZmZXJpbmcgdGhpcyByZXByZXNlbnRhdGlvbiI6 IGl0J3Mgbm90IGNsZWFyDQp0byBtZSB3aGF0ICJ0aGlzIHJlcHJlc2VudGF0aW9uIiByZWZlcnMg dG87DQotIHRoaXJkIHBhcmE6ICJbLi4uXSBpbiBhIGZvcm1hdCBhcyBkZWZpbmVkIFsuLi5dIiAt PiAiWy4uLl0gaW4gdGhlIGZvcm1hdA0KZGVmaW5lZCBbLi4uXSI7DQotIHByb2JsZW0gd2l0aCB0 aGUgZGVmaW5lZCBzeW50YXg6IGl0J3MgaW1wb3NzaWJsZSB0byBzcGVjaWZ5IGENCm5vbi1saXRl cmFsIGdyb3VwIHdpdGggYSBub24tZGVmYXVsdCBwb3J0LiAgSSdkIHN1Z2dlc3QgYWRkaW5nIHRo ZQ0Kb3B0aW9uYWwgcG9ydCB0byB0aGUgbm9uLWxpdGVyYWwgZm9ybWF0IGFzIHdlbGw7DQotIGZp ZnRoIHBhcmE6ICJTSE9VTEQgTk9UIGJlIGluY2x1ZGVkIGlmIHVua25vd24iIGlzbid0IHRoaXMg bW9yZSBhIE1VU1QNCk5PVD8gIFdoYXQgc2hvdWxkIEkgcHV0IGludG8gaXQgaWYgSSBkb24ndCBr bm93IHdoYXQgdG8gcHV0IGludG8gaXQ/DQpBbHNvLCB0aGUgcHJlY2VkaW5nIE1VU1Qgc291bmRz IG1vcmUgbGlrZSBhIFNIT1VMRD8NCg0KU2VjdGlvbiAyLjcuMi4yDQoNCi0gSSdkIGFkZCBhIG5v dGUgYWJvdXQgdGhlIG5lZWQgZm9yIHRoZSBHcm91cCBpbmRleCB0byBiZSB1bmlxdWUNCi0gd2hh dCBoYXBwZW5zIHdoZW4gYSBjbGllbnQgdHJpZXMgdG8gcmVnaXN0ZXIgYSBkdXBsaWNhdGUgImEi Pw0KLSBsYXN0IHBhcmE6IGFkZCBjb250ZXh0L3JhdGlvbmFsZSBmb3IgdGhlIHJlLWpvaW4gcmVx dWlyZW1lbnQgb24gUE9TVCBvZg0KYW4gYWxyZWFkeSByZWdpc3RlcmVkDQoNClNlY3Rpb24gMi43 LjIuMw0KDQotIHRoZSAiLyIgaW4gICIveytsb2NhdGlvbn0iIGxvb2tzIHJlZHVuZGFudA0KLSB3 b3VsZCBiZSBuaWNlIHRvIGhhdmUgdGV4dCB0aGF0IGRlc2NyaWJlcyB0aGUgYWN0aW9ucyB0aGF0 IGFyZSB0byBiZQ0KZG9uZSBieSB0aGUgc2VydmVyIG9uIHN1Y2Nlc3NmdWwgZGVsZXRpb24NCg0K U2VjdGlvbiAyLjcuMi40DQoNCi0gdGhlICIvIiBpbiAgIi97K2xvY2F0aW9ufSIgbG9va3MgcmVk dW5kYW50DQoNClNlY3Rpb24gMi43LjIuNQ0KDQotIGxhc3QgcGFyYTogYWRkIHJlZmVyZW5jZSB0 byBSRkM1OTUyPw0KDQpTZWN0aW9uIDIuNy4yLjYNCg0KLSB3b3VsZCBiZSBuaWNlIHRvIGhhdmUg dGV4dCB0aGF0IGRlc2NyaWJlcyB0aGUgYWN0aW9ucyB0aGF0IGFyZSB0byBiZQ0KZG9uZSBieSB0 aGUgc2VydmVyIG9uIHN1Y2Nlc3NmdWwgdXBkYXRlDQoNClNlY3Rpb24gMi43LjIuNw0KDQotIGZp cnN0IHBhcmE6IGl0J3Mgbm90IGNsZWFyIHdoYXQgbWFrZXMgYSBDb0FQIGNsaWVudCByZXNwb25z aWJpbGUgZm9yIHRoZQ0KZ3JvdXAgbWVtYmVyc2hpcCBvYmplY3RzDQotIHdvdWxkIGJlIG5pY2Ug dG8gaGF2ZSB0ZXh0IHRoYXQgZGVzY3JpYmVzIHRoZSBhY3Rpb25zIHRoYXQgYXJlIHRvIGJlDQpk b25lIGJ5IHRoZSBzZXJ2ZXIgb24gc3VjY2Vzc2Z1bCB1cGRhdGUNCg0KU2VjdGlvbiAyLjgNCg0K LSBJdCBpcyBzYWlkIHRoYXQgdGhlIHJlc3BvbnNlIHN1cHByZXNzaW9uIHNob3VsZCBiZSBjb25m aWd1cmFiaWxlLCB3aGljaA0KaXMgZ3JlYXQuICBCdXQgdGhlbiB3aHkgbm90IGFsbG93aW5nIHRo aXMgdmlhIHRoZSAiR3JvdXAgTWVtYmVyc2hpcA0KUkVTVGZ1bCBJbnRlcmZhY2UiPw0KDQpTZWN0 aW9uIDIuMTANCg0KLSBzaGFtZWxlc3MgcGx1ZzogdGhlICJNdWx0aXBhcnQgQ29udGVudC1Gb3Jt YXQgRW5jb2RpbmcgZm9yIENvQVAiIEktRA0KY291bGQgcHJvdmlkZSB0aGUgYWdncmVnYXRpb24g Zm9ybWF0IG5lZWRlZCA7LSkNCg0K From Akbar.Rahman@interdigital.com Sun Dec 15 18:23:14 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866CD1AE27C for ; Sun, 15 Dec 2013 18:23:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sju2JY8EfKyb for ; Sun, 15 Dec 2013 18:23:09 -0800 (PST) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) by ietfa.amsl.com (Postfix) with ESMTP id 70AC31ADFCC for ; Sun, 15 Dec 2013 18:23:09 -0800 (PST) X-ASG-Debug-ID: 1387160587-06daaa10604c6d0001-aa7cYp Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id srsaAOMLy5vpxF8a for ; Sun, 15 Dec 2013 21:23:07 -0500 (EST) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 15 Dec 2013 21:23:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Sun, 15 Dec 2013 21:23:32 -0500 X-ASG-Orig-Subj: RE: [core] WGLC comments for draft-ietf-core-groupcomm-17 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC comments for draft-ietf-core-groupcomm-17 Thread-Index: AQHO+RNnaMhII7lMuEy2T0VkoimTy5pWGPxA From: "Rahman, Akbar" To: "FOSSATI, Thomas (Thomas)" X-OriginalArrivalTime: 16 Dec 2013 02:23:32.0903 (UTC) FILETIME=[D1077370:01CEFA05] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1387160587 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.143132 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Cc: core@ietf.org Subject: Re: [core] WGLC comments for draft-ietf-core-groupcomm-17 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 02:23:14 -0000 SGkgVGhvbWFzLA0KDQoNClRoYW5rcyBmb3IgeW91ciBkZXRhaWxlZCByZXZpZXcuICBFc2tvIGFu ZCBJIHdpbGwgcmV2aWV3IHlvdXIgY29tbWVudHMgaW4gdGhlIG5leHQgIGZldyBkYXlzIGFuZCBn ZXQgYmFjayB0byB5b3Ugd2l0aCBhIGNvbnNvbGlkYXRlZCByZXNwb25zZS4NCg0KDQpBa2Jhcg0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogY29yZSBbbWFpbHRvOmNvcmUtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEZPU1NBVEksIFRob21hcyAoVGhvbWFzKQ0KU2Vu dDogU2F0dXJkYXksIERlY2VtYmVyIDE0LCAyMDEzIDQ6MjggUE0NClRvOiBjb3JlIChjb3JlQGll dGYub3JnKQ0KU3ViamVjdDogW2NvcmVdIFdHTEMgY29tbWVudHMgZm9yIGRyYWZ0LWlldGYtY29y ZS1ncm91cGNvbW0tMTcNCg0KSGkgQWtiYXIsIEVza28uDQoNCkdvb2Qgam9iIHdpdGggdGhlIGRv Y3VtZW50LiAgVGhlIOKAnFVzZSBDYXNlc+KAnSBzZWN0aW9uIGlzIGVzcGVjaWFsbHkgZW5qb3lh YmxlLg0KDQpUaGVyZSBhcmUgbm8gbWFqb3IgaXNzdWVzIG9uIG15IHNpZGU7IHRoZSBmb2xsb3dp bmcgY29tbWVudHMgYXJlIG1vc3RseSBlZGl0b3JpYWwuDQoNCkNoZWVycywgVGhvbWFzLg0KDQpT ZWN0aW9uIDEuMQ0KDQotIGh0dHBiaXMgaGFzIGJlZW4gc2VudCB0byBJRVNHIGZvciBwdWJsaWNh dGlvbiwgSSBndWVzcyBpdCdzIG9rIHRvIHJlZmVyZW5jZSBpdCBpbnN0ZWFkIG9mIDI2MTY7DQot IGxhc3QgcGFyYTogaXQnZCBiZSBzdXBlciBuaWNlIHRvIGhhdmUgcG9pbnRlcnMgdG8gc2VjdGlv bnMgd2hpbGUgdG9waWNzIGFyZSBlbnVtZXJhdGVkOw0KDQpTZWN0aW9uIDEuMw0KDQotICJJUCBt dWx0aWNhc3QiIGRlZmluaXRpb24gY291bGQgYmUgbWFkZSBhIGJpdCByaWNoZXI/ICBUbyBtZSBJ UCBtdWx0aWNhc3QgaXMgbm90IGp1c3QgYSBtYXR0ZXIgb2YgYWRkcmVzc2luZywgaXMgYWxzbyB0 aGUgbWVtYmVyc2hpcCBtYW5hZ2VtZW50LCB0aGUgcm91dGluZyBhbmQgZm9yd2FyZGluZywgdGhl IGFic3RyYWN0aW9uIGJ1aWx0IG9uIHRvcCBvZiBkaWZmZXJlbnQgTDIgcHJvdG9jb2xzLg0KDQpT ZWN0aW9uIDIuMg0KDQotIGZpcnN0IHBhcmE6IGlzIGl0IG5lY2Vzc2FyeSBmb3IgdGhlIHR3byBN QVkncyB0byBiZSBSRkMyMTE5Pw0KLSBzZWNvbmQgcGFyYSwgbGFzdCBzZW50ZW5jZTogaXMgdGhl cmUgYW55IHJlYXNvbiB3aHkgdGhlICJtYXkgYWxzbyBiZSBlbmFibGVkIiBpcyBub3QgUkZDMjEx OT8NCi0gZm91cnRoIHBhcmE6IGl0J3Mgbm90IGNsZWFyIHRvIG1lIHdoYXQgdGhlICJncm91cCBj b21tdW5pY2F0aW9uIHJlcXVlc3QgQVBJIiBpcw0KLSBmaWZ0aCBwYXJhOiBpcyB0aGUgIkl0IGlz IHJlY29tbWVuZGVkIiBtZWFudCB0byBiZSBSRkMyMTE5Pw0KLSBsYXN0IHBhcmE6IG5vdCBjbGVh ciB3aGF0IHRoZSB1c2UgY2FzZSBmb3IgdGhlIHJldmVyc2UgRE5TIG1hcHBpbmcgd291bGQgYmUu DQoNClNlY3Rpb24gMi4zDQoNCi0gaXNuJ3QgYnVsbGV0IDMuIChpLmUuIHVzZSB0aGUgZGVmYXVs dCBDb0FQIHBvcnQpIGp1c3QgYSBzcGVjaWFsIGNhc2Ugb2YgMS4gKGkuZS4gcHJlLWNvbmZpZ3Vy ZWQgcG9ydCBudW1iZXIpPw0KDQpTZWN0aW9uIDIuNA0KDQotIEkgZ3Vlc3MgaXQncyB0aGUgdW5y ZWxpYWJsZSAobW9yZSB0aGVuIHRoZSBsb3NzeSkgbmF0dXJlIG9mIElQIG11bHRpY2FzdCB0aGF0 IG1ha2VzIFBPU1QgdW51c2FibGU/DQoNClNlY3Rpb24gMi41DQoNCi0gc2Vjb25kIHBhcmE6IGl0 IGxvb2tzIGxpa2UgdGhlIHNlcnZlciBjYW4gdW5pbGF0ZXJhbGx5IGRlY2lkZSB0byBzdXBwcmVz cyBhIHJlc3BvbnNlIHRvIGEgbXVsdGljYXN0IHJlcXVlc3QuICBCdXQgdGhlcmUgaXMgbm8gbWVu dGlvbiBhYm91dCB3aGljaCBjb25kaXRpb25zIGNvdWxkIHRyaWdnZXIgdGhlIGFjdHVhbCByZXNw b25zZSBzdXBwcmVzc2lvbi4gIEEgcG9pbnRlciB0byBTZWN0aW9uIDIuOCBwZXJoYXBzPw0KDQoN ClNlY3Rpb24gMi43DQoNCi0gVGhlIHRpdGxlL25hbWUgaXMgdmVyeSBnZW5lcmljLiAgIkdyb3Vw IE1lbWJlcnNoaXAgUkVTVGZ1bCBJbnRlcmZhY2UiDQoob3Igc2ltaWxhcikgd291bGQgYmUgbW9y ZSBlYXNpbHkgYW5kIGNvbnNpc3RlbnRseSByZWZlcmVuY2VkIGluIHN1YnNlcXVlbnQgdGV4dCAo d2hlcmUgaXQgYXBwZWFycyBhcyAiUkVTVGZ1bCBDb0FQIGludGVyZmFjZSIsIGFuZCB0aGVuIGFz ICJSRVNUZnVsIGludGVyZmFjZSIpLg0KLSBmaXJzdCBwYXJhOiBtaXNzaW5nIGNvbW1hICJbLi4u XSBvbmx5IGFzIFsuLi5dIiAtPiAiWy4uLl0gb25seSwgYXMgWy4uLl0iDQotIHNlY29uZCBwYXJh OiB0aGUgIlRodXMgb25seSBhdXRob3JpemVkIGNvbnRyb2xsZXJzIFsuLi5dIiBpcyBub3QgY2xl YXIgdG8gbWU6IGl0IHNlZW1zIHRvIGltcGx5IHRoYXQgRFRMUyBwcm92aWRlcyBhdXRob3Jpc2F0 aW9uLCB3aGljaCBpdCBkb2Vzbid0Lg0KDQpTZWN0aW9uIDIuNy4yLjENCg0KLSB0aGUgYmVnaW5u aW5nIG9mIHRoaXMgc2VjdGlvbiBjb3VsZCBoYXZlIGEgc21hbGwgZGVzY3JpcHRpb24gb2YgdGhl IHNlbWFudGljcywgYmVmb3JlIGdvaW5nIGRlZXAgaW50byBzeW50YWN0aWMgZGV0YWlscz8NCi0g c2Vjb25kIHBhcmE6ICJBIHJlc291cmNlIG9mZmVyaW5nIHRoaXMgcmVwcmVzZW50YXRpb24iOiBp dCdzIG5vdCBjbGVhciB0byBtZSB3aGF0ICJ0aGlzIHJlcHJlc2VudGF0aW9uIiByZWZlcnMgdG87 DQotIHRoaXJkIHBhcmE6ICJbLi4uXSBpbiBhIGZvcm1hdCBhcyBkZWZpbmVkIFsuLi5dIiAtPiAi Wy4uLl0gaW4gdGhlIGZvcm1hdCBkZWZpbmVkIFsuLi5dIjsNCi0gcHJvYmxlbSB3aXRoIHRoZSBk ZWZpbmVkIHN5bnRheDogaXQncyBpbXBvc3NpYmxlIHRvIHNwZWNpZnkgYSBub24tbGl0ZXJhbCBn cm91cCB3aXRoIGEgbm9uLWRlZmF1bHQgcG9ydC4gIEknZCBzdWdnZXN0IGFkZGluZyB0aGUgb3B0 aW9uYWwgcG9ydCB0byB0aGUgbm9uLWxpdGVyYWwgZm9ybWF0IGFzIHdlbGw7DQotIGZpZnRoIHBh cmE6ICJTSE9VTEQgTk9UIGJlIGluY2x1ZGVkIGlmIHVua25vd24iIGlzbid0IHRoaXMgbW9yZSBh IE1VU1QgTk9UPyAgV2hhdCBzaG91bGQgSSBwdXQgaW50byBpdCBpZiBJIGRvbid0IGtub3cgd2hh dCB0byBwdXQgaW50byBpdD8NCkFsc28sIHRoZSBwcmVjZWRpbmcgTVVTVCBzb3VuZHMgbW9yZSBs aWtlIGEgU0hPVUxEPw0KDQpTZWN0aW9uIDIuNy4yLjINCg0KLSBJJ2QgYWRkIGEgbm90ZSBhYm91 dCB0aGUgbmVlZCBmb3IgdGhlIEdyb3VwIGluZGV4IHRvIGJlIHVuaXF1ZQ0KLSB3aGF0IGhhcHBl bnMgd2hlbiBhIGNsaWVudCB0cmllcyB0byByZWdpc3RlciBhIGR1cGxpY2F0ZSAiYSI/DQotIGxh c3QgcGFyYTogYWRkIGNvbnRleHQvcmF0aW9uYWxlIGZvciB0aGUgcmUtam9pbiByZXF1aXJlbWVu dCBvbiBQT1NUIG9mIGFuIGFscmVhZHkgcmVnaXN0ZXJlZA0KDQpTZWN0aW9uIDIuNy4yLjMNCg0K LSB0aGUgIi8iIGluICAiL3srbG9jYXRpb259IiBsb29rcyByZWR1bmRhbnQNCi0gd291bGQgYmUg bmljZSB0byBoYXZlIHRleHQgdGhhdCBkZXNjcmliZXMgdGhlIGFjdGlvbnMgdGhhdCBhcmUgdG8g YmUgZG9uZSBieSB0aGUgc2VydmVyIG9uIHN1Y2Nlc3NmdWwgZGVsZXRpb24NCg0KU2VjdGlvbiAy LjcuMi40DQoNCi0gdGhlICIvIiBpbiAgIi97K2xvY2F0aW9ufSIgbG9va3MgcmVkdW5kYW50DQoN ClNlY3Rpb24gMi43LjIuNQ0KDQotIGxhc3QgcGFyYTogYWRkIHJlZmVyZW5jZSB0byBSRkM1OTUy Pw0KDQpTZWN0aW9uIDIuNy4yLjYNCg0KLSB3b3VsZCBiZSBuaWNlIHRvIGhhdmUgdGV4dCB0aGF0 IGRlc2NyaWJlcyB0aGUgYWN0aW9ucyB0aGF0IGFyZSB0byBiZSBkb25lIGJ5IHRoZSBzZXJ2ZXIg b24gc3VjY2Vzc2Z1bCB1cGRhdGUNCg0KU2VjdGlvbiAyLjcuMi43DQoNCi0gZmlyc3QgcGFyYTog aXQncyBub3QgY2xlYXIgd2hhdCBtYWtlcyBhIENvQVAgY2xpZW50IHJlc3BvbnNpYmlsZSBmb3Ig dGhlIGdyb3VwIG1lbWJlcnNoaXAgb2JqZWN0cw0KLSB3b3VsZCBiZSBuaWNlIHRvIGhhdmUgdGV4 dCB0aGF0IGRlc2NyaWJlcyB0aGUgYWN0aW9ucyB0aGF0IGFyZSB0byBiZSBkb25lIGJ5IHRoZSBz ZXJ2ZXIgb24gc3VjY2Vzc2Z1bCB1cGRhdGUNCg0KU2VjdGlvbiAyLjgNCg0KLSBJdCBpcyBzYWlk IHRoYXQgdGhlIHJlc3BvbnNlIHN1cHByZXNzaW9uIHNob3VsZCBiZSBjb25maWd1cmFiaWxlLCB3 aGljaCBpcyBncmVhdC4gIEJ1dCB0aGVuIHdoeSBub3QgYWxsb3dpbmcgdGhpcyB2aWEgdGhlICJH cm91cCBNZW1iZXJzaGlwIFJFU1RmdWwgSW50ZXJmYWNlIj8NCg0KU2VjdGlvbiAyLjEwDQoNCi0g c2hhbWVsZXNzIHBsdWc6IHRoZSAiTXVsdGlwYXJ0IENvbnRlbnQtRm9ybWF0IEVuY29kaW5nIGZv ciBDb0FQIiBJLUQgY291bGQgcHJvdmlkZSB0aGUgYWdncmVnYXRpb24gZm9ybWF0IG5lZWRlZCA7 LSkNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmNv cmUgbWFpbGluZyBsaXN0DQpjb3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2NvcmUNCg== From weigengyu@bupt.edu.cn Sun Dec 15 21:26:02 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA4B1AE08D for ; Sun, 15 Dec 2013 21:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlbCNvbWdTY7 for ; Sun, 15 Dec 2013 21:25:59 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3003A1ADFA9 for ; Sun, 15 Dec 2013 21:25:58 -0800 (PST) Received: from WeiGengyuPC (unknown [10.103.241.46]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id B5C0019F4B4; Mon, 16 Dec 2013 13:25:55 +0800 (HKT) Message-ID: <1D599AF996314F5CAEA2D49CF7A7F774@WeiGengyuPC> From: "weigengyu" To: "Rahman, Akbar" , "FOSSATI, Thomas \(Thomas\)" References: In-Reply-To: Date: Mon, 16 Dec 2013 13:25:53 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3505.912 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912 Cc: core@ietf.org Subject: Re: [core] WGLC comments for draft-ietf-core-groupcomm-17 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 05:26:02 -0000 Hi Akbar, I also think you did a good job. And I would like to give some comments after reading your draft. >From the scope (1.2 scope ) the draft describes "group definition, group resource manipulation, and group configuration. Also, proxy operation and minimizing network congestion for group communication" 1. about group definition 1.1 You use terminalogyies group communication for CoAP, CoAP multicast, what the difference is? 1.2 in "2.2 Group Definition and Naming" "A group is defined as a set of CoAP endpoints, where each endpoint is configured to receive multicast CoAP requests that are sent to the group’s associated IP multicast address. An endpoint MAY be a member of multiple groups. Group membership of an endpoint MAY dynamically change over time." As CoAP endpoints include client and servers, A CoAP Group should include a sender (at least) and multiple recievers. or you can called the servers related to the specific IP multicast address as a receive-only group. 1.3 "Note: A Group URI is needed to initiate CoAP group communications." Is it possible to give Group URI an explicity Symble that is different from Host URI, just as specified in the resource type. The difference is not only in the meaning of words, but also by the symbole definition. 2. about group configuration 2.1 in "2.3. Port and URI Configuration" Is it possible and necessary to define a CoAP Group Comm port number? Even thoufh CoAP Supports multicast, it has no explicity flag in message when doing multicast. If there is a dedicated CoAP Group Comm port number, the differece for unicast and multicast are clear; all CoAP group comm can use that UDP port number and different groups are identified by Group URI. 2.2 in "2.5. Messaging and Responses" "The CoAP client can distinguish the origin of multiple server responses by source IP address of the UDP message containing the CoAP response. In case a CoAP client sent multiple group requests, the responses are as usual matched to a request using the CoAP Token." Suggest to "The CoAP client can distinguish the origin of multiple server responses by source IP address of the UDP message, CoAP URI, or other unique identity. " 2.3 in "2.7.2. RESTful Interface" "To access this interface a client MUST use unicast CoAP methods (GET/PUT/POST/DELETE) only as it is a method of configuring group information in individual endpoints." I do suggest to add a client to use multicast CoAP methods as option. Configure the endpoints one by one may has considerations of security issues, but should reserve one to many configuration operations. 3. group resource manipulation in "2.9. Congestion Control", The draft gives decriptions on " CoAP [I-D.ietf-core-coap] reduces multicast-specific congestion risks through the following measures: ......" But there are no words about how a node should do when there is congestion. Maybe this is the critical issue of congestion control and this is out of the scope. I am appreciate your works on section 3 and 4. And no commets on others currently. Just read Thomas email > "- httpbis has been sent to IESG for publication, I guess it's ok to > reference it instead of 2616;" If it referes to http2.0, I prefer rfc2616. I am not sure whether http2.0 is so-called RESTful. Regards, Gengyu Network Techonology Center School of Computer Beijing University of Posts & Telecommunications -----原始邮件----- From: Rahman, Akbar Sent: Monday, December 16, 2013 10:23 AM To: FOSSATI, Thomas (Thomas) Cc: core@ietf.org Subject: Re: [core] WGLC comments for draft-ietf-core-groupcomm-17 Hi Thomas, Thanks for your detailed review. Esko and I will review your comments in the next few days and get back to you with a consolidated response. Akbar -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of FOSSATI, Thomas (Thomas) Sent: Saturday, December 14, 2013 4:28 PM To: core (core@ietf.org) Subject: [core] WGLC comments for draft-ietf-core-groupcomm-17 Hi Akbar, Esko. Good job with the document. The “Use Cases” section is especially enjoyable. There are no major issues on my side; the following comments are mostly editorial. Cheers, Thomas. Section 1.1 - httpbis has been sent to IESG for publication, I guess it's ok to reference it instead of 2616; - last para: it'd be super nice to have pointers to sections while topics are enumerated; Section 1.3 - "IP multicast" definition could be made a bit richer? To me IP multicast is not just a matter of addressing, is also the membership management, the routing and forwarding, the abstraction built on top of different L2 protocols. Section 2.2 - first para: is it necessary for the two MAY's to be RFC2119? - second para, last sentence: is there any reason why the "may also be enabled" is not RFC2119? - fourth para: it's not clear to me what the "group communication request API" is - fifth para: is the "It is recommended" meant to be RFC2119? - last para: not clear what the use case for the reverse DNS mapping would be. Section 2.3 - isn't bullet 3. (i.e. use the default CoAP port) just a special case of 1. (i.e. pre-configured port number)? Section 2.4 - I guess it's the unreliable (more then the lossy) nature of IP multicast that makes POST unusable? Section 2.5 - second para: it looks like the server can unilaterally decide to suppress a response to a multicast request. But there is no mention about which conditions could trigger the actual response suppression. A pointer to Section 2.8 perhaps? Section 2.7 - The title/name is very generic. "Group Membership RESTful Interface" (or similar) would be more easily and consistently referenced in subsequent text (where it appears as "RESTful CoAP interface", and then as "RESTful interface"). - first para: missing comma "[...] only as [...]" -> "[...] only, as [...]" - second para: the "Thus only authorized controllers [...]" is not clear to me: it seems to imply that DTLS provides authorisation, which it doesn't. Section 2.7.2.1 - the beginning of this section could have a small description of the semantics, before going deep into syntactic details? - second para: "A resource offering this representation": it's not clear to me what "this representation" refers to; - third para: "[...] in a format as defined [...]" -> "[...] in the format defined [...]"; - problem with the defined syntax: it's impossible to specify a non-literal group with a non-default port. I'd suggest adding the optional port to the non-literal format as well; - fifth para: "SHOULD NOT be included if unknown" isn't this more a MUST NOT? What should I put into it if I don't know what to put into it? Also, the preceding MUST sounds more like a SHOULD? Section 2.7.2.2 - I'd add a note about the need for the Group index to be unique - what happens when a client tries to register a duplicate "a"? - last para: add context/rationale for the re-join requirement on POST of an already registered Section 2.7.2.3 - the "/" in "/{+location}" looks redundant - would be nice to have text that describes the actions that are to be done by the server on successful deletion Section 2.7.2.4 - the "/" in "/{+location}" looks redundant Section 2.7.2.5 - last para: add reference to RFC5952? Section 2.7.2.6 - would be nice to have text that describes the actions that are to be done by the server on successful update Section 2.7.2.7 - first para: it's not clear what makes a CoAP client responsibile for the group membership objects - would be nice to have text that describes the actions that are to be done by the server on successful update Section 2.8 - It is said that the response suppression should be configurabile, which is great. But then why not allowing this via the "Group Membership RESTful Interface"? Section 2.10 - shameless plug: the "Multipart Content-Format Encoding for CoAP" I-D could provide the aggregation format needed ;-) _______________________________________________ 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 thomas.fossati@alcatel-lucent.com Mon Dec 16 00:29:44 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6D91AE2F3 for ; Mon, 16 Dec 2013 00:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QS39EyZMxU1y for ; Mon, 16 Dec 2013 00:29:42 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id AF53C1AE2F2 for ; Mon, 16 Dec 2013 00:29:42 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id rBG8TTuG029030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 16 Dec 2013 02:29:31 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id rBG8TQrW001468 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Dec 2013 09:29:27 +0100 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.153]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 16 Dec 2013 09:29:26 +0100 From: "FOSSATI, Thomas (Thomas)" To: weigengyu , "Rahman, Akbar" Thread-Topic: [core] WGLC comments for draft-ietf-core-groupcomm-17 Thread-Index: AQHO+RNnaMhII7lMuEy2T0VkoimTy5pWGPxAgAAirYCAADNGAA== Date: Mon, 16 Dec 2013 08:29:26 +0000 Message-ID: References: <1D599AF996314F5CAEA2D49CF7A7F774@WeiGengyuPC> In-Reply-To: <1D599AF996314F5CAEA2D49CF7A7F774@WeiGengyuPC> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="utf-8" Content-ID: <1A72687F4EF28F47BAB8E477938A54C8@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "core@ietf.org" Subject: Re: [core] WGLC comments for draft-ietf-core-groupcomm-17 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 08:29:44 -0000 SGkgR2VuZ3l1LCBBa2JhciwNCg0KT24gMTYvMTIvMjAxMyAwNToyNSwgIndlaWdlbmd5dSIgPHdl aWdlbmd5dUBidXB0LmVkdS5jbj4gd3JvdGU6DQo+SnVzdCByZWFkIFRob21hcyBlbWFpbA0KPj4g Ii0gaHR0cGJpcyBoYXMgYmVlbiBzZW50IHRvIElFU0cgZm9yIHB1YmxpY2F0aW9uLCBJIGd1ZXNz IGl0J3Mgb2sgdG8NCj4+IHJlZmVyZW5jZSBpdCBpbnN0ZWFkIG9mIDI2MTY7Ig0KPg0KPiAgICAg SWYgaXQgcmVmZXJlcyB0byBodHRwMi4wLCBJIHByZWZlciByZmMyNjE2Lg0KDQpJIG1lYW4gdGhl IDI2MTYtYmlzIGRvY3VtZW50IHNldCwgbm90IEhUVFAvMi4wLg0KDQpDaGVlcnMNCg0K From kovatsch@inf.ethz.ch Mon Dec 16 03:58:12 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83BE11ADF64 for ; Mon, 16 Dec 2013 03:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.438 X-Spam-Level: X-Spam-Status: No, score=-7.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PC4QO0V53tk for ; Mon, 16 Dec 2013 03:58:07 -0800 (PST) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id 590AD1ADF62 for ; Mon, 16 Dec 2013 03:58:06 -0800 (PST) Received: from CAS20.d.ethz.ch (172.31.51.110) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.3.174.1; Mon, 16 Dec 2013 12:58:02 +0100 Received: from MBX110.d.ethz.ch ([fe80::9d9a:a7f2:c282:5f6a]) by CAS20.d.ethz.ch ([fe80::2cd8:4907:7776:c56d%10]) with mapi id 14.02.0387.000; Mon, 16 Dec 2013 12:58:04 +0100 From: "Kovatsch Matthias" To: "core@ietf.org" Thread-Topic: CoAP open source project: Californium (Cf) goes Eclipse Thread-Index: Ac76VPzNrf4H9wMdQ+O9KIOgOFQ3TQ== Date: Mon, 16 Dec 2013 11:58:04 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B51C183C15@MBX110.d.ethz.ch> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.130.253] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [core] CoAP open source project: Californium (Cf) goes Eclipse X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 11:58:13 -0000 Dear list and followers We created a proposal to get the Californium (Cf) CoAP framework (Java) und= er the hat of the Eclipse Foundation. The main goal is to find a long-term = home and more developers to make it a full-fledged open source project: http://www.eclipse.org/proposals/technology.californium/ If you are an interested third party or, even better, would like to become = a committer, please share your comments here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D424024 Best regards Matthias From Akbar.Rahman@interdigital.com Mon Dec 16 06:39:22 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B471AE01E for ; Mon, 16 Dec 2013 06:39:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g_RKvFlHmB8w for ; Mon, 16 Dec 2013 06:39:20 -0800 (PST) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) by ietfa.amsl.com (Postfix) with ESMTP id E077B1ADF76 for ; Mon, 16 Dec 2013 06:39:19 -0800 (PST) X-ASG-Debug-ID: 1387204757-06daaa105f528b0001-aa7cYp Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id rb7K1FqqtODiJJ3C for ; Mon, 16 Dec 2013 09:39:17 -0500 (EST) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Dec 2013 09:39:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Mon, 16 Dec 2013 09:39:41 -0500 X-ASG-Orig-Subj: RE: [core] WGLC comments for draft-ietf-core-groupcomm-17 Message-ID: In-Reply-To: <1D599AF996314F5CAEA2D49CF7A7F774@WeiGengyuPC> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] WGLC comments for draft-ietf-core-groupcomm-17 Thread-Index: Ac76H22d1LMTrs3fTFCcRGtP5N6vNQATRVZQ References: <1D599AF996314F5CAEA2D49CF7A7F774@WeiGengyuPC> From: "Rahman, Akbar" To: "weigengyu" X-OriginalArrivalTime: 16 Dec 2013 14:39:42.0851 (UTC) FILETIME=[A85EA530:01CEFA6C] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1387204757 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.143144 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Cc: core@ietf.org Subject: Re: [core] WGLC comments for draft-ietf-core-groupcomm-17 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 14:39:22 -0000 VGhhbmtzLCBHZW5neXUsIGZvciB5b3VyIHRob3JvdWdoIHJldmlldy4gIEVza28gYW5kIEkgd2ls bCBnZXQgYmFjayB0byB5b3Ugd2l0aCBhIHBvaW50IGJ5IHBvaW50IHJlc3BvbnNlIGluIHRoZSBu ZXh0IGZldyBkYXlzLg0KDQoNCkFrYmFyDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiB3ZWlnZW5neXUgW21haWx0bzp3ZWlnZW5neXVAYnVwdC5lZHUuY25dIA0KU2VudDogTW9u ZGF5LCBEZWNlbWJlciAxNiwgMjAxMyAxMjoyNiBBTQ0KVG86IFJhaG1hbiwgQWtiYXI7IEZPU1NB VEksIFRob21hcyAoVGhvbWFzKQ0KQ2M6IGNvcmVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbY29y ZV0gV0dMQyBjb21tZW50cyBmb3IgZHJhZnQtaWV0Zi1jb3JlLWdyb3VwY29tbS0xNw0KDQpIaSBB a2JhciwNCg0KSSBhbHNvIHRoaW5rIHlvdSBkaWQgYSBnb29kIGpvYi4NCkFuZCBJIHdvdWxkIGxp a2UgdG8gZ2l2ZSBzb21lIGNvbW1lbnRzIGFmdGVyIHJlYWRpbmcgeW91ciBkcmFmdC4NCg0KRnJv bSB0aGUgc2NvcGUgKDEuMiBzY29wZSApICB0aGUgZHJhZnQgZGVzY3JpYmVzICJncm91cCBkZWZp bml0aW9uLCBncm91cCByZXNvdXJjZSBtYW5pcHVsYXRpb24sIGFuZCBncm91cCBjb25maWd1cmF0 aW9uLiBBbHNvLCBwcm94eSBvcGVyYXRpb24gYW5kIG1pbmltaXppbmcgbmV0d29yayBjb25nZXN0 aW9uIGZvciBncm91cCBjb21tdW5pY2F0aW9uIg0KDQoxLiBhYm91dCBncm91cCBkZWZpbml0aW9u DQoxLjEgICAgWW91IHVzZSAgdGVybWluYWxvZ3lpZXMgZ3JvdXAgY29tbXVuaWNhdGlvbiBmb3Ig Q29BUCwgQ29BUCBtdWx0aWNhc3QsIA0Kd2hhdCB0aGUgZGlmZmVyZW5jZSBpcz8NCjEuMiAgICBp biAiMi4yIEdyb3VwIERlZmluaXRpb24gYW5kIE5hbWluZyINCiAgICAgICAgIkEgZ3JvdXAgaXMg ZGVmaW5lZCBhcyBhIHNldCBvZiBDb0FQIGVuZHBvaW50cywgd2hlcmUgZWFjaCBlbmRwb2ludCBp cyBjb25maWd1cmVkIHRvIHJlY2VpdmUgbXVsdGljYXN0IENvQVAgcmVxdWVzdHMgdGhhdCBhcmUg c2VudCB0byB0aGUgZ3JvdXDigJlzIGFzc29jaWF0ZWQgSVAgbXVsdGljYXN0IGFkZHJlc3MuDQpB biBlbmRwb2ludCBNQVkgYmUgYSBtZW1iZXIgb2YgbXVsdGlwbGUgZ3JvdXBzLiBHcm91cCBtZW1i ZXJzaGlwIG9mIGFuIGVuZHBvaW50IE1BWSBkeW5hbWljYWxseSBjaGFuZ2Ugb3ZlciB0aW1lLiIN CiAgICAgICAgIEFzIENvQVAgZW5kcG9pbnRzIGluY2x1ZGUgY2xpZW50IGFuZCBzZXJ2ZXJzLCAg QSBDb0FQIEdyb3VwIHNob3VsZCBpbmNsdWRlIGEgc2VuZGVyIChhdCBsZWFzdCkgYW5kIG11bHRp cGxlIHJlY2lldmVycy4NCiAgICAgICBvciB5b3UgY2FuIGNhbGxlZCB0aGUgc2VydmVycyByZWxh dGVkIHRvIHRoZSBzcGVjaWZpYyBJUCBtdWx0aWNhc3QgYWRkcmVzcyBhcyBhIHJlY2VpdmUtb25s eSBncm91cC4NCjEuMyAgIk5vdGU6IEEgR3JvdXAgVVJJIGlzIG5lZWRlZCB0byBpbml0aWF0ZSBD b0FQIGdyb3VwIGNvbW11bmljYXRpb25zLiINCiAgICAgICAgSXMgaXQgcG9zc2libGUgdG8gZ2l2 ZSBHcm91cCBVUkkgYW4gZXhwbGljaXR5IFN5bWJsZSB0aGF0IGlzIGRpZmZlcmVudCBmcm9tIEhv c3QgVVJJLCBqdXN0IGFzIHNwZWNpZmllZCBpbiB0aGUgcmVzb3VyY2UgdHlwZS4NCiAgICAgICAg VGhlIGRpZmZlcmVuY2UgaXMgbm90IG9ubHkgaW4gdGhlIG1lYW5pbmcgb2Ygd29yZHMsIGJ1dCBh bHNvIGJ5IHRoZSBzeW1ib2xlIGRlZmluaXRpb24uDQoNCjIuIGFib3V0IGdyb3VwIGNvbmZpZ3Vy YXRpb24NCg0KMi4xIGluICIyLjMuIFBvcnQgYW5kIFVSSSBDb25maWd1cmF0aW9uIg0KICAgICAg SXMgaXQgcG9zc2libGUgYW5kIG5lY2Vzc2FyeSB0byBkZWZpbmUgYSBDb0FQIEdyb3VwIENvbW0g cG9ydCBudW1iZXI/DQogICAgICBFdmVuIHRob3VmaCBDb0FQIFN1cHBvcnRzICBtdWx0aWNhc3Qs ICBpdCBoYXMgbm8gZXhwbGljaXR5IGZsYWcgaW4gbWVzc2FnZSB3aGVuIGRvaW5nIG11bHRpY2Fz dC4NCiAgICAgIElmIHRoZXJlIGlzIGEgZGVkaWNhdGVkIENvQVAgR3JvdXAgQ29tbSBwb3J0IG51 bWJlciwgdGhlIGRpZmZlcmVjZSBmb3IgdW5pY2FzdCBhbmQgbXVsdGljYXN0IGFyZSBjbGVhcjsg YWxsIENvQVAgZ3JvdXAgY29tbSBjYW4gdXNlIHRoYXQgVURQIHBvcnQgbnVtYmVyICBhbmQgZGlm ZmVyZW50IGdyb3VwcyBhcmUgaWRlbnRpZmllZCBieSBHcm91cCBVUkkuDQoNCjIuMiBpbiAiMi41 LiBNZXNzYWdpbmcgYW5kIFJlc3BvbnNlcyINCiAgICAgICJUaGUgQ29BUCBjbGllbnQgY2FuIGRp c3Rpbmd1aXNoIHRoZSBvcmlnaW4gb2YgbXVsdGlwbGUgc2VydmVyIHJlc3BvbnNlcyBieSBzb3Vy Y2UgSVAgYWRkcmVzcyBvZiB0aGUgVURQIG1lc3NhZ2UgY29udGFpbmluZyB0aGUgQ29BUCByZXNw b25zZS4gSW4gY2FzZSBhIENvQVAgY2xpZW50IHNlbnQgbXVsdGlwbGUgZ3JvdXAgcmVxdWVzdHMs IHRoZSByZXNwb25zZXMgYXJlIGFzIHVzdWFsIG1hdGNoZWQgdG8gYSByZXF1ZXN0IHVzaW5nIHRo ZSBDb0FQIFRva2VuLiINCiAgICAgICBTdWdnZXN0IHRvICJUaGUgQ29BUCBjbGllbnQgY2FuIGRp c3Rpbmd1aXNoIHRoZSBvcmlnaW4gb2YgbXVsdGlwbGUgc2VydmVyIHJlc3BvbnNlcyBieSBzb3Vy Y2UgSVAgYWRkcmVzcyBvZiB0aGUgVURQIG1lc3NhZ2UsICBDb0FQIFVSSSwgb3Igb3RoZXIgdW5p cXVlIGlkZW50aXR5LiAgIg0KDQoyLjMgaW4gIjIuNy4yLiBSRVNUZnVsIEludGVyZmFjZSINCiAg ICAgICJUbyBhY2Nlc3MgdGhpcyBpbnRlcmZhY2UgYSBjbGllbnQgTVVTVCB1c2UgdW5pY2FzdCBD b0FQIG1ldGhvZHMNCihHRVQvUFVUL1BPU1QvREVMRVRFKSBvbmx5IGFzIGl0IGlzIGEgbWV0aG9k IG9mIGNvbmZpZ3VyaW5nIGdyb3VwIGluZm9ybWF0aW9uIGluIGluZGl2aWR1YWwgZW5kcG9pbnRz LiINCiAgICAgIEkgZG8gc3VnZ2VzdCB0byBhZGQgYSBjbGllbnQgdG8gdXNlIG11bHRpY2FzdCBD b0FQIG1ldGhvZHMgYXMgb3B0aW9uLg0KICAgICBDb25maWd1cmUgdGhlIGVuZHBvaW50cyBvbmUg Ynkgb25lIG1heSBoYXMgY29uc2lkZXJhdGlvbnMgb2Ygc2VjdXJpdHkgaXNzdWVzLCBidXQgc2hv dWxkIHJlc2VydmUgb25lIHRvIG1hbnkgY29uZmlndXJhdGlvbiBvcGVyYXRpb25zLg0KDQozLiBn cm91cCByZXNvdXJjZSBtYW5pcHVsYXRpb24NCiAgICAgaW4gIjIuOS4gQ29uZ2VzdGlvbiBDb250 cm9sIiwNCg0KICAgICBUaGUgZHJhZnQgZ2l2ZXMgZGVjcmlwdGlvbnMgb24gICIgQ29BUCBbSS1E LmlldGYtY29yZS1jb2FwXSByZWR1Y2VzIG11bHRpY2FzdC1zcGVjaWZpYyBjb25nZXN0aW9uIHJp c2tzIHRocm91Z2ggdGhlIGZvbGxvd2luZyBtZWFzdXJlczogLi4uLi4uIg0KICAgICBCdXQgdGhl cmUgYXJlIG5vIHdvcmRzIGFib3V0IGhvdyBhIG5vZGUgc2hvdWxkIGRvIHdoZW4gdGhlcmUgaXMg Y29uZ2VzdGlvbi4NCiAgICAgTWF5YmUgdGhpcyBpcyB0aGUgY3JpdGljYWwgaXNzdWUgb2YgY29u Z2VzdGlvbiBjb250cm9sIGFuZCB0aGlzIGlzIG91dCBvZiB0aGUgc2NvcGUuDQoNCkkgYW0gYXBw cmVjaWF0ZSB5b3VyIHdvcmtzIG9uIHNlY3Rpb24gMyBhbmQgNC4gIEFuZCBubyBjb21tZXRzIG9u IG90aGVycyBjdXJyZW50bHkuDQoNCkp1c3QgcmVhZCBUaG9tYXMgZW1haWwNCj4gIi0gaHR0cGJp cyBoYXMgYmVlbiBzZW50IHRvIElFU0cgZm9yIHB1YmxpY2F0aW9uLCBJIGd1ZXNzIGl0J3Mgb2sg dG8gDQo+IHJlZmVyZW5jZSBpdCBpbnN0ZWFkIG9mIDI2MTY7Ig0KDQogICAgIElmIGl0IHJlZmVy ZXMgdG8gaHR0cDIuMCwgSSBwcmVmZXIgcmZjMjYxNi4gIEkgYW0gbm90IHN1cmUgd2hldGhlcg0K aHR0cDIuMCBpcyBzby1jYWxsZWQgUkVTVGZ1bC4NCg0KDQpSZWdhcmRzLA0KDQpHZW5neXUNCg0K TmV0d29yayBUZWNob25vbG9neSBDZW50ZXINClNjaG9vbCBvZiBDb21wdXRlcg0KQmVpamluZyBV bml2ZXJzaXR5IG9mIFBvc3RzICYgVGVsZWNvbW11bmljYXRpb25zDQoNCg0KLS0tLS3ljp/lp4vp gq7ku7YtLS0tLSANCkZyb206IFJhaG1hbiwgQWtiYXINClNlbnQ6IE1vbmRheSwgRGVjZW1iZXIg MTYsIDIwMTMgMTA6MjMgQU0NClRvOiBGT1NTQVRJLCBUaG9tYXMgKFRob21hcykNCkNjOiBjb3Jl QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2NvcmVdIFdHTEMgY29tbWVudHMgZm9yIGRyYWZ0LWll dGYtY29yZS1ncm91cGNvbW0tMTcNCg0KSGkgVGhvbWFzLA0KDQoNClRoYW5rcyBmb3IgeW91ciBk ZXRhaWxlZCByZXZpZXcuICBFc2tvIGFuZCBJIHdpbGwgcmV2aWV3IHlvdXIgY29tbWVudHMgaW4g DQp0aGUgbmV4dCAgZmV3IGRheXMgYW5kIGdldCBiYWNrIHRvIHlvdSB3aXRoIGEgY29uc29saWRh dGVkIHJlc3BvbnNlLg0KDQoNCkFrYmFyDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBjb3JlIFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRk9T U0FUSSwgVGhvbWFzIA0KKFRob21hcykNClNlbnQ6IFNhdHVyZGF5LCBEZWNlbWJlciAxNCwgMjAx MyA0OjI4IFBNDQpUbzogY29yZSAoY29yZUBpZXRmLm9yZykNClN1YmplY3Q6IFtjb3JlXSBXR0xD IGNvbW1lbnRzIGZvciBkcmFmdC1pZXRmLWNvcmUtZ3JvdXBjb21tLTE3DQoNCkhpIEFrYmFyLCBF c2tvLg0KDQpHb29kIGpvYiB3aXRoIHRoZSBkb2N1bWVudC4gIFRoZSDigJxVc2UgQ2FzZXPigJ0g c2VjdGlvbiBpcyBlc3BlY2lhbGx5IA0KZW5qb3lhYmxlLg0KDQpUaGVyZSBhcmUgbm8gbWFqb3Ig aXNzdWVzIG9uIG15IHNpZGU7IHRoZSBmb2xsb3dpbmcgY29tbWVudHMgYXJlIG1vc3RseSANCmVk aXRvcmlhbC4NCg0KQ2hlZXJzLCBUaG9tYXMuDQoNClNlY3Rpb24gMS4xDQoNCi0gaHR0cGJpcyBo YXMgYmVlbiBzZW50IHRvIElFU0cgZm9yIHB1YmxpY2F0aW9uLCBJIGd1ZXNzIGl0J3Mgb2sgdG8g DQpyZWZlcmVuY2UgaXQgaW5zdGVhZCBvZiAyNjE2Ow0KLSBsYXN0IHBhcmE6IGl0J2QgYmUgc3Vw ZXIgbmljZSB0byBoYXZlIHBvaW50ZXJzIHRvIHNlY3Rpb25zIHdoaWxlIHRvcGljcyANCmFyZSBl bnVtZXJhdGVkOw0KDQpTZWN0aW9uIDEuMw0KDQotICJJUCBtdWx0aWNhc3QiIGRlZmluaXRpb24g Y291bGQgYmUgbWFkZSBhIGJpdCByaWNoZXI/ICBUbyBtZSBJUCBtdWx0aWNhc3QgDQppcyBub3Qg anVzdCBhIG1hdHRlciBvZiBhZGRyZXNzaW5nLCBpcyBhbHNvIHRoZSBtZW1iZXJzaGlwIG1hbmFn ZW1lbnQsIHRoZSANCnJvdXRpbmcgYW5kIGZvcndhcmRpbmcsIHRoZSBhYnN0cmFjdGlvbiBidWls dCBvbiB0b3Agb2YgZGlmZmVyZW50IEwyIA0KcHJvdG9jb2xzLg0KDQpTZWN0aW9uIDIuMg0KDQot IGZpcnN0IHBhcmE6IGlzIGl0IG5lY2Vzc2FyeSBmb3IgdGhlIHR3byBNQVkncyB0byBiZSBSRkMy MTE5Pw0KLSBzZWNvbmQgcGFyYSwgbGFzdCBzZW50ZW5jZTogaXMgdGhlcmUgYW55IHJlYXNvbiB3 aHkgdGhlICJtYXkgYWxzbyBiZSANCmVuYWJsZWQiIGlzIG5vdCBSRkMyMTE5Pw0KLSBmb3VydGgg cGFyYTogaXQncyBub3QgY2xlYXIgdG8gbWUgd2hhdCB0aGUgImdyb3VwIGNvbW11bmljYXRpb24g cmVxdWVzdCANCkFQSSIgaXMNCi0gZmlmdGggcGFyYTogaXMgdGhlICJJdCBpcyByZWNvbW1lbmRl ZCIgbWVhbnQgdG8gYmUgUkZDMjExOT8NCi0gbGFzdCBwYXJhOiBub3QgY2xlYXIgd2hhdCB0aGUg dXNlIGNhc2UgZm9yIHRoZSByZXZlcnNlIEROUyBtYXBwaW5nIHdvdWxkIA0KYmUuDQoNClNlY3Rp b24gMi4zDQoNCi0gaXNuJ3QgYnVsbGV0IDMuIChpLmUuIHVzZSB0aGUgZGVmYXVsdCBDb0FQIHBv cnQpIGp1c3QgYSBzcGVjaWFsIGNhc2Ugb2YgMS4gDQooaS5lLiBwcmUtY29uZmlndXJlZCBwb3J0 IG51bWJlcik/DQoNClNlY3Rpb24gMi40DQoNCi0gSSBndWVzcyBpdCdzIHRoZSB1bnJlbGlhYmxl IChtb3JlIHRoZW4gdGhlIGxvc3N5KSBuYXR1cmUgb2YgSVAgbXVsdGljYXN0IA0KdGhhdCBtYWtl cyBQT1NUIHVudXNhYmxlPw0KDQpTZWN0aW9uIDIuNQ0KDQotIHNlY29uZCBwYXJhOiBpdCBsb29r cyBsaWtlIHRoZSBzZXJ2ZXIgY2FuIHVuaWxhdGVyYWxseSBkZWNpZGUgdG8gc3VwcHJlc3MgDQph IHJlc3BvbnNlIHRvIGEgbXVsdGljYXN0IHJlcXVlc3QuICBCdXQgdGhlcmUgaXMgbm8gbWVudGlv biBhYm91dCB3aGljaCANCmNvbmRpdGlvbnMgY291bGQgdHJpZ2dlciB0aGUgYWN0dWFsIHJlc3Bv bnNlIHN1cHByZXNzaW9uLiAgQSBwb2ludGVyIHRvIA0KU2VjdGlvbiAyLjggcGVyaGFwcz8NCg0K DQpTZWN0aW9uIDIuNw0KDQotIFRoZSB0aXRsZS9uYW1lIGlzIHZlcnkgZ2VuZXJpYy4gICJHcm91 cCBNZW1iZXJzaGlwIFJFU1RmdWwgSW50ZXJmYWNlIg0KKG9yIHNpbWlsYXIpIHdvdWxkIGJlIG1v cmUgZWFzaWx5IGFuZCBjb25zaXN0ZW50bHkgcmVmZXJlbmNlZCBpbiBzdWJzZXF1ZW50IA0KdGV4 dCAod2hlcmUgaXQgYXBwZWFycyBhcyAiUkVTVGZ1bCBDb0FQIGludGVyZmFjZSIsIGFuZCB0aGVu IGFzICJSRVNUZnVsIA0KaW50ZXJmYWNlIikuDQotIGZpcnN0IHBhcmE6IG1pc3NpbmcgY29tbWEg IlsuLi5dIG9ubHkgYXMgWy4uLl0iIC0+ICJbLi4uXSBvbmx5LCBhcyBbLi4uXSINCi0gc2Vjb25k IHBhcmE6IHRoZSAiVGh1cyBvbmx5IGF1dGhvcml6ZWQgY29udHJvbGxlcnMgWy4uLl0iIGlzIG5v dCBjbGVhciB0byANCm1lOiBpdCBzZWVtcyB0byBpbXBseSB0aGF0IERUTFMgcHJvdmlkZXMgYXV0 aG9yaXNhdGlvbiwgd2hpY2ggaXQgZG9lc24ndC4NCg0KU2VjdGlvbiAyLjcuMi4xDQoNCi0gdGhl IGJlZ2lubmluZyBvZiB0aGlzIHNlY3Rpb24gY291bGQgaGF2ZSBhIHNtYWxsIGRlc2NyaXB0aW9u IG9mIHRoZSANCnNlbWFudGljcywgYmVmb3JlIGdvaW5nIGRlZXAgaW50byBzeW50YWN0aWMgZGV0 YWlscz8NCi0gc2Vjb25kIHBhcmE6ICJBIHJlc291cmNlIG9mZmVyaW5nIHRoaXMgcmVwcmVzZW50 YXRpb24iOiBpdCdzIG5vdCBjbGVhciB0byANCm1lIHdoYXQgInRoaXMgcmVwcmVzZW50YXRpb24i IHJlZmVycyB0bzsNCi0gdGhpcmQgcGFyYTogIlsuLi5dIGluIGEgZm9ybWF0IGFzIGRlZmluZWQg Wy4uLl0iIC0+ICJbLi4uXSBpbiB0aGUgZm9ybWF0IA0KZGVmaW5lZCBbLi4uXSI7DQotIHByb2Js ZW0gd2l0aCB0aGUgZGVmaW5lZCBzeW50YXg6IGl0J3MgaW1wb3NzaWJsZSB0byBzcGVjaWZ5IGEg bm9uLWxpdGVyYWwgDQpncm91cCB3aXRoIGEgbm9uLWRlZmF1bHQgcG9ydC4gIEknZCBzdWdnZXN0 IGFkZGluZyB0aGUgb3B0aW9uYWwgcG9ydCB0byB0aGUgDQpub24tbGl0ZXJhbCBmb3JtYXQgYXMg d2VsbDsNCi0gZmlmdGggcGFyYTogIlNIT1VMRCBOT1QgYmUgaW5jbHVkZWQgaWYgdW5rbm93biIg aXNuJ3QgdGhpcyBtb3JlIGEgTVVTVCANCk5PVD8gIFdoYXQgc2hvdWxkIEkgcHV0IGludG8gaXQg aWYgSSBkb24ndCBrbm93IHdoYXQgdG8gcHV0IGludG8gaXQ/DQpBbHNvLCB0aGUgcHJlY2VkaW5n IE1VU1Qgc291bmRzIG1vcmUgbGlrZSBhIFNIT1VMRD8NCg0KU2VjdGlvbiAyLjcuMi4yDQoNCi0g SSdkIGFkZCBhIG5vdGUgYWJvdXQgdGhlIG5lZWQgZm9yIHRoZSBHcm91cCBpbmRleCB0byBiZSB1 bmlxdWUNCi0gd2hhdCBoYXBwZW5zIHdoZW4gYSBjbGllbnQgdHJpZXMgdG8gcmVnaXN0ZXIgYSBk dXBsaWNhdGUgImEiPw0KLSBsYXN0IHBhcmE6IGFkZCBjb250ZXh0L3JhdGlvbmFsZSBmb3IgdGhl IHJlLWpvaW4gcmVxdWlyZW1lbnQgb24gUE9TVCBvZiBhbiANCmFscmVhZHkgcmVnaXN0ZXJlZA0K DQpTZWN0aW9uIDIuNy4yLjMNCg0KLSB0aGUgIi8iIGluICAiL3srbG9jYXRpb259IiBsb29rcyBy ZWR1bmRhbnQNCi0gd291bGQgYmUgbmljZSB0byBoYXZlIHRleHQgdGhhdCBkZXNjcmliZXMgdGhl IGFjdGlvbnMgdGhhdCBhcmUgdG8gYmUgZG9uZSANCmJ5IHRoZSBzZXJ2ZXIgb24gc3VjY2Vzc2Z1 bCBkZWxldGlvbg0KDQpTZWN0aW9uIDIuNy4yLjQNCg0KLSB0aGUgIi8iIGluICAiL3srbG9jYXRp b259IiBsb29rcyByZWR1bmRhbnQNCg0KU2VjdGlvbiAyLjcuMi41DQoNCi0gbGFzdCBwYXJhOiBh ZGQgcmVmZXJlbmNlIHRvIFJGQzU5NTI/DQoNClNlY3Rpb24gMi43LjIuNg0KDQotIHdvdWxkIGJl IG5pY2UgdG8gaGF2ZSB0ZXh0IHRoYXQgZGVzY3JpYmVzIHRoZSBhY3Rpb25zIHRoYXQgYXJlIHRv IGJlIGRvbmUgDQpieSB0aGUgc2VydmVyIG9uIHN1Y2Nlc3NmdWwgdXBkYXRlDQoNClNlY3Rpb24g Mi43LjIuNw0KDQotIGZpcnN0IHBhcmE6IGl0J3Mgbm90IGNsZWFyIHdoYXQgbWFrZXMgYSBDb0FQ IGNsaWVudCByZXNwb25zaWJpbGUgZm9yIHRoZSANCmdyb3VwIG1lbWJlcnNoaXAgb2JqZWN0cw0K LSB3b3VsZCBiZSBuaWNlIHRvIGhhdmUgdGV4dCB0aGF0IGRlc2NyaWJlcyB0aGUgYWN0aW9ucyB0 aGF0IGFyZSB0byBiZSBkb25lIA0KYnkgdGhlIHNlcnZlciBvbiBzdWNjZXNzZnVsIHVwZGF0ZQ0K DQpTZWN0aW9uIDIuOA0KDQotIEl0IGlzIHNhaWQgdGhhdCB0aGUgcmVzcG9uc2Ugc3VwcHJlc3Np b24gc2hvdWxkIGJlIGNvbmZpZ3VyYWJpbGUsIHdoaWNoIGlzIA0KZ3JlYXQuICBCdXQgdGhlbiB3 aHkgbm90IGFsbG93aW5nIHRoaXMgdmlhIHRoZSAiR3JvdXAgTWVtYmVyc2hpcCBSRVNUZnVsIA0K SW50ZXJmYWNlIj8NCg0KU2VjdGlvbiAyLjEwDQoNCi0gc2hhbWVsZXNzIHBsdWc6IHRoZSAiTXVs dGlwYXJ0IENvbnRlbnQtRm9ybWF0IEVuY29kaW5nIGZvciBDb0FQIiBJLUQgY291bGQgDQpwcm92 aWRlIHRoZSBhZ2dyZWdhdGlvbiBmb3JtYXQgbmVlZGVkIDstKQ0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KY29yZSBtYWlsaW5nIGxpc3QNCmNvcmVA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmNvcmUgbWFpbGlu ZyBsaXN0DQpjb3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2NvcmUgDQoNCg== From Akbar.Rahman@interdigital.com Tue Dec 17 13:44:15 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8B61A1F19 for ; Tue, 17 Dec 2013 13:44:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhjALx3U3SQs for ; Tue, 17 Dec 2013 13:44:12 -0800 (PST) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2121A1F79 for ; Tue, 17 Dec 2013 13:44:12 -0800 (PST) X-ASG-Debug-ID: 1387316649-06daaa105f65bc0001-aa7cYp Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id mBPGaLnqLKdNxgab for ; Tue, 17 Dec 2013 16:44:09 -0500 (EST) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Dec 2013 16:44:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Tue, 17 Dec 2013 16:44:34 -0500 X-ASG-Orig-Subj: RE: [core] WGLC comments for draft-ietf-core-groupcomm-17 Message-ID: In-Reply-To: <1D599AF996314F5CAEA2D49CF7A7F774@WeiGengyuPC> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] WGLC comments for draft-ietf-core-groupcomm-17 Thread-Index: Ac76H22d1LMTrs3fTFCcRGtP5N6vNQBSSudA References: <1D599AF996314F5CAEA2D49CF7A7F774@WeiGengyuPC> From: "Rahman, Akbar" To: "weigengyu" X-OriginalArrivalTime: 17 Dec 2013 21:44:35.0230 (UTC) FILETIME=[2D6CBBE0:01CEFB71] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1387316649 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.143180 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Cc: core@ietf.org Subject: Re: [core] WGLC comments for draft-ietf-core-groupcomm-17 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 21:44:15 -0000 SGkgR2VuZ3l1LA0KDQoNClRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHRoZSBnb29kIGNvbW1lbnRz LiAgQmVsb3cgYXJlIG91ciBlbWJlZGRlZCBSRVNQT05TRVMuICBQbGVhc2UgcmV2aWV3IGFuZCB3 cml0ZSBiYWNrIHdpdGggeW91ciB0aG91Z2h0cy4NCg0KDQpCZXN0IFJlZ2FyZHMsDQoNCg0KQWti YXIgJiBFc2tvDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHdlaWdlbmd5 dSBbbWFpbHRvOndlaWdlbmd5dUBidXB0LmVkdS5jbl0gDQpTZW50OiBNb25kYXksIERlY2VtYmVy IDE2LCAyMDEzIDEyOjI2IEFNDQpUbzogUmFobWFuLCBBa2JhcjsgRk9TU0FUSSwgVGhvbWFzIChU aG9tYXMpDQpDYzogY29yZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtjb3JlXSBXR0xDIGNvbW1l bnRzIGZvciBkcmFmdC1pZXRmLWNvcmUtZ3JvdXBjb21tLTE3DQoNCj5IaSBBa2JhciwNCj4NCj5J IGFsc28gdGhpbmsgeW91IGRpZCBhIGdvb2Qgam9iLg0KPkFuZCBJIHdvdWxkIGxpa2UgdG8gZ2l2 ZSBzb21lIGNvbW1lbnRzIGFmdGVyIHJlYWRpbmcgeW91ciBkcmFmdC4NCj4NCj5Gcm9tIHRoZSBz Y29wZSAoMS4yIHNjb3BlICkgIHRoZSBkcmFmdCBkZXNjcmliZXMgImdyb3VwIGRlZmluaXRpb24s IGdyb3VwIHJlc291cmNlIG1hbmlwdWxhdGlvbiwgYW5kIGdyb3VwIGNvbmZpZ3VyYXRpb24uIEFs c28sIHByb3h5IG9wZXJhdGlvbiBhbmQgbWluaW1pemluZyBuZXR3b3JrIGNvbmdlc3Rpb24gZm9y IGdyb3VwID5jb21tdW5pY2F0aW9uIg0KPg0KPjEuIGFib3V0IGdyb3VwIGRlZmluaXRpb24NCj4x LjEgICAgWW91IHVzZSAgdGVybWluYWxvZ3lpZXMgZ3JvdXAgY29tbXVuaWNhdGlvbiBmb3IgQ29B UCwgQ29BUCBtdWx0aWNhc3QsIA0KPndoYXQgdGhlIGRpZmZlcmVuY2UgaXM/DQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCltBS0JBUl0gQVMgREVGSU5FRCBJTiBTRUNUSU9OIDEuMywgVEhFIE1B SU4gRElGRkVSRU5DRSBJUyBUSEFUICJNVUxUSUNBU1QiIElOIE9VUiBEUkFGVCBSRUZFUlMgVE8g IklQIE1VTFRJQ0FTVCIuICBXSElMRSAiR1JPVVAgQ09NTVVOSUNBVElPTiIgUkVGRVJTIFRPIFNF TkRJTkcgT0YgQVBQTElDQVRJT04gQ09BUCBNRVNTQUdFUyBPVkVSIElQIE1VTFRJQ0FTVC4gIFBF UkhBUFMgT05FIENMQVJJRklDQVRJT04gV0UgQ0FOIE1BS0UgSVMgQVMgRk9MTE9XUyBUTyBUSEUg IkdST1VQIENPTU1VTklDQVRJT04iIERFRklOSVRJT04gSU4gU0VDVElPTiAxLjM6DQoNCkZST006 DQoiR3JvdXAgQ29tbXVuaWNhdGlvbg0KCUEgc291cmNlIG5vZGUgc2VuZHMgYSBzaW5nbGUgbWVz c2FnZSB3aGljaCBpcyBkZWxpdmVyZWQgdG8gbXVsdGlwbGUgZGVzdGluYXRpb24gbm9kZXMgLi4u Ig0KDQpUTzoNCiJHcm91cCBDb21tdW5pY2F0aW9uDQoJQSBzb3VyY2Ugbm9kZSBzZW5kcyBhIHNp bmdsZSBhcHBsaWNhdGlvbiBsYXllciAoZS5nLiBDb0FQKSBtZXNzYWdlIHdoaWNoIGlzIGRlbGl2 ZXJlZCB0byBtdWx0aXBsZSBkZXN0aW5hdGlvbiBub2RlcyAuLi4iDQoNCkRPIFlPVSBBR1JFRT8N Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQo+MS4yICAgIGluICIyLjIgR3JvdXAgRGVm aW5pdGlvbiBhbmQgTmFtaW5nIg0KPiAgICAgICAgIkEgZ3JvdXAgaXMgZGVmaW5lZCBhcyBhIHNl dCBvZiBDb0FQIGVuZHBvaW50cywgd2hlcmUgZWFjaCBlbmRwb2ludCBpcyBjb25maWd1cmVkIHRv IHJlY2VpdmUgbXVsdGljYXN0IENvQVAgcmVxdWVzdHMgdGhhdCBhcmUgc2VudCB0byB0aGUgZ3Jv dXDigJlzIGFzc29jaWF0ZWQgSVAgbXVsdGljYXN0IGFkZHJlc3MuDQo+QW4gZW5kcG9pbnQgTUFZ IGJlIGEgbWVtYmVyIG9mIG11bHRpcGxlIGdyb3Vwcy4gR3JvdXAgbWVtYmVyc2hpcCBvZiBhbiBl bmRwb2ludCBNQVkgZHluYW1pY2FsbHkgY2hhbmdlIG92ZXIgdGltZS4iDQo+ICAgICAgICAgQXMg Q29BUCBlbmRwb2ludHMgaW5jbHVkZSBjbGllbnQgYW5kIHNlcnZlcnMsICBBIENvQVAgR3JvdXAg c2hvdWxkIGluY2x1ZGUgYSBzZW5kZXIgKGF0IGxlYXN0KSBhbmQgbXVsdGlwbGUgcmVjaWV2ZXJz Lg0KPiAgICAgICBvciB5b3UgY2FuIGNhbGxlZCB0aGUgc2VydmVycyByZWxhdGVkIHRvIHRoZSBz cGVjaWZpYyBJUCBtdWx0aWNhc3QgYWRkcmVzcyBhcyBhIHJlY2VpdmUtb25seSBncm91cC4NCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KW0FLQkFSXSBJVCBJUyBPUFRJT05BTCBGT1IgVEhFIFNF TkRFUiBUTyBCRSBQQVJUIE9GIFRIRSBDT0FQIEdST1VQIEFTIFdFIEhBVkUgU1RBVEVEIElOIFRI RSBERUZJTklUSU9OIE9GIEdST1VQIENPTU1VTkNBVElPTiBJTiBTRUNUSU9OIDEuMy4gIChJLkUu ICJUaGUgc291cmNlIG5vZGUgaXRzZWxmIG1heSBiZSBwYXJ0IG9mIHRoZSBncm91cCIpLiAgIFRI SVMgSVMgSE9XIEFMTCAgVU5ERVJMWUlORyBJUCBNVUxUSUNBU1QgR1JPVVBTIFdPUksuDQoNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCj4xLjMgICJOb3RlOiBBIEdyb3VwIFVSSSBpcyBu ZWVkZWQgdG8gaW5pdGlhdGUgQ29BUCBncm91cCBjb21tdW5pY2F0aW9ucy4iDQo+ICAgICAgICBJ cyBpdCBwb3NzaWJsZSB0byBnaXZlIEdyb3VwIFVSSSBhbiBleHBsaWNpdHkgU3ltYmxlIHRoYXQg aXMgZGlmZmVyZW50IGZyb20gSG9zdCBVUkksIGp1c3QgYXMgc3BlY2lmaWVkIGluIHRoZSByZXNv dXJjZSB0eXBlLg0KPiAgICAgICAgVGhlIGRpZmZlcmVuY2UgaXMgbm90IG9ubHkgaW4gdGhlIG1l YW5pbmcgb2Ygd29yZHMsIGJ1dCBhbHNvIGJ5IHRoZSBzeW1ib2xlIGRlZmluaXRpb24uDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCltBS0JBUl0gV0UgU1RBVEVEIElOIFNFQ1RJT04gMi4yICgi R3JvdXAgVVJJcyBmb2xsb3cgdGhlIENvQVAgVVJJIHN5bnRheCIpIFNPIEkgQU0gTk9UIFNVUkUg V0hBVCBZT1UgTUVBTiBCWSBESUZGRVJFTlQgU1lNQk9MPyAgV0UgV0lMTCBIT1dFVkVSIENMQVJJ RlkgV0hBVCAiZ3JvdXAgY29tbXVuaWNhdGlvbnMgcmVxdWVzdCBBUEkiIE1FQU5TIEZST00gVEhF IFNBTUUgU0VDVElPTiAyLjIgQVMgVEhPTUFTIFNVR0dFU1RFRC4gIFdJTEwgVEhBVCBBTlNXRVIg IFlPVVIgUVVFU1RJT04/DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCj4yLiBhYm91 dCBncm91cCBjb25maWd1cmF0aW9uDQo+DQo+Mi4xIGluICIyLjMuIFBvcnQgYW5kIFVSSSBDb25m aWd1cmF0aW9uIg0KPiAgICAgIElzIGl0IHBvc3NpYmxlIGFuZCBuZWNlc3NhcnkgdG8gZGVmaW5l IGEgQ29BUCBHcm91cCBDb21tIHBvcnQgbnVtYmVyPw0KPiAgICAgIEV2ZW4gdGhvdWZoIENvQVAg U3VwcG9ydHMgIG11bHRpY2FzdCwgIGl0IGhhcyBubyBleHBsaWNpdHkgZmxhZyBpbiBtZXNzYWdl IHdoZW4gZG9pbmcgbXVsdGljYXN0Lg0KPiAgICAgIElmIHRoZXJlIGlzIGEgZGVkaWNhdGVkIENv QVAgR3JvdXAgQ29tbSBwb3J0IG51bWJlciwgdGhlIGRpZmZlcmVjZSBmb3IgdW5pY2FzdCBhbmQg bXVsdGljYXN0IGFyZSBjbGVhcjsgYWxsIENvQVAgZ3JvdXAgY29tbSBjYW4gdXNlIHRoYXQgVURQ IHBvcnQgbnVtYmVyICBhbmQgZGlmZmVyZW50IGdyb3VwcyBhcmUgaWRlbnRpZmllZCBieSA+R3Jv dXAgVVJJLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpbQUtCQVJdIFRIRSBTVEFOREFSRCBX QVkgRk9SIEEgU0VSVkVSIFRPIEtOT1cgVEhBVCBJVCBSRUNFSVZFRCBBIE1VTFRJQ0FTVCBNRVNT QUdFIElTIElERU5USUZJRUQgSU4gU0VDVElPTiAyLjgNCg0KICAgIlRvIGFwcGx5IGFueSBydWxl cyBmb3IgcmVxdWVzdCBhbmQvb3IgcmVzcG9uc2Ugc3VwcHJlc3Npb24sIGEgQ29BUA0KICAgc2Vy dmVyIG11c3QgYmUgYXdhcmUgdGhhdCBhbiBpbmNvbWluZyByZXF1ZXN0IGFycml2ZWQgdmlhIG11 bHRpY2FzdA0KICAgYnkgbWFraW5nIHVzZSBvZiBBUElzIHN1Y2ggYXMgSVBWNl9SRUNWUEtUSU5G TyBbUkZDMzU0Ml0uIg0KDQoNCkRPRVMgVEhBVCBBTlNXRVIgWU9VUiBRVUVTVElPTj8NCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCj4yLjIgaW4gIjIuNS4gTWVzc2FnaW5nIGFuZCBSZXNw b25zZXMiDQo+ICAgICAgIlRoZSBDb0FQIGNsaWVudCBjYW4gZGlzdGluZ3Vpc2ggdGhlIG9yaWdp biBvZiBtdWx0aXBsZSBzZXJ2ZXIgcmVzcG9uc2VzIGJ5IHNvdXJjZSBJUCBhZGRyZXNzIG9mIHRo ZSBVRFAgbWVzc2FnZSBjb250YWluaW5nIHRoZSBDb0FQIHJlc3BvbnNlLiBJbiBjYXNlIGEgQ29B UCBjbGllbnQgc2VudCBtdWx0aXBsZSBncm91cCByZXF1ZXN0cywgPnRoZSByZXNwb25zZXMgYXJl IGFzIHVzdWFsIG1hdGNoZWQgdG8gYSByZXF1ZXN0IHVzaW5nIHRoZSBDb0FQIFRva2VuLiINCj4g ICAgICAgU3VnZ2VzdCB0byAiVGhlIENvQVAgY2xpZW50IGNhbiBkaXN0aW5ndWlzaCB0aGUgb3Jp Z2luIG9mIG11bHRpcGxlIHNlcnZlciByZXNwb25zZXMgYnkgc291cmNlIElQIGFkZHJlc3Mgb2Yg dGhlIFVEUCBtZXNzYWdlLCAgQ29BUCBVUkksIG9yIG90aGVyIHVuaXF1ZSBpZGVudGl0eS4gICIN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KW0FLQkFSXSBCVVQgVEhFUkUgSVMgTk8gIkNvQVAg VVJJIiAgSU4gQSBSRVNQT05TRT8NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KDQo+ Mi4zIGluICIyLjcuMi4gUkVTVGZ1bCBJbnRlcmZhY2UiDQo+ICAgICAgIlRvIGFjY2VzcyB0aGlz IGludGVyZmFjZSBhIGNsaWVudCBNVVNUIHVzZSB1bmljYXN0IENvQVAgbWV0aG9kcw0KPihHRVQv UFVUL1BPU1QvREVMRVRFKSBvbmx5IGFzIGl0IGlzIGEgbWV0aG9kIG9mIGNvbmZpZ3VyaW5nIGdy b3VwIGluZm9ybWF0aW9uIGluIGluZGl2aWR1YWwgZW5kcG9pbnRzLiINCj4gICAgICBJIGRvIHN1 Z2dlc3QgdG8gYWRkIGEgY2xpZW50IHRvIHVzZSBtdWx0aWNhc3QgQ29BUCBtZXRob2RzIGFzIG9w dGlvbi4NCj4gICAgIENvbmZpZ3VyZSB0aGUgZW5kcG9pbnRzIG9uZSBieSBvbmUgbWF5IGhhcyBj b25zaWRlcmF0aW9ucyBvZiBzZWN1cml0eSBpc3N1ZXMsIGJ1dCBzaG91bGQgcmVzZXJ2ZSBvbmUg dG8gbWFueSBjb25maWd1cmF0aW9uIG9wZXJhdGlvbnMuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KW0FLQkFSXSBDVVJSRU5UTFkgSU4gQ09BUCBUSEUgT05MWSBTRUNVUklUWSBJUyBPTkUg VE8gT05FIChJLkUuIFVOSUNBU1QgRFRMUykuICBUSEVSRSBJUyBOTyBNVUxUSUNBU1QgU0VDVVJJ VFkuICBTTyBJIERPTidUIFVOREVSU1RBTkQgWU9VUiBMQVNUIFNFTlRFTkNFPw0KDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCg0KDQo+My4gZ3JvdXAgcmVzb3VyY2UgbWFuaXB1bGF0aW9uDQo+ ICAgICBpbiAiMi45LiBDb25nZXN0aW9uIENvbnRyb2wiLA0KPg0KPiAgICAgVGhlIGRyYWZ0IGdp dmVzIGRlY3JpcHRpb25zIG9uICAiIENvQVAgW0ktRC5pZXRmLWNvcmUtY29hcF0gcmVkdWNlcyBt dWx0aWNhc3Qtc3BlY2lmaWMgY29uZ2VzdGlvbiByaXNrcyB0aHJvdWdoIHRoZSBmb2xsb3dpbmcg bWVhc3VyZXM6IC4uLi4uLiINCj4gICAgIEJ1dCB0aGVyZSBhcmUgbm8gd29yZHMgYWJvdXQgaG93 IGEgbm9kZSBzaG91bGQgZG8gd2hlbiB0aGVyZSBpcyBjb25nZXN0aW9uLg0KPiAgICAgTWF5YmUg dGhpcyBpcyB0aGUgY3JpdGljYWwgaXNzdWUgb2YgY29uZ2VzdGlvbiBjb250cm9sIGFuZCB0aGlz IGlzIG91dCBvZiB0aGUgc2NvcGUuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KW0FLQkFS XSBZT1UgQVJFIENPUlJFQ1QuICBXRSBPTkxZIEdJVkUgUlVMRVMgVE8gQVZPSUQgQ09OR0VTVElP Ti4gIEFOWVRISU5HIEVMU0UgSVMgT1VUIE9GIFNDT1BFLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCg0KDQo+SSBhbSBhcHByZWNpYXRlIHlvdXIgd29ya3Mgb24gc2VjdGlvbiAzIGFuZCA0 LiAgQW5kIG5vIGNvbW1ldHMgb24gb3RoZXJzIGN1cnJlbnRseS4NCj4NCj5KdXN0IHJlYWQgVGhv bWFzIGVtYWlsDQo+ICItIGh0dHBiaXMgaGFzIGJlZW4gc2VudCB0byBJRVNHIGZvciBwdWJsaWNh dGlvbiwgSSBndWVzcyBpdCdzIG9rIHRvIA0KPiByZWZlcmVuY2UgaXQgaW5zdGVhZCBvZiAyNjE2 OyINCj4NCj4gICAgIElmIGl0IHJlZmVyZXMgdG8gaHR0cDIuMCwgSSBwcmVmZXIgcmZjMjYxNi4g IEkgYW0gbm90IHN1cmUgd2hldGhlcg0KPmh0dHAyLjAgaXMgc28tY2FsbGVkIFJFU1RmdWwuDQoN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KW0FLQkFSXSBZRVMuICBQTEVBU0UgU0VFIE1ZIFJF U1BPTlNFIFRPIFRIT01BUy4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KDQpSZWdh cmRzLA0KDQpHZW5neXUNCg0KTmV0d29yayBUZWNob25vbG9neSBDZW50ZXINClNjaG9vbCBvZiBD b21wdXRlcg0KQmVpamluZyBVbml2ZXJzaXR5IG9mIFBvc3RzICYgVGVsZWNvbW11bmljYXRpb25z DQoNCg0KLS0tLS3ljp/lp4vpgq7ku7YtLS0tLSANCkZyb206IFJhaG1hbiwgQWtiYXINClNlbnQ6 IE1vbmRheSwgRGVjZW1iZXIgMTYsIDIwMTMgMTA6MjMgQU0NClRvOiBGT1NTQVRJLCBUaG9tYXMg KFRob21hcykNCkNjOiBjb3JlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2NvcmVdIFdHTEMgY29t bWVudHMgZm9yIGRyYWZ0LWlldGYtY29yZS1ncm91cGNvbW0tMTcNCg0KSGkgVGhvbWFzLA0KDQoN ClRoYW5rcyBmb3IgeW91ciBkZXRhaWxlZCByZXZpZXcuICBFc2tvIGFuZCBJIHdpbGwgcmV2aWV3 IHlvdXIgY29tbWVudHMgaW4gDQp0aGUgbmV4dCAgZmV3IGRheXMgYW5kIGdldCBiYWNrIHRvIHlv dSB3aXRoIGEgY29uc29saWRhdGVkIHJlc3BvbnNlLg0KDQoNCkFrYmFyDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBjb3JlIFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgRk9TU0FUSSwgVGhvbWFzIA0KKFRob21hcykNClNlbnQ6IFNhdHVyZGF5 LCBEZWNlbWJlciAxNCwgMjAxMyA0OjI4IFBNDQpUbzogY29yZSAoY29yZUBpZXRmLm9yZykNClN1 YmplY3Q6IFtjb3JlXSBXR0xDIGNvbW1lbnRzIGZvciBkcmFmdC1pZXRmLWNvcmUtZ3JvdXBjb21t LTE3DQoNCkhpIEFrYmFyLCBFc2tvLg0KDQpHb29kIGpvYiB3aXRoIHRoZSBkb2N1bWVudC4gIFRo ZSDigJxVc2UgQ2FzZXPigJ0gc2VjdGlvbiBpcyBlc3BlY2lhbGx5IA0KZW5qb3lhYmxlLg0KDQpU aGVyZSBhcmUgbm8gbWFqb3IgaXNzdWVzIG9uIG15IHNpZGU7IHRoZSBmb2xsb3dpbmcgY29tbWVu dHMgYXJlIG1vc3RseSANCmVkaXRvcmlhbC4NCg0KQ2hlZXJzLCBUaG9tYXMuDQoNClNlY3Rpb24g MS4xDQoNCi0gaHR0cGJpcyBoYXMgYmVlbiBzZW50IHRvIElFU0cgZm9yIHB1YmxpY2F0aW9uLCBJ IGd1ZXNzIGl0J3Mgb2sgdG8gDQpyZWZlcmVuY2UgaXQgaW5zdGVhZCBvZiAyNjE2Ow0KLSBsYXN0 IHBhcmE6IGl0J2QgYmUgc3VwZXIgbmljZSB0byBoYXZlIHBvaW50ZXJzIHRvIHNlY3Rpb25zIHdo aWxlIHRvcGljcyANCmFyZSBlbnVtZXJhdGVkOw0KDQpTZWN0aW9uIDEuMw0KDQotICJJUCBtdWx0 aWNhc3QiIGRlZmluaXRpb24gY291bGQgYmUgbWFkZSBhIGJpdCByaWNoZXI/ICBUbyBtZSBJUCBt dWx0aWNhc3QgDQppcyBub3QganVzdCBhIG1hdHRlciBvZiBhZGRyZXNzaW5nLCBpcyBhbHNvIHRo ZSBtZW1iZXJzaGlwIG1hbmFnZW1lbnQsIHRoZSANCnJvdXRpbmcgYW5kIGZvcndhcmRpbmcsIHRo ZSBhYnN0cmFjdGlvbiBidWlsdCBvbiB0b3Agb2YgZGlmZmVyZW50IEwyIA0KcHJvdG9jb2xzLg0K DQpTZWN0aW9uIDIuMg0KDQotIGZpcnN0IHBhcmE6IGlzIGl0IG5lY2Vzc2FyeSBmb3IgdGhlIHR3 byBNQVkncyB0byBiZSBSRkMyMTE5Pw0KLSBzZWNvbmQgcGFyYSwgbGFzdCBzZW50ZW5jZTogaXMg dGhlcmUgYW55IHJlYXNvbiB3aHkgdGhlICJtYXkgYWxzbyBiZSANCmVuYWJsZWQiIGlzIG5vdCBS RkMyMTE5Pw0KLSBmb3VydGggcGFyYTogaXQncyBub3QgY2xlYXIgdG8gbWUgd2hhdCB0aGUgImdy b3VwIGNvbW11bmljYXRpb24gcmVxdWVzdCANCkFQSSIgaXMNCi0gZmlmdGggcGFyYTogaXMgdGhl ICJJdCBpcyByZWNvbW1lbmRlZCIgbWVhbnQgdG8gYmUgUkZDMjExOT8NCi0gbGFzdCBwYXJhOiBu b3QgY2xlYXIgd2hhdCB0aGUgdXNlIGNhc2UgZm9yIHRoZSByZXZlcnNlIEROUyBtYXBwaW5nIHdv dWxkIA0KYmUuDQoNClNlY3Rpb24gMi4zDQoNCi0gaXNuJ3QgYnVsbGV0IDMuIChpLmUuIHVzZSB0 aGUgZGVmYXVsdCBDb0FQIHBvcnQpIGp1c3QgYSBzcGVjaWFsIGNhc2Ugb2YgMS4gDQooaS5lLiBw cmUtY29uZmlndXJlZCBwb3J0IG51bWJlcik/DQoNClNlY3Rpb24gMi40DQoNCi0gSSBndWVzcyBp dCdzIHRoZSB1bnJlbGlhYmxlIChtb3JlIHRoZW4gdGhlIGxvc3N5KSBuYXR1cmUgb2YgSVAgbXVs dGljYXN0IA0KdGhhdCBtYWtlcyBQT1NUIHVudXNhYmxlPw0KDQpTZWN0aW9uIDIuNQ0KDQotIHNl Y29uZCBwYXJhOiBpdCBsb29rcyBsaWtlIHRoZSBzZXJ2ZXIgY2FuIHVuaWxhdGVyYWxseSBkZWNp ZGUgdG8gc3VwcHJlc3MgDQphIHJlc3BvbnNlIHRvIGEgbXVsdGljYXN0IHJlcXVlc3QuICBCdXQg dGhlcmUgaXMgbm8gbWVudGlvbiBhYm91dCB3aGljaCANCmNvbmRpdGlvbnMgY291bGQgdHJpZ2dl ciB0aGUgYWN0dWFsIHJlc3BvbnNlIHN1cHByZXNzaW9uLiAgQSBwb2ludGVyIHRvIA0KU2VjdGlv biAyLjggcGVyaGFwcz8NCg0KDQpTZWN0aW9uIDIuNw0KDQotIFRoZSB0aXRsZS9uYW1lIGlzIHZl cnkgZ2VuZXJpYy4gICJHcm91cCBNZW1iZXJzaGlwIFJFU1RmdWwgSW50ZXJmYWNlIg0KKG9yIHNp bWlsYXIpIHdvdWxkIGJlIG1vcmUgZWFzaWx5IGFuZCBjb25zaXN0ZW50bHkgcmVmZXJlbmNlZCBp biBzdWJzZXF1ZW50IA0KdGV4dCAod2hlcmUgaXQgYXBwZWFycyBhcyAiUkVTVGZ1bCBDb0FQIGlu dGVyZmFjZSIsIGFuZCB0aGVuIGFzICJSRVNUZnVsIA0KaW50ZXJmYWNlIikuDQotIGZpcnN0IHBh cmE6IG1pc3NpbmcgY29tbWEgIlsuLi5dIG9ubHkgYXMgWy4uLl0iIC0+ICJbLi4uXSBvbmx5LCBh cyBbLi4uXSINCi0gc2Vjb25kIHBhcmE6IHRoZSAiVGh1cyBvbmx5IGF1dGhvcml6ZWQgY29udHJv bGxlcnMgWy4uLl0iIGlzIG5vdCBjbGVhciB0byANCm1lOiBpdCBzZWVtcyB0byBpbXBseSB0aGF0 IERUTFMgcHJvdmlkZXMgYXV0aG9yaXNhdGlvbiwgd2hpY2ggaXQgZG9lc24ndC4NCg0KU2VjdGlv biAyLjcuMi4xDQoNCi0gdGhlIGJlZ2lubmluZyBvZiB0aGlzIHNlY3Rpb24gY291bGQgaGF2ZSBh IHNtYWxsIGRlc2NyaXB0aW9uIG9mIHRoZSANCnNlbWFudGljcywgYmVmb3JlIGdvaW5nIGRlZXAg aW50byBzeW50YWN0aWMgZGV0YWlscz8NCi0gc2Vjb25kIHBhcmE6ICJBIHJlc291cmNlIG9mZmVy aW5nIHRoaXMgcmVwcmVzZW50YXRpb24iOiBpdCdzIG5vdCBjbGVhciB0byANCm1lIHdoYXQgInRo aXMgcmVwcmVzZW50YXRpb24iIHJlZmVycyB0bzsNCi0gdGhpcmQgcGFyYTogIlsuLi5dIGluIGEg Zm9ybWF0IGFzIGRlZmluZWQgWy4uLl0iIC0+ICJbLi4uXSBpbiB0aGUgZm9ybWF0IA0KZGVmaW5l ZCBbLi4uXSI7DQotIHByb2JsZW0gd2l0aCB0aGUgZGVmaW5lZCBzeW50YXg6IGl0J3MgaW1wb3Nz aWJsZSB0byBzcGVjaWZ5IGEgbm9uLWxpdGVyYWwgDQpncm91cCB3aXRoIGEgbm9uLWRlZmF1bHQg cG9ydC4gIEknZCBzdWdnZXN0IGFkZGluZyB0aGUgb3B0aW9uYWwgcG9ydCB0byB0aGUgDQpub24t bGl0ZXJhbCBmb3JtYXQgYXMgd2VsbDsNCi0gZmlmdGggcGFyYTogIlNIT1VMRCBOT1QgYmUgaW5j bHVkZWQgaWYgdW5rbm93biIgaXNuJ3QgdGhpcyBtb3JlIGEgTVVTVCANCk5PVD8gIFdoYXQgc2hv dWxkIEkgcHV0IGludG8gaXQgaWYgSSBkb24ndCBrbm93IHdoYXQgdG8gcHV0IGludG8gaXQ/DQpB bHNvLCB0aGUgcHJlY2VkaW5nIE1VU1Qgc291bmRzIG1vcmUgbGlrZSBhIFNIT1VMRD8NCg0KU2Vj dGlvbiAyLjcuMi4yDQoNCi0gSSdkIGFkZCBhIG5vdGUgYWJvdXQgdGhlIG5lZWQgZm9yIHRoZSBH cm91cCBpbmRleCB0byBiZSB1bmlxdWUNCi0gd2hhdCBoYXBwZW5zIHdoZW4gYSBjbGllbnQgdHJp ZXMgdG8gcmVnaXN0ZXIgYSBkdXBsaWNhdGUgImEiPw0KLSBsYXN0IHBhcmE6IGFkZCBjb250ZXh0 L3JhdGlvbmFsZSBmb3IgdGhlIHJlLWpvaW4gcmVxdWlyZW1lbnQgb24gUE9TVCBvZiBhbiANCmFs cmVhZHkgcmVnaXN0ZXJlZA0KDQpTZWN0aW9uIDIuNy4yLjMNCg0KLSB0aGUgIi8iIGluICAiL3sr bG9jYXRpb259IiBsb29rcyByZWR1bmRhbnQNCi0gd291bGQgYmUgbmljZSB0byBoYXZlIHRleHQg dGhhdCBkZXNjcmliZXMgdGhlIGFjdGlvbnMgdGhhdCBhcmUgdG8gYmUgZG9uZSANCmJ5IHRoZSBz ZXJ2ZXIgb24gc3VjY2Vzc2Z1bCBkZWxldGlvbg0KDQpTZWN0aW9uIDIuNy4yLjQNCg0KLSB0aGUg Ii8iIGluICAiL3srbG9jYXRpb259IiBsb29rcyByZWR1bmRhbnQNCg0KU2VjdGlvbiAyLjcuMi41 DQoNCi0gbGFzdCBwYXJhOiBhZGQgcmVmZXJlbmNlIHRvIFJGQzU5NTI/DQoNClNlY3Rpb24gMi43 LjIuNg0KDQotIHdvdWxkIGJlIG5pY2UgdG8gaGF2ZSB0ZXh0IHRoYXQgZGVzY3JpYmVzIHRoZSBh Y3Rpb25zIHRoYXQgYXJlIHRvIGJlIGRvbmUgDQpieSB0aGUgc2VydmVyIG9uIHN1Y2Nlc3NmdWwg dXBkYXRlDQoNClNlY3Rpb24gMi43LjIuNw0KDQotIGZpcnN0IHBhcmE6IGl0J3Mgbm90IGNsZWFy IHdoYXQgbWFrZXMgYSBDb0FQIGNsaWVudCByZXNwb25zaWJpbGUgZm9yIHRoZSANCmdyb3VwIG1l bWJlcnNoaXAgb2JqZWN0cw0KLSB3b3VsZCBiZSBuaWNlIHRvIGhhdmUgdGV4dCB0aGF0IGRlc2Ny aWJlcyB0aGUgYWN0aW9ucyB0aGF0IGFyZSB0byBiZSBkb25lIA0KYnkgdGhlIHNlcnZlciBvbiBz dWNjZXNzZnVsIHVwZGF0ZQ0KDQpTZWN0aW9uIDIuOA0KDQotIEl0IGlzIHNhaWQgdGhhdCB0aGUg cmVzcG9uc2Ugc3VwcHJlc3Npb24gc2hvdWxkIGJlIGNvbmZpZ3VyYWJpbGUsIHdoaWNoIGlzIA0K Z3JlYXQuICBCdXQgdGhlbiB3aHkgbm90IGFsbG93aW5nIHRoaXMgdmlhIHRoZSAiR3JvdXAgTWVt YmVyc2hpcCBSRVNUZnVsIA0KSW50ZXJmYWNlIj8NCg0KU2VjdGlvbiAyLjEwDQoNCi0gc2hhbWVs ZXNzIHBsdWc6IHRoZSAiTXVsdGlwYXJ0IENvbnRlbnQtRm9ybWF0IEVuY29kaW5nIGZvciBDb0FQ IiBJLUQgY291bGQgDQpwcm92aWRlIHRoZSBhZ2dyZWdhdGlvbiBmb3JtYXQgbmVlZGVkIDstKQ0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KY29yZSBt YWlsaW5nIGxpc3QNCmNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vY29yZQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCmNvcmUgbWFpbGluZyBsaXN0DQpjb3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUgDQoNCg== From thomas.fossati@alcatel-lucent.com Tue Dec 17 15:37:58 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B58D1ADBD0 for ; Tue, 17 Dec 2013 15:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JS9nAWirozKA for ; Tue, 17 Dec 2013 15:37:55 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD991AD9AB for ; Tue, 17 Dec 2013 15:37:54 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id rBHNbmQY000976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 17 Dec 2013 17:37:49 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id rBHNblJe019019 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Dec 2013 00:37:47 +0100 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.153]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Wed, 18 Dec 2013 00:37:47 +0100 From: "FOSSATI, Thomas (Thomas)" To: "Rahman, Akbar" Thread-Topic: [core] WGLC comments for draft-ietf-core-groupcomm-17 Thread-Index: AQHO+RNnaMhII7lMuEy2T0VkoimTy5pYtZZAgABJdwA= Date: Tue, 17 Dec 2013 23:37:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="utf-8" Content-ID: <007AC272DD0E714BAE2D056D967FD125@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "core@ietf.org" Subject: Re: [core] WGLC comments for draft-ietf-core-groupcomm-17 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 23:37:58 -0000 SGkgQWtiYXIsIEVza28sDQoNCnRoYW5rcyBmb3IgdGhlIHF1aWNrIGFuZCByaWNoIHJlc3BvbnNl LiAgSeKAmW0gY3V0dGluZyB0aGUgY29tbWVudHMgdGhhdCB5b3UNCmFncmVlZCB0byBhZGRyZXNz LCBhbmQgZm9jdXMgb24gdGhlIHJlbWFpbmluZyBiaXRzLiAgQlRXLCB5b3VyIGlubGluZQ0KY29t bWVudHMgcHJvdmlkZSBhIGxvdCBvZiBnb29kIHN0dWZmIHRoYXQgd291bGQgYmUgbmljZSB0byBz ZWUgaW4gdGhlDQpmaW5hbCB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVudC4NCg0KT24gMTcvMTIvMjAx MyAxOTo0OSwgIlJhaG1hbiwgQWtiYXIiIDxBa2Jhci5SYWhtYW5AaW50ZXJkaWdpdGFsLmNvbT4g d3JvdGU6DQo+PlNlY3Rpb24gMS4xDQo+Pg0KPj4tIGh0dHBiaXMgaGFzIGJlZW4gc2VudCB0byBJ RVNHIGZvciBwdWJsaWNhdGlvbiwgSSBndWVzcyBpdCdzIG9rIHRvDQo+PnJlZmVyZW5jZSBpdCBp bnN0ZWFkIG9mIDI2MTY7DQo+W0FLQkFSXSBJIFRISU5LIElUIElTIFNBRkVSIEZPUiBVUyBUTyBS RUZFUiBTVElMTCBUTyBSRkMgMjYxNiBGT1IgTk9XLg0KPk9VUiBMT0dJQyBJUyBBUyBGT0xMT1dT IC0gSUYgVEhFIEhUVFBCSVMgRE9DVU1FTlRTIChFLkcuDQo+aHR0cDovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLWh0dHBiaXMtcDEtbWVzc2FnaW5nLyApIEdFVA0KPlBVQkxJ U0hFRCBJTiBUSU1FLCBUSEVOIFRIRSBSRkMgRURJVE9SIFdJTEwgQVVUT01BVElDQUxMWSBDSEFO R0UgVEhFDQo+UkVGRVJFTkNFIElOIFRISVMgRE9DVU1FTlQgKEFTIFRIRSBORVcgRE9DVU1FTlRT IFdJTEwgT0JTRUxFVEUgUkZDIDI2MTYpLg0KPiBBTFNPIFRIRVJFIElTIEEgU0VUIE9GIDUgRE9D VU1FTlRTIFJFUExBQ0lORyAyNjE2IFNPIFdFIEFSRSBOT1QgU1VSRQ0KPldIQVQgQ09OVkVOVElP TiBUSEUgUkZDIEVESVRPUiBXSUxMIFVTRSAoSS5FLiBXSUxMIFRIRVkgUkVGRVJFTkNFIEFMTCA1 DQo+RE9DVU1FTlRTIE9SIE9OTFkgVEhFIEZJUlNUPykuDQoNCklJUkMgYXQgc29tZSBwb2ludCBp biB0aW1lIHRoZXJlIHdhcyBhIOKAnFBhcnQgMOKAnSBkb2N1bWVudCBmbG9hdGluZyBhcm91bmQN CkhUVFBiaXMsIHdoaWNoIHByb3ZpZGVkIGEgc2luZ2xlIHJlZmVyZW5jZSBwb2ludCBmb3IgdGhl IHdob2xlIGRvY3Mgc2V0Lg0KSeKAmXZlIHNlYXJjaGVkIGJyaWVmbHkgaW4gaHR0cDovL2RhdGF0 cmFja2VyLmlldGYub3JnL3dnL2h0dHBiaXMvIGJ1dCBJDQpjYW7igJl0IGZpbmQgaXQgYW55bW9y ZS4gIEFncmVlZCB0byBsZXQgdGhlIFJGQyBFZGl0b3IgYWRqdXN0IHRoZSByZWZlcmVuY2UNCmFz IG5lZWRlZC4NCg0KPj4tIGZpZnRoIHBhcmE6IGlzIHRoZSAiSXQgaXMgcmVjb21tZW5kZWQiIG1l YW50IHRvIGJlIFJGQzIxMTk/DQo+W0FLQkFSXSBXRSBQUkVGRVIgVE8gTEVBVkUgSVQgQVMgTk9O IFJGQyAyMTE5LiAgUkVBU09OIC0gSVQgSEFTIE5PIElNUEFDVA0KPk9OIElOVEVST1BFUkFCSUxJ VFkgQVMgVEhFIFBST0NFU1MgREVTQ1JJQkVEIEhBUFBFTlMgSU5TSURFIEEgU0lOR0xFIENPQVAN Cj5DTElFTlQgVEhBVCBPUFRJT05BTExZIENPTlRBQ1RTIEEgTk9OLUNPQVAgQVdBUkUgRE5TIFNF UlZFUi4gIFRIRQ0KPlJFQ09NTUVOREFUSU9OIFNFUlZFUyBIRVJFIFRPIE1BS0UgVEhJUyBQUk9D RVNTIE1PUkUgRUZGSUNJRU5UIEJZDQo+U0tJUFBJTkcgVEhFIEROUyBSRVNPTFVUSU9OIFNURVAs IFdIRU5FVkVSIFBPU1NJQkxFLiAgQUxTTywgVEhFIFdHDQo+SU5ESUNBVEVEIFRIQVQgRE5TIFJF U09MVVRJT04gT0YgSVAgTVVMVElDQVNUIEFERFJFU1NFUyBNQVkgT0ZURU4gTk9UIEJFDQo+REVQ TE9ZRUQgKEFUIExFQVNUIElOSVRJQUxMWSkuDQoNCk9LLg0KDQo+Pi0gbGFzdCBwYXJhOiBub3Qg Y2xlYXIgd2hhdCB0aGUgdXNlIGNhc2UgZm9yIHRoZSByZXZlcnNlIEROUyBtYXBwaW5nDQo+Pndv dWxkIGJlLg0KPltBS0JBUl0gUkVWRVJTRSBETlMgTUFQUElORyBNQVkgT0NDVVIgRFVSSU5HIEFO IEFVRElUL0lOU1BFQ1RJT04gT0YgQQ0KPkJVSUxESU5HIENPTlRST0wgU1lTVEVNLiAgQU4gQVVU SE9SSVpFRCBDT0FQIENMSUVOVCAoRS5HLiBMT0NBTA0KPkNPTU1JU1NJT05JTkcgVE9PTCBPUiBE SUFHTk9TVElDUyBOT0RFIE9OIFRIRSBJUCBORVRXT1JLKSBVU0VTIFRIRQ0KPlJFU1RGVUwgSU5U RVJGQUNFIChTRUNUSU9OIDIuNy4yKSBUTyBSRVRSSUVWRSBHUk9VUCBNRU1CRVJTSElQIChJUA0K Pk1VTFRJQ0FTVCBBRERSRVNTKSBPRiBBIE5VTUJFUiBPRiBOT0RFUy4gIFRIRU4gSVQgVVNFUyBS RVZFUlNFIEROUw0KPk1BUFBJTkcgVE8gVFJBTlNMQVRFIFRIRVNFIEJBQ0sgVE8gSFVNQU4tUkVB REFCTEUgSE9TVE5BTUVTLCBUTyBTSE9XIElODQo+VEhFIERJQUdOT1NUSUNTIFVJLg0KDQpFeGNl bGxlbnQuICBXb3VsZCB5b3UgbWluZCBhZGRpbmcgdGhlIHVzZS1jYXNlIGRlc2NyaWJlZCBhYm92 ZSB0byB0aGUNCmN1cnJlbnQgdGV4dD8NCg0KPj5TZWN0aW9uIDIuMw0KPj4NCj4+LSBpc24ndCBi dWxsZXQgMy4gKGkuZS4gdXNlIHRoZSBkZWZhdWx0IENvQVAgcG9ydCkganVzdCBhIHNwZWNpYWwg Y2FzZQ0KPj5vZiAxLiAoaS5lLiBwcmUtY29uZmlndXJlZCBwb3J0IG51bWJlcik/DQo+W0FLQkFS XSBZRVMsIEJVVCBJVCBJUyBDTEVBUkVSIFRPIExFQVZFIFRIRU0gQVMgU0VQQVJBVEUgQ0FTRVMg QVMgVEhFDQo+REVGQVVMVCBJUyBBIFNQRUNJQUwgVkFMVUUgVEhBVCBTSE9VTEQgQkUgRVhQTElD SVRMWSBDQUxMRUQgT1VULg0KDQpPSy4NCihMb29raW5nIGF0IGl0IHdpdGggbXkgaW1wbGVtZW50 ZXIgc3BlY3Mgb24gSSB3YXMgc2VlaW5nIGEgY29uZmlnIGZpbGUNCnByb3ZpZGluZyBzdGF0aWMg c2V0dGluZ3MsIHNoaXBwaW5nIHdpdGggdGhlIHBvcnQtbnVtYmVyIHZhcmlhYmxlIGhhdmluZyBh DQpwcmUtY2FubmVkIDU2ODMgdmFsdWUuKQ0KDQo+Pi0gc2Vjb25kIHBhcmE6IHRoZSAiVGh1cyBv bmx5IGF1dGhvcml6ZWQgY29udHJvbGxlcnMgWy4uLl0iIGlzIG5vdCBjbGVhcg0KPj50byBtZTog aXQgc2VlbXMgdG8gaW1wbHkgdGhhdCBEVExTIHByb3ZpZGVzIGF1dGhvcmlzYXRpb24sIHdoaWNo IGl0DQo+PmRvZXNuJ3QuDQo+W0FLQkFSXSAoQ09NTUVOVCBJUyBUTyAyLjcuMikuICBUSElTIFNF RU1TIFRPIEdFVCBJTlRPIFRIRSBXSE9MRSBRVUVTVElPTg0KPk9GIEFDTCBCRUlORyBSQUlTRUQg SU4NCj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvYWNlL2N1cnJlbnQvbXNn MDAwNDkuaHRtbCAuICBCVVQNCj5QRVJIQVBTIFdFIENBTiBKVVNUIENIQU5HRSBUSEUgU0VOVEVO Q0UgVE86ICJQUkVGRVJBQkxZIEEgRk9STSBPRg0KPkFVVEhPUklaQVRJT04gKE1BS0lORyBVU0Ug T0YgRFRMUyBBVVRIRU5USUNBVElPTikgSVMgSU1QTEVNRU5URUQgQVMgV0VMTCwNCj5TVUNIIFRI QVQgT05MWSBBVVRIT1JJWkVEIENPTlRST0xMRVJTIEFSRSBBTExPV0VEIEJZIEFOIEVORFBPSU5U IFRPDQo+Q09ORklHVVJFIElUUyBHUk9VUCBNRU1CRVJTSElQIi4NCg0KU291bmRzIGdvb2QuDQoN Cj4+U2VjdGlvbiAyLjcuMi4zDQo+Pg0KPj4tIHRoZSAiLyIgaW4gICIveytsb2NhdGlvbn0iIGxv b2tzIHJlZHVuZGFudA0KPj4tIHdvdWxkIGJlIG5pY2UgdG8gaGF2ZSB0ZXh0IHRoYXQgZGVzY3Jp YmVzIHRoZSBhY3Rpb25zIHRoYXQgYXJlIHRvIGJlDQo+PmRvbmUgYnkgdGhlIHNlcnZlciBvbiBz dWNjZXNzZnVsIGRlbGV0aW9uDQo+PlNlY3Rpb24gMi43LjIuNA0KPj4NCj4+LSB0aGUgIi8iIGlu ICAiL3srbG9jYXRpb259IiBsb29rcyByZWR1bmRhbnQNCj5bQUtCQVJdIFRISVMgV0FTIFRBS0VO IEZST00gQ09SRS1SRVNPVVJDRS1ESVJFQ1RPUlktMDAgU08gV0UgV0lMTCBLRUVQIElUDQo+IFVO TEVTUyBUSEVZIENIQU5HRSBBUyBXRUxMLg0KDQpBaCwgT0suICBBbnl3YXksIHdpdGggVVJJLXRl bXBsYXRlcywgaWYgeW91IGhhdmUgYSB2YXJpYWJsZSAnbG9jYXRpb24nDQpwb3B1bGF0ZWQgYnkg YSBMb2NhdGlvbi1QYXRoIE9wdGlvbiBsaWtlIHRoaXM6DQoNCiAgbG9jYXRpb24gOj0gJy9jb2Fw LWdyb3VwLzEyJw0KDQpBbmQgYW4gYXNzb2NpYXRlZCBVUkktdGVtcGxhdGUgbGlrZSB0aGlzOg0K DQogIC97K2xvY2F0aW9ufQ0KDQoNClRoZW4gdGhlIGV4cGFuc2lvbiB3b3VsZCBiZToNCg0KICAv L2NvYXAtZ3JvdXAvMTINCg0KPj5TZWN0aW9uIDIuOA0KPj4NCj4+LSBJdCBpcyBzYWlkIHRoYXQg dGhlIHJlc3BvbnNlIHN1cHByZXNzaW9uIHNob3VsZCBiZSBjb25maWd1cmFiaWxlLA0KPj53aGlj aCBpcyBncmVhdC4gIEJ1dCB0aGVuIHdoeSBub3QgYWxsb3dpbmcgdGhpcyB2aWEgdGhlICJHcm91 cA0KPj5NZW1iZXJzaGlwIFJFU1RmdWwgSW50ZXJmYWNlIj8NCj5bQUtCQVJdIFdFIFNQRUNJRklD QUxMWSBLRVBUIFRIRSBHUk9VUCBNRU1CRVJTSElQIElOVEVSRkFDRSBUTyBPTkxZDQo+REVGSU5F IFRIRSBOQU1FIEFORCBJUCBBRERSRVNTRVMgT0YgVEhFIEdST1VQLiAgSUYgV0UgT1BFTiBJVCBV UCBUTyBPVEhFUg0KPlBBUkFNRVRFUlMgVEhFTiBJVCBXSUxMIEdFVCBVTldJRUxETFkuDQoNCk9L LiAgQWdyZWVkIHRoaXMgaXMgbm90IHRoZSByaWdodCB0aW1pbmcgZm9yIGEgY29tbWVudCBsaWtl IHRoaXMuICBJDQpzaG91bGQgaGF2ZSBkb25lIGl0IHByZS1XR0xDIDotKQ0KDQo+PlNlY3Rpb24g Mi4xMA0KPj4NCj4+LSBzaGFtZWxlc3MgcGx1ZzogdGhlICJNdWx0aXBhcnQgQ29udGVudC1Gb3Jt YXQgRW5jb2RpbmcgZm9yIENvQVAiIEktRA0KPj5jb3VsZCBwcm92aWRlIHRoZSBhZ2dyZWdhdGlv biBmb3JtYXQgbmVlZGVkIDstKQ0KPltBS0JBUl0gTklDRSBQUk9QT1NBTCwgQlVUIFRIRSBNVUxU SVBBUlQgRk9STUFUIElGICBVU0VEIEZPUiBHUk9VUENPTU0NCj5XT09VTEQgQUxTTyBIQVZFIFRP IEVOQ09ERSBUSEUgSURFTlRJVElFUyAoSVAgQUREUkVTU0VTKSBPRiBUSEUNCj5JTkRJVklEVUFM IFNFUlZFUlMgVEhBVCBQUk9WSURFIEVBQ0ggUkVTUE9OU0UuICBTTyBJVCBJUyBOT1QgMTAwJQ0K PlNVSVRBQkxFIFlFVC4gIERPIFlPVSBBR1JFRT8NCg0KTXVsdGlwYXJ0IGlzIHJlY3Vyc2l2ZSwg c28geW91IGNvdWxkIGhhdmUgYW4gaW5uZXIgbXVsdGlwYXJ0IHdoaWNoDQphZ2dyZWdhdGVzIHRo ZSBwZXItcmVzcG9uc2UgYXR0cmlidXRlcyAoaS5lLiBpZGVudGlmaWVyL2xvY2F0b3Igb2YgdGhl DQpzZW5kZXIsIENvQVAgcGF5bG9hZCksIGFuZCBhbiBvdXRlciBtdWx0aXBhcnQgcHJvdmlkaW5n IHRoZSBsaXN0L3NldCB0aGF0DQpnYXRoZXJzIGFsbCB0aGUgcmVzcG9uc2VzIHRvZ2V0aGVyLg0K DQoNCkNoZWVycywgVGhvbWFzLg0KDQoNCg== From weigengyu@bupt.edu.cn Tue Dec 17 19:31:02 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBAC1AE23A for ; Tue, 17 Dec 2013 19:31:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJ59xGXwlq2M for ; Tue, 17 Dec 2013 19:30:57 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 833D81AE049 for ; Tue, 17 Dec 2013 19:30:55 -0800 (PST) Received: from WeiGengyuPC (unknown [10.103.241.46]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 3584819F3A0; Wed, 18 Dec 2013 11:30:52 +0800 (HKT) Message-ID: From: "weigengyu" To: "Rahman, Akbar" References: <1D599AF996314F5CAEA2D49CF7A7F774@WeiGengyuPC> In-Reply-To: Date: Wed, 18 Dec 2013 11:30:51 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3505.912 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912 Cc: core@ietf.org Subject: Re: [core] WGLC comments for draft-ietf-core-groupcomm-17 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 03:31:02 -0000 Hi Akbar, My comments on each problem will be sent one by one. >1.1 You use terminologyies group communication for CoAP, CoAP >multicast, >1.2 in "2.2 Group Definition and Naming" Group communication and multicast are different. If multicast in the draft is restricted as the IP mulitcast, CLARIFICATION in terminology definition is OK. CoAP multicast should be avoided. CoAP group communications is different from general group communication. In a CoAP group, there are sender(s) and receivers, the sender and the receiver should be different. A sender is authorizied to send to the gorup by IP multicast. The receivers knows who is/are the sender(s) authorized to send, and receive the message by IP multicast. Each reciever is not permited to send to the group by IP multicast. > TO: > "Group Communication > A source node sends a single application layer (e.g. CoAP) message which > is delivered to multiple destination nodes ..." > DO YOU AGREE? Yes, I agree. > [AKBAR] IT IS OPTIONAL FOR THE SENDER TO BE PART OF THE COAP GROUP AS WE > HAVE STATED IN THE DEFINITION OF GROUP COMMUNCATION IN SECTION 1.3. > (I.E. "The source node itself may be part of the group"). THIS IS HOW > ALL UNDERLYING IP MULTICAST GROUPS WORK. I do not agree that "IT IS OPTIONAL FOR THE SENDER TO BE PART OF THE COAP GROUP ". I do not aggree that the sender is not part of the group. If the sender is not part of the group, how the receivers know whether it is authorize to send. Group membership management is at the application layer. This issue will effect authentication and authorization. Reagrds, Gengyu Network Techonology Center School of Computer Beijing University of Posts & Telecommunications -----原始邮件----- From: Rahman, Akbar Sent: Wednesday, December 18, 2013 5:44 AM To: weigengyu Cc: core@ietf.org ; Dijk, Esko Subject: RE: [core] WGLC comments for draft-ietf-core-groupcomm-17 Hi Gengyu, Thank you very much for the good comments. Below are our embedded RESPONSES. Please review and write back with your thoughts. Best Regards, Akbar & Esko -----Original Message----- From: weigengyu [mailto:weigengyu@bupt.edu.cn] Sent: Monday, December 16, 2013 12:26 AM To: Rahman, Akbar; FOSSATI, Thomas (Thomas) Cc: core@ietf.org Subject: Re: [core] WGLC comments for draft-ietf-core-groupcomm-17 >Hi Akbar, > >I also think you did a good job. >And I would like to give some comments after reading your draft. > >From the scope (1.2 scope ) the draft describes "group definition, group >resource manipulation, and group configuration. Also, proxy operation and >minimizing network congestion for group >communication" > >1. about group definition >1.1 You use terminalogyies group communication for CoAP, CoAP >multicast, >what the difference is? ------------------------ [AKBAR] AS DEFINED IN SECTION 1.3, THE MAIN DIFFERENCE IS THAT "MULTICAST" IN OUR DRAFT REFERS TO "IP MULTICAST". WHILE "GROUP COMMUNICATION" REFERS TO SENDING OF APPLICATION COAP MESSAGES OVER IP MULTICAST. PERHAPS ONE CLARIFICATION WE CAN MAKE IS AS FOLLOWS TO THE "GROUP COMMUNICATION" DEFINITION IN SECTION 1.3: FROM: "Group Communication A source node sends a single message which is delivered to multiple destination nodes ..." TO: "Group Communication A source node sends a single application layer (e.g. CoAP) message which is delivered to multiple destination nodes ..." DO YOU AGREE? ------------------------- >1.2 in "2.2 Group Definition and Naming" > "A group is defined as a set of CoAP endpoints, where each endpoint > is configured to receive multicast CoAP requests that are sent to the > group’s associated IP multicast address. >An endpoint MAY be a member of multiple groups. Group membership of an >endpoint MAY dynamically change over time." > As CoAP endpoints include client and servers, A CoAP Group should > include a sender (at least) and multiple recievers. > or you can called the servers related to the specific IP multicast > address as a receive-only group. ------------------------ [AKBAR] IT IS OPTIONAL FOR THE SENDER TO BE PART OF THE COAP GROUP AS WE HAVE STATED IN THE DEFINITION OF GROUP COMMUNCATION IN SECTION 1.3. (I.E. "The source node itself may be part of the group"). THIS IS HOW ALL UNDERLYING IP MULTICAST GROUPS WORK. ------------------------ >1.3 "Note: A Group URI is needed to initiate CoAP group communications." > Is it possible to give Group URI an explicity Symble that is > different from Host URI, just as specified in the resource type. > The difference is not only in the meaning of words, but also by the > symbole definition. ------------------------ [AKBAR] WE STATED IN SECTION 2.2 ("Group URIs follow the CoAP URI syntax") SO I AM NOT SURE WHAT YOU MEAN BY DIFFERENT SYMBOL? WE WILL HOWEVER CLARIFY WHAT "group communications request API" MEANS FROM THE SAME SECTION 2.2 AS THOMAS SUGGESTED. WILL THAT ANSWER YOUR QUESTION? ------------------------ >2. about group configuration > >2.1 in "2.3. Port and URI Configuration" > Is it possible and necessary to define a CoAP Group Comm port number? > Even thoufh CoAP Supports multicast, it has no explicity flag in > message when doing multicast. > If there is a dedicated CoAP Group Comm port number, the differece > for unicast and multicast are clear; all CoAP group comm can use that UDP > port number and different groups are identified by >Group URI. ------------------------ [AKBAR] THE STANDARD WAY FOR A SERVER TO KNOW THAT IT RECEIVED A MULTICAST MESSAGE IS IDENTIFIED IN SECTION 2.8 "To apply any rules for request and/or response suppression, a CoAP server must be aware that an incoming request arrived via multicast by making use of APIs such as IPV6_RECVPKTINFO [RFC3542]." DOES THAT ANSWER YOUR QUESTION? ------------------------ >2.2 in "2.5. Messaging and Responses" > "The CoAP client can distinguish the origin of multiple server > responses by source IP address of the UDP message containing the CoAP > response. In case a CoAP client sent multiple group requests, >the > responses are as usual matched to a request using the CoAP Token." > Suggest to "The CoAP client can distinguish the origin of multiple > server responses by source IP address of the UDP message, CoAP URI, or > other unique identity. " ------------------------ [AKBAR] BUT THERE IS NO "CoAP URI" IN A RESPONSE? ------------------------ >2.3 in "2.7.2. RESTful Interface" > "To access this interface a client MUST use unicast CoAP methods >(GET/PUT/POST/DELETE) only as it is a method of configuring group >information in individual endpoints." > I do suggest to add a client to use multicast CoAP methods as option. > Configure the endpoints one by one may has considerations of security > issues, but should reserve one to many configuration operations. ------------------------ [AKBAR] CURRENTLY IN COAP THE ONLY SECURITY IS ONE TO ONE (I.E. UNICAST DTLS). THERE IS NO MULTICAST SECURITY. SO I DON'T UNDERSTAND YOUR LAST SENTENCE? ------------------------ >3. group resource manipulation > in "2.9. Congestion Control", > > The draft gives decriptions on " CoAP [I-D.ietf-core-coap] reduces > multicast-specific congestion risks through the following measures: > ......" > But there are no words about how a node should do when there is > congestion. > Maybe this is the critical issue of congestion control and this is out > of the scope. ------------------------ [AKBAR] YOU ARE CORRECT. WE ONLY GIVE RULES TO AVOID CONGESTION. ANYTHING ELSE IS OUT OF SCOPE. ------------------------ >I am appreciate your works on section 3 and 4. And no commets on others >currently. > >Just read Thomas email > "- httpbis has been sent to IESG for publication, I guess it's ok to > reference it instead of 2616;" > > If it referes to http2.0, I prefer rfc2616. I am not sure whether >http2.0 is so-called RESTful. ------------------------ [AKBAR] YES. PLEASE SEE MY RESPONSE TO THOMAS. ------------------------ Regards, Gengyu Network Techonology Center School of Computer Beijing University of Posts & Telecommunications -----原始邮件----- From: Rahman, Akbar Sent: Monday, December 16, 2013 10:23 AM To: FOSSATI, Thomas (Thomas) Cc: core@ietf.org Subject: Re: [core] WGLC comments for draft-ietf-core-groupcomm-17 Hi Thomas, Thanks for your detailed review. Esko and I will review your comments in the next few days and get back to you with a consolidated response. Akbar -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of FOSSATI, Thomas (Thomas) Sent: Saturday, December 14, 2013 4:28 PM To: core (core@ietf.org) Subject: [core] WGLC comments for draft-ietf-core-groupcomm-17 Hi Akbar, Esko. Good job with the document. The “Use Cases” section is especially enjoyable. There are no major issues on my side; the following comments are mostly editorial. Cheers, Thomas. Section 1.1 - httpbis has been sent to IESG for publication, I guess it's ok to reference it instead of 2616; - last para: it'd be super nice to have pointers to sections while topics are enumerated; Section 1.3 - "IP multicast" definition could be made a bit richer? To me IP multicast is not just a matter of addressing, is also the membership management, the routing and forwarding, the abstraction built on top of different L2 protocols. Section 2.2 - first para: is it necessary for the two MAY's to be RFC2119? - second para, last sentence: is there any reason why the "may also be enabled" is not RFC2119? - fourth para: it's not clear to me what the "group communication request API" is - fifth para: is the "It is recommended" meant to be RFC2119? - last para: not clear what the use case for the reverse DNS mapping would be. Section 2.3 - isn't bullet 3. (i.e. use the default CoAP port) just a special case of 1. (i.e. pre-configured port number)? Section 2.4 - I guess it's the unreliable (more then the lossy) nature of IP multicast that makes POST unusable? Section 2.5 - second para: it looks like the server can unilaterally decide to suppress a response to a multicast request. But there is no mention about which conditions could trigger the actual response suppression. A pointer to Section 2.8 perhaps? Section 2.7 - The title/name is very generic. "Group Membership RESTful Interface" (or similar) would be more easily and consistently referenced in subsequent text (where it appears as "RESTful CoAP interface", and then as "RESTful interface"). - first para: missing comma "[...] only as [...]" -> "[...] only, as [...]" - second para: the "Thus only authorized controllers [...]" is not clear to me: it seems to imply that DTLS provides authorisation, which it doesn't. Section 2.7.2.1 - the beginning of this section could have a small description of the semantics, before going deep into syntactic details? - second para: "A resource offering this representation": it's not clear to me what "this representation" refers to; - third para: "[...] in a format as defined [...]" -> "[...] in the format defined [...]"; - problem with the defined syntax: it's impossible to specify a non-literal group with a non-default port. I'd suggest adding the optional port to the non-literal format as well; - fifth para: "SHOULD NOT be included if unknown" isn't this more a MUST NOT? What should I put into it if I don't know what to put into it? Also, the preceding MUST sounds more like a SHOULD? Section 2.7.2.2 - I'd add a note about the need for the Group index to be unique - what happens when a client tries to register a duplicate "a"? - last para: add context/rationale for the re-join requirement on POST of an already registered Section 2.7.2.3 - the "/" in "/{+location}" looks redundant - would be nice to have text that describes the actions that are to be done by the server on successful deletion Section 2.7.2.4 - the "/" in "/{+location}" looks redundant Section 2.7.2.5 - last para: add reference to RFC5952? Section 2.7.2.6 - would be nice to have text that describes the actions that are to be done by the server on successful update Section 2.7.2.7 - first para: it's not clear what makes a CoAP client responsibile for the group membership objects - would be nice to have text that describes the actions that are to be done by the server on successful update Section 2.8 - It is said that the response suppression should be configurabile, which is great. But then why not allowing this via the "Group Membership RESTful Interface"? Section 2.10 - shameless plug: the "Multipart Content-Format Encoding for CoAP" I-D could provide the aggregation format needed ;-) _______________________________________________ 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 weigengyu@bupt.edu.cn Tue Dec 17 22:11:41 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4F01ADFA7 for ; Tue, 17 Dec 2013 22:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhfQ0zO7s-k8 for ; Tue, 17 Dec 2013 22:11:35 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 817251AE01B for ; Tue, 17 Dec 2013 22:11:32 -0800 (PST) Received: from WeiGengyuPC (unknown [10.103.241.46]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 0EE2019F39C for ; Wed, 18 Dec 2013 14:11:23 +0800 (HKT) Message-ID: From: "weigengyu" To: Date: Wed, 18 Dec 2013 14:11:21 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3505.912 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912 Subject: Re: [core] WGLC comments for draft-ietf-core-groupcomm-17 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 06:11:41 -0000 -----原始邮件----- From: weigengyu Sent: Wednesday, December 18, 2013 12:38 PM To: Rahman, Akbar Subject: Re: [core] WGLC comments for draft-ietf-core-groupcomm-17 Hi Akbar, This email is "about group configuration" In the draft, you gave >2.1 in "2.3. Port and URI Configuration" "All CoAP multicast requests MUST be sent using a port number according to one of below options: 1. A pre-configured port number. 2. If the client is configured to use service discovery ...... 3. Use the default CoAP UDP port (5683). My comment is that three options are not better than on dedicated one. It possible and necessary to define a dedicated port number for CoAP Group Comm ? If you think not, just ignor this problem. >>1.3 "Note: A Group URI is needed to initiate CoAP group communications." >> Is it possible to give Group URI an explicity Symble that is >> different from Host URI, just as specified in the resource type. >> The difference is not only in the meaning of words, but also by >> the symbole definition. ------------------------ > [AKBAR] WE STATED IN SECTION 2.2 ("Group URIs follow the CoAP URI syntax") > SO I AM NOT SURE WHAT YOU MEAN BY DIFFERENT SYMBOL? > WE WILL HOWEVER CLARIFY WHAT "group communications request API" MEANS FROM > THE SAME SECTION 2.2 AS THOMAS SUGGESTED. WILL THAT ANSWER YOUR > QUESTION? Yes. > [AKBAR] THE STANDARD WAY FOR A SERVER TO KNOW THAT IT RECEIVED A MULTICAST > MESSAGE IS IDENTIFIED IN SECTION 2.8 > "To apply any rules for request and/or response suppression, a CoAP > server must be aware that an incoming request arrived via multicast > by making use of APIs such as IPV6_RECVPKTINFO [RFC3542]." > DOES THAT ANSWER YOUR QUESTION? > ------------------------ [RFC3542] is possile to use. But RFC3542 is defined for using raw IPv6 sockets. CoAP protocol stack has UDP over IPv6. So, I do not prefer this cross layer mechanism. So, I think that it is better for the UDP and CoAP to have an explicit identifier of multicast or group communications. >>2.2 in "2.5. Messaging and Responses" >> "The CoAP client can distinguish the origin of multiple server >> responses by source IP address of the UDP message containing the CoAP >> response. In case a CoAP client sent multiple group requests, >the >> responses are as usual matched to a request using the CoAP Token." >> Suggest to "The CoAP client can distinguish the origin of multiple >> server responses by source IP address of the UDP message, CoAP URI, or >> other unique identity. " ------------------------ > [AKBAR] BUT THERE IS NO "CoAP URI" IN A RESPONSE? Current draft is that "THERE IS NO "CoAP URI" IN A RESPONSE?", and the related problem are aready understood. Maybe, Change to: "The CoAP client can distinguish the origin of multiple server responses by source IP address of the UDP message or other unique identity. " Otherwise, leave the problem left. >>2.3 in "2.7.2. RESTful Interface" >> "To access this interface a client MUST use unicast CoAP methods >> (GET/PUT/POST/DELETE) only as it is a method of configuring group >> information in individual endpoints." > I do suggest to add a client to use multicast CoAP methods as option. > Configure the endpoints one by one may has considerations of security > issues, but should reserve one to many configuration operations. > [AKBAR] CURRENTLY IN COAP THE ONLY SECURITY IS ONE TO ONE (I.E. UNICAST > DTLS). THERE IS NO MULTICAST SECURITY. SO I DON'T UNDERSTAND YOUR LAST > SENTENCE? Yes. current DTLS supports unicast. And I am sure that you might know more than I do about DTLS supporting multicast, i.e. "DTLS-based Multicast Security for Low-Power and Lossy Networks (LLNs)" . I suggest that for configuration operations a client is permitted to use mulitcast CoAP methods as option. >>3. group resource manipulation >> in "2.9. Congestion Control", >> The draft gives decriptions on " CoAP [I-D.ietf-core-coap] reduces >> multicast-specific congestion risks through the following measures: >> ......" >> But there are no words about how a node should do when there is >> congestion. >> Maybe this is the critical issue of congestion control and this is >> out of the scope. >------------------------ >[AKBAR] YOU ARE CORRECT. WE ONLY GIVE RULES TO AVOID CONGESTION. ANYTHING >ELSE IS OUT OF SCOPE. ------------------------ Why not to use congestion avoidance. There are common senses about congestion avoidance and control after the famous paper "Congestion Avoidance and Control V. Jacobson (Originally Published in: Proc. SIGCOMM '88" even that is about TCP. comments are above. Regards, Network Techonology Center School of Computer Beijing University of Posts & Telecommunications -----原始邮件----- From: Rahman, Akbar Sent: Wednesday, December 18, 2013 5:44 AM To: weigengyu Cc: core@ietf.org ; Dijk, Esko Subject: RE: [core] WGLC comments for draft-ietf-core-groupcomm-17 Hi Gengyu, Thank you very much for the good comments. Below are our embedded RESPONSES. Please review and write back with your thoughts. Best Regards, Akbar & Esko -----Original Message----- From: weigengyu [mailto:weigengyu@bupt.edu.cn] Sent: Monday, December 16, 2013 12:26 AM To: Rahman, Akbar; FOSSATI, Thomas (Thomas) Cc: core@ietf.org Subject: Re: [core] WGLC comments for draft-ietf-core-groupcomm-17 >Hi Akbar, > >I also think you did a good job. >And I would like to give some comments after reading your draft. > >From the scope (1.2 scope ) the draft describes "group definition, group >resource manipulation, and group configuration. Also, proxy operation and >minimizing network congestion for group >communication" > >1. about group definition >1.1 You use terminalogyies group communication for CoAP, CoAP >multicast, >what the difference is? ------------------------ [AKBAR] AS DEFINED IN SECTION 1.3, THE MAIN DIFFERENCE IS THAT "MULTICAST" IN OUR DRAFT REFERS TO "IP MULTICAST". WHILE "GROUP COMMUNICATION" REFERS TO SENDING OF APPLICATION COAP MESSAGES OVER IP MULTICAST. PERHAPS ONE CLARIFICATION WE CAN MAKE IS AS FOLLOWS TO THE "GROUP COMMUNICATION" DEFINITION IN SECTION 1.3: FROM: "Group Communication A source node sends a single message which is delivered to multiple destination nodes ..." TO: "Group Communication A source node sends a single application layer (e.g. CoAP) message which is delivered to multiple destination nodes ..." DO YOU AGREE? ------------------------- >1.2 in "2.2 Group Definition and Naming" > "A group is defined as a set of CoAP endpoints, where each endpoint > is configured to receive multicast CoAP requests that are sent to the > group’s associated IP multicast address. >An endpoint MAY be a member of multiple groups. Group membership of an >endpoint MAY dynamically change over time." > As CoAP endpoints include client and servers, A CoAP Group should > include a sender (at least) and multiple recievers. > or you can called the servers related to the specific IP multicast > address as a receive-only group. ------------------------ [AKBAR] IT IS OPTIONAL FOR THE SENDER TO BE PART OF THE COAP GROUP AS WE HAVE STATED IN THE DEFINITION OF GROUP COMMUNCATION IN SECTION 1.3. (I.E. "The source node itself may be part of the group"). THIS IS HOW ALL UNDERLYING IP MULTICAST GROUPS WORK. ------------------------ >1.3 "Note: A Group URI is needed to initiate CoAP group communications." > Is it possible to give Group URI an explicity Symble that is > different from Host URI, just as specified in the resource type. > The difference is not only in the meaning of words, but also by the > symbole definition. ------------------------ [AKBAR] WE STATED IN SECTION 2.2 ("Group URIs follow the CoAP URI syntax") SO I AM NOT SURE WHAT YOU MEAN BY DIFFERENT SYMBOL? WE WILL HOWEVER CLARIFY WHAT "group communications request API" MEANS FROM THE SAME SECTION 2.2 AS THOMAS SUGGESTED. WILL THAT ANSWER YOUR QUESTION? ------------------------ >2. about group configuration > >2.1 in "2.3. Port and URI Configuration" > Is it possible and necessary to define a CoAP Group Comm port number? > Even thoufh CoAP Supports multicast, it has no explicity flag in > message when doing multicast. > If there is a dedicated CoAP Group Comm port number, the differece > for unicast and multicast are clear; all CoAP group comm can use that UDP > port number and different groups are identified by >Group URI. ------------------------ [AKBAR] THE STANDARD WAY FOR A SERVER TO KNOW THAT IT RECEIVED A MULTICAST MESSAGE IS IDENTIFIED IN SECTION 2.8 "To apply any rules for request and/or response suppression, a CoAP server must be aware that an incoming request arrived via multicast by making use of APIs such as IPV6_RECVPKTINFO [RFC3542]." DOES THAT ANSWER YOUR QUESTION? ------------------------ >2.2 in "2.5. Messaging and Responses" > "The CoAP client can distinguish the origin of multiple server > responses by source IP address of the UDP message containing the CoAP > response. In case a CoAP client sent multiple group requests, >the > responses are as usual matched to a request using the CoAP Token." > Suggest to "The CoAP client can distinguish the origin of multiple > server responses by source IP address of the UDP message, CoAP URI, or > other unique identity. " ------------------------ [AKBAR] BUT THERE IS NO "CoAP URI" IN A RESPONSE? ------------------------ >2.3 in "2.7.2. RESTful Interface" > "To access this interface a client MUST use unicast CoAP methods >(GET/PUT/POST/DELETE) only as it is a method of configuring group >information in individual endpoints." > I do suggest to add a client to use multicast CoAP methods as option. > Configure the endpoints one by one may has considerations of security > issues, but should reserve one to many configuration operations. ------------------------ [AKBAR] CURRENTLY IN COAP THE ONLY SECURITY IS ONE TO ONE (I.E. UNICAST DTLS). THERE IS NO MULTICAST SECURITY. SO I DON'T UNDERSTAND YOUR LAST SENTENCE? ------------------------ >3. group resource manipulation > in "2.9. Congestion Control", > > The draft gives decriptions on " CoAP [I-D.ietf-core-coap] reduces > multicast-specific congestion risks through the following measures: > ......" > But there are no words about how a node should do when there is > congestion. > Maybe this is the critical issue of congestion control and this is out > of the scope. ------------------------ [AKBAR] YOU ARE CORRECT. WE ONLY GIVE RULES TO AVOID CONGESTION. ANYTHING ELSE IS OUT OF SCOPE. ------------------------ >I am appreciate your works on section 3 and 4. And no commets on others >currently. > >Just read Thomas email > "- httpbis has been sent to IESG for publication, I guess it's ok to > reference it instead of 2616;" > > If it referes to http2.0, I prefer rfc2616. I am not sure whether >http2.0 is so-called RESTful. ------------------------ [AKBAR] YES. PLEASE SEE MY RESPONSE TO THOMAS. ------------------------ Regards, Gengyu Network Techonology Center School of Computer Beijing University of Posts & Telecommunications -----原始邮件----- From: Rahman, Akbar Sent: Monday, December 16, 2013 10:23 AM To: FOSSATI, Thomas (Thomas) Cc: core@ietf.org Subject: Re: [core] WGLC comments for draft-ietf-core-groupcomm-17 Hi Thomas, Thanks for your detailed review. Esko and I will review your comments in the next few days and get back to you with a consolidated response. Akbar -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of FOSSATI, Thomas (Thomas) Sent: Saturday, December 14, 2013 4:28 PM To: core (core@ietf.org) Subject: [core] WGLC comments for draft-ietf-core-groupcomm-17 Hi Akbar, Esko. Good job with the document. The “Use Cases” section is especially enjoyable. There are no major issues on my side; the following comments are mostly editorial. Cheers, Thomas. Section 1.1 - httpbis has been sent to IESG for publication, I guess it's ok to reference it instead of 2616; - last para: it'd be super nice to have pointers to sections while topics are enumerated; Section 1.3 - "IP multicast" definition could be made a bit richer? To me IP multicast is not just a matter of addressing, is also the membership management, the routing and forwarding, the abstraction built on top of different L2 protocols. Section 2.2 - first para: is it necessary for the two MAY's to be RFC2119? - second para, last sentence: is there any reason why the "may also be enabled" is not RFC2119? - fourth para: it's not clear to me what the "group communication request API" is - fifth para: is the "It is recommended" meant to be RFC2119? - last para: not clear what the use case for the reverse DNS mapping would be. Section 2.3 - isn't bullet 3. (i.e. use the default CoAP port) just a special case of 1. (i.e. pre-configured port number)? Section 2.4 - I guess it's the unreliable (more then the lossy) nature of IP multicast that makes POST unusable? Section 2.5 - second para: it looks like the server can unilaterally decide to suppress a response to a multicast request. But there is no mention about which conditions could trigger the actual response suppression. A pointer to Section 2.8 perhaps? Section 2.7 - The title/name is very generic. "Group Membership RESTful Interface" (or similar) would be more easily and consistently referenced in subsequent text (where it appears as "RESTful CoAP interface", and then as "RESTful interface"). - first para: missing comma "[...] only as [...]" -> "[...] only, as [...]" - second para: the "Thus only authorized controllers [...]" is not clear to me: it seems to imply that DTLS provides authorisation, which it doesn't. Section 2.7.2.1 - the beginning of this section could have a small description of the semantics, before going deep into syntactic details? - second para: "A resource offering this representation": it's not clear to me what "this representation" refers to; - third para: "[...] in a format as defined [...]" -> "[...] in the format defined [...]"; - problem with the defined syntax: it's impossible to specify a non-literal group with a non-default port. I'd suggest adding the optional port to the non-literal format as well; - fifth para: "SHOULD NOT be included if unknown" isn't this more a MUST NOT? What should I put into it if I don't know what to put into it? Also, the preceding MUST sounds more like a SHOULD? Section 2.7.2.2 - I'd add a note about the need for the Group index to be unique - what happens when a client tries to register a duplicate "a"? - last para: add context/rationale for the re-join requirement on POST of an already registered Section 2.7.2.3 - the "/" in "/{+location}" looks redundant - would be nice to have text that describes the actions that are to be done by the server on successful deletion Section 2.7.2.4 - the "/" in "/{+location}" looks redundant Section 2.7.2.5 - last para: add reference to RFC5952? Section 2.7.2.6 - would be nice to have text that describes the actions that are to be done by the server on successful update Section 2.7.2.7 - first para: it's not clear what makes a CoAP client responsibile for the group membership objects - would be nice to have text that describes the actions that are to be done by the server on successful update Section 2.8 - It is said that the response suppression should be configurabile, which is great. But then why not allowing this via the "Group Membership RESTful Interface"? Section 2.10 - shameless plug: the "Multipart Content-Format Encoding for CoAP" I-D could provide the aggregation format needed ;-) _______________________________________________ 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 esko.dijk@philips.com Wed Dec 18 00:26:09 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F012F1ADFE3 for ; Wed, 18 Dec 2013 00:26:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.948 X-Spam-Level: X-Spam-Status: No, score=-2.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, UNRESOLVED_TEMPLATE=1.252] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYSpMT5XYOTL for ; Wed, 18 Dec 2013 00:26:06 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id 99B8D1ADFA0 for ; Wed, 18 Dec 2013 00:26:06 -0800 (PST) Received: from mail56-tx2-R.bigfish.com (10.9.14.251) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.22; Wed, 18 Dec 2013 08:26:05 +0000 Received: from mail56-tx2 (localhost [127.0.0.1]) by mail56-tx2-R.bigfish.com (Postfix) with ESMTP id 0459D1200D4; Wed, 18 Dec 2013 08:26:05 +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: -8 X-BigFish: VPS-8(zzdb82h217bI15d6O1418I9251Idf9Idd85kzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzd9hzz2dh109h2a8h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh2222h224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2184h2216h22d0h2336h1155h) Received: from mail56-tx2 (localhost.localdomain [127.0.0.1]) by mail56-tx2 (MessageSwitch) id 1387355163270321_7179; Wed, 18 Dec 2013 08:26:03 +0000 (UTC) Received: from TX2EHSMHS026.bigfish.com (unknown [10.9.14.240]) by mail56-tx2.bigfish.com (Postfix) with ESMTP id 3C873200054; Wed, 18 Dec 2013 08:26:03 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by TX2EHSMHS026.bigfish.com (10.9.99.126) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 18 Dec 2013 08:26:02 +0000 Received: from 011-DB3MMR1-020.MGDPHG.emi.philips.com (10.128.28.101) by 011-DB3MMR1-004.MGDPHG.emi.philips.com (10.128.28.54) with Microsoft SMTP Server (TLS) id 14.3.158.2; Wed, 18 Dec 2013 08:25:29 +0000 Received: from 011-DB3MPN2-081.MGDPHG.emi.philips.com ([169.254.1.51]) by 011-DB3MMR1-020.MGDPHG.emi.philips.com ([fe80::65e7:4d4c:4c67:daa9%11]) with mapi id 14.03.0158.002; Wed, 18 Dec 2013 08:25:29 +0000 From: "Dijk, Esko" To: weigengyu , "core@ietf.org" Thread-Topic: [core] WGLC comments for draft-ietf-core-groupcomm-17 Thread-Index: AQHO+7f4aMhII7lMuEy2T0VkoimTy5pZk7ew Date: Wed, 18 Dec 2013 08:25:28 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED6180CC5868B@011-DB3MPN2-081.MGDPHG.emi.philips.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.106] 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% Subject: Re: [core] WGLC comments for draft-ietf-core-groupcomm-17 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 08:26:09 -0000 SGVsbG8sDQoNCj4gTXkgY29tbWVudCBpcyB0aGF0IHRocmVlIG9wdGlvbnMgYXJlIG5vdCBiZXR0 ZXIgdGhhbiBvbiBkZWRpY2F0ZWQgb25lLg0KPiBJdCBwb3NzaWJsZSBhbmQgbmVjZXNzYXJ5IHRv IGRlZmluZSBhIGRlZGljYXRlZCBwb3J0IG51bWJlciBmb3IgQ29BUCBHcm91cCBDb21tID8NCj4g SWYgeW91IHRoaW5rIG5vdCwganVzdCBpZ25vciB0aGlzIHByb2JsZW0uDQpUaGUgY3VycmVudCBD b0FQIG1vZGVsIGlzIHRoYXQgaXQgYWxsb3dzIHRvIHVzZSBhbnkgYXZhaWxhYmxlIFVEUCBwb3J0 OyBhbmQgaW4gR3JvdXBDb21tIHdlIHNpbXBseSBmb2xsb3cgdGhhdCBtb2RlbC4NCg0KPiBbUkZD MzU0Ml0gaXMgcG9zc2lsZSB0byB1c2UuIEJ1dCBSRkMzNTQyIGlzIGRlZmluZWQgZm9yIHVzaW5n IHJhdyBJUHY2IHNvY2tldHMuDQo+IENvQVAgcHJvdG9jb2wgc3RhY2sgaGFzIFVEUCBvdmVyIElQ djYuICBTbywgSSBkbyBub3QgcHJlZmVyIHRoaXMgY3Jvc3MgbGF5ZXIgbWVjaGFuaXNtLg0KPiBT bywgSSB0aGluayB0aGF0IGl0IGlzIGJldHRlciBmb3IgdGhlIFVEUCBhbmQgQ29BUCB0byBoYXZl IGFuIGV4cGxpY2l0IGlkZW50aWZpZXIgb2YgbXVsdGljYXN0IG9yIGdyb3VwIGNvbW11bmljYXRp b25zLg0KSSBhZ3JlZSB0aGlzIG1pZ2h0IGJlIGVhc2llciBmb3IgZGV0ZWN0aW9uIGF0IHRoZSBD b0FQIGxldmVsLiBIb3dldmVyLCBpdCBkb2VzIG1lYW4gYSAobWFsaWNpb3VzLCBvciBzbG9wcHkp IGNsaWVudCBjb3VsZCBzZW5kIGEgdW5pY2FzdC1mb3JtYXR0ZWQgQ29BUCByZXF1ZXN0IGluc2lk ZSBhbiBJUCBtdWx0aWNhc3QgcGFja2V0LiBUaGF0IGFnYWluIHBvc2VzIHNlY3VyaXR5L2Nvbmdl c3Rpb24gcmlza3MgaWYgdGhlIHNlcnZlcnMgYXJlIHVuYXdhcmUgb2YgdGhpcyBmYWN0LiBBbmQg YmVzaWRlcyBjdXJyZW50IGNvcmUtY29hcCB3aGljaCBpcyBuZWFybHkgZG9uZSwgZG9lcyBub3Qg aGF2ZSBhIGZsYWcgdG8gaW5kaWNhdGUgJ211bHRpY2FzdCcuDQoNCj4gTWF5YmUsIENoYW5nZSB0 bzogIlRoZSBDb0FQIGNsaWVudCBjYW4gZGlzdGluZ3Vpc2ggdGhlIG9yaWdpbiBvZiBtdWx0aXBs ZSBzZXJ2ZXIgcmVzcG9uc2VzIGJ5IHNvdXJjZSBJUCBhZGRyZXNzIG9mIHRoZSBVRFAgbWVzc2Fn ZSBvciBvdGhlciB1bmlxdWUgaWRlbnRpdHkuICAiDQpJIGFncmVlIHdpdGggdGhpcyBwcm9wb3Nh bC4gSXQgaXMgbm90IG1hbmRhdG9yeSB0byB1c2UgdGhlIHNvdXJjZSBJUCBhZGRyZXNzIG9mIHRo ZSBVRFAgbWVzc2FnZSBpZiBhbm90aGVyIG1lYW5zIG9mIGlkZW50aWZpY2F0aW9uIGlzIHByZXNl bnQgaW4gdGhlIHJlc3BvbnNlLiBFLmcuLCBzb21lIElEIGluIHRoZSBwYXlsb2FkIG9yIHRoZSBy ZWNlbnRseSBwcm9wb3NlZCAiTm9kZUlEIiBvcHRpb24gb3Igc2ltaWxhciwgaW4gdGhlIGZ1dHVy ZS4NCg0KPiBJIHN1Z2dlc3QgdGhhdCBmb3IgY29uZmlndXJhdGlvbiBvcGVyYXRpb25zIGEgY2xp ZW50IGlzIHBlcm1pdHRlZCB0byB1c2UgbXVsaXRjYXN0IENvQVAgbWV0aG9kcyBhcyBvcHRpb24u DQpJIGRvbid0IHNlZSBhIHVzZSBjYXNlIHlldCBmb3IgbXVsdGljYXN0IGNvbmZpZ3VyYXRpb24g KFBVVC9QT1NUKS4gTWF5YmUgYSBtdWx0aWNhc3QgR0VUIG9uICJBbGwgQ29BUCBub2RlcyIgdG8g cXVpY2tseSBnYXRoZXIgZ3JvdXAgbWVtYmVyc2hpcCBpbmZvIGlzIHVzZWZ1bCBmb3Igc29tZT8N ClRoZSBNVVNUIHdlIGhhdmUgdGhlcmUgcHJvdmlkZXMgdGhlIGJlc3QgaW50ZXJvcGVyYWJpbGl0 eSBmb3IgdGhvc2Ugd2hvIGltcGxlbWVudCB0aGUgaW50ZXJmYWNlLiAgQnV0IHdlIGNvdWxkIGNv bnNpZGVyIHRoYXQgbXVsdGljYXN0IE1BWSBiZSB1c2VkIGZvciBHRVQgcmVxdWVzdHMgb24gdGhp cyBpbnRlcmZhY2UuIChUaGF0IHdvdWxkIGJlIGFsbG93ZWQgdGhlbiB3aXRob3V0IERUTFMsIHNp bmNlIHRoZXNlIEdFVCByZXF1ZXN0cyBkbyBub3QgYWN0dWFsbHkgY2hhbmdlIHRoZSBjb25maWd1 cmF0aW9uIG9uIG5vZGVzKQ0KQWtiYXIvYWxsLCBhbnkgY29tbWVudHM/DQoNCj4gV2h5IG5vdCB0 byB1c2UgY29uZ2VzdGlvbiBhdm9pZGFuY2UuDQpUaGUgdGVybSAiQ29uZ2VzdGlvbiBjb250cm9s IiBpcyB0YWtlbiBvdmVyIGZyb20gY29yZS1jb2FwLiBJJ20gbm90IHN1cmUgd2hldGhlciB0aGVy ZSBhcmUgZ2VuZXJhbCBkZWZpbml0aW9ucyBvZiBib3RoPyBUaGUgSmFjb2Jzb24gcGFwZXIgc2Vl bXMgdG8gc3VnZ2VzdCB0aGF0ICJjb250cm9sIiBpcyB0aGUgYWN0aXZlIGlkZW50aWZpY2F0aW9u IG9mIGNvbmdlc3Rpb24gcHJvYmxlbXMgaW4gdGhlIG5ldHdvcmsgYW5kIGZpeGluZyB0aGVtLg0K V2UgcmF0aGVyIHVzZSB0aGUgdGVybSBhcyB0aGUgc3BlY2lmaWMgcG9saWNpZXMvbWVjaGFuaXNt cyB0aGF0IGJvdGggY2xpZW50cyBhbmQgc2VydmVycyBoYXZlIHRvIGFwcGx5LCBvciBtYXkgYXBw bHksIHRvIHJlZHVjZSB0aGUgcmlzayBvZiBuZXR3b3JrIGNvbmdlc3Rpb24uDQoNCkVza28NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRoZSBpbmZvcm1hdGlvbiBjb250YWlu ZWQgaW4gdGhpcyBtZXNzYWdlIG1heSBiZSBjb25maWRlbnRpYWwgYW5kIGxlZ2FsbHkgcHJvdGVj dGVkIHVuZGVyIGFwcGxpY2FibGUgbGF3LiBUaGUgbWVzc2FnZSBpcyBpbnRlbmRlZCBzb2xlbHkg Zm9yIHRoZSBhZGRyZXNzZWUocykuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGll bnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHVzZSwgZm9yd2FyZGluZywgZGlz c2VtaW5hdGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMgbWVzc2FnZSBpcyBzdHJpY3RseSBw cm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl ZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCBh bmQgZGVzdHJveSBhbGwgY29waWVzIG9mIHRoZSBvcmlnaW5hbCBtZXNzYWdlLg0K From Akbar.Rahman@interdigital.com Wed Dec 18 09:24:11 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 650E01AE0CC for ; Wed, 18 Dec 2013 09:24:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXf1jRZUl6TL for ; Wed, 18 Dec 2013 09:24:09 -0800 (PST) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) by ietfa.amsl.com (Postfix) with ESMTP id 756B31AE0C2 for ; Wed, 18 Dec 2013 09:24:09 -0800 (PST) X-ASG-Debug-ID: 1387387446-06daaa105f6f4a0001-aa7cYp Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id o5IKq8OkYuqAIVqD for ; Wed, 18 Dec 2013 12:24:06 -0500 (EST) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Dec 2013 12:24:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Wed, 18 Dec 2013 12:24:31 -0500 X-ASG-Orig-Subj: RE: [core] WGLC comments for draft-ietf-core-groupcomm-17 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] WGLC comments for draft-ietf-core-groupcomm-17 Thread-Index: AQHO+RNnaMhII7lMuEy2T0VkoimTy5pYtZZAgABJdwCAATleMA== References: From: "Rahman, Akbar" To: "FOSSATI, Thomas (Thomas)" X-OriginalArrivalTime: 18 Dec 2013 17:24:32.0623 (UTC) FILETIME=[03F597F0:01CEFC16] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1387387446 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.143200 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Cc: core@ietf.org Subject: Re: [core] WGLC comments for draft-ietf-core-groupcomm-17 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 17:24:11 -0000 SGkgVGhvbWFzLA0KDQoNClRoYW5rcyBmb3IgdGhlIGZlZWRiYWNrLiAgU28gSSB0aGluayB3ZSBo YXZlIGNvbWUgdG8gYW4gYWdyZWVtZW50IG9uIGFsbCB5b3VyIGl0ZW1zIGV4Y2VwdCBmb3I6DQoN Cg0KPj5TZWN0aW9uIDIuMTANCj4+DQo+Pi0gc2hhbWVsZXNzIHBsdWc6IHRoZSAiTXVsdGlwYXJ0 IENvbnRlbnQtRm9ybWF0IEVuY29kaW5nIGZvciBDb0FQIiBJLUQgDQo+PmNvdWxkIHByb3ZpZGUg dGhlIGFnZ3JlZ2F0aW9uIGZvcm1hdCBuZWVkZWQgOy0pDQoNCj5NdWx0aXBhcnQgaXMgcmVjdXJz aXZlLCBzbyB5b3UgY291bGQgaGF2ZSBhbiBpbm5lciBtdWx0aXBhcnQgd2hpY2ggYWdncmVnYXRl cyB0aGUgcGVyLXJlc3BvbnNlIGF0dHJpYnV0ZXMgKGkuZS4gaWRlbnRpZmllci9sb2NhdG9yIG9m IHRoZSBzZW5kZXIsIENvQVAgcGF5bG9hZCksIGFuZCBhbiBvdXRlciBtdWx0aXBhcnQgcHJvdmlk aW5nIHRoZSA+bGlzdC9zZXQgdGhhdCBnYXRoZXJzIGFsbCB0aGUgcmVzcG9uc2VzIHRvZ2V0aGVy Lg0KDQoNCk91ciBwcm9wb3NhbCBpcyB0aGF0IHdlIGNhbiBjaGFuZ2UgdGhlIGZvbGxvd2luZyBp biBvdXIgU2VjdGlvbiAyLjEwIChQcm94eSBPcGVyYXRpb24pLiAgVGhpcyB3b3VsZCBiZSBzaW1p bGFyIHRvIG91ciBTZWN0aW9uIDUuMy4zIChTZWN1cml0eSBGdXR1cmUgRXZvbHV0aW9uKS4NCg0K DQpGUk9NOg0KICAgICAiVGhlcmUgaXMgbm8gZGVmYXVsdCBmb3JtYXQgZGVmaW5lZCBpbiBDb0FQ IGZvciBhZ2dyZWdhdGlvbiBvZg0KICAgICAgbXVsdGlwbGUgcmVzcG9uc2VzIGludG8gYSBzaW5n bGUgcmVzcG9uc2UuIg0KDQoNClRPOg0KDQogICAgICJUaGVyZSBpcyBubyBkZWZhdWx0IGZvcm1h dCB5ZXQgYWRvcHRlZCBpbiBDb0FQIGZvciBhZ2dyZWdhdGlvbiBvZg0KICAgICAgbXVsdGlwbGUg cmVzcG9uc2VzIGludG8gYSBzaW5nbGUgcmVzcG9uc2UuICBIb3dldmVyLCBzb21lIHByb3Bvc2Fs cyBhcmUgYmVpbmcgY29uc2lkZXJlZCBzdWNoIGFzIGZvc3NhdGktY29yZS1tdWx0aXBhci1jdC4i DQoNCg0KDQpQbGVhc2UgdGVsbCB1cyBpZiB5b3UgaGF2ZSBhbnkgZnVydGhlciBjb21tZW50cy4N Cg0KDQoNCi9Ba2JhciAmIEVza28NCg0KDQoNCg== From Akbar.Rahman@interdigital.com Wed Dec 18 09:32:18 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4921ADFAB for ; Wed, 18 Dec 2013 09:32:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvODa_0plgvt for ; Wed, 18 Dec 2013 09:32:17 -0800 (PST) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) by ietfa.amsl.com (Postfix) with ESMTP id 0FAA11ADF63 for ; Wed, 18 Dec 2013 09:32:17 -0800 (PST) X-ASG-Debug-ID: 1387387935-06daaa105f6f630001-aa7cYp Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id CCK8FZF6GTRrwHaT for ; Wed, 18 Dec 2013 12:32:15 -0500 (EST) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Dec 2013 12:32:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Wed, 18 Dec 2013 12:32:39 -0500 X-ASG-Orig-Subj: Final comment from Thomas on groupcomm-17 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Final comment from Thomas on groupcomm-17 Thread-Index: Ac78FvLRP4bc/XMUQQ21px1AQNXmNA== From: "Rahman, Akbar" To: "FOSSATI, Thomas (Thomas)" X-OriginalArrivalTime: 18 Dec 2013 17:32:40.0879 (UTC) FILETIME=[26FB8BF0:01CEFC17] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1387387935 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.143200 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Cc: core@ietf.org Subject: [core] Final comment from Thomas on groupcomm-17 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 17:32:18 -0000 SSdtIHJlc2VuZGluZyB0aGlzIHdpdGggYSBkaWZmZXJlbnQgdGl0bGUgYXMgSSB3YXMgdG9sZCB0 aGF0IG15IGV4Y2Vzc2l2ZSBjYXBpdGFsaXphdGlvbiBpbiBteSBwcmV2aW91cyBFbWFpbHMgaGFk IGNhdXNlZCBwcm9ibGVtcyB3aXRoIHRoZSBtYWlsaW5nIGxpc3Qgc2VydmVycy4NCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJhaG1hbiwgQWtiYXIgDQpTZW50OiBXZWRuZXNk YXksIERlY2VtYmVyIDE4LCAyMDEzIDEyOjI1IFBNDQpUbzogJ0ZPU1NBVEksIFRob21hcyAoVGhv bWFzKScNCkNjOiBjb3JlQGlldGYub3JnOyBEaWprLCBFc2tvDQpTdWJqZWN0OiBSRTogW2NvcmVd IFdHTEMgY29tbWVudHMgZm9yIGRyYWZ0LWlldGYtY29yZS1ncm91cGNvbW0tMTcNCg0KSGkgVGhv bWFzLA0KDQoNClRoYW5rcyBmb3IgdGhlIGZlZWRiYWNrLiAgU28gSSB0aGluayB3ZSBoYXZlIGNv bWUgdG8gYW4gYWdyZWVtZW50IG9uIGFsbCB5b3VyIGl0ZW1zIGV4Y2VwdCBmb3I6DQoNCg0KPj5T ZWN0aW9uIDIuMTANCj4+DQo+Pi0gc2hhbWVsZXNzIHBsdWc6IHRoZSAiTXVsdGlwYXJ0IENvbnRl bnQtRm9ybWF0IEVuY29kaW5nIGZvciBDb0FQIiBJLUQgDQo+PmNvdWxkIHByb3ZpZGUgdGhlIGFn Z3JlZ2F0aW9uIGZvcm1hdCBuZWVkZWQgOy0pDQoNCj5NdWx0aXBhcnQgaXMgcmVjdXJzaXZlLCBz byB5b3UgY291bGQgaGF2ZSBhbiBpbm5lciBtdWx0aXBhcnQgd2hpY2ggYWdncmVnYXRlcyB0aGUg cGVyLXJlc3BvbnNlIGF0dHJpYnV0ZXMgKGkuZS4gaWRlbnRpZmllci9sb2NhdG9yIG9mIHRoZSBz ZW5kZXIsIENvQVAgcGF5bG9hZCksIGFuZCBhbiBvdXRlciBtdWx0aXBhcnQgcHJvdmlkaW5nIHRo ZSA+bGlzdC9zZXQgdGhhdCBnYXRoZXJzIGFsbCB0aGUgcmVzcG9uc2VzIHRvZ2V0aGVyLg0KDQoN Ck91ciBwcm9wb3NhbCBpcyB0aGF0IHdlIGNhbiBjaGFuZ2UgdGhlIGZvbGxvd2luZyBpbiBvdXIg U2VjdGlvbiAyLjEwIChQcm94eSBPcGVyYXRpb24pLiAgVGhpcyB3b3VsZCBiZSBzaW1pbGFyIHRv IG91ciBTZWN0aW9uIDUuMy4zIChTZWN1cml0eSBGdXR1cmUgRXZvbHV0aW9uKS4NCg0KDQpGUk9N Og0KICAgICAiVGhlcmUgaXMgbm8gZGVmYXVsdCBmb3JtYXQgZGVmaW5lZCBpbiBDb0FQIGZvciBh Z2dyZWdhdGlvbiBvZg0KICAgICAgbXVsdGlwbGUgcmVzcG9uc2VzIGludG8gYSBzaW5nbGUgcmVz cG9uc2UuIg0KDQoNClRPOg0KDQogICAgICJUaGVyZSBpcyBubyBkZWZhdWx0IGZvcm1hdCB5ZXQg YWRvcHRlZCBpbiBDb0FQIGZvciBhZ2dyZWdhdGlvbiBvZg0KICAgICAgbXVsdGlwbGUgcmVzcG9u c2VzIGludG8gYSBzaW5nbGUgcmVzcG9uc2UuICBIb3dldmVyLCBzb21lIHByb3Bvc2FscyBhcmUg YmVpbmcgY29uc2lkZXJlZCBzdWNoIGFzIGZvc3NhdGktY29yZS1tdWx0aXBhci1jdC4iDQoNCg0K DQpQbGVhc2UgdGVsbCB1cyBpZiB5b3UgaGF2ZSBhbnkgZnVydGhlciBjb21tZW50cy4NCg0KDQoN Ci9Ba2JhciAmIEVza28NCg0KDQoNCg== From thomas.fossati@alcatel-lucent.com Wed Dec 18 09:45:33 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE471AE026 for ; Wed, 18 Dec 2013 09:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUZ7JcA8lCQK for ; Wed, 18 Dec 2013 09:45:32 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 25DDE1AE019 for ; Wed, 18 Dec 2013 09:45:32 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id rBIHjRUs003460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 18 Dec 2013 11:45:29 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id rBIHjQMm019454 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Dec 2013 18:45:26 +0100 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.153]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Wed, 18 Dec 2013 18:45:26 +0100 From: "FOSSATI, Thomas (Thomas)" To: "Rahman, Akbar" Thread-Topic: Final comment from Thomas on groupcomm-17 Thread-Index: Ac78FvLRP4bc/XMUQQ21px1AQNXmNP//8zGA Date: Wed, 18 Dec 2013 17:45:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "core@ietf.org" Subject: Re: [core] Final comment from Thomas on groupcomm-17 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 17:45:33 -0000 SGkgQWtiYXIsDQoNCk9uIDE4LzEyLzIwMTMgMTc6MzIsICJSYWhtYW4sIEFrYmFyIiA8QWtiYXIu UmFobWFuQGludGVyZGlnaXRhbC5jb20+IHdyb3RlOg0KPlRoYW5rcyBmb3IgdGhlIGZlZWRiYWNr LiAgU28gSSB0aGluayB3ZSBoYXZlIGNvbWUgdG8gYW4gYWdyZWVtZW50IG9uIGFsbA0KPnlvdXIg aXRlbXMNCg0KWWVzLCBJIHRoaW5rIHNvLg0KSSBoYXZlIHN0ZXBwZWQgYmFjayBmcm9tIHRoZSAi cmVzcG9uc2Ugc3VwcHJlc3Npb24gaW5kaWNhdG9ycyBpbiB0aGUgQVBJ4oCdDQphcmd1bWVudCBh cyBJIHRoaW5rIGl0IGlzIHNvbWV0aGluZyB0aGF0IHdlIGRvbuKAmXQgbmVlZCB0byBoYXZlDQpp bW1lZGlhdGVseSwgYW5kIHJlcXVpcmVzIGEgYml0IG1vcmUgdGhpbmtpbmcgYW5kIHRhbGtpbmcu DQoNCj5leGNlcHQgZm9yOg0KPg0KPj4+U2VjdGlvbiAyLjEwDQo+Pj4NCj4+Pi0gc2hhbWVsZXNz IHBsdWc6IHRoZSAiTXVsdGlwYXJ0IENvbnRlbnQtRm9ybWF0IEVuY29kaW5nIGZvciBDb0FQIiBJ LUQNCj4+PmNvdWxkIHByb3ZpZGUgdGhlIGFnZ3JlZ2F0aW9uIGZvcm1hdCBuZWVkZWQgOy0pDQo+ DQo+Pk11bHRpcGFydCBpcyByZWN1cnNpdmUsIHNvIHlvdSBjb3VsZCBoYXZlIGFuIGlubmVyIG11 bHRpcGFydCB3aGljaA0KPj5hZ2dyZWdhdGVzIHRoZSBwZXItcmVzcG9uc2UgYXR0cmlidXRlcyAo aS5lLiBpZGVudGlmaWVyL2xvY2F0b3Igb2YgdGhlDQo+PnNlbmRlciwgQ29BUCBwYXlsb2FkKSwg YW5kIGFuIG91dGVyIG11bHRpcGFydCBwcm92aWRpbmcgdGhlID5saXN0L3NldA0KPj50aGF0IGdh dGhlcnMgYWxsIHRoZSByZXNwb25zZXMgdG9nZXRoZXIuDQo+DQo+DQo+T3VyIHByb3Bvc2FsIGlz IHRoYXQgd2UgY2FuIGNoYW5nZSB0aGUgZm9sbG93aW5nIGluIG91ciBTZWN0aW9uIDIuMTANCj4o UHJveHkgT3BlcmF0aW9uKS4gIFRoaXMgd291bGQgYmUgc2ltaWxhciB0byBvdXIgU2VjdGlvbiA1 LjMuMyAoU2VjdXJpdHkNCj5GdXR1cmUgRXZvbHV0aW9uKS4NCj4NCj4NCj5GUk9NOg0KPiAgICAg IlRoZXJlIGlzIG5vIGRlZmF1bHQgZm9ybWF0IGRlZmluZWQgaW4gQ29BUCBmb3IgYWdncmVnYXRp b24gb2YNCj4gICAgICBtdWx0aXBsZSByZXNwb25zZXMgaW50byBhIHNpbmdsZSByZXNwb25zZS4i DQo+DQo+DQo+VE86DQo+DQo+ICAgICAiVGhlcmUgaXMgbm8gZGVmYXVsdCBmb3JtYXQgeWV0IGFk b3B0ZWQgaW4gQ29BUCBmb3IgYWdncmVnYXRpb24gb2YNCj4gICAgICBtdWx0aXBsZSByZXNwb25z ZXMgaW50byBhIHNpbmdsZSByZXNwb25zZS4gIEhvd2V2ZXIsIHNvbWUgcHJvcG9zYWxzDQo+YXJl IGJlaW5nIGNvbnNpZGVyZWQgc3VjaCBhcyBmb3NzYXRpLWNvcmUtbXVsdGlwYXItY3QuIg0KDQpF eGNlbGxlbnQuDQoNCj5QbGVhc2UgdGVsbCB1cyBpZiB5b3UgaGF2ZSBhbnkgZnVydGhlciBjb21t ZW50cy4NCg0KVGhhbmtzIGFnYWluIHRvIHlvdSAmIEVza28gZm9yIHRoZSBuaWNlIGRvY3VtZW50 IGFuZCBwcm9tcHQgZmVlZGJhY2suDQoNCkNoZWVycywgVGhvbWFzLg0KDQo= From cabo@tzi.org Wed Dec 18 22:25:44 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3943D1ADFF4 for ; Wed, 18 Dec 2013 22:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fh9ACXWQAB3m for ; Wed, 18 Dec 2013 22:25:43 -0800 (PST) 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 89E821AE07B for ; Wed, 18 Dec 2013 22:25:28 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rBJ6PKnn008446; Thu, 19 Dec 2013 07:25:21 +0100 (CET) Received: from [192.168.217.105] (p54893954.dip0.t-ipconnect.de [84.137.57.84]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 95349463; Thu, 19 Dec 2013 07:25:18 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Thu, 19 Dec 2013 07:25:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <89B6EC6F-0E59-4995-97F0-8B1222479646@tzi.org> References: To: "Rahman, Akbar" X-Mailer: Apple Mail (2.1827) Cc: "core \(core@ietf.org\)" Subject: Re: [core] Final comment from Thomas on groupcomm-17 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 06:25:44 -0000 On 18 Dec 2013, at 18:32, Rahman, Akbar = wrote: > such as fossati-core-multipar-ct I'm not sure we are ready to propose one specific format for response sets. Just to demonstrate the potential variety, I have added another proposal for a response set format to draft-bormann-coap-misc (section = 4). Gr=FC=DFe, Carsten From Akbar.Rahman@interdigital.com Thu Dec 19 07:37:31 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6461ADFB1 for ; Thu, 19 Dec 2013 07:37:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.262 X-Spam-Level: X-Spam-Status: No, score=0.262 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vq9kFssyjxhQ for ; Thu, 19 Dec 2013 07:37:29 -0800 (PST) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8B81ADF5D for ; Thu, 19 Dec 2013 07:37:29 -0800 (PST) X-ASG-Debug-ID: 1387467446-06daaa106079f40001-aa7cYp Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id i2NcF8LFE0lRuN2C for ; Thu, 19 Dec 2013 10:37:26 -0500 (EST) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Dec 2013 10:37:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Dec 2013 10:37:52 -0500 X-ASG-Orig-Subj: RE: [core] Final comment from Thomas on groupcomm-17 Message-ID: In-Reply-To: <89B6EC6F-0E59-4995-97F0-8B1222479646@tzi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Final comment from Thomas on groupcomm-17 Thread-Index: Ac78gzuyXHBv4EwcRlCcquxw92Ls1wATL/jw References: <89B6EC6F-0E59-4995-97F0-8B1222479646@tzi.org> From: "Rahman, Akbar" To: "Carsten Bormann" X-OriginalArrivalTime: 19 Dec 2013 15:37:52.0999 (UTC) FILETIME=[47E63770:01CEFCD0] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1387467446 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.143225 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Cc: core@ietf.org Subject: Re: [core] Final comment from Thomas on groupcomm-17 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 15:37:31 -0000 Okay, I guess you are saying that we should have an adopted WG draft on = the topic of aggregation format (as we now have more than 1 proposal) = before we reference it. That makes sense to me. Best Regards, Akbar -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org]=20 Sent: Thursday, December 19, 2013 1:25 AM To: Rahman, Akbar Cc: FOSSATI, Thomas (Thomas); core (core@ietf.org) Subject: Re: [core] Final comment from Thomas on groupcomm-17 On 18 Dec 2013, at 18:32, Rahman, Akbar = wrote: > such as fossati-core-multipar-ct I'm not sure we are ready to propose one specific format for response = sets. Just to demonstrate the potential variety, I have added another = proposal for a response set format to draft-bormann-coap-misc (section = 4). Gr=FC=DFe, Carsten From Akbar.Rahman@interdigital.com Thu Dec 19 08:17:18 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4BDB1ACCEC for ; Thu, 19 Dec 2013 08:17:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrWPHcK162BL for ; Thu, 19 Dec 2013 08:17:17 -0800 (PST) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) by ietfa.amsl.com (Postfix) with ESMTP id B64A71AC4A6 for ; Thu, 19 Dec 2013 08:17:17 -0800 (PST) X-ASG-Debug-ID: 1387469832-06daaa10617a8a0001-aa7cYp Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id vpXTSsRkv3RtEdoK for ; Thu, 19 Dec 2013 11:17:12 -0500 (EST) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Dec 2013 11:17:38 -0500 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 Dec 2013 11:17:37 -0500 X-ASG-Orig-Subj: Test Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Test Thread-Index: Ac781aZNZenU0admSqG/b5mVtAkQsg== From: "Rahman, Akbar" To: X-OriginalArrivalTime: 19 Dec 2013 16:17:38.0469 (UTC) FILETIME=[D5C00D50:01CEFCD5] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1387469832 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.143226 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Subject: [core] Test X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 16:17:19 -0000 This is a test (as our company Email servers are having some issues with ietf emails). Please ignore. From Akbar.Rahman@interdigital.com Thu Dec 19 09:03:05 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D51491AE06C for ; Thu, 19 Dec 2013 09:03:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9d8O-rGXAKZ for ; Thu, 19 Dec 2013 09:03:04 -0800 (PST) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) by ietfa.amsl.com (Postfix) with ESMTP id 512171AE034 for ; Thu, 19 Dec 2013 09:03:04 -0800 (PST) X-ASG-Debug-ID: 1387472580-06daaa10607b500001-aa7cYp Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id vZFA3YL0zSOWkDFy for ; Thu, 19 Dec 2013 12:03:00 -0500 (EST) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Dec 2013 12:03:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Thu, 19 Dec 2013 12:03:26 -0500 X-ASG-Orig-Subj: RE: [core] WGLC comments for draft-ietf-core-groupcomm-17 Message-ID: In-Reply-To: <031DD135F9160444ABBE3B0C36CED6180CC5868B@011-DB3MPN2-081.MGDPHG.emi.philips.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] WGLC comments for draft-ietf-core-groupcomm-17 Thread-Index: AQHO+7f4aMhII7lMuEy2T0VkoimTy5pZk7ewgAIql9A= References: <031DD135F9160444ABBE3B0C36CED6180CC5868B@011-DB3MPN2-081.MGDPHG.emi.philips.com> From: "Rahman, Akbar" To: "Dijk, Esko" X-OriginalArrivalTime: 19 Dec 2013 17:03:27.0008 (UTC) FILETIME=[3C01D200:01CEFCDC] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1387472580 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.143226 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Cc: core@ietf.org Subject: Re: [core] WGLC comments for draft-ietf-core-groupcomm-17 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 17:03:06 -0000 SGkgRXNrbywNCg0KDQo+PiBJIHN1Z2dlc3QgdGhhdCBmb3IgY29uZmlndXJhdGlvbiBvcGVyYXRp b25zIGEgY2xpZW50IGlzIHBlcm1pdHRlZCB0byB1c2UgbXVsaXRjYXN0IENvQVAgbWV0aG9kcyBh cyBvcHRpb24uDQoNCj5JIGRvbid0IHNlZSBhIHVzZSBjYXNlIHlldCBmb3IgbXVsdGljYXN0IGNv bmZpZ3VyYXRpb24gKFBVVC9QT1NUKS4gTWF5YmUgYSBtdWx0aWNhc3QgR0VUIG9uICJBbGwgQ29B UCBub2RlcyIgdG8gcXVpY2tseSBnYXRoZXIgZ3JvdXAgbWVtYmVyc2hpcCBpbmZvIGlzIHVzZWZ1 bCBmb3Igc29tZT8NCj5UaGUgTVVTVCB3ZSBoYXZlIHRoZXJlIHByb3ZpZGVzIHRoZSBiZXN0IGlu dGVyb3BlcmFiaWxpdHkgZm9yIHRob3NlIHdobyBpbXBsZW1lbnQgdGhlIGludGVyZmFjZS4gIEJ1 dCB3ZSBjb3VsZCBjb25zaWRlciB0aGF0IG11bHRpY2FzdCBNQVkgYmUgdXNlZCBmb3IgR0VUIHJl cXVlc3RzIG9uIHRoaXMgaW50ZXJmYWNlLiAoVGhhdCB3b3VsZCA+YmUgYWxsb3dlZCB0aGVuIHdp dGhvdXQgRFRMUywgc2luY2UgdGhlc2UgR0VUIHJlcXVlc3RzIGRvIG5vdCBhY3R1YWxseSBjaGFu Z2UgdGhlIGNvbmZpZ3VyYXRpb24gb24gbm9kZXMpIA0KDQo+QWtiYXIvYWxsLCBhbnkgY29tbWVu dHM/DQoNCg0KSSB0aGluayB0aGF0IGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gY2FuIG9mdGVu IGJlIHNlbnNpdGl2ZSBhcyB3ZWxsIChlLmcuIGl0IGNhbiBnaXZlIHZhbHVhYmxlIGhpbnRzIHRv IGFuIGF0dGFja2VyKS4gIFNvIHdlIHNob3VsZCBqdXN0IHN0aWNrIHRvIG91ciBjdXJyZW50IGFw cHJvYWNoIG9mIGtlZXBpbmcgdGhlIHdob2xlIEdyb3VwIE1lbWJlcnNoaXAgQ29uZmlndXJhdGlv biBSRVNUZnVsIGludGVyZmFjZSBhcyBNVVNUIGJlIHVuaWNhc3QgKHB0LXRvLXB0KSBhbmQgU0hP VUxEIHVzZSBEVExTLg0KDQoNCkJlc3QgUmVnYXJkcywNCg0KDQpBa2Jhcg0KDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBEaWprLCBFc2tvIFttYWlsdG86ZXNrby5kaWprQHBo aWxpcHMuY29tXSANClNlbnQ6IFdlZG5lc2RheSwgRGVjZW1iZXIgMTgsIDIwMTMgMzoyNSBBTQ0K VG86IHdlaWdlbmd5dTsgY29yZUBpZXRmLm9yZw0KQ2M6IFJhaG1hbiwgQWtiYXINClN1YmplY3Q6 IFJFOiBbY29yZV0gV0dMQyBjb21tZW50cyBmb3IgZHJhZnQtaWV0Zi1jb3JlLWdyb3VwY29tbS0x Nw0KDQpIZWxsbywNCg0KPiBNeSBjb21tZW50IGlzIHRoYXQgdGhyZWUgb3B0aW9ucyBhcmUgbm90 IGJldHRlciB0aGFuIG9uIGRlZGljYXRlZCBvbmUuDQo+IEl0IHBvc3NpYmxlIGFuZCBuZWNlc3Nh cnkgdG8gZGVmaW5lIGEgZGVkaWNhdGVkIHBvcnQgbnVtYmVyIGZvciBDb0FQIEdyb3VwIENvbW0g Pw0KPiBJZiB5b3UgdGhpbmsgbm90LCBqdXN0IGlnbm9yIHRoaXMgcHJvYmxlbS4NClRoZSBjdXJy ZW50IENvQVAgbW9kZWwgaXMgdGhhdCBpdCBhbGxvd3MgdG8gdXNlIGFueSBhdmFpbGFibGUgVURQ IHBvcnQ7IGFuZCBpbiBHcm91cENvbW0gd2Ugc2ltcGx5IGZvbGxvdyB0aGF0IG1vZGVsLg0KDQo+ IFtSRkMzNTQyXSBpcyBwb3NzaWxlIHRvIHVzZS4gQnV0IFJGQzM1NDIgaXMgZGVmaW5lZCBmb3Ig dXNpbmcgcmF3IElQdjYgc29ja2V0cy4NCj4gQ29BUCBwcm90b2NvbCBzdGFjayBoYXMgVURQIG92 ZXIgSVB2Ni4gIFNvLCBJIGRvIG5vdCBwcmVmZXIgdGhpcyBjcm9zcyBsYXllciBtZWNoYW5pc20u DQo+IFNvLCBJIHRoaW5rIHRoYXQgaXQgaXMgYmV0dGVyIGZvciB0aGUgVURQIGFuZCBDb0FQIHRv IGhhdmUgYW4gZXhwbGljaXQgaWRlbnRpZmllciBvZiBtdWx0aWNhc3Qgb3IgZ3JvdXAgY29tbXVu aWNhdGlvbnMuDQpJIGFncmVlIHRoaXMgbWlnaHQgYmUgZWFzaWVyIGZvciBkZXRlY3Rpb24gYXQg dGhlIENvQVAgbGV2ZWwuIEhvd2V2ZXIsIGl0IGRvZXMgbWVhbiBhIChtYWxpY2lvdXMsIG9yIHNs b3BweSkgY2xpZW50IGNvdWxkIHNlbmQgYSB1bmljYXN0LWZvcm1hdHRlZCBDb0FQIHJlcXVlc3Qg aW5zaWRlIGFuIElQIG11bHRpY2FzdCBwYWNrZXQuIFRoYXQgYWdhaW4gcG9zZXMgc2VjdXJpdHkv Y29uZ2VzdGlvbiByaXNrcyBpZiB0aGUgc2VydmVycyBhcmUgdW5hd2FyZSBvZiB0aGlzIGZhY3Qu IEFuZCBiZXNpZGVzIGN1cnJlbnQgY29yZS1jb2FwIHdoaWNoIGlzIG5lYXJseSBkb25lLCBkb2Vz IG5vdCBoYXZlIGEgZmxhZyB0byBpbmRpY2F0ZSAnbXVsdGljYXN0Jy4NCg0KPiBNYXliZSwgQ2hh bmdlIHRvOiAiVGhlIENvQVAgY2xpZW50IGNhbiBkaXN0aW5ndWlzaCB0aGUgb3JpZ2luIG9mIG11 bHRpcGxlIHNlcnZlciByZXNwb25zZXMgYnkgc291cmNlIElQIGFkZHJlc3Mgb2YgdGhlIFVEUCBt ZXNzYWdlIG9yIG90aGVyIHVuaXF1ZSBpZGVudGl0eS4gICINCkkgYWdyZWUgd2l0aCB0aGlzIHBy b3Bvc2FsLiBJdCBpcyBub3QgbWFuZGF0b3J5IHRvIHVzZSB0aGUgc291cmNlIElQIGFkZHJlc3Mg b2YgdGhlIFVEUCBtZXNzYWdlIGlmIGFub3RoZXIgbWVhbnMgb2YgaWRlbnRpZmljYXRpb24gaXMg cHJlc2VudCBpbiB0aGUgcmVzcG9uc2UuIEUuZy4sIHNvbWUgSUQgaW4gdGhlIHBheWxvYWQgb3Ig dGhlIHJlY2VudGx5IHByb3Bvc2VkICJOb2RlSUQiIG9wdGlvbiBvciBzaW1pbGFyLCBpbiB0aGUg ZnV0dXJlLg0KDQo+IEkgc3VnZ2VzdCB0aGF0IGZvciBjb25maWd1cmF0aW9uIG9wZXJhdGlvbnMg YSBjbGllbnQgaXMgcGVybWl0dGVkIHRvIHVzZSBtdWxpdGNhc3QgQ29BUCBtZXRob2RzIGFzIG9w dGlvbi4NCkkgZG9uJ3Qgc2VlIGEgdXNlIGNhc2UgeWV0IGZvciBtdWx0aWNhc3QgY29uZmlndXJh dGlvbiAoUFVUL1BPU1QpLiBNYXliZSBhIG11bHRpY2FzdCBHRVQgb24gIkFsbCBDb0FQIG5vZGVz IiB0byBxdWlja2x5IGdhdGhlciBncm91cCBtZW1iZXJzaGlwIGluZm8gaXMgdXNlZnVsIGZvciBz b21lPw0KVGhlIE1VU1Qgd2UgaGF2ZSB0aGVyZSBwcm92aWRlcyB0aGUgYmVzdCBpbnRlcm9wZXJh YmlsaXR5IGZvciB0aG9zZSB3aG8gaW1wbGVtZW50IHRoZSBpbnRlcmZhY2UuICBCdXQgd2UgY291 bGQgY29uc2lkZXIgdGhhdCBtdWx0aWNhc3QgTUFZIGJlIHVzZWQgZm9yIEdFVCByZXF1ZXN0cyBv biB0aGlzIGludGVyZmFjZS4gKFRoYXQgd291bGQgYmUgYWxsb3dlZCB0aGVuIHdpdGhvdXQgRFRM Uywgc2luY2UgdGhlc2UgR0VUIHJlcXVlc3RzIGRvIG5vdCBhY3R1YWxseSBjaGFuZ2UgdGhlIGNv bmZpZ3VyYXRpb24gb24gbm9kZXMpIEFrYmFyL2FsbCwgYW55IGNvbW1lbnRzPw0KDQo+IFdoeSBu b3QgdG8gdXNlIGNvbmdlc3Rpb24gYXZvaWRhbmNlLg0KVGhlIHRlcm0gIkNvbmdlc3Rpb24gY29u dHJvbCIgaXMgdGFrZW4gb3ZlciBmcm9tIGNvcmUtY29hcC4gSSdtIG5vdCBzdXJlIHdoZXRoZXIg dGhlcmUgYXJlIGdlbmVyYWwgZGVmaW5pdGlvbnMgb2YgYm90aD8gVGhlIEphY29ic29uIHBhcGVy IHNlZW1zIHRvIHN1Z2dlc3QgdGhhdCAiY29udHJvbCIgaXMgdGhlIGFjdGl2ZSBpZGVudGlmaWNh dGlvbiBvZiBjb25nZXN0aW9uIHByb2JsZW1zIGluIHRoZSBuZXR3b3JrIGFuZCBmaXhpbmcgdGhl bS4NCldlIHJhdGhlciB1c2UgdGhlIHRlcm0gYXMgdGhlIHNwZWNpZmljIHBvbGljaWVzL21lY2hh bmlzbXMgdGhhdCBib3RoIGNsaWVudHMgYW5kIHNlcnZlcnMgaGF2ZSB0byBhcHBseSwgb3IgbWF5 IGFwcGx5LCB0byByZWR1Y2UgdGhlIHJpc2sgb2YgbmV0d29yayBjb25nZXN0aW9uLg0KDQpFc2tv DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUaGUgaW5mb3JtYXRpb24gY29u dGFpbmVkIGluIHRoaXMgbWVzc2FnZSBtYXkgYmUgY29uZmlkZW50aWFsIGFuZCBsZWdhbGx5IHBy b3RlY3RlZCB1bmRlciBhcHBsaWNhYmxlIGxhdy4gVGhlIG1lc3NhZ2UgaXMgaW50ZW5kZWQgc29s ZWx5IGZvciB0aGUgYWRkcmVzc2VlKHMpLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVj aXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB1c2UsIGZvcndhcmRpbmcs IGRpc3NlbWluYXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIG1lc3NhZ2UgaXMgc3RyaWN0 bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1h aWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0aGUgb3JpZ2luYWwgbWVzc2FnZS4NCg== From pab@pabigot.com Fri Dec 20 06:53:16 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E311AE2E8 for ; Fri, 20 Dec 2013 06:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ToWty_-EmF7L for ; Fri, 20 Dec 2013 06:53:15 -0800 (PST) Received: from m1plsmtpa01-01.prod.mesa1.secureserver.net (m1plsmtpa01-01.prod.mesa1.secureserver.net [64.202.165.173]) by ietfa.amsl.com (Postfix) with ESMTP id 692A11AE2E2 for ; Fri, 20 Dec 2013 06:53:15 -0800 (PST) Received: from [192.168.65.10] ([66.41.60.82]) by m1plsmtpa01-01.prod.mesa1.secureserver.net with id 3qtB1n00S1mTNtu01qtCTt; Fri, 20 Dec 2013 07:53:13 -0700 Message-ID: <52B459DE.2050706@pabigot.com> Date: Fri, 20 Dec 2013 08:53:18 -0600 From: "Peter A. Bigot" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: core Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [core] core-coap RFC status X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 14:53:16 -0000 draft-ietf-core-coap has been hanging in limbo for about a year now, currently waiting for some missing references. In this state it's not possible to record technical issues where they can easily be found by future implementers (viz. as errata recorded on the IETF RFC page). There are gaps in -coap that impact the evaluation of documents that are in or have passed WGLC. The interaction of message cancellation with retransmission requirements affects an assessment of the supersedure approach in -observe. I expect -groupcomm also has some impact on how -coap must be interpreted since -coap only barely mentions multicast support. Is there an estimate of when this will be resolved? Peter From cabo@tzi.org Fri Dec 20 07:15:00 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D621ACCDF for ; Fri, 20 Dec 2013 07:15:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9k1NOkGJs_Y for ; Fri, 20 Dec 2013 07:14:58 -0800 (PST) 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 BC3E61ACC8A for ; Fri, 20 Dec 2013 07:14:57 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rBKFEnmt013883; Fri, 20 Dec 2013 16:14:49 +0100 (CET) Received: from fb3-c3750-e0-1.informatik.uni-bremen.de (fb3-c3750-e0-1.informatik.uni-bremen.de [134.102.116.253]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 22F64EB5; Fri, 20 Dec 2013 16:14:49 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: <52B459DE.2050706@pabigot.com> Date: Fri, 20 Dec 2013 16:14:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52B459DE.2050706@pabigot.com> To: "Peter A. Bigot" X-Mailer: Apple Mail (2.1827) Cc: core Subject: Re: [core] core-coap RFC status X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 15:15:00 -0000 On 20 Dec 2013, at 15:53, Peter A. Bigot wrote: > Is there an estimate of when this will be resolved? The status of the RFC as it progresses through publication can be = watched at: http://www.rfc-editor.org/cluster_info.php?cid=3DC203 This shows that publication is held up by waiting for two security area = documents. Following the links on this page, and using the =93history=94 tab on the = linked pages, we see: draft-mcgrew-tls-aes-ccm-ecc-07 2013-10-24 07 State changed to Approved-announcement to be = sent::Point Raised - writeup needed from IESG Evaluation draft-ietf-tls-oob-pubkey-10 2013-11-21 10 State changed to Approved-announcement to be = sent::Point Raised - writeup needed from IESG Evaluation So both documents have already been approved a while ago, but are = waiting for some processing by their responsible AD. (Unfortunately, this also means the IANA assignments needed to use = CoAP=92s RPK mode also haven=92t been made. We went into the last CoAP interop with made-up numbers for these.) Once the write-ups for the two drafts are available, the RFC editor will = process them, and then the entire cluster will be published; this = typically takes another two months. This does not have to keep us from creating implementer notes. Two documents of interest are: =97 http://tools.ietf.org/html/draft-bormann-core-roadmap This is a place where we can collect information about how pieces fit = together,=20 as well as non-obvious spec interpretation issues. =97 http://tools.ietf.org/html/draft-kovatsch-lwig-coap This can be used to collect implementation notes, including = implementation techniques=20 that may not be obvious. Both documents are meant to be open to contributions. If you are aware of something that needs to be documented, please tell = us (or, even better, write text). Gr=FC=DFe, Carsten From trac+core@trac.tools.ietf.org Sun Dec 22 12:21:57 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C81B31AE037 for ; Sun, 22 Dec 2013 12:21:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMhrLPT3VJOZ for ; Sun, 22 Dec 2013 12:21:56 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id F381C1AE320 for ; Sun, 22 Dec 2013 12:21:55 -0800 (PST) Received: from localhost ([127.0.0.1]:43967 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VupX3-0002sl-HF; Sun, 22 Dec 2013 21:21:49 +0100 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: Sun, 22 Dec 2013 20:21:49 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/357 Message-ID: <060.92b43c5a8289d01c5a37be4497bacdc7@trac.tools.ietf.org> X-Trac-Ticket-ID: 357 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 Cc: core@ietf.org Subject: [core] #357: To add "IPv6 addresses of other scopes MAY be enabled." X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 22 Dec 2013 20:21:58 -0000 #357: To add "IPv6 addresses of other scopes MAY be enabled." "For IPv4, the address is 224.0.1.187 and for IPv6 a server node joins at least both the link-local scoped address FF02::FD and the site-local scoped address FF05::FD." Based on WGLC comment Thomas Fossati; "second para, last sentence: is there any reason why the "may also be enabled" is not RFC2119?". To add "IPv6 addresses of other scopes MAY be enabled." -- -------------------------+------------------------------------------------- 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 Sun Dec 22 12:49:55 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1B61AEC07 for ; Sun, 22 Dec 2013 12:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzH2fYlsUs-t for ; Sun, 22 Dec 2013 12:49:54 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id DF1B11AEC05 for ; Sun, 22 Dec 2013 12:49:53 -0800 (PST) Received: from localhost ([127.0.0.1]:45218 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Vupy9-0008On-8w; Sun, 22 Dec 2013 21:49:49 +0100 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: Sun, 22 Dec 2013 20:49:49 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/358 Message-ID: <060.40e2fe0c2d7e0612baa22e4634662627@trac.tools.ietf.org> X-Trac-Ticket-ID: 358 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 Cc: core@ietf.org Subject: [core] #358: Fix requirements text for Section 2.7.2.1 Group Membership Interface X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 22 Dec 2013 20:49:55 -0000 #358: Fix requirements text for Section 2.7.2.1 Group Membership Interface Fix requirements text for Section 2.7.2.1 Group Membership Interface "In a response, the "a" 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." -> change to "In a response, the "a" key/value pair SHOULD be included if the IP address is known at the time of generating the response, and MUST NOT be included if unknown." -- -------------------------+------------------------------------------------- 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 Sun Dec 22 12:51:03 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 189D41AE256 for ; Sun, 22 Dec 2013 12:51:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I20h26S9isgv for ; Sun, 22 Dec 2013 12:51:01 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id BA74C1AE06A for ; Sun, 22 Dec 2013 12:51:01 -0800 (PST) Received: from localhost ([127.0.0.1]:45266 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VupzC-0004q5-O2; Sun, 22 Dec 2013 21:50:54 +0100 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: Sun, 22 Dec 2013 20:50:54 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/358#comment:1 Message-ID: <075.72dfc271ed2d20e20c57a3d93a3fa297@trac.tools.ietf.org> References: <060.40e2fe0c2d7e0612baa22e4634662627@trac.tools.ietf.org> X-Trac-Ticket-ID: 358 In-Reply-To: <060.40e2fe0c2d7e0612baa22e4634662627@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 Cc: core@ietf.org Subject: Re: [core] #358: Fix requirements text for Section 2.7.2.1 Group Membership Interface X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 22 Dec 2013 20:51:03 -0000 #358: Fix requirements text for Section 2.7.2.1 Group Membership Interface Comment (by esko.dijk@philips.com): From the WGLC review by Thomas Fossati -- -------------------------+------------------------------------------------- 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 trac+core@trac.tools.ietf.org Sun Dec 22 13:01:18 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8614E1AE055 for ; Sun, 22 Dec 2013 13:01:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, UPPERCASE_50_75=0.008] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1yuFjgqOfHo for ; Sun, 22 Dec 2013 13:01:17 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 311BD1AE010 for ; Sun, 22 Dec 2013 13:01:17 -0800 (PST) Received: from localhost ([127.0.0.1]:45444 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Vuq97-0002iJ-DY; Sun, 22 Dec 2013 22:01:09 +0100 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: Sun, 22 Dec 2013 21:01:09 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/359 Message-ID: <060.5fa5cf83e5505791b48717a0abde9869@trac.tools.ietf.org> X-Trac-Ticket-ID: 359 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 Cc: core@ietf.org Subject: [core] #359: Fix requirements text for Section 2.7.2.2. X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 22 Dec 2013 21:01:18 -0000 #359: Fix requirements text for Section 2.7.2.2. Based on WGLC review Thomas Fossati: >Section 2.7.2.2 > >- I'd add a note about the need for the Group index to be unique >- what happens when a client tries to register a duplicate "a"? >- last para: add context/rationale for the re-join requirement on POST >of an already registered [AKBAR] OK, WE CAN ADD A SENTENCE SAYING A GENERATED GROUP INDEX "MUST" BE LOCALLY UNIQUE. WE COULD ADD THAT A CLIENT "MUST NOT" REGISTER A DUPLICATE "a" IN A SINGLE PUT OR POST REQUEST. THE "MUST re-join" WAS STATED FOR DIAGNOSTICS/DEBUGGING PURPOSES. IF MULTICAST RECEPTION FOR SOME REASON DOES NOT WORK ON THE NODE, USING THIS GROUP API, A REJOIN OF THE MULTICAST GROUP COULD BE FORCED. HOWEVER FOR INTEROPERABILITY THIS IS NOT STRICTLY NEEDED; AS THE CLIENT COULD SIMPLY SEND A COMMAND TO UNREGISTER THE GROUP AND SUBSEQUENTLY SEND A COMMAND TO JOIN THAT GROUP, EFFECTING THE SAME RESULT. SO WE COULD DROP THE "MUST" AND LEAVE THE EXACT BEHAVIOR UP TO THE IMPLEMENTER. -- -------------------------+------------------------------------------------- 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 Sun Dec 22 13:19:41 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A989B1AEC75 for ; Sun, 22 Dec 2013 13:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9Oe_OwiGDTZ for ; Sun, 22 Dec 2013 13:19:39 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id E05431AEC70 for ; Sun, 22 Dec 2013 13:19:38 -0800 (PST) Received: from localhost ([127.0.0.1]:45884 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VuqQv-0007ak-JS; Sun, 22 Dec 2013 22:19:33 +0100 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: Sun, 22 Dec 2013 21:19:33 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/360 Message-ID: <060.19957e60b1c16a62fc8bf9f2bfdac52a@trac.tools.ietf.org> X-Trac-Ticket-ID: 360 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 Cc: core@ietf.org Subject: [core] #360: Add text for server duties upon all-at-once PUT section 2.7.2.6 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 22 Dec 2013 21:19:41 -0000 #360: Add text for server duties upon all-at-once PUT section 2.7.2.6 Based on WGLC review Thomas Fossati; >- would be nice to have text that describes the actions that are to be >done by the server on successful update Proposal to add: After a successful PUT on the Group configuration resource, the endpoint MUST effect registration to any new IP multicast group(s) and de- registration from any previous IP multicast group(s), i.e. not anymore present in the new memberships, as soon as possible. Also it MUST take into account the group indices present in the new resource during the generation of any new unique group indices in the future. -- -------------------------+------------------------------------------------- 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 Sun Dec 22 13:32:13 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E90101AEC8A for ; Sun, 22 Dec 2013 13:32:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUQ43utejAN5 for ; Sun, 22 Dec 2013 13:32:12 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 2888A1AEC89 for ; Sun, 22 Dec 2013 13:32:12 -0800 (PST) Received: from localhost ([127.0.0.1]:46603 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Vuqd2-0001o4-Ov; Sun, 22 Dec 2013 22:32:04 +0100 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: Sun, 22 Dec 2013 21:32:04 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/361 Message-ID: <060.aadc15a569395836d4f72809459c6dfa@trac.tools.ietf.org> X-Trac-Ticket-ID: 361 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 Cc: core@ietf.org Subject: [core] #361: Add text for single membership PUT section 2.7.2.7. X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 22 Dec 2013 21:32:14 -0000 #361: Add text for single membership PUT section 2.7.2.7. Based on WGLC review Thomas Fossati; >Section 2.7.2.7 > >- first para: it's not clear what makes a CoAP client responsibile for >the group membership objects >- would be nice to have text that describes the actions that are to be >done by the server on successful update [AKBAR] OK. THE RESPONSIBILITY CAN BE BASED ON APPLICATION-LEVEL KNOWLEDGE, E.G. A COMISSIONING TOOL (CT) ALWAYS ASSUMES IT IS RESPONSIBLE FOR ANY GROUP MEMBERSHIP OBJECTS THAT THE CT IS USED ON BY THE HUMAN OPERATOR. BY DEFAULT, A COAP CLIENT IS ONLY RESPONSIBLE FOR THOSE GROPU MEMBERSHIP OBJECTS THAT IT CREATED (USING POST OR PUT). TEXT ABOUT THE ACTIONS WILL BE ADDED. Proposal: to add " A (unicast) PUT with a group membership JSON object will replace an existing group membership in the endpoint with the new one defined in the PUT request. This can be used to update the group membership. After a successful PUT on the Group configuration resource, the endpoint MUST effect registration to any new IP multicast group(s) and de- registration from any previous IP multicast group(s), i.e. not anymore present in the new membership, as soon as possible. " -- -------------------------+------------------------------------------------- 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 internet-drafts@ietf.org Sun Dec 22 17:55:41 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1D851AE348; Sun, 22 Dec 2013 17:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCYJxREpv2uU; Sun, 22 Dec 2013 17:55:40 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D75A1AE39A; Sun, 22 Dec 2013 17:55:39 -0800 (PST) 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.90 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131223015539.15610.78795.idtracker@ietfa.amsl.com> Date: Sun, 22 Dec 2013 17:55:39 -0800 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-groupcomm-18.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2013 01:55:42 -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 Authors : Akbar Rahman Esko Dijk Filename : draft-ietf-core-groupcomm-18.txt Pages : 48 Date : 2013-12-22 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-18 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-groupcomm-18 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 Sun Dec 22 18:40:00 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93EC01AE667 for ; Sun, 22 Dec 2013 18:40:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yt3pM6_zshhI for ; Sun, 22 Dec 2013 18:39:58 -0800 (PST) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) by ietfa.amsl.com (Postfix) with ESMTP id 997D51AE626 for ; Sun, 22 Dec 2013 18:39:58 -0800 (PST) X-ASG-Debug-ID: 1387766394-06daaa105f977c0001-aa7cYp Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id xLEZ442S3kQK50dY for ; Sun, 22 Dec 2013 21:39:54 -0500 (EST) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 22 Dec 2013 21:40:21 -0500 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: Sun, 22 Dec 2013 21:40:19 -0500 X-ASG-Orig-Subj: RE: [core] I-D Action: draft-ietf-core-groupcomm-18.txt Message-ID: In-Reply-To: <20131223015539.15610.78795.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] I-D Action: draft-ietf-core-groupcomm-18.txt Thread-Index: Ac7/gkrr9xBorqO/TLuuTJzynfN5KwAAAgXQ References: <20131223015539.15610.78795.idtracker@ietfa.amsl.com> From: "Rahman, Akbar" To: X-OriginalArrivalTime: 23 Dec 2013 02:40:21.0310 (UTC) FILETIME=[52FA65E0:01CEFF88] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1387766394 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.143316 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Cc: core@ietf.org Subject: Re: [core] I-D Action: draft-ietf-core-groupcomm-18.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2013 02:40:00 -0000 Hi Carsten, We have updated the Groupcomm draft to address all the WGLC issues raised by Thomas Fossati and Gengyu Wei (that we agreed were within the scope of the current document). The details of the exact changes are listed below. Please tell us if you want us to make any further updates. Best Regards, Akbar & Esko ---------------------------------------------------------- Changes from ietf-17 to ietf-18: o Extensive editorial updates based on WGLC comments by Thomas Fossati and Gengyu Wei. o Addressed ticket #361: Added text for single membership PUT section 2.7.2.7 (Updating a single group membership (PUT)). o Addressed ticket #360: Added text for server duties upon all-at- once PUT section 2.7.2.6 (Creating/updating all group memberships at once (PUT)). o Addressed ticket #359: Fixed requirements text for Section 2.7.2.2 (Creating a new multicast group membership (POST)). o Addressed ticket #358: Fixed requirements text for Section 2.7.2.1 (CoAP-Group Resource Type and Media Type). o Addressed ticket #357: Added that "IPv6 addresses of other scopes MAY be enabled" in section 2.2 (Group Definition and Naming). o Various editorial updates for improved readability. -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Sunday, December 22, 2013 8:56 PM To: i-d-announce@ietf.org Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-groupcomm-18.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments Working Group of the IETF. Title : Group Communication for CoAP Authors : Akbar Rahman Esko Dijk Filename : draft-ietf-core-groupcomm-18.txt Pages : 48 Date : 2013-12-22 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-18 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-groupcomm-18 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 barryleiba.mailing.lists@gmail.com Mon Dec 23 10:57:00 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E01D11AE264 for ; Mon, 23 Dec 2013 10:57:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ic9ZZ8HRzAR5 for ; Mon, 23 Dec 2013 10:57:00 -0800 (PST) Received: from mail-vb0-x22a.google.com (mail-vb0-x22a.google.com [IPv6:2607:f8b0:400c:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id E33CC1AE263 for ; Mon, 23 Dec 2013 10:56:59 -0800 (PST) Received: by mail-vb0-f42.google.com with SMTP id w5so3021144vbf.15 for ; Mon, 23 Dec 2013 10:56:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=zdlxclyNfdYPW3tTU7/676oLMZBbvyPi2XtgaR4dldU=; b=qhXXXPsIVgzUSSuP8mjyPqdB5L/MEfWJs1DaZC0n39N9COGD6/LQXelHAXyTb+aLSe PYBwgT/TTFKntl3agRdVGqxeXU+8JJPkuFMkETH+bKbNr2RZBDrb/To5ZroK9tXg6Bkq 9uN8SWoNJGVAh753X2Fz0BKCjVTMmvQ+86IPhTh1D3oSHOhpdNAOjoqHfGPliiCdLGqY DMxCP70eC9bfW3PLigxwSw/SICGaUy1NpdnH0NuGZCoxZnbV2KQRGYAvHtZ3+Erao8HN ooMskvgcqa2GC6tv3nF1DkPGvXQlMQOu/i1kDe13nXOaeIy3ixT2/PCVtiuTuysJeo3c 5Ejw== MIME-Version: 1.0 X-Received: by 10.220.159.4 with SMTP id h4mr14510407vcx.1.1387825016404; Mon, 23 Dec 2013 10:56:56 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.170.71 with HTTP; Mon, 23 Dec 2013 10:56:56 -0800 (PST) In-Reply-To: <52B459DE.2050706@pabigot.com> References: <52B459DE.2050706@pabigot.com> Date: Mon, 23 Dec 2013 13:56:56 -0500 X-Google-Sender-Auth: LbzxiqMARRFKVCWluiIcVHNNmSk Message-ID: From: Barry Leiba To: "Peter A. Bigot" Content-Type: text/plain; charset=ISO-8859-1 Cc: core Subject: Re: [core] core-coap RFC status X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2013 18:57:01 -0000 In addition to what Carsten said, let me add one thing: > In this state it's not > possible to record technical issues where they can easily be found by > future implementers (viz. as errata recorded on the IETF RFC page). The CoAP document will go through a final edit phase (called "AUTH48") once the missing references are cleared (and I'm working with Sean, the responsible AD for the two TLS documents in question, to get that to happen as soon as possible). Significant changes to the document are not allowed in AUTH48 state, but: 1. Anything that would otherwise be filed as errata can and should be fixed in AUTH48. If there are things of that nature that we know now that need to be corrected, be sure the authors and chairs know about them so we can get them fixed at the time the RFC is published, so we don't need to file errata later. 2. It's possible to have the working group review other changes and to make them during AUTH48. This does not include significant rethinking of things, nor resolution of new controversies (or revisiting of old ones), but it can include technical faults that were not anticipated and have since been discovered. Again, if there are things of this nature, please make sure we sort them out *before* the RFC is published. Barry, Applications AD From pab@pabigot.com Mon Dec 23 11:34:37 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 912601AE18B for ; Mon, 23 Dec 2013 11:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRhZg-Cv2GX4 for ; Mon, 23 Dec 2013 11:34:36 -0800 (PST) Received: from p3plsmtpa07-10.prod.phx3.secureserver.net (p3plsmtpa07-10.prod.phx3.secureserver.net [173.201.192.239]) by ietfa.amsl.com (Postfix) with ESMTP id E8FD81ADFE8 for ; Mon, 23 Dec 2013 11:34:35 -0800 (PST) Received: from [192.168.65.10] ([66.41.60.82]) by p3plsmtpa07-10.prod.phx3.secureserver.net with id 57aX1n0041mTNtu017aXY1; Mon, 23 Dec 2013 12:34:32 -0700 Message-ID: <52B8904F.8070902@pabigot.com> Date: Mon, 23 Dec 2013 13:34:39 -0600 From: "Peter A. Bigot" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Barry Leiba References: <52B459DE.2050706@pabigot.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: core Subject: Re: [core] core-coap RFC status X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2013 19:34:37 -0000 On 12/23/2013 12:56 PM, Barry Leiba wrote: > In addition to what Carsten said, let me add one thing: > >> In this state it's not >> possible to record technical issues where they can easily be found by >> future implementers (viz. as errata recorded on the IETF RFC page). > > The CoAP document will go through a final edit phase (called "AUTH48") > once the missing references are cleared (and I'm working with Sean, > the responsible AD for the two TLS documents in question, to get that > to happen as soon as possible). Significant changes to the document > are not allowed in AUTH48 state, but: > > 1. Anything that would otherwise be filed as errata can and should be > fixed in AUTH48. If there are things of that nature that we know now > that need to be corrected, be sure the authors and chairs know about > them so we can get them fixed at the time the RFC is published, so we > don't need to file errata later. > > 2. It's possible to have the working group review other changes and to > make them during AUTH48. This does not include significant rethinking > of things, nor resolution of new controversies (or revisiting of old > ones), but it can include technical faults that were not anticipated > and have since been discovered. Again, if there are things of this > nature, please make sure we sort them out *before* the RFC is > published. > > Barry, Applications AD > The two topics I recall planning to raise as technical errata are: 1) the ability to express option numbers that exceed 65535, as raised in http://www.ietf.org/mail-archive/web/core/current/msg04972.html. 2) The interaction of message cancellation (a REST-layer concept) with CoAP message-layer retransmission which is subject to congestion limitations. The fundamental issue is whether base CoAP permits a right-to-transmit that is left unused due to cancellation to be transferred to a new message, and if so any constraints on how such a transmission may be used. One entry point to the massive but unresolved (AFAIK) discussion is at http://www.ietf.org/mail-archive/web/core/current/msg05038.html. (I think -observe was updated in some way resulting from this discussion, but that the underlying issue with respect to -core remains unaddressed.) My views and proposals on these issues are in the referenced messages and their follow-ups. I don't recall a consensus on either. Peter From weigengyu@bupt.edu.cn Mon Dec 23 21:18:07 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0A8E1AE413 for ; Mon, 23 Dec 2013 21:18:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.457 X-Spam-Level: ** X-Spam-Status: No, score=2.457 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, STOX_REPLY_TYPE_WITHOUT_QUOTES=1.757] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ibXicfGc30z for ; Mon, 23 Dec 2013 21:18:02 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2813A1AE410 for ; Mon, 23 Dec 2013 21:17:59 -0800 (PST) Received: from WeiGengyuPC (unknown [10.103.241.46]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id EB27919F36F; Tue, 24 Dec 2013 13:17:52 +0800 (HKT) Message-ID: From: "weigengyu" To: "Carsten Bormann" , References: In-Reply-To: Date: Tue, 24 Dec 2013 13:17:53 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3505.912 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912 Subject: [core] Group Communication identify X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Dec 2013 05:18:08 -0000 Hi Carsten and all: I raise a problem without relation to the current group comm draft. The problem is whether we need an explicit identity of multicast/group comm message. There is no identity in the CoAP message whether it is a group comm or multicast message in CoAP-18. Although Group URI is defined in Group Comm for CoAP, each node needs to do name resolution to know the multicast/group comm, or the node to dig out the IP address from the underneath protocol layers. This may not be a trivial for an intermediary node to get this knowledge when forwading message as message is transferred hop by hop. So, marking a message to be multicast/group comm can simplify this. Marking a message to be a CoAP multicast/group comm message would have following alternatives: 1. define a bit flag in message format, that informs whether message is sent in multicast/group comm; 2. define a option of multicast or Group comm; 3. define a dedicated UDP port number, which represents for multicast/group comm; 4. define a primitive to get the underneath IP address and determines whether the message is multicast/group comm by IP multicast address; Current CoAP drafts seem to use #4 that is a cross layer means. Probably, the above #1, #2 and #3 would be better than #4. Regards, Gengyu Network Technology Center School of computer Beijing University of Posts & Telecommunications -----原始邮件----- From: Carsten Bormann Sent: Tuesday, December 10, 2013 1:49 AM To: core (core@ietf.org) Subject: [core] WGLC of draft-ietf-core-groupcomm-17 In Vancouver, we said we were going to WGLC the groupcomm draft after some more edits, which were submitted by the authors on 2013-11-28. All outstanding tickets are closed. The recent discussion on correlating responses to multicast requests might lead to some additional explanatory text on how to handle the correlation, but this is something we can handle during the WGLC. So this starts a working group last call for -groupcomm for submission as an informational RFC, ending on 24:00 PDT on Monday, December 23, 2013. Please start a new email thread for each major issue that will need discussion and make sure the subject line includes the draft name and some sort of name for the issue. For minor issues such as typos and things that are not likely to lead to much discussion, it is probably easier to group them all in to one email but again, please make sure the subject line includes the draft name. If you read the draft and think it looks fine, please send a one line email to the list or to the chairs letting us know that so we can get a feel of how broad the review has been. If you are aware of any patent claims that might apply to systems that implement the suggestions in this draft, please review BCP 78 and BCP 79 and make any appropriate IPR declaration. If you are not sure whether you need to make a declaration or not, please talk to the chairs and we will help get you in touch with people that can provide appropriate advice. Grüße, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core