From prvs=979304fdf=abhijan.bhattacharyya@tcs.com Tue Oct 1 13:22:39 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9607411E81B9 for ; Tue, 1 Oct 2013 13:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTtd1+KPTjrW for ; Tue, 1 Oct 2013 13:22:28 -0700 (PDT) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id BA08711E8153 for ; Tue, 1 Oct 2013 13:22:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,1015,1371061800"; d="scan'208";a="455452651" Received: from INKOLSALDLPMTA1.india.tcs.com (unknown [127.0.0.1]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id 6A7D2DAC12; Wed, 2 Oct 2013 01:51:53 +0530 (IST) Received: from InKolM02.tcs.com (unknown [172.18.18.104]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id 3ABCADAC02; Wed, 2 Oct 2013 01:51:53 +0530 (IST) MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: , From: Abhijan Bhattacharyya To: "Rahman, Akbar" , "Carsten Bormann" Message-ID: Date: Wed, 2 Oct 2013 01:51:51 +0530 X-Mailer: Lotus Domino Web Server Release 9.0HF507 August 20, 2013 X-MIMETrack: Serialize by Notes Server on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 10/02/2013 01:51:51, Serialize complete at 10/02/2013 01:51:51, Itemize by Notes Server on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 10/02/2013 01:51:51, Serialize by Notes Server on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 10/02/2013 01:51:52, Serialize complete at 10/02/2013 01:51:52, Serialize by Router on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 10/02/2013 01:51:52 Content-Type: multipart/alternative; boundary="=_alternative 006FDD2965257BF7_=" Cc: Arpan Pal , core@ietf.org Subject: Re: [core] Fw: New Version Notification fordraft-tcs-coap-no-response-option-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 20:22:40 -0000 --=_alternative 006FDD2965257BF7_= MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Akbar & Carsten, First of all, thank you very much for your detail scrutiny of the draft. = =A0Let us address the comments one by one. 1) Regarding editorial issues: =A0 =A0------------------------- Yes, indeed there is deviation. Somehow it happened while submitting the in= itial version. Did not change the name in the next versions to avoid confus= ion as rightly pointed out by Carsten. 2) Regarding applicability of 'No-Resp' for POST =A0 =A0--------------------------------------------- Yes, the draft should give an example regarding how No-Resp for POST can be= useful. The cases where this option can be used with POST have already bee= n put up in the discussion. In fact, the request/response example given in = the draft (Figure 1) can also be performed using POST without changing any = functionality. In that case each update will actually create a resource wit= h the name-value pairs. Probably that might be useful for a real end-to-end= implementation which would need to maintain a database of the updates.=A0 Let me give a brief background here. This draft is actually a result of an = effort to improve an existing HTTP based traffic monitoring system. In the = HTTP case the clients actually 'POST' the updates in the form of name-value= pair as new resources. The handler at the server extracts the values from = the POST call and writes into the server. A typical RESTful request string,= in the HTTP based solution, looks like: POST //insertInfo?VehId=3D0010&RouteId=3DDN47&Lat=3D12.8888&Long= =3D88.2222&timeStamp=3D2013-08-03T15:55:07 The 'insertInfo' string provides the handler at the server end. Would the draft sound convincing for POST if we incorporate another example= with the same scenario, and with similar request string as the above, but = using CoAP?=A0 3) Regarding the semantics, etc. =A0 =A0----------------------------- We can change the 1 byte interpretation to keep the semantic integrity. In = fact, I later realized that we should actually do that way if we strictly a= dhere to the definition of 'uint' in the CoAP specification (the value zero= represented as empty to conserve bytes ). This can be done in no time. Bas= ically we have to 'NOT' the table for 1 byte representation.=A0 However, I need to get my understanding right regarding the concern raised = by Carsten on "how a client implementation would handle a response ...... a= s it no longer knows whether a response is to be expected and when it can s= top expecting one." I think it is a more generic question regarding the opt= ional granularity feature. Opening up any given class of response means, th= e client has to wait up to the defined time-out period for all the requests= . The client never knows whether the present request will be a success or a= failure. Thus, if the client decides to open up the responses for errors (= 4.xx & 5.xx) then it has to wait for the entire time-out period even for th= e instances where the request is successful and the server is not supposed = to send back a response. This may affect the performance in terms of time. = But the advantage due to resource saving will still hold good. We can leave= the use of the granularity feature on the application developer. Is my und= erstanding correct? =A0 Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Limited Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D Notice: The information contained in this e-mail message and/or attachments to it may contain = confidential or privileged information. If you are = not the intended recipient, any dissemination, use, = review, distribution, printing or copying of the = information contained in this e-mail message = and/or attachments to it are strictly prohibited. If = you have received this communication in error, = please notify us by reply e-mail or telephone and = immediately and permanently delete the message = and any attachments. Thank you --=_alternative 006FDD2965257BF7_= Content-ID: <> MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Akbar &= amp; Carsten,
First of all, thank you very much for your detail scrutiny of the = draft.  Let us address the comments one by one.

1) Regarding editorial issu= es:
&= nbsp;  -------------------------
Yes, indeed there is deviation. Somehow it= happened while submitting the initial version. Did not change the name in = the next versions to avoid confusion as rightly pointed out by Carsten.

2) Regar= ding applicability of 'No-Resp' for POST
   --------------------------= -------------------
Yes, the draft should give an example regarding how No-Resp = for POST can be useful. The cases where this option can be used with POST h= ave already been put up in the discussion. In fact, the request/response ex= ample given in the draft (Figure 1) can also be performed using POST withou= t changing any functionality. In that case each update will actually create= a resource with the name-value pairs. Probably that might be useful for a = real end-to-end implementation which would need to maintain a database of t= he updates. 
Let me give a brief background here. This draft is actually a = result of an effort to improve an existing HTTP based traffic monitoring sy= stem. In the HTTP case the clients actually 'POST' the updates in the form = of name-value pair as new resources. The handler at the server extracts the= values from the POST call and writes into the server. A typical RESTful re= quest string, in the HTTP based solution, looks like:
POST /<BaseUrl>/inse= rtInfo?VehId=3D0010&RouteId=3DDN47&Lat=3D12.8888&Long=3D88.2222= &timeStamp=3D2013-08-03T15:55:07

The 'insertInfo' string provides the handle= r at the server end.

Would the draft sound convincing for POST if we incorporate= another example with the same scenario, and with similar request string as= the above, but using CoAP? 

3) Regarding the semantics, etc.
<= div>   -----= ------------------------
We can change the 1 byte interpretation to keep the sem= antic integrity. In fact, I later realized that we should actually do that = way if we strictly adhere to the definition of 'uint' in the CoAP specifica= tion (the value zero represented as empty to conserve bytes ). This can be = done in no time. Basically we have to 'NOT' the table for 1 byte representa= tion. 
However, I need to get my understanding right regarding the concern = raised by Carsten on "how a client implementation would handle a response .= ..... as it no longer knows whether a response is to be expected and when i= t can stop expecting one." I think it is a more generic question regarding = the optional granularity feature. Opening up any given class of response me= ans, the client has to wait up to the defined time-out period for all the r= equests. The client never knows whether the present request will be a succe= ss or a failure. Thus, if the client decides to open up the responses for e= rrors (4.xx & 5.xx) then it has to wait for the entire time-out period = even for the instances where the request is successful and the server is no= t supposed to send back a response. This may affect the performance in term= s of time. But the advantage due to resource saving will still hold good. W= e can leave the use of the granularity feature on the application developer= . Is my understanding correct?  

Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innova= tion Lab, Kolkata, India
Tata Consultancy Services Limited
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.= com
___________= _________________________________
Experience certainty. IT Services
Business Solutions Consulting<= br>___________________= _________________________

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

--=_alternative 006FDD2965257BF7_=-- From trac+core@trac.tools.ietf.org Wed Oct 2 02:39:28 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7DB021E8286 for ; Wed, 2 Oct 2013 02:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_37=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uui3o8OOgEge for ; Wed, 2 Oct 2013 02:39:22 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5FF21E8155 for ; Wed, 2 Oct 2013 02:39:22 -0700 (PDT) Received: from localhost ([127.0.0.1]:54649 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VRIto-0003j4-KT; Wed, 02 Oct 2013 11:39:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Wed, 02 Oct 2013 09:39:16 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/342#comment:3 Message-ID: <075.5c9996aa1b6fb7906896fc07b0f4c9ef@trac.tools.ietf.org> References: <060.cc050320858f531c711a89d46c5b0c92@trac.tools.ietf.org> X-Trac-Ticket-ID: 342 In-Reply-To: <060.cc050320858f531c711a89d46c5b0c92@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20131002093922.6C5FF21E8155@ietfa.amsl.com> Resent-Date: Wed, 2 Oct 2013 02:39:22 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #342: Specify notation of IPv6 address in group membership configuration interface X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 09:39:29 -0000 #342: Specify notation of IPv6 address in group membership configuration interface Comment (by esko.dijk@philips.com): New proposal: to better comply to the RFC 3986 URI syntax, which is used by core-coap, the notation with square brackets is mandatory for IPv6. This allows re-use of the parsing code for CoAP URIs for this purpose. group-address = IPv4address [ “:” port ] / “[“ IPv6address “]” [“:” port ] Done in [1508] -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: protocol | Status: closed defect | Milestone: Priority: major | Version: Component: groupcomm | Resolution: fixed Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Wed Oct 2 02:50:07 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3AC21E82D6 for ; Wed, 2 Oct 2013 02:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHkx+HMvtmjL for ; Wed, 2 Oct 2013 02:49:59 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id A479221E80F1 for ; Wed, 2 Oct 2013 02:49:07 -0700 (PDT) Received: from localhost ([127.0.0.1]:55349 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VRJ3J-00076Z-4b; Wed, 02 Oct 2013 11:49:05 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Wed, 02 Oct 2013 09:49:05 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/345 Message-ID: <060.4f30f91b1272efb4055558cc7e059626@trac.tools.ietf.org> X-Trac-Ticket-ID: 345 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20131002094907.A479221E80F1@ietfa.amsl.com> Resent-Date: Wed, 2 Oct 2013 02:49:07 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #345: DELETE in group management interface does not really delete the resource X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 09:50:07 -0000 #345: DELETE in group management interface does not really delete the resource DELETE in group management interface (Section 2.6.2) does not really delete the resource, it only clears the JSON key/values of the resources. Therefore to comply better with CoAP DELETE semantics, the proposal is to not define DELETE here but rather PUT with an empty JSON array ([]) to clear the list. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: protocol | Status: new enhancement | Milestone: Priority: minor | Version: Component: groupcomm | Keywords: Severity: - | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Wed Oct 2 02:50:27 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5077621E8254 for ; Wed, 2 Oct 2013 02:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9C5VU-cEWae for ; Wed, 2 Oct 2013 02:50:19 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id AF7FD21E829E for ; Wed, 2 Oct 2013 02:49:29 -0700 (PDT) Received: from localhost ([127.0.0.1]:55354 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VRJ3d-00055Q-RD; Wed, 02 Oct 2013 11:49:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Wed, 02 Oct 2013 09:49:25 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/345#comment:1 Message-ID: <075.e7656b0a858ea0b00e8e2fc873fad67e@trac.tools.ietf.org> References: <060.4f30f91b1272efb4055558cc7e059626@trac.tools.ietf.org> X-Trac-Ticket-ID: 345 In-Reply-To: <060.4f30f91b1272efb4055558cc7e059626@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20131002094929.AF7FD21E829E@ietfa.amsl.com> Resent-Date: Wed, 2 Oct 2013 02:49:29 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #345: DELETE in group management interface does not really delete the resource X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 09:50:27 -0000 #345: DELETE in group management interface does not really delete the resource Changes (by esko.dijk@philips.com): * status: new => closed * resolution: => fixed Comment: Fixed in [1509] -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: protocol | Status: closed enhancement | Milestone: Priority: minor | Version: Component: groupcomm | Resolution: fixed Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From internet-drafts@ietf.org Wed Oct 2 06:51:56 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C45D21F9C8E; Wed, 2 Oct 2013 06:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWq0Iwqw-k3D; Wed, 2 Oct 2013 06:51:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C510E21F9D68; Wed, 2 Oct 2013 06:51:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131002135102.20697.64311.idtracker@ietfa.amsl.com> Date: Wed, 02 Oct 2013 06:51:02 -0700 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-groupcomm-16.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 13:51:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments Working = Group of the IETF. Title : Group Communication for CoAP Author(s) : Akbar Rahman Esko Dijk Filename : draft-ietf-core-groupcomm-16.txt Pages : 41 Date : 2013-10-02 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-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-groupcomm-16 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 Wed Oct 2 06:59:08 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B4921F92DA for ; Wed, 2 Oct 2013 06:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LukCV4+ubA2 for ; Wed, 2 Oct 2013 06:58:45 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 616EC21F9C68 for ; Wed, 2 Oct 2013 06:57:21 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Oct 2013 09:57:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Oct 2013 09:57:19 -0400 Message-ID: In-Reply-To: <20131002135102.20697.64311.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] I-D Action: draft-ietf-core-groupcomm-16.txt Thread-Index: Ac6/ds0cCP4793WITqqvFRXMRKsSCQAAAuSA References: <20131002135102.20697.64311.idtracker@ietfa.amsl.com> From: "Rahman, Akbar" To: "Carsten Bormann" X-OriginalArrivalTime: 02 Oct 2013 13:57:20.0579 (UTC) FILETIME=[50137930:01CEBF77] Cc: core@ietf.org Subject: Re: [core] I-D Action: draft-ietf-core-groupcomm-16.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 13:59:08 -0000 Hi Carsten, Esko and I have taken another pass through the Groupcomm I-D and have made the updates summarized below. Please review at your convenience and tell us if you have any other comments. Best Regards, Akbar & Esko =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Changes from ietf-15 to ietf-16: o In section 2.6.2, changed DELETE in group management interface to a PUT with empty JSON array to clear the list (#345). o In section 2.6.2, aligned the syntax for IP addresses to follow RFC 3986 URI syntax, which is also used by coap-18. This allows re-use of the parsing code for CoAP URIs for this purpose (#342). o Addressed some more editorial comments provided by Carsten Bormann in preparation for WGLC. o Various editorial updates for improved readability. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Wednesday, October 02, 2013 9:51 AM To: i-d-announce@ietf.org Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-groupcomm-16.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments Working Group of the IETF. Title : Group Communication for CoAP Author(s) : Akbar Rahman Esko Dijk Filename : draft-ietf-core-groupcomm-16.txt Pages : 41 Date : 2013-10-02 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-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-groupcomm-16 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 esko.dijk@philips.com Wed Oct 2 07:03:18 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE9F21F8E2D for ; Wed, 2 Oct 2013 07:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.533 X-Spam-Level: X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EP9GvdIzZ4L6 for ; Wed, 2 Oct 2013 07:03:06 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0184.outbound.messaging.microsoft.com [213.199.154.184]) by ietfa.amsl.com (Postfix) with ESMTP id 0D80221F84F8 for ; Wed, 2 Oct 2013 07:02:21 -0700 (PDT) Received: from mail176-db8-R.bigfish.com (10.174.8.232) by DB8EHSOBE036.bigfish.com (10.174.4.99) with Microsoft SMTP Server id 14.1.225.22; Wed, 2 Oct 2013 14:02:20 +0000 Received: from mail176-db8 (localhost [127.0.0.1]) by mail176-db8-R.bigfish.com (Postfix) with ESMTP id BDBB1D801B3; Wed, 2 Oct 2013 14:02:20 +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(zz217bI15d6O542I9251Idd85kzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h186068h8275dhz2dh2a8h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h1155h) Received: from mail176-db8 (localhost.localdomain [127.0.0.1]) by mail176-db8 (MessageSwitch) id 1380722537884416_13256; Wed, 2 Oct 2013 14:02:17 +0000 (UTC) Received: from DB8EHSMHS010.bigfish.com (unknown [10.174.8.248]) by mail176-db8.bigfish.com (Postfix) with ESMTP id C888816004B; Wed, 2 Oct 2013 14:02:17 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by DB8EHSMHS010.bigfish.com (10.174.4.20) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 2 Oct 2013 14:02:12 +0000 Received: from 011-DB3MPN2-081.MGDPHG.emi.philips.com ([169.254.1.172]) by 011-DB3MMR1-006.MGDPHG.emi.philips.com ([10.128.28.56]) with mapi id 14.03.0146.002; Wed, 2 Oct 2013 14:02:02 +0000 From: "Dijk, Esko" To: "Rahman, Akbar" , Carsten Bormann Thread-Topic: [core] Fw: New Version Notification fordraft-tcs-coap-no-response-option-02.txt Thread-Index: AQHOvgZLb2NT4y2bEEeUaqnlg5qRApnelHUAgAAMlICAAtFnkA== Date: Wed, 2 Oct 2013 14:02:01 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618016ED78E@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="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% X-FOPE-CONNECTOR: Id%0$Dn%INTERDIGITAL.COM$RO%1$TLS%0$FQDN%$TlsDn% Cc: Abhijan Bhattacharyya , Arpan Pal , "core@ietf.org" Subject: Re: [core] Fw: New Version Notification fordraft-tcs-coap-no-response-option-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 14:03:18 -0000 I would argue that also for doing updates, such as frequent event reports, = POST can be used with a "No Response" option. A POST does not necessarily lead to creation of a new resource. See core-coap 5.8.2. which mentions POST to update a target resource: " It = usually results in a new resource being created or the target resource bein= g updated." So I see the value of a "No Response" option much more in this case, rather= than in the resource creation case. Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Rah= man, Akbar Sent: Monday, September 30, 2013 20:55 To: Carsten Bormann Cc: Abhijan Bhattacharyya; Arpan Pal; core@ietf.org Subject: Re: [core] Fw: New Version Notification fordraft-tcs-coap-no-respo= nse-option-02.txt > There may still be applications where this is acceptable, e.g. if no further client access is required, or if the new resources are later picked= up by a different client that finds them using a collection resource. The = draft probably should give an example for this. Yes, I agree this is possible. I just got an impression from the existing = I-D examples that the "No Response" feature was mostly targeted towards hig= h frequency updates (i.e. PUT) for which a response was not required (to re= duce congestion, reduce BW usage, etc). But perhaps a new class of example= s showing how this would benefit POST can change this perception. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From cabo@tzi.org Wed Oct 2 13:30:58 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21BF621F8C0C for ; Wed, 2 Oct 2013 13:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvzH-3iIS-9Q for ; Wed, 2 Oct 2013 13:30:44 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id A07D121F84A8 for ; Wed, 2 Oct 2013 13:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r92KUBJH005262; Wed, 2 Oct 2013 22:30:11 +0200 (CEST) Received: from [192.168.217.105] (p54894EBD.dip0.t-ipconnect.de [84.137.78.189]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 01CF3651; Wed, 2 Oct 2013 22:30:10 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <5249A188.10200@pabigot.com> Date: Wed, 2 Oct 2013 22:30:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6949DD0D-41C9-4B95-AA49-63BC0567271A@tzi.org> References: <5244498E.3050202@pabigot.com> <52450F90.8020202@pabigot.com> <5245880B.2000601@pabigot.com> <52494000.8060104@pabigot.com> <5249A188.10200@pabigot.com> To: "Peter A. Bigot" X-Mailer: Apple Mail (2.1510) Cc: core , Klaus Hartke Subject: Re: [core] Comments on draft-ietf-core-observe-10 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 20:30:58 -0000 On Sep 30, 2013, at 18:06, "Peter A. Bigot" wrote: > My last comment: please make clear that when the steps in observe 4.5 = occur the message ID is (or is not) expected to be one of the things = that changes when the new transmission starts with the retransmission = state left over from the superseded transmission. That clarity is = absolutely lacking in the current draft for anybody who hasn't been = actively involved in observe over the last three years. The message ID is used for duplicate detection, so if you have new data = that you want a receiver to actually receive in addition to the old = data, you have to send the new data with a new message ID. (Note that = the message ID is different from the Observe Option value, which is also = a sequence number.) I think some of the confusion comes from the fact that a simple = canceling of a transmission sequence in progress is dangerous, if it = also simply clears the binary exponential backoff (BEBO) counter. This = means that a server could send unacknowledged notifications at a high = rate if the resource changes fast enough -- a recipe for congestion = overload. So one way to keep the request/response/notify layer separate from the = message layer is to implement cancel in such a way that the BEBO counter = is saved for the peer. A server that has a new value for the resource = can then simply cancel the transmission of the old one; if that was = never acknowledged, the new resource value will be transmitted at the = back-off rate. (An optimization where incoming acknowledgements for = canceled transmissions are still handled is left as an exercise for the = reader :-). Gr=FC=DFe, Carsten From matthias.thoma@sap.com Thu Oct 3 06:06:58 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0CDF21F98AC for ; Thu, 3 Oct 2013 06:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.648 X-Spam-Level: X-Spam-Status: No, score=-9.648 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OH+Ypkvw+MTp for ; Thu, 3 Oct 2013 06:06:31 -0700 (PDT) Received: from smtpgw.sap-ag.de (smtpgw01.sap-ag.de [155.56.66.96]) by ietfa.amsl.com (Postfix) with ESMTP id 582FB11E80D7 for ; Thu, 3 Oct 2013 06:03:02 -0700 (PDT) From: "Thoma, Matthias" To: "core@ietf.org" Thread-Topic: Question about Location and redirection Thread-Index: Ac7ANCZxMWlqK6EcRaK9AiBvEG4N/w== Date: Thu, 3 Oct 2013 13:02:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.40.39] Content-Type: multipart/alternative; boundary="_000_D1CA41DA3AC72045B3C52249FB3FC7CC3B77A74BDEWDFEMB15Aglob_" MIME-Version: 1.0 Subject: [core] Question about Location and redirection X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 Oct 2013 13:06:59 -0000 --_000_D1CA41DA3AC72045B3C52249FB3FC7CC3B77A74BDEWDFEMB15Aglob_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, I have been lurking on this mailing list for a while and also saw that in e= arlier days there were quite some discussions on redirection and location. = Nonetheless, I haven't been able to figure out what was the conclusion out = of this discussions. What I am looking for is a standards compliant way to tell a service consum= er that either the requested resource can be found somewhere else (like the= 3xx-family of response codes would allow me), or that it has has been crea= ted on a different coap endpoint (the location case). The (simplified) rational is that I have a system of cooperating objects, s= ome with different capabilities, but all speak CoAP. Now the objects have = to deliver some document as a result of a GET. Sometimes, it would now be p= referable to have this document stored on a CoAP node with higher storage c= apacities, so I would like to have this very constrained device reply with = a "yes, you can get that document, but you need to fetch it from here" in a= CoAP compliant way. Furthermore, the devices support getting historical data (like sensor value= s from the last month). These are also stored on a different node in the sy= stem for capacity reasons. Now a GET like get coap://nodeX:1000/data/jan201= 1 would answer, with something like "yes, you can get that data, but I do n= ot store that on my own persistent memory anymore, please get it from here = coap://nodeY:1000/nodeX/data/jan2011. For performance reasons, the nodeX sh= ould not get the data from nodeY first and then return it to the caller. I have similar use cases for POSTs where data is generated on a different n= ode in my network of cooperating devices. As far as I can see this use cases are not yet supported by CoAP at the mom= ent (please, correct me if I am wrong!) as neither the 3xx family known fro= m HTTP is supported nor non relative location options. In HTTP it wouldn't = be a problem to implement the use case. Is something like this possible at the moment without specifying my own app= lication layer protocol on top of CoAP, or by introducing custom response c= odes and thus being no longer standards compliant? Is supporting redirecti= on/non-relative location planned in any planned further version of CoAP? I = noticed, that the 3.xx response code family is reserved as well as some opt= ions for location. Nonetheless, this wouldn't be the first standard, where = things stay reserved forever :) Best, Matthias Thoma Matthias Thoma P&I BIT PA&TS SAP (Switzerland) Inc. | Althardstrasse 80 | 8105 Regensdorf | Switzerland Please consider to send me encrypted mail: http://keys.sap.com --_000_D1CA41DA3AC72045B3C52249FB3FC7CC3B77A74BDEWDFEMB15Aglob_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello all,

 

I have been lurking on this mai= ling list for a while and also saw that in earlier days there were quite so= me discussions on redirection and location. Nonetheless, I haven’t be= en able to figure out what was the conclusion out of this discussions.

 

What I am looking for is a stan= dards compliant way to tell a service consumer that either the requested re= source can be found somewhere else (like the 3xx-family of response codes w= ould allow me), or that it has has been created on a different coap endpoint (the location case).

 

The (simplified) rational is th= at I have a system of cooperating objects, some with different capabilities= , but all speak CoAP. Now  the objects have to deliver some document a= s a result of a GET. Sometimes, it would now be preferable to have this document stored on a CoAP node with higher = storage capacities, so I would like to have this very constrained device re= ply with a “yes, you can get that document, but you need to fetch it = from here” in a  CoAP  compliant way.

 

Furthermore, the devices suppor= t getting historical data (like sensor values from the last month). These a= re also stored on a different node in the system for capacity reasons. Now = a GET like get coap://nodeX:1000/data/jan2011 would answer, with something like “yes, you can get that data, but I= do not store that on my own persistent memory anymore, please get it from = here coap://nodeY:1000/nodeX/data/jan2011. For performance reasons, the nod= eX should not get the data from nodeY first and then return it to the caller.

 

I have similar use cases for PO= STs where data is generated on a different node in my network of cooperatin= g devices.

 

As far as I can see this use ca= ses are not yet supported by CoAP at the moment (please, correct me if I am= wrong!) as neither the 3xx family known from HTTP is supported nor non rel= ative location options. In HTTP it wouldn’t be a problem to implement the use case.

 

Is something like this possible= at the moment without specifying my own application layer protocol on top = of CoAP, or by introducing custom response codes and thus being no longer s= tandards compliant?  Is supporting redirection/non-relative location planned in any planned further version of CoAP? I noticed, that t= he 3.xx response code family is reserved as well as some options for locati= on. Nonetheless, this wouldn’t be the first standard, where things st= ay reserved forever J

 

Best,

  Matthias Thoma 

 

Matthias Thoma

P&I BIT PA&TS SAP (Switzerland) Inc. | Althardstrasse 80 | 8105 Regensdorf  | Switzerland

= Please consider to send me encrypted mail: http://keys.sap.com

--_000_D1CA41DA3AC72045B3C52249FB3FC7CC3B77A74BDEWDFEMB15Aglob_-- From cabo@tzi.org Thu Oct 3 08:16:16 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAA5121E8085 for ; Thu, 3 Oct 2013 08:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y61X-MdexG6c for ; Thu, 3 Oct 2013 08:16:04 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 4D17F11E812B for ; Thu, 3 Oct 2013 08:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r93F55HB009419; Thu, 3 Oct 2013 17:05:05 +0200 (CEST) Received: from [192.168.217.105] (p5489466A.dip0.t-ipconnect.de [84.137.70.106]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 21EFA77B; Thu, 3 Oct 2013 17:05:05 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: Date: Thu, 3 Oct 2013 17:05:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <666C7B91-B444-4872-9C30-5ACC5B71BC8F@tzi.org> References: To: "Thoma, Matthias" X-Mailer: Apple Mail (2.1510) Cc: "core@ietf.org" Subject: Re: [core] Question about Location and redirection X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 Oct 2013 15:16:16 -0000 Hi Matthias, On Oct 3, 2013, at 15:02, "Thoma, Matthias" = wrote: > As far as I can see this use cases are not yet supported by CoAP at = the moment (please, correct me if I am wrong!) as neither the 3xx family = known from HTTP is supported nor non relative location options. Indeed. While early drafts of CoAP did have some forms of redirection, = we found that the use cases most people had in mind did not call for = redirects. The main reason is that in a CoRE world, URIs are usually = found through a discovery process, and these URIs can be made to point = to the right place right away. > In HTTP it wouldn=92t be a problem to implement the use case. Right. HTTP has more support for a human user, who is likely to type a = URI and expect to arrive at the right document even if its real URI is = longer or points to somewhere else. We didn't have strong support for = making the protocol machine more complex to support redirection. We = also didn't want to have the security considerations. > Is something like this possible at the moment without specifying my = own application layer protocol on top of CoAP, Actually, it seems you already have your own little application layer = protocol here. How does the client arrive at coap://nodeX:1000/data/jan2011 without = some form of URI arithmetic? (If the server supplies the URI as in HATEOAS, it can already supply the = URI pointing to the final place.) > or by introducing custom response codes and thus being no longer = standards compliant? =20 That would probably be a way to do this that creates large integration = problems. A better way might be to define an "application/vnd-xxx.indirection" = media type that your constrained node can send back to point to the real = place. This could also provide some further application semantics if = needed (e.g., some form of authentication, if this needs to run in NoSec = mode). (It is easy to construct something like this from JSON or CBOR.) > Is supporting redirection/non-relative location planned in any planned = further version of CoAP? There are no plans. Should there be? Convince the WG! > I noticed, that the 3.xx response code family is reserved as well as = some options for location. Right, we didn't want to close the door to extensions of the protocol = state machine forever. However a strong objective remains to avoid baggage from HTTP that is = not really needed in the CoRE world. Gr=FC=DFe, Carsten From Akbar.Rahman@InterDigital.com Thu Oct 3 08:42:17 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32DA521F8FF5 for ; Thu, 3 Oct 2013 08:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, DRUGS_MUSCLE=0.01, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-zcegRlxRLn for ; Thu, 3 Oct 2013 08:42:06 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB0121E8082 for ; Thu, 3 Oct 2013 08:30:31 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Oct 2013 11:30:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CEC04D.7E38F95D" Date: Thu, 3 Oct 2013 11:30:29 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Fw: New Version Notification fordraft-tcs-coap-no-response-option-02.txt Thread-Index: Ac6+4/MZrSsW7HD4Sjml167jThxR7gBaNf2g References: , From: "Rahman, Akbar" To: "Abhijan Bhattacharyya" X-OriginalArrivalTime: 03 Oct 2013 15:30:30.0824 (UTC) FILETIME=[7E88EA80:01CEC04D] Cc: Arpan Pal , core@ietf.org Subject: Re: [core] Fw: New Version Notification fordraft-tcs-coap-no-response-option-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 15:42:17 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CEC04D.7E38F95D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Abhijan, =20 =20 Regarding your point =20 > Would the draft sound convincing for POST if we incorporate another example with the same scenario, and with similar request string as the above, but using CoAP?=20 =20 Yes, I think you should provide another example. Please also look at Esko's comment on POST (i.e. update vs new resource). Finally, it would be useful if you could have explicit guidance on using this option with the other methods (i.e. GET, DELETE). Unless you subscribe to Carsten's philosophy of leaving it "as an exercise for the reader" ... =20 =20 =20 Akbar =20 =20 From: Abhijan Bhattacharyya [mailto:abhijan.bhattacharyya@tcs.com]=20 Sent: Tuesday, October 01, 2013 4:22 PM To: Rahman, Akbar; Carsten Bormann Cc: Arpan Pal; core@ietf.org; Soma Bandyopadhyay Subject: RE: [core] Fw: New Version Notification fordraft-tcs-coap-no-response-option-02.txt =20 Hi Akbar & Carsten, First of all, thank you very much for your detail scrutiny of the draft. Let us address the comments one by one. =20 1) Regarding editorial issues: ------------------------- Yes, indeed there is deviation. Somehow it happened while submitting the initial version. Did not change the name in the next versions to avoid confusion as rightly pointed out by Carsten. =20 2) Regarding applicability of 'No-Resp' for POST --------------------------------------------- Yes, the draft should give an example regarding how No-Resp for POST can be useful. The cases where this option can be used with POST have already been put up in the discussion. In fact, the request/response example given in the draft (Figure 1) can also be performed using POST without changing any functionality. In that case each update will actually create a resource with the name-value pairs. Probably that might be useful for a real end-to-end implementation which would need to maintain a database of the updates.=20 Let me give a brief background here. This draft is actually a result of an effort to improve an existing HTTP based traffic monitoring system. In the HTTP case the clients actually 'POST' the updates in the form of name-value pair as new resources. The handler at the server extracts the values from the POST call and writes into the server. A typical RESTful request string, in the HTTP based solution, looks like: POST //insertInfo?VehId=3D0010&RouteId=3DDN47&Lat=3D12.8888&Long=3D88= .2222&t imeStamp=3D2013-08-03T15:55:07 =20 The 'insertInfo' string provides the handler at the server end. =20 Would the draft sound convincing for POST if we incorporate another example with the same scenario, and with similar request string as the above, but using CoAP?=20 =20 3) Regarding the semantics, etc. ----------------------------- We can change the 1 byte interpretation to keep the semantic integrity. In fact, I later realized that we should actually do that way if we strictly adhere to the definition of 'uint' in the CoAP specification (the value zero represented as empty to conserve bytes ). This can be done in no time. Basically we have to 'NOT' the table for 1 byte representation.=20 However, I need to get my understanding right regarding the concern raised by Carsten on "how a client implementation would handle a response ...... as it no longer knows whether a response is to be expected and when it can stop expecting one." I think it is a more generic question regarding the optional granularity feature. Opening up any given class of response means, the client has to wait up to the defined time-out period for all the requests. The client never knows whether the present request will be a success or a failure. Thus, if the client decides to open up the responses for errors (4.xx & 5.xx) then it has to wait for the entire time-out period even for the instances where the request is successful and the server is not supposed to send back a response. This may affect the performance in terms of time. But the advantage due to resource saving will still hold good. We can leave the use of the granularity feature on the application developer. Is my understanding correct? =20 =20 Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Limited Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D Notice: The information contained in this e-mail message and/or attachments to it may contain=20 confidential or privileged information. If you are=20 not the intended recipient, any dissemination, use,=20 review, distribution, printing or copying of the=20 information contained in this e-mail message=20 and/or attachments to it are strictly prohibited. If=20 you have received this communication in error,=20 please notify us by reply e-mail or telephone and=20 immediately and permanently delete the message=20 and any attachments. Thank you ------_=_NextPart_001_01CEC04D.7E38F95D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Abhijan,

 

 

Regarding your point

 

> Would = the draft sound convincing for POST if we incorporate another example = with the same scenario, and with similar request string as the above, = but using CoAP? 

 

Yes, I think you should provide another example.  Please also = look at Esko’s comment on POST (i.e. update vs new = resource).  Finally, it would be useful if you could have explicit = guidance on using this option with the other methods (i.e. GET, = DELETE).  Unless you subscribe to Carsten’s philosophy of = leaving it “as an exercise for the reader” = …

 

 

 

Akbar

 

 

From:= = Abhijan Bhattacharyya [mailto:abhijan.bhattacharyya@tcs.com] =
Sent: Tuesday, October 01, 2013 4:22 PM
To: Rahman, = Akbar; Carsten Bormann
Cc: Arpan Pal; core@ietf.org; Soma = Bandyopadhyay
Subject: RE: [core] Fw: New Version Notification = fordraft-tcs-coap-no-response-option-02.txt

 

Hi Akbar = & Carsten,

First of = all, thank you very much for your detail scrutiny of the draft. =  Let us address the comments one by = one.

 =

1) = Regarding editorial issues:

  =  -------------------------

Yes, = indeed there is deviation. Somehow it happened while submitting the = initial version. Did not change the name in the next versions to avoid = confusion as rightly pointed out by = Carsten.

 =

2) = Regarding applicability of 'No-Resp' for = POST

  =  ---------------------------------------------

=

Yes, the = draft should give an example regarding how No-Resp for POST can be = useful. The cases where this option can be used with POST have already = been put up in the discussion. In fact, the request/response example = given in the draft (Figure 1) can also be performed using POST without = changing any functionality. In that case each update will actually = create a resource with the name-value pairs. Probably that might be = useful for a real end-to-end implementation which would need to maintain = a database of the updates. 

Let me = give a brief background here. This draft is actually a result of an = effort to improve an existing HTTP based traffic monitoring system. In = the HTTP case the clients actually 'POST' the updates in the form of = name-value pair as new resources. The handler at the server extracts the = values from the POST call and writes into the server. A typical RESTful = request string, in the HTTP based solution, looks = like:

POST = /<BaseUrl>/insertInfo?VehId=3D0010&RouteId=3DDN47&Lat=3D12.= 8888&Long=3D88.2222&timeStamp=3D2013-08-03T15:55:07

 =

The = 'insertInfo' string provides the handler at the server = end.

 =

Would the = draft sound convincing for POST if we incorporate another example with = the same scenario, and with similar request string as the above, but = using CoAP? 

 =

3) = Regarding the semantics, etc.

  =  -----------------------------

We can = change the 1 byte interpretation to keep the semantic integrity. In = fact, I later realized that we should actually do that way if we = strictly adhere to the definition of 'uint' in the CoAP specification = (the value zero represented as empty to conserve bytes ). This can be = done in no time. Basically we have to 'NOT' the table for 1 byte = representation. 

However, I = need to get my understanding right regarding the concern raised by = Carsten on "how a client implementation would handle a response = ...... as it no longer knows whether a response is to be expected and = when it can stop expecting one." I think it is a more generic = question regarding the optional granularity feature. Opening up any = given class of response means, the client has to wait up to the defined = time-out period for all the requests. The client never knows whether the = present request will be a success or a failure. Thus, if the client = decides to open up the responses for errors (4.xx & 5.xx) then it = has to wait for the entire time-out period even for the instances where = the request is successful and the server is not supposed to send back a = response. This may affect the performance in terms of time. But the = advantage due to resource saving will still hold good. We can leave the = use of the granularity feature on the application developer. Is my = understanding correct?  

 =

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

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

------_=_NextPart_001_01CEC04D.7E38F95D-- From matthias.thoma@sap.com Thu Oct 3 10:41:22 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C25A911E8129 for ; Thu, 3 Oct 2013 10:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.948 X-Spam-Level: X-Spam-Status: No, score=-9.948 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lE4efhatk4VE for ; Thu, 3 Oct 2013 10:41:09 -0700 (PDT) Received: from smtpgw.sap-ag.de (smtpgw02.sap-ag.de [155.56.66.97]) by ietfa.amsl.com (Postfix) with ESMTP id 6C02011E8130 for ; Thu, 3 Oct 2013 10:23:20 -0700 (PDT) From: "Thoma, Matthias" To: Carsten Bormann Thread-Topic: [core] Question about Location and redirection Thread-Index: Ac7ANCZxMWlqK6EcRaK9AiBvEG4N/wABQXmAAAaye8A= Date: Thu, 3 Oct 2013 17:23:11 +0000 Message-ID: References: <666C7B91-B444-4872-9C30-5ACC5B71BC8F@tzi.org> In-Reply-To: <666C7B91-B444-4872-9C30-5ACC5B71BC8F@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.40.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "core@ietf.org" Subject: Re: [core] Question about Location and redirection X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 Oct 2013 17:41:22 -0000 Hello Carsten, > Indeed. While early drafts of CoAP did have some forms of redirection, w= e found that the use cases most people had in mind did not call for redirec= ts. The > main reason is that in a CoRE world, URIs are usually found thro= ugh a discovery process, and these URIs can be made to point to the right p= lace right away. Agreed, but with a but: Especially, in CoRE world I believe an "out of reso= urce" situation and changes of resources after discovery is something that = is not that out of scope. With regard to the redirection I currently have t= o have a very data-centric view (interacting with data on constrained devic= es via RESTful interfaces). I agree that it is not needed if "just" conside= r "simple" temperature sensors without storage or home automation actors, b= ut with some data collection in mind some questions pop up: (1) Going the plain discovery approach and assuming that resources can be m= oved (like the historical data in my example). How should I tell the user (= does not need to be a human user) that a resource he maybe just discovered = seconds ago is no longer available here, but is somewhere else and he needs= to rediscover? None of the existing response codes seems to really fit in = such a dynamic scenario. Of course, I can encode that information in the pa= yload of one of the responses, but that hurts interoperability as well.=20 (2) Clean API and semantics. Semantically speaking, I want to have the data= from a nodeX, and asking something like nodeX/data/02102013 enables a clea= n API design and eases discovery (discovery just could return nodeX is a Se= nsorDeviceWithStorage). In maybe 95% of all cases the node might be able t= o return the data itself, but it would be nice to also support the remainin= g 5%. The problem of where to store information in an out of resource situa= tion is now on the side of the application itself. Following a rediscovery = approach the complexity on the caller side increases and more complex disco= very mechanisms are needed.=20 > > In HTTP it wouldn't be a problem to implement the use case. > > Right. HTTP has more support for a human user, who is likely to type a U= RI and expect to arrive at the right document even if its real URI is longe= r or points > to somewhere else. =20 As you might have seen, I did not have had a human user in mind. What I was= looking for, was a way that an arbitrary COAP client can ask for resource= s on my nodes, even if it had to be moved to somewhere else because the dev= ice is too constrained and any CoAP client would be able to bring you to th= e right place immediately...=20 > > Is something like this possible at the moment without specifying my own= application layer protocol on top of CoAP, > > Actually, it seems you already have your own little application layer pro= tocol here. > How does the client arrive at coap://nodeX:1000/data/jan2011 without some= form of URI arithmetic? The Uniform Resource Identifiers (URIs) are defined in a data model. The no= des provide as part of their discovery process standard resource (like temp= erature) and URI construction rules for data-centric access. With very very= constrained nodes even this documents do not fit on the node. Kind of a pr= oblem similar to what to do when ".well-known/core" cannot be provided by t= he note (or only that and nothing else). This is an exceptional border case= though. > > or by introducing custom response codes and thus being no longer standa= rds compliant? =20 > > That would probably be a way to do this that creates large integration pr= oblems. > > > A better way might be to define an "application/vnd-xxx.indirection" medi= a type that your constrained node can send back to point to the real place.= This > could also provide some further application semantics if needed (e= .g., some form of authentication, if this needs to run in NoSec mode). > (It is easy to construct something like this from JSON or CBOR.) Sure, on the application layer there are many options to deal with my speci= fic use case. I just hoped to find something that works with any CoAP clien= t just out-of-the-box, kind of do a GET and the URI and get the JSON result= with or without any redirection. Nonetheless, I will explore application l= evel options a little bit further then. Just wanted to be really sure, that= CoAP does not have something built-in... Best, Matthias=20 From prvs=9829a79c6=abhijan.bhattacharyya@tcs.com Thu Oct 3 23:21:21 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A837321F89F7 for ; Thu, 3 Oct 2013 23:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.694 X-Spam-Level: X-Spam-Status: No, score=-4.694 tagged_above=-999 required=5 tests=[AWL=0.694, BAYES_00=-2.599, DRUGS_MUSCLE=0.01, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, J_CHICKENPOX_71=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWkPEmkifHVZ for ; Thu, 3 Oct 2013 23:21:07 -0700 (PDT) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id AFC9421F9767 for ; Thu, 3 Oct 2013 23:21:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,1031,1371061800"; d="scan'208";a="456452198" X-DISCLAIMER: FALSE Received: from INKOLSALDLPMTA1.india.tcs.com (unknown [127.0.0.1]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id CD6A1DAC12; Fri, 4 Oct 2013 11:50:34 +0530 (IST) Received: from InKolM02.tcs.com (unknown [172.18.18.104]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id 98DDADAC02; Fri, 4 Oct 2013 11:50:34 +0530 (IST) In-Reply-To: References: , To: "Rahman, Akbar" MIME-Version: 1.0 X-KeepSent: CDB4AC68:35297318-65257BFA:00225804; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: Abhijan Bhattacharyya Message-ID: Date: Fri, 4 Oct 2013 11:50:33 +0530 X-MIMETrack: Serialize by Notes Server on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 10/04/2013 11:50:33, Serialize complete at 10/04/2013 11:50:33, Serialize by Router on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 10/04/2013 11:50:34, Serialize complete at 10/04/2013 11:50:34 Content-Type: multipart/alternative; boundary="=_alternative 0022CE5965257BFA_=" Cc: Arpan Pal , core@ietf.org Subject: Re: [core] Fw: New Version Notification fordraft-tcs-coap-no-response-option-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 06:21:21 -0000 This is a multipart message in MIME format. --=_alternative 0022CE5965257BFA_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi Akbar, Sure! We are tracking all the value adding inputs very closely. The=20 accumulated inputs blended with our understanding will be reflected in the = next version of the draft which we are going to upload soon. Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Limited Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Experience certainty. IT Services Business Solutions Consulting =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F From: "Rahman, Akbar" To: "Abhijan Bhattacharyya" Cc: "Arpan Pal" , , "Soma Bandyopadhyay"=20 , "Carsten Bormann" Date: 10/03/2013 09:00 PM Subject: RE: [core] Fw: New Version Notification=20 fordraft-tcs-coap-no-response-option-02.txt Hi Abhijan, =20 =20 Regarding your point =20 > Would the draft sound convincing for POST if we incorporate another=20 example with the same scenario, and with similar request string as the=20 above, but using CoAP?=20 =20 Yes, I think you should provide another example. Please also look at=20 Esko?s comment on POST (i.e. update vs new resource). Finally, it would=20 be useful if you could have explicit guidance on using this option with=20 the other methods (i.e. GET, DELETE). Unless you subscribe to Carsten?s=20 philosophy of leaving it ?as an exercise for the reader? ? =20 =20 =20 Akbar =20 =20 From: Abhijan Bhattacharyya [mailto:abhijan.bhattacharyya@tcs.com]=20 Sent: Tuesday, October 01, 2013 4:22 PM To: Rahman, Akbar; Carsten Bormann Cc: Arpan Pal; core@ietf.org; Soma Bandyopadhyay Subject: RE: [core] Fw: New Version Notification=20 fordraft-tcs-coap-no-response-option-02.txt =20 Hi Akbar & Carsten, First of all, thank you very much for your detail scrutiny of the draft.=20 Let us address the comments one by one. =20 1) Regarding editorial issues: ------------------------- Yes, indeed there is deviation. Somehow it happened while submitting the=20 initial version. Did not change the name in the next versions to avoid=20 confusion as rightly pointed out by Carsten. =20 2) Regarding applicability of 'No-Resp' for POST --------------------------------------------- Yes, the draft should give an example regarding how No-Resp for POST can=20 be useful. The cases where this option can be used with POST have already=20 been put up in the discussion. In fact, the request/response example given = in the draft (Figure 1) can also be performed using POST without changing=20 any functionality. In that case each update will actually create a=20 resource with the name-value pairs. Probably that might be useful for a=20 real end-to-end implementation which would need to maintain a database of=20 the updates.=20 Let me give a brief background here. This draft is actually a result of an = effort to improve an existing HTTP based traffic monitoring system. In the = HTTP case the clients actually 'POST' the updates in the form of=20 name-value pair as new resources. The handler at the server extracts the=20 values from the POST call and writes into the server. A typical RESTful=20 request string, in the HTTP based solution, looks like: POST=20 //insertInfo?VehId=3D0010&RouteId=3DDN47&Lat=3D12.8888&Long=3D88.2= 222&timeStamp=3D2013-08-03T15:55:07 =20 The 'insertInfo' string provides the handler at the server end. =20 Would the draft sound convincing for POST if we incorporate another=20 example with the same scenario, and with similar request string as the=20 above, but using CoAP?=20 =20 3) Regarding the semantics, etc. ----------------------------- We can change the 1 byte interpretation to keep the semantic integrity. In = fact, I later realized that we should actually do that way if we strictly=20 adhere to the definition of 'uint' in the CoAP specification (the value=20 zero represented as empty to conserve bytes ). This can be done in no=20 time. Basically we have to 'NOT' the table for 1 byte representation.=20 However, I need to get my understanding right regarding the concern raised = by Carsten on "how a client implementation would handle a response ......=20 as it no longer knows whether a response is to be expected and when it can = stop expecting one." I think it is a more generic question regarding the=20 optional granularity feature. Opening up any given class of response=20 means, the client has to wait up to the defined time-out period for all=20 the requests. The client never knows whether the present request will be a = success or a failure. Thus, if the client decides to open up the responses = for errors (4.xx & 5.xx) then it has to wait for the entire time-out=20 period even for the instances where the request is successful and the=20 server is not supposed to send back a response. This may affect the=20 performance in terms of time. But the advantage due to resource saving=20 will still hold good. We can leave the use of the granularity feature on=20 the application developer. Is my understanding correct?=20 =20 Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Limited Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Experience certainty. IT Services Business Solutions Consulting =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D Notice: The information contained in this e-mail message and/or attachments to it may contain=20 confidential or privileged information. If you are=20 not the intended recipient, any dissemination, use,=20 review, distribution, printing or copying of the=20 information contained in this e-mail message=20 and/or attachments to it are strictly prohibited. If=20 you have received this communication in error,=20 please notify us by reply e-mail or telephone and=20 immediately and permanently delete the message=20 and any attachments. Thank you --=_alternative 0022CE5965257BFA_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi Akbar,
Sure! We are tracking all the value adding inputs very closely. The accumulated inputs blended with our underst= anding will be reflected in the next version of the draft which we are going to upload soon.

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


From: "Rahman, Akbar" <Akbar.= Rahman@InterDigital.com>
To: "Abhijan Bhattacharyya" &l= t;abhijan.bhattacharyya@tcs.com>
Cc: "Arpan Pal" <arpan.pal@= tcs.com>, <core@ietf.org>, "Soma Bandyopadhyay" <soma.bandyopadhya= y@tcs.com>, "Carsten Bormann" <cabo@tzi.org>
Date: 10/03/2013 09:00 PM
Subject: RE: [core] Fw: New Version Notificat= ion fordraft-tcs-coap-no-response-option-02.txt




Hi Abhijan,
 
 
Regarding your point
 
> Would the draft sound convincing f= or POST if we incorporate another example with the same scenario, and with similar request string as the above, but using CoAP?
 
Yes, I think you should= provide another example.  Please also look at Esko’s comment on POST (i.= e. update vs new resource).  Finally, it would be useful if you could have explicit guidance on using this option with the other methods (i.e. GET, DELETE).  Unless you subscribe to Carsten’s philosophy of l= eaving it “as an exercise for the reader” …
 
 
 
Akbar
 
 
From: Abhijan Bhattacharyya [mailto:abhijan.bhattacharyya@tcs.com]
Sent: Tuesday, October 01, 2013 4:22 PM
To: Rahman, Akbar; Carsten Bormann
Cc: Arpan Pal; core@ietf.org; Soma Bandyopadhyay
Subject: RE: [core] Fw: New Version Notification fordraft-tcs-coap-no-r= esponse-option-02.txt
 
Hi Akbar & Carsten,
First of all, thank you very much for y= our detail scrutiny of the draft.  Let us address the comments one by one.
 
1) Regarding editorial issues:
   -------------------------<= /font>
Yes, indeed there is deviation. Somehow it happened while submitting the initial version. Did not change the name in the next versions to avoid confusion as rightly pointed out by Carsten.<= /font>
 
2) Regarding applicability of 'No-Resp' for POST
   --------------------------= -------------------
Yes, the draft should give an example r= egarding how No-Resp for POST can be useful. The cases where this option can be used with POST have already been put up in the discussion. In fact, the request/response example given in the draft (Figure 1) can also be performed using POST without changing any functionality. In that case each update will actually create a resource with the name-value pairs. Probably that might be useful for a real end-to-end implementation which would need to maintain a database of the updates.
Let me give a brief background here. Th= is draft is actually a result of an effort to improve an existing HTTP based traffic monitoring system. In the HTTP case the clients actually 'POST' the updates in the form of name-value pair as new resources. The handler at the server extracts the values from the POST call and writes into the server. A typical RESTful request string, in the HTTP based solution, looks like:
POST /<BaseUrl>/insertInfo?VehId= =3D0010&RouteId=3DDN47&Lat=3D12.8888&Long=3D88.2222&timeSta= mp=3D2013-08-03T15:55:07
 
The 'insertInfo' string provides the ha= ndler at the server end.
 
Would the draft sound convincing for PO= ST if we incorporate another example with the same scenario, and with similar request string as the above, but using CoAP?
 
3) Regarding the semantics, etc.
   --------------------------= ---
We can change the 1 byte interpretation to keep the semantic integrity. In fact, I later realized that we should actually do that way if we strictly adhere to the definition of 'uint' in the CoAP specification (the value zero represented as empty to conserve bytes ). This can be done in no time. Basically we have to 'NOT' the table for 1 byte representation.
However, I need to get my understanding right regarding the concern raised by Carsten on "how a client impleme= ntation would handle a response ...... as it no longer knows whether a response is to be expected and when it can stop expecting one." I think it is a more generic question regarding the optional granularity feature. Opening up any given class of response means, the client has to wait up to the defined time-out period for all the requests. The client never knows whether the present request will be a success or a failure. Thus, if the client decides to open up the responses for errors (4.xx & 5.xx) then it has to wait for the entire time-out period even for the instances where the request is successful and the server is not supposed to send back a response. This may affect the performance in terms of time. But the advanta= ge due to resource saving will still hold good. We can leave the use of the granularity feature on the application developer. Is my understanding corre= ct?  
 
Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services Limited
Mailto: abhijan.bhattacharyya@tcs.com=
Website: http://www.tcs.com
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Experience certainty. IT Services
Business Solutions
Consulting
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F

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

--=_alternative 0022CE5965257BFA_=-- From pab@pabigot.com Fri Oct 4 12:39:57 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 261A821F9DF1 for ; Fri, 4 Oct 2013 12:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8sqgBySaxHib for ; Fri, 4 Oct 2013 12:39:50 -0700 (PDT) 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 1C61521F9DD0 for ; Fri, 4 Oct 2013 12:39:48 -0700 (PDT) Received: from [192.168.65.10] ([66.41.60.82]) by m1plsmtpa01-01.prod.mesa1.secureserver.net with id Z7fY1m00M1mTNtu017fZfj; Fri, 04 Oct 2013 12:39:48 -0700 Message-ID: <524F1978.4080607@pabigot.com> Date: Fri, 04 Oct 2013 14:39:36 -0500 From: "Peter A. Bigot" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Carsten Bormann References: <5244498E.3050202@pabigot.com> <52450F90.8020202@pabigot.com> <5245880B.2000601@pabigot.com> <52494000.8060104@pabigot.com> <5249A188.10200@pabigot.com> <6949DD0D-41C9-4B95-AA49-63BC0567271A@tzi.org> In-Reply-To: <6949DD0D-41C9-4B95-AA49-63BC0567271A@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: core , Klaus Hartke Subject: Re: [core] Comments on draft-ietf-core-observe-10 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 19:39:57 -0000 On 10/02/2013 03:30 PM, Carsten Bormann wrote: > On Sep 30, 2013, at 18:06, "Peter A. Bigot" wrote: > >> My last comment: please make clear that when the steps in observe >> 4.5 occur the message ID is (or is not) expected to be one of the >> things that changes when the new transmission starts with the >> retransmission state left over from the superseded transmission. >> That clarity is absolutely lacking in the current draft for anybody >> who hasn't been actively involved in observe over the last three >> years. > > The message ID is used for duplicate detection, so if you have new > data that you want a receiver to actually receive in addition to the > old data, you have to send the new data with a new message ID. (Note > that the message ID is different from the Observe Option value, which > is also a sequence number.) Yes, as I've made progress in the new CoAPy that was the obvious right choice though it had not been clear in the description or the discussion. > > I think some of the confusion comes from the fact that a simple > canceling of a transmission sequence in progress is dangerous, if it > also simply clears the binary exponential backoff (BEBO) counter. > This means that a server could send unacknowledged notifications at a > high rate if the resource changes fast enough -- a recipe for > congestion overload. Yes; though this requirement is independent of observe's technique of superseding a partially-completed transmission with a new message. coap-18 4.2 permits a server to cancel remaining retransmissions of a confirmable message. I believe the intent of 4.2 and 4.7 is that the cancelled message remains technically outstanding and thus blocks further transmissions as constrained by NSTART unless there is evidence that the destination endpoint received the message. > > So one way to keep the request/response/notify layer separate from > the message layer is to implement cancel in such a way that the BEBO > counter is saved for the peer. A server that has a new value for the > resource can then simply cancel the transmission of the old one; if > that was never acknowledged, the new resource value will be > transmitted at the back-off rate. And this I think is still a mistake. For observe, where we don't really care if the message gets through, I suppose you can do this as an optimization. But what happens if the new message uses the last two of five total transmissions, and isn't acknowledged? Is something allowed to detect this, and use part of the next BEBO cycle to give that message the total number of transmissions it warrants? What if the next message for the destination endpoint isn't even an observe notification, but another confirmable message queued for the same endpoint before the resource changed and observe chose to supersede the current one? Madness lies in this direction. > (An optimization where incoming > acknowledgements for canceled transmissions are still handled is left > as an exercise for the reader :-). Well, you have to handle that anyway, so it's not a big deal. Peter From pab@pabigot.com Fri Oct 4 16:18:48 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9621921F9DFA for ; Fri, 4 Oct 2013 16:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xoScLk+lt0VI for ; Fri, 4 Oct 2013 16:18:42 -0700 (PDT) Received: from m1plsmtpa01-06.prod.mesa1.secureserver.net (m1plsmtpa01-06.prod.mesa1.secureserver.net [64.202.165.34]) by ietfa.amsl.com (Postfix) with ESMTP id 06A2021F9DF6 for ; Fri, 4 Oct 2013 16:18:39 -0700 (PDT) Received: from [192.168.65.10] ([66.41.60.82]) by m1plsmtpa01-06.prod.mesa1.secureserver.net with id ZBJe1m0061mTNtu01BJeBN; Fri, 04 Oct 2013 16:18:39 -0700 Message-ID: <524F4CD1.9080402@pabigot.com> Date: Fri, 04 Oct 2013 18:18:41 -0500 From: "Peter A. Bigot" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: core Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [core] Option method/response validation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 23:18:48 -0000 Section 5.4 of coap-18 has: Not all options are defined for use with all methods and response codes. The possible options for methods and response codes are defined in Section 5.8 and Section 5.9 respectively. In case an option is not defined for a method or response code, it MUST NOT be included by a sender and MUST be treated like an unrecognized option by a recipient. The use of MUST (NOT) here is a strong (technically "absolute") requirement, but I'm not finding much guidance from 5.8 and 5.9 regarding which options are defined for which methods and response codes. This makes meeting the requirement difficult. Any comments on the following tentative conclusions? If-Match and If-None-Match are permitted for PUT by 5.8.3, but not mentioned in other request methods. I don't think they make sense for GET; I can imagine a use for POST; and If-Match (but not If-None-Match) certainly makes sense for DELETE. Disallow for GET, allow all others except If-None-Match for DELETE is disallowed. Uri-Host, Uri-Port, Uri-Path, and Uri-Query may appear in any request, and in no responses. Location-Path and Location-Query may only appear in 2.01 Created responses. Content-Format is explicitly allowed only for 0.03 PUT. It is implicitly allowed for 0.02 POST requests and 2.xx Success responses except for 2.03 ValidContent because these codes mention a representation in the payload and 5.5.1 says Content-Format applies to resource and action result payloads. 5.5.2 implies it must not appear for a diagnostic payload, therefore cannot appear in 4.xx or 5.xx error responses. Accept can appear only in 0.01 GET requests. But the other methods all have valid responses that can contain non-diagnostic content, so maybe it's ok for them too? These options cannot appear (except as unrecognized) in any request: Location-Path, Max-Age, Location-Query, Size1 (unless block is supported) These options cannot appear (except as unrecognized) in any response: If-Match, Uri-Host, If-None-Match, Uri-Port, Uri-Path, Uri-Query, Accept, Proxy-Uri, Proxy-Scheme I'd appreciate feedback if these conclusions are thought to be wrong, as well as insight on how much people expect extensions to be allowed to change the restrictions for existing options (as Size1 would be permitted in (some?) requests under draft-ietf-core-block-12). As an example, I'd love to be able to put Uri-* in a future response related to redirection, even though default Uri-Host and Uri-Post values would have to be defined for response use in terms of the source endpoint. Peter From tho@koanlogic.com Sat Oct 5 00:53:24 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82A3721F9A43 for ; Sat, 5 Oct 2013 00:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D978F58rWEBQ for ; Sat, 5 Oct 2013 00:53:18 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by ietfa.amsl.com (Postfix) with ESMTP id 364C721F9346 for ; Sat, 5 Oct 2013 00:53:17 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id o14so4092311lbi.32 for ; Sat, 05 Oct 2013 00:53:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Ueo6WN8gW0mfoKPlNg2QhoWsBTqs4OFk3ZNwaE2nNjc=; b=arOVjz4h11a/7iWIbuDqVnm7hpZufziX7QOqAZIESWdtJXmWRkpw2IzHkuZ3JkKjpV PQYtv7YzKwnp/SOS7F20gaKe7Rc17rjXCSOCuqiPAgp3dwJ3SgkRrYOk+8KtJnpRsmsT DoE6YSyfPkan5I56Y4evREdCG5yk/XF/XvejxEQ/wYk6VDdGNaxJTBj2m3AxaeamfGRN AHKyLroFKNe360gJpVbNmAq/vMfmhZMQYRgnHXxI7DTHmvnFFDPzFvLJs0EvlCrpGa/P ol6GFeKVuFjFiy/CYLfcGr2CSgVE1HDeWQ0UVxXDG2zVrXN2n+KOUtgAT0oyPtoew0LI 8gwQ== X-Gm-Message-State: ALoCoQlSH9fMdLx57sfFf3xzd6VIDaeLNKYW/srDkZxm1rRUelBn5QxI8W9Ck0nxlQV9kQtNr58M MIME-Version: 1.0 X-Received: by 10.112.51.101 with SMTP id j5mr15155142lbo.17.1380959596927; Sat, 05 Oct 2013 00:53:16 -0700 (PDT) Received: by 10.114.21.4 with HTTP; Sat, 5 Oct 2013 00:53:16 -0700 (PDT) X-Originating-IP: [92.20.236.53] In-Reply-To: <524F4CD1.9080402@pabigot.com> References: <524F4CD1.9080402@pabigot.com> Date: Sat, 5 Oct 2013 08:53:16 +0100 Message-ID: From: Thomas Fossati To: "Peter A. Bigot" Content-Type: text/plain; charset=ISO-8859-1 Cc: core Subject: Re: [core] Option method/response validation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2013 07:53:24 -0000 Hi Peter, On Sat, Oct 5, 2013 at 12:18 AM, Peter A. Bigot wrote: > If-Match and If-None-Match are permitted for PUT by 5.8.3, but not > mentioned in other request methods. I don't think they make sense for > GET; one possible use for GET+If-None-Match is to implement a sort of HEAD: if the server has the requested resource, then it could respond 2.03 with the Etag'ed representation metadata? From hartke@tzi.org Sat Oct 5 02:28:54 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF2AA21F9B58 for ; Sat, 5 Oct 2013 02:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruuAlvBAZo8A for ; Sat, 5 Oct 2013 02:28:48 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id AB2E121F9B21 for ; Sat, 5 Oct 2013 02:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r959ScxE000395 for ; Sat, 5 Oct 2013 11:28:38 +0200 (CEST) Received: from mail-ve0-f180.google.com (mail-ve0-f180.google.com [209.85.128.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 8220BC25 for ; Sat, 5 Oct 2013 11:28:38 +0200 (CEST) Received: by mail-ve0-f180.google.com with SMTP id jz11so2853494veb.39 for ; Sat, 05 Oct 2013 02:28:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=oem0/2/kpSFEdTzqbe28Rvqoh5y8PnI7Rgxb5rFNBtE=; b=NEkP/yAgFNy3Px8kmx5asXXD6AHTyiH/ymJ65kZAugP6C9O4jSVXaW9g9WW0dZyUvI QRfBcSZUjghtgkVQnMLDruiHh0TR9F5pVNQ3HDdJqe18YYcgkrhLRxfxjda9jXkiDiC6 LhZAdRvJXsS2ZvzqVTmr3ulkg5ymYRG0bael6J6Uq68YXLMLEqWJb2VCplQ2f+AGoEfh GLsjvCFvnUVuSRmhimCjYCp8BEXsiH2vCFyK+O4aQe2QOv1egNFFAdwJnxQrul5Y0Xe5 fG+DzivA7C2dA7mo90esCkGCYNPyWHGVfozuq+LjFbT/0Yy+4TWw5zbDRQ1+MxFIyscy hgIg== X-Received: by 10.52.75.228 with SMTP id f4mr13208997vdw.6.1380965317046; Sat, 05 Oct 2013 02:28:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.24.83 with HTTP; Sat, 5 Oct 2013 02:27:56 -0700 (PDT) In-Reply-To: References: <666C7B91-B444-4872-9C30-5ACC5B71BC8F@tzi.org> From: Klaus Hartke Date: Sat, 5 Oct 2013 12:27:56 +0300 Message-ID: To: "Thoma, Matthias" Content-Type: text/plain; charset=ISO-8859-1 Cc: "core@ietf.org" Subject: Re: [core] Question about Location and redirection X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2013 09:28:54 -0000 Matthias Thoma wrote: > Just wanted to be really sure, that CoAP does not have something built-in... As Carsten said, there are no plans at this time. But the 3.xx family of response codes has indeed been reserved for this purpose, and there are some option numbers reserved to express locations on a different CoAP endpoint or non-CoAP resources. To validate the reservations, I wrote a small specification for myself some time ago and also added it experimentally to my CoAP implementation. If there is enough interest in the working group, I could quickly turn it into a draft. Best regards, Klaus From pab@pabigot.com Sat Oct 5 05:20:40 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38A3521F9CC7 for ; Sat, 5 Oct 2013 05:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlAP6QCJgt5e for ; Sat, 5 Oct 2013 05:20:34 -0700 (PDT) Received: from m1plsmtpa01-05.prod.mesa1.secureserver.net (m1plsmtpa01-05.prod.mesa1.secureserver.net [64.202.165.10]) by ietfa.amsl.com (Postfix) with ESMTP id 1D32421F9CDA for ; Sat, 5 Oct 2013 05:20:33 -0700 (PDT) Received: from [192.168.65.10] ([66.41.60.82]) by m1plsmtpa01-05.prod.mesa1.secureserver.net with id ZQLU1m00S1mTNtu01QLVfF; Sat, 05 Oct 2013 05:20:30 -0700 Message-ID: <52500410.403@pabigot.com> Date: Sat, 05 Oct 2013 07:20:32 -0500 From: "Peter A. Bigot" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Thomas Fossati References: <524F4CD1.9080402@pabigot.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: core Subject: Re: [core] Option method/response validation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2013 12:20:40 -0000 On 10/05/2013 02:53 AM, Thomas Fossati wrote: > Hi Peter, > > On Sat, Oct 5, 2013 at 12:18 AM, Peter A. Bigot wrote: >> If-Match and If-None-Match are permitted for PUT by 5.8.3, but not >> mentioned in other request methods. I don't think they make sense for >> GET; > > one possible use for GET+If-None-Match is to implement a sort of HEAD: > if the server has the requested resource, then it could respond 2.03 > with the Etag'ed representation metadata? I think this would change conditional request too much. If-None-Match succeeds only if the resource has no representation (interpreted to mean it does not exist on the server), so an unconditional GET would return 4.04 Not Found. 5.10.8 says this means the If-None-Match may be ignored in this case. If-Match with an empty string would match any representation, so is a test for existence of the resource. The current representation might not even have an entity-tag; and if it does there's no reasonable way for a client to ask what an arbitrary entity-tag represents, so the server could only return 2.03 Valid if the request included the ETag to tell the server it knew about that particular representation. But then this is functionally equivalent to an unconditional GET. However: DELETE with If-None-Match would return 4.12 Precondition Failed if the resource existed (as opposed to 2.05 Deleted or an authorization error if the conditional option was absent), and 4.04 Not Found if it didn't, so that actually already is a sort of HEAD low-cost probe for existence without returning the representation. (Unless the server may check for authorization data first and return 4.03 Forbidden even if the resource doesn't exist, which case you can't tell anything from the result.) Interesting. Peter From cabo@tzi.org Sat Oct 5 07:20:56 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9DB321F84A8 for ; Sat, 5 Oct 2013 07:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJEGx6XRlQpt for ; Sat, 5 Oct 2013 07:20:50 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF1621F8EA8 for ; Sat, 5 Oct 2013 07:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r95EKdXE022951; Sat, 5 Oct 2013 16:20:39 +0200 (CEST) Received: from [192.168.217.105] (p54892064.dip0.t-ipconnect.de [84.137.32.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 527BEC75; Sat, 5 Oct 2013 16:20:39 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <524F4CD1.9080402@pabigot.com> Date: Sat, 5 Oct 2013 16:20:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <53B33ABC-821C-4D27-A4B7-FD100A2745C1@tzi.org> References: <524F4CD1.9080402@pabigot.com> To: "Peter A. Bigot" X-Mailer: Apple Mail (2.1510) Cc: core Subject: Re: [core] Option method/response validation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2013 14:20:56 -0000 > If-Match and If-None-Match are permitted for PUT by 5.8.3, but not > mentioned in other request methods. I don't think they make sense for > GET; I can imagine a use for POST; and If-Match (but not = If-None-Match) > certainly makes sense for DELETE. Disallow for GET, allow all others > except If-None-Match for DELETE is disallowed. I read the mention in 5.8.3 as a helpful pointer, not as Expressio unius = est exclusio alterius. 5.10.8 makes no attempt at restricting these options to specific = methods. (5.10.8.2 mentions some combinations are "not very useful", but doesn't = attempt to rule them out.) > Uri-Host, Uri-Port, Uri-Path, and Uri-Query may appear in any request, > and in no responses. Indeed. (They MUST NOT be included in conjunction with a Proxy-Uri Option, see = 5.10.2.) > Location-Path and Location-Query may only appear in 2.01 Created > responses. At least that is the only usage defined at the moment. (If we do go for a redirection extension, that would likely use these, = too, and not the Uri-* options.) > Content-Format is explicitly allowed only for 0.03 PUT. It is > implicitly allowed for 0.02 POST requests and 2.xx Success responses > except for 2.03 ValidContent because these codes mention a > representation in the payload and 5.5.1 says Content-Format applies to > resource and action result payloads. 5.5.2 implies it must not appear > for a diagnostic payload, therefore cannot appear in 4.xx or 5.xx = error > responses. That is not exactly what it says. 5.5.1 says that whenever the payload is a representation, the = Content-Format option gives you its media type (and that applies to all = methods and response codes). It then weasels around the ability to = leave off the option when the application can divine its value. The end = of 5.5.1 combined with 5.5.2 says that if it is left off with a = 4.xx/5.xx response, any payload present is not a representation but a = diagnostic payload. So there is no way to have a "format divined by = application" representation with 4.xx/5.xx, but you can very well send a = representation with these response codes, which is indicated by giving a = Content-Format option. The diagnostic payload (read "not a representation") was invented as a = way to transport the "reason phrase" of an HTTP status line where it = most matters, which is in the error cases. > Accept can appear only in 0.01 GET requests. I don't read 5.5.4 that way at all; it is actually quite useful to be = able to select the content-format of a POST response. (Again, there is a helpful pointer in 5.8.1.) > But the other methods all > have valid responses that can contain non-diagnostic content, so maybe > it's ok for them too? Yes. > These options cannot appear (except as unrecognized) in any request: > Location-Path, Max-Age, Location-Query, Size1 (unless block is = supported) (Max-Age had request semantics in an earlier version of CoAP, we removed = that.) I don't think including a Size1 option in a request is outlawed by = 5.10.9, it is just not very useful without -block, as it is redundant = with the size of the actual payload supplied. > These options cannot appear (except as unrecognized) in any response: > If-Match, Uri-Host, If-None-Match, Uri-Port, Uri-Path, Uri-Query, = Accept, Proxy-Uri, Proxy-Scheme Right. Gr=FC=DFe, Carsten From cabo@tzi.org Sat Oct 5 07:28:39 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 012D521F8C40 for ; Sat, 5 Oct 2013 07:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1sIe+4rLM64 for ; Sat, 5 Oct 2013 07:28:33 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id E1D3321F8B4E for ; Sat, 5 Oct 2013 07:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r95ESUl7007693; Sat, 5 Oct 2013 16:28:30 +0200 (CEST) Received: from [192.168.217.105] (p54892064.dip0.t-ipconnect.de [84.137.32.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6FD22C79; Sat, 5 Oct 2013 16:28:30 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <52500410.403@pabigot.com> Date: Sat, 5 Oct 2013 16:28:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <11BE53DD-515F-4859-856A-CD0E9A149B71@tzi.org> References: <524F4CD1.9080402@pabigot.com> <52500410.403@pabigot.com> To: "Peter A. Bigot" X-Mailer: Apple Mail (2.1510) Cc: core Subject: Re: [core] Option method/response validation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2013 14:28:39 -0000 On Oct 5, 2013, at 14:20, "Peter A. Bigot" wrote: > However: DELETE with If-None-Match would return 4.12 Precondition = Failed if the resource existed (as opposed to 2.05 Deleted or an = authorization error if the conditional option was absent), and 4.04 Not = Found if it didn't, so that actually already is a sort of HEAD low-cost = probe for existence without returning the representation. =20 And the same thing would work with GET as well, no? The server could actually put an ETag on a 4.12 (ETag is "selected = representation" metadata, 5.5.3), providing some more of the HEAD-style = functionality Thomas was looking for. > (Unless the server may check for authorization data first and return = 4.03 Forbidden even if the resource doesn't exist, which case you can't = tell anything from the result.) Yes, authorization checks always need to go first so you don't disclose = information about the presence of the resource to an unauthorized = client. Gr=FC=DFe, Carsten From pab@pabigot.com Sat Oct 5 08:57:02 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D761221F8F6D for ; Sat, 5 Oct 2013 08:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dh2GeZAUnQto for ; Sat, 5 Oct 2013 08:56:57 -0700 (PDT) Received: from m1plsmtpa01-06.prod.mesa1.secureserver.net (m1plsmtpa01-06.prod.mesa1.secureserver.net [64.202.165.34]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB3821F8E40 for ; Sat, 5 Oct 2013 08:56:53 -0700 (PDT) Received: from [192.168.65.10] ([66.41.60.82]) by m1plsmtpa01-06.prod.mesa1.secureserver.net with id ZTwq1m00B1mTNtu01Twr5C; Sat, 05 Oct 2013 08:56:53 -0700 Message-ID: <525036C6.8070309@pabigot.com> Date: Sat, 05 Oct 2013 10:56:54 -0500 From: "Peter A. Bigot" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Carsten Bormann References: <524F4CD1.9080402@pabigot.com> <52500410.403@pabigot.com> <11BE53DD-515F-4859-856A-CD0E9A149B71@tzi.org> In-Reply-To: <11BE53DD-515F-4859-856A-CD0E9A149B71@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: core Subject: Re: [core] Option method/response validation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2013 15:57:03 -0000 On 10/05/2013 09:28 AM, Carsten Bormann wrote: > On Oct 5, 2013, at 14:20, "Peter A. Bigot" wrote: > >> However: DELETE with If-None-Match would return 4.12 Precondition >> Failed if the resource existed (as opposed to 2.05 Deleted or an >> authorization error if the conditional option was absent), and 4.04 >> Not Found if it didn't, so that actually already is a sort of HEAD >> low-cost probe for existence without returning the representation. > > And the same thing would work with GET as well, no? Yes, and would be a safer approach since it's safe and idempotent. So there is no reason for If-None-Match on DELETE. > The server could > actually put an ETag on a 4.12 (ETag is "selected representation" > metadata, 5.5.3), providing some more of the HEAD-style functionality > Thomas was looking for. Yes, though it wouldn't be useful unless the client already knew what the ETag represented. Huh. If a resource is destroyed, and then a new resource created with the same URI, does the server have to make any given entity tag is not associated with a different resource representation for the new resource? Probably so. > >> (Unless the server may check for authorization data first and >> return 4.03 Forbidden even if the resource doesn't exist, which >> case you can't tell anything from the result.) > > Yes, authorization checks always need to go first so you don't > disclose information about the presence of the resource to an > unauthorized client. Good point regarding best-practices, but that's not in the specification. It also needs clarification, since authorization may be relevant only for specific methods on specific resources. Unless you stop using 4.04 entirely, the fact you got a 4.03 instead of a 4.04 tells you there's something that could be there. Peter From pab@pabigot.com Sat Oct 5 08:57:57 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED3B21F8E8E for ; Sat, 5 Oct 2013 08:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.544 X-Spam-Level: X-Spam-Status: No, score=-1.544 tagged_above=-999 required=5 tests=[AWL=-0.905, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6O5WtB4f4Klf for ; Sat, 5 Oct 2013 08:57:38 -0700 (PDT) Received: from m1plsmtpa01-02.prod.mesa1.secureserver.net (m1plsmtpa01-02.prod.mesa1.secureserver.net [64.202.165.174]) by ietfa.amsl.com (Postfix) with ESMTP id A8A0421F90A7 for ; Sat, 5 Oct 2013 08:57:38 -0700 (PDT) Received: from [192.168.65.10] ([66.41.60.82]) by m1plsmtpa01-02.prod.mesa1.secureserver.net with id ZTxc1m00E1mTNtu01TxdP0; Sat, 05 Oct 2013 08:57:38 -0700 Message-ID: <525036F4.7050302@pabigot.com> Date: Sat, 05 Oct 2013 10:57:40 -0500 From: "Peter A. Bigot" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Carsten Bormann References: <524F4CD1.9080402@pabigot.com> <53B33ABC-821C-4D27-A4B7-FD100A2745C1@tzi.org> In-Reply-To: <53B33ABC-821C-4D27-A4B7-FD100A2745C1@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: core Subject: Re: [core] Option method/response validation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2013 15:57:57 -0000 Again the quote from 5.4 which is the heart of this matter: Not all options are defined for use with all methods and response codes. The possible options for methods and response codes are defined in Section 5.8 and Section 5.9 respectively. In case an option is not defined for a method or response code, it MUST NOT be included by a sender and MUST be treated like an unrecognized option by a recipient. On 10/05/2013 09:20 AM, Carsten Bormann wrote: >> If-Match and If-None-Match are permitted for PUT by 5.8.3, but not >> mentioned in other request methods. I don't think they make sense >> for GET; I can imagine a use for POST; and If-Match (but not >> If-None-Match) certainly makes sense for DELETE. Disallow for GET, >> allow all others except If-None-Match for DELETE is disallowed. > > I read the mention in 5.8.3 as a helpful pointer, not as Expressio > unius est exclusio alterius. Indeed. 5.4 is what mandates "exclusio alterius". 5.8.3 is one of the few sections that "expressio"d something. > > 5.10.8 makes no attempt at restricting these options to specific > methods. (5.10.8.2 mentions some combinations are "not very useful", > but doesn't attempt to rule them out.) If they are not defined as possible options, 5.4 rules them out. It would perhaps have been better if 5.4 had not done that, but it did. I understand your position from the perspective of what was intended, and it's consistent with my proposed "interpretation". But I don't understand your response from the perspective of what the specification requires. 5.10.8 doesn't have to restrict something in the specific case when it's already been restricted in the general case. >> Content-Format is explicitly allowed only for 0.03 PUT. It is >> implicitly allowed for 0.02 POST requests and 2.xx Success >> responses except for 2.03 ValidContent because these codes mention >> a representation in the payload and 5.5.1 says Content-Format >> applies to resource and action result payloads. 5.5.2 implies it >> must not appear for a diagnostic payload, therefore cannot appear >> in 4.xx or 5.xx error responses. > > That is not exactly what it says. > > 5.5.1 says that whenever the payload is a representation, the > Content-Format option gives you its media type (and that applies to > all methods and response codes). It then weasels around the ability > to leave off the option when the application can divine its value. > The end of 5.5.1 combined with 5.5.2 says that if it is left off with > a 4.xx/5.xx response, any payload present is not a representation but > a diagnostic payload. So there is no way to have a "format divined > by application" representation with 4.xx/5.xx, but you can very well > send a representation with these response codes, which is indicated > by giving a Content-Format option. Section 5.5: Both requests and responses may include a payload, depending on the method or response code respectively. If a method or response code is not defined to have a payload, then a sender MUST NOT include one, and a recipient MUST ignore it. None of the existing 4.xx/5.xx codes specify a payload, so none of them can have one, except under the general allowance in 5.9.2 and 5.9.3 that the server SHOULD include a diagnostic payload under certain circumstances. So those codes can't have payloads other than diagnostic payloads, and diagnostic payloads can't have a Content-Format. So Content-Format can't appear in responses with 4.xx/5.xx codes. QED. Yes, further specifications might change this for new result codes by defining resource representation and action result payloads. That's irrelevant to what we're doing today. > > The diagnostic payload (read "not a representation") was invented as > a way to transport the "reason phrase" of an HTTP status line where > it most matters, which is in the error cases. > >> Accept can appear only in 0.01 GET requests. > > I don't read 5.5.4 that way at all; it is actually quite useful to be > able to select the content-format of a POST response. (Again, there > is a helpful pointer in 5.8.1.) > >> But the other methods all have valid responses that can contain >> non-diagnostic content, so maybe it's ok for them too? > > Yes. Will that be in the errata for coap when the RFC comes out? Because simply stating it here in the working group email list doesn't change the text of the RFC-to-be, or help future implementers. Basically, 5.4 and 5.5 both put MUST restrictions on options and payloads, and the conditions on relaxing those restrictions were not met by the remainder of the text. Too late now. What's going to be done about it? Peter > >> These options cannot appear (except as unrecognized) in any >> request: Location-Path, Max-Age, Location-Query, Size1 (unless >> block is supported) > > (Max-Age had request semantics in an earlier version of CoAP, we > removed that.) > > I don't think including a Size1 option in a request is outlawed by > 5.10.9, it is just not very useful without -block, as it is redundant > with the size of the actual payload supplied. > >> These options cannot appear (except as unrecognized) in any >> response: If-Match, Uri-Host, If-None-Match, Uri-Port, Uri-Path, >> Uri-Query, Accept, Proxy-Uri, Proxy-Scheme > > Right. > > Gre, Carsten > From cabo@tzi.org Sat Oct 5 09:16:18 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E29321F856A for ; Sat, 5 Oct 2013 09:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYvkpYZBoqw7 for ; Sat, 5 Oct 2013 09:16:12 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id A253F21F8E70 for ; Sat, 5 Oct 2013 09:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r95GG56B008859; Sat, 5 Oct 2013 18:16:05 +0200 (CEST) Received: from [192.168.217.105] (p54892064.dip0.t-ipconnect.de [84.137.32.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 69832CA3; Sat, 5 Oct 2013 18:16:05 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <525036F4.7050302@pabigot.com> Date: Sat, 5 Oct 2013 18:16:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7A40D7D8-DF6B-46B7-97D2-58672CCEB926@tzi.org> References: <524F4CD1.9080402@pabigot.com> <53B33ABC-821C-4D27-A4B7-FD100A2745C1@tzi.org> <525036F4.7050302@pabigot.com> To: "Peter A. Bigot" X-Mailer: Apple Mail (2.1510) Cc: core Subject: Re: [core] Option method/response validation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2013 16:16:18 -0000 On Oct 5, 2013, at 17:57, "Peter A. Bigot" wrote: >> I read the mention in 5.8.3 as a helpful pointer, not as Expressio >> unius est exclusio alterius. >=20 > Indeed. 5.4 is what mandates "exclusio alterius". 5.8.3 is one of = the few sections that "expressio"d something. I can see how you could read 5.4 like that. But most options aren't even discussed in 5.8/5.9 at all. Content-Format is only discussed for PUT in those sections. If an option is defined for all of the codes, or for a class of them, = there is no need to "define" it again in each method or response code; = that would become very tedious. Gr=FC=DFe, Carsten From cabo@tzi.org Sat Oct 5 09:31:27 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 771B821F8616; Sat, 5 Oct 2013 09:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tj7XAJn+DN-u; Sat, 5 Oct 2013 09:31:21 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC1521F8447; Sat, 5 Oct 2013 09:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r95GVIrR013568; Sat, 5 Oct 2013 18:31:18 +0200 (CEST) Received: from [192.168.217.105] (p54892064.dip0.t-ipconnect.de [84.137.32.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 58C9ECAC; Sat, 5 Oct 2013 18:31:18 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Carsten Bormann In-Reply-To: Date: Sat, 5 Oct 2013 18:31:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: lwip@ietf.org, "core@ietf.org WG" , roll WG , 6lowpan@ietf.org, "dtls-iot@ietf.org" , "6lo@ietf.org WG" <6lo@ietf.org>, IETF 6TSCH <6tsch@ietf.org> X-Mailer: Apple Mail (2.1510) Subject: [core] Constrained Node/Network Cluster @ IETF88, early draft version X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2013 16:31:27 -0000 A first draft version of the IETF88 agenda is out. ** THIS IS GOING TO CHANGE ** for conflict resolution,=20 so please don't make travel arrangements based on it. Here is my usual eclectic condensed agenda built from that. =20 All times are PST (UTC-0800). The Constrained Node/Network group meetings are nicely spread out over = the week. The lwig/6tisch conflict is unfortunate; this will split the audience. The oauth conflict on Monday is survivable, we'll do all = security-related CoRE work on Thursday then. Gr=FC=DFe, Carsten MONDAY, November 4, 2013 0900-1130 Morning Session I Georgia B APP appsawg Applications Area Working Group WG - - = Combined with APPAREA Regency D INT 6man IPv6 Maintenance WG 1300-1430 Afternoon Session I Regency B SEC *** dice DTLS In Constrained Environments WG 1450-1720 Afternoon Session II Georgia B APP *** core Constrained RESTful Environments WG Regency C INT intarea Internet Area Working Group WG Plaza C SEC oauth Web Authorization Protocol WG 1740-1940 Afternoon Session III Regency A APP httpbis Hypertext Transfer Protocol Bis WG Regency D OPS v6ops IPv6 Operations WG Regency C RTG rtgarea Routing Area Open Meeting TUESDAY, November 5, 2013 0900-1130 Morning Session I Georgia A APP httpbis Hypertext Transfer Protocol Bis WG 1300-1400 Afternoon Session I Plaza A APP json JavaScript Object Notation WG Regency B INT its Intelligent Transportation Systems BOF 1420-1550 Afternoon Session II Georgia B INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Regency A INT *** lwig Light-Weight Implementation Guidance WG Regency B TSV tsvwg Transport Area Working Group WG 1610-1840 Afternoon Session III Regency A INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Plaza A OPS eman Energy Management WG Georgia A SEC tls Transport Layer Security WG WEDNESDAY, November 6, 2013 1300-1530 Afternoon Session I Regency C OPS v6ops IPv6 Operations WG Regency D SEC perpass Handling Pervasive Monitoring in the = IETF BOF Georgia B TSV rmcat RTP Media Congestion Avoidance = Techniques WG THURSDAY, November 7, 2013 0900-1130 Morning Session I Regency D INT homenet Home Networking WG Georgia A SEC jose Javascript Object Signing and Encryption = WG Regency C TSV tsvarea Transport Area Open Meeting 1300-1500 Afternoon Session I Regency D SEC saag Security Area Open Meeting 1520-1720 Afternoon Session II Georgia B APP *** core Constrained RESTful Environments WG FRIDAY, November 8, 2013 0900-1100 Morning Session I Regency D RTG *** roll Routing Over Low power and Lossy = networks WG Georgia B SEC httpauth Hypertext Transfer Protocol = Authentication WG Regency B TSV tsvwg Transport Area Working Group WG 1120-1220 Afternoon Session I Regency D INT dnssd Extensions for Scalable DNS Service = Discovery WG 1230-1330 Afternoon Session II Regency D INT dnssd Extensions for Scalable DNS Service = Discovery WG From pab@pabigot.com Mon Oct 7 11:01:52 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42D7C11E811E for ; Mon, 7 Oct 2013 11:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.363 X-Spam-Level: X-Spam-Status: No, score=-1.363 tagged_above=-999 required=5 tests=[AWL=-0.724, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcZRvjueqK3x for ; Mon, 7 Oct 2013 11:01:46 -0700 (PDT) Received: from m1plsmtpa01-03.prod.mesa1.secureserver.net (m1plsmtpa01-03.prod.mesa1.secureserver.net [64.202.165.4]) by ietfa.amsl.com (Postfix) with ESMTP id 6A11611E80F2 for ; Mon, 7 Oct 2013 11:01:46 -0700 (PDT) Received: from [192.168.65.10] ([66.41.60.82]) by m1plsmtpa01-03.prod.mesa1.secureserver.net with id aJ1j1m00b1mTNtu01J1kSX; Mon, 07 Oct 2013 11:01:45 -0700 Message-ID: <5252F70D.1090702@pabigot.com> Date: Mon, 07 Oct 2013 13:01:49 -0500 From: "Peter A. Bigot" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: core Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [core] observation on strict tolerance and Max-Age X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 18:01:52 -0000 In my email about observe I noted the SHOULD obligation in coap-18 section 5.10.5: The value is intended to be current at the time of transmission. Servers that provide resources with strict tolerances on the value of Max-Age SHOULD update the value before each retransmission. (See also Section 5.7.1.) In scanning the list archives I see only one discussion that touched on this (Spencer Dawkins' comments on 15 May 2013), where there was a statement made about an expectation that CoAP servers be aware of the nature of the resources they were serving, with an implication that most resources are not subject to the SHOULD because they don't require such tolerances. As I read it, when a message does contain a representation of a resource with "strict tolerances" the origin server must update (and potentially add, if the first transmission was defaulted) the Max-Age option value in two cases: (1) on each re-transmission of an unacknowledged confirmable response under BEBO, and (2) on re-transmission of a piggy-backed response due to duplicated receipt of a request per 4.5. Further, while it may be reasonable to expect that a server knows which of its resources have strict tolerances, it is less reasonable to expect this of a proxy. 5.7.1 merely mentions they must update Max-Age for the response; absent some way to communicate the strictness of the cached resource representation to the proxy, there's a case to be made that proxies must do this sort of update on all retransmissions of that response. Peter From prvs=986ad0eca=abhijan.bhattacharyya@tcs.com Tue Oct 8 03:22:47 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7217121E8196 for ; Tue, 8 Oct 2013 03:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.727 X-Spam-Level: X-Spam-Status: No, score=-4.727 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, DRUGS_MUSCLE=0.01, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gfrjvj8iPjgY for ; Tue, 8 Oct 2013 03:22:43 -0700 (PDT) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 3779921E81B9 for ; Tue, 8 Oct 2013 03:22:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,1056,1371061800"; d="scan'208";a="457852049" Received: from INKOLSALDLPMTA1.india.tcs.com (unknown [127.0.0.1]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id 6E98EDAC14 for ; Tue, 8 Oct 2013 15:52:28 +0530 (IST) Received: from InKolM02.tcs.com (unknown [172.18.18.104]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id 40C1DDAC02 for ; Tue, 8 Oct 2013 15:52:28 +0530 (IST) MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: From: Abhijan Bhattacharyya To: Message-ID: Date: Tue, 8 Oct 2013 15:52:00 +0530 X-Mailer: Lotus Domino Web Server Release 9.0HF507 August 20, 2013 X-MIMETrack: Serialize by Notes Server on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 10/08/2013 15:52:00, Serialize complete at 10/08/2013 15:52:01, Itemize by Notes Server on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 10/08/2013 15:52:01, Serialize by Notes Server on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 10/08/2013 15:52:02, Serialize complete at 10/08/2013 15:52:02, Serialize by Router on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 10/08/2013 15:52:27, Serialize complete at 10/08/2013 15:52:27 Content-Type: multipart/alternative; boundary="=_alternative 0038F26E65257BFE_=" Cc: Arpan Pal Subject: [core] Fw: New Version Notification for draft-tcs-coap-no-response-option-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 10:22:47 -0000 --=_alternative 0038F26E65257BFE_= MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear All, A new version for the No-Resp option is uploaded. This version tries to add= ress all the comments received on the last version. The key modifications i= n this version are as below: 1. A guideline on applicability of this option with the 4 REST methods is p= rovided 2. Interpretation of the 1 bit option values is changed 3. The examples section is re-organised and 2 examples with POST is incorpo= rated Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Limited Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ -----Forwarded by Abhijan Bhattacharyya/KOL/TCS on 10/08/2013 03:46PM ----- = To: Abhijan Bhattacharyya , Soma Bandyopadhy= ay , Arpan Pal From: internet-drafts@ietf.org Date: 10/08/2013 03:43PM Subject: New Version Notification for draft-tcs-coap-no-response-option-03.= txt A new version of I-D, draft-tcs-coap-no-response-option-03.txt has been successfully submitted by Abhijan Bhattacharyya and posted to the IETF repository. Filename: draft-tcs-coap-no-response-option Revision: 03 Title: CoAP option for no server-response Creation date: 2013-10-08 Group: Individual Submission Number of pages: 16 URL: http://www.ietf.org/internet-drafts/draft-tcs-coap-no-resp= onse-option-03.txt Status: http://datatracker.ietf.org/doc/draft-tcs-coap-no-response= -option Htmlized: http://tools.ietf.org/html/draft-tcs-coap-no-response-opti= on-03 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-tcs-coap-no-respo= nse-option-03 Abstract: There can be typical M2M scenarios where responses from the data sink to the data source against request/ notification from the source might be considered redundant. This kind of open-loop exchange (with no reverse path from the sink to the source) may be desired while updating resources or notifying about the updated status of a resource in constrained systems looking for maximized throughput with minimized resource consumption. CoAP already provides a non-confirmable (NON) mode of exchange where The receiving end-point does not respond with ACK. However, the receiving end-point responds the sender with a status code indicating "the result of the attempt to understand and satisfy the request". This draft introduces a header option: 'No-Resp' to suppress responses from the receiver and discusses exemplary use cases which motivated this proposition based on real experience. This option also provides granularity by allowing suppression of a typical class or a combination of classes of responses. This option is applicable for both request/ response as well as resource-observe mode and may be effective for both unicast and multicast scenarios. = = Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D Notice: The information contained in this e-mail message and/or attachments to it may contain = confidential or privileged information. If you are = not the intended recipient, any dissemination, use, = review, distribution, printing or copying of the = information contained in this e-mail message = and/or attachments to it are strictly prohibited. If = you have received this communication in error, = please notify us by reply e-mail or telephone and = immediately and permanently delete the message = and any attachments. Thank you --=_alternative 0038F26E65257BFE_= Content-ID: <> MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear All,
A new version for the No-Resp option is uploaded. This version tries t= o address all the comments received on the last version. The key modificati= ons in this version are as below:
 
1. A guideline on applicability of this option with the= 4 REST methods is provided
2. Interpretation of the 1 bit option values is changed
3. The examples section is re-organised and 2 examples with = POST is incorporated



Regards
Abhijan Bhattacharyya
Ass= ociate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Cons= ultancy Services Limited
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
____________________________________= ________
Experience certainty. IT Services
Business Solutions
Cons= ulting
____________________________________________


<= FONT color=3D#990099>-----Forwarded by Abhijan Bhattacharyya/KOL/TCS on 10/= 08/2013 03:46PM ----- =
To: Abhijan Bhattacharyya <abhijan.bhattacharyya@tcs.com>, So= ma Bandyopadhyay <soma.bandyopadhyay@tcs.com>, Arpan Pal <arpan.pa= l@tcs.com>
From: internet-drafts@ietf.org
Date: 10/08/2013 03:43PM=
Subject: New Version Notification for draft-tcs-coap-no-response-option= -03.txt

http://www.ietf.org/interne= t-drafts/draft-tcs-coap-no-response-option-03.txt
Status:   &nb= sp;      http://datatracker.ietf.org/doc/draft-tcs-coap-n= o-response-option
Htmlized:        http://tools= .ietf.org/html/draft-tcs-coap-no-response-option-03
Diff:   &nb= sp;        http://www.ietf.org/rfcdiff?url2= =3Ddraft-tcs-coap-no-response-option-03

Abstract:
  = ; There can be typical M2M scenarios where responses from the data
 = ;  sink to the data source against request/ notification from the
&= nbsp;  source might be considered redundant. This kind of open-loop   exchange (with no reverse path from the sink to the source) m= ay be
   desired while updating resources or notifying about t= he updated
   status of a resource in constrained systems look= ing for maximized
   throughput with minimized resource consum= ption. CoAP already
   provides a non-confirmable (NON) mode o= f exchange where The
   receiving end-point does not respond w= ith ACK. However, the
   receiving end-point responds the send= er with a status code
   indicating "the result of the attempt= to understand and satisfy the
   request".

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

           =                      = ;                     &nb= sp;                     &= nbsp;      


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

The IETF Secretariat

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

--=_alternative 0038F26E65257BFE_=-- From cabo@tzi.org Tue Oct 8 03:41:08 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B0021E81CB for ; Tue, 8 Oct 2013 03:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSvx+epIOQxD for ; Tue, 8 Oct 2013 03:41:00 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 09F5521E8196 for ; Tue, 8 Oct 2013 03:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r98Aeka3018652; Tue, 8 Oct 2013 12:40:46 +0200 (CEST) Received: from [10.0.1.4] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id F280F7DA; Tue, 8 Oct 2013 12:40:45 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann X-Priority: 3 (Normal) In-Reply-To: Date: Tue, 8 Oct 2013 12:40:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Abhijan Bhattacharyya X-Mailer: Apple Mail (2.1510) Cc: Arpan Pal , core@ietf.org Subject: Re: [core] Fw: New Version Notification for draft-tcs-coap-no-response-option-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 10:41:08 -0000 Hi Abhijan, thanks for the update. A quick reaction to the new table 2: While it is true that the default value for the option is not very = useful with GET, setting specific bits might still make it useful. I = think it would be worthwhile thinking about this. (More generally speaking, having examples for the option bits would be = useful for the other methods as well. If they are hard to come up with = -- maybe we don't need the option bits?) Nits: "empty or 0 value" -- for a uint, 0 is usually represented as an empty = value. So talking about 0 would be enough. I would also do this in the = examples. (For comparison, the Observe option currently is slightly more complex*) = by saying that the request option is empty and the response option is a = uint; here, the option always is a uint.) One other comment that just came to mind now: Similar to HTTP header names, CoAP option names usually use full words = (unless there is a commonly used abbreviation, such as URI or "Max"; the = latter was just copied from HTTP.) There is no point in trying to optimize the length of the option name, = as the option number being encoded is a small integer anyway. So it would seem to be more in style with the rest of CoAP to call the = option "No-Response". Gr=FC=DFe, Carsten *) Which is out of character with the other CoAP options, each of which = has a single encoding (which does simplify implementation somewhat). Of = course, it is easy to implement Observe as always being uint, so maybe = that is not really an issue. From trac+core@trac.tools.ietf.org Tue Oct 8 05:08:15 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9623921E808A for ; Tue, 8 Oct 2013 05:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Gsb43cfZA6B for ; Tue, 8 Oct 2013 05:08:15 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id E8F3E11E819C for ; Tue, 8 Oct 2013 05:08:14 -0700 (PDT) Received: from localhost ([127.0.0.1]:44458 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VTW57-0000ah-KR; Tue, 08 Oct 2013 14:08:05 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Tue, 08 Oct 2013 12:08:05 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/346 Message-ID: <060.3b4321d40c10aa360522a7791cb8644c@trac.tools.ietf.org> X-Trac-Ticket-ID: 346 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, angelo@castellani.net, esko.dijk@philips.com, salvatore.loreto@ericsson.com, tho@koanlogic.com Resent-Message-Id: <20131008120814.E8F3E11E819C@ietfa.amsl.com> Resent-Date: Tue, 8 Oct 2013 05:08:14 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #346: Select solution for default HTTP-CoAP URI mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 12:08:15 -0000 #346: Select solution for default HTTP-CoAP URI mapping Current http-mapping-01 presents 5 different options. Based on WG discussion during the IETF 87 meeting; one preferred solution has to be presented. Selection expected around October 10th 2013. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-http- esko.dijk@philips.com | mapping@tools.ietf.org Type: editorial | Status: new Priority: major | Milestone: Component: http- | Version: mapping | Keywords: Severity: - | -------------------------+------------------------------------------------- Ticket URL: core From prvs=986ad0eca=abhijan.bhattacharyya@tcs.com Tue Oct 8 05:14:19 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D89F21E819C for ; Tue, 8 Oct 2013 05:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.546 X-Spam-Level: X-Spam-Status: No, score=-5.546 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvLzZTf1ReWA for ; Tue, 8 Oct 2013 05:14:14 -0700 (PDT) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 1382421E8085 for ; Tue, 8 Oct 2013 05:14:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,1056,1371061800"; d="scan'208";a="457904259" Received: from INKOLSALDLPMTA1.india.tcs.com (unknown [127.0.0.1]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id EE9C8DAC12; Tue, 8 Oct 2013 17:44:09 +0530 (IST) Received: from InKolM02.tcs.com (unknown [172.18.18.104]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id BEA0BDAC02; Tue, 8 Oct 2013 17:44:09 +0530 (IST) MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: , From: Abhijan Bhattacharyya To: Carsten Bormann Message-ID: Date: Tue, 8 Oct 2013 17:44:09 +0530 X-Mailer: Lotus Domino Web Server Release 9.0HF507 August 20, 2013 X-MIMETrack: Serialize by Notes Server on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 10/08/2013 17:44:09, Serialize complete at 10/08/2013 17:44:09, Itemize by Notes Server on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 10/08/2013 17:44:09, Serialize by Router on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 10/08/2013 17:44:09 Content-Type: multipart/alternative; boundary="=_alternative 004336A465257BFE_=" Cc: Arpan Pal , core@ietf.org Subject: Re: [core] Fw: New Version Notification for draft-tcs-coap-no-response-option-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 12:14:19 -0000 --=_alternative 004336A465257BFE_= MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Carsten, >While it is true that the default value for the option is not very >useful with GET, setting specific bits might still make it useful. I >think it would be worthwhile thinking about this. >(More generally speaking, having examples for the option bits would >be useful for the other methods as well. If they are hard to come up >with -- maybe we don't need the option bits?) Any value for this option should be treated as 'DON'T CARE' (like digital l= ogic) for GET or DELETE. In fact these methods ideally should not use this = option. That is why no values were specified and no examples were illustrat= ed for GET and DELETE. Still, do you think it will be useful if we specify= a default value like '7' (specifying all responses to be allowed) for GET = and DELETE? Or, may be, we put some examples showing that although we use t= his option with whatever value still that does not have any effect on the e= xchanges? >"empty or 0 value" -- for a uint, 0 is usually represented as an >empty value. >So talking about 0 would be enough. I would also do this in the >examples. >(For comparison, the Observe option currently is slightly more >complex*) by saying that the request option is empty and the response >option is a uint; here, the option always is a uint.) Actually the idea was that there may be applications which would benefit by= not allowing any response. So in such a case the application will not requ= ire any granularity and hence may save 1 byte (which may be significant ove= rhead for very small sized updates) by using it as empty. But yes we can si= mplify things if we keep it as 1 byte uint. >One other comment that just came to mind now: >Similar to HTTP header names, CoAP option names usually use full >words (unless there is a commonly used abbreviation, such as URI or >"Max"; the latter was just copied from HTTP.) >There is no point in trying to optimize the length of the option >name, as the option number being encoded is a small integer anyway. >So it would seem to be more in style with the rest of CoAP to call >the option "No-Response". Agreed and accepted. Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Limited Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ -----Carsten Bormann wrote: ----- >To: Abhijan Bhattacharyya >From: Carsten Bormann >Date: 10/08/2013 04:11PM >Cc: , Arpan Pal >Subject: Re: [core] Fw: New Version Notification for >draft-tcs-coap-no-response-option-03.txt > > >Hi Abhijan, > >thanks for the update. > >A quick reaction to the new table 2: > >While it is true that the default value for the option is not very >useful with GET, setting specific bits might still make it useful. I >think it would be worthwhile thinking about this. >(More generally speaking, having examples for the option bits would >be useful for the other methods as well. If they are hard to come up >with -- maybe we don't need the option bits?) > >Nits: > >"empty or 0 value" -- for a uint, 0 is usually represented as an >empty value. >So talking about 0 would be enough. I would also do this in the >examples. >(For comparison, the Observe option currently is slightly more >complex*) by saying that the request option is empty and the response >option is a uint; here, the option always is a uint.) > >One other comment that just came to mind now: >Similar to HTTP header names, CoAP option names usually use full >words (unless there is a commonly used abbreviation, such as URI or >"Max"; the latter was just copied from HTTP.) >There is no point in trying to optimize the length of the option >name, as the option number being encoded is a small integer anyway. >So it would seem to be more in style with the rest of CoAP to call >the option "No-Response". > >Gr=FC=DFe, Carsten > >*) Which is out of character with the other CoAP options, each of >which has a single encoding (which does simplify implementation >somewhat). Of course, it is easy to implement Observe as always >being uint, so maybe that is not really an issue. =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D Notice: The information contained in this e-mail message and/or attachments to it may contain = confidential or privileged information. If you are = not the intended recipient, any dissemination, use, = review, distribution, printing or copying of the = information contained in this e-mail message = and/or attachments to it are strictly prohibited. If = you have received this communication in error, = please notify us by reply e-mail or telephone and = immediately and permanently delete the message = and any attachments. Thank you --=_alternative 004336A465257BFE_= Content-ID: <> MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Carsten,
 
>While it is true that the default value for = the option is not very
>useful with GET, setting specific bits might = still make it useful.  I
>think it would be worthwhile thinking = about this.
>(More generally speaking, having examples for the option= bits would
>be useful for the other methods as well.  If they a= re hard to come up
>with -- maybe we don't need the option bits?)
 
Any value for this option should be treated as 'DON'T CARE' (like digi= tal logic) for GET or DELETE. In fact these methods ideally should not use = this option. That is why no values were specified and no examples were illu= strated for GET and DELETE. Still, do you think it will be useful if w= e  specify a default value like '7' (specifying all responses to be al= lowed) for GET and DELETE? Or, may be, we put some examples showing that al= though we use this option with whatever value still that does not have any = effect on the exchanges?

>"empty or 0 value= " -- for a uint, 0 is usually represented as an
>empty value.
>= So talking about 0 would be enough.  I would also do this in the
&g= t;examples.
>(For comparison, the Observe option currently is slightl= y more
>complex*) by saying that the request option is empty and the = response
>option is a uint; here, the option always is a uint.)
Actually the idea was that there may be applications which would benef= it by not allowing any response. So in such a case the application will not= require any granularity and hence may save 1 byte (which may be significan= t overhead for very small sized updates) by using it as empty. But yes we c= an simplify things if we keep it as 1 byte uint.
 
>One other comment that just came to mind now= :
>Similar to HTTP header names, CoAP option names usually use full>words (unless there is a commonly used abbreviation, such as URI or>"Max"; the latter was just copied from HTTP.)
>There is no poin= t in trying to optimize the length of the option
>name, as the option= number being encoded is a small integer anyway.
>So it would seem to= be more in style with the rest of CoAP to call
>the option "No-Respo= nse".
Agreed and accepted.

Regards
Abhijan Bhattacharyya
Associate Consultant
Scient= ist, Innovation Lab, Kolkata, India
Tata Consultancy Services LimitedMailto: abhijan.bhattacha= ryya@tcs.com
Website: http://www.tcs= .com
____________________________________________
Experience cert= ainty. IT Services
Business Solutions
Consulting
_________________= ___________________________


-----Carsten= Bormann <cabo@tzi.org> wrote: -----

>To: Abhijan Bh= attacharyya <abhijan.bhattacharyya@tcs.com>
>From: Carsten Borm= ann <cabo@tzi.org>
>Date: 10/08/2013 04:11PM
>Cc: <cor= e@ietf.org>, Arpan Pal <arpan.pal@tcs.com>
>Subject: Re: [co= re] Fw: New Version Notification for
>draft-tcs-coap-no-response-opti= on-03.txt
>
>
>Hi Abhijan,
>
>thanks for the = update.
>
>A quick reaction to the new table 2:
>
>= While it is true that the default value for the option is not very
>u= seful with GET, setting specific bits might still make it useful.  I>think it would be worthwhile thinking about this.
>(More genera= lly speaking, having examples for the option bits would
>be useful fo= r the other methods as well.  If they are hard to come up
>with = -- maybe we don't need the option bits?)
>
>Nits:
>
&g= t;"empty or 0 value" -- for a uint, 0 is usually represented as an
>e= mpty value.
>So talking about 0 would be enough.  I would also d= o this in the
>examples.
>(For comparison, the Observe option c= urrently is slightly more
>complex*) by saying that the request optio= n is empty and the response
>option is a uint; here, the option alway= s is a uint.)
>
>One other comment that just came to mind now:<= BR>>Similar to HTTP header names, CoAP option names usually use full
= >words (unless there is a commonly used abbreviation, such as URI or
= >"Max"; the latter was just copied from HTTP.)
>There is no point = in trying to optimize the length of the option
>name, as the option n= umber being encoded is a small integer anyway.
>So it would seem to b= e more in style with the rest of CoAP to call
>the option "No-Respons= e".
>
>Gr=FC=DFe, Carsten
>
>*) Which is out of cha= racter with the other CoAP options, each of
>which has a single encod= ing (which does simplify implementation
>somewhat).  Of course, = it is easy to implement Observe as always
>being uint, so maybe that = is not really an issue.

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

--=_alternative 004336A465257BFE_=-- From hartke@tzi.org Tue Oct 8 06:03:59 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 643D721F999B for ; Tue, 8 Oct 2013 06:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqYdy3qsRjAW for ; Tue, 8 Oct 2013 06:03:52 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE3921E8084 for ; Tue, 8 Oct 2013 06:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r98D31E5025461 for ; Tue, 8 Oct 2013 15:03:01 +0200 (CEST) Received: from mail-vb0-f49.google.com (mail-vb0-f49.google.com [209.85.212.49]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B77C891F for ; Tue, 8 Oct 2013 15:03:01 +0200 (CEST) Received: by mail-vb0-f49.google.com with SMTP id w16so4130164vbb.36 for ; Tue, 08 Oct 2013 06:03:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=sg+QIeoM5OCe7+RfYbWGfy4PSp1DsakRYThzQUnQoAo=; b=Ljz9+kxjghJWBxLHr581RnVaUsWlr+PxHjABQvuS1tnmJ9qQS2sth7dl5SCJ05/brn Rb+AdK68/xAoX3GivkM/MR2TVVu8P5Eh3Aa3S29bqczNy9HL3BjQKisHzFpAcJCzK4yQ dhaa5iJQSwYjLvbb3UFZ9Zbup9dyVRKY8N363jFh2Y0JmgdzoXEv8E29Y3H/Hi9r8pdW ObMZ0mlo3R3WunQf2Ccdgb7HK3xnWJSDg1sbI4CyYB3DBYV84EEr0K4RocADBk8H4PzH HM3TD+Wh0YOI6lsxXwVSu+OKBYrBPK72iJNV5zQILXBuIjJQ4NrMpXZgl+8iqU4g+gZw 1KdQ== X-Received: by 10.220.74.69 with SMTP id t5mr994722vcj.18.1381237380381; Tue, 08 Oct 2013 06:03:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.24.83 with HTTP; Tue, 8 Oct 2013 06:02:20 -0700 (PDT) In-Reply-To: References: From: Klaus Hartke Date: Tue, 8 Oct 2013 16:02:20 +0300 Message-ID: To: Abhijan Bhattacharyya Content-Type: text/plain; charset=ISO-8859-1 Cc: Arpan Pal , "core@ietf.org WG" Subject: Re: [core] Fw: New Version Notification for draft-tcs-coap-no-response-option-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 13:03:59 -0000 The idea of suppressing responses has been floating around for some time, so it's good to see that someone finally started to write it down. I've got a few comments/questions: * How does it work across proxies? For example, normally a proxy is free to satisfy a request as it sees fit; is a proxy required to include the No-Resp option in its request if the original client doesn't want a response? What should happen when a proxy does not implement the option? * How does it interact with caches? For example, if there is no response, cache entries do not get invalidated; is this intended? * I'm not sure what a No-Resp option in a notification/response does. If a message is non-confirmable, then there is already no message coming back from the recipient. * Regarding high-frequency/real-time updates: Just because the sender does not have to wait for a response doesn't mean that it can send as frequently as it likes. Since there is no return traffic from the recipient, the sender cannot monitor packet loss and cannot estimate the RTT. This means the sender "SHOULD NOT send more than one UDP datagram every 3 seconds, and SHOULD use an even less aggressive rate when possible." (rfc5405) * There is no need for short option names, since the names are not included in the message. Why not "No-Response"? Or maybe "Response-Filter"? * Is the option intended to be critical or elective? * If, for example, only 2.xx responses are suppressed and an error occurs, the non-confirmable 4.xx/5xx response could get lost. This could leave the impression that the request was successful. It might be worth pointing out that this is not the case. * How does a sender detect if it's sending its data to a recipient that is long gone? * Should a recipient be able to detect if consecutive messages were reordered? * There is no need to distinguish between a 0-byte/empty value and the 1-byte value 0b00000000. Both encode the same uint. * The bit field (table 3) could be slightly simplified by setting the bits according to the response classes: 00000000 suppress all responses 00000010 allow 2.xx 00001000 allow 4.xx 00010000 allow 5.xx * "Thus, if the client decides to open up the responses for errors (4.xx & 5.xx) then it has to wait for the entire time-out period" -- CoAP does not define a time-out period for responses, only for acknowledgements/resets. * When can the token in a request with No-Resp option be reused? * The path and query in the example in figure 3 should be split in multiple options: Uri-Path: "insertInfo" Uri-Query: "VehID=00" Uri-Query: "RouteID=DN47" Uri-Query: "Lat=22.5649015" Uri-Query: "Long=88.4103511667" Uri-Query: "Time=2013-01-13T11:24:51" As an observation, non-confirmable PUTs with No-Resp option seem to provide a similar service as draft-ietf-core-observe, but much more lightweight. When comparing the two approaches, it's clear that No-Resp appears that way because -observe simply does a lot more: -observe scales from a single recipient to huge numbers of recipients by the use of proxies, implements congestion control, detects when recipients are gone, and provides message reordering detection. Most of this was formulated by the working group as a strong requirement for -observe. However, when people bring up the idea of suppressing responses, they are usually happy to give up all of this. That puzzles me. Best regards, Klaus On 8 October 2013 13:22, Abhijan Bhattacharyya wrote: > Dear All, > A new version for the No-Resp option is uploaded. This version tries to > address all the comments received on the last version. The key modifications > in this version are as below: > > 1. A guideline on applicability of this option with the 4 REST methods is > provided > 2. Interpretation of the 1 bit option values is changed > 3. The examples section is re-organised and 2 examples with POST is > incorporated > > Regards > Abhijan Bhattacharyya From trac+core@trac.tools.ietf.org Tue Oct 8 23:22:06 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C305421F9D55 for ; Tue, 8 Oct 2013 23:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlYpHnF7dGP9 for ; Tue, 8 Oct 2013 23:22:04 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id E052221F9D22 for ; Tue, 8 Oct 2013 23:21:57 -0700 (PDT) Received: from localhost ([127.0.0.1]:56198 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VTn9T-0004MJ-Rc; Wed, 09 Oct 2013 08:21:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Wed, 09 Oct 2013 06:21:43 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/347 Message-ID: <060.169326d8222adc3febca647f61c5be0c@trac.tools.ietf.org> X-Trac-Ticket-ID: 347 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, angelo@castellani.net, esko.dijk@philips.com, salvatore.loreto@ericsson.com, tho@koanlogic.com Resent-Message-Id: <20131009062157.E052221F9D22@ietfa.amsl.com> Resent-Date: Tue, 8 Oct 2013 23:21:57 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #347: Add use case(s) for http-coap mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 06:22:06 -0000 #347: Add use case(s) for http-coap mapping The authors propose to add one or more small use case descriptions, to illustrate the use of HTTP-CoAP mapping. Possible use cases are: 1. Smartphone at home makes coap:// request to a sensor via WiFi. When away from home, the same request is done by https:// request over an external network to the home router which contains a HTTP-CoAP proxy. 2. Building control system that can make HTTP requests (but not CoAP requests) checks the status of sensors/actuators via a HTTP-CoAP proxy. 3. A HTTP-CoAP proxy is configured to expose the contents of a sensor to the world, for demonstration purposes. It converts http:// and https:// GET requests to secure coaps:// requests to the sensor. Note: the sensor can only process secured requests, not coap:// requests. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-http- esko.dijk@philips.com | mapping@tools.ietf.org Type: task | Status: new Priority: major | Milestone: Component: http- | Version: mapping | Keywords: Severity: - | -------------------------+------------------------------------------------- Ticket URL: core From esko.dijk@philips.com Wed Oct 9 00:18:13 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A369521E80D3 for ; Wed, 9 Oct 2013 00:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.597 X-Spam-Level: X-Spam-Status: No, score=-3.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQ4aZbYTYsHN for ; Wed, 9 Oct 2013 00:18:08 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 81B0521E80CE for ; Wed, 9 Oct 2013 00:18:05 -0700 (PDT) Received: from mail174-ch1-R.bigfish.com (10.43.68.244) by CH1EHSOBE016.bigfish.com (10.43.70.66) with Microsoft SMTP Server id 14.1.225.22; Wed, 9 Oct 2013 07:18:04 +0000 Received: from mail174-ch1 (localhost [127.0.0.1]) by mail174-ch1-R.bigfish.com (Postfix) with ESMTP id 757091401C0 for ; Wed, 9 Oct 2013 07:18:04 +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: -21 X-BigFish: VPS-21(zz217bI15d6Oc85fh9251Idd85kzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah18c673h1de097h186068h18de19h8275bh8275dhz2dh2a8h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1bceh1fb3h1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h20f0h2184m1155h) Received: from mail174-ch1 (localhost.localdomain [127.0.0.1]) by mail174-ch1 (MessageSwitch) id 1381303030146608_22577; Wed, 9 Oct 2013 07:17:10 +0000 (UTC) Received: from CH1EHSMHS028.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.253]) by mail174-ch1.bigfish.com (Postfix) with ESMTP id 1F0EC4601D8 for ; Wed, 9 Oct 2013 07:17:10 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CH1EHSMHS028.bigfish.com (10.43.70.28) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 9 Oct 2013 07:17:09 +0000 Received: from 011-DB3MMR1-013.MGDPHG.emi.philips.com (10.128.28.97) by 011-DB3MMR1-008.MGDPHG.emi.philips.com (10.128.28.47) with Microsoft SMTP Server (TLS) id 14.3.146.2; Wed, 9 Oct 2013 07:17:07 +0000 Received: from 011-DB3MPN2-081.MGDPHG.emi.philips.com ([169.254.1.172]) by 011-DB3MMR1-013.MGDPHG.emi.philips.com ([10.128.28.97]) with mapi id 14.03.0146.002; Wed, 9 Oct 2013 07:17:00 +0000 From: "Dijk, Esko" To: "core (core@ietf.org)" Thread-Topic: Selection of default HTTP-CoAP URI mapping Thread-Index: Ac7EvBgAG2+IWp6yTFCEAgbsPJarlw== Date: Wed, 9 Oct 2013 07:16:59 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618016F4CFF@011-DB3MPN2-081.MGDPHG.emi.philips.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [188.207.99.91] Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED618016F4CFF011DB3MPN2081MG_" MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [core] Selection of default HTTP-CoAP URI mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 07:18:13 -0000 --_000_031DD135F9160444ABBE3B0C36CED618016F4CFF011DB3MPN2081MG_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, the authors of draft-ietf-core-http-mapping-01 would like to propose a defa= ult HTTP-to-CoAP URI mapping solution that combines elements of the two bes= t candidate solutions #2 and #5 (explained in http://tools.ietf.org/html/draft-ietf-core-http-mapping-01#se= ction-4.2.2 and http://tools.ietf.org/html/draft-ietf-core-http-mapping-01#= section-4.2.5 respectively) Below URI template uses the notation of RFC 6570. The proposed format is /.well-known/core/{coap-scheme}/{+authority-pct-encoded}/{+path}?{+que= ry} where 'coap-scheme' can be coap or coaps. So, two sub-resources of the alre= ady-reserved /.well-known/core are used. Example: HTTP request to the proxy: http://proxy.example.com/.well-known/core/coap/server.coap.example.com:4567= /foo/bar?a=3D3 becomes a CoAP request sent by the proxy: coap://server.coap.example.com:4567/foo/bar?a=3D3 This format should make it easy to 'see' the CoAP URI embedded in the HTTP = URI (except that the :// part has become a /) and also allows coap access f= rom https and vice versa coaps from http, which is needed in some use cases= (refer to ticket #347 http://trac.tools.ietf.org/wg/core/trac/ticket/347 f= or these use cases). Note: To mitigate certain security worries about accessing coaps URIs over = an unprotected http connection, we plan to add a recommendation that a conf= igurable proxy by default disallows translating of http requests to coaps r= equests. If there are no objections, we'll update the I-D text to express this solut= ion. best regards, Esko ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_031DD135F9160444ABBE3B0C36CED618016F4CFF011DB3MPN2081MG_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

the authors of draft-ietf-core-http-mapping-01 would= like to propose a default HTTP-to-CoAP URI mapping solution that combines = elements of the two best candidate solutions #2 and #5

(explained in http://tools.ietf.org/html/draft-ietf-core-http-mapping-01#section-4.2.2 and http://tools.ietf.org/html/draft-ietf-core-http-mapping-01#section-4.2.5 respectively)

 

Below URI template uses the notation of RFC 6570. Th= e proposed format is

     /.well-known/core/{= coap-scheme}/{+authority-pct-encoded}/{+path}?{+query}

 

where ‘coap-scheme’ can be coap or coaps= . So, two sub-resources of the already-reserved /.well-known/core are used.

 

Example:

HTTP request to the proxy:

http://proxy.example.com/.well-known/core/coap/server.coap.example.com:45= 67/foo/bar?a=3D3

becomes a CoAP request sent by the proxy:

        &nbs= p;       coap://server.coap.example.com:4567/= foo/bar?a=3D3

 

This format should make it easy to ‘see’= the CoAP URI embedded in the HTTP URI (except that the :// part has become= a /) and also allows coap access from https and vice versa coaps from http= , which is needed in some use cases (refer to ticket #347 http://trac.tools.ietf.org/wg/core/trac/ticket/347 for these use cases= ).

Note: To mitigate certain security worries about acc= essing coaps URIs over an unprotected http connection, we plan to add a rec= ommendation that a configurable proxy by default disallows translating of h= ttp requests to coaps requests.

 

If there are no objections, we’ll update the I= -D text to express this solution.

 

best regards,

Esko


The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
 --_000_031DD135F9160444ABBE3B0C36CED618016F4CFF011DB3MPN2081MG_-- From trac+core@trac.tools.ietf.org Wed Oct 9 03:42:43 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86EA811E8171 for ; Wed, 9 Oct 2013 03:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAVR0qo05Ab1 for ; Wed, 9 Oct 2013 03:42:43 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id E9DD411E8163 for ; Wed, 9 Oct 2013 03:42:42 -0700 (PDT) Received: from localhost ([127.0.0.1]:50779 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VTrDu-000719-Qx; Wed, 09 Oct 2013 12:42:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Wed, 09 Oct 2013 10:42:34 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/346#comment:1 Message-ID: <075.377a12b6e6d2c218c5b105ce45ad6e7e@trac.tools.ietf.org> References: <060.3b4321d40c10aa360522a7791cb8644c@trac.tools.ietf.org> X-Trac-Ticket-ID: 346 In-Reply-To: <060.3b4321d40c10aa360522a7791cb8644c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, angelo@castellani.net, esko.dijk@philips.com, salvatore.loreto@ericsson.com, tho@koanlogic.com Resent-Message-Id: <20131009104242.E9DD411E8163@ietfa.amsl.com> Resent-Date: Wed, 9 Oct 2013 03:42:42 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #346: Select solution for default HTTP-CoAP URI mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 10:42:43 -0000 #346: Select solution for default HTTP-CoAP URI mapping Changes (by esko.dijk@philips.com): * status: new => closed * type: editorial => task * resolution: => fixed Comment: Done in [1512], following the proposed format posted 2013-10-09 on the CoRE WG list. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-http- esko.dijk@philips.com | mapping@tools.ietf.org Type: task | Status: closed Priority: major | Milestone: Component: http- | Version: mapping | Resolution: fixed Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Wed Oct 9 05:13:40 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F8D21F9FFF for ; Wed, 9 Oct 2013 05:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvu-JtHi6WcC for ; Wed, 9 Oct 2013 05:13:39 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id DDECE21E8064 for ; Wed, 9 Oct 2013 05:13:37 -0700 (PDT) Received: from localhost ([127.0.0.1]:59313 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VTsdv-0006wk-Kv; Wed, 09 Oct 2013 14:13:31 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Wed, 09 Oct 2013 12:13:31 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/347#comment:1 Message-ID: <075.4652c9b4f40a98351d706cf70fb1e809@trac.tools.ietf.org> References: <060.169326d8222adc3febca647f61c5be0c@trac.tools.ietf.org> X-Trac-Ticket-ID: 347 In-Reply-To: <060.169326d8222adc3febca647f61c5be0c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, angelo@castellani.net, esko.dijk@philips.com, salvatore.loreto@ericsson.com, tho@koanlogic.com Resent-Message-Id: <20131009121337.DDECE21E8064@ietfa.amsl.com> Resent-Date: Wed, 9 Oct 2013 05:13:37 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #347: Add use case(s) for http-coap mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 12:13:40 -0000 #347: Add use case(s) for http-coap mapping Changes (by esko.dijk@philips.com): * status: new => closed * resolution: => fixed Comment: Done in [1513]. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-http- esko.dijk@philips.com | mapping@tools.ietf.org Type: task | Status: closed Priority: major | Milestone: Component: http- | Version: mapping | Resolution: fixed Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From prvs=987082501=abhijan.bhattacharyya@tcs.com Wed Oct 9 12:13:45 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8258B21F9A0C for ; Wed, 9 Oct 2013 12:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.144 X-Spam-Level: X-Spam-Status: No, score=-5.144 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, DRUGS_MUSCLE=0.01, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zIefv4EoWO8 for ; Wed, 9 Oct 2013 12:13:41 -0700 (PDT) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id DEB2A21E8176 for ; Wed, 9 Oct 2013 12:13:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,1065,1371061800"; d="scan'208";a="458499722" Received: from INKOLSALDLPMTA1.india.tcs.com (unknown [127.0.0.1]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id 67376DAC12 for ; Thu, 10 Oct 2013 00:43:29 +0530 (IST) Received: from InKolM02.tcs.com (unknown [172.18.18.104]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id 3C649DAC02 for ; Thu, 10 Oct 2013 00:43:29 +0530 (IST) MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: From: Abhijan Bhattacharyya To: Message-ID: Date: Thu, 10 Oct 2013 00:43:27 +0530 X-Mailer: Lotus Domino Web Server Release 9.0HF507 August 20, 2013 X-MIMETrack: Serialize by Notes Server on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 10/10/2013 00:43:27, Serialize complete at 10/10/2013 00:43:27, Itemize by Notes Server on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 10/10/2013 00:43:27, Serialize by Notes Server on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 10/10/2013 00:43:28, Serialize complete at 10/10/2013 00:43:28, Serialize by Router on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 10/10/2013 00:43:28 Content-Type: multipart/alternative; boundary="=_alternative 00699A0D65257BFF_=" Subject: [core] Fw: New Version Notification for draft-tcs-coap-no-response-option-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 19:13:45 -0000 --=_alternative 00699A0D65257BFF_= MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, A new version for no-response option has been uploaded. This version addres= ses most of the recent comments from Carsten and Klaus. Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Limited Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ -----Forwarded by Abhijan Bhattacharyya/KOL/TCS on 10/10/2013 12:41AM ----- = To: Abhijan Bhattacharyya , Soma Bandyopadhy= ay , Arpan Pal From: internet-drafts@ietf.org Date: 10/10/2013 12:36AM Subject: New Version Notification for draft-tcs-coap-no-response-option-04.= txt A new version of I-D, draft-tcs-coap-no-response-option-04.txt has been successfully submitted by Abhijan Bhattacharyya and posted to the IETF repository. Filename: draft-tcs-coap-no-response-option Revision: 04 Title: CoAP option for no server-response Creation date: 2013-10-09 Group: Individual Submission Number of pages: 15 URL: http://www.ietf.org/internet-drafts/draft-tcs-coap-no-resp= onse-option-04.txt Status: http://datatracker.ietf.org/doc/draft-tcs-coap-no-response= -option Htmlized: http://tools.ietf.org/html/draft-tcs-coap-no-response-opti= on-04 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-tcs-coap-no-respo= nse-option-04 Abstract: There can be typical M2M scenarios where responses from the data sink to the data source against request/ notification from the source might be considered redundant. This kind of open-loop exchange (with no reverse path from the sink to the source) may be desired while updating resources in constrained systems looking for maximized throughput with minimized resource consumption. CoAP already provides a non-confirmable (NON) mode of exchange where The receiving end-point does not respond with ACK. However, the receiving end-point responds the sender with a status code indicating "the result of the attempt to understand and satisfy the request". This draft introduces a header option: 'No-Response' to suppress responses from the receiver and discusses exemplary use cases which motivated this proposition based on real experience. This option also provides granularity by allowing suppression of a typical class or a combination of classes of responses. This option may be effective for both unicast and multicast scenarios. = = Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D Notice: The information contained in this e-mail message and/or attachments to it may contain = confidential or privileged information. If you are = not the intended recipient, any dissemination, use, = review, distribution, printing or copying of the = information contained in this e-mail message = and/or attachments to it are strictly prohibited. If = you have received this communication in error, = please notify us by reply e-mail or telephone and = immediately and permanently delete the message = and any attachments. Thank you --=_alternative 00699A0D65257BFF_= Content-ID: <> MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi All,
A new version for no-response option has been uploaded. This version a= ddresses most of the recent comments from Carsten and Klaus.


Reg= ards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovat= ion Lab, Kolkata, India
Tata Consultancy Services Limited
Mailto: abhijan.bhattacharyya@tcs.com=
Website: http://www.tcs.com
= ____________________________________________
Experience certainty. IT Se= rvices
Business Solutions
Consulting
_____________________________= _______________


-----Forwarded by Abhija= n Bhattacharyya/KOL/TCS on 10/10/2013 12:41AM ----- =
To: Abhijan Bhattacharyya <abhijan.bhattacharyya@tcs.com>, So= ma Bandyopadhyay <soma.bandyopadhyay@tcs.com>, Arpan Pal <arpan.pa= l@tcs.com>
From: internet-drafts@ietf.org
Date: 10/10/2013 12:36AM=
Subject: New Version Notification for draft-tcs-coap-no-response-option= -04.txt

http://www.ietf.org/interne= t-drafts/draft-tcs-coap-no-response-option-04.txt
Status:   &nb= sp;      http://datatracker.ietf.org/doc/draft-tcs-coap-n= o-response-option
Htmlized:        http://tools= .ietf.org/html/draft-tcs-coap-no-response-option-04
Diff:   &nb= sp;        http://www.ietf.org/rfcdiff?url2= =3Ddraft-tcs-coap-no-response-option-04

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

&nbs= p;  This draft introduces a header option: 'No-Response' to suppress   responses from the receiver and discusses exemplary use case= s which
   motivated this proposition based on real experience= . This option
   also provides granularity by allowing suppres= sion of a typical class
   or a combination of classes of resp= onses. This option may be
   effective for both unicast and mu= lticast scenarios.

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


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

The IETF Secretariat

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

--=_alternative 00699A0D65257BFF_=-- From prvs=987082501=abhijan.bhattacharyya@tcs.com Wed Oct 9 12:35:34 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE3121E8194 for ; Wed, 9 Oct 2013 12:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFLWMLkIqsQk for ; Wed, 9 Oct 2013 12:35:29 -0700 (PDT) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id CBE8821E81AD for ; Wed, 9 Oct 2013 12:35:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,1065,1371061800"; d="scan'208";a="458505085" Received: from INKOLSALDLPMTA1.india.tcs.com (unknown [127.0.0.1]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id 3F501DAC12; Thu, 10 Oct 2013 01:05:23 +0530 (IST) Received: from InKolM02.tcs.com (unknown [172.18.18.104]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id 032BADAC02; Thu, 10 Oct 2013 01:05:23 +0530 (IST) MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: , From: Abhijan Bhattacharyya To: Klaus Hartke Message-ID: Date: Thu, 10 Oct 2013 01:05:17 +0530 X-Mailer: Lotus Domino Web Server Release 9.0HF507 August 20, 2013 X-MIMETrack: Serialize by Notes Server on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 10/10/2013 01:05:17, Serialize complete at 10/10/2013 01:05:18, Itemize by Notes Server on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 10/10/2013 01:05:18, Serialize by Notes Server on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 10/10/2013 01:05:19, Serialize complete at 10/10/2013 01:05:19, Serialize by Router on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 10/10/2013 01:05:22, Serialize complete at 10/10/2013 01:05:22 Content-Type: multipart/alternative; boundary="=_alternative 006B9A0E65257BFF_=" Cc: Arpan Pal , "core@ietf.org WG" Subject: Re: [core] Fw: New Version Notification for draft-tcs-coap-no-response-option-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 19:35:34 -0000 --=_alternative 006B9A0E65257BFF_= MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Claus, First of all, thanks for your detailed feedback on the draft. =A0We would l= ike to clear the fact that this option is no way conceived as a substitute = to the versatile and "well thought of" resource-observe option. However, th= ere may be certain situations where the No-Response option may appear as a = more lightweight way of performing stuffs with lower complexity.=A0 Addressing comments from you and Carsten, we have submitted a new version o= f draft which is available at:=A0=A0http://tools.ietf.org/html/draft-tcs-co= ap-no-response-option-04 Requesting your feedback on this version please. Also, let us =A0address some of your queries/ comments here: >=A0* How does it work across proxies? > For example, normally a proxy is free to satisfy a request as it sees > fit; is a proxy required to include the No-Resp option in its request > if the original client doesn't want a response? What should happen > when a proxy does not implement the option? This option is presently NOT to be forwarded by proxies and hence no cachin= g. We have explained this in the text below Table 1 in section 4. However, = this issue can be kept as an open question for experts to comment on.=A0 >=A0* I'm not sure what a No-Resp option in a notification/response does. > If a message is non-confirmable, then there is already no message > coming back from the recipient. This option has no effect for notifications. Examples in the previous versi= ons created the confusion. Requesting you to please check the section 5.2. >=A0* Regarding high-frequency/real-time updates: Just because the sender > does not have to wait for a response doesn't mean that it can send as > frequently as it likes. Since there is no return traffic from the > recipient, the sender cannot monitor packet loss and cannot estimate > the RTT. This means the sender "SHOULD NOT send more than one UDP > datagram every 3 seconds, and SHOULD use an even less aggressive rate > when possible." (rfc5405) Yes. What we mean is that this option gets rid of the dependency on the rev= erse path completely where possible. The application is free to choose the = update rates according to the system being developed (abiding by the prescr= ibed bounds). >=A0* There is no need for short option names, since the names are not > included in the message. Why not "No-Response"? Or maybe > "Response-Filter"? Agreed. Reflected in the present version. Carsten already commented the sam= e. "Response-Filter" is lucrative, but we are keeping "No-Response" for now= to maintain the consistency. Further name changes can be taken up later. >=A0* Is the option intended to be critical or elective? Elective. This was already mentioned in the draft. But not in the standard = way of CoAP spec. We have modified the table format. please check Table 1. >=A0* If, for example, only 2.xx responses are suppressed and an error > occurs, the non-confirmable 4.xx/5xx response could get lost. This > could leave the impression that the request was successful. It might > be worth pointing out that this is not the case. >=A0* How does a sender detect if it's sending its data to a recipient > that is long gone? Addressed these points. Please refer to the enhanced implementation note in= section 4.1 >=A0* Should a recipient be able to detect if consecutive messages were reo= rdered? Keeping this open. Would be good if we get some expert comments. >=A0* There is no need to distinguish between a 0-byte/empty value and the > 1-byte value 0b00000000. Both encode the same uint. >=A0 Accepted. Received same comment from Carsten. >=A0* The bit field (table 3) could be slightly simplified by setting the > bits according to the response classes: >=A0 > 00000000 suppress all responses > 00000010 allow 2.xx > 00001000 allow 4.xx > 00010000 allow 5.xx Accepted. Reflected in the draft. Please check modified table 3. In fact th= is scheme will have one far-sighted advantage. This keeps the option open f= or incorporating 3.xx responses as well if required in future. Recently was= hearing few conversations on 3.xx responses though actions on that does no= t seem imminent. >=A0* "Thus, if the client decides to open up the responses for errors > (4.xx & 5.xx) then it has to wait for the entire time-out period" -- > CoAP does not define a time-out period for responses, only for > acknowledgements/resets. Definitely not specified by CoAP. The term 'application specific' was missi= ng. Please refer to the new description. >=A0* When can the token in a request with No-Resp option be reused? Again, keeping it open for now. >=A0* The path and query in the example in figure 3 should be split in > multiple options: >=A0 > Uri-Path: "insertInfo" > Uri-Query: "VehID=3D00" > Uri-Query: "RouteID=3DDN47" > Uri-Query: "Lat=3D22.5649015" > Uri-Query: "Long=3D88.4103511667" > Uri-Query: "Time=3D2013-01-13T11:24:51" Addressed. modified accordingly. Please check new figure 3. Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Limited Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ -----Klaus Hartke wrote: ----- To: Abhijan Bhattacharyya From: Klaus Hartke Date: 10/08/2013 06:33PM Cc: "core@ietf.org WG" , Arpan Pal Subject: Re: [core] Fw: New Version Notification for draft-tcs-coap-no-resp= onse-option-03.txt The idea of suppressing responses has been floating around for some time, so it's good to see that someone finally started to write it down. I've got a few comments/questions: * How does it work across proxies? For example, normally a proxy is free to satisfy a request as it sees fit; is a proxy required to include the No-Resp option in its request if the original client doesn't want a response? What should happen when a proxy does not implement the option? * How does it interact with caches? For example, if there is no response, cache entries do not get invalidated; is this intended? * I'm not sure what a No-Resp option in a notification/response does. If a message is non-confirmable, then there is already no message coming back from the recipient. * Regarding high-frequency/real-time updates: Just because the sender does not have to wait for a response doesn't mean that it can send as frequently as it likes. Since there is no return traffic from the recipient, the sender cannot monitor packet loss and cannot estimate the RTT. This means the sender "SHOULD NOT send more than one UDP datagram every 3 seconds, and SHOULD use an even less aggressive rate when possible." (rfc5405) * There is no need for short option names, since the names are not included in the message. Why not "No-Response"? Or maybe "Response-Filter"? * Is the option intended to be critical or elective? * If, for example, only 2.xx responses are suppressed and an error occurs, the non-confirmable 4.xx/5xx response could get lost. This could leave the impression that the request was successful. It might be worth pointing out that this is not the case. * How does a sender detect if it's sending its data to a recipient that is long gone? * Should a recipient be able to detect if consecutive messages were reorder= ed? * There is no need to distinguish between a 0-byte/empty value and the 1-byte value 0b00000000. Both encode the same uint. * The bit field (table 3) could be slightly simplified by setting the bits according to the response classes: 00000000 suppress all responses 00000010 allow 2.xx 00001000 allow 4.xx 00010000 allow 5.xx * "Thus, if the client decides to open up the responses for errors (4.xx & 5.xx) then it has to wait for the entire time-out period" -- CoAP does not define a time-out period for responses, only for acknowledgements/resets. * When can the token in a request with No-Resp option be reused? * The path and query in the example in figure 3 should be split in multiple options: Uri-Path: "insertInfo" Uri-Query: "VehID=3D00" Uri-Query: "RouteID=3DDN47" Uri-Query: "Lat=3D22.5649015" Uri-Query: "Long=3D88.4103511667" Uri-Query: "Time=3D2013-01-13T11:24:51" As an observation, non-confirmable PUTs with No-Resp option seem to provide a similar service as draft-ietf-core-observe, but much more lightweight. When comparing the two approaches, it's clear that No-Resp appears that way because -observe simply does a lot more: -observe scales from a single recipient to huge numbers of recipients by the use of proxies, implements congestion control, detects when recipients are gone, and provides message reordering detection. Most of this was formulated by the working group as a strong requirement for -observe. However, when people bring up the idea of suppressing responses, they are usually happy to give up all of this. That puzzles me. Best regards, Klaus On 8 October 2013 13:22, Abhijan Bhattacharyya wrote: > Dear All, > A new version for the No-Resp option is uploaded. This version tries to > address all the comments received on the last version. The key modificati= ons > in this version are as below: > > 1. A guideline on applicability of this option with the 4 REST methods is > provided > 2. Interpretation of the 1 bit option values is changed > 3. The examples section is re-organised and 2 examples with POST is > incorporated > > Regards > Abhijan Bhattacharyya =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D Notice: The information contained in this e-mail message and/or attachments to it may contain = confidential or privileged information. If you are = not the intended recipient, any dissemination, use, = review, distribution, printing or copying of the = information contained in this e-mail message = and/or attachments to it are strictly prohibited. If = you have received this communication in error, = please notify us by reply e-mail or telephone and = immediately and permanently delete the message = and any attachments. Thank you --=_alternative 006B9A0E65257BFF_= Content-ID: <> MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
<= font size=3D"2" style=3D"font-family: arial, helvetica, sans-serif;">Hi Cla= us,
First of all, thanks for your detailed feedback on the draft.  We = would like to clear the fact that this option is no way conceived as a subs= titute to the versatile and "well thought of" resource-observe option. Howe= ver, there may be certain situations where the No-Response option may appea= r as a more lightweight way of performing stuffs with lower complexity.&nbs= p;
 http://tools.ietf.org/html/draft-tcs-coap-no-response-option-04

Requesting your feedback on this version please.

Also, l= et us  address some of your queries/ comments here:

>=  * How does it work across proxies?
> For example, normally a pr= oxy is free to satisfy a request as it sees
> fit; is a proxy require= d to include the No-Resp option in its request
> if the original clie= nt doesn't want a response? What should happen
> when a proxy does no= t implement the option?

This option is presently NOT to be forwarded by= proxies and hence no caching. We have explained this in the text below Tab= le 1 in section 4. However, this issue can be kept as an open question for = experts to comment on. 

> * I'm not sure what a No= -Resp option in a notification/response does.
> If a message is non-c= onfirmable, then there is already no message
> coming back from the r= ecipient.

This option has no effect for notifications. Examples = in the previous versions created the confusion. Requesting you to please ch= eck the section 5.2.

> * Regarding high-frequency/real-= time updates: Just because the sender
> does not have to wait for a r= esponse doesn't mean that it can send as
> frequently as it likes. Si= nce there is no return traffic from the
> recipient, the sender canno= t monitor packet loss and cannot estimate
> the RTT. This means the s= ender "SHOULD NOT send more than one UDP
> datagram every 3 seconds, = and SHOULD use an even less aggressive rate
> when possible." (rfc540= 5)

Yes. What we mean is that this option gets rid of the dependency on = the reverse path completely where possible. The application is free to choo= se the update rates according to the system being developed (abiding by the= prescribed bounds).

> * There is no need for short opt= ion names, since the names are not
> included in the message. Why not= "No-Response"? Or maybe
> "Response-Filter"?

Agreed. Reflected i= n the present version. Carsten already commented the same. "Response-Filter= " is lucrative, but we are keeping "No-Response" for now to maintain the co= nsistency. Further name changes can be taken up later.

>&nbs= p;* Is the option intended to be critical or elective?
Elective. This = was already mentioned in the draft. But not in the standard way of CoAP spe= c. We have modified the table format. please check Table 1.

&= gt; * If, for example, only 2.xx responses are suppressed and an error=
> occurs, the non-confirmable 4.xx/5xx response could get lost. This=
> could leave the impression that the request was successful. It mig= ht
> be worth pointing out that this is not the case.

> * How does a sender detect if it's sending it= s data to a recipient
> that is long gone?

Addressed these points= . Please refer to the enhanced implementation note in section 4.1
> * Should a recipient be able to detect if consecutive messages= were reordered?
Keeping this open. Would be good if we get some exper= t comments.

> * There is no need to distinguish b= etween a 0-byte/empty value and the
> 1-byte value 0b00000000. Both e= ncode the same uint.
> 

Accepted. Received same = comment from Carsten.

> * The bit field (table 3) could= be slightly simplified by setting the
> bits according to the respon= se classes:
> 
> 00000000 suppress all responses
> 0= 0000010 allow 2.xx
> 00001000 allow 4.xx
> 00010000 allow 5.xx<= /font>

Accepted. Reflected in the draft. Please check modified table 3. In fac= t this scheme will have one far-sighted advantage. This keeps the option op= en for incorporating 3.xx responses as well if required in future. Recently= was hearing few conversations on 3.xx responses though actions on that doe= s not seem imminent.

> * "Thus, if the client decides t= o open up the responses for errors
> (4.xx & 5.xx) then it has to= wait for the entire time-out period" --
> CoAP does not define a tim= e-out period for responses, only for
> acknowledgements/resets.
= Definitely not specified by CoAP. The term 'application specific' was missi= ng. Please refer to the new description.

> * When can t= he token in a request with No-Resp option be reused?
Again, keeping = it open for now.

> * The path and query in the ex= ample in figure 3 should be split in
> multiple options:
> = ;
> Uri-Path: "insertInfo"
> Uri-Query: "VehID=3D00"
> Ur= i-Query: "RouteID=3DDN47"
> Uri-Query: "Lat=3D22.5649015"
> Uri= -Query: "Long=3D88.4103511667"
> Uri-Query: "Time=3D2013-01-13T11:24:= 51"

Addressed. modified accordingly. Please check new figure 3.<= /font>


Rega= rds
Abhijan = Bhattacharyya
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services Limite= d
Mailto: abhijan.bhattacharyya@tcs.com<= br>Website: http://www.tcs.com
____________________________________________
<= font face=3D"Verdana, Arial, Helvetica, sans-serif">Experience certainty. I= T Services
= Business Solutions
Consulting
____________________________________________

-----Klaus Hartke <hartke@tzi.org> wrote: -----
To: Abhijan Bhattacharyya <abhijan.b= hattacharyya@tcs.com>
From: Klaus Hartke <hartke@tzi.org>
Da= te: 10/08/2013 06:33PM
Cc: "core@ietf.org WG" <core@ietf.org>, Arp= an Pal <arpan.pal@tcs.com>
Subject: Re: [core] Fw: New Version Not= ification for draft-tcs-coap-no-response-option-03.txt

The idea of suppressing res= ponses has been floating around for some
time, so it's good to see that = someone finally started to write it
down.

I've got a few comments= /questions:

* How does it work across proxies?
For example, norma= lly a proxy is free to satisfy a request as it sees
fit; is a proxy requ= ired to include the No-Resp option in its request
if the original client= doesn't want a response? What should happen
when a proxy does not imple= ment the option?

* How does it interact with caches?
For example,= if there is no response, cache entries do not get
invalidated; is this = intended?

* I'm not sure what a No-Resp option in a notification/res= ponse does.
If a message is non-confirmable, then there is already no me= ssage
coming back from the recipient.

* Regarding high-frequency/= real-time updates: Just because the sender
does not have to wait for a r= esponse doesn't mean that it can send as
frequently as it likes. Since t= here is no return traffic from the
recipient, the sender cannot monitor = packet loss and cannot estimate
the RTT. This means the sender "SHOULD N= OT send more than one UDP
datagram every 3 seconds, and SHOULD use an ev= en less aggressive rate
when possible." (rfc5405)

* There is no n= eed for short option names, since the names are not
included in the mess= age. Why not "No-Response"? Or maybe
"Response-Filter"?

* Is the = option intended to be critical or elective?

* If, for example, only = 2.xx responses are suppressed and an error
occurs, the non-confirmable 4= .xx/5xx response could get lost. This
could leave the impression that th= e request was successful. It might
be worth pointing out that this is no= t the case.

* How does a sender detect if it's sending its data to a= recipient
that is long gone?

* Should a recipient be able to det= ect if consecutive messages were reordered?

* There is no need to di= stinguish between a 0-byte/empty value and the
1-byte value 0b00000000. = Both encode the same uint.

* The bit field (table 3) could be slight= ly simplified by setting the
bits according to the response classes:
=
00000000 suppress all responses
00000010 allow 2.xx
00001000 allo= w 4.xx
00010000 allow 5.xx

* "Thus, if the client decides to open= up the responses for errors
(4.xx & 5.xx) then it has to wait for t= he entire time-out period" --
CoAP does not define a time-out period for= responses, only for
acknowledgements/resets.

* When can the toke= n in a request with No-Resp option be reused?

* The path and query i= n the example in figure 3 should be split in
multiple options:

Ur= i-Path: "insertInfo"
Uri-Query: "VehID=3D00"
Uri-Query: "RouteID=3DDN= 47"
Uri-Query: "Lat=3D22.5649015"
Uri-Query: "Long=3D88.4103511667"Uri-Query: "Time=3D2013-01-13T11:24:51"


As an observation, non= -confirmable PUTs with No-Resp option seem to
provide a similar service = as draft-ietf-core-observe, but much more
lightweight.

When compa= ring the two approaches, it's clear that No-Resp appears
that way becaus= e -observe simply does a lot more: -observe scales from
a single recipie= nt to huge numbers of recipients by the use of
proxies, implements conge= stion control, detects when recipients are
gone, and provides message re= ordering detection. Most of this was
formulated by the working group as = a strong requirement for -observe.

However, when people bring up the= idea of suppressing responses, they
are usually happy to give up all of= this. That puzzles me.

Best regards,
Klaus


On 8 Octob= er 2013 13:22, Abhijan Bhattacharyya
<abhijan.bhattacharyya@tcs.com&g= t; wrote:
> Dear All,
> A new version for the No-Resp option is= uploaded. This version tries to
> address all the comments received = on the last version. The key modifications
> in this version are as b= elow:
>
> 1. A guideline on applicability of this option with t= he 4 REST methods is
> provided
> 2. Interpretation of the 1 bi= t option values is changed
> 3. The examples section is re-organised = and 2 examples with POST is
> incorporated
>
> Regards> Abhijan Bhattacharyya

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

--=_alternative 006B9A0E65257BFF_=-- From schmitt@ifi.uzh.ch Thu Oct 10 04:15:50 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFCF621E809E for ; Thu, 10 Oct 2013 04:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.036 X-Spam-Level: X-Spam-Status: No, score=-5.036 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_IMAGE_ONLY_28=1.561, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlWCw5QdXpg0 for ; Thu, 10 Oct 2013 04:15:46 -0700 (PDT) Received: from ladislav.ifi.uzh.ch (ladislav.ifi.uzh.ch [130.60.156.19]) by ietfa.amsl.com (Postfix) with ESMTP id E8EA821E8106 for ; Thu, 10 Oct 2013 04:15:41 -0700 (PDT) Received: from authenticated sender schmitt by ladislav.ifi.uzh.ch (postfix) with ESMTPSA id SA; <5E29B76098> Message-ID: <52568C5C.8050205@ifi.uzh.ch> Date: Thu, 10 Oct 2013 13:15:40 +0200 From: "Dr. Corinna Schmitt" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "cabo@tzi.org" References: <8896EFF2-BD1E-4634-8195-34580E1096F0@tzi.org> In-Reply-To: <8896EFF2-BD1E-4634-8195-34580E1096F0@tzi.org> Content-Type: multipart/alternative; boundary="------------060504080105030603040702" X-Virus-Scanned: clamav-milter 0.97.6 at ladislav X-Virus-Status: Clean Cc: core@ietf.org Subject: Re: [core] Travel planning: some CoRE-AA work on Sunday, Nov 3rd X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 11:15:50 -0000 This is a multi-part message in MIME format. --------------060504080105030603040702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Dear Carsten, as mailed to you some weeks ago I will come to Vancouver on Friday, November 1st. I have already some appointments scheduled at the weekend before IETF 88. Thus, it will be nice to have some more information of your planned AA meeting (schedule, location), because we are involved. Do you have some updates for the meeting you announced? Is there a presentation requested concerning our AA work at University of Zurich? We will update our current draft " draft-schmitt-two-way-authentication-for-iot-00" within the next days. When will be the detailed schedule for IETF CoRE - Meetings available? Regards, Corinna Am 11.09.13 15:24, schrieb Carsten Bormann: > (CoRE = Constrained RESTful Environments, the application protocol work for the "Internet of Things".) > > For those that are interested in the CoRE Authorization work that started in Berlin, and that haven't already booked their Vancouver flights: > > We are planning some informal technical discussion in Vancouver on Sunday, Nov 3rd, starting about noon. > The objective is to achieve mutual understanding of the technical approaches and maybe some merging/taxonomizing of those. > The objective is expressly not to discuss how to do this work in the IETF (rechartering? BOF?), that must come after understanding what it is that we want to achieve. > > This informal meeting will have a strong "we assume you have read the drafts" component, but otherwise open to all interested attendees. I'm CCing SAAG because this isn't strictly an applications area subject. (There sure will be a lot of interest in other aspects of applications area security in Vancouver, as well...) > > Details of the meeting (drafts to read, agenda, room, etc.) will emerge soon. > > Gre, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > -- --------------060504080105030603040702 Content-Type: multipart/related; boundary="------------000802080706040803080708" --------------000802080706040803080708 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear Carsten,

as mailed to you some weeks ago I will come to Vancouver on Friday, November 1st.  I have already some appointments scheduled at the weekend before IETF 88. Thus, it will be nice to have some more information of your planned AA meeting (schedule, location), because we are involved.

Do you have some updates for the meeting you announced?
Is there a presentation requested concerning our AA work at University of Zurich? We will update our current draft " draft-schmitt-two-way-authentication-for-iot-00" within the next days.

When will be the detailed schedule for IETF CoRE - Meetings available?

Regards,
Corinna


Am 11.09.13 15:24, schrieb Carsten Bormann:
(CoRE = Constrained RESTful Environments, the application protocol work for the "Internet of Things".)

For those that are interested in the CoRE Authorization work that started in Berlin, and that haven't already booked their Vancouver flights:

We are planning some informal technical discussion in Vancouver on Sunday, Nov 3rd, starting about noon.
The objective is to achieve mutual understanding of the technical approaches and maybe some merging/taxonomizing of those.
The objective is expressly not to discuss how to do this work in the IETF (rechartering? BOF?), that must come after understanding what it is that we want to achieve.

This informal meeting will have a strong "we assume you have read the drafts" component, but  otherwise open to all interested attendees.  I'm CCing SAAG because this isn't strictly an applications area subject.  (There sure will be a lot of interest in other aspects of applications area security in Vancouver, as well...)

Details of the meeting (drafts to read, agenda, room, etc.) will emerge soon.

Grüße, Carsten

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


--
--------------000802080706040803080708 Content-Type: image/png; x-mac-type="0"; x-mac-creator="0"; name="visitenkarte.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="visitenkarte.png" iVBORw0KGgoAAAANSUhEUgAAASgAAACgCAIAAAAw8WZPAAAAAXNSR0IArs4c6QAAAARnQU1B AACxjwv8YQUAAAAgY0hSTQAAeiYAAICEAAD6AAAAgOgAAHUwAADqYAAAOpgAABdwnLpRPAAA buNJREFUeF7t3Qe8FtXRP3CT901i2htTTVeTGE035Z+YZkxijFFjQcVKVXrvvffee6/Se+9I R0CahSqCgtJBQKTl/9099y4P9yIiEOXq83zwus8+Z8+ePTtzZs7Mb2Y+9p///OeKd/uMGTNm 5cqVWq1atWr//v3v1jz9e3oGPnIzcOWVV/7ud7/z2DfeeON9993n67tMAcZ7p8/s2bMfeeSR q666Skd14s/o0aOdTH/SM5CegSwzMHny5MAjWAbXYRnMcg7muuKsvz333HOuvPXWW59++ul9 +/ad4/r0T+kZSM9A9hnAdTjopptuwp9nnZ+zMB5mu/nmm8/Nr+m5Ts9AegbedQYIMNKLGMze MivjVa1alax866233rXTdIP0DKRn4HxmIOifWXjqDMbDdRqdOnXqZPqTnoH0DFyKGcBNmLNP nz40z1QuPc14NEx86bc0412KCU/3kZ6BaAYC4/k0adKEYEt4L4PxKKP2dUEaphkvTTLpGbhU M5AwHs4i2Ii3wHsZjJdq/bxgxsvk7XPovWkl9lK90HQ/OWMGUhlvx44d1157bRBvEeNxQdxx xx0Ju7wnxjtx4sTJEyeSa/fs2b1mzZrp06YPHzp02JAh/jmYOmUyifrGG28kzU6eyBmzlh5l egYucgZSGQ/9ly1btk2bNhmMh+vw3oUxXrhq586dkyZNatyoYY1q1apXq1anVq0G9eo1rFu3 ob/16tWrU6d61arVq1WvX6/+6FGjt219NVx1kY+Uvjw9A5f/DGRhvJdffpnQixiP4INNSbV1 no/EI+hsBl2/ffuOnj17li9XrmrlKhivaZMmXTt3fnrwoKlTpsyeNXvO7NnTp00bNnRoj27d WjRv3rhhw+pVq5cuWbpTx46bN28K7KerSGymP+kZ+DDOQBbGQ/CMKYsWLboiMWa+J4kXGGb0 qFHlypatVrVqy+YtunbpsnDBgtkzZo4bOzb7Jm/evGecX75sWa+ePTWuXatW2dKl+/fre/jw YY2PH08z3oeR6NLPlGLVTJgiIMuuCP9LZZVzSzwsovGunTsbN2pUsUKF5k2bDujf74Xnn8c8 zg8cMLBCuXKv79hhzhM5dvTo2y2bN2/YoMHxY8e12bhhw/BhQ1s0bVa1cuWaNWps2rgxrXam SfTDOgPZJV5Ak12RP39+3r3zZzwtX968mW5Zr27dNq3bLFiwYPOmTXv37Hb+hRdeaFCvfptW rVu1aJnwkoO5s+c4o/3gQQN9XfbssmeXLiX9Onbo0KhRw9IlSzr+b8i9YPi55IbU49aY4yfi 5enSKclRT8czPD5pj86HiAuzMx49k7Z5RRbLCgY4h8Tz6ytbtpQpXTrs5ba8vMWZwQMHkn57 du/R47/vvPPfd92FLZ0/cuTI4UOHHIwaOfLef//7zjvuaNWyha99+vRt3qz59te2b33llT69 e7do1qxYkaKB984x4cnSENqkPs/5X3VJXijGyzKYLF8v6C6RvvD228defOGFtWvWHHrzzfPZ aV/QjdIXva8zkJ3xgn3lCiDOLADqs77y2JryH5EKNnXNmzXr3Knj/v37aJj169WbMX0GY+bK 5cunTJ78VMGCRQsXLl60qM3bcyuemzljhqt6dutWMH/+J/PntxvkynDJvr372rZp88zcuW+8 /kbMe81Lliix5eWXw9Yxu63l2LHjSxYvNs6DBw8ans+xt48tXrSI8ebNN98860Rqc/To0WZN m+Z54vF169ZdQjrW1fLlyx95ODeJ/fbbb7u7UZHhe/fuveC7RPrC88/f8+9/f+H//u/zn//c nDlz0ur3+8of/7WbXSzjRULm5Ek806RxEzZJTNK5c+eXXnypdMlSFM6li5doMGHcuP59+w3q 379mjeq7du3EVBs2rHfjwQMGdOvSuX/v3jWrVX/z4MG9+/Y9u2RJm9athw8btmDe/Igze/Zs 3bKVHeORw4dTN4cZwu3kyTffPPSrm276whe+sHbN2iBe9u8/8LOf/vSLX/wipgpSOhB9+DU8 LSfHN77+dfGIvXr0SG2TCMxwSTI1CdtEfcVdht6yCFhnmjZpqtsfXn/9gQMHjr711r3/vucr X/7y2rXR2MJVZ3QV95X6ZrPcMQy+YIEC+rzt73+rVq3qhg0bLoyHQ1cXdu1/jfbesePsmsI7 jTx5rZdwkBc8S8mFyajO0VXyrpOHfW8Sz2Vjx4whslq3arV169Y1q1a3atmyc8eOc2bNInwi Ujt5EkNWrVK1ZvXq+fPmxZlUphnTp1PMGjdswOJSrXLlgvny7969J2KJN97ApdOnTp01c2bb 1m22b9/eoV077r4e3bpHhH6md+HUyVOHDh36xc9//vnPfU6fmYy3/yc//jH58NJLEeNl/3jg 48feHjt6NA5n7EkaBHF61kvCSfvC1F+1T7ZeCR/a5TZv3oKEj9ofP/HTn/7ks5/97OZYYqcS U1ATMroNojzlTJYx/PmPf/z85z+/efPm6PwF4dSzdHjBhBUT9wljiN7FRXzi53jHLXagyH37 9x858lbGHTMfIPWeYcYgLvbu3Xfs2LGLGE7GpfFDnX6lnvQ99RnGGAZ//Ngxo0rOvJPmleW9 nC/jRZR36hQzZrkyZVq1aLFkyeIN69e3b9vu9dffGDVixBtv7Iyf5MT+ffuKFylSqkSJ8mXL 3H7bbfx4M6ZNw0779u3Ndd99LCj8B84vmB+JuPBZtHDRYw8/XKRQ4SOHDlO0WjVv7vL16zdk ed/uTnH91S9vuuqqLwSp4rP/wIGf/exnX/rSlzZu2Lh39+4qVau0bNmCCM11/3333ntP/379 XMU52aN791q1a7GjEstFixV1d+dPHD9OSyxUqBDLELZp367dnf/61x3//CdPo02pBtOmTS1W tOjAAf1LlSzlV2cGDhjwQK5ct/7lFiYi82u0NarXGPL009aXEiVKkKsUxNy5czdu0mTcuHGF Cxfu0rmLnr2fiRMnPvXUU8xXpihsDnfseB2Q4K4777rvnnt5Vg4dPvzKK6+UKF7i29/+1he+ 8H+PPfaYTa+Rv1e20X79uvXlypUrUqRI2TJlFi9afDFsE+xSR986+p6IMkvjt98+ijTfiRxx Ea/Sr3716+B/Mn6zWqVKlddefTXLuvP6668/kvvhv9zyl02bIt/vxQzJteSEV/PSSy8VLVLE HSN6OG/W03j1qlVVqlTdtXMX/rnrzjvZJ+2ngEN2vrHzrK/swiVeWHL43+rWrt2zRw/W/0kT Jgzo15/EM61+Oha74Xbv2tm+bZsmjRsVL1KU0Js0aSK6rFK58p7du/kMKlUoX71K5SqVKs5N 2b34SbfPPbdy8qRJWzZvfnrQ4LatW9uVvSfG44hH/V/60hc/9alPfe5zn/vaV79KYSMJly5Z ao/32//3/3y1GwQMd/DUk0/pnF3nq1/56qc++ckVK1bQb50nTn/60586sINFA40bN3aMl/wl 5Ht07/Hxj30Md/36l78qXqyYHkYMH+Gnf99993MrVlxzzTWf/cxn3Vr7W//ylzGjR/vp61// OsuTSb/9H7f72r170HVPbtu69ZY//9mZL171RQNwULRoUUP97ne+S2aSeKT67f/4x6HDkVHq PVGY9rNmzvrSF7/YpHHjMqVKXfPda6ZNm5Zlrc0i6rN8zUIiDerXDyr6WT/n1hpcsn79+rxP PHFg//7kQbL0w/b2veuus0JFciymMWTg8VetXJml5cL5C0y+peTc488+zuxEbzdeIF++l154 ccf2HTVq1CRCAg4k++esklCzMaNGf/5zn31126vWi+98+9tbt24bOWK4YdsdnPWVXTjjedp9 e/dWrVyJL47DAJXXrlmT6HtlyytBbQsikfb49KBBxYoUQXwMJ+PHje3SqXPRwkU2b9zUskWL B+6/P+/jjzdt1IhBJfVNWOybN23WsWOHl1560Z6Q2aZyxYpbtkTG0sTEgmAPHz70q1/+8qpo j5epah7YHyQe3WzrK1u9wv/5n//B2mYk1/33h30dLedvf/3rlZ/6FPfFiuXLceP1P/gByCjx 9bGPfezRRx5hSkXuv/rVr55fu3b5s8u+/73vfeMb39i9a1e7tm01+OY3vwlzQw0mD3XYrGmz iHliNZXW/Yn//d+HHngAb6Own//sZ/afkDomgXB2U+179+q9Yd26r3z5K9ddey0pF15tgwYN /PTYo4/ywcycMfNb3/qmUS1auNBk/u63/w83mh/KxQVAeXTuWur3ju2vOc6fL999993rYNu2 baR0o0aNyA2moA4dOljsKlWsNH78eL+aPQxWoWLFCRMmWEb7+/Tt1759+759+qD13/z611On Th0zekzXLl3r16/ft29feweT7EldK+1VyxYtrarI9403XgdB7Na1K5EFR/HG66+b3s9+5jPl ypazGw+i4PChw927dStXrvzokSMJ/0YNG331K1955OFHwoZWhzOmT0PKq1etHjpsWLeu3WrX qt2nV6+XN7/M4/W1r32NimFuF8xfULlSJauz9/j2sbcZGgy1d+/e8+fPN+zWrVozmLOu165d u3//fnQMQrJevegBJ0+afOjNQ7ZCn/70p5944gnaVvfu3V/dts19bRkqVKjYuWMncqxbNMJy NlCJjhxeXLJDmThhwnXXXkOhe+CBB1CLm9Kzvvud79h9XGLGi5aiyZOrVanct3dvE2pZmj9v Xs/uPRgVkiXZxBFfdWvXKl2iBN4rWCA/bHTtGjWeeOzxhfPnFy1cqFTxElTNxx99ZN68eanj 8wLwkvfXrk1b74+QbNywkYmM22RoAIHxfnnTTV+86iq6QZiIAwcO/uynP2Nc2bRxE7fEtddc 861vfSvMY4Xy5RE3kJq3/feY8RZRKU+cuOOfd2AnXPf44499/OMfR08jRowgJ6+++ms/+P73 se6nr7ySyFm/bl37du31QNsM96pZvYavhEm+vHkxcMJ4D+bK5cEt2L/+1a8w3sYYCeDTqVMn 7b1dmqQDil+w1Wh5+23/+N///d+pk6eElsyYH7viiqcHD3Z8y5//5BZWorO+v3eVfq7CeD/+ 0Y3r173k2GMa1fbXXnvwgQdKly6NDRhvmIK+fvXX/3LLn8uXL2/GVj73HDpmMKtUsSLSIf// 9te/0R2KFyuKmH584423/f3v3pdrv//97wPhMiA98fjjjzz88E0///mePXtoB48/9pjO/3n7 7XT4z332s3nz5OFM+v3NN1tWSpUs8fWvX61zQsbg0bHjm37xi2rVql1//fVDhwxF93g7f778 mD+T8aYbxuqVq+jhN97ww6pVqnztq18Z0H+A4V199dWYbf78BT/+0Y95s/7+178ZCRv7d77z bbxqOaMrff6zn9X5jTfeYCbDJYTkvGeeiVaW+Hk5kO1Hrv7a14x85IgRX/7SlxYvXITrvPpy 5cv36dW7Vo2aP/3xT9q2aQvnGI04/jAH7tu7J1CjiaXu6Wr2rJkF8hf49je/2aNHjxGB8V6+ 1IxnUlq2bNmsSZNpU6fOnjWrQL78hZ58avOm6DanF+Z4E2jBo4K21rhp0+FDhloL8z6RZ+6c udAtlhOYsjq1a82de4ahXCe4ZdCAAVga3VAz3Kh+3bpvHz29u4j2eIcOeWfUuUQPsdx+77rv mcRXXtmC8a757ncxD1+iDpECcqcVZzDelVdivIgfOnZ03j7zuuuuu/GHN9iU2gqSk7RBK6tF vXevXkOGDLEussdoSVC4yt2ZdpiUCEYnTTrl3rJH4sWM58W8GUnjq64KyoYP6f31q6/+7ne/ S9H9zGc+E7TrsOdElJ/8xCdmTJseWt59190f//jHRg4fbtfxpz/+0TpCfl4s470UMR440c2/ +x3z1be+8Y3q1asRgN/51rc2rN/wk5/8JISE/b9f/waxejSbAjveb3/725jtnnvuKVuGsh19 /n3nXcC3DpB4sVjBxsl2sLSeG274oZf1oxtvLFKoEBFHsg0aOJA2sW7dehTyg+99nwCc/8w8 rLt7d4SsoBQdPHDA5W7kq/UrX958NpA//clPpkyaFJ7XX+IUBa9ZvcpiUalSJWd+8Yufe4/0 +R//6Edert3NH3//B+fnzpn9/eu+x8LHrNWhfdRnty5db/7dzQ6KFStaqlQpBz/76U+s4wcP HJw0cSK59K1vftMBU/uNN9yw6rmVa9aspoksXby4QH6mwLzhkd3rB9ddZ80KLOeVEQx5Hn+c HiHsJrTBeFh9x47t48aOY2nXDDE4c4kZz51wfO1aNQkBhIXErZED+/c/cvjIGVvJmPEG9OvH X3fLH/8oIqFVq1b0GS9m5PARsNF33XFH7vvvb1Cv7jPPnFY1g5pK139m9pxXX3112bPP2gKx x9SqWdNXUiJZ5smKe/59D7q3CmK5I2+9xQNBdPzpD384fPgI1RTjURR37dplwKVLl4kYr3v3 LIxHInmvn/zkJzEbQ5GWtsX/8z8f/8Pv/0DHCNO6d89ef1u1aqkHARaBJmgsDvCbd+a8NXLK pMmB8fhYvFpbxM9+9jMzZ8586+hRQ/VQeZ54gnS1M7zlT382gYm1wDvWAxsS4TNr1syvfvWr FNpNmzYee/voJWG8SNWMTbhUuHz58nF+WpuEokTaY9++r732Ggq2uGjw29/8Bh0XLlS40FOF xo8bT6ZhvHvvucci69djb79929/+1qhBzHiPPVayZElbod/+9rd0H4IRw8yZNfuGH/7Q47Rr 165bt+5Urx9eHzEeje5HN9zw+o7tkyZOuuGH16OKTMY7aHnq1DFikvzYLm9eKr3BkDxZGG/t mtUYj2LpjtScXj17zJ8/z8xDbjA7sf1qz8/pdbNzSOM1NrbNWDdN4FtH3ipSuIi1wBnXDh40 GF8xoowbN55YmzB+PDObBZqoF7x23XXXLlm0mJvXJ7x9HwqdJZ5QDZYwBGrPXLBgweBAThiP Yd80/uJnP7eg6Pa/wnicdZUqVOzfty/RRJR5+LlxxrIzlJ9Tp6KtUes2jz/yCFNPoSefZLKz DbUXomHmfeLx+++55+EHHyhVongWVRNOSle8eeXLlitbqvTLmzaNGDacO962J7lFsO7QDEkP VGtl/fGPf+yAAAxKmhWBpkcR4rjz9amnCvm1U4cOGA95OZ4XbywjGnr8CV/pmfNj/yEevuvO aP/2zW9886+33oqSbM8MqWmTyLjCrBKuMvV/+P3v//ynPzn585/93F2gwx3f8c/bI9Pf0bf/ cdttvtqxMI1SuV1Cif30p690I8SdPIiDCRMm2ohrHGm2n/50tHVsEhmT7F5wL15lbcs6t++q ZcYNXEXaXPWF/6tRowat8qc/+TGf/ltHjtx9513snLiOZ4V8u+GGG/51xx3aWIOsoZ733nvv bdSwodEOHjTI17qxnCeBWYft8ZYsWfLQgw8SmJw6P/zh9XCGzlAR1730Em7MlStXv379vYXF ixfT3J5f+/zY0WO+8bWrX3t1m/0IzblunXp8sJH0OHnKevrLm36h/x98/3vDhgy1xuknvMEw /kzjynN01zKly7iEUIpcVnNm2w6w6onq5DtlD/vHP/7x8MMP79u3n6pJrLmWfmg5sI1kFi5e vDgWcS0VhsXBIBs2aGjHMWrkKHa1a7/73WJFi8nR/OUvfXHJokVI9Jvf+EaFCuXJTLLOpvHv f/ubBciON4iWQAPJMaqmVFvr+/Xrd813vst6BJjlzMZNZ4ccX6BxxS3ZAJh9Md7G9etNk72s dTSb5fTU3j17atWoQdvs368/QUdjHD923LgxY7t37fbEo4/16tnLDpjUpnNnIayYc9bPmTnr 1a1bEcrkiROrValii5jaLIwe7z36yKM0qN/f/DtK7MQJE6MZOXmS6YLW7n1gJC3tCiypqJCk kujCcsXOHhlFTv0H0gUNiRikT4Y+Ga8xmLn+/e9+h23sNo8fP0am5c2Td9SokWHSeRSQoAW1 RPHiwYPPKmMppQVYF/XDfkhJ++Mf/mBxpXlqsPWVLV48gYYWkwcJkpPZ84FcD+jt3nvu7dun L/Jykt7VsH59BEFeZZvb8+O8k6dsd2vWqFmmTBnvi0IY6AWJoHVCb8yoUXjg5z//ueelyJFv brRi+YqKFSsxhjVv3gwcp1evXjNmzAz384y2RowrWo6MzSFt2rTlzrELbdq0KdXLbNNrSpcq jb6Z3CxPFDANoAvsAL3KLp0716hZ004s2SzR9umBQ4cMiZTPgwebNWuGl8Lz+mvRsR/zRiwT 4ydMwPyWLZYSYkqfNiMeiOOX8QPgnvT2pnhTV65cpQOLSPv2Hdgdhg0bzt5o9SS6Vz5na7Ky YsWK7dq2a9q0mS+nTp4YNmxo5cqV586d26RJ02ARwUulSpVs2aI5FjJ7xhC2nYnCmbxBJ9nh 2Jm4o5cvX4ZaQD4YKfiHdu7cddYXd+GMN2rkCM9pO2TG+/XpQzcI+JIsH9qzrVqgVK+qZ4/u S5csYSgfO2Yswg3nWVCQfhbGMzKq4+yZszp16EiVJbgtwEwj2ZuFTuyUCJlwHCGLjx9PlqXw Nfzk48WEg6AuZsdYnnFh7BqJrzrt9c6Yej6tlMspk4Fb4saZ3Ub++miNDOexPVMNs0TcQ4aV KBpqpgNdJ8k4Q4vw9UK57mTq06VOTnIXB5Re3kJrfGaD03OV2syDhDiSM06mTGY0pbGqknxQ aXwy4yniB8qYRi/Fw3oXqSSYiiXIJKSM9kmz5InCGV1mecbk/SYHJzIHGRxd2T/ZZyk1f0Jq e2/8bAve6YfKmMNMensnxPyFM97oUSObNGw4aOCANatXYyFCL9ipsjLe668PHjjA4rRg3ryh Q4dWLF/e1q5e3ToWcraKFcuWPb92DRGRnfEisjtxgnmDJ501zBJr09+hfcSrZ9wiepWR3yKF QDOwIGG9DCQb+zair5nH0fnIG5wZphS3cybTaXoiK946/JTKAKk3DbfMaKCnTIdK8s7sdkDG f/Ob3/zPxz8ePGkp98q4NpXlkmdMHuFs7/t8zp3hBs4YZ+QGP33ezpxxclkmHj1pk9F7ZsvM Z8zwFWUAieKOwin/S+YhzHP0Y+bf1DPJcWr7cDJz6s71aPFbzHiEjDd4+sKMyYxXtvCM8WsO RynPknqD0/fNPJs8Vvxc5+tKT52qcNMwK9kf5mIYb0STBg1sABg/+vbuQ1PasX171oX51Enb 6B7du61du2bJ4iV0D1av4sWK534oN92M089+w1aYNynVgR5GqSsrIhvM1MmT165ebXfets3Z GO98aO+cbc4hTM4qbcKUZZ+45GTWu8XtOSHs3Ig7bqjwdBc98EvWQdhRx+p5+vM+zcDFMN4o sqtf374vb9o8fOgwaiToY3Z6YlRo3KD++LFjJk2YaBNFarEWCH+gNDLiUbvpkFx8z8zNsseL hJgOqZqCD2wbJowf53bAIqkSL2gyWT6xKHv3JSqs08m1Z7kkFqRZnyhDrGUsDUGlJCoTXora x4tw6gt0jl4wfuzYZUuXXjzW8ZKTRliUz2fSLvmtP7IdXjjjzZo1i0fO7o6Jn1zCVCReNhTv qZ2vvzH06aeZJWV5GD9u3HPPrWCoFezHz8bzvmTxInFmAVR9pg4ZEf3uXbsF+DVt3Hj5smep alUqVZaeLGmGUN566whQKLACRJx/0f9ff8NW0xJ+Pm/Utg0yo0XzFnrI3p6tr3jRYpCWYJ8Z N7UTO3Vq5vTpDRvU50WwdWbCejh3boYZXgoGJCsFW47gpuyyI3V1OJ+xpdt8uGfgwhnvpRdf tGGjZLKckntVK1WGLcimap7avXNnm9atGJHZLZk07QnFH4wYPnzqlEnMaM/MmQPCUrlChSyq Jqai+SyYP09L1iHBdazD3AlgRwnjOXj22We5azm+v/+979/wwxt++hPW8p+wPmfdB57tHWoD z816TgPs0L79GZfEu8ED+w/w7TA3c9QGPSwe1X969+x19113Pf/883//298pzLkffIiVuU2r Vjf/9ndQS4zXwXvx4aab9NNd5AxcIOPZtRAIsGAd2rWN4NETJ/bt1WvksGEg3ll4jx8PQgUQ wVatXp3anTq0nzVj+qwZM8SniwmaOmnStMmTy5YqlYrVjLekkcmLnXfixEmECfNuuzZtuCX4 W1IZD1CLP5S/FSry+ut/wOuNi8ZPiNCG4RPUp3DM4JYchzMEJgt7rvtzrVq5KiiHqXKJD5SR nRvQEpN6vl+fvgBQrOr/uO0f856ZB3ixcOHC3j17Yjnu6V/8/BfBX3+RLyZ9+Yd7Bi6Q8QKN Mkvy0tDWGC25E3r16EmyZaE5+h/n2/wFCwYNGkQWsX/CxYEOtG/Tlpth3JgxrNhdO3cJ+Npk rh2/+MKLTRs3nT59OifysqXPRpCxevXejhDrGa0i5nz7bcIQcAyUjDMN1/3zn/90hhWUX5GM 1fTwkUP82pHR9QDZvA+wYMaM6Ry7RiKGCMNjpNdf3xFQzgsWzHeeXxV4JUBPOHO576iRTViA ZkcgL+VvwRpvu+22alWr0YS5vAsXKgTnTYCDlYJZ7ty1K0H0fbipJ/10FzwDF8V406dOg9Vi q+QlB03gN0wiwRMRQeJhMHEMUPDQJ3yRi+3rnn8eAA9Kk1bmQxcNEi/1s2fvXszTulVLTmeQ P7Z4PsNEiMVSMXrqcAlNVYwCkMRS1ov//IfqG8D+jnfv3oU3YAi2bttmt/blL38ZWpIL+9NX fgrAh5aoZfC589sKSvDVBzrp0KHDv/zlLwU6XHvtNeGk2KJFcTwbvzAMDe824QZ8LNo92l/u 3MlRy88bocMu+IWkL/xozMCFM575sQsSWQdrv3DBQqSPjnUnxiR8jsrRc+zY9ldf4zSHwo/5 oQ/XeWAVYTUCTMMxYRLhvk+eDFfF/44GnyZLyboXX6SsVixfAWIzizh1iX7hG/9yyy0YI8lH OGDAAF/hVLS3KED04UlGIJLQpg4CS0YZ64ULBSx+/H8+PmvGTKoj5gTvgquIIi3mz+eWxHga 61zyeVApfYK8ZFkgsn+9rFwFHw0yznlPeeGMFywNZAvjXpVKlbgHunfp2kUIXdu2Hdu3jw/a AUbyH1SqUKFzhw7du3QRU2eb17VTpy6dOrVs1kxcpgP/BA3Vr1vHgWtdqLEDpk6XQ8oBKHVo 115wQ3auCxIPCAhL/O63v2MFDWwwcOBAZ4SWOBa7ASKMozIZ79uEHkSSn/D2vffe94lPfILH AtzUJaVKlEwYiWYKF0sGBldHk0YRUDOEJuS895we8WU2AxfOeIHoyROM0axxYzF1AszBncFZ alStWrJYcdgUdsiSJYqTV+wiUoxxxLVo1hSXVqxQ3p4NrlrqB9wovV+F8uVEo8vCAjztwJap fNmyMtuKCxbhDvgXAo5SZy+IRKBHGHAIY3HWCc9AtWKSggUKOmNrx/KZMJ4wEPbPkOKFQBYV ivHIW+nMXAKV5nyYFPKQpcSFIdhPUJIGHirNeJcZDefI4VwU4wXeY9IUEsrMwJjO9gjNLEpN zPi0KVMdkCQTxk9wnsSgjjKW3HfPPYLBxRAJNxRiSLUTAFq3Th0ijspXl+WzY0cxfngAZzYS zFi/PvuHG2X18J44CZ4pegM/PFmwIMuJVWDXrt3YyW7QSeGYrqI3iuYWBRMkHsZjBQ3xYIHx /vcT/wtC2bB+FAPONBJyfjLb4NjAeHzfacbLkdR9GQ/6Yhkv5r1TjRs1Jgrq1a3HrMevBRVF HEWwzMaN+bKLFC4s8teBXH033nCj8BPmeDEX4tA3btwApSnEi+4HPoYnwcapdrff9neARior BmYtlEkhOx4FMzCifupTnxRl873rrrWRu1702HXXiR9l5Rdf97Uog8DDbiTQTiiKZAc8H1/5 ylfiCL0Mxrvrrjvxm+Xg2aXP/t///Z9jO7q77767RrXqkaj88Y9lTAlRtqJX/Er8piXeZUzP OWZol4DxdCHEA2JDkIHkFrAsQoDhbhkwJ44bB8zRo2vXIYMHyXriQIRbrH+W+MY3vl63Vi0h RXJptmjalK+MRte+TRueCciPAX37yWUiaqNkyRJCE95pd4dp+bgF2tA2JbqQSuhrX/uquFtG mqJFikoJwV5SoEAB2YfkPhAwwhopPYGgSRKPNkniiQoVqC+oxC369O4jJyet9cpPXVmyRMk3 3zwoQwTx+EKcwkyGGFbNd9pq5pgXnh7o5TEDl4DxgpWFIle2dJnmzZsjX3Aqhkr1Ejq1b1+m ZKmunbrI605vnD51CiVT2pnyZcpiBtksbJzq162HY/3jKO/TsydoGBu9/EhqLURxbjHRv9Nc SQYvLdTpj+Pt2wW5eCoBLMRvCKySzUGzYGt9fcfrYGU0yeNxrBAOZF8NAU1hy2ozKdAJPEAM DCeBzjkJPCNbi2eEGk1jGi8P0s3Zo7gEjBcmIOK9ba8KJcRLHHpt2rQWB2R3JIpRRL1/XNJQ woKgBQLLsCBHC1w1kWV/JcUFBJYNGKEnmR+/vA2eXNROnluvS6wpWQ7CeLJ8AuI5nEwc3Emb yDNxZs3opJPgHkhtmbPfeXr0l8EMXDLGC2HUZAtZx1ApE96A/v1BsZIb0DzlgChfpsyTBQqo RpLniTyMnPIOLJgXGet95JKQb4cuV61K1Tq1a2/bGqUGuwymKD2E9Axc+hm4ZIyXyD3cItIH DlNFBF4v6BNGS0Dn3Xv2+NuwXv0QF8MKKlWE8jcRimXaNJ43fMiAoaIQeFeI/730j5vuMT0D l8cMXGLGS0DJ9k7SYJJd0kKxpjSoX89XyWSLFy0yacL4qZMnVShXntuAVGzauBEHoH8ay/YX cmCmue7yII/0KP5bM3CJGc8wQxR9YB6aJy8f/zhnQ/Wq1TgY+MS5B2r4r3JlTvOqVSqrSaIc lwwuIuoyWC4leP+/9dzpftMz8IHOwKVnvNTHSQwSUJ2SK4p2le5TZJ0SsIIS4EXomcrHnbZb XE4JET7Q95K++Yd8Bv67jJeksnkn82OmiEvnHfiQ01n68bLMwH+X8dLTnZ6B9AycdQbSjJcm jPQMfAAzkGa8D2DS07dMz0Ca8dI0kJ6BD2AGPpKMF2w+mZ/zmfX31PhdO0y9eXbkZzgTRWOk ZD4+V5+Z+Zsv7SDf9SnSDS5mBnI242VHY57PXCDULBe+61WXFqgZYOXJJwvvqScQygBHjBRV s36XD7R3AjJVGyCN4X63Cbssfs/BjGfoEpCJJFDDxUeKlMT/fu5k95oJVgLR7tipk7ydIhIC DPqdPn5dvWZNz569xDGcu+V5vlIDWLN6jVwZ3bt1X71qZZY+fVVnr3jxElteeeW8bnfqpIrN hvf88y8YQMoacbqkxHkOLN3sfZuBHMx4KEwAqwKOii0LxpPWUshcVAg6qFyZJXgcJEIgZIuQ 4EwyCFnJfvXrX//gB98XOBsQaoFkIx0vviTjZCxNVFFWhW9BnE43yKLkwHGYxDNOuntSR+WM WhnRANSjEkAo0k8JVaWJw02TSkO+CtuXSDcpc5tUPgoqaBhYUnbHVxVdRB7iPceyYsvYLWGh XqU5DWWHo/7T4IT3javO40Y5m/EmTpz46U9/pkOHjmKO7vxXVEoS9jr1kYjBKNleZmklxA0L qoghupdmQq22lzdvUhA8cNHevXtCEuhUPsSD5OquXTvXrn1exs5Enkj+Jy1nKr85Vv8tFLIy 87hFbbTdu/YEvTF5F9JVSMJ7y5/+BCAu6yGJnSDsDr75piSBcoS2adNGVC9MuQhj5cdSxyMD m7sEXtW/TG6ORQkKXAxh9YraWVNCugqRh4Lyk6Lt50EP6Sbv0wzkbMZTAfiqL1wV6qdLMi0a XeoHRRQ6deoo64TUg+o0pJZN10w9a/wp5C9hIQc4UCDS9773vWu+e43KktgMyrRixQq9evZU JlL6sxUrlovKFeCLGYoUKdy9e/e//vWvxKZKLC6H9q5Vq5a6hJLJ537oIdyC4nPdd79q7IqD Fi9WLMTmxlLq5JEjb/38pz8V6r569ZrTYvP48c6dOunwW9/6drkypQ3v61+7OveDD6ru4kYy d5LkkkpJhJEvTx55QQUZlyhWTP4YgcUwd5s2bVLYUZZeqXu///3vKT4uf+GggYOUQZUlTVpR 9d+tGmmZ9z5x1Xnc5sPAeKHcHBnw6KOPUgiVDZMB6ZOf/MQd/7yjR48eGC8p3aORDLyf/MQn 1CVPpJCDfn37OVm3Tl3JNr/whf+rXKmiSPZrr/nu16++WtXyBfPnhwy5KJtodfBArlwSY197 zTWqr7BnPPrIw5/8xCeFIFavVv3jH/+YMoCkaL06dWfOnKXqqqroI4ZnVPQOeqngep1IAwMr HmSsYoNXfvJTTxV8UuXuaVOnafCpT35SNaUuXbpKgla7dm3Z5tVzJ6uxk+f62BVXVK9eQ5Jf Bd+HDx9uYPJ/eljppG6++feSO+XJk2fK5CmVKlV2F0XGW7RoIaY+bXc5D454n5p8mBjvP2qs KyA+/5l5aj5ffbWK25EOqSxoQnC+ivdD06rUZzBeJAVOPProI6ovBKVOaW+UunHDevJHnukg lDCeXCxKN6qy4kCKNCextxzvbx48IKyesMWBG+NkSnZofnVepRZK41VXXdWkcZQGNxJ48Rpw 7NjbzCo33vBD7KcT8vbJgk/qYf++DLy4pGxqNrwYB+Cr7S6HmtxnNrHKEjnTrl27r3z5SwKv rA62uPICW2vcpWfPnn4lLV3L2uRY9hqrg7ymqXd/nygrfZtzzsCHgfGYWBAWmlZ73gIvhYQg 9x/dcOOBffsz9MlTGVusQJfIXXhuJCIzjSKqnP/5z3+Wy8zJwk899aMf3Sj3EsZTuzyD8fr1 y2S8ufKOKccZGO+mm26SEwnj/eRHP4qDel/A8HL4CryQRRffyu1px2XnmZB+YoORWub+++77 8he/+NILL+bO/fBvf/tbwjncDuMRtspq40kGmEJPPRUYz4LiV0kTv/XNb0iJv2nTxm9945tN mzSWoA3jqVTuV1U+pc1evSra48ntfc13viNxcHjYNC9cPjPwYWC8efPmI6xhQ4dR6iRaJ0/y 5817w/U/3LN7DyqP0hYpdRJ/NGPHJxBQuaRjEY3LOX/0aJlSpSXefHnzywTSH/7w+7/+9dZX trwsXyCKPyvjqeXgvLydzCSB8X584402cljl61+/WqVbumgkA48fW7Vq5Re/+MWmKRLPSfUk QreyHhqMjEw1alT/3Oc+F1JWR4zXurXx2E8eOXLkhz+8PmE8i4JfW7Vs+c1vfF0WpsB4zZo2 SWU8aRaxuiVAyy1btmhQpnSa8S4fjssYSc5mPDsi4uuvf/ubRJ0sCtgAsSK4B+6//+qvfVUq aHn7ZNGcOmVqEDiB94TCf+ELX7jh+uvt3277+9+nTJqocAIr4q9/9evb/n7b5z73WXwlv5hU gY89+kjgBNYUN1q0cFHY49kKOkmgsce4S+7cD3FoOOAAkM+ziZj6GjVtGnPlyvWnP/5R+9o1 a4YBUDTfOnpU1m2bwwceeMBmjFDl+mCTNE7M9uCDD1WrUkXCqOBOOHT4kAd5/NFHidNvf/tb IUVvwwYNlHRWHWXd+nWf+fSnpfpUJ8xdOnXqHD1dr16Ob/nzLSqHSvL7y5t+oe6KwkZvvnno sqO+j/CAcjDjRX7t1avLly//1JNP2iMxLXJhoTx03LdvX5aSw4cPod1ixUvIlptpVMwogrdk yRKZJvLlzVumTJmQoX3pkiWly5QhWzjBfN2/b7/k1gMHDoom6NSpRYsWlStXzsZJ/s9y5crL FoOJevfu3ahRY0qgBBb16tU/fOiwnLlVqlRRBkwy3BbNmxmXHNgMnqHPsMezFRQK7KcCBQr2 6N6dwyNTFK9ma3niiTzdu3aTSLtq1ap6s+1knlGDRQJCObVlpqEvsr5UrVKN319hzWrVqqki ZmDlK1ScN3++rrgWWrVspX9Zfd1UGaZiRYs1atgoLpT77jiYjzAvvK+PnoMZLwvwKoim4DtP jsNBIu7iqWVXzJr8L0tXiWxMlZOOQ82jjM5jX3y4Y3KQfTazDCD49pOTKWPOejK6XVzMPdtd Mu6LiVNulzGwgBA4PciUeyWmnfeVvtI3e4cZyMGM54kCICP5JM8YzoSv72RUOPdVSedJJ6kd huPkLllud8avmbfJMv/Z736Wx3mHu5zrdpmPnPrUqe3TjHCZzEDOZrzMScyE88d5ls49s7Ek OXviwFAUNsiZiA1SOzpxdgY+U5ZGl4QJvbC3G+RbKt8GGXthvSVXpfYQS9ywZFxst9lHFeT5 eRpPo3m+yAfLyZfnYMYLalXMJxnFzVNddmd9KciCnVAi97MSDaZl6oTw0HOis6WSLzY4gxmh yQ4dCkBKn5DS9+jRt0DMLmA3hR/Azdhgjx59O1Bwklz0+LsFKZxDpgW7bpZBBlY0d5eWdJN5 i5Ljv8MKmDHUeInxXJd2ADmotxzMeIYu/bsqPw5e27Zt5MiRGStuCj1loUgvm9Fvfpy7OnlJ QcI4M3bM2LJlynAqRILr5MlevXoqmB54+9CbB2vWqLEmNpkmOiFoJQxXEhWhKkP//v1nz5rZ qWOnpNlZNcwst05t075t29WrVrmcfaV69erlyparUaPmwhicfVaqSgafNIjQ1plNiTWrABvp nrgsWXhMZiR2I3lMzd5Zx5mI3NN3jKYoQ7s++zD8GkmwE6Bt3bt1MxWhWap+Hs6E/ScLsLLy qswT6HGb00tA/MoybhIdXerV4TJhzhzMeN4fFOWwYcMcrF29mjkxxazwH2rMGV8zzQwd2rdX F8VPQeVKbcNEmdRIQQ4lixd/KNcDwavO38BTFy5MPvsP7GeHJD/DGX48BlI2RgX9UpvFq39W m0pQa8MnlSKV5gRDcRICUywSg+2Lz78AL5baONFmk5PPPPPMCy9EjrvsHzRdpnTpBPzN3aLP uXPnrl+/HtLgrFOUejI1BiI5HwaQxZATfuUyZUNOFqPs42FP5tv0yM8tXx6gQhmTQPU9ccac ZJmfy4RhLtUwcjbjATEHZti6ZUsokrx27RoHEF4onS9B4T4FjJT88ZxDnh4CzIXspPcM5G55 htKEhLT245l//ON2QOdDh4CJT1HzlLYtVrjIizFBk5PFihThxHPVwAEDXeK+Rw4dIiGbNWuu OBmfOAwXMSUdfdPGjV0yccIEjgTgSb3Fmt6pdevWqT0GWaLw2PbtO/r169+sWTM98+D79O7Z S4F1qLckGogDoGbNmkYCitm7V2+IcEU2ZSilD/MouESue9VdDB7MTb0xGG6xF9DhilhzpZBy XO2G91SBAkHi+bRs0Tx1+bBqqJ7rcaZMnkT2zJgxs0uXLk0aN546dVrTpk1HjBjBf6j8k3ir nj17jBo5yvysX7/hjTdeBwQ1FRz3oS6Np2ioEsaYsaIlxowZy5uiTevWrT2vmoRmHgZ9/Ljx O19/49FHHgHdduHE8RN4VlauWKGUd9u2bT2Xik5eh/cFgkPfBtCrV68e2PdpCXipqP4y6CeH M16PHhxxFDz0V6N6dZuZmjWqL126lMyZO2f22jWrVSnqipQ6d/YWoftR8MO5c8+cPiNQ4YRx 413F+6wi9IplyytUqICybRTDm27epInqYoMHDrRjaVCvXtu2bZC4gs9g1oLcSpUsaWnX26hR o/jxlPJbv2FDsaJFpk6Z3LJ5c5KTgrdi+Yry5crjk9Dh2tVrli97dvCgwfh/1apV4pjokGTm ooULJ0+ajDQXLlx0/733GXO8LpzikYO6tr/DLerAvPzylnJlyr7x+uuulX57wfwF4h6sC5gN 0UNI099g06wOHdp3oAh07NABt4wfPz7XffeFrMH4X83QLS9vCeuOvwL5pPQGDADIVtUMB5ol K8uDDzwAzlr4qULLly2/9S9/GTd2bNHCRejVVjRTQWxWr1YtWo969hTN6NdHcudetHixsocW l7x58ryyZYvGvKkrn1u5bcuWObNnqZgtOmnDunWtW7cSh4Eb8z7++I7XtoOzzZhuwO29Jrgf RUsVG9W5laVooUKehVj+UNpgcjrjdcc5EydN4j1HuC+9+MJDDzyABIXwwDELz1F+CCwLir9P r17oA61079o1YTyiaVG8fVK62RIuvGD9+nW+hl2HIipCSJX1e27Fii5xmQegUChKQkybIUOe dgv4LMoVE0uNaAe42r0wXpvWrYiRpwoWhFp+5OFH4mJjERR7z569cG21a9dRBX41aRzXW+cc VzJJjaTFixZFEql58xXLl6cwXjWi28Ixa0a0WACg7Nq5U6Q5BrMXjW8XgXKQOEf53j17H3zg wU6dO4uHsvRUqVgxCDq3c5UDXcHQIPqE8dxu7uzZvpooSb7bt2urHwjPRvUbOFmnZk2kryq9 Y8vX4oULYdAUuLeiQc84CbNqVmnXVA9fmzVpGuEQSpZc/uwy/JzQlqXNSzG2DRs2KBplzHTR EsWKLlqw0AriwmiJqV5j+fJloVvIoeHDhls+OnboGJaMJKLyMpBVl2YIOZ3xeii57sVs2bwZ HYPzI3cUbBexbdurVStXUbeoV4+ezZs2xVpjRo/REouKQI/kXUQoTYT8OOjTp09c46Hl889H dTAD4ylstH7dOu3xtj5Rw/Rp05FmYDzhORivdu1aGI8hVJsMxpscM17/ARaC5cuXr1m7lh2V ukipU5hFvomhQ4ay06xa+Zy7h1tPGDcOPwcLCjVvxbJlWRiPNJg5Yzp5VblSZbqfZPj169XT Zt/+/YSneHYYmvnz52G8fHnzzJkzd8WKFQBlFcqWjRjv1KmK5cqJMAyP3LF9h4DwDh86ZFC8 RTnFjNeOVCf6LEmmgPoAc1eubFk6uQr1JDPgTq0aNaSrSBhPKv6pU6d4Cp24iq2rdMkStsTl SpdW/dNJJRCB4BYvXkJXN59DBj89bep0ANfiRYsuWbS4Tq1a2hi5NWXF8mUe31cQ9rHxy/Jy K5YvB/j24bOw5GzG69ShA7LzhtauXmWZP3L4kIrQY8eOmzNn9tZXtqrCZ9OCRqtbpNeuLVu2 7IwZM/55++30yUB2djIVCY2pU9lRtmx5GcosWBRjxjtRvUoVYT5UtVtvuQW5d+3WbdLESRiV MjZt2lS6mQiAu++6i/Ylao5eR1oWK1x4wrixlDEaoOKbtCb/mBDYcWzkShYvMWH8BMTtdkgz ADi7dOo8dtQosbyRfjVt2t9uvXXZ0qUx451EjuwiMN842bpgVJUrVcLSipm5+7atVLjZQn7b t21H4tE2d+/ehR/69+s/b94zIoawa/v27QcPHqTEvP1neK6tW7fBqhmzqaDaPfPMPHFStqYl ihWn1EGWkdgUh9o1a5gBxQynTJla+MknBUlAfs+bO4eSSQCSe+Da5u3BXLlEA5oiMln/BrZw wULMbxMrWMmiYAJ6dO9mxZk/f/6/77rTRprMr1O7Di0gz+OP7XzjdcqzXZyWdolUaOuXfhg8 Bw0Y4OmETRbMn4+4jhnvQ6Vy5mDG8yps53CUA+YTlISyrNYtmregpciqYLPEQgDfGCwco0aN FlBDY6RrhU0XKUT+MGYKnGOnmz17Djt4+IlWNnPGTK9cLDnCcvLZZ5996aV13j5SYyBhGGRI wIrdunbDdSLfhPkISF+37qUgEl2Ojok4VhDCSqcvvvCiMtQDBgw01Fdf3Yaw3IcNEwNoMHjg IMF77CUqchqAreabhw5ZGt4+dgxSFFc7iSXQqBxJrvUULVu2tDti15HsqEWLlhs2bIRWpTC3 atXKGYKCqta5c5cRw4YdOhhbjOJ93Yb1G8RGNW3SFOLUyfA4OjQDwiNog0L4bWbNgOAmSw8r CFMHcaeCvFgkthn9WCMYThTTtsS8tG4dY4n2Otm69ZWxY8dQHQ8ePEA7ZXbasH4dZcE4hw0d ynwiSNLwbJLhV60pONBusFu3bpCufsVqfBI0BTrLwAH9CUD7z2gVjLyCaca7NFruxfZyNhzj acRjlhUlC0IyZq0zai/7GsRgGFZG+0x3Q3J5oN3wyeKxSAFyngZwRs0yP8mFp3vIhJVmsdpn ONDjeyV3yfII2Xs7x5nEMJh9HlIGkzF7wcmS2jLJCpM5RWdBlqZ6F7Iv52cdW+pkJpdk91KE 7FUXSy6X2fU5W+JdZpOZHk56Bs53BnI244WlMDyDv/+NdfG8nEjvgOTM/hKMMAMReib67Hxf 17u1o6clYiQW25dOUMT5qoMwjKc6gqWE40QipaoM7zbSj/rvOZjxImTgsSi5nWc4cvhIAApe SlIL4XMAlJlozOzE4tY+4dbnRUoxgIad8xwpn0Of59XbmY3CTlL/zDkh7V8MXr2Ans5ySUaw VZxEmCE3mvaTMqYd0f2xY8cxYvxconwjS+alueWHupcczHgBlGxbz5gmHlQmr8R+EA4CBWec jMD4Z5yMfsgkkYTQkwszcsyePMkAGNIohJkKxJCx0mceMJ8wHjCuhPMZvUUwwwBFPM1FbJvA GdBtsgwi3+R2qaPN6OJsMUEBpZ3cInNIp/tnfhRcW6tWTaCZZc8uCyDIlIfKGH/2543Dfc/F 7R6Njy6a6qpVx4we/eqrrzVu2Ei0LjOmK3kO1LiHs6lZs4Zmad5710UjBzOeoUNISIk3e/Zs tjKZS84EQJ6BwwxaEBRI9l0+MRkLh+NhLlIrKyDFjRs2nC4WHRN+zF0Z3fCYAXIxq0iORBSk dp6p8sX6WCa78kZwasGy6DbcNwnbTa6dMGHCypUrU7six7MPO+PNRewSc2PMj107dwFzEboO xsUgmfJ2U0N44+CjTANSKmDVc51VdOtH5l9wNu51YLfXXnuVvZEbAGhG6he99ezenbN029at 7psYjd+V+D7KDXIw43nfDOuSWCZEiWgGDRhYpWrV3r37HH377aefHgLhIWPCqBEjYa840y3M cICcXc2aN2fdrlql6jPPzMUwjPi0MokkeAIgs6Smrle3Hm8SdPLokchr6759e1u0bFGrVm2+ JmEQfG4w+ERcseLF//WvO3E+vziQNN8G1JVkDbyCL7zwYrt27bnRIdpwV5hoRvmypcsEGyZX Ne+WA64tcrtJk6Zt2rR9Ye3zd999N+Al2z1HWeUqVYYNG+7K0aPHcJPobeTIUXXq1DVgcBl4 EYiZkLrChx+iQrnyQQ8MH+tRl85denTvsWPH6zzgnpcj0Ug4SPRPUXRrDhjhFJ4XkitSHUMs YmYPiYQ3G+pMJD0DAwG7hK98DOXKlnFt8utHmaPO89lzNuNhKlnDYrmBlE/xDpUvWxbFYwzw rkKFCtG7+HaLFi4Mc8hxDOj477vvHj92HLAvyCVvFXyTNZs/2n6Ok7pr5058g8CNWKhK5SpL Fi/hXwawhF8BziBDZKpdumQpkQKECc4CRgzvAh8t1R9S1icHF6xww/r1YankJuKnKl2ylFCA RMh07tTZ7dQ/AVXhsufyMmYAK5UPeL2xE5TzyBEjXFizeg1eNU5zmaQrV66M1qGN9UnMQoE8 PWhw6VIljYTHMkhX4+Gdc2DwHGikK6aSahrcxIVgJc57XoPx+Dz4ADe84YSYrE3AAIQYn57L 9cbDKdxB4plEVjds0PD5taejoghtqVy6du2q/arnVsLKOjBmrsjZs2afW2s9T9L8cDfL2YyH Vp59NgPn4cVDPwyPBSBHMEhHvbp16J8L5y/o1qWLkyWLF/NVPAHUv8zNI0cMf/Pgm+XLlFa9 AJoR40lSBPW7bNmzUBra8+pOmzKldq0oHK5i+fJJqAuEIfRJ7ty5582dC5gClmkSixQqTGpF AMW4aoIIicGDBgYEI7h9iPSJfcCRrLMdhbDhLyaCpkyZ0qFdO7gtTAuo7VeLBeCVWz/84EO2 jlKhLVq0MGStxYEtmjXXpnKFiuDaoGc4n8pK3YwYYOWqgOR6bfv2jh07YoaNGzcEMKSFwNLj oG+fvqCVXNjQBWRUtapVwFwAXPwEMSOeIEgt0ljaX0tA4EN/HYen8DW4+PbvP2AAAGh0yxAa 4om6dumapFT7cHPORT5dzmY82wxbi0TDGdCvX8h4CQMFMIUa1r30EjgFxsMMJYsVI5QwHigW /iRVYD6gojAevnLV9OnTevXoQRSgS19VCALdYE4gScqWKqWyl5PPrXgOdtGODriJXgrKGKCP gPwEkRgCE8qiiCKHPj0kpHZu0gT8MuCeMwwzjjEerVI8IY6dNjWKbNq2bWvZMmVF2UgyLawB OLNK5UrSh23dtk3RH1wEo+zXls1bIHxISLAsWiGciicNMwAUTrp6HMe2ZDHmez2hGo2hUSPA SAc0zxnTpoO/gNFE4M+KFa0drVtGz2t9oW068AjgY8IvILaC7HKSug5ikkx1OLCQlS9bThAQ /Tlgr23zwMqTh71I6vwQX56DGc+6Kw4I2M/mR6wXzSpCSxYtKmyMQkX+UNIYJKOok3btAK+e zJ9fcQ9qJ+Ai/oTWlTzTV0GiwJODBw/Ony+/JNBUTUod0rH8Q3VCZgLv2klWqlDRBgnErHSp UsTUww/lxqgLFiwsXqz42jVr8z2RBy4Z9kpyS4AskmrihImdOnTUj3BvgwkEjSswqruDO9tb zpg+TdkgLI3oGWkMHnga4llsgQgAjya2TVwfM73dncD5WKlr4MFJb2OzaxXWoDxQIHR/NS5S uPBo4Q6t2xCSJCSkuPNw4bZ/IP+lSpSkb7OFkI1AniJ94dGo3/aQ1atWE0aQdBVYK5C+kZtq wFGg6nHjxi1cYCzP2OtaDlh9NbMdtYKYeboAqGp84SXyY3xImS8HM17AFqlZ1a9fX2YMUdi+ KpwgqjJKanDq1Lxn5gpPhVoUFcZ2ggPZJ2logkRffPFFOx+bHNs8+5nVq1d16NCBGAQRtPvC J6QKsbNl88u6xRiWfVYNbZCySBlCxoZQYBty7NWrN7aBzHQM2ElRpPFKaiAsdeXKVZhEEKBq dcEHsHvXbtB7Ymfzps1GawtHAut8/vwFbdu2U3VMG/BuDYgOGE7PhVvkcdEJeKf+RXB7cBuz lSufAxPt06c3QRfkUtAAlyxaRFZ369ZVnmmTYz2KvJHHjsFG4gpD0obMpwaDU5PYrP8Vylc0 5kmTJodOEmZLpfloqnfvxmYqNwgFZGSKZmzYcA6MYJ59dslS97XrE5KX2s+HlHEu9rFyMOMl pJboP6mQwiABsvwUnjb5KRycFQOZ5WTYRGX/pE5flkQSoXEqyDO6XYqPQ6g7AcKtl9ptAhk9 Y/DvkMbi9NPFZBB4JvsgA7onOZ/l0UClGVTDr+dgmHMgRWP80BkOj3DmYmnzQ319zma8nPtq zLtNXefOnXfv2nlmIsH3+5nYReWcjtj2PME37/cAP5z3SzPeB/Zes8irD2QciWs+QtsdT8uo 9+8lpBnv/Zvr9J3SM5DMQJrx0sSQnoEPYAbSjPcBTHr6lukZSDNemgbSM/ABzECa8T6ASU/f Mj0DacZL00B6Bj6AGUgz3gcw6elbpmcgzXhpGkjPwAcwA2nG+wAmPX3L9AykGS9NA+kZ+ABm IM14H8Ckp2+ZnoEczHhxmscMMH5I7hhCb97rS4WZDLMQgIuOU+H277W3828f7hINOyOO4fSl IVDg3J8kniCjcQhNCBkv40+YkPiJMrJZJ8EZyU9JCEVSFDI1ju7MsImMyQkhF8ktUoeadBs1 eIfohIxHzoyWOOszhnGeT3xD8qbC857njL3b1L4fv+doxjsugaRMOwoehPcktDQqzfMeP+Lo JIOQux9QWIidIL04LewJGUfE1L1T6EBCxO/xbqebG3AIKfQ3yTLkZyvHoWgw70hGgR/kL1Ip QfomyQX90YnAQtmZMugvypwbLUzCC50PS5IDl8R3PPHWkWjqhCbs2bM7JErcs3uvZ08YSdj7 jtdff3Xbq8IRpb2QXdRESQkTzU9mHIObRj9l1pR3awUbBPueIywoZHPzV4LAqBTz2RbKI6rP HDoUErqde3rdyPOLAIwm8JwgbzdSP1C5lQt+X5f2whzMeN6KkiCFCxcpX768mjvmRSEuQdln ov5Px6Elj5p6gAIkhhg3Zkwo6dy8aZP1L70Ueli6eHHd2nVioZqZqTqOxQ5SMdBxdJz5axLz FjFPyoqeiKZIIsWfRFxYo5VFkU9JHGo476/g1Hx58qKSs5Kdk35Sk0z6oxrVqklmMWTw4Pnz 5rujNCoSioWrYu49JEGLHBOK9QiWlQRNLgwJHUJ2DPHjhQsXln9T7LmvIoNKlyotq8XmzS+H B1RJS+2X2nXqlChRQj4YZ6Q2Gz92rIygoorDg8ho5hYh2UT4KLckv2DqY2al1xMnhSM3adRY foCe3Xsk61d007ipg0mTJgmxdZyljkKsz2Smr86czEOHolJ7wurDTSPxHmVJy3jvyd39pNRu wwb1w7u7tFx0Ab3lbMYLOeeIK7m3vH605aVaBRFEyE0kdlu0NbKTalptGhOuio3zcS7naJmX EkKWPqm+oguPH1ezTra8kKlOqhW14MK6G9ggfFSl079mqhxbm8PqLhDbT/v37Uu4S/0gvzqJ evQfsu6RTqFlLO2itV8AePWqVTrG6YZcK/+SxJsPP/RQKKyV5Y0GaabmkdQS+MqodCv1g1QU 0YAXLmwYF5TMYOAZM2vXrOUWEq5MnKh82Fi50qSZqVi+whtv7JR/dvLEqFyZgXhezC+4XslI SdNCD+5ltP6akwH9+jspnp1AM11uahyRgD1yBMWHUuYmXz9SV+jBGwlBydnVPyeV1FMQk9Q1 53oIExjl84z0jKiQ4N69+6gbo0eNxn6+xm9nj+eVsjp5F5HUlUj32DGZF4sWLqTCkZ/27tsb K9sIIJreAwf2hzGEN67iZ4P69dKMdwHLxBmXmE35C6QeMbOWZNXhlFaUXESevFo1a6urLNeY 1H0Ki1etVk3qFOWOK1WsJNlJqxYtJUeRztkbVU1WZjuqZs8ePWlRsnFpQ0qowuU91aldS+eq z+lNTgdZfVSQrFatuvSYbVq1/sMf/oA4QqJOmQUlcZHQWvE3SVz69elrRVfRynIg54ocKtu3 vybZniRIJJWsE15/RGsxN0pRERjPZ9SIEf379lXQTycJC4WfgiClK6q8l5o8V5EwCSw0UNFS TdbQ2EdmJDUDpSSUr0VWmKaNm4Q8ufILyq0iA0WD+g0krUDrMlyE0sqknPRHFqkgE5yRu1Yi I6wlHYb0FmHOlYyVRUJ9eckpLAFS11A0ypevgLFNmhTD7qgs4e7dewIDJ0MKfbq7BIcmPzCh rKS4i1yVf0lqDPM5YcLEAf0HFCxYUBHZpc8+a3klq/M8kWf9upeGPP10hQoVpcawQjVp3ERi JSl0S5coIfWTZlKqCuo/8tYRiVUVnY5qa0s3HKeiqVSpcolixcx/SO59scR30dfnbIknKdgT jz/x5JNPNmsSZbZq07pNvz59LN5UUDm/VCr2RjGVcseoTQlLqY1e3rzl3rvvlgTJu5w+daqc JbNnziI6MJu/UdHWoUPkyUOyVE2aiaRjRJAstxUrlKdrPVXgSbLIvkKbGtVrWEddSNkjHCSH xhV66N2zR8F8+W0nsJZ8gZhZs2NH30aO8rXIfSLlHiZKDANy+6mwafwouE6t2mR1tSqVSYNA H74qE42BQ+72TZs216xZK17Io0IRDtq1aZsnTx6FKQsWKFi/Xn2XHIlqJ0RqcMkSJf/fb35D vURrmPmlFyMt2pDGjBqFQ3AsQmzbuo1nlKEoqJdlS5ci2SI+jzvv2qWzTDAOqH/9+kVZKnCm CntPFsj/zNw5tpSFCz2Fc0yC/bAMn1RN+UtlH5UwSh7BaJwnT3quSZMmWhnDE/krd8uTBQvK oSYHXKsWzTdt3HDHP26nvCycPx/34u2e3bpT/vv37xfeoIQuMhpa7yxnJtYyKjna448+Kukb SViiaFF7UfMvMWmp4sXVpldfVvFtSdaktLHLxefyXHl98jgaUprxLmrdiFZf5Ua7dpN6VeYv mpIcRCqJSuq65eXNqEeWS6RJF6JxeT1jxoxWAN3uR6lXKopMW7Z2gwYOkM6ImiR7LD3KCrp5 40aqqWoMC+fPsxVR1TH3Q7mbNm1WuFAhRRLpdWQdBpOtCK0bg0xbJFggTYmrH3n4YTk7EZbz XraRyDOp6KQslI8+/EjtWrXUHmgoU1hmfRUXSs2E2hy0bdO2atVqhC1VU1KjIB+sDldccYWF IFAMc0iF8hVcHudgjxp0aNe+b99+iHhklIEvSr9ZrVpV2fgIfyPctHGT7KOSiNKyQs5pOyvF n4MUOnb8mOxpshjGtZ2lEjtcoVyUri/6Lb5X9WpVg248beq0wYOj1NG1atRcv36DdKO7d+4k ssuWKW3XJ0116HDNmjVkjgMZqCRfDCc9nUfo27t3xM+ZezNZp3DF5s2baMKG59WYW3J42dJn B/bvp8w19Vj604h1T5zUZt2LL9FuHnzgAVkGZVKTetAW14pmybPHw3gjRgwnAx+4PxfhLJep h2VzkiLR17pxweeN6zeEEtNpxrtYxkNDiMacyq4Z8md6YWafUkfJrFq5UmQ76drVrlob/IAC vKeqFSsxYsppOX7cWGqkjF00N/obxtOPVJxv7NxZQzmO+fMaNWgwYfw4RPnmm4cOxkVV9UO9 JLJY0uSx9tW2SlXUtavXlCxRwg4K71GfnJcXjG4TLrH8Y0V0tmr1qsM0uSgzV/RJrClKk2um 7rG0fOq8/uWWW9wl2HAYFSWcJaAsGWHfZdl+Ji46Gz6SF6JCB1jOoqNz+iHpLb2f3KHO+5XU tdAQtr7Wr1sXe4RryZMK5ctZODz+sbeP4l5LQxBKfu3bu0+oEe9DZ+vff4CDMqVKrd+wgagk 1mybCRP6BR4IzVavWa0EswNSS20TBzpT+hxTydUZKdjRJ8PIVKZUaZk5ZWcsX6YsPqGTV65Y ycj79O5F37ZQhpkk8IcNifIUW0qsj8yqllEagc3qgf0HPG+ZUiWlVLXAUV9NjvRNqtWSvQS4 bYOnsxOJ52dZtGlPG1cuiu3ihVPuV6nUbc/oHl6YysNegL2HN03BkHOWQvj4Y4/LZCklprIK FmbWDUqLNyd565hRo627pCWZwDxDqWNIWPfii6+/sZNiJnlk3dq1WR3Z+qKq3IMGIg70pLFc sfrPlzcvC2SDevWdl41PyXXcpZ/evXrTyuyC6I0SUBIINDELBIlE3EkFL5Ulug6Gh4gxZsyU 4jJhJAdVK1UKxqFEPjiOWsfqn61agXz5KYoeH/V36tB+aqzU0cQ8e9KPgsaFnnrKgIsULqLW NLovUbwEg1CdWrVw7zNz5lIWlExo37YtUrRm2Z3KqDtz5ozQA6lu6iQvpKiTyXaMZL6Huutf /6Lu1qheTRZ3/dDeLXOutQzhwCWLF4WEtj169AwSL8seD08/v/Z59lL8Zj3yq+LYD+TKRQex ajxZoGB0bfcexKORFC9aTIp+Sqkq87LQSwFM0bXBk5rNg5PVrFk8D9RL2RatHfJk57rv/pjx mq5eufLAwQMVypbDqHazkhRbGW1D9J+WeBfJeiet0CNGjLQuBlMEFUj9ILttTIi1qKCUfsV3 hg8fMXnylI0bqX6bvWDrPdcTQqRKIeVZs2exgqgr8NZbR5Xz3r9/H3cg4tCnv7qVqdZ+Q4ER Ak25Dx2+eehNQ6d5yodp48SAqdkLz6+VSRZXUJ+wmeyuVFbjkQyXuT961LhKOCmEaJJ3H+wl EmwmcxHl+Vy1yvbpbPQRmf/ci3mDP0AaX5TnqVhuULAkogaT9KMZ48eQIUNtdwMvrVmzdsTI kbt2RuXEJH72UDNnzjIhhBLzCTvTM1G6segT7fcOHpRp0/RqRvvVP51NNls7KJZh02WG5cx+ bsUK+gLiHjt2rLoRJs2qpzG3xGvbtgX5lvrx1XThEzMZKxEnvaOQXt4uMVS091pf3vwyFXfi xEkyoCqDYdiS1StJz/eowAMlxcbPezRLVlJjsAQsW7bMhFhq2V3pI5HJ9OhR6wV92DFXkzdI nblYmrtE1+dg40qqNMiyssZrWkoKyxRpEq5Krj2zslesAmUa9MJFqQt2SjcZtofkzFnzYZ7R PsW5Fw0ghR5Dsyxn3tHwdmbyzOT9JeNMJYxkAIHtU0abJQ3m6WycyeVZKIOim/I4mbXHYqUx Ow0lg8nuToi4OqWj1JZZJjx7t6nzmepeP+sYkrechU4uEeNcbDc5m/Eu9unT16dn4AOagRzM eBbLZPRBOwoC6lLOZOYtguk/rLJZbhCt2SnFYrNInowLM4Esrk0VO6niNFEss8jYLG0iQGnS W1yJ/Ayxlu3howk5w5OWkez9vc5SIo6S580+1Umb0HmQOUGSx6PIQKWeqUecgYzNuCS+PExd xtPFVplU8Z78FCpsJhpH7IS/pDTwXmfq/NrnZMY7fpxxcssWxRG2ej0HDhxUEOHSTrqXGpAT sQUyep1gK1lqptIJbTDsKjOoTZVwu59Dh8LXBJpoJ7bjte0xnOKg3SZkhjH7avuhyMGGjRtY U5JLbOE2bNjI4geWoQ3XCD+4j32XF+Z2Nqs2OTjQ3mzbtlc3bFivOOtZnz1GyBzne1SyyxgS pMj5kUdGK0NVOMVGLjx7BAw6cCAq457Sizb2xgyOYRjhjRheJuNFLGQ36CnswWxVudftM5l4 wzzYHJoFM2OEoddQKzce+UZmEvMMPrpp8+bDbx6KqDae54ALDcgyW2VTcekX3/c0U+fdOAcz nilmqCxQoACsCazjunUvhepwyaoZjkmEQAepP6WKytS5ymJrdgksCNe58wiCAZBlLwJ2pIC5 tOGLZ0EN/b999K08jz/OPZg5jKikEeM7uytfBXplZgRe4dTmxEdMjgEs9PB8XGndYI6+fZQR r06dOmXKlKlapTLjQblyZSFu6tevhzIxKkc8MynPHuMNFEjevHlq166lxhBTx1nsMXFNJYUs QXaAeEKxsWha4k+4Y/T3zD1laj/hF2WG2HK13LtnjzEbQ2ob/WGApwoW7NGtW+jfje6+8061 BMMtNN7+2nYGZC+rR7fuVpAWzZt5BP4DDIMhlWoyh0yj/EChZxeqjlKkUCHNmG2xPb8O2IqZ dIlnZyKGEIAo0nLRosWKGbHfqj2YEMB5c8EH0DBnM556yEyall44abYvrlXIzEgURNrYKedB +EFEYmo+xueDaKK3EpePVXkHXDPWTML6Gq+cQb+JpYSWjGBPFSjA4a6BGIg+vftwWwErhVcb tB1m6wL58sVglIhW+KYfffhhjuCEppVibtUy8inrMwYiRmOAseKWcEmtWrWA9AMnJO8/0C4X Ip+BS/Ati2tykjfZsRKtHhlqhA09/HRW8tEtaczUHiBabkO0sg1akAio0C3RQTQlAtOsRDOT oSJGz6gSYJ5HH2vXJipbCQ4CjRlVoowrwifzAOf5+COPdOvcOQyGizXXvfc+M3t2Mg9gesEd J5ri6FtH98NVxvg1dcswlRqd4cIgVONhHyxetCgfaXTy2DFOF04Lx1FVtvETeGUxeVRbs0oV r4mnbu2aNdtffY3v4aww1w+At855y5zNeKRHcKBXr16DLbtA/ny1atYCwmShZmeP5EyFCtxK bx48wDmrUhwX9sJ4DSYh8SpGpUEFig+KzYwZylYtdQbtOetaLxicivvBSbKOeAp8kvAqMATg RQSJOHWKpZ6rmi+R6zkm8ij+BU1wJXNeE1YJbXFgQDBpYJ3u3r370qVLUjknNIM+4zcH91WC jz+NX85JhcSqVKqs8BjAGvs7lGapUqVZ+XftysB2ZhHvboHTVN4MHhdAFsLKs4tRgLHi4Nqz ew9NwTKUcL4DZQBVBQuPQEo3atBQnc0O7TOcjZwf0KfJUqGN9U5XADrd4yqZ3Bgtm7ckIWdn egWxfdmyZUBPpkyZZM6jQcbhHcFJyNOdN29eJQq5ExJG5QUh3HhKleNzkqfE2+TM4OLHaSbc JDhP4sGaQagErDaVRNG11Mm83FgujCeHM16PHqWjaoktOUxfevGFwk89ZTvUqWMnPiLeapAO OgxZBPFQIF9e72zunLla8sMiRE68ShUqzJsXvdRkpz5s+PA5szNAIZzOMGj2TlGlxZgqufgq la/A+5QQh57xGJcgwIqTsKMLFixQjxaAJuqWpH3r6EMPPIDhjYpqRMKAGloa/nXHHevXrder oIGBAweWKF4c80TdZm6QOAA5fMkiG6rRI0ciUGUrLS7aAEz97re/LV+uLJFjm9S/Xz8162hx RERQIHm0Bw0cZCsVhwedNAlPPPYYqlUxE4DOP15paiGOov268OlBg1yVaoYB++IfD/w/bOgw /jF4zgQXpta5KuoJ42kD0wyGCnwXqk+bDY44LLFg3rzQCdfl7X//O7CBn1q2bOV2XkeRIoWB 4/bt248DKedQRDz+bhQumTFt2q233NKlSxfaKfyDMwKXbv7tb82VZRFWRl1eJ7naoXA9CICO Pv9w880BqHR58lsyqhzPeDVr1qRu2QhZv4MONnTokJHDh9uPzZsblapE0JDQ9WrXpmpGK3GL FlMnTwKVUBQOzYnKCeQO0QurlS9/vmLFiou7EdngQBktQBNUy6VrpiLGq1AhqJq+gkrnzZMX TkW19IIFCgBM5H7oIVqQJRk+m/pkli3DDz34IIe4S4gaVIWRoF4QKPBkYm/k66cyhSUgiCxA DRU2HSQxaQplUi89jnEK/rXkI7hAo6HzZXE5eB+AG9hIkPxAf0ailDRmo2F6EIoiafn4o4/x Pnv8m37xC0IvuvXxEyJqBw8aDORx/3331YCfbtvWQz2cOzcfOgBa8WLFAn4a4yUSz1chObly 5YJxIzltPufMmQPdakkqWqQIHGmIh8J4ue6/H07aMfgIaCUtkWlEYGGIRQwf8U1hJxkdT5qM Dx2wCVFeQGHtUe0dDI+4BoUNwDfAIC1FMFN26tdvkDfPE8xI4cEv50/OZjwY6UBePiB5ETWw uAwcOGrkCLssaAdfMQ8oE5Cetw5WInATjIvwQRDEEUNZWOnhLQirunXrQUELlmFJGzNmTFQV uUGDu+++O6hA9CUlvyPTYhy1ybo4bNhwberUqY2qFi9eMnDAwN59ehcrVgzFJOEFkPIQzy5n PEiWc2AL28UQFuRDAQY7jqg/7KxOnoRTiwo4xyFnoQ2lC/W3Ugx5bCQbx40dg3UTksXqNjm+ Ghi8OAlJ4kER6M0eD60LHfAroCblmTRjtCDxdFi0cJFhQ6OtVwhTMkVMGsWLl6BtstzQZgd4 qN69WTUee/QxS4aW1i97vNB5vB7tJ6ysbqVKlbIAqWXta+/evXLnzq2ZWdKG/blkyZK0DA9I /qsNGEYOj0JHTZ5C1I99e/hqd0fERQcvvqASPXEdxjl92nT6vP02DdPX2lHQUwb0lApqHtwr dcN8ebJfzma8Xj17jB0zOrwnaK9Qu9yajbZodHQzWigwJ+t8zWrVAb5QFZ3Ei8EDUIt4EjmG lxQ6oaAmqmY4s3XrKxbXcEwpgg+0ZcowK2T60yiNtosJ9YDVU958Dd2CUJIVjRo2omjZaFnR O3ToWKhQIbApVGi9V9O4VKmS6DW6JCreesomqljRIqxEemCTJFHhpMlnazwiwyp0SyBJ+z2B diSAzuG5Q4qHLHu8iPH2G3aFsMezKgm9o28XyC+uZy5IKv4sVbIUiZF6LVmHSZInip9iUbfO 0f7NBzbVGpekWkiaUfYE4yRfgSotYck8AH2VK1OO7AJ8hSZjLnYX4ExbNc8IrWpmPKOY+qAw W3GaNW4irI51F9SOUs1oqWB14UKFCepXX32VZdhCCZ7qwWkxwLelS5acMSPCml6ezJY6qhzM eKj21ddeQ0+BYmDWoxQpJ07s2LH9jTeiRADIl34Cx4iWvTZaH20zorC4CPjkKVMIIpEjYTqC LXPH9h0Qj8G6Gc6Tb9Sz8NUL1qe/Wd6rbqNbZ35sooiUMKqQQGn16jWsKThWz4gG2jNE6MQS ZpWvhpdCLicobzwHBuVyEQDMKoLiUGSgaY3Jeaq1Y3XJp02bTrsL9snsBBebUt8Kj+9XEl4k m8gJC5PIJmZAV3GgGXMiJTws76idYWJn9ZMbKc4e1gVTDU1JPmahJLalCP4afzSz3oVY2PAh vYULG6ox0DPtt6M68ps3G4ApJV1BQ4NETXowBpZbQXfhwe0bx0+YCIubOQ+bpk6dRp671/r1 68yJZchPOcF/npONKymJseL3Gn+SXVMqeDL8mqwxWX5KKCMxsaTSUyoqJfSTnbhDgo/TFBZG kvIJYwsnU4+zf40vyoBrZHo6znVJ0ttZB5Y6pAyBlg3BmsxYlgFn0daS6T091TGiIPtjvtM8 pK7xqccZbJn5JKlskzxdWALOMXWnW0bzl0auZCfS9Jn0DKRnIEe7E876+s4qtc4io86mkATn +RkyJEYYhjOpP1EUQuN3IqHkkosZZJo+P8QzkIP3eGd9K1QSWxf/zmHXOvrWW7bmGcn54n18 0FEDa7HCrX3+ed5bEKegv9m6MKPbAs6YPoPrwh4yoBbfifF0yJDDCmLbmJofNhmwQdrC2WVd /sa3DzHpf7CPlrMZL2Xbdhqn//TTTwe7c8xOpzcGSWOmF5462MuQC1Azlr3Qnj2aoa9xo4YM bsAuTI6YBO6EV4oFnJlUtGW3rl1eBLOMWSqDac/cQ+pHFgYG1WRfl+w6kjFI4yPj0OkGHywV pO/+vs9ADma8iGdi0xk8brAQbHt1Gx/xsCFDnh78tLBxDm7cAZEo5Jm5TBuNiTt2wt17MN1e TgXJMzmvubm279jBssdCPf+ZeTiNKRwaA8SRI5v7wWfylKmSJsGOuTDOWxzJPKZCljfH7nLo 8GEeYSbQ3Xt261b2LrbNKINDDBzzZsNcGwOMr6RMI4YNjwXv0Q8+19z7TnbpG+ZgxkOv0FLl ypWHHfEiBw4YwIErzaOTeZ/IU7VqFeikyBfUrBlJVbx4cRlQgI/gvzZu2sixK5vlX2+9Fe+1 bNni9zf/XoIGPi7/eCCkypk4YeL9997L7ydjUpfOnSQO4Em//fbbpUtp2iTKJxkJq1P/ASuT GdYRcJkERDxyNWrWBONgKBejoPOKFStyeERcFzOexpzCXTp37t2zl5Qt0Plc2AaZ1jk/aqyY UxnPuNHrUwUKBlAIoAmpFXLxQ7s3b9rMDqxSpUpbt2yRlgfWkRe7dKmSXNIA7zKIyP8FMMX3 ChIpb7E2OpHoVnJleaxs88TCgXqSk9WqVMVpoDAEY+sYnl+2dGnJ0oOWSAWV/8cBNNOi2Fk8 Y9p0OZdopFHeruPHuKrlUwqN9QBXEVUFOHUK0AMUAwBaqiwyMGwm05+PzgzkVMYLMoQjWDiJ FNHgVLBUgb4BxKLceBE8ql4E4GzcGD6LqQOhO1mhbNk5c2djHjpnzHivUB2rx4xH3EmJi9Pk gcM2sqqCwsAHSwoowSOAYuu4BwBrGXXCvcSqdI0DYVq3ar1s6VLgKeBdQa7u2L5dlBxaQthp U6P86j4ghe3btAnHVocA/JXzC8Y6zXgfHZYLT5qDGS+ghwkxsEOSqnSJkiG3PugwQL0DYGWM B7m7dPESMqpl8xYeWA5Glkk4SRfWrVP3tde22+5RQbUXgikAh2pKTI0fO44SmPeJJwCa2rRt K/BHviqRYJrhyZUrngvTh/F0G/FzhQoyTwtKCGhMEq91XIRAHjuBambZjhRqXjhpcN9rKSWZ A7E/bLBpxkszHvDTtddee8Wtt96KQMPyHD6X1T7EYEDpJaWVLBkKmdTq2LEjbbN71279+/WX MNOAYflBpaLkykuXCleV6hz1V6lUUeQBqcX0Iic09K3AH8hJqGKX4C6cIMEjeKRiA5C44FGY Z+zo0WvWrpXpmX1EgmqAr9mz59jgMZPA4LvR3XfdBbIklTpjZteu3aZOnRKCaOSulKFdRoOn nx7CCkqiijETmtCrZ69JEybojVjmV0gzXprxcgbjeU+AjIIjxYABXkbrwslTjPhEDd8A6HME vNyxg1gTSCLOUkESRkvbQtZOqHzmRJdjV1vEkLpD5E6IA1Aoz0n7QDGjYbkRJKql9ObYLAKI viqkJToOFWrs0BYtWoh7FZojHl24YOFCv8aZRU6wrEBy+mzdGoEYiTtgaE5C5wUZgTtu377D lvKjRnbp583BqqaXl0jj+PgMGGL4NXm8VIdbuCq5PGkTqCGLkE8AK2d12WVpn3ptfIvTSbJS 73jmsC8vVSLNEu/PDORsxnt/5ih9l/QMXPIZyMGMd56wzOxTFm9YMyK7L4eNaxCA7wRAy/KY voZ3ltRDPjtNnAk6Df0HFeCsKNN33WSee5CXnC4/9B3mYMbzbpYtWy6vUcI8iQUoOcj+/jQW GGoPFkfuvR6Fk3+gL9l4hNvZN77TKGBKhYTbpkaPGYO2wWVgYqK0lpkg7ezP66HUalQ55OWX N6uywJcYb1Zfj/JhZkOZAuLYKvOvvNMy5LxtsL1uFi39A525nH3zHMx4iKBZ0yZRfoTMj/JU IcW/g7h2+elPwJSFp4XknD51GmMMt4GkfdH5zEC7ZDoyY/ZOB3R7zxmiJlPmRMaSk6nZrDM2 mUnLhEwDh5y5zTu9I+W3UEU5yOHTci8TZcrkw7UYJeTL3JfCo6m5lfp0MppED5gZER9+4tnv 3r0HV6dEZkp/GKp8M+r1hV8Dj4Vj7scK5cpivDNHmHoHNdNHuC87kDXLD2pNhoLVOZv8P7jR 52zGU3VNcishycePvQ2DIv+U5Hxy4xQvXkzCPLZEpsXVa9ZESTgkxoyqdUcVt9XiYsEXcCAB GQKKQJfHjqmJB4epJDrz4yG5igUl7NoVYTJPnFAfWGQ6OSFHy062yrhouISqfnIlAlabJi5D o0TOZoPRj58UFla7izMd54SMmu7omKFVOjC5H6XE4pZg3pT1QGIyFxJlADeJjUeGwlWrVovp VoKPTz+OSY9YRfrAkOCAT9+v7iKdCd8GDKrjUAuJKVU6CZnzpE6RlcSA9+7Z7Xk5UdTc4TUJ 1SfNlXEaAyeK3oTnO3mQBfiNndJym65169dp76TBw52q1KM3hm+w1aefHhzVOr8Myhp/cOxz 4XfO2YwHrSIBifLWXTt3ARC55Za/cLUpaHjLLbeEBGFAm9Wj/MT1uRMgUVCpnLZ8dzhBklaV 2WSMlRcE/cFh+lUmr/vuuUeZO7Qr8xxwCWkg52yUDnDrVkWbpd9CjqNHjxoSZ/gy8T169ChX tpwkKMDZfHTWAv4JiLCyZctyl1euVNG9otSA+/Yjbn6IRQsXkFdr1z7fpGkT2VflIDEGGACZ nsmoqHH8oXzCl0n1JSFn+bJlIcsgUSdMGO8nydQsHIBplStXIb2hdv7yl7/ECQ5fhBZQh10e Md6RO+64Q+Yy2ZnuvfdeTPXs0iUywEoPY7TyC4HLSFgGOOrCjRvWgwpUr1ZdAb1Vq1YpQKmu rdybUVKTOnXAXC09JnbihPGm4p577sH55kHVctrs5bBJvnDy/+CufEfGy58/P8JN1TYutyk2 NimGZJImpmhTXG1y/vB3m0y5vgkjnAZvqZmVfuHCRSFXCroPBcf9BNglozMyIhlyP/jgnNmz nh48qG3r1nLOyeEhPzSwGFHTplWrXj16Eq0YMs9jjxFTZGZAqBBxvPa41LF0Q/37RlXCBeMp m4r96GalS5biMDR1SjHjH7FIdlM6DBMLU0ogG4l8hFguPEX4SUag4XFwEymsN6kyn3/hBWxg n+avx1RqPGR0pWRKOEsiEbkyqamjkC9PHntXEDlZUlaufE6dR8147WU3mjZlqjLikXq5b7+R h6TLBw7sl2aTDJ8xY6YM0PJhmgQ7OreQH0ViMnVhZROcOWM6AFDPnlFv1jWLVFrVvGDOzc54 NKCbbrrpiqpVqwL+XuaMR7ysWPEcCIsCvDRJ9U0RLoUQWIwWJKnrvLlzPYJ4BVlxwrMIsSPi qIING9SXT5LWhIvgXYQSYUiJruCtmzRuBEs5eOBAVYXJrihT6vLl7dq0AcvEWoIhZJgO2fIk DnJ56Pm1ba/Cdnbu2Im0UcnZmTgZbv0AZONFV80U89t0yfnpDFEmJ6SD9u3bcf1TFKFqMG3o DbmHxKwYT0QFvVcaNfEWBq9SsfNMMmQUw4m9Wf26Uf4yCq+MmrVq1yarqakGuWH9Biq3NOna k2x8/ThfAV05wmTgVrs43ItOThrj/HnPPEMaW18sBDLf1qsjT/spD+i83mbNmCFTU7euUW8k /JLFZ2S/vmAS/GhemJ3xFLumpFwhg2/RokUvc8aT2hUpSAlesVx52zDYMcv2kbeOUNuwnxgc ATgegUBApgwDTtLTGFRgo6mp2M+mS+o7mqS48pLFi8u3aeNmyS+YL7/U1IhVSnBKJjYr/ORT UgOKbn/iscfJKM1syeS9kkIzlCUI9nr64fBhQ/2VcJrEK1tabfG3jTBUAnCJVJz6sUwApilR 4BKiiXFFmrAKRNCu3YapK3FG3bp09atr6caGR+IRxX169ZZkNrw2m668efJs2fKyXK6ygHk0 WDn1ekg8GjV0uASb4pjIbUH0+EfPAZ0zsP8AS0OZ0qVkE/NVOQcrl9mZPWumNcjKMmTQYJEZ AjU8ZqMG9a1fJJ7UzoI8BF65pEXLlhL+Ofhoss3FP3V2xgscd0VAjl3mjCcv+nPLlrEcEHFY TpSd1OLibiz79jlq7lj7baLwGIrv1bM3/VBouaXdvmh4DKSOFu+2bUNx+qqVq7ZqFSGbyTGp pnUrSK9gwYKRyDp1Cn+iYDOO1iWTtSHs3iNKV96vbx85p7Foz+7dataoKREtD4fErOqJlyhW nJa4bes2iE28JOxdks98efJaDkaNGvXE4483btzIMCSEJPEwHouFyKahQ4fRgXfu3GV7ZgXB xpLwYlTWlyaNGotdAlUjOYkgkRlgop6XJJRJmtosV6xtWMECBUl+T6rAyNKlz9oysP2SY0aL c+gyZUqXkb1X2maZKsUZCi+kJ9u7UoNpBzQFYVDuiJNZj9q0aknM6g3oVLSUxzd7xi+TvI3i 5bYBuXiWeH96yM54xB2hd4WXdPPNN1svE9673KYYKdOR6E5WcTF1NnUkwPoNG3x1nkyzq0G1 dkchpSSDJFMe6cQJwOgXWeTi2CI2TFXv4t4OImL9RKa/3XvYF0kbPUdugxMnXCjVioOouDYi PfLWGzsjNKb5YZthtECpLIohyTnepvup0SF1vN5wkZa4RVJkmzSWHssERlq1ehWZaTCYnPSL IKbHjslFaYemE4MJedfd2rVUSrfWf1zL6Di9kYWGePdePDg902aS0SXq8ODBuKzfgWich9/y q0+cJ+aE/wkLJMPDa2Ud4WkwFXL1unVczTxqSWzqwSDdSD+GZ0rDjLH6CunwK65Oavq9P8T6 YbpLFsbzpq666ip/I8aTzJxp7rJlvGBbT/xRiVcqOWC0nD49Y2uXnAzaUXioxHCf5WSYlHM3 S9pkX7pwvs1bq1atK1aoGDaZqb2lKhFZ5jal2RkJocP55Eapw07tOXUkyeSkOvdSM9CkdpLl eVMHnDEJmR7CZE6yDObDxBLvz7NkIZuE1yLGw3+0TRj/8CYuN4l37gkK/rdIvr2/nyj38/Hj FHVxQ2SCeSNC3wXe9f6OMH23y2EGUhkvldEixvMRrHnfffflUMYLw34nDOR/a/ZjKGQiyoKa +n6P4b/1bOl+L9kMpDJeqmqZwXgIiKWFvSXHSbxLNkPpjtIz8F+YgYTxmFEEnYeqmj6nGc8p 9pYs0ehn3aikT6ZnID0D72kGbEmYMJPd3BmM5wvrlp8lin1PnaYbp2cgPQPnmAGyDlvhvdQ2 pyVeOEvuPfLII1xAmDA9m+kZSM/AxcwAbrKvo2GmyrqsqmbqDYDI2Dldk2a/i5n39LUf5RmA Z7jxxhs56pJ93bkkXvIblnMNZx9rJ6OLvR8P7Ed5HtPPnp6Bc89A7FuabadGZ7zyyiuFH2RR L8+L8ZJGPA0MnsQl9lXqPv1Jz0B6Bs46A5REbILr8N5ZpVwq4/1/9BckHFTJneYAAAAASUVO RK5CYII= --------------000802080706040803080708-- --------------060504080105030603040702-- From cabo@tzi.org Thu Oct 10 05:15:00 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97EA721F9468 for ; Thu, 10 Oct 2013 05:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.128 X-Spam-Level: X-Spam-Status: No, score=-106.128 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4FCj3LZUAy4 for ; Thu, 10 Oct 2013 05:14:55 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 92CAD21F8235 for ; Thu, 10 Oct 2013 05:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9ACEn9T001411; Thu, 10 Oct 2013 14:14:49 +0200 (CEST) Received: from [192.168.217.105] (p5489015C.dip0.t-ipconnect.de [84.137.1.92]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6EFBD4EE; Thu, 10 Oct 2013 14:14:49 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <52568C5C.8050205@ifi.uzh.ch> Date: Thu, 10 Oct 2013 14:14:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <33A6A7A6-472B-486F-94F3-F420C7A1674E@tzi.org> References: <8896EFF2-BD1E-4634-8195-34580E1096F0@tzi.org> <52568C5C.8050205@ifi.uzh.ch> To: "Dr. Corinna Schmitt" X-Mailer: Apple Mail (2.1510) Cc: core@ietf.org Subject: Re: [core] Travel planning: some CoRE-AA work on Sunday, Nov 3rd X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 12:15:00 -0000 Hi Corinna, good to know you will be able to come. We still plan to have a "hallway meeting" (in an IETF meeting room) on = Sunday from 12 to 16. At first, it didn't look like we'd need the whole four hours, but that = is becoming more likely. In the end, the participants will decide how we want to use the time. It would be nice to begin the meeting with the participants introducing = themselves, their backgrounds, their general way of approaching this = problem area. (I will collect one slide per attendee for supporting = that introduction.) We then want to talk about the drafts available, how they fit together, = what they cover, what needs work, what of this we might want to propose = for standardization, and who might be able to do the work. If you think that discussion would benefit from some introductory = presentation of your draft and its relationship to the other ones, = please do prepare one. (I also would like to make sure that any slides prepared for Sunday are = being made available to the CoRE WG.) We do want to focus the time on discussion, not presentation; as usual = we will be assuming everyone has read all of the (relevant) drafts. The agenda for the CoRE meetings themselves depends on a number of = variables. A call for agenda items will go out shortly. IF (big if) the overall IETF agenda stays the way it has been drafted, = we will not do security-related work in the Monday slot, because of the = conflict with the OAuth WG. It is hard to plan the security segment on (what is then likely to be) = Thursday, because we don't know the outcome of the Sunday meeting. We certainly won't have time for presentations of all the drafts. The best use of the time on Thursday would be to arrive at a plan on = Sunday, and to present and discuss that (and probably some technical = background) on Thursday. This would require us (on Sunday) selecting a small group to prepare = that slot and probably a few more hallway interactions and emails until = Thursday. Gr=FC=DFe, Carsten On Oct 10, 2013, at 13:15, "Dr. Corinna Schmitt" = wrote: > Dear Carsten, >=20 > as mailed to you some weeks ago I will come to Vancouver on Friday, = November 1st. I have already some appointments scheduled at the weekend = before IETF 88. Thus, it will be nice to have some more information of = your planned AA meeting (schedule, location), because we are involved. >=20 > Do you have some updates for the meeting you announced? > Is there a presentation requested concerning our AA work at University = of Zurich? We will update our current draft " = draft-schmitt-two-way-authentication-for-iot-00" within the next days. >=20 > When will be the detailed schedule for IETF CoRE - Meetings available? >=20 > Regards, > Corinna >=20 >=20 > Am 11.09.13 15:24, schrieb Carsten Bormann: >> (CoRE =3D Constrained RESTful Environments, the application protocol = work for the "Internet of Things".) >>=20 >> For those that are interested in the CoRE Authorization work that = started in Berlin, and that haven't already booked their Vancouver = flights: >>=20 >> We are planning some informal technical discussion in Vancouver on = Sunday, Nov 3rd, starting about noon. >> The objective is to achieve mutual understanding of the technical = approaches and maybe some merging/taxonomizing of those. >> The objective is expressly not to discuss how to do this work in the = IETF (rechartering? BOF?), that must come after understanding what it is = that we want to achieve. >>=20 >> This informal meeting will have a strong "we assume you have read the = drafts" component, but otherwise open to all interested attendees. I'm = CCing SAAG because this isn't strictly an applications area subject. = (There sure will be a lot of interest in other aspects of applications = area security in Vancouver, as well...) >>=20 >> Details of the meeting (drafts to read, agenda, room, etc.) will = emerge soon. >>=20 >> Gr=FC=DFe, Carsten >>=20 >> _______________________________________________ >> core mailing list >>=20 >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >>=20 >>=20 >>=20 >=20 >=20 > --=20 > From schmitt@ifi.uzh.ch Thu Oct 10 05:44:44 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19C7511E80E3 for ; Thu, 10 Oct 2013 05:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.817 X-Spam-Level: X-Spam-Status: No, score=-5.817 tagged_above=-999 required=5 tests=[AWL=0.780, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GN+9IOECYnPe for ; Thu, 10 Oct 2013 05:44:40 -0700 (PDT) Received: from ladislav.ifi.uzh.ch (ladislav.ifi.uzh.ch [130.60.156.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2533D11E8141 for ; Thu, 10 Oct 2013 05:44:37 -0700 (PDT) Received: from authenticated sender schmitt by ladislav.ifi.uzh.ch (postfix) with ESMTPSA id SA; Message-ID: <5256A134.9020604@ifi.uzh.ch> Date: Thu, 10 Oct 2013 14:44:36 +0200 From: "Dr. Corinna Schmitt" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Carsten Bormann References: <8896EFF2-BD1E-4634-8195-34580E1096F0@tzi.org> <52568C5C.8050205@ifi.uzh.ch> <33A6A7A6-472B-486F-94F3-F420C7A1674E@tzi.org> In-Reply-To: <33A6A7A6-472B-486F-94F3-F420C7A1674E@tzi.org> Content-Type: multipart/alternative; boundary="------------070808000403080400020901" X-Virus-Scanned: clamav-milter 0.97.6 at ladislav X-Virus-Status: Clean Cc: core@ietf.org Subject: Re: [core] Travel planning: some CoRE-AA work on Sunday, Nov 3rd X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 12:44:44 -0000 This is a multi-part message in MIME format. --------------070808000403080400020901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Dear Carsten, thanks for the detailed answer. I think we can base on the discussions within the AA-group we had in Berlin and due to conference calls over the last weeks. We already have a good strategy how to combine the work and existing drafts of us. I am looking forward for upcoming discussions and ideas. Thanks for organizing the meeting and hosting the AA-group in CoRE. Regards, Corinna Am 10.10.13 14:14, schrieb Carsten Bormann: > Hi Corinna, > > good to know you will be able to come. > > We still plan to have a "hallway meeting" (in an IETF meeting room) on Sunday from 12 to 16. > At first, it didn't look like we'd need the whole four hours, but that is becoming more likely. > In the end, the participants will decide how we want to use the time. > > It would be nice to begin the meeting with the participants introducing themselves, their backgrounds, their general way of approaching this problem area. (I will collect one slide per attendee for supporting that introduction.) > We then want to talk about the drafts available, how they fit together, what they cover, what needs work, what of this we might want to propose for standardization, and who might be able to do the work. > > If you think that discussion would benefit from some introductory presentation of your draft and its relationship to the other ones, please do prepare one. > (I also would like to make sure that any slides prepared for Sunday are being made available to the CoRE WG.) > We do want to focus the time on discussion, not presentation; as usual we will be assuming everyone has read all of the (relevant) drafts. > > The agenda for the CoRE meetings themselves depends on a number of variables. > A call for agenda items will go out shortly. > > IF (big if) the overall IETF agenda stays the way it has been drafted, we will not do security-related work in the Monday slot, because of the conflict with the OAuth WG. > It is hard to plan the security segment on (what is then likely to be) Thursday, because we don't know the outcome of the Sunday meeting. > We certainly won't have time for presentations of all the drafts. > The best use of the time on Thursday would be to arrive at a plan on Sunday, and to present and discuss that (and probably some technical background) on Thursday. > This would require us (on Sunday) selecting a small group to prepare that slot and probably a few more hallway interactions and emails until Thursday. > > Gre, Carsten > > > On Oct 10, 2013, at 13:15, "Dr. Corinna Schmitt" wrote: > >> Dear Carsten, >> >> as mailed to you some weeks ago I will come to Vancouver on Friday, November 1st. I have already some appointments scheduled at the weekend before IETF 88. Thus, it will be nice to have some more information of your planned AA meeting (schedule, location), because we are involved. >> >> Do you have some updates for the meeting you announced? >> Is there a presentation requested concerning our AA work at University of Zurich? We will update our current draft " draft-schmitt-two-way-authentication-for-iot-00" within the next days. >> >> When will be the detailed schedule for IETF CoRE - Meetings available? >> >> Regards, >> Corinna >> >> >> Am 11.09.13 15:24, schrieb Carsten Bormann: >>> (CoRE = Constrained RESTful Environments, the application protocol work for the "Internet of Things".) >>> >>> For those that are interested in the CoRE Authorization work that started in Berlin, and that haven't already booked their Vancouver flights: >>> >>> We are planning some informal technical discussion in Vancouver on Sunday, Nov 3rd, starting about noon. >>> The objective is to achieve mutual understanding of the technical approaches and maybe some merging/taxonomizing of those. >>> The objective is expressly not to discuss how to do this work in the IETF (rechartering? BOF?), that must come after understanding what it is that we want to achieve. >>> >>> This informal meeting will have a strong "we assume you have read the drafts" component, but otherwise open to all interested attendees. I'm CCing SAAG because this isn't strictly an applications area subject. (There sure will be a lot of interest in other aspects of applications area security in Vancouver, as well...) >>> >>> Details of the meeting (drafts to read, agenda, room, etc.) will emerge soon. >>> >>> Gre, Carsten >>> >>> _______________________________________________ >>> core mailing list >>> >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> >>> >>> >> >> -- >> -- --------------070808000403080400020901 Content-Type: multipart/related; boundary="------------030201090500060601040706" --------------030201090500060601040706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear Carsten,

thanks for the detailed answer.
I think we can base on the discussions within the AA-group we had in Berlin and due to conference calls over the last weeks. We already have a good strategy how to combine the work and existing drafts of us. I am looking forward for upcoming discussions and ideas.

Thanks for organizing the meeting and hosting the AA-group in CoRE.

Regards,
Corinna

Am 10.10.13 14:14, schrieb Carsten Bormann:
Hi Corinna,

good to know you will be able to come.

We still plan to have a "hallway meeting" (in an IETF meeting room) on Sunday from 12 to 16.
At first, it didn't look like we'd need the whole four hours, but that is becoming more likely.
In the end, the participants will decide how we want to use the time.

It would be nice to begin the meeting with the participants introducing themselves, their backgrounds, their general way of approaching this problem area.  (I will collect one slide per attendee for supporting that introduction.)
We then want to talk about the drafts available, how they fit together, what they cover, what needs work, what of this we might want to propose for standardization, and who might be able to do the work.

If you think that discussion would benefit from some introductory presentation of your draft and its relationship to the other ones, please do prepare one.
(I also would like to make sure that any slides prepared for Sunday are being made available to the CoRE WG.)
We do want to focus the time on discussion, not presentation; as usual we will be assuming everyone has read all of the (relevant) drafts.

The agenda for the CoRE meetings themselves depends on a number of variables.
A call for agenda items will go out shortly.

IF (big if) the overall IETF agenda stays the way it has been drafted, we will not do security-related work in the Monday slot, because of the conflict with the OAuth WG.
It is hard to plan the security segment on (what is then likely to be) Thursday, because we don't know the outcome of the Sunday meeting.
We certainly won't have time for presentations of all the drafts.
The best use of the time on Thursday would be to arrive at a plan on Sunday, and to present and discuss that (and probably some technical background) on Thursday.
This would require us (on Sunday) selecting a small group to prepare that slot and probably a few more hallway interactions and emails until Thursday.

Grüße, Carsten


On Oct 10, 2013, at 13:15, "Dr. Corinna Schmitt" <schmitt@ifi.uzh.ch> wrote:


Dear Carsten,

as mailed to you some weeks ago I will come to Vancouver on Friday, November 1st.  I have already some appointments scheduled at the weekend before IETF 88. Thus, it will be nice to have some more information of your planned AA meeting (schedule, location), because we are involved.

Do you have some updates for the meeting you announced?
Is there a presentation requested concerning our AA work at University of Zurich? We will update our current draft " draft-schmitt-two-way-authentication-for-iot-00" within the next days.

When will be the detailed schedule for IETF CoRE - Meetings available?

Regards,
Corinna


Am 11.09.13 15:24, schrieb Carsten Bormann:

(CoRE = Constrained RESTful Environments, the application protocol work for the "Internet of Things".)

For those that are interested in the CoRE Authorization work that started in Berlin, and that haven't already booked their Vancouver flights:

We are planning some informal technical discussion in Vancouver on Sunday, Nov 3rd, starting about noon.
The objective is to achieve mutual understanding of the technical approaches and maybe some merging/taxonomizing of those.
The objective is expressly not to discuss how to do this work in the IETF (rechartering? BOF?), that must come after understanding what it is that we want to achieve.

This informal meeting will have a strong "we assume you have read the drafts" component, but  otherwise open to all interested attendees.  I'm CCing SAAG because this isn't strictly an applications area subject.  (There sure will be a lot of interest in other aspects of applications area security in Vancouver, as well...)

Details of the meeting (drafts to read, agenda, room, etc.) will emerge soon.

Grüße, Carsten

_______________________________________________
core mailing list

core@ietf.org
https://www.ietf.org/mailman/listinfo/core





-- 
<visitenkarte.png>


    

    

    

    
-- 

      

  


--------------030201090500060601040706
Content-Type: image/png; x-mac-type="0"; x-mac-creator="0";
 name="visitenkarte.png"
Content-Transfer-Encoding: base64
Content-ID: 
Content-Disposition: inline;
 filename="visitenkarte.png"

iVBORw0KGgoAAAANSUhEUgAAASgAAACgCAIAAAAw8WZPAAAAAXNSR0IArs4c6QAAAARnQU1B
AACxjwv8YQUAAAAgY0hSTQAAeiYAAICEAAD6AAAAgOgAAHUwAADqYAAAOpgAABdwnLpRPAAA
buNJREFUeF7t3Qe8FtXRP3CT901i2htTTVeTGE035Z+YZkxijFFjQcVKVXrvvffee6/Se+9I
R0CahSqCgtJBQKTl/9099y4P9yIiEOXq83zwus8+Z8+ePTtzZs7Mb2Y+9p///OeKd/uMGTNm
5cqVWq1atWr//v3v1jz9e3oGPnIzcOWVV/7ud7/z2DfeeON9993n67tMAcZ7p8/s2bMfeeSR
q666Skd14s/o0aOdTH/SM5CegSwzMHny5MAjWAbXYRnMcg7muuKsvz333HOuvPXWW59++ul9
+/ad4/r0T+kZSM9A9hnAdTjopptuwp9nnZ+zMB5mu/nmm8/Nr+m5Ts9AegbedQYIMNKLGMze
MivjVa1alax866233rXTdIP0DKRn4HxmIOifWXjqDMbDdRqdOnXqZPqTnoH0DFyKGcBNmLNP
nz40z1QuPc14NEx86bc0412KCU/3kZ6BaAYC4/k0adKEYEt4L4PxKKP2dUEaphkvTTLpGbhU
M5AwHs4i2Ii3wHsZjJdq/bxgxsvk7XPovWkl9lK90HQ/OWMGUhlvx44d1157bRBvEeNxQdxx
xx0Ju7wnxjtx4sTJEyeSa/fs2b1mzZrp06YPHzp02JAh/jmYOmUyifrGG28kzU6eyBmzlh5l
egYucgZSGQ/9ly1btk2bNhmMh+vw3oUxXrhq586dkyZNatyoYY1q1apXq1anVq0G9eo1rFu3
ob/16tWrU6d61arVq1WvX6/+6FGjt219NVx1kY+Uvjw9A5f/DGRhvJdffpnQixiP4INNSbV1
no/EI+hsBl2/ffuOnj17li9XrmrlKhivaZMmXTt3fnrwoKlTpsyeNXvO7NnTp00bNnRoj27d
WjRv3rhhw+pVq5cuWbpTx46bN28K7KerSGymP+kZ+DDOQBbGQ/CMKYsWLboiMWa+J4kXGGb0
qFHlypatVrVqy+YtunbpsnDBgtkzZo4bOzb7Jm/evGecX75sWa+ePTWuXatW2dKl+/fre/jw
YY2PH08z3oeR6NLPlGLVTJgiIMuuCP9LZZVzSzwsovGunTsbN2pUsUKF5k2bDujf74Xnn8c8
zg8cMLBCuXKv79hhzhM5dvTo2y2bN2/YoMHxY8e12bhhw/BhQ1s0bVa1cuWaNWps2rgxrXam
SfTDOgPZJV5Ak12RP39+3r3zZzwtX968mW5Zr27dNq3bLFiwYPOmTXv37Hb+hRdeaFCvfptW
rVu1aJnwkoO5s+c4o/3gQQN9XfbssmeXLiX9Onbo0KhRw9IlSzr+b8i9YPi55IbU49aY4yfi
5enSKclRT8czPD5pj86HiAuzMx49k7Z5RRbLCgY4h8Tz6ytbtpQpXTrs5ba8vMWZwQMHkn57
du/R47/vvPPfd92FLZ0/cuTI4UOHHIwaOfLef//7zjvuaNWyha99+vRt3qz59te2b33llT69
e7do1qxYkaKB984x4cnSENqkPs/5X3VJXijGyzKYLF8v6C6RvvD228defOGFtWvWHHrzzfPZ
aV/QjdIXva8zkJ3xgn3lCiDOLADqs77y2JryH5EKNnXNmzXr3Knj/v37aJj169WbMX0GY+bK
5cunTJ78VMGCRQsXLl60qM3bcyuemzljhqt6dutWMH/+J/PntxvkynDJvr372rZp88zcuW+8
/kbMe81Lliix5eWXw9Yxu63l2LHjSxYvNs6DBw8ans+xt48tXrSI8ebNN98860Rqc/To0WZN
m+Z54vF169ZdQjrW1fLlyx95ODeJ/fbbb7u7UZHhe/fuveC7RPrC88/f8+9/f+H//u/zn//c
nDlz0ur3+8of/7WbXSzjRULm5Ek806RxEzZJTNK5c+eXXnypdMlSFM6li5doMGHcuP59+w3q
379mjeq7du3EVBs2rHfjwQMGdOvSuX/v3jWrVX/z4MG9+/Y9u2RJm9athw8btmDe/Igze/Zs
3bKVHeORw4dTN4cZwu3kyTffPPSrm276whe+sHbN2iBe9u8/8LOf/vSLX/wipgpSOhB9+DU8
LSfHN77+dfGIvXr0SG2TCMxwSTI1CdtEfcVdht6yCFhnmjZpqtsfXn/9gQMHjr711r3/vucr
X/7y2rXR2MJVZ3QV95X6ZrPcMQy+YIEC+rzt73+rVq3qhg0bLoyHQ1cXdu1/jfbesePsmsI7
jTx5rZdwkBc8S8mFyajO0VXyrpOHfW8Sz2Vjx4whslq3arV169Y1q1a3atmyc8eOc2bNInwi
Ujt5EkNWrVK1ZvXq+fPmxZlUphnTp1PMGjdswOJSrXLlgvny7969J2KJN97ApdOnTp01c2bb
1m22b9/eoV077r4e3bpHhH6md+HUyVOHDh36xc9//vnPfU6fmYy3/yc//jH58NJLEeNl/3jg
48feHjt6NA5n7EkaBHF61kvCSfvC1F+1T7ZeCR/a5TZv3oKEj9ofP/HTn/7ks5/97OZYYqcS
U1ATMroNojzlTJYx/PmPf/z85z+/efPm6PwF4dSzdHjBhBUT9wljiN7FRXzi53jHLXagyH37
9x858lbGHTMfIPWeYcYgLvbu3Xfs2LGLGE7GpfFDnX6lnvQ99RnGGAZ//Ngxo0rOvJPmleW9
nC/jRZR36hQzZrkyZVq1aLFkyeIN69e3b9vu9dffGDVixBtv7Iyf5MT+ffuKFylSqkSJ8mXL
3H7bbfx4M6ZNw0779u3Ndd99LCj8B84vmB+JuPBZtHDRYw8/XKRQ4SOHDlO0WjVv7vL16zdk
ed/uTnH91S9vuuqqLwSp4rP/wIGf/exnX/rSlzZu2Lh39+4qVau0bNmCCM11/3333ntP/379
XMU52aN791q1a7GjEstFixV1d+dPHD9OSyxUqBDLELZp367dnf/61x3//CdPo02pBtOmTS1W
tOjAAf1LlSzlV2cGDhjwQK5ct/7lFiYi82u0NarXGPL009aXEiVKkKsUxNy5czdu0mTcuHGF
Cxfu0rmLnr2fiRMnPvXUU8xXpihsDnfseB2Q4K4777rvnnt5Vg4dPvzKK6+UKF7i29/+1he+
8H+PPfaYTa+Rv1e20X79uvXlypUrUqRI2TJlFi9afDFsE+xSR986+p6IMkvjt98+ijTfiRxx
Ea/Sr3716+B/Mn6zWqVKlddefTXLuvP6668/kvvhv9zyl02bIt/vxQzJteSEV/PSSy8VLVLE
HSN6OG/W03j1qlVVqlTdtXMX/rnrzjvZJ+2ngEN2vrHzrK/swiVeWHL43+rWrt2zRw/W/0kT
Jgzo15/EM61+Oha74Xbv2tm+bZsmjRsVL1KU0Js0aSK6rFK58p7du/kMKlUoX71K5SqVKs5N
2b34SbfPPbdy8qRJWzZvfnrQ4LatW9uVvSfG44hH/V/60hc/9alPfe5zn/vaV79KYSMJly5Z
ao/32//3/3y1GwQMd/DUk0/pnF3nq1/56qc++ckVK1bQb50nTn/60586sINFA40bN3aMl/wl
5Ht07/Hxj30Md/36l78qXqyYHkYMH+Gnf99993MrVlxzzTWf/cxn3Vr7W//ylzGjR/vp61//
OsuTSb/9H7f72r170HVPbtu69ZY//9mZL171RQNwULRoUUP97ne+S2aSeKT67f/4x6HDkVHq
PVGY9rNmzvrSF7/YpHHjMqVKXfPda6ZNm5Zlrc0i6rN8zUIiDerXDyr6WT/n1hpcsn79+rxP
PHFg//7kQbL0w/b2veuus0JFciymMWTg8VetXJml5cL5C0y+peTc488+zuxEbzdeIF++l154
ccf2HTVq1CRCAg4k++esklCzMaNGf/5zn31126vWi+98+9tbt24bOWK4YdsdnPWVXTjjedp9
e/dWrVyJL47DAJXXrlmT6HtlyytBbQsikfb49KBBxYoUQXwMJ+PHje3SqXPRwkU2b9zUskWL
B+6/P+/jjzdt1IhBJfVNWOybN23WsWOHl1560Z6Q2aZyxYpbtkTG0sTEgmAPHz70q1/+8qpo
j5epah7YHyQe3WzrK1u9wv/5n//B2mYk1/33h30dLedvf/3rlZ/6FPfFiuXLceP1P/gByCjx
9bGPfezRRx5hSkXuv/rVr55fu3b5s8u+/73vfeMb39i9a1e7tm01+OY3vwlzQw0mD3XYrGmz
iHliNZXW/Yn//d+HHngAb6Own//sZ/afkDomgXB2U+179+q9Yd26r3z5K9ddey0pF15tgwYN
/PTYo4/ywcycMfNb3/qmUS1auNBk/u63/w83mh/KxQVAeXTuWur3ju2vOc6fL999993rYNu2
baR0o0aNyA2moA4dOljsKlWsNH78eL+aPQxWoWLFCRMmWEb7+/Tt1759+759+qD13/z611On
Th0zekzXLl3r16/ft29feweT7EldK+1VyxYtrarI9403XgdB7Na1K5EFR/HG66+b3s9+5jPl
ypazGw+i4PChw927dStXrvzokSMJ/0YNG331K1955OFHwoZWhzOmT0PKq1etHjpsWLeu3WrX
qt2nV6+XN7/M4/W1r32NimFuF8xfULlSJauz9/j2sbcZGgy1d+/e8+fPN+zWrVozmLOu165d
u3//fnQMQrJevegBJ0+afOjNQ7ZCn/70p5944gnaVvfu3V/dts19bRkqVKjYuWMncqxbNMJy
NlCJjhxeXLJDmThhwnXXXkOhe+CBB1CLm9Kzvvud79h9XGLGi5aiyZOrVanct3dvE2pZmj9v
Xs/uPRgVkiXZxBFfdWvXKl2iBN4rWCA/bHTtGjWeeOzxhfPnFy1cqFTxElTNxx99ZN68eanj
8wLwkvfXrk1b74+QbNywkYmM22RoAIHxfnnTTV+86iq6QZiIAwcO/uynP2Nc2bRxE7fEtddc
861vfSvMY4Xy5RE3kJq3/feY8RZRKU+cuOOfd2AnXPf44499/OMfR08jRowgJ6+++ms/+P73
se6nr7ySyFm/bl37du31QNsM96pZvYavhEm+vHkxcMJ4D+bK5cEt2L/+1a8w3sYYCeDTqVMn
7b1dmqQDil+w1Wh5+23/+N///d+pk6eElsyYH7viiqcHD3Z8y5//5BZWorO+v3eVfq7CeD/+
0Y3r173k2GMa1fbXXnvwgQdKly6NDRhvmIK+fvXX/3LLn8uXL2/GVj73HDpmMKtUsSLSIf//
9te/0R2KFyuKmH584423/f3v3pdrv//97wPhMiA98fjjjzz88E0///mePXtoB48/9pjO/3n7
7XT4z332s3nz5OFM+v3NN1tWSpUs8fWvX61zQsbg0bHjm37xi2rVql1//fVDhwxF93g7f778
mD+T8aYbxuqVq+jhN97ww6pVqnztq18Z0H+A4V199dWYbf78BT/+0Y95s/7+178ZCRv7d77z
bbxqOaMrff6zn9X5jTfeYCbDJYTkvGeeiVaW+Hk5kO1Hrv7a14x85IgRX/7SlxYvXITrvPpy
5cv36dW7Vo2aP/3xT9q2aQvnGI04/jAH7tu7J1CjiaXu6Wr2rJkF8hf49je/2aNHjxGB8V6+
1IxnUlq2bNmsSZNpU6fOnjWrQL78hZ58avOm6DanF+Z4E2jBo4K21rhp0+FDhloL8z6RZ+6c
udAtlhOYsjq1a82de4ahXCe4ZdCAAVga3VAz3Kh+3bpvHz29u4j2eIcOeWfUuUQPsdx+77rv
mcRXXtmC8a757ncxD1+iDpECcqcVZzDelVdivIgfOnZ03j7zuuuuu/GHN9iU2gqSk7RBK6tF
vXevXkOGDLEussdoSVC4yt2ZdpiUCEYnTTrl3rJH4sWM58W8GUnjq64KyoYP6f31q6/+7ne/
S9H9zGc+E7TrsOdElJ/8xCdmTJseWt59190f//jHRg4fbtfxpz/+0TpCfl4s470UMR440c2/
+x3z1be+8Y3q1asRgN/51rc2rN/wk5/8JISE/b9f/waxejSbAjveb3/725jtnnvuKVuGsh19
/n3nXcC3DpB4sVjBxsl2sLSeG274oZf1oxtvLFKoEBFHsg0aOJA2sW7dehTyg+99nwCc/8w8
rLt7d4SsoBQdPHDA5W7kq/UrX958NpA//clPpkyaFJ7XX+IUBa9ZvcpiUalSJWd+8Yufe4/0
+R//6Edert3NH3//B+fnzpn9/eu+x8LHrNWhfdRnty5db/7dzQ6KFStaqlQpBz/76U+s4wcP
HJw0cSK59K1vftMBU/uNN9yw6rmVa9aspoksXby4QH6mwLzhkd3rB9ddZ80KLOeVEQx5Hn+c
HiHsJrTBeFh9x47t48aOY2nXDDE4c4kZz51wfO1aNQkBhIXErZED+/c/cvjIGVvJmPEG9OvH
X3fLH/8oIqFVq1b0GS9m5PARsNF33XFH7vvvb1Cv7jPPnFY1g5pK139m9pxXX3112bPP2gKx
x9SqWdNXUiJZ5smKe/59D7q3CmK5I2+9xQNBdPzpD384fPgI1RTjURR37dplwKVLl4kYr3v3
LIxHInmvn/zkJzEbQ5GWtsX/8z8f/8Pv/0DHCNO6d89ef1u1aqkHARaBJmgsDvCbd+a8NXLK
pMmB8fhYvFpbxM9+9jMzZ8586+hRQ/VQeZ54gnS1M7zlT382gYm1wDvWAxsS4TNr1syvfvWr
FNpNmzYee/voJWG8SNWMTbhUuHz58nF+WpuEokTaY9++r732Ggq2uGjw29/8Bh0XLlS40FOF
xo8bT6ZhvHvvucci69djb79929/+1qhBzHiPPVayZElbod/+9rd0H4IRw8yZNfuGH/7Q47Rr
165bt+5Urx9eHzEeje5HN9zw+o7tkyZOuuGH16OKTMY7aHnq1DFikvzYLm9eKr3BkDxZGG/t
mtUYj2LpjtScXj17zJ8/z8xDbjA7sf1qz8/pdbNzSOM1NrbNWDdN4FtH3ipSuIi1wBnXDh40
GF8xoowbN55YmzB+PDObBZqoF7x23XXXLlm0mJvXJ7x9HwqdJZ5QDZYwBGrPXLBgweBAThiP
Yd80/uJnP7eg6Pa/wnicdZUqVOzfty/RRJR5+LlxxrIzlJ9Tp6KtUes2jz/yCFNPoSefZLKz
DbUXomHmfeLx+++55+EHHyhVongWVRNOSle8eeXLlitbqvTLmzaNGDacO962J7lFsO7QDEkP
VGtl/fGPf+yAAAxKmhWBpkcR4rjz9amnCvm1U4cOGA95OZ4XbywjGnr8CV/pmfNj/yEevuvO
aP/2zW9886+33oqSbM8MqWmTyLjCrBKuMvV/+P3v//ynPzn585/93F2gwx3f8c/bI9Pf0bf/
cdttvtqxMI1SuV1Cif30p690I8SdPIiDCRMm2ohrHGm2n/50tHVsEhmT7F5wL15lbcs6t++q
ZcYNXEXaXPWF/6tRowat8qc/+TGf/ltHjtx9513snLiOZ4V8u+GGG/51xx3aWIOsoZ733nvv
bdSwodEOHjTI17qxnCeBWYft8ZYsWfLQgw8SmJw6P/zh9XCGzlAR1730Em7MlStXv379vYXF
ixfT3J5f+/zY0WO+8bWrX3t1m/0IzblunXp8sJH0OHnKevrLm36h/x98/3vDhgy1xuknvMEw
/kzjynN01zKly7iEUIpcVnNm2w6w6onq5DtlD/vHP/7x8MMP79u3n6pJrLmWfmg5sI1kFi5e
vDgWcS0VhsXBIBs2aGjHMWrkKHa1a7/73WJFi8nR/OUvfXHJokVI9Jvf+EaFCuXJTLLOpvHv
f/ubBciON4iWQAPJMaqmVFvr+/Xrd813vst6BJjlzMZNZ4ccX6BxxS3ZAJh9Md7G9etNk72s
dTSb5fTU3j17atWoQdvs368/QUdjHD923LgxY7t37fbEo4/16tnLDpjUpnNnIayYc9bPmTnr
1a1bEcrkiROrValii5jaLIwe7z36yKM0qN/f/DtK7MQJE6MZOXmS6YLW7n1gJC3tCiypqJCk
kujCcsXOHhlFTv0H0gUNiRikT4Y+Ga8xmLn+/e9+h23sNo8fP0am5c2Td9SokWHSeRSQoAW1
RPHiwYPPKmMppQVYF/XDfkhJ++Mf/mBxpXlqsPWVLV48gYYWkwcJkpPZ84FcD+jt3nvu7dun
L/Jykt7VsH59BEFeZZvb8+O8k6dsd2vWqFmmTBnvi0IY6AWJoHVCb8yoUXjg5z//ueelyJFv
brRi+YqKFSsxhjVv3gwcp1evXjNmzAz384y2RowrWo6MzSFt2rTlzrELbdq0KdXLbNNrSpcq
jb6Z3CxPFDANoAvsAL3KLp0716hZ004s2SzR9umBQ4cMiZTPgwebNWuGl8Lz+mvRsR/zRiwT
4ydMwPyWLZYSYkqfNiMeiOOX8QPgnvT2pnhTV65cpQOLSPv2Hdgdhg0bzt5o9SS6Vz5na7Ky
YsWK7dq2a9q0mS+nTp4YNmxo5cqV586d26RJ02ARwUulSpVs2aI5FjJ7xhC2nYnCmbxBJ9nh
2Jm4o5cvX4ZaQD4YKfiHdu7cddYXd+GMN2rkCM9pO2TG+/XpQzcI+JIsH9qzrVqgVK+qZ4/u
S5csYSgfO2Yswg3nWVCQfhbGMzKq4+yZszp16EiVJbgtwEwj2ZuFTuyUCJlwHCGLjx9PlqXw
Nfzk48WEg6AuZsdYnnFh7BqJrzrt9c6Yej6tlMspk4Fb4saZ3Ub++miNDOexPVMNs0TcQ4aV
KBpqpgNdJ8k4Q4vw9UK57mTq06VOTnIXB5Re3kJrfGaD03OV2syDhDiSM06mTGY0pbGqknxQ
aXwy4yniB8qYRi/Fw3oXqSSYiiXIJKSM9kmz5InCGV1mecbk/SYHJzIHGRxd2T/ZZyk1f0Jq
e2/8bAve6YfKmMNMensnxPyFM97oUSObNGw4aOCANatXYyFCL9ipsjLe668PHjjA4rRg3ryh
Q4dWLF/e1q5e3ToWcraKFcuWPb92DRGRnfEisjtxgnmDJ501zBJr09+hfcSrZ9wiepWR3yKF
QDOwIGG9DCQb+zair5nH0fnIG5wZphS3cybTaXoiK946/JTKAKk3DbfMaKCnTIdK8s7sdkDG
f/Ob3/zPxz8ePGkp98q4NpXlkmdMHuFs7/t8zp3hBs4YZ+QGP33ezpxxclkmHj1pk9F7ZsvM
Z8zwFWUAieKOwin/S+YhzHP0Y+bf1DPJcWr7cDJz6s71aPFbzHiEjDd4+sKMyYxXtvCM8WsO
RynPknqD0/fNPJs8Vvxc5+tKT52qcNMwK9kf5mIYb0STBg1sABg/+vbuQ1PasX171oX51Enb
6B7du61du2bJ4iV0D1av4sWK534oN92M089+w1aYNynVgR5GqSsrIhvM1MmT165ebXfets3Z
GO98aO+cbc4hTM4qbcKUZZ+45GTWu8XtOSHs3Ig7bqjwdBc98EvWQdhRx+p5+vM+zcDFMN4o
sqtf374vb9o8fOgwaiToY3Z6YlRo3KD++LFjJk2YaBNFarEWCH+gNDLiUbvpkFx8z8zNsseL
hJgOqZqCD2wbJowf53bAIqkSL2gyWT6xKHv3JSqs08m1Z7kkFqRZnyhDrGUsDUGlJCoTXora
x4tw6gt0jl4wfuzYZUuXXjzW8ZKTRliUz2fSLvmtP7IdXjjjzZo1i0fO7o6Jn1zCVCReNhTv
qZ2vvzH06aeZJWV5GD9u3HPPrWCoFezHz8bzvmTxInFmAVR9pg4ZEf3uXbsF+DVt3Hj5smep
alUqVZaeLGmGUN566whQKLACRJx/0f9ff8NW0xJ+Pm/Utg0yo0XzFnrI3p6tr3jRYpCWYJ8Z
N7UTO3Vq5vTpDRvU50WwdWbCejh3boYZXgoGJCsFW47gpuyyI3V1OJ+xpdt8uGfgwhnvpRdf
tGGjZLKckntVK1WGLcimap7avXNnm9atGJHZLZk07QnFH4wYPnzqlEnMaM/MmQPCUrlChSyq
Jqai+SyYP09L1iHBdazD3AlgRwnjOXj22We5azm+v/+979/wwxt++hPW8p+wPmfdB57tHWoD
z816TgPs0L79GZfEu8ED+w/w7TA3c9QGPSwe1X969+x19113Pf/883//298pzLkffIiVuU2r
Vjf/9ndQS4zXwXvx4aab9NNd5AxcIOPZtRAIsGAd2rWN4NETJ/bt1WvksGEg3ll4jx8PQgUQ
wVatXp3anTq0nzVj+qwZM8SniwmaOmnStMmTy5YqlYrVjLekkcmLnXfixEmECfNuuzZtuCX4
W1IZD1CLP5S/FSry+ut/wOuNi8ZPiNCG4RPUp3DM4JYchzMEJgt7rvtzrVq5KiiHqXKJD5SR
nRvQEpN6vl+fvgBQrOr/uO0f856ZB3ixcOHC3j17Yjnu6V/8/BfBX3+RLyZ9+Yd7Bi6Q8QKN
Mkvy0tDWGC25E3r16EmyZaE5+h/n2/wFCwYNGkQWsX/CxYEOtG/Tlpth3JgxrNhdO3cJ+Npk
rh2/+MKLTRs3nT59OifysqXPRpCxevXejhDrGa0i5nz7bcIQcAyUjDMN1/3zn/90hhWUX5GM
1fTwkUP82pHR9QDZvA+wYMaM6Ry7RiKGCMNjpNdf3xFQzgsWzHeeXxV4JUBPOHO576iRTViA
ZkcgL+VvwRpvu+22alWr0YS5vAsXKgTnTYCDlYJZ7ty1K0H0fbipJ/10FzwDF8V406dOg9Vi
q+QlB03gN0wiwRMRQeJhMHEMUPDQJ3yRi+3rnn8eAA9Kk1bmQxcNEi/1s2fvXszTulVLTmeQ
P7Z4PsNEiMVSMXrqcAlNVYwCkMRS1ov//IfqG8D+jnfv3oU3YAi2bttmt/blL38ZWpIL+9NX
fgrAh5aoZfC589sKSvDVBzrp0KHDv/zlLwU6XHvtNeGk2KJFcTwbvzAMDe824QZ8LNo92l/u
3MlRy88bocMu+IWkL/xozMCFM575sQsSWQdrv3DBQqSPjnUnxiR8jsrRc+zY9ldf4zSHwo/5
oQ/XeWAVYTUCTMMxYRLhvk+eDFfF/44GnyZLyboXX6SsVixfAWIzizh1iX7hG/9yyy0YI8lH
OGDAAF/hVLS3KED04UlGIJLQpg4CS0YZ64ULBSx+/H8+PmvGTKoj5gTvgquIIi3mz+eWxHga
61zyeVApfYK8ZFkgsn+9rFwFHw0yznlPeeGMFywNZAvjXpVKlbgHunfp2kUIXdu2Hdu3jw/a
AUbyH1SqUKFzhw7du3QRU2eb17VTpy6dOrVs1kxcpgP/BA3Vr1vHgWtdqLEDpk6XQ8oBKHVo
115wQ3auCxIPCAhL/O63v2MFDWwwcOBAZ4SWOBa7ASKMozIZ79uEHkSSn/D2vffe94lPfILH
AtzUJaVKlEwYiWYKF0sGBldHk0YRUDOEJuS895we8WU2AxfOeIHoyROM0axxYzF1AszBncFZ
alStWrJYcdgUdsiSJYqTV+wiUoxxxLVo1hSXVqxQ3p4NrlrqB9wovV+F8uVEo8vCAjztwJap
fNmyMtuKCxbhDvgXAo5SZy+IRKBHGHAIY3HWCc9AtWKSggUKOmNrx/KZMJ4wEPbPkOKFQBYV
ivHIW+nMXAKV5nyYFPKQpcSFIdhPUJIGHirNeJcZDefI4VwU4wXeY9IUEsrMwJjO9gjNLEpN
zPi0KVMdkCQTxk9wnsSgjjKW3HfPPYLBxRAJNxRiSLUTAFq3Th0ijspXl+WzY0cxfngAZzYS
zFi/PvuHG2X18J44CZ4pegM/PFmwIMuJVWDXrt3YyW7QSeGYrqI3iuYWBRMkHsZjBQ3xYIHx
/vcT/wtC2bB+FAPONBJyfjLb4NjAeHzfacbLkdR9GQ/6Yhkv5r1TjRs1Jgrq1a3HrMevBRVF
HEWwzMaN+bKLFC4s8teBXH033nCj8BPmeDEX4tA3btwApSnEi+4HPoYnwcapdrff9neARior
BmYtlEkhOx4FMzCifupTnxRl873rrrWRu1702HXXiR9l5Rdf97Uog8DDbiTQTiiKZAc8H1/5
ylfiCL0Mxrvrrjvxm+Xg2aXP/t///Z9jO7q77767RrXqkaj88Y9lTAlRtqJX/Er8piXeZUzP
OWZol4DxdCHEA2JDkIHkFrAsQoDhbhkwJ44bB8zRo2vXIYMHyXriQIRbrH+W+MY3vl63Vi0h
RXJptmjalK+MRte+TRueCciPAX37yWUiaqNkyRJCE95pd4dp+bgF2tA2JbqQSuhrX/uquFtG
mqJFikoJwV5SoEAB2YfkPhAwwhopPYGgSRKPNkniiQoVqC+oxC369O4jJyet9cpPXVmyRMk3
3zwoQwTx+EKcwkyGGFbNd9pq5pgXnh7o5TEDl4DxgpWFIle2dJnmzZsjX3Aqhkr1Ejq1b1+m
ZKmunbrI605vnD51CiVT2pnyZcpiBtksbJzq162HY/3jKO/TsydoGBu9/EhqLURxbjHRv9Nc
SQYvLdTpj+Pt2wW5eCoBLMRvCKySzUGzYGt9fcfrYGU0yeNxrBAOZF8NAU1hy2ozKdAJPEAM
DCeBzjkJPCNbi2eEGk1jGi8P0s3Zo7gEjBcmIOK9ba8KJcRLHHpt2rQWB2R3JIpRRL1/XNJQ
woKgBQLLsCBHC1w1kWV/JcUFBJYNGKEnmR+/vA2eXNROnluvS6wpWQ7CeLJ8AuI5nEwc3Emb
yDNxZs3opJPgHkhtmbPfeXr0l8EMXDLGC2HUZAtZx1ApE96A/v1BsZIb0DzlgChfpsyTBQqo
RpLniTyMnPIOLJgXGet95JKQb4cuV61K1Tq1a2/bGqUGuwymKD2E9Axc+hm4ZIyXyD3cItIH
DlNFBF4v6BNGS0Dn3Xv2+NuwXv0QF8MKKlWE8jcRimXaNJ43fMiAoaIQeFeI/730j5vuMT0D
l8cMXGLGS0DJ9k7SYJJd0kKxpjSoX89XyWSLFy0yacL4qZMnVShXntuAVGzauBEHoH8ay/YX
cmCmue7yII/0KP5bM3CJGc8wQxR9YB6aJy8f/zhnQ/Wq1TgY+MS5B2r4r3JlTvOqVSqrSaIc
lwwuIuoyWC4leP+/9dzpftMz8IHOwKVnvNTHSQwSUJ2SK4p2le5TZJ0SsIIS4EXomcrHnbZb
XE4JET7Q95K++Yd8Bv67jJeksnkn82OmiEvnHfiQ01n68bLMwH+X8dLTnZ6B9AycdQbSjJcm
jPQMfAAzkGa8D2DS07dMz0Ca8dI0kJ6BD2AGPpKMF2w+mZ/zmfX31PhdO0y9eXbkZzgTRWOk
ZD4+V5+Z+Zsv7SDf9SnSDS5mBnI242VHY57PXCDULBe+61WXFqgZYOXJJwvvqScQygBHjBRV
s36XD7R3AjJVGyCN4X63Cbssfs/BjGfoEpCJJFDDxUeKlMT/fu5k95oJVgLR7tipk7ydIhIC
DPqdPn5dvWZNz569xDGcu+V5vlIDWLN6jVwZ3bt1X71qZZY+fVVnr3jxElteeeW8bnfqpIrN
hvf88y8YQMoacbqkxHkOLN3sfZuBHMx4KEwAqwKOii0LxpPWUshcVAg6qFyZJXgcJEIgZIuQ
4EwyCFnJfvXrX//gB98XOBsQaoFkIx0vviTjZCxNVFFWhW9BnE43yKLkwHGYxDNOuntSR+WM
WhnRANSjEkAo0k8JVaWJw02TSkO+CtuXSDcpc5tUPgoqaBhYUnbHVxVdRB7iPceyYsvYLWGh
XqU5DWWHo/7T4IT3javO40Y5m/EmTpz46U9/pkOHjmKO7vxXVEoS9jr1kYjBKNleZmklxA0L
qoghupdmQq22lzdvUhA8cNHevXtCEuhUPsSD5OquXTvXrn1exs5Enkj+Jy1nKr85Vv8tFLIy
87hFbbTdu/YEvTF5F9JVSMJ7y5/+BCAu6yGJnSDsDr75piSBcoS2adNGVC9MuQhj5cdSxyMD
m7sEXtW/TG6ORQkKXAxh9YraWVNCugqRh4Lyk6Lt50EP6Sbv0wzkbMZTAfiqL1wV6qdLMi0a
XeoHRRQ6deoo64TUg+o0pJZN10w9a/wp5C9hIQc4UCDS9773vWu+e43KktgMyrRixQq9evZU
JlL6sxUrlovKFeCLGYoUKdy9e/e//vWvxKZKLC6H9q5Vq5a6hJLJ537oIdyC4nPdd79q7IqD
Fi9WLMTmxlLq5JEjb/38pz8V6r569ZrTYvP48c6dOunwW9/6drkypQ3v61+7OveDD6ru4kYy
d5LkkkpJhJEvTx55QQUZlyhWTP4YgcUwd5s2bVLYUZZeqXu///3vKT4uf+GggYOUQZUlTVpR
9d+tGmmZ9z5x1Xnc5sPAeKHcHBnw6KOPUgiVDZMB6ZOf/MQd/7yjR48eGC8p3aORDLyf/MQn
1CVPpJCDfn37OVm3Tl3JNr/whf+rXKmiSPZrr/nu16++WtXyBfPnhwy5KJtodfBArlwSY197
zTWqr7BnPPrIw5/8xCeFIFavVv3jH/+YMoCkaL06dWfOnKXqqqroI4ZnVPQOeqngep1IAwMr
HmSsYoNXfvJTTxV8UuXuaVOnafCpT35SNaUuXbpKgla7dm3Z5tVzJ6uxk+f62BVXVK9eQ5Jf
Bd+HDx9uYPJ/eljppG6++feSO+XJk2fK5CmVKlV2F0XGW7RoIaY+bXc5D454n5p8mBjvP2qs
KyA+/5l5aj5ffbWK25EOqSxoQnC+ivdD06rUZzBeJAVOPProI6ovBKVOaW+UunHDevJHnukg
lDCeXCxKN6qy4kCKNCextxzvbx48IKyesMWBG+NkSnZofnVepRZK41VXXdWkcZQGNxJ48Rpw
7NjbzCo33vBD7KcT8vbJgk/qYf++DLy4pGxqNrwYB+Cr7S6HmtxnNrHKEjnTrl27r3z5SwKv
rA62uPICW2vcpWfPnn4lLV3L2uRY9hqrg7ymqXd/nygrfZtzzsCHgfGYWBAWmlZ73gIvhYQg
9x/dcOOBffsz9MlTGVusQJfIXXhuJCIzjSKqnP/5z3+Wy8zJwk899aMf3Sj3EsZTuzyD8fr1
y2S8ufKOKccZGO+mm26SEwnj/eRHP4qDel/A8HL4CryQRRffyu1px2XnmZB+YoORWub+++77
8he/+NILL+bO/fBvf/tbwjncDuMRtspq40kGmEJPPRUYz4LiV0kTv/XNb0iJv2nTxm9945tN
mzSWoA3jqVTuV1U+pc1evSra48ntfc13viNxcHjYNC9cPjPwYWC8efPmI6xhQ4dR6iRaJ0/y
5817w/U/3LN7DyqP0hYpdRJ/NGPHJxBQuaRjEY3LOX/0aJlSpSXefHnzywTSH/7w+7/+9dZX
trwsXyCKPyvjqeXgvLydzCSB8X584402cljl61+/WqVbumgkA48fW7Vq5Re/+MWmKRLPSfUk
QreyHhqMjEw1alT/3Oc+F1JWR4zXurXx2E8eOXLkhz+8PmE8i4JfW7Vs+c1vfF0WpsB4zZo2
SWU8aRaxuiVAyy1btmhQpnSa8S4fjssYSc5mPDsi4uuvf/ubRJ0sCtgAsSK4B+6//+qvfVUq
aHn7ZNGcOmVqEDiB94TCf+ELX7jh+uvt3277+9+nTJqocAIr4q9/9evb/n7b5z73WXwlv5hU
gY89+kjgBNYUN1q0cFHY49kKOkmgsce4S+7cD3FoOOAAkM+ziZj6GjVtGnPlyvWnP/5R+9o1
a4YBUDTfOnpU1m2bwwceeMBmjFDl+mCTNE7M9uCDD1WrUkXCqOBOOHT4kAd5/NFHidNvf/tb
IUVvwwYNlHRWHWXd+nWf+fSnpfpUJ8xdOnXqHD1dr16Ob/nzLSqHSvL7y5t+oe6KwkZvvnno
sqO+j/CAcjDjRX7t1avLly//1JNP2iMxLXJhoTx03LdvX5aSw4cPod1ixUvIlptpVMwogrdk
yRKZJvLlzVumTJmQoX3pkiWly5QhWzjBfN2/b7/k1gMHDoom6NSpRYsWlStXzsZJ/s9y5crL
FoOJevfu3ahRY0qgBBb16tU/fOiwnLlVqlRRBkwy3BbNmxmXHNgMnqHPsMezFRQK7KcCBQr2
6N6dwyNTFK9ma3niiTzdu3aTSLtq1ap6s+1knlGDRQJCObVlpqEvsr5UrVKN319hzWrVqqki
ZmDlK1ScN3++rrgWWrVspX9Zfd1UGaZiRYs1atgoLpT77jiYjzAvvK+PnoMZLwvwKoim4DtP
jsNBIu7iqWVXzJr8L0tXiWxMlZOOQ82jjM5jX3y4Y3KQfTazDCD49pOTKWPOejK6XVzMPdtd
Mu6LiVNulzGwgBA4PciUeyWmnfeVvtI3e4cZyMGM54kCICP5JM8YzoSv72RUOPdVSedJJ6kd
huPkLllud8avmbfJMv/Z736Wx3mHu5zrdpmPnPrUqe3TjHCZzEDOZrzMScyE88d5ls49s7Ek
OXviwFAUNsiZiA1SOzpxdgY+U5ZGl4QJvbC3G+RbKt8GGXthvSVXpfYQS9ywZFxst9lHFeT5
eRpPo3m+yAfLyZfnYMYLalXMJxnFzVNddmd9KciCnVAi97MSDaZl6oTw0HOis6WSLzY4gxmh
yQ4dCkBKn5DS9+jRt0DMLmA3hR/Azdhgjx59O1Bwklz0+LsFKZxDpgW7bpZBBlY0d5eWdJN5
i5Ljv8MKmDHUeInxXJd2ADmotxzMeIYu/bsqPw5e27Zt5MiRGStuCj1loUgvm9Fvfpy7OnlJ
QcI4M3bM2LJlynAqRILr5MlevXoqmB54+9CbB2vWqLEmNpkmOiFoJQxXEhWhKkP//v1nz5rZ
qWOnpNlZNcwst05t075t29WrVrmcfaV69erlyparUaPmwhicfVaqSgafNIjQ1plNiTWrABvp
nrgsWXhMZiR2I3lMzd5Zx5mI3NN3jKYoQ7s++zD8GkmwE6Bt3bt1MxWhWap+Hs6E/ScLsLLy
qswT6HGb00tA/MoybhIdXerV4TJhzhzMeN4fFOWwYcMcrF29mjkxxazwH2rMGV8zzQwd2rdX
F8VPQeVKbcNEmdRIQQ4lixd/KNcDwavO38BTFy5MPvsP7GeHJD/DGX48BlI2RgX9UpvFq39W
m0pQa8MnlSKV5gRDcRICUywSg+2Lz78AL5baONFmk5PPPPPMCy9EjrvsHzRdpnTpBPzN3aLP
uXPnrl+/HtLgrFOUejI1BiI5HwaQxZATfuUyZUNOFqPs42FP5tv0yM8tXx6gQhmTQPU9ccac
ZJmfy4RhLtUwcjbjATEHZti6ZUsokrx27RoHEF4onS9B4T4FjJT88ZxDnh4CzIXspPcM5G55
htKEhLT245l//ON2QOdDh4CJT1HzlLYtVrjIizFBk5PFihThxHPVwAEDXeK+Rw4dIiGbNWuu
OBmfOAwXMSUdfdPGjV0yccIEjgTgSb3Fmt6pdevWqT0GWaLw2PbtO/r169+sWTM98+D79O7Z
S4F1qLckGogDoGbNmkYCitm7V2+IcEU2ZSilD/MouESue9VdDB7MTb0xGG6xF9DhilhzpZBy
XO2G91SBAkHi+bRs0Tx1+bBqqJ7rcaZMnkT2zJgxs0uXLk0aN546dVrTpk1HjBjBf6j8k3ir
nj17jBo5yvysX7/hjTdeBwQ1FRz3oS6Np2ioEsaYsaIlxowZy5uiTevWrT2vmoRmHgZ9/Ljx
O19/49FHHgHdduHE8RN4VlauWKGUd9u2bT2Xik5eh/cFgkPfBtCrV68e2PdpCXipqP4y6CeH
M16PHhxxFDz0V6N6dZuZmjWqL126lMyZO2f22jWrVSnqipQ6d/YWoftR8MO5c8+cPiNQ4YRx
413F+6wi9IplyytUqICybRTDm27epInqYoMHDrRjaVCvXtu2bZC4gs9g1oLcSpUsaWnX26hR
o/jxlPJbv2FDsaJFpk6Z3LJ5c5KTgrdi+Yry5crjk9Dh2tVrli97dvCgwfh/1apV4pjokGTm
ooULJ0+ajDQXLlx0/733GXO8LpzikYO6tr/DLerAvPzylnJlyr7x+uuulX57wfwF4h6sC5gN
0UNI099g06wOHdp3oAh07NABt4wfPz7XffeFrMH4X83QLS9vCeuOvwL5pPQGDADIVtUMB5ol
K8uDDzwAzlr4qULLly2/9S9/GTd2bNHCRejVVjRTQWxWr1YtWo969hTN6NdHcudetHixsocW
l7x58ryyZYvGvKkrn1u5bcuWObNnqZgtOmnDunWtW7cSh4Eb8z7++I7XtoOzzZhuwO29Jrgf
RUsVG9W5laVooUKehVj+UNpgcjrjdcc5EydN4j1HuC+9+MJDDzyABIXwwDELz1F+CCwLir9P
r17oA61079o1YTyiaVG8fVK62RIuvGD9+nW+hl2HIipCSJX1e27Fii5xmQegUChKQkybIUOe
dgv4LMoVE0uNaAe42r0wXpvWrYiRpwoWhFp+5OFH4mJjERR7z569cG21a9dRBX41aRzXW+cc
VzJJjaTFixZFEql58xXLl6cwXjWi28Ixa0a0WACg7Nq5U6Q5BrMXjW8XgXKQOEf53j17H3zg
wU6dO4uHsvRUqVgxCDq3c5UDXcHQIPqE8dxu7uzZvpooSb7bt2urHwjPRvUbOFmnZk2kryq9
Y8vX4oULYdAUuLeiQc84CbNqVmnXVA9fmzVpGuEQSpZc/uwy/JzQlqXNSzG2DRs2KBplzHTR
EsWKLlqw0AriwmiJqV5j+fJloVvIoeHDhls+OnboGJaMJKLyMpBVl2YIOZ3xeii57sVs2bwZ
HYPzI3cUbBexbdurVStXUbeoV4+ezZs2xVpjRo/REouKQI/kXUQoTYT8OOjTp09c46Hl889H
dTAD4ylstH7dOu3xtj5Rw/Rp05FmYDzhORivdu1aGI8hVJsMxpscM17/ARaC5cuXr1m7lh2V
ukipU5hFvomhQ4ay06xa+Zy7h1tPGDcOPwcLCjVvxbJlWRiPNJg5Yzp5VblSZbqfZPj169XT
Zt/+/YSneHYYmvnz52G8fHnzzJkzd8WKFQBlFcqWjRjv1KmK5cqJMAyP3LF9h4DwDh86ZFC8
RTnFjNeOVCf6LEmmgPoAc1eubFk6uQr1JDPgTq0aNaSrSBhPKv6pU6d4Cp24iq2rdMkStsTl
SpdW/dNJJRCB4BYvXkJXN59DBj89bep0ANfiRYsuWbS4Tq1a2hi5NWXF8mUe31cQ9rHxy/Jy
K5YvB/j24bOw5GzG69ShA7LzhtauXmWZP3L4kIrQY8eOmzNn9tZXtqrCZ9OCRqtbpNeuLVu2
7IwZM/55++30yUB2djIVCY2pU9lRtmx5GcosWBRjxjtRvUoVYT5UtVtvuQW5d+3WbdLESRiV
MjZt2lS6mQiAu++6i/Ylao5eR1oWK1x4wrixlDEaoOKbtCb/mBDYcWzkShYvMWH8BMTtdkgz
ADi7dOo8dtQosbyRfjVt2t9uvXXZ0qUx451EjuwiMN842bpgVJUrVcLSipm5+7atVLjZQn7b
t21H4tE2d+/ehR/69+s/b94zIoawa/v27QcPHqTEvP1neK6tW7fBqhmzqaDaPfPMPHFStqYl
ihWn1EGWkdgUh9o1a5gBxQynTJla+MknBUlAfs+bO4eSSQCSe+Da5u3BXLlEA5oiMln/BrZw
wULMbxMrWMmiYAJ6dO9mxZk/f/6/77rTRprMr1O7Di0gz+OP7XzjdcqzXZyWdolUaOuXfhg8
Bw0Y4OmETRbMn4+4jhnvQ6Vy5mDG8yps53CUA+YTlISyrNYtmregpciqYLPEQgDfGCwco0aN
FlBDY6RrhU0XKUT+MGYKnGOnmz17Djt4+IlWNnPGTK9cLDnCcvLZZ5996aV13j5SYyBhGGRI
wIrdunbDdSLfhPkISF+37qUgEl2Ojok4VhDCSqcvvvCiMtQDBgw01Fdf3Yaw3IcNEwNoMHjg
IMF77CUqchqAreabhw5ZGt4+dgxSFFc7iSXQqBxJrvUULVu2tDti15HsqEWLlhs2bIRWpTC3
atXKGYKCqta5c5cRw4YdOhhbjOJ93Yb1G8RGNW3SFOLUyfA4OjQDwiNog0L4bWbNgOAmSw8r
CFMHcaeCvFgkthn9WCMYThTTtsS8tG4dY4n2Otm69ZWxY8dQHQ8ePEA7ZXbasH4dZcE4hw0d
ynwiSNLwbJLhV60pONBusFu3bpCufsVqfBI0BTrLwAH9CUD7z2gVjLyCaca7NFruxfZyNhzj
acRjlhUlC0IyZq0zai/7GsRgGFZG+0x3Q3J5oN3wyeKxSAFyngZwRs0yP8mFp3vIhJVmsdpn
ONDjeyV3yfII2Xs7x5nEMJh9HlIGkzF7wcmS2jLJCpM5RWdBlqZ6F7Iv52cdW+pkJpdk91KE
7FUXSy6X2fU5W+JdZpOZHk56Bs53BnI244WlMDyDv/+NdfG8nEjvgOTM/hKMMAMReib67Hxf
17u1o6clYiQW25dOUMT5qoMwjKc6gqWE40QipaoM7zbSj/rvOZjxImTgsSi5nWc4cvhIAApe
SlIL4XMAlJlozOzE4tY+4dbnRUoxgIad8xwpn0Of59XbmY3CTlL/zDkh7V8MXr2Ans5ySUaw
VZxEmCE3mvaTMqYd0f2xY8cxYvxconwjS+alueWHupcczHgBlGxbz5gmHlQmr8R+EA4CBWec
jMD4Z5yMfsgkkYTQkwszcsyePMkAGNIohJkKxJCx0mceMJ8wHjCuhPMZvUUwwwBFPM1FbJvA
GdBtsgwi3+R2qaPN6OJsMUEBpZ3cInNIp/tnfhRcW6tWTaCZZc8uCyDIlIfKGH/2543Dfc/F
7R6Njy6a6qpVx4we/eqrrzVu2Ei0LjOmK3kO1LiHs6lZs4Zmad5710UjBzOeoUNISIk3e/Zs
tjKZS84EQJ6BwwxaEBRI9l0+MRkLh+NhLlIrKyDFjRs2nC4WHRN+zF0Z3fCYAXIxq0iORBSk
dp6p8sX6WCa78kZwasGy6DbcNwnbTa6dMGHCypUrU7six7MPO+PNRewSc2PMj107dwFzEboO
xsUgmfJ2U0N44+CjTANSKmDVc51VdOtH5l9wNu51YLfXXnuVvZEbAGhG6he99ezenbN029at
7psYjd+V+D7KDXIw43nfDOuSWCZEiWgGDRhYpWrV3r37HH377aefHgLhIWPCqBEjYa840y3M
cICcXc2aN2fdrlql6jPPzMUwjPi0MokkeAIgs6Smrle3Hm8SdPLokchr6759e1u0bFGrVm2+
JmEQfG4w+ERcseLF//WvO3E+vziQNN8G1JVkDbyCL7zwYrt27bnRIdpwV5hoRvmypcsEGyZX
Ne+WA64tcrtJk6Zt2rR9Ye3zd999N+Al2z1HWeUqVYYNG+7K0aPHcJPobeTIUXXq1DVgcBl4
EYiZkLrChx+iQrnyQQ8MH+tRl85denTvsWPH6zzgnpcj0Ug4SPRPUXRrDhjhFJ4XkitSHUMs
YmYPiYQ3G+pMJD0DAwG7hK98DOXKlnFt8utHmaPO89lzNuNhKlnDYrmBlE/xDpUvWxbFYwzw
rkKFCtG7+HaLFi4Mc8hxDOj477vvHj92HLAvyCVvFXyTNZs/2n6Ok7pr5058g8CNWKhK5SpL
Fi/hXwawhF8BziBDZKpdumQpkQKECc4CRgzvAh8t1R9S1icHF6xww/r1YankJuKnKl2ylFCA
RMh07tTZ7dQ/AVXhsufyMmYAK5UPeL2xE5TzyBEjXFizeg1eNU5zmaQrV66M1qGN9UnMQoE8
PWhw6VIljYTHMkhX4+Gdc2DwHGikK6aSahrcxIVgJc57XoPx+Dz4ADe84YSYrE3AAIQYn57L
9cbDKdxB4plEVjds0PD5taejoghtqVy6du2q/arnVsLKOjBmrsjZs2afW2s9T9L8cDfL2YyH
Vp59NgPn4cVDPwyPBSBHMEhHvbp16J8L5y/o1qWLkyWLF/NVPAHUv8zNI0cMf/Pgm+XLlFa9
AJoR40lSBPW7bNmzUBra8+pOmzKldq0oHK5i+fJJqAuEIfRJ7ty5582dC5gClmkSixQqTGpF
AMW4aoIIicGDBgYEI7h9iPSJfcCRrLMdhbDhLyaCpkyZ0qFdO7gtTAuo7VeLBeCVWz/84EO2
jlKhLVq0MGStxYEtmjXXpnKFiuDaoGc4n8pK3YwYYOWqgOR6bfv2jh07YoaNGzcEMKSFwNLj
oG+fvqCVXNjQBWRUtapVwFwAXPwEMSOeIEgt0ljaX0tA4EN/HYen8DW4+PbvP2AAAGh0yxAa
4om6dumapFT7cHPORT5dzmY82wxbi0TDGdCvX8h4CQMFMIUa1r30EjgFxsMMJYsVI5QwHigW
/iRVYD6gojAevnLV9OnTevXoQRSgS19VCALdYE4gScqWKqWyl5PPrXgOdtGODriJXgrKGKCP
gPwEkRgCE8qiiCKHPj0kpHZu0gT8MuCeMwwzjjEerVI8IY6dNjWKbNq2bWvZMmVF2UgyLawB
OLNK5UrSh23dtk3RH1wEo+zXls1bIHxISLAsWiGciicNMwAUTrp6HMe2ZDHmez2hGo2hUSPA
SAc0zxnTpoO/gNFE4M+KFa0drVtGz2t9oW068AjgY8IvILaC7HKSug5ikkx1OLCQlS9bThAQ
/Tlgr23zwMqTh71I6vwQX56DGc+6Kw4I2M/mR6wXzSpCSxYtKmyMQkX+UNIYJKOok3btAK+e
zJ9fcQ9qJ+Ai/oTWlTzTV0GiwJODBw/Ony+/JNBUTUod0rH8Q3VCZgLv2klWqlDRBgnErHSp
UsTUww/lxqgLFiwsXqz42jVr8z2RBy4Z9kpyS4AskmrihImdOnTUj3BvgwkEjSswqruDO9tb
zpg+TdkgLI3oGWkMHnga4llsgQgAjya2TVwfM73dncD5WKlr4MFJb2OzaxXWoDxQIHR/NS5S
uPBo4Q6t2xCSJCSkuPNw4bZ/IP+lSpSkb7OFkI1AniJ94dGo3/aQ1atWE0aQdBVYK5C+kZtq
wFGg6nHjxi1cYCzP2OtaDlh9NbMdtYKYeboAqGp84SXyY3xImS8HM17AFqlZ1a9fX2YMUdi+
KpwgqjJKanDq1Lxn5gpPhVoUFcZ2ggPZJ2logkRffPFFOx+bHNs8+5nVq1d16NCBGAQRtPvC
J6QKsbNl88u6xRiWfVYNbZCySBlCxoZQYBty7NWrN7aBzHQM2ElRpPFKaiAsdeXKVZhEEKBq
dcEHsHvXbtB7Ymfzps1GawtHAut8/vwFbdu2U3VMG/BuDYgOGE7PhVvkcdEJeKf+RXB7cBuz
lSufAxPt06c3QRfkUtAAlyxaRFZ369ZVnmmTYz2KvJHHjsFG4gpD0obMpwaDU5PYrP8Vylc0
5kmTJodOEmZLpfloqnfvxmYqNwgFZGSKZmzYcA6MYJ59dslS97XrE5KX2s+HlHEu9rFyMOMl
pJboP6mQwiABsvwUnjb5KRycFQOZ5WTYRGX/pE5flkQSoXEqyDO6XYqPQ6g7AcKtl9ptAhk9
Y/DvkMbi9NPFZBB4JvsgA7onOZ/l0UClGVTDr+dgmHMgRWP80BkOj3DmYmnzQ319zma8nPtq
zLtNXefOnXfv2nlmIsH3+5nYReWcjtj2PME37/cAP5z3SzPeB/Zes8irD2QciWs+QtsdT8uo
9+8lpBnv/Zvr9J3SM5DMQJrx0sSQnoEPYAbSjPcBTHr6lukZSDNemgbSM/ABzECa8T6ASU/f
Mj0DacZL00B6Bj6AGUgz3gcw6elbpmcgzXhpGkjPwAcwA2nG+wAmPX3L9AykGS9NA+kZ+ABm
IM14H8Ckp2+ZnoEczHhxmscMMH5I7hhCb97rS4WZDLMQgIuOU+H277W3828f7hINOyOO4fSl
IVDg3J8kniCjcQhNCBkv40+YkPiJMrJZJ8EZyU9JCEVSFDI1ju7MsImMyQkhF8ktUoeadBs1
eIfohIxHzoyWOOszhnGeT3xD8qbC857njL3b1L4fv+doxjsugaRMOwoehPcktDQqzfMeP+Lo
JIOQux9QWIidIL04LewJGUfE1L1T6EBCxO/xbqebG3AIKfQ3yTLkZyvHoWgw70hGgR/kL1Ip
QfomyQX90YnAQtmZMugvypwbLUzCC50PS5IDl8R3PPHWkWjqhCbs2bM7JErcs3uvZ08YSdj7
jtdff3Xbq8IRpb2QXdRESQkTzU9mHIObRj9l1pR3awUbBPueIywoZHPzV4LAqBTz2RbKI6rP
HDoUErqde3rdyPOLAIwm8JwgbzdSP1C5lQt+X5f2whzMeN6KkiCFCxcpX768mjvmRSEuQdln
ov5Px6Elj5p6gAIkhhg3Zkwo6dy8aZP1L70Ueli6eHHd2nVioZqZqTqOxQ5SMdBxdJz5axLz
FjFPyoqeiKZIIsWfRFxYo5VFkU9JHGo476/g1Hx58qKSs5Kdk35Sk0z6oxrVqklmMWTw4Pnz
5rujNCoSioWrYu49JEGLHBOK9QiWlQRNLgwJHUJ2DPHjhQsXln9T7LmvIoNKlyotq8XmzS+H
B1RJS+2X2nXqlChRQj4YZ6Q2Gz92rIygoorDg8ho5hYh2UT4KLckv2DqY2al1xMnhSM3adRY
foCe3Xsk61d007ipg0mTJgmxdZyljkKsz2Smr86czEOHolJ7wurDTSPxHmVJy3jvyd39pNRu
wwb1w7u7tFx0Ab3lbMYLOeeIK7m3vH605aVaBRFEyE0kdlu0NbKTalptGhOuio3zcS7naJmX
EkKWPqm+oguPH1ezTra8kKlOqhW14MK6G9ggfFSl079mqhxbm8PqLhDbT/v37Uu4S/0gvzqJ
evQfsu6RTqFlLO2itV8AePWqVTrG6YZcK/+SxJsPP/RQKKyV5Y0GaabmkdQS+MqodCv1g1QU
0YAXLmwYF5TMYOAZM2vXrOUWEq5MnKh82Fi50qSZqVi+whtv7JR/dvLEqFyZgXhezC+4XslI
SdNCD+5ltP6akwH9+jspnp1AM11uahyRgD1yBMWHUuYmXz9SV+jBGwlBydnVPyeV1FMQk9Q1
53oIExjl84z0jKiQ4N69+6gbo0eNxn6+xm9nj+eVsjp5F5HUlUj32DGZF4sWLqTCkZ/27tsb
K9sIIJreAwf2hzGEN67iZ4P69dKMdwHLxBmXmE35C6QeMbOWZNXhlFaUXESevFo1a6urLNeY
1H0Ki1etVk3qFOWOK1WsJNlJqxYtJUeRztkbVU1WZjuqZs8ePWlRsnFpQ0qowuU91aldS+eq
z+lNTgdZfVSQrFatuvSYbVq1/sMf/oA4QqJOmQUlcZHQWvE3SVz69elrRVfRynIg54ocKtu3
vybZniRIJJWsE15/RGsxN0pRERjPZ9SIEf379lXQTycJC4WfgiClK6q8l5o8V5EwCSw0UNFS
TdbQ2EdmJDUDpSSUr0VWmKaNm4Q8ufILyq0iA0WD+g0krUDrMlyE0sqknPRHFqkgE5yRu1Yi
I6wlHYb0FmHOlYyVRUJ9eckpLAFS11A0ypevgLFNmhTD7qgs4e7dewIDJ0MKfbq7BIcmPzCh
rKS4i1yVf0lqDPM5YcLEAf0HFCxYUBHZpc8+a3klq/M8kWf9upeGPP10hQoVpcawQjVp3ERi
JSl0S5coIfWTZlKqCuo/8tYRiVUVnY5qa0s3HKeiqVSpcolixcx/SO59scR30dfnbIknKdgT
jz/x5JNPNmsSZbZq07pNvz59LN5UUDm/VCr2RjGVcseoTQlLqY1e3rzl3rvvlgTJu5w+daqc
JbNnziI6MJu/UdHWoUPkyUOyVE2aiaRjRJAstxUrlKdrPVXgSbLIvkKbGtVrWEddSNkjHCSH
xhV66N2zR8F8+W0nsJZ8gZhZs2NH30aO8rXIfSLlHiZKDANy+6mwafwouE6t2mR1tSqVSYNA
H74qE42BQ+72TZs216xZK17Io0IRDtq1aZsnTx6FKQsWKFi/Xn2XHIlqJ0RqcMkSJf/fb35D
vURrmPmlFyMt2pDGjBqFQ3AsQmzbuo1nlKEoqJdlS5ci2SI+jzvv2qWzTDAOqH/9+kVZKnCm
CntPFsj/zNw5tpSFCz2Fc0yC/bAMn1RN+UtlH5UwSh7BaJwnT3quSZMmWhnDE/krd8uTBQvK
oSYHXKsWzTdt3HDHP26nvCycPx/34u2e3bpT/vv37xfeoIQuMhpa7yxnJtYyKjna448+Kukb
SViiaFF7UfMvMWmp4sXVpldfVvFtSdaktLHLxefyXHl98jgaUprxLmrdiFZf5Ua7dpN6VeYv
mpIcRCqJSuq65eXNqEeWS6RJF6JxeT1jxoxWAN3uR6lXKopMW7Z2gwYOkM6ImiR7LD3KCrp5
40aqqWoMC+fPsxVR1TH3Q7mbNm1WuFAhRRLpdWQdBpOtCK0bg0xbJFggTYmrH3n4YTk7EZbz
XraRyDOp6KQslI8+/EjtWrXUHmgoU1hmfRUXSs2E2hy0bdO2atVqhC1VU1KjIB+sDldccYWF
IFAMc0iF8hVcHudgjxp0aNe+b99+iHhklIEvSr9ZrVpV2fgIfyPctHGT7KOSiNKyQs5pOyvF
n4MUOnb8mOxpshjGtZ2lEjtcoVyUri/6Lb5X9WpVg248beq0wYOj1NG1atRcv36DdKO7d+4k
ssuWKW3XJ0116HDNmjVkjgMZqCRfDCc9nUfo27t3xM+ZezNZp3DF5s2baMKG59WYW3J42dJn
B/bvp8w19Vj604h1T5zUZt2LL9FuHnzgAVkGZVKTetAW14pmybPHw3gjRgwnAx+4PxfhLJep
h2VzkiLR17pxweeN6zeEEtNpxrtYxkNDiMacyq4Z8md6YWafUkfJrFq5UmQ76drVrlob/IAC
vKeqFSsxYsppOX7cWGqkjF00N/obxtOPVJxv7NxZQzmO+fMaNWgwYfw4RPnmm4cOxkVV9UO9
JLJY0uSx9tW2SlXUtavXlCxRwg4K71GfnJcXjG4TLrH8Y0V0tmr1qsM0uSgzV/RJrClKk2um
7rG0fOq8/uWWW9wl2HAYFSWcJaAsGWHfZdl+Ji46Gz6SF6JCB1jOoqNz+iHpLb2f3KHO+5XU
tdAQtr7Wr1sXe4RryZMK5ctZODz+sbeP4l5LQxBKfu3bu0+oEe9DZ+vff4CDMqVKrd+wgagk
1mybCRP6BR4IzVavWa0EswNSS20TBzpT+hxTydUZKdjRJ8PIVKZUaZk5ZWcsX6YsPqGTV65Y
ycj79O5F37ZQhpkk8IcNifIUW0qsj8yqllEagc3qgf0HPG+ZUiWlVLXAUV9NjvRNqtWSvQS4
bYOnsxOJ52dZtGlPG1cuiu3ihVPuV6nUbc/oHl6YysNegL2HN03BkHOWQvj4Y4/LZCklprIK
FmbWDUqLNyd565hRo627pCWZwDxDqWNIWPfii6+/sZNiJnlk3dq1WR3Z+qKq3IMGIg70pLFc
sfrPlzcvC2SDevWdl41PyXXcpZ/evXrTyuyC6I0SUBIINDELBIlE3EkFL5Ulug6Gh4gxZsyU
4jJhJAdVK1UKxqFEPjiOWsfqn61agXz5KYoeH/V36tB+aqzU0cQ8e9KPgsaFnnrKgIsULqLW
NLovUbwEg1CdWrVw7zNz5lIWlExo37YtUrRm2Z3KqDtz5ozQA6lu6iQvpKiTyXaMZL6Huutf
/6Lu1qheTRZ3/dDeLXOutQzhwCWLF4WEtj169AwSL8seD08/v/Z59lL8Zj3yq+LYD+TKRQex
ajxZoGB0bfcexKORFC9aTIp+Sqkq87LQSwFM0bXBk5rNg5PVrFk8D9RL2RatHfJk57rv/pjx
mq5eufLAwQMVypbDqHazkhRbGW1D9J+WeBfJeiet0CNGjLQuBlMEFUj9ILttTIi1qKCUfsV3
hg8fMXnylI0bqX6bvWDrPdcTQqRKIeVZs2exgqgr8NZbR5Xz3r9/H3cg4tCnv7qVqdZ+Q4ER
Ak25Dx2+eehNQ6d5yodp48SAqdkLz6+VSRZXUJ+wmeyuVFbjkQyXuT961LhKOCmEaJJ3H+wl
EmwmcxHl+Vy1yvbpbPQRmf/ci3mDP0AaX5TnqVhuULAkogaT9KMZ48eQIUNtdwMvrVmzdsTI
kbt2RuXEJH72UDNnzjIhhBLzCTvTM1G6segT7fcOHpRp0/RqRvvVP51NNls7KJZh02WG5cx+
bsUK+gLiHjt2rLoRJs2qpzG3xGvbtgX5lvrx1XThEzMZKxEnvaOQXt4uMVS091pf3vwyFXfi
xEkyoCqDYdiS1StJz/eowAMlxcbPezRLVlJjsAQsW7bMhFhq2V3pI5HJ9OhR6wV92DFXkzdI
nblYmrtE1+dg40qqNMiyssZrWkoKyxRpEq5Krj2zslesAmUa9MJFqQt2SjcZtofkzFnzYZ7R
PsW5Fw0ghR5Dsyxn3tHwdmbyzOT9JeNMJYxkAIHtU0abJQ3m6WycyeVZKIOim/I4mbXHYqUx
Ow0lg8nuToi4OqWj1JZZJjx7t6nzmepeP+sYkrechU4uEeNcbDc5m/Eu9unT16dn4AOagRzM
eBbLZPRBOwoC6lLOZOYtguk/rLJZbhCt2SnFYrNInowLM4Esrk0VO6niNFEss8jYLG0iQGnS
W1yJ/Ayxlu3howk5w5OWkez9vc5SIo6S580+1Umb0HmQOUGSx6PIQKWeqUecgYzNuCS+PExd
xtPFVplU8Z78FCpsJhpH7IS/pDTwXmfq/NrnZMY7fpxxcssWxRG2ej0HDhxUEOHSTrqXGpAT
sQUyep1gK1lqptIJbTDsKjOoTZVwu59Dh8LXBJpoJ7bjte0xnOKg3SZkhjH7avuhyMGGjRtY
U5JLbOE2bNjI4geWoQ3XCD+4j32XF+Z2Nqs2OTjQ3mzbtlc3bFivOOtZnz1GyBzne1SyyxgS
pMj5kUdGK0NVOMVGLjx7BAw6cCAq457Sizb2xgyOYRjhjRheJuNFLGQ36CnswWxVudftM5l4
wzzYHJoFM2OEoddQKzce+UZmEvMMPrpp8+bDbx6KqDae54ALDcgyW2VTcekX3/c0U+fdOAcz
nilmqCxQoACsCazjunUvhepwyaoZjkmEQAepP6WKytS5ymJrdgksCNe58wiCAZBlLwJ2pIC5
tOGLZ0EN/b999K08jz/OPZg5jKikEeM7uytfBXplZgRe4dTmxEdMjgEs9PB8XGndYI6+fZQR
r06dOmXKlKlapTLjQblyZSFu6tevhzIxKkc8MynPHuMNFEjevHlq166lxhBTx1nsMXFNJYUs
QXaAeEKxsWha4k+4Y/T3zD1laj/hF2WG2HK13LtnjzEbQ2ob/WGApwoW7NGtW+jfje6+8061
BMMtNN7+2nYGZC+rR7fuVpAWzZt5BP4DDIMhlWoyh0yj/EChZxeqjlKkUCHNmG2xPb8O2IqZ
dIlnZyKGEIAo0nLRosWKGbHfqj2YEMB5c8EH0DBnM556yEyall44abYvrlXIzEgURNrYKedB
+EFEYmo+xueDaKK3EpePVXkHXDPWTML6Gq+cQb+JpYSWjGBPFSjA4a6BGIg+vftwWwErhVcb
tB1m6wL58sVglIhW+KYfffhhjuCEppVibtUy8inrMwYiRmOAseKWcEmtWrWA9AMnJO8/0C4X
Ip+BS/Ati2tykjfZsRKtHhlqhA09/HRW8tEtaczUHiBabkO0sg1akAio0C3RQTQlAtOsRDOT
oSJGz6gSYJ5HH2vXJipbCQ4CjRlVoowrwifzAOf5+COPdOvcOQyGizXXvfc+M3t2Mg9gesEd
J5ri6FtH98NVxvg1dcswlRqd4cIgVONhHyxetCgfaXTy2DFOF04Lx1FVtvETeGUxeVRbs0oV
r4mnbu2aNdtffY3v4aww1w+At855y5zNeKRHcKBXr16DLbtA/ny1atYCwmShZmeP5EyFCtxK
bx48wDmrUhwX9sJ4DSYh8SpGpUEFig+KzYwZylYtdQbtOetaLxicivvBSbKOeAp8kvAqMATg
RQSJOHWKpZ6rmi+R6zkm8ij+BU1wJXNeE1YJbXFgQDBpYJ3u3r370qVLUjknNIM+4zcH91WC
jz+NX85JhcSqVKqs8BjAGvs7lGapUqVZ+XftysB2ZhHvboHTVN4MHhdAFsLKs4tRgLHi4Nqz
ew9NwTKUcL4DZQBVBQuPQEo3atBQnc0O7TOcjZwf0KfJUqGN9U5XADrd4yqZ3Bgtm7ckIWdn
egWxfdmyZUBPpkyZZM6jQcbhHcFJyNOdN29eJQq5ExJG5QUh3HhKleNzkqfE2+TM4OLHaSbc
JDhP4sGaQagErDaVRNG11Mm83FgujCeHM16PHqWjaoktOUxfevGFwk89ZTvUqWMnPiLeapAO
OgxZBPFQIF9e72zunLla8sMiRE68ShUqzJsXvdRkpz5s+PA5szNAIZzOMGj2TlGlxZgqufgq
la/A+5QQh57xGJcgwIqTsKMLFixQjxaAJuqWpH3r6EMPPIDhjYpqRMKAGloa/nXHHevXrder
oIGBAweWKF4c80TdZm6QOAA5fMkiG6rRI0ciUGUrLS7aAEz97re/LV+uLJFjm9S/Xz8162hx
RERQIHm0Bw0cZCsVhwedNAlPPPYYqlUxE4DOP15paiGOov268OlBg1yVaoYB++IfD/w/bOgw
/jF4zgQXpta5KuoJ42kD0wyGCnwXqk+bDY44LLFg3rzQCdfl7X//O7CBn1q2bOV2XkeRIoWB
4/bt248DKedQRDz+bhQumTFt2q233NKlSxfaKfyDMwKXbv7tb82VZRFWRl1eJ7naoXA9CICO
Pv9w880BqHR58lsyqhzPeDVr1qRu2QhZv4MONnTokJHDh9uPzZsblapE0JDQ9WrXpmpGK3GL
FlMnTwKVUBQOzYnKCeQO0QurlS9/vmLFiou7EdngQBktQBNUy6VrpiLGq1AhqJq+gkrnzZMX
TkW19IIFCgBM5H7oIVqQJRk+m/pkli3DDz34IIe4S4gaVIWRoF4QKPBkYm/k66cyhSUgiCxA
DRU2HSQxaQplUi89jnEK/rXkI7hAo6HzZXE5eB+AG9hIkPxAf0ailDRmo2F6EIoiafn4o4/x
Pnv8m37xC0IvuvXxEyJqBw8aDORx/3331YCfbtvWQz2cOzcfOgBa8WLFAn4a4yUSz1chObly
5YJxIzltPufMmQPdakkqWqQIHGmIh8J4ue6/H07aMfgIaCUtkWlEYGGIRQwf8U1hJxkdT5qM
Dx2wCVFeQGHtUe0dDI+4BoUNwDfAIC1FMFN26tdvkDfPE8xI4cEv50/OZjwY6UBePiB5ETWw
uAwcOGrkCLssaAdfMQ8oE5Cetw5WInATjIvwQRDEEUNZWOnhLQirunXrQUELlmFJGzNmTFQV
uUGDu+++O6hA9CUlvyPTYhy1ybo4bNhwberUqY2qFi9eMnDAwN59ehcrVgzFJOEFkPIQzy5n
PEiWc2AL28UQFuRDAQY7jqg/7KxOnoRTiwo4xyFnoQ2lC/W3Ugx5bCQbx40dg3UTksXqNjm+
Ghi8OAlJ4kER6M0eD60LHfAroCblmTRjtCDxdFi0cJFhQ6OtVwhTMkVMGsWLl6BtstzQZgd4
qN69WTUee/QxS4aW1i97vNB5vB7tJ6ysbqVKlbIAqWXta+/evXLnzq2ZWdKG/blkyZK0DA9I
/qsNGEYOj0JHTZ5C1I99e/hqd0fERQcvvqASPXEdxjl92nT6vP02DdPX2lHQUwb0lApqHtwr
dcN8ebJfzma8Xj17jB0zOrwnaK9Qu9yajbZodHQzWigwJ+t8zWrVAb5QFZ3Ei8EDUIt4EjmG
lxQ6oaAmqmY4s3XrKxbXcEwpgg+0ZcowK2T60yiNtosJ9YDVU958Dd2CUJIVjRo2omjZaFnR
O3ToWKhQIbApVGi9V9O4VKmS6DW6JCreesomqljRIqxEemCTJFHhpMlnazwiwyp0SyBJ+z2B
diSAzuG5Q4qHLHu8iPH2G3aFsMezKgm9o28XyC+uZy5IKv4sVbIUiZF6LVmHSZInip9iUbfO
0f7NBzbVGpekWkiaUfYE4yRfgSotYck8AH2VK1OO7AJ8hSZjLnYX4ExbNc8IrWpmPKOY+qAw
W3GaNW4irI51F9SOUs1oqWB14UKFCepXX32VZdhCCZ7qwWkxwLelS5acMSPCml6ezJY6qhzM
eKj21ddeQ0+BYmDWoxQpJ07s2LH9jTeiRADIl34Cx4iWvTZaH20zorC4CPjkKVMIIpEjYTqC
LXPH9h0Qj8G6Gc6Tb9Sz8NUL1qe/Wd6rbqNbZ35sooiUMKqQQGn16jWsKThWz4gG2jNE6MQS
ZpWvhpdCLicobzwHBuVyEQDMKoLiUGSgaY3Jeaq1Y3XJp02bTrsL9snsBBebUt8Kj+9XEl4k
m8gJC5PIJmZAV3GgGXMiJTws76idYWJn9ZMbKc4e1gVTDU1JPmahJLalCP4afzSz3oVY2PAh
vYULG6ox0DPtt6M68ps3G4ApJV1BQ4NETXowBpZbQXfhwe0bx0+YCIubOQ+bpk6dRp671/r1
68yJZchPOcF/npONKymJseL3Gn+SXVMqeDL8mqwxWX5KKCMxsaTSUyoqJfSTnbhDgo/TFBZG
kvIJYwsnU4+zf40vyoBrZHo6znVJ0ttZB5Y6pAyBlg3BmsxYlgFn0daS6T091TGiIPtjvtM8
pK7xqccZbJn5JKlskzxdWALOMXWnW0bzl0auZCfS9Jn0DKRnIEe7E876+s4qtc4io86mkATn
+RkyJEYYhjOpP1EUQuN3IqHkkosZZJo+P8QzkIP3eGd9K1QSWxf/zmHXOvrWW7bmGcn54n18
0FEDa7HCrX3+ed5bEKegv9m6MKPbAs6YPoPrwh4yoBbfifF0yJDDCmLbmJofNhmwQdrC2WVd
/sa3DzHpf7CPlrMZL2Xbdhqn//TTTwe7c8xOpzcGSWOmF5462MuQC1Azlr3Qnj2aoa9xo4YM
bsAuTI6YBO6EV4oFnJlUtGW3rl1eBLOMWSqDac/cQ+pHFgYG1WRfl+w6kjFI4yPj0OkGHywV
pO/+vs9ADma8iGdi0xk8brAQbHt1Gx/xsCFDnh78tLBxDm7cAZEo5Jm5TBuNiTt2wt17MN1e
TgXJMzmvubm279jBssdCPf+ZeTiNKRwaA8SRI5v7wWfylKmSJsGOuTDOWxzJPKZCljfH7nLo
8GEeYSbQ3Xt261b2LrbNKINDDBzzZsNcGwOMr6RMI4YNjwXv0Q8+19z7TnbpG+ZgxkOv0FLl
ypWHHfEiBw4YwIErzaOTeZ/IU7VqFeikyBfUrBlJVbx4cRlQgI/gvzZu2sixK5vlX2+9Fe+1
bNni9zf/XoIGPi7/eCCkypk4YeL9997L7ydjUpfOnSQO4Em//fbbpUtp2iTKJxkJq1P/ASuT
GdYRcJkERDxyNWrWBONgKBejoPOKFStyeERcFzOexpzCXTp37t2zl5Qt0Plc2AaZ1jk/aqyY
UxnPuNHrUwUKBlAIoAmpFXLxQ7s3b9rMDqxSpUpbt2yRlgfWkRe7dKmSXNIA7zKIyP8FMMX3
ChIpb7E2OpHoVnJleaxs88TCgXqSk9WqVMVpoDAEY+sYnl+2dGnJ0oOWSAWV/8cBNNOi2Fk8
Y9p0OZdopFHeruPHuKrlUwqN9QBXEVUFOHUK0AMUAwBaqiwyMGwm05+PzgzkVMYLMoQjWDiJ
FNHgVLBUgb4BxKLceBE8ql4E4GzcGD6LqQOhO1mhbNk5c2djHjpnzHivUB2rx4xH3EmJi9Pk
gcM2sqqCwsAHSwoowSOAYuu4BwBrGXXCvcSqdI0DYVq3ar1s6VLgKeBdQa7u2L5dlBxaQthp
U6P86j4ghe3btAnHVocA/JXzC8Y6zXgfHZYLT5qDGS+ghwkxsEOSqnSJkiG3PugwQL0DYGWM
B7m7dPESMqpl8xYeWA5Glkk4SRfWrVP3tde22+5RQbUXgikAh2pKTI0fO44SmPeJJwCa2rRt
K/BHviqRYJrhyZUrngvTh/F0G/FzhQoyTwtKCGhMEq91XIRAHjuBambZjhRqXjhpcN9rKSWZ
A7E/bLBpxkszHvDTtddee8Wtt96KQMPyHD6X1T7EYEDpJaWVLBkKmdTq2LEjbbN71279+/WX
MNOAYflBpaLkykuXCleV6hz1V6lUUeQBqcX0Iic09K3AH8hJqGKX4C6cIMEjeKRiA5C44FGY
Z+zo0WvWrpXpmX1EgmqAr9mz59jgMZPA4LvR3XfdBbIklTpjZteu3aZOnRKCaOSulKFdRoOn
nx7CCkqiijETmtCrZ69JEybojVjmV0gzXprxcgbjeU+AjIIjxYABXkbrwslTjPhEDd8A6HME
vNyxg1gTSCLOUkESRkvbQtZOqHzmRJdjV1vEkLpD5E6IA1Aoz0n7QDGjYbkRJKql9ObYLAKI
viqkJToOFWrs0BYtWoh7FZojHl24YOFCv8aZRU6wrEBy+mzdGoEYiTtgaE5C5wUZgTtu377D
lvKjRnbp583BqqaXl0jj+PgMGGL4NXm8VIdbuCq5PGkTqCGLkE8AK2d12WVpn3ptfIvTSbJS
73jmsC8vVSLNEu/PDORsxnt/5ih9l/QMXPIZyMGMd56wzOxTFm9YMyK7L4eNaxCA7wRAy/KY
voZ3ltRDPjtNnAk6Df0HFeCsKNN33WSee5CXnC4/9B3mYMbzbpYtWy6vUcI8iQUoOcj+/jQW
GGoPFkfuvR6Fk3+gL9l4hNvZN77TKGBKhYTbpkaPGYO2wWVgYqK0lpkg7ezP66HUalQ55OWX
N6uywJcYb1Zfj/JhZkOZAuLYKvOvvNMy5LxtsL1uFi39A525nH3zHMx4iKBZ0yZRfoTMj/JU
IcW/g7h2+elPwJSFp4XknD51GmMMt4GkfdH5zEC7ZDoyY/ZOB3R7zxmiJlPmRMaSk6nZrDM2
mUnLhEwDh5y5zTu9I+W3UEU5yOHTci8TZcrkw7UYJeTL3JfCo6m5lfp0MppED5gZER9+4tnv
3r0HV6dEZkp/GKp8M+r1hV8Dj4Vj7scK5cpivDNHmHoHNdNHuC87kDXLD2pNhoLVOZv8P7jR
52zGU3VNcishycePvQ2DIv+U5Hxy4xQvXkzCPLZEpsXVa9ZESTgkxoyqdUcVt9XiYsEXcCAB
GQKKQJfHjqmJB4epJDrz4yG5igUl7NoVYTJPnFAfWGQ6OSFHy062yrhouISqfnIlAlabJi5D
o0TOZoPRj58UFla7izMd54SMmu7omKFVOjC5H6XE4pZg3pT1QGIyFxJlADeJjUeGwlWrVovp
VoKPTz+OSY9YRfrAkOCAT9+v7iKdCd8GDKrjUAuJKVU6CZnzpE6RlcSA9+7Z7Xk5UdTc4TUJ
1SfNlXEaAyeK3oTnO3mQBfiNndJym65169dp76TBw52q1KM3hm+w1aefHhzVOr8Myhp/cOxz
4XfO2YwHrSIBifLWXTt3ARC55Za/cLUpaHjLLbeEBGFAm9Wj/MT1uRMgUVCpnLZ8dzhBklaV
2WSMlRcE/cFh+lUmr/vuuUeZO7Qr8xxwCWkg52yUDnDrVkWbpd9CjqNHjxoSZ/gy8T169ChX
tpwkKMDZfHTWAv4JiLCyZctyl1euVNG9otSA+/Yjbn6IRQsXkFdr1z7fpGkT2VflIDEGGACZ
nsmoqHH8oXzCl0n1JSFn+bJlIcsgUSdMGO8nydQsHIBplStXIb2hdv7yl7/ECQ5fhBZQh10e
Md6RO+64Q+Yy2ZnuvfdeTPXs0iUywEoPY7TyC4HLSFgGOOrCjRvWgwpUr1ZdAb1Vq1YpQKmu
rdybUVKTOnXAXC09JnbihPGm4p577sH55kHVctrs5bBJvnDy/+CufEfGy58/P8JN1TYutyk2
NimGZJImpmhTXG1y/vB3m0y5vgkjnAZvqZmVfuHCRSFXCroPBcf9BNglozMyIhlyP/jgnNmz
nh48qG3r1nLOyeEhPzSwGFHTplWrXj16Eq0YMs9jjxFTZGZAqBBxvPa41LF0Q/37RlXCBeMp
m4r96GalS5biMDR1SjHjH7FIdlM6DBMLU0ogG4l8hFguPEX4SUag4XFwEymsN6kyn3/hBWxg
n+avx1RqPGR0pWRKOEsiEbkyqamjkC9PHntXEDlZUlaufE6dR8147WU3mjZlqjLikXq5b7+R
h6TLBw7sl2aTDJ8xY6YM0PJhmgQ7OreQH0ViMnVhZROcOWM6AFDPnlFv1jWLVFrVvGDOzc54
NKCbbrrpiqpVqwL+XuaMR7ysWPEcCIsCvDRJ9U0RLoUQWIwWJKnrvLlzPYJ4BVlxwrMIsSPi
qIING9SXT5LWhIvgXYQSYUiJruCtmzRuBEs5eOBAVYXJrihT6vLl7dq0AcvEWoIhZJgO2fIk
DnJ56Pm1ba/Cdnbu2Im0UcnZmTgZbv0AZONFV80U89t0yfnpDFEmJ6SD9u3bcf1TFKFqMG3o
DbmHxKwYT0QFvVcaNfEWBq9SsfNMMmQUw4m9Wf26Uf4yCq+MmrVq1yarqakGuWH9Biq3NOna
k2x8/ThfAV05wmTgVrs43ItOThrj/HnPPEMaW18sBDLf1qsjT/spD+i83mbNmCFTU7euUW8k
/JLFZ2S/vmAS/GhemJ3xFLumpFwhg2/RokUvc8aT2hUpSAlesVx52zDYMcv2kbeOUNuwnxgc
ATgegUBApgwDTtLTGFRgo6mp2M+mS+o7mqS48pLFi8u3aeNmyS+YL7/U1IhVSnBKJjYr/ORT
UgOKbn/iscfJKM1syeS9kkIzlCUI9nr64fBhQ/2VcJrEK1tabfG3jTBUAnCJVJz6sUwApilR
4BKiiXFFmrAKRNCu3YapK3FG3bp09atr6caGR+IRxX169ZZkNrw2m668efJs2fKyXK6ygHk0
WDn1ekg8GjV0uASb4pjIbUH0+EfPAZ0zsP8AS0OZ0qVkE/NVOQcrl9mZPWumNcjKMmTQYJEZ
AjU8ZqMG9a1fJJ7UzoI8BF65pEXLlhL+Ofhoss3FP3V2xgscd0VAjl3mjCcv+nPLlrEcEHFY
TpSd1OLibiz79jlq7lj7baLwGIrv1bM3/VBouaXdvmh4DKSOFu+2bUNx+qqVq7ZqFSGbyTGp
pnUrSK9gwYKRyDp1Cn+iYDOO1iWTtSHs3iNKV96vbx85p7Foz+7dataoKREtD4fErOqJlyhW
nJa4bes2iE28JOxdks98efJaDkaNGvXE4483btzIMCSEJPEwHouFyKahQ4fRgXfu3GV7ZgXB
xpLwYlTWlyaNGotdAlUjOYkgkRlgop6XJJRJmtosV6xtWMECBUl+T6rAyNKlz9oysP2SY0aL
c+gyZUqXkb1X2maZKsUZCi+kJ9u7UoNpBzQFYVDuiJNZj9q0aknM6g3oVLSUxzd7xi+TvI3i
5bYBuXiWeH96yM54xB2hd4WXdPPNN1svE9673KYYKdOR6E5WcTF1NnUkwPoNG3x1nkyzq0G1
dkchpSSDJFMe6cQJwOgXWeTi2CI2TFXv4t4OImL9RKa/3XvYF0kbPUdugxMnXCjVioOouDYi
PfLWGzsjNKb5YZthtECpLIohyTnepvup0SF1vN5wkZa4RVJkmzSWHssERlq1ehWZaTCYnPSL
IKbHjslFaYemE4MJedfd2rVUSrfWf1zL6Di9kYWGePdePDg902aS0SXq8ODBuKzfgWich9/y
q0+cJ+aE/wkLJMPDa2Ud4WkwFXL1unVczTxqSWzqwSDdSD+GZ0rDjLH6CunwK65Oavq9P8T6
YbpLFsbzpq666ip/I8aTzJxp7rJlvGBbT/xRiVcqOWC0nD49Y2uXnAzaUXioxHCf5WSYlHM3
S9pkX7pwvs1bq1atK1aoGDaZqb2lKhFZ5jal2RkJocP55Eapw07tOXUkyeSkOvdSM9CkdpLl
eVMHnDEJmR7CZE6yDObDxBLvz7NkIZuE1yLGw3+0TRj/8CYuN4l37gkK/rdIvr2/nyj38/Hj
FHVxQ2SCeSNC3wXe9f6OMH23y2EGUhkvldEixvMRrHnfffflUMYLw34nDOR/a/ZjKGQiyoKa
+n6P4b/1bOl+L9kMpDJeqmqZwXgIiKWFvSXHSbxLNkPpjtIz8F+YgYTxmFEEnYeqmj6nGc8p
9pYs0ehn3aikT6ZnID0D72kGbEmYMJPd3BmM5wvrlp8lin1PnaYbp2cgPQPnmAGyDlvhvdQ2
pyVeOEvuPfLII1xAmDA9m+kZSM/AxcwAbrKvo2GmyrqsqmbqDYDI2Dldk2a/i5n39LUf5RmA
Z7jxxhs56pJ93bkkXvIblnMNZx9rJ6OLvR8P7Ed5HtPPnp6Bc89A7FuabadGZ7zyyiuFH2RR
L8+L8ZJGPA0MnsQl9lXqPv1Jz0B6Bs46A5REbILr8N5ZpVwq4/1/9BckHFTJneYAAAAASUVO
RK5CYII=
--------------030201090500060601040706--

--------------070808000403080400020901--

From schmitt@ifi.uzh.ch  Thu Oct 10 06:27:18 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F23A21F9A10 for ; Thu, 10 Oct 2013 06:27:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.977
X-Spam-Level: 
X-Spam-Status: No, score=-4.977 tagged_above=-999 required=5 tests=[AWL=-0.840, BAYES_00=-2.599, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cW5xWth0-N8b for ; Thu, 10 Oct 2013 06:27:07 -0700 (PDT)
Received: from ladislav.ifi.uzh.ch (ladislav.ifi.uzh.ch [130.60.156.19]) by ietfa.amsl.com (Postfix) with ESMTP id 381F221F938E for ; Thu, 10 Oct 2013 06:27:07 -0700 (PDT)
Received: from authenticated sender schmitt by ladislav.ifi.uzh.ch (postfix) with ESMTPSA id SA; <36407760B8>
Message-ID: <5256AB28.7010502@ifi.uzh.ch>
Date: Thu, 10 Oct 2013 15:27:04 +0200
From: "Dr. Corinna Schmitt" 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: core@ietf.org
Content-Type: multipart/alternative; boundary="------------090205000708090207080204"
X-Virus-Scanned: clamav-milter 0.97.6 at ladislav
X-Virus-Status: Clean
Subject: [core] Updated draft "DTLS-based Security with two-way Authentication for IoT"
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Oct 2013 13:27:18 -0000

This is a multi-part message in MIME format.
--------------090205000708090207080204
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Dear CoRE-Members and interest parties for AA,

University of Zurich updated the draft " DTLS-based Security with 
two-way Authentication for IoT" including a use-case decription and some 
hardware requirements. The input is based on ongoing work at University 
of Zurich and received feedback from AA-members in Berlin at IETF 87.

The draft is available under: 
http://www.ietf.org/id/draft-schmitt-two-way-authentication-for-iot-01.txt

We are looking forward for upcoming discussions and feedback at IETF 88 
in Vancouver.

Regards,
Corinna

-- 

--------------090205000708090207080204
Content-Type: multipart/related;
 boundary="------------010205090606080907080107"


--------------010205090606080907080107
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit


  

    
  
  
    Dear CoRE-Members and interest parties for AA,

    

    University of Zurich updated the draft "
    
    DTLS-based Security with two-way Authentication for IoT" including a
    use-case decription and some hardware requirements. The input is
    based on ongoing work at University of Zurich and received feedback
    from AA-members in Berlin at IETF 87.

    

    The draft is available under:
http://www.ietf.org/id/draft-schmitt-two-way-authentication-for-iot-01.txt

    

    We are looking forward for upcoming discussions and feedback at IETF
    88 in Vancouver.

    

    Regards,

    Corinna 

    

    
-- 

      

  


--------------010205090606080907080107
Content-Type: image/png; x-mac-type="0"; x-mac-creator="0";
 name="visitenkarte.png"
Content-Transfer-Encoding: base64
Content-ID: 
Content-Disposition: inline;
 filename="visitenkarte.png"

iVBORw0KGgoAAAANSUhEUgAAASgAAACgCAIAAAAw8WZPAAAAAXNSR0IArs4c6QAAAARnQU1B
AACxjwv8YQUAAAAgY0hSTQAAeiYAAICEAAD6AAAAgOgAAHUwAADqYAAAOpgAABdwnLpRPAAA
buNJREFUeF7t3Qe8FtXRP3CT901i2htTTVeTGE035Z+YZkxijFFjQcVKVXrvvffee6/Se+9I
R0CahSqCgtJBQKTl/9099y4P9yIiEOXq83zwus8+Z8+ePTtzZs7Mb2Y+9p///OeKd/uMGTNm
5cqVWq1atWr//v3v1jz9e3oGPnIzcOWVV/7ud7/z2DfeeON9993n67tMAcZ7p8/s2bMfeeSR
q666Skd14s/o0aOdTH/SM5CegSwzMHny5MAjWAbXYRnMcg7muuKsvz333HOuvPXWW59++ul9
+/ad4/r0T+kZSM9A9hnAdTjopptuwp9nnZ+zMB5mu/nmm8/Nr+m5Ts9AegbedQYIMNKLGMze
MivjVa1alax866233rXTdIP0DKRn4HxmIOifWXjqDMbDdRqdOnXqZPqTnoH0DFyKGcBNmLNP
nz40z1QuPc14NEx86bc0412KCU/3kZ6BaAYC4/k0adKEYEt4L4PxKKP2dUEaphkvTTLpGbhU
M5AwHs4i2Ii3wHsZjJdq/bxgxsvk7XPovWkl9lK90HQ/OWMGUhlvx44d1157bRBvEeNxQdxx
xx0Ju7wnxjtx4sTJEyeSa/fs2b1mzZrp06YPHzp02JAh/jmYOmUyifrGG28kzU6eyBmzlh5l
egYucgZSGQ/9ly1btk2bNhmMh+vw3oUxXrhq586dkyZNatyoYY1q1apXq1anVq0G9eo1rFu3
ob/16tWrU6d61arVq1WvX6/+6FGjt219NVx1kY+Uvjw9A5f/DGRhvJdffpnQixiP4INNSbV1
no/EI+hsBl2/ffuOnj17li9XrmrlKhivaZMmXTt3fnrwoKlTpsyeNXvO7NnTp00bNnRoj27d
WjRv3rhhw+pVq5cuWbpTx46bN28K7KerSGymP+kZ+DDOQBbGQ/CMKYsWLboiMWa+J4kXGGb0
qFHlypatVrVqy+YtunbpsnDBgtkzZo4bOzb7Jm/evGecX75sWa+ePTWuXatW2dKl+/fre/jw
YY2PH08z3oeR6NLPlGLVTJgiIMuuCP9LZZVzSzwsovGunTsbN2pUsUKF5k2bDujf74Xnn8c8
zg8cMLBCuXKv79hhzhM5dvTo2y2bN2/YoMHxY8e12bhhw/BhQ1s0bVa1cuWaNWps2rgxrXam
SfTDOgPZJV5Ak12RP39+3r3zZzwtX968mW5Zr27dNq3bLFiwYPOmTXv37Hb+hRdeaFCvfptW
rVu1aJnwkoO5s+c4o/3gQQN9XfbssmeXLiX9Onbo0KhRw9IlSzr+b8i9YPi55IbU49aY4yfi
5enSKclRT8czPD5pj86HiAuzMx49k7Z5RRbLCgY4h8Tz6ytbtpQpXTrs5ba8vMWZwQMHkn57
du/R47/vvPPfd92FLZ0/cuTI4UOHHIwaOfLef//7zjvuaNWyha99+vRt3qz59te2b33llT69
e7do1qxYkaKB984x4cnSENqkPs/5X3VJXijGyzKYLF8v6C6RvvD228defOGFtWvWHHrzzfPZ
aV/QjdIXva8zkJ3xgn3lCiDOLADqs77y2JryH5EKNnXNmzXr3Knj/v37aJj169WbMX0GY+bK
5cunTJ78VMGCRQsXLl60qM3bcyuemzljhqt6dutWMH/+J/PntxvkynDJvr372rZp88zcuW+8
/kbMe81Lliix5eWXw9Yxu63l2LHjSxYvNs6DBw8ans+xt48tXrSI8ebNN98860Rqc/To0WZN
m+Z54vF169ZdQjrW1fLlyx95ODeJ/fbbb7u7UZHhe/fuveC7RPrC88/f8+9/f+H//u/zn//c
nDlz0ur3+8of/7WbXSzjRULm5Ek806RxEzZJTNK5c+eXXnypdMlSFM6li5doMGHcuP59+w3q
379mjeq7du3EVBs2rHfjwQMGdOvSuX/v3jWrVX/z4MG9+/Y9u2RJm9athw8btmDe/Igze/Zs
3bKVHeORw4dTN4cZwu3kyTffPPSrm276whe+sHbN2iBe9u8/8LOf/vSLX/wipgpSOhB9+DU8
LSfHN77+dfGIvXr0SG2TCMxwSTI1CdtEfcVdht6yCFhnmjZpqtsfXn/9gQMHjr711r3/vucr
X/7y2rXR2MJVZ3QV95X6ZrPcMQy+YIEC+rzt73+rVq3qhg0bLoyHQ1cXdu1/jfbesePsmsI7
jTx5rZdwkBc8S8mFyajO0VXyrpOHfW8Sz2Vjx4whslq3arV169Y1q1a3atmyc8eOc2bNInwi
Ujt5EkNWrVK1ZvXq+fPmxZlUphnTp1PMGjdswOJSrXLlgvny7969J2KJN97ApdOnTp01c2bb
1m22b9/eoV077r4e3bpHhH6md+HUyVOHDh36xc9//vnPfU6fmYy3/yc//jH58NJLEeNl/3jg
48feHjt6NA5n7EkaBHF61kvCSfvC1F+1T7ZeCR/a5TZv3oKEj9ofP/HTn/7ks5/97OZYYqcS
U1ATMroNojzlTJYx/PmPf/z85z+/efPm6PwF4dSzdHjBhBUT9wljiN7FRXzi53jHLXagyH37
9x858lbGHTMfIPWeYcYgLvbu3Xfs2LGLGE7GpfFDnX6lnvQ99RnGGAZ//Ngxo0rOvJPmleW9
nC/jRZR36hQzZrkyZVq1aLFkyeIN69e3b9vu9dffGDVixBtv7Iyf5MT+ffuKFylSqkSJ8mXL
3H7bbfx4M6ZNw0779u3Ndd99LCj8B84vmB+JuPBZtHDRYw8/XKRQ4SOHDlO0WjVv7vL16zdk
ed/uTnH91S9vuuqqLwSp4rP/wIGf/exnX/rSlzZu2Lh39+4qVau0bNmCCM11/3333ntP/379
XMU52aN791q1a7GjEstFixV1d+dPHD9OSyxUqBDLELZp367dnf/61x3//CdPo02pBtOmTS1W
tOjAAf1LlSzlV2cGDhjwQK5ct/7lFiYi82u0NarXGPL009aXEiVKkKsUxNy5czdu0mTcuHGF
Cxfu0rmLnr2fiRMnPvXUU8xXpihsDnfseB2Q4K4777rvnnt5Vg4dPvzKK6+UKF7i29/+1he+
8H+PPfaYTa+Rv1e20X79uvXlypUrUqRI2TJlFi9afDFsE+xSR986+p6IMkvjt98+ijTfiRxx
Ea/Sr3716+B/Mn6zWqVKlddefTXLuvP6668/kvvhv9zyl02bIt/vxQzJteSEV/PSSy8VLVLE
HSN6OG/W03j1qlVVqlTdtXMX/rnrzjvZJ+2ngEN2vrHzrK/swiVeWHL43+rWrt2zRw/W/0kT
Jgzo15/EM61+Oha74Xbv2tm+bZsmjRsVL1KU0Js0aSK6rFK58p7du/kMKlUoX71K5SqVKs5N
2b34SbfPPbdy8qRJWzZvfnrQ4LatW9uVvSfG44hH/V/60hc/9alPfe5zn/vaV79KYSMJly5Z
ao/32//3/3y1GwQMd/DUk0/pnF3nq1/56qc++ckVK1bQb50nTn/60586sINFA40bN3aMl/wl
5Ht07/Hxj30Md/36l78qXqyYHkYMH+Gnf99993MrVlxzzTWf/cxn3Vr7W//ylzGjR/vp61//
OsuTSb/9H7f72r170HVPbtu69ZY//9mZL171RQNwULRoUUP97ne+S2aSeKT67f/4x6HDkVHq
PVGY9rNmzvrSF7/YpHHjMqVKXfPda6ZNm5Zlrc0i6rN8zUIiDerXDyr6WT/n1hpcsn79+rxP
PHFg//7kQbL0w/b2veuus0JFciymMWTg8VetXJml5cL5C0y+peTc488+zuxEbzdeIF++l154
ccf2HTVq1CRCAg4k++esklCzMaNGf/5zn31126vWi+98+9tbt24bOWK4YdsdnPWVXTjjedp9
e/dWrVyJL47DAJXXrlmT6HtlyytBbQsikfb49KBBxYoUQXwMJ+PHje3SqXPRwkU2b9zUskWL
B+6/P+/jjzdt1IhBJfVNWOybN23WsWOHl1560Z6Q2aZyxYpbtkTG0sTEgmAPHz70q1/+8qpo
j5epah7YHyQe3WzrK1u9wv/5n//B2mYk1/33h30dLedvf/3rlZ/6FPfFiuXLceP1P/gByCjx
9bGPfezRRx5hSkXuv/rVr55fu3b5s8u+/73vfeMb39i9a1e7tm01+OY3vwlzQw0mD3XYrGmz
iHliNZXW/Yn//d+HHngAb6Own//sZ/afkDomgXB2U+179+q9Yd26r3z5K9ddey0pF15tgwYN
/PTYo4/ywcycMfNb3/qmUS1auNBk/u63/w83mh/KxQVAeXTuWur3ju2vOc6fL999993rYNu2
baR0o0aNyA2moA4dOljsKlWsNH78eL+aPQxWoWLFCRMmWEb7+/Tt1759+759+qD13/z611On
Th0zekzXLl3r16/ft29feweT7EldK+1VyxYtrarI9403XgdB7Na1K5EFR/HG66+b3s9+5jPl
ypazGw+i4PChw927dStXrvzokSMJ/0YNG331K1955OFHwoZWhzOmT0PKq1etHjpsWLeu3WrX
qt2nV6+XN7/M4/W1r32NimFuF8xfULlSJauz9/j2sbcZGgy1d+/e8+fPN+zWrVozmLOu165d
u3//fnQMQrJevegBJ0+afOjNQ7ZCn/70p5944gnaVvfu3V/dts19bRkqVKjYuWMncqxbNMJy
NlCJjhxeXLJDmThhwnXXXkOhe+CBB1CLm9Kzvvud79h9XGLGi5aiyZOrVanct3dvE2pZmj9v
Xs/uPRgVkiXZxBFfdWvXKl2iBN4rWCA/bHTtGjWeeOzxhfPnFy1cqFTxElTNxx99ZN68eanj
8wLwkvfXrk1b74+QbNywkYmM22RoAIHxfnnTTV+86iq6QZiIAwcO/uynP2Nc2bRxE7fEtddc
861vfSvMY4Xy5RE3kJq3/feY8RZRKU+cuOOfd2AnXPf44499/OMfR08jRowgJ6+++ms/+P73
se6nr7ySyFm/bl37du31QNsM96pZvYavhEm+vHkxcMJ4D+bK5cEt2L/+1a8w3sYYCeDTqVMn
7b1dmqQDil+w1Wh5+23/+N///d+pk6eElsyYH7viiqcHD3Z8y5//5BZWorO+v3eVfq7CeD/+
0Y3r173k2GMa1fbXXnvwgQdKly6NDRhvmIK+fvXX/3LLn8uXL2/GVj73HDpmMKtUsSLSIf//
9te/0R2KFyuKmH584423/f3v3pdrv//97wPhMiA98fjjjzz88E0///mePXtoB48/9pjO/3n7
7XT4z332s3nz5OFM+v3NN1tWSpUs8fWvX61zQsbg0bHjm37xi2rVql1//fVDhwxF93g7f778
mD+T8aYbxuqVq+jhN97ww6pVqnztq18Z0H+A4V199dWYbf78BT/+0Y95s/7+178ZCRv7d77z
bbxqOaMrff6zn9X5jTfeYCbDJYTkvGeeiVaW+Hk5kO1Hrv7a14x85IgRX/7SlxYvXITrvPpy
5cv36dW7Vo2aP/3xT9q2aQvnGI04/jAH7tu7J1CjiaXu6Wr2rJkF8hf49je/2aNHjxGB8V6+
1IxnUlq2bNmsSZNpU6fOnjWrQL78hZ58avOm6DanF+Z4E2jBo4K21rhp0+FDhloL8z6RZ+6c
udAtlhOYsjq1a82de4ahXCe4ZdCAAVga3VAz3Kh+3bpvHz29u4j2eIcOeWfUuUQPsdx+77rv
mcRXXtmC8a757ncxD1+iDpECcqcVZzDelVdivIgfOnZ03j7zuuuuu/GHN9iU2gqSk7RBK6tF
vXevXkOGDLEussdoSVC4yt2ZdpiUCEYnTTrl3rJH4sWM58W8GUnjq64KyoYP6f31q6/+7ne/
S9H9zGc+E7TrsOdElJ/8xCdmTJseWt59190f//jHRg4fbtfxpz/+0TpCfl4s470UMR440c2/
+x3z1be+8Y3q1asRgN/51rc2rN/wk5/8JISE/b9f/waxejSbAjveb3/725jtnnvuKVuGsh19
/n3nXcC3DpB4sVjBxsl2sLSeG274oZf1oxtvLFKoEBFHsg0aOJA2sW7dehTyg+99nwCc/8w8
rLt7d4SsoBQdPHDA5W7kq/UrX958NpA//clPpkyaFJ7XX+IUBa9ZvcpiUalSJWd+8Yufe4/0
+R//6Edert3NH3//B+fnzpn9/eu+x8LHrNWhfdRnty5db/7dzQ6KFStaqlQpBz/76U+s4wcP
HJw0cSK59K1vftMBU/uNN9yw6rmVa9aspoksXby4QH6mwLzhkd3rB9ddZ80KLOeVEQx5Hn+c
HiHsJrTBeFh9x47t48aOY2nXDDE4c4kZz51wfO1aNQkBhIXErZED+/c/cvjIGVvJmPEG9OvH
X3fLH/8oIqFVq1b0GS9m5PARsNF33XFH7vvvb1Cv7jPPnFY1g5pK139m9pxXX3112bPP2gKx
x9SqWdNXUiJZ5smKe/59D7q3CmK5I2+9xQNBdPzpD384fPgI1RTjURR37dplwKVLl4kYr3v3
LIxHInmvn/zkJzEbQ5GWtsX/8z8f/8Pv/0DHCNO6d89ef1u1aqkHARaBJmgsDvCbd+a8NXLK
pMmB8fhYvFpbxM9+9jMzZ8586+hRQ/VQeZ54gnS1M7zlT382gYm1wDvWAxsS4TNr1syvfvWr
FNpNmzYee/voJWG8SNWMTbhUuHz58nF+WpuEokTaY9++r732Ggq2uGjw29/8Bh0XLlS40FOF
xo8bT6ZhvHvvucci69djb79929/+1qhBzHiPPVayZElbod/+9rd0H4IRw8yZNfuGH/7Q47Rr
165bt+5Urx9eHzEeje5HN9zw+o7tkyZOuuGH16OKTMY7aHnq1DFikvzYLm9eKr3BkDxZGG/t
mtUYj2LpjtScXj17zJ8/z8xDbjA7sf1qz8/pdbNzSOM1NrbNWDdN4FtH3ipSuIi1wBnXDh40
GF8xoowbN55YmzB+PDObBZqoF7x23XXXLlm0mJvXJ7x9HwqdJZ5QDZYwBGrPXLBgweBAThiP
Yd80/uJnP7eg6Pa/wnicdZUqVOzfty/RRJR5+LlxxrIzlJ9Tp6KtUes2jz/yCFNPoSefZLKz
DbUXomHmfeLx+++55+EHHyhVongWVRNOSle8eeXLlitbqvTLmzaNGDacO962J7lFsO7QDEkP
VGtl/fGPf+yAAAxKmhWBpkcR4rjz9amnCvm1U4cOGA95OZ4XbywjGnr8CV/pmfNj/yEevuvO
aP/2zW9886+33oqSbM8MqWmTyLjCrBKuMvV/+P3v//ynPzn585/93F2gwx3f8c/bI9Pf0bf/
cdttvtqxMI1SuV1Cif30p690I8SdPIiDCRMm2ohrHGm2n/50tHVsEhmT7F5wL15lbcs6t++q
ZcYNXEXaXPWF/6tRowat8qc/+TGf/ltHjtx9513snLiOZ4V8u+GGG/51xx3aWIOsoZ733nvv
bdSwodEOHjTI17qxnCeBWYft8ZYsWfLQgw8SmJw6P/zh9XCGzlAR1730Em7MlStXv379vYXF
ixfT3J5f+/zY0WO+8bWrX3t1m/0IzblunXp8sJH0OHnKevrLm36h/x98/3vDhgy1xuknvMEw
/kzjynN01zKly7iEUIpcVnNm2w6w6onq5DtlD/vHP/7x8MMP79u3n6pJrLmWfmg5sI1kFi5e
vDgWcS0VhsXBIBs2aGjHMWrkKHa1a7/73WJFi8nR/OUvfXHJokVI9Jvf+EaFCuXJTLLOpvHv
f/ubBciON4iWQAPJMaqmVFvr+/Xrd813vst6BJjlzMZNZ4ccX6BxxS3ZAJh9Md7G9etNk72s
dTSb5fTU3j17atWoQdvs368/QUdjHD923LgxY7t37fbEo4/16tnLDpjUpnNnIayYc9bPmTnr
1a1bEcrkiROrValii5jaLIwe7z36yKM0qN/f/DtK7MQJE6MZOXmS6YLW7n1gJC3tCiypqJCk
kujCcsXOHhlFTv0H0gUNiRikT4Y+Ga8xmLn+/e9+h23sNo8fP0am5c2Td9SokWHSeRSQoAW1
RPHiwYPPKmMppQVYF/XDfkhJ++Mf/mBxpXlqsPWVLV48gYYWkwcJkpPZ84FcD+jt3nvu7dun
L/Jykt7VsH59BEFeZZvb8+O8k6dsd2vWqFmmTBnvi0IY6AWJoHVCb8yoUXjg5z//ueelyJFv
brRi+YqKFSsxhjVv3gwcp1evXjNmzAz384y2RowrWo6MzSFt2rTlzrELbdq0KdXLbNNrSpcq
jb6Z3CxPFDANoAvsAL3KLp0716hZ004s2SzR9umBQ4cMiZTPgwebNWuGl8Lz+mvRsR/zRiwT
4ydMwPyWLZYSYkqfNiMeiOOX8QPgnvT2pnhTV65cpQOLSPv2Hdgdhg0bzt5o9SS6Vz5na7Ky
YsWK7dq2a9q0mS+nTp4YNmxo5cqV586d26RJ02ARwUulSpVs2aI5FjJ7xhC2nYnCmbxBJ9nh
2Jm4o5cvX4ZaQD4YKfiHdu7cddYXd+GMN2rkCM9pO2TG+/XpQzcI+JIsH9qzrVqgVK+qZ4/u
S5csYSgfO2Yswg3nWVCQfhbGMzKq4+yZszp16EiVJbgtwEwj2ZuFTuyUCJlwHCGLjx9PlqXw
Nfzk48WEg6AuZsdYnnFh7BqJrzrt9c6Yej6tlMspk4Fb4saZ3Ub++miNDOexPVMNs0TcQ4aV
KBpqpgNdJ8k4Q4vw9UK57mTq06VOTnIXB5Re3kJrfGaD03OV2syDhDiSM06mTGY0pbGqknxQ
aXwy4yniB8qYRi/Fw3oXqSSYiiXIJKSM9kmz5InCGV1mecbk/SYHJzIHGRxd2T/ZZyk1f0Jq
e2/8bAve6YfKmMNMensnxPyFM97oUSObNGw4aOCANatXYyFCL9ipsjLe668PHjjA4rRg3ryh
Q4dWLF/e1q5e3ToWcraKFcuWPb92DRGRnfEisjtxgnmDJ501zBJr09+hfcSrZ9wiepWR3yKF
QDOwIGG9DCQb+zair5nH0fnIG5wZphS3cybTaXoiK946/JTKAKk3DbfMaKCnTIdK8s7sdkDG
f/Ob3/zPxz8ePGkp98q4NpXlkmdMHuFs7/t8zp3hBs4YZ+QGP33ezpxxclkmHj1pk9F7ZsvM
Z8zwFWUAieKOwin/S+YhzHP0Y+bf1DPJcWr7cDJz6s71aPFbzHiEjDd4+sKMyYxXtvCM8WsO
RynPknqD0/fNPJs8Vvxc5+tKT52qcNMwK9kf5mIYb0STBg1sABg/+vbuQ1PasX171oX51Enb
6B7du61du2bJ4iV0D1av4sWK534oN92M089+w1aYNynVgR5GqSsrIhvM1MmT165ebXfets3Z
GO98aO+cbc4hTM4qbcKUZZ+45GTWu8XtOSHs3Ig7bqjwdBc98EvWQdhRx+p5+vM+zcDFMN4o
sqtf374vb9o8fOgwaiToY3Z6YlRo3KD++LFjJk2YaBNFarEWCH+gNDLiUbvpkFx8z8zNsseL
hJgOqZqCD2wbJowf53bAIqkSL2gyWT6xKHv3JSqs08m1Z7kkFqRZnyhDrGUsDUGlJCoTXora
x4tw6gt0jl4wfuzYZUuXXjzW8ZKTRliUz2fSLvmtP7IdXjjjzZo1i0fO7o6Jn1zCVCReNhTv
qZ2vvzH06aeZJWV5GD9u3HPPrWCoFezHz8bzvmTxInFmAVR9pg4ZEf3uXbsF+DVt3Hj5smep
alUqVZaeLGmGUN566whQKLACRJx/0f9ff8NW0xJ+Pm/Utg0yo0XzFnrI3p6tr3jRYpCWYJ8Z
N7UTO3Vq5vTpDRvU50WwdWbCejh3boYZXgoGJCsFW47gpuyyI3V1OJ+xpdt8uGfgwhnvpRdf
tGGjZLKckntVK1WGLcimap7avXNnm9atGJHZLZk07QnFH4wYPnzqlEnMaM/MmQPCUrlChSyq
Jqai+SyYP09L1iHBdazD3AlgRwnjOXj22We5azm+v/+979/wwxt++hPW8p+wPmfdB57tHWoD
z816TgPs0L79GZfEu8ED+w/w7TA3c9QGPSwe1X969+x19113Pf/883//298pzLkffIiVuU2r
Vjf/9ndQS4zXwXvx4aab9NNd5AxcIOPZtRAIsGAd2rWN4NETJ/bt1WvksGEg3ll4jx8PQgUQ
wVatXp3anTq0nzVj+qwZM8SniwmaOmnStMmTy5YqlYrVjLekkcmLnXfixEmECfNuuzZtuCX4
W1IZD1CLP5S/FSry+ut/wOuNi8ZPiNCG4RPUp3DM4JYchzMEJgt7rvtzrVq5KiiHqXKJD5SR
nRvQEpN6vl+fvgBQrOr/uO0f856ZB3ixcOHC3j17Yjnu6V/8/BfBX3+RLyZ9+Yd7Bi6Q8QKN
Mkvy0tDWGC25E3r16EmyZaE5+h/n2/wFCwYNGkQWsX/CxYEOtG/Tlpth3JgxrNhdO3cJ+Npk
rh2/+MKLTRs3nT59OifysqXPRpCxevXejhDrGa0i5nz7bcIQcAyUjDMN1/3zn/90hhWUX5GM
1fTwkUP82pHR9QDZvA+wYMaM6Ry7RiKGCMNjpNdf3xFQzgsWzHeeXxV4JUBPOHO576iRTViA
ZkcgL+VvwRpvu+22alWr0YS5vAsXKgTnTYCDlYJZ7ty1K0H0fbipJ/10FzwDF8V406dOg9Vi
q+QlB03gN0wiwRMRQeJhMHEMUPDQJ3yRi+3rnn8eAA9Kk1bmQxcNEi/1s2fvXszTulVLTmeQ
P7Z4PsNEiMVSMXrqcAlNVYwCkMRS1ov//IfqG8D+jnfv3oU3YAi2bttmt/blL38ZWpIL+9NX
fgrAh5aoZfC589sKSvDVBzrp0KHDv/zlLwU6XHvtNeGk2KJFcTwbvzAMDe824QZ8LNo92l/u
3MlRy88bocMu+IWkL/xozMCFM575sQsSWQdrv3DBQqSPjnUnxiR8jsrRc+zY9ldf4zSHwo/5
oQ/XeWAVYTUCTMMxYRLhvk+eDFfF/44GnyZLyboXX6SsVixfAWIzizh1iX7hG/9yyy0YI8lH
OGDAAF/hVLS3KED04UlGIJLQpg4CS0YZ64ULBSx+/H8+PmvGTKoj5gTvgquIIi3mz+eWxHga
61zyeVApfYK8ZFkgsn+9rFwFHw0yznlPeeGMFywNZAvjXpVKlbgHunfp2kUIXdu2Hdu3jw/a
AUbyH1SqUKFzhw7du3QRU2eb17VTpy6dOrVs1kxcpgP/BA3Vr1vHgWtdqLEDpk6XQ8oBKHVo
115wQ3auCxIPCAhL/O63v2MFDWwwcOBAZ4SWOBa7ASKMozIZ79uEHkSSn/D2vffe94lPfILH
AtzUJaVKlEwYiWYKF0sGBldHk0YRUDOEJuS895we8WU2AxfOeIHoyROM0axxYzF1AszBncFZ
alStWrJYcdgUdsiSJYqTV+wiUoxxxLVo1hSXVqxQ3p4NrlrqB9wovV+F8uVEo8vCAjztwJap
fNmyMtuKCxbhDvgXAo5SZy+IRKBHGHAIY3HWCc9AtWKSggUKOmNrx/KZMJ4wEPbPkOKFQBYV
ivHIW+nMXAKV5nyYFPKQpcSFIdhPUJIGHirNeJcZDefI4VwU4wXeY9IUEsrMwJjO9gjNLEpN
zPi0KVMdkCQTxk9wnsSgjjKW3HfPPYLBxRAJNxRiSLUTAFq3Th0ijspXl+WzY0cxfngAZzYS
zFi/PvuHG2X18J44CZ4pegM/PFmwIMuJVWDXrt3YyW7QSeGYrqI3iuYWBRMkHsZjBQ3xYIHx
/vcT/wtC2bB+FAPONBJyfjLb4NjAeHzfacbLkdR9GQ/6Yhkv5r1TjRs1Jgrq1a3HrMevBRVF
HEWwzMaN+bKLFC4s8teBXH033nCj8BPmeDEX4tA3btwApSnEi+4HPoYnwcapdrff9neARior
BmYtlEkhOx4FMzCifupTnxRl873rrrWRu1702HXXiR9l5Rdf97Uog8DDbiTQTiiKZAc8H1/5
ylfiCL0Mxrvrrjvxm+Xg2aXP/t///Z9jO7q77767RrXqkaj88Y9lTAlRtqJX/Er8piXeZUzP
OWZol4DxdCHEA2JDkIHkFrAsQoDhbhkwJ44bB8zRo2vXIYMHyXriQIRbrH+W+MY3vl63Vi0h
RXJptmjalK+MRte+TRueCciPAX37yWUiaqNkyRJCE95pd4dp+bgF2tA2JbqQSuhrX/uquFtG
mqJFikoJwV5SoEAB2YfkPhAwwhopPYGgSRKPNkniiQoVqC+oxC369O4jJyet9cpPXVmyRMk3
3zwoQwTx+EKcwkyGGFbNd9pq5pgXnh7o5TEDl4DxgpWFIle2dJnmzZsjX3Aqhkr1Ejq1b1+m
ZKmunbrI605vnD51CiVT2pnyZcpiBtksbJzq162HY/3jKO/TsydoGBu9/EhqLURxbjHRv9Nc
SQYvLdTpj+Pt2wW5eCoBLMRvCKySzUGzYGt9fcfrYGU0yeNxrBAOZF8NAU1hy2ozKdAJPEAM
DCeBzjkJPCNbi2eEGk1jGi8P0s3Zo7gEjBcmIOK9ba8KJcRLHHpt2rQWB2R3JIpRRL1/XNJQ
woKgBQLLsCBHC1w1kWV/JcUFBJYNGKEnmR+/vA2eXNROnluvS6wpWQ7CeLJ8AuI5nEwc3Emb
yDNxZs3opJPgHkhtmbPfeXr0l8EMXDLGC2HUZAtZx1ApE96A/v1BsZIb0DzlgChfpsyTBQqo
RpLniTyMnPIOLJgXGet95JKQb4cuV61K1Tq1a2/bGqUGuwymKD2E9Axc+hm4ZIyXyD3cItIH
DlNFBF4v6BNGS0Dn3Xv2+NuwXv0QF8MKKlWE8jcRimXaNJ43fMiAoaIQeFeI/730j5vuMT0D
l8cMXGLGS0DJ9k7SYJJd0kKxpjSoX89XyWSLFy0yacL4qZMnVShXntuAVGzauBEHoH8ay/YX
cmCmue7yII/0KP5bM3CJGc8wQxR9YB6aJy8f/zhnQ/Wq1TgY+MS5B2r4r3JlTvOqVSqrSaIc
lwwuIuoyWC4leP+/9dzpftMz8IHOwKVnvNTHSQwSUJ2SK4p2le5TZJ0SsIIS4EXomcrHnbZb
XE4JET7Q95K++Yd8Bv67jJeksnkn82OmiEvnHfiQ01n68bLMwH+X8dLTnZ6B9AycdQbSjJcm
jPQMfAAzkGa8D2DS07dMz0Ca8dI0kJ6BD2AGPpKMF2w+mZ/zmfX31PhdO0y9eXbkZzgTRWOk
ZD4+V5+Z+Zsv7SDf9SnSDS5mBnI242VHY57PXCDULBe+61WXFqgZYOXJJwvvqScQygBHjBRV
s36XD7R3AjJVGyCN4X63Cbssfs/BjGfoEpCJJFDDxUeKlMT/fu5k95oJVgLR7tipk7ydIhIC
DPqdPn5dvWZNz569xDGcu+V5vlIDWLN6jVwZ3bt1X71qZZY+fVVnr3jxElteeeW8bnfqpIrN
hvf88y8YQMoacbqkxHkOLN3sfZuBHMx4KEwAqwKOii0LxpPWUshcVAg6qFyZJXgcJEIgZIuQ
4EwyCFnJfvXrX//gB98XOBsQaoFkIx0vviTjZCxNVFFWhW9BnE43yKLkwHGYxDNOuntSR+WM
WhnRANSjEkAo0k8JVaWJw02TSkO+CtuXSDcpc5tUPgoqaBhYUnbHVxVdRB7iPceyYsvYLWGh
XqU5DWWHo/7T4IT3javO40Y5m/EmTpz46U9/pkOHjmKO7vxXVEoS9jr1kYjBKNleZmklxA0L
qoghupdmQq22lzdvUhA8cNHevXtCEuhUPsSD5OquXTvXrn1exs5Enkj+Jy1nKr85Vv8tFLIy
87hFbbTdu/YEvTF5F9JVSMJ7y5/+BCAu6yGJnSDsDr75piSBcoS2adNGVC9MuQhj5cdSxyMD
m7sEXtW/TG6ORQkKXAxh9YraWVNCugqRh4Lyk6Lt50EP6Sbv0wzkbMZTAfiqL1wV6qdLMi0a
XeoHRRQ6deoo64TUg+o0pJZN10w9a/wp5C9hIQc4UCDS9773vWu+e43KktgMyrRixQq9evZU
JlL6sxUrlovKFeCLGYoUKdy9e/e//vWvxKZKLC6H9q5Vq5a6hJLJ537oIdyC4nPdd79q7IqD
Fi9WLMTmxlLq5JEjb/38pz8V6r569ZrTYvP48c6dOunwW9/6drkypQ3v61+7OveDD6ru4kYy
d5LkkkpJhJEvTx55QQUZlyhWTP4YgcUwd5s2bVLYUZZeqXu///3vKT4uf+GggYOUQZUlTVpR
9d+tGmmZ9z5x1Xnc5sPAeKHcHBnw6KOPUgiVDZMB6ZOf/MQd/7yjR48eGC8p3aORDLyf/MQn
1CVPpJCDfn37OVm3Tl3JNr/whf+rXKmiSPZrr/nu16++WtXyBfPnhwy5KJtodfBArlwSY197
zTWqr7BnPPrIw5/8xCeFIFavVv3jH/+YMoCkaL06dWfOnKXqqqroI4ZnVPQOeqngep1IAwMr
HmSsYoNXfvJTTxV8UuXuaVOnafCpT35SNaUuXbpKgla7dm3Z5tVzJ6uxk+f62BVXVK9eQ5Jf
Bd+HDx9uYPJ/eljppG6++feSO+XJk2fK5CmVKlV2F0XGW7RoIaY+bXc5D454n5p8mBjvP2qs
KyA+/5l5aj5ffbWK25EOqSxoQnC+ivdD06rUZzBeJAVOPProI6ovBKVOaW+UunHDevJHnukg
lDCeXCxKN6qy4kCKNCextxzvbx48IKyesMWBG+NkSnZofnVepRZK41VXXdWkcZQGNxJ48Rpw
7NjbzCo33vBD7KcT8vbJgk/qYf++DLy4pGxqNrwYB+Cr7S6HmtxnNrHKEjnTrl27r3z5SwKv
rA62uPICW2vcpWfPnn4lLV3L2uRY9hqrg7ymqXd/nygrfZtzzsCHgfGYWBAWmlZ73gIvhYQg
9x/dcOOBffsz9MlTGVusQJfIXXhuJCIzjSKqnP/5z3+Wy8zJwk899aMf3Sj3EsZTuzyD8fr1
y2S8ufKOKccZGO+mm26SEwnj/eRHP4qDel/A8HL4CryQRRffyu1px2XnmZB+YoORWub+++77
8he/+NILL+bO/fBvf/tbwjncDuMRtspq40kGmEJPPRUYz4LiV0kTv/XNb0iJv2nTxm9945tN
mzSWoA3jqVTuV1U+pc1evSra48ntfc13viNxcHjYNC9cPjPwYWC8efPmI6xhQ4dR6iRaJ0/y
5817w/U/3LN7DyqP0hYpdRJ/NGPHJxBQuaRjEY3LOX/0aJlSpSXefHnzywTSH/7w+7/+9dZX
trwsXyCKPyvjqeXgvLydzCSB8X584402cljl61+/WqVbumgkA48fW7Vq5Re/+MWmKRLPSfUk
QreyHhqMjEw1alT/3Oc+F1JWR4zXurXx2E8eOXLkhz+8PmE8i4JfW7Vs+c1vfF0WpsB4zZo2
SWU8aRaxuiVAyy1btmhQpnSa8S4fjssYSc5mPDsi4uuvf/ubRJ0sCtgAsSK4B+6//+qvfVUq
aHn7ZNGcOmVqEDiB94TCf+ELX7jh+uvt3277+9+nTJqocAIr4q9/9evb/n7b5z73WXwlv5hU
gY89+kjgBNYUN1q0cFHY49kKOkmgsce4S+7cD3FoOOAAkM+ziZj6GjVtGnPlyvWnP/5R+9o1
a4YBUDTfOnpU1m2bwwceeMBmjFDl+mCTNE7M9uCDD1WrUkXCqOBOOHT4kAd5/NFHidNvf/tb
IUVvwwYNlHRWHWXd+nWf+fSnpfpUJ8xdOnXqHD1dr16Ob/nzLSqHSvL7y5t+oe6KwkZvvnno
sqO+j/CAcjDjRX7t1avLly//1JNP2iMxLXJhoTx03LdvX5aSw4cPod1ixUvIlptpVMwogrdk
yRKZJvLlzVumTJmQoX3pkiWly5QhWzjBfN2/b7/k1gMHDoom6NSpRYsWlStXzsZJ/s9y5crL
FoOJevfu3ahRY0qgBBb16tU/fOiwnLlVqlRRBkwy3BbNmxmXHNgMnqHPsMezFRQK7KcCBQr2
6N6dwyNTFK9ma3niiTzdu3aTSLtq1ap6s+1knlGDRQJCObVlpqEvsr5UrVKN319hzWrVqqki
ZmDlK1ScN3++rrgWWrVspX9Zfd1UGaZiRYs1atgoLpT77jiYjzAvvK+PnoMZLwvwKoim4DtP
jsNBIu7iqWVXzJr8L0tXiWxMlZOOQ82jjM5jX3y4Y3KQfTazDCD49pOTKWPOejK6XVzMPdtd
Mu6LiVNulzGwgBA4PciUeyWmnfeVvtI3e4cZyMGM54kCICP5JM8YzoSv72RUOPdVSedJJ6kd
huPkLllud8avmbfJMv/Z736Wx3mHu5zrdpmPnPrUqe3TjHCZzEDOZrzMScyE88d5ls49s7Ek
OXviwFAUNsiZiA1SOzpxdgY+U5ZGl4QJvbC3G+RbKt8GGXthvSVXpfYQS9ywZFxst9lHFeT5
eRpPo3m+yAfLyZfnYMYLalXMJxnFzVNddmd9KciCnVAi97MSDaZl6oTw0HOis6WSLzY4gxmh
yQ4dCkBKn5DS9+jRt0DMLmA3hR/Azdhgjx59O1Bwklz0+LsFKZxDpgW7bpZBBlY0d5eWdJN5
i5Ljv8MKmDHUeInxXJd2ADmotxzMeIYu/bsqPw5e27Zt5MiRGStuCj1loUgvm9Fvfpy7OnlJ
QcI4M3bM2LJlynAqRILr5MlevXoqmB54+9CbB2vWqLEmNpkmOiFoJQxXEhWhKkP//v1nz5rZ
qWOnpNlZNcwst05t075t29WrVrmcfaV69erlyparUaPmwhicfVaqSgafNIjQ1plNiTWrABvp
nrgsWXhMZiR2I3lMzd5Zx5mI3NN3jKYoQ7s++zD8GkmwE6Bt3bt1MxWhWap+Hs6E/ScLsLLy
qswT6HGb00tA/MoybhIdXerV4TJhzhzMeN4fFOWwYcMcrF29mjkxxazwH2rMGV8zzQwd2rdX
F8VPQeVKbcNEmdRIQQ4lixd/KNcDwavO38BTFy5MPvsP7GeHJD/DGX48BlI2RgX9UpvFq39W
m0pQa8MnlSKV5gRDcRICUywSg+2Lz78AL5baONFmk5PPPPPMCy9EjrvsHzRdpnTpBPzN3aLP
uXPnrl+/HtLgrFOUejI1BiI5HwaQxZATfuUyZUNOFqPs42FP5tv0yM8tXx6gQhmTQPU9ccac
ZJmfy4RhLtUwcjbjATEHZti6ZUsokrx27RoHEF4onS9B4T4FjJT88ZxDnh4CzIXspPcM5G55
htKEhLT245l//ON2QOdDh4CJT1HzlLYtVrjIizFBk5PFihThxHPVwAEDXeK+Rw4dIiGbNWuu
OBmfOAwXMSUdfdPGjV0yccIEjgTgSb3Fmt6pdevWqT0GWaLw2PbtO/r169+sWTM98+D79O7Z
S4F1qLckGogDoGbNmkYCitm7V2+IcEU2ZSilD/MouESue9VdDB7MTb0xGG6xF9DhilhzpZBy
XO2G91SBAkHi+bRs0Tx1+bBqqJ7rcaZMnkT2zJgxs0uXLk0aN546dVrTpk1HjBjBf6j8k3ir
nj17jBo5yvysX7/hjTdeBwQ1FRz3oS6Np2ioEsaYsaIlxowZy5uiTevWrT2vmoRmHgZ9/Ljx
O19/49FHHgHdduHE8RN4VlauWKGUd9u2bT2Xik5eh/cFgkPfBtCrV68e2PdpCXipqP4y6CeH
M16PHhxxFDz0V6N6dZuZmjWqL126lMyZO2f22jWrVSnqipQ6d/YWoftR8MO5c8+cPiNQ4YRx
413F+6wi9IplyytUqICybRTDm27epInqYoMHDrRjaVCvXtu2bZC4gs9g1oLcSpUsaWnX26hR
o/jxlPJbv2FDsaJFpk6Z3LJ5c5KTgrdi+Yry5crjk9Dh2tVrli97dvCgwfh/1apV4pjokGTm
ooULJ0+ajDQXLlx0/733GXO8LpzikYO6tr/DLerAvPzylnJlyr7x+uuulX57wfwF4h6sC5gN
0UNI099g06wOHdp3oAh07NABt4wfPz7XffeFrMH4X83QLS9vCeuOvwL5pPQGDADIVtUMB5ol
K8uDDzwAzlr4qULLly2/9S9/GTd2bNHCRejVVjRTQWxWr1YtWo969hTN6NdHcudetHixsocW
l7x58ryyZYvGvKkrn1u5bcuWObNnqZgtOmnDunWtW7cSh4Eb8z7++I7XtoOzzZhuwO29Jrgf
RUsVG9W5laVooUKehVj+UNpgcjrjdcc5EydN4j1HuC+9+MJDDzyABIXwwDELz1F+CCwLir9P
r17oA61079o1YTyiaVG8fVK62RIuvGD9+nW+hl2HIipCSJX1e27Fii5xmQegUChKQkybIUOe
dgv4LMoVE0uNaAe42r0wXpvWrYiRpwoWhFp+5OFH4mJjERR7z569cG21a9dRBX41aRzXW+cc
VzJJjaTFixZFEql58xXLl6cwXjWi28Ixa0a0WACg7Nq5U6Q5BrMXjW8XgXKQOEf53j17H3zg
wU6dO4uHsvRUqVgxCDq3c5UDXcHQIPqE8dxu7uzZvpooSb7bt2urHwjPRvUbOFmnZk2kryq9
Y8vX4oULYdAUuLeiQc84CbNqVmnXVA9fmzVpGuEQSpZc/uwy/JzQlqXNSzG2DRs2KBplzHTR
EsWKLlqw0AriwmiJqV5j+fJloVvIoeHDhls+OnboGJaMJKLyMpBVl2YIOZ3xeii57sVs2bwZ
HYPzI3cUbBexbdurVStXUbeoV4+ezZs2xVpjRo/REouKQI/kXUQoTYT8OOjTp09c46Hl889H
dTAD4ylstH7dOu3xtj5Rw/Rp05FmYDzhORivdu1aGI8hVJsMxpscM17/ARaC5cuXr1m7lh2V
ukipU5hFvomhQ4ay06xa+Zy7h1tPGDcOPwcLCjVvxbJlWRiPNJg5Yzp5VblSZbqfZPj169XT
Zt/+/YSneHYYmvnz52G8fHnzzJkzd8WKFQBlFcqWjRjv1KmK5cqJMAyP3LF9h4DwDh86ZFC8
RTnFjNeOVCf6LEmmgPoAc1eubFk6uQr1JDPgTq0aNaSrSBhPKv6pU6d4Cp24iq2rdMkStsTl
SpdW/dNJJRCB4BYvXkJXN59DBj89bep0ANfiRYsuWbS4Tq1a2hi5NWXF8mUe31cQ9rHxy/Jy
K5YvB/j24bOw5GzG69ShA7LzhtauXmWZP3L4kIrQY8eOmzNn9tZXtqrCZ9OCRqtbpNeuLVu2
7IwZM/55++30yUB2djIVCY2pU9lRtmx5GcosWBRjxjtRvUoVYT5UtVtvuQW5d+3WbdLESRiV
MjZt2lS6mQiAu++6i/Ylao5eR1oWK1x4wrixlDEaoOKbtCb/mBDYcWzkShYvMWH8BMTtdkgz
ADi7dOo8dtQosbyRfjVt2t9uvXXZ0qUx451EjuwiMN842bpgVJUrVcLSipm5+7atVLjZQn7b
t21H4tE2d+/ehR/69+s/b94zIoawa/v27QcPHqTEvP1neK6tW7fBqhmzqaDaPfPMPHFStqYl
ihWn1EGWkdgUh9o1a5gBxQynTJla+MknBUlAfs+bO4eSSQCSe+Da5u3BXLlEA5oiMln/BrZw
wULMbxMrWMmiYAJ6dO9mxZk/f/6/77rTRprMr1O7Di0gz+OP7XzjdcqzXZyWdolUaOuXfhg8
Bw0Y4OmETRbMn4+4jhnvQ6Vy5mDG8yps53CUA+YTlISyrNYtmregpciqYLPEQgDfGCwco0aN
FlBDY6RrhU0XKUT+MGYKnGOnmz17Djt4+IlWNnPGTK9cLDnCcvLZZ5996aV13j5SYyBhGGRI
wIrdunbDdSLfhPkISF+37qUgEl2Ojok4VhDCSqcvvvCiMtQDBgw01Fdf3Yaw3IcNEwNoMHjg
IMF77CUqchqAreabhw5ZGt4+dgxSFFc7iSXQqBxJrvUULVu2tDti15HsqEWLlhs2bIRWpTC3
atXKGYKCqta5c5cRw4YdOhhbjOJ93Yb1G8RGNW3SFOLUyfA4OjQDwiNog0L4bWbNgOAmSw8r
CFMHcaeCvFgkthn9WCMYThTTtsS8tG4dY4n2Otm69ZWxY8dQHQ8ePEA7ZXbasH4dZcE4hw0d
ynwiSNLwbJLhV60pONBusFu3bpCufsVqfBI0BTrLwAH9CUD7z2gVjLyCaca7NFruxfZyNhzj
acRjlhUlC0IyZq0zai/7GsRgGFZG+0x3Q3J5oN3wyeKxSAFyngZwRs0yP8mFp3vIhJVmsdpn
ONDjeyV3yfII2Xs7x5nEMJh9HlIGkzF7wcmS2jLJCpM5RWdBlqZ6F7Iv52cdW+pkJpdk91KE
7FUXSy6X2fU5W+JdZpOZHk56Bs53BnI244WlMDyDv/+NdfG8nEjvgOTM/hKMMAMReib67Hxf
17u1o6clYiQW25dOUMT5qoMwjKc6gqWE40QipaoM7zbSj/rvOZjxImTgsSi5nWc4cvhIAApe
SlIL4XMAlJlozOzE4tY+4dbnRUoxgIad8xwpn0Of59XbmY3CTlL/zDkh7V8MXr2Ans5ySUaw
VZxEmCE3mvaTMqYd0f2xY8cxYvxconwjS+alueWHupcczHgBlGxbz5gmHlQmr8R+EA4CBWec
jMD4Z5yMfsgkkYTQkwszcsyePMkAGNIohJkKxJCx0mceMJ8wHjCuhPMZvUUwwwBFPM1FbJvA
GdBtsgwi3+R2qaPN6OJsMUEBpZ3cInNIp/tnfhRcW6tWTaCZZc8uCyDIlIfKGH/2543Dfc/F
7R6Njy6a6qpVx4we/eqrrzVu2Ei0LjOmK3kO1LiHs6lZs4Zmad5710UjBzOeoUNISIk3e/Zs
tjKZS84EQJ6BwwxaEBRI9l0+MRkLh+NhLlIrKyDFjRs2nC4WHRN+zF0Z3fCYAXIxq0iORBSk
dp6p8sX6WCa78kZwasGy6DbcNwnbTa6dMGHCypUrU7six7MPO+PNRewSc2PMj107dwFzEboO
xsUgmfJ2U0N44+CjTANSKmDVc51VdOtH5l9wNu51YLfXXnuVvZEbAGhG6he99ezenbN029at
7psYjd+V+D7KDXIw43nfDOuSWCZEiWgGDRhYpWrV3r37HH377aefHgLhIWPCqBEjYa840y3M
cICcXc2aN2fdrlql6jPPzMUwjPi0MokkeAIgs6Smrle3Hm8SdPLokchr6759e1u0bFGrVm2+
JmEQfG4w+ERcseLF//WvO3E+vziQNN8G1JVkDbyCL7zwYrt27bnRIdpwV5hoRvmypcsEGyZX
Ne+WA64tcrtJk6Zt2rR9Ye3zd999N+Al2z1HWeUqVYYNG+7K0aPHcJPobeTIUXXq1DVgcBl4
EYiZkLrChx+iQrnyQQ8MH+tRl85denTvsWPH6zzgnpcj0Ug4SPRPUXRrDhjhFJ4XkitSHUMs
YmYPiYQ3G+pMJD0DAwG7hK98DOXKlnFt8utHmaPO89lzNuNhKlnDYrmBlE/xDpUvWxbFYwzw
rkKFCtG7+HaLFi4Mc8hxDOj477vvHj92HLAvyCVvFXyTNZs/2n6Ok7pr5058g8CNWKhK5SpL
Fi/hXwawhF8BziBDZKpdumQpkQKECc4CRgzvAh8t1R9S1icHF6xww/r1YankJuKnKl2ylFCA
RMh07tTZ7dQ/AVXhsufyMmYAK5UPeL2xE5TzyBEjXFizeg1eNU5zmaQrV66M1qGN9UnMQoE8
PWhw6VIljYTHMkhX4+Gdc2DwHGikK6aSahrcxIVgJc57XoPx+Dz4ADe84YSYrE3AAIQYn57L
9cbDKdxB4plEVjds0PD5taejoghtqVy6du2q/arnVsLKOjBmrsjZs2afW2s9T9L8cDfL2YyH
Vp59NgPn4cVDPwyPBSBHMEhHvbp16J8L5y/o1qWLkyWLF/NVPAHUv8zNI0cMf/Pgm+XLlFa9
AJoR40lSBPW7bNmzUBra8+pOmzKldq0oHK5i+fJJqAuEIfRJ7ty5582dC5gClmkSixQqTGpF
AMW4aoIIicGDBgYEI7h9iPSJfcCRrLMdhbDhLyaCpkyZ0qFdO7gtTAuo7VeLBeCVWz/84EO2
jlKhLVq0MGStxYEtmjXXpnKFiuDaoGc4n8pK3YwYYOWqgOR6bfv2jh07YoaNGzcEMKSFwNLj
oG+fvqCVXNjQBWRUtapVwFwAXPwEMSOeIEgt0ljaX0tA4EN/HYen8DW4+PbvP2AAAGh0yxAa
4om6dumapFT7cHPORT5dzmY82wxbi0TDGdCvX8h4CQMFMIUa1r30EjgFxsMMJYsVI5QwHigW
/iRVYD6gojAevnLV9OnTevXoQRSgS19VCALdYE4gScqWKqWyl5PPrXgOdtGODriJXgrKGKCP
gPwEkRgCE8qiiCKHPj0kpHZu0gT8MuCeMwwzjjEerVI8IY6dNjWKbNq2bWvZMmVF2UgyLawB
OLNK5UrSh23dtk3RH1wEo+zXls1bIHxISLAsWiGciicNMwAUTrp6HMe2ZDHmez2hGo2hUSPA
SAc0zxnTpoO/gNFE4M+KFa0drVtGz2t9oW068AjgY8IvILaC7HKSug5ikkx1OLCQlS9bThAQ
/Tlgr23zwMqTh71I6vwQX56DGc+6Kw4I2M/mR6wXzSpCSxYtKmyMQkX+UNIYJKOok3btAK+e
zJ9fcQ9qJ+Ai/oTWlTzTV0GiwJODBw/Ony+/JNBUTUod0rH8Q3VCZgLv2klWqlDRBgnErHSp
UsTUww/lxqgLFiwsXqz42jVr8z2RBy4Z9kpyS4AskmrihImdOnTUj3BvgwkEjSswqruDO9tb
zpg+TdkgLI3oGWkMHnga4llsgQgAjya2TVwfM73dncD5WKlr4MFJb2OzaxXWoDxQIHR/NS5S
uPBo4Q6t2xCSJCSkuPNw4bZ/IP+lSpSkb7OFkI1AniJ94dGo3/aQ1atWE0aQdBVYK5C+kZtq
wFGg6nHjxi1cYCzP2OtaDlh9NbMdtYKYeboAqGp84SXyY3xImS8HM17AFqlZ1a9fX2YMUdi+
KpwgqjJKanDq1Lxn5gpPhVoUFcZ2ggPZJ2logkRffPFFOx+bHNs8+5nVq1d16NCBGAQRtPvC
J6QKsbNl88u6xRiWfVYNbZCySBlCxoZQYBty7NWrN7aBzHQM2ElRpPFKaiAsdeXKVZhEEKBq
dcEHsHvXbtB7Ymfzps1GawtHAut8/vwFbdu2U3VMG/BuDYgOGE7PhVvkcdEJeKf+RXB7cBuz
lSufAxPt06c3QRfkUtAAlyxaRFZ369ZVnmmTYz2KvJHHjsFG4gpD0obMpwaDU5PYrP8Vylc0
5kmTJodOEmZLpfloqnfvxmYqNwgFZGSKZmzYcA6MYJ59dslS97XrE5KX2s+HlHEu9rFyMOMl
pJboP6mQwiABsvwUnjb5KRycFQOZ5WTYRGX/pE5flkQSoXEqyDO6XYqPQ6g7AcKtl9ptAhk9
Y/DvkMbi9NPFZBB4JvsgA7onOZ/l0UClGVTDr+dgmHMgRWP80BkOj3DmYmnzQ319zma8nPtq
zLtNXefOnXfv2nlmIsH3+5nYReWcjtj2PME37/cAP5z3SzPeB/Zes8irD2QciWs+QtsdT8uo
9+8lpBnv/Zvr9J3SM5DMQJrx0sSQnoEPYAbSjPcBTHr6lukZSDNemgbSM/ABzECa8T6ASU/f
Mj0DacZL00B6Bj6AGUgz3gcw6elbpmcgzXhpGkjPwAcwA2nG+wAmPX3L9AykGS9NA+kZ+ABm
IM14H8Ckp2+ZnoEczHhxmscMMH5I7hhCb97rS4WZDLMQgIuOU+H277W3828f7hINOyOO4fSl
IVDg3J8kniCjcQhNCBkv40+YkPiJMrJZJ8EZyU9JCEVSFDI1ju7MsImMyQkhF8ktUoeadBs1
eIfohIxHzoyWOOszhnGeT3xD8qbC857njL3b1L4fv+doxjsugaRMOwoehPcktDQqzfMeP+Lo
JIOQux9QWIidIL04LewJGUfE1L1T6EBCxO/xbqebG3AIKfQ3yTLkZyvHoWgw70hGgR/kL1Ip
QfomyQX90YnAQtmZMugvypwbLUzCC50PS5IDl8R3PPHWkWjqhCbs2bM7JErcs3uvZ08YSdj7
jtdff3Xbq8IRpb2QXdRESQkTzU9mHIObRj9l1pR3awUbBPueIywoZHPzV4LAqBTz2RbKI6rP
HDoUErqde3rdyPOLAIwm8JwgbzdSP1C5lQt+X5f2whzMeN6KkiCFCxcpX768mjvmRSEuQdln
ov5Px6Elj5p6gAIkhhg3Zkwo6dy8aZP1L70Ueli6eHHd2nVioZqZqTqOxQ5SMdBxdJz5axLz
FjFPyoqeiKZIIsWfRFxYo5VFkU9JHGo476/g1Hx58qKSs5Kdk35Sk0z6oxrVqklmMWTw4Pnz
5rujNCoSioWrYu49JEGLHBOK9QiWlQRNLgwJHUJ2DPHjhQsXln9T7LmvIoNKlyotq8XmzS+H
B1RJS+2X2nXqlChRQj4YZ6Q2Gz92rIygoorDg8ho5hYh2UT4KLckv2DqY2al1xMnhSM3adRY
foCe3Xsk61d007ipg0mTJgmxdZyljkKsz2Smr86czEOHolJ7wurDTSPxHmVJy3jvyd39pNRu
wwb1w7u7tFx0Ab3lbMYLOeeIK7m3vH605aVaBRFEyE0kdlu0NbKTalptGhOuio3zcS7naJmX
EkKWPqm+oguPH1ezTra8kKlOqhW14MK6G9ggfFSl079mqhxbm8PqLhDbT/v37Uu4S/0gvzqJ
evQfsu6RTqFlLO2itV8AePWqVTrG6YZcK/+SxJsPP/RQKKyV5Y0GaabmkdQS+MqodCv1g1QU
0YAXLmwYF5TMYOAZM2vXrOUWEq5MnKh82Fi50qSZqVi+whtv7JR/dvLEqFyZgXhezC+4XslI
SdNCD+5ltP6akwH9+jspnp1AM11uahyRgD1yBMWHUuYmXz9SV+jBGwlBydnVPyeV1FMQk9Q1
53oIExjl84z0jKiQ4N69+6gbo0eNxn6+xm9nj+eVsjp5F5HUlUj32DGZF4sWLqTCkZ/27tsb
K9sIIJreAwf2hzGEN67iZ4P69dKMdwHLxBmXmE35C6QeMbOWZNXhlFaUXESevFo1a6urLNeY
1H0Ki1etVk3qFOWOK1WsJNlJqxYtJUeRztkbVU1WZjuqZs8ePWlRsnFpQ0qowuU91aldS+eq
z+lNTgdZfVSQrFatuvSYbVq1/sMf/oA4QqJOmQUlcZHQWvE3SVz69elrRVfRynIg54ocKtu3
vybZniRIJJWsE15/RGsxN0pRERjPZ9SIEf379lXQTycJC4WfgiClK6q8l5o8V5EwCSw0UNFS
TdbQ2EdmJDUDpSSUr0VWmKaNm4Q8ufILyq0iA0WD+g0krUDrMlyE0sqknPRHFqkgE5yRu1Yi
I6wlHYb0FmHOlYyVRUJ9eckpLAFS11A0ypevgLFNmhTD7qgs4e7dewIDJ0MKfbq7BIcmPzCh
rKS4i1yVf0lqDPM5YcLEAf0HFCxYUBHZpc8+a3klq/M8kWf9upeGPP10hQoVpcawQjVp3ERi
JSl0S5coIfWTZlKqCuo/8tYRiVUVnY5qa0s3HKeiqVSpcolixcx/SO59scR30dfnbIknKdgT
jz/x5JNPNmsSZbZq07pNvz59LN5UUDm/VCr2RjGVcseoTQlLqY1e3rzl3rvvlgTJu5w+daqc
JbNnziI6MJu/UdHWoUPkyUOyVE2aiaRjRJAstxUrlKdrPVXgSbLIvkKbGtVrWEddSNkjHCSH
xhV66N2zR8F8+W0nsJZ8gZhZs2NH30aO8rXIfSLlHiZKDANy+6mwafwouE6t2mR1tSqVSYNA
H74qE42BQ+72TZs216xZK17Io0IRDtq1aZsnTx6FKQsWKFi/Xn2XHIlqJ0RqcMkSJf/fb35D
vURrmPmlFyMt2pDGjBqFQ3AsQmzbuo1nlKEoqJdlS5ci2SI+jzvv2qWzTDAOqH/9+kVZKnCm
CntPFsj/zNw5tpSFCz2Fc0yC/bAMn1RN+UtlH5UwSh7BaJwnT3quSZMmWhnDE/krd8uTBQvK
oSYHXKsWzTdt3HDHP26nvCycPx/34u2e3bpT/vv37xfeoIQuMhpa7yxnJtYyKjna448+Kukb
SViiaFF7UfMvMWmp4sXVpldfVvFtSdaktLHLxefyXHl98jgaUprxLmrdiFZf5Ua7dpN6VeYv
mpIcRCqJSuq65eXNqEeWS6RJF6JxeT1jxoxWAN3uR6lXKopMW7Z2gwYOkM6ImiR7LD3KCrp5
40aqqWoMC+fPsxVR1TH3Q7mbNm1WuFAhRRLpdWQdBpOtCK0bg0xbJFggTYmrH3n4YTk7EZbz
XraRyDOp6KQslI8+/EjtWrXUHmgoU1hmfRUXSs2E2hy0bdO2atVqhC1VU1KjIB+sDldccYWF
IFAMc0iF8hVcHudgjxp0aNe+b99+iHhklIEvSr9ZrVpV2fgIfyPctHGT7KOSiNKyQs5pOyvF
n4MUOnb8mOxpshjGtZ2lEjtcoVyUri/6Lb5X9WpVg248beq0wYOj1NG1atRcv36DdKO7d+4k
ssuWKW3XJ0116HDNmjVkjgMZqCRfDCc9nUfo27t3xM+ZezNZp3DF5s2baMKG59WYW3J42dJn
B/bvp8w19Vj604h1T5zUZt2LL9FuHnzgAVkGZVKTetAW14pmybPHw3gjRgwnAx+4PxfhLJep
h2VzkiLR17pxweeN6zeEEtNpxrtYxkNDiMacyq4Z8md6YWafUkfJrFq5UmQ76drVrlob/IAC
vKeqFSsxYsppOX7cWGqkjF00N/obxtOPVJxv7NxZQzmO+fMaNWgwYfw4RPnmm4cOxkVV9UO9
JLJY0uSx9tW2SlXUtavXlCxRwg4K71GfnJcXjG4TLrH8Y0V0tmr1qsM0uSgzV/RJrClKk2um
7rG0fOq8/uWWW9wl2HAYFSWcJaAsGWHfZdl+Ji46Gz6SF6JCB1jOoqNz+iHpLb2f3KHO+5XU
tdAQtr7Wr1sXe4RryZMK5ctZODz+sbeP4l5LQxBKfu3bu0+oEe9DZ+vff4CDMqVKrd+wgagk
1mybCRP6BR4IzVavWa0EswNSS20TBzpT+hxTydUZKdjRJ8PIVKZUaZk5ZWcsX6YsPqGTV65Y
ycj79O5F37ZQhpkk8IcNifIUW0qsj8yqllEagc3qgf0HPG+ZUiWlVLXAUV9NjvRNqtWSvQS4
bYOnsxOJ52dZtGlPG1cuiu3ihVPuV6nUbc/oHl6YysNegL2HN03BkHOWQvj4Y4/LZCklprIK
FmbWDUqLNyd565hRo627pCWZwDxDqWNIWPfii6+/sZNiJnlk3dq1WR3Z+qKq3IMGIg70pLFc
sfrPlzcvC2SDevWdl41PyXXcpZ/evXrTyuyC6I0SUBIINDELBIlE3EkFL5Ulug6Gh4gxZsyU
4jJhJAdVK1UKxqFEPjiOWsfqn61agXz5KYoeH/V36tB+aqzU0cQ8e9KPgsaFnnrKgIsULqLW
NLovUbwEg1CdWrVw7zNz5lIWlExo37YtUrRm2Z3KqDtz5ozQA6lu6iQvpKiTyXaMZL6Huutf
/6Lu1qheTRZ3/dDeLXOutQzhwCWLF4WEtj169AwSL8seD08/v/Z59lL8Zj3yq+LYD+TKRQex
ajxZoGB0bfcexKORFC9aTIp+Sqkq87LQSwFM0bXBk5rNg5PVrFk8D9RL2RatHfJk57rv/pjx
mq5eufLAwQMVypbDqHazkhRbGW1D9J+WeBfJeiet0CNGjLQuBlMEFUj9ILttTIi1qKCUfsV3
hg8fMXnylI0bqX6bvWDrPdcTQqRKIeVZs2exgqgr8NZbR5Xz3r9/H3cg4tCnv7qVqdZ+Q4ER
Ak25Dx2+eehNQ6d5yodp48SAqdkLz6+VSRZXUJ+wmeyuVFbjkQyXuT961LhKOCmEaJJ3H+wl
EmwmcxHl+Vy1yvbpbPQRmf/ci3mDP0AaX5TnqVhuULAkogaT9KMZ48eQIUNtdwMvrVmzdsTI
kbt2RuXEJH72UDNnzjIhhBLzCTvTM1G6segT7fcOHpRp0/RqRvvVP51NNls7KJZh02WG5cx+
bsUK+gLiHjt2rLoRJs2qpzG3xGvbtgX5lvrx1XThEzMZKxEnvaOQXt4uMVS091pf3vwyFXfi
xEkyoCqDYdiS1StJz/eowAMlxcbPezRLVlJjsAQsW7bMhFhq2V3pI5HJ9OhR6wV92DFXkzdI
nblYmrtE1+dg40qqNMiyssZrWkoKyxRpEq5Krj2zslesAmUa9MJFqQt2SjcZtofkzFnzYZ7R
PsW5Fw0ghR5Dsyxn3tHwdmbyzOT9JeNMJYxkAIHtU0abJQ3m6WycyeVZKIOim/I4mbXHYqUx
Ow0lg8nuToi4OqWj1JZZJjx7t6nzmepeP+sYkrechU4uEeNcbDc5m/Eu9unT16dn4AOagRzM
eBbLZPRBOwoC6lLOZOYtguk/rLJZbhCt2SnFYrNInowLM4Esrk0VO6niNFEss8jYLG0iQGnS
W1yJ/Ayxlu3howk5w5OWkez9vc5SIo6S580+1Umb0HmQOUGSx6PIQKWeqUecgYzNuCS+PExd
xtPFVplU8Z78FCpsJhpH7IS/pDTwXmfq/NrnZMY7fpxxcssWxRG2ej0HDhxUEOHSTrqXGpAT
sQUyep1gK1lqptIJbTDsKjOoTZVwu59Dh8LXBJpoJ7bjte0xnOKg3SZkhjH7avuhyMGGjRtY
U5JLbOE2bNjI4geWoQ3XCD+4j32XF+Z2Nqs2OTjQ3mzbtlc3bFivOOtZnz1GyBzne1SyyxgS
pMj5kUdGK0NVOMVGLjx7BAw6cCAq457Sizb2xgyOYRjhjRheJuNFLGQ36CnswWxVudftM5l4
wzzYHJoFM2OEoddQKzce+UZmEvMMPrpp8+bDbx6KqDae54ALDcgyW2VTcekX3/c0U+fdOAcz
nilmqCxQoACsCazjunUvhepwyaoZjkmEQAepP6WKytS5ymJrdgksCNe58wiCAZBlLwJ2pIC5
tOGLZ0EN/b999K08jz/OPZg5jKikEeM7uytfBXplZgRe4dTmxEdMjgEs9PB8XGndYI6+fZQR
r06dOmXKlKlapTLjQblyZSFu6tevhzIxKkc8MynPHuMNFEjevHlq166lxhBTx1nsMXFNJYUs
QXaAeEKxsWha4k+4Y/T3zD1laj/hF2WG2HK13LtnjzEbQ2ob/WGApwoW7NGtW+jfje6+8061
BMMtNN7+2nYGZC+rR7fuVpAWzZt5BP4DDIMhlWoyh0yj/EChZxeqjlKkUCHNmG2xPb8O2IqZ
dIlnZyKGEIAo0nLRosWKGbHfqj2YEMB5c8EH0DBnM556yEyall44abYvrlXIzEgURNrYKedB
+EFEYmo+xueDaKK3EpePVXkHXDPWTML6Gq+cQb+JpYSWjGBPFSjA4a6BGIg+vftwWwErhVcb
tB1m6wL58sVglIhW+KYfffhhjuCEppVibtUy8inrMwYiRmOAseKWcEmtWrWA9AMnJO8/0C4X
Ip+BS/Ati2tykjfZsRKtHhlqhA09/HRW8tEtaczUHiBabkO0sg1akAio0C3RQTQlAtOsRDOT
oSJGz6gSYJ5HH2vXJipbCQ4CjRlVoowrwifzAOf5+COPdOvcOQyGizXXvfc+M3t2Mg9gesEd
J5ri6FtH98NVxvg1dcswlRqd4cIgVONhHyxetCgfaXTy2DFOF04Lx1FVtvETeGUxeVRbs0oV
r4mnbu2aNdtffY3v4aww1w+At855y5zNeKRHcKBXr16DLbtA/ny1atYCwmShZmeP5EyFCtxK
bx48wDmrUhwX9sJ4DSYh8SpGpUEFig+KzYwZylYtdQbtOetaLxicivvBSbKOeAp8kvAqMATg
RQSJOHWKpZ6rmi+R6zkm8ij+BU1wJXNeE1YJbXFgQDBpYJ3u3r370qVLUjknNIM+4zcH91WC
jz+NX85JhcSqVKqs8BjAGvs7lGapUqVZ+XftysB2ZhHvboHTVN4MHhdAFsLKs4tRgLHi4Nqz
ew9NwTKUcL4DZQBVBQuPQEo3atBQnc0O7TOcjZwf0KfJUqGN9U5XADrd4yqZ3Bgtm7ckIWdn
egWxfdmyZUBPpkyZZM6jQcbhHcFJyNOdN29eJQq5ExJG5QUh3HhKleNzkqfE2+TM4OLHaSbc
JDhP4sGaQagErDaVRNG11Mm83FgujCeHM16PHqWjaoktOUxfevGFwk89ZTvUqWMnPiLeapAO
OgxZBPFQIF9e72zunLla8sMiRE68ShUqzJsXvdRkpz5s+PA5szNAIZzOMGj2TlGlxZgqufgq
la/A+5QQh57xGJcgwIqTsKMLFixQjxaAJuqWpH3r6EMPPIDhjYpqRMKAGloa/nXHHevXrder
oIGBAweWKF4c80TdZm6QOAA5fMkiG6rRI0ciUGUrLS7aAEz97re/LV+uLJFjm9S/Xz8162hx
RERQIHm0Bw0cZCsVhwedNAlPPPYYqlUxE4DOP15paiGOov268OlBg1yVaoYB++IfD/w/bOgw
/jF4zgQXpta5KuoJ42kD0wyGCnwXqk+bDY44LLFg3rzQCdfl7X//O7CBn1q2bOV2XkeRIoWB
4/bt248DKedQRDz+bhQumTFt2q233NKlSxfaKfyDMwKXbv7tb82VZRFWRl1eJ7naoXA9CICO
Pv9w880BqHR58lsyqhzPeDVr1qRu2QhZv4MONnTokJHDh9uPzZsblapE0JDQ9WrXpmpGK3GL
FlMnTwKVUBQOzYnKCeQO0QurlS9/vmLFiou7EdngQBktQBNUy6VrpiLGq1AhqJq+gkrnzZMX
TkW19IIFCgBM5H7oIVqQJRk+m/pkli3DDz34IIe4S4gaVIWRoF4QKPBkYm/k66cyhSUgiCxA
DRU2HSQxaQplUi89jnEK/rXkI7hAo6HzZXE5eB+AG9hIkPxAf0ailDRmo2F6EIoiafn4o4/x
Pnv8m37xC0IvuvXxEyJqBw8aDORx/3331YCfbtvWQz2cOzcfOgBa8WLFAn4a4yUSz1chObly
5YJxIzltPufMmQPdakkqWqQIHGmIh8J4ue6/H07aMfgIaCUtkWlEYGGIRQwf8U1hJxkdT5qM
Dx2wCVFeQGHtUe0dDI+4BoUNwDfAIC1FMFN26tdvkDfPE8xI4cEv50/OZjwY6UBePiB5ETWw
uAwcOGrkCLssaAdfMQ8oE5Cetw5WInATjIvwQRDEEUNZWOnhLQirunXrQUELlmFJGzNmTFQV
uUGDu+++O6hA9CUlvyPTYhy1ybo4bNhwberUqY2qFi9eMnDAwN59ehcrVgzFJOEFkPIQzy5n
PEiWc2AL28UQFuRDAQY7jqg/7KxOnoRTiwo4xyFnoQ2lC/W3Ugx5bCQbx40dg3UTksXqNjm+
Ghi8OAlJ4kER6M0eD60LHfAroCblmTRjtCDxdFi0cJFhQ6OtVwhTMkVMGsWLl6BtstzQZgd4
qN69WTUee/QxS4aW1i97vNB5vB7tJ6ysbqVKlbIAqWXta+/evXLnzq2ZWdKG/blkyZK0DA9I
/qsNGEYOj0JHTZ5C1I99e/hqd0fERQcvvqASPXEdxjl92nT6vP02DdPX2lHQUwb0lApqHtwr
dcN8ebJfzma8Xj17jB0zOrwnaK9Qu9yajbZodHQzWigwJ+t8zWrVAb5QFZ3Ei8EDUIt4EjmG
lxQ6oaAmqmY4s3XrKxbXcEwpgg+0ZcowK2T60yiNtosJ9YDVU958Dd2CUJIVjRo2omjZaFnR
O3ToWKhQIbApVGi9V9O4VKmS6DW6JCreesomqljRIqxEemCTJFHhpMlnazwiwyp0SyBJ+z2B
diSAzuG5Q4qHLHu8iPH2G3aFsMezKgm9o28XyC+uZy5IKv4sVbIUiZF6LVmHSZInip9iUbfO
0f7NBzbVGpekWkiaUfYE4yRfgSotYck8AH2VK1OO7AJ8hSZjLnYX4ExbNc8IrWpmPKOY+qAw
W3GaNW4irI51F9SOUs1oqWB14UKFCepXX32VZdhCCZ7qwWkxwLelS5acMSPCml6ezJY6qhzM
eKj21ddeQ0+BYmDWoxQpJ07s2LH9jTeiRADIl34Cx4iWvTZaH20zorC4CPjkKVMIIpEjYTqC
LXPH9h0Qj8G6Gc6Tb9Sz8NUL1qe/Wd6rbqNbZ35sooiUMKqQQGn16jWsKThWz4gG2jNE6MQS
ZpWvhpdCLicobzwHBuVyEQDMKoLiUGSgaY3Jeaq1Y3XJp02bTrsL9snsBBebUt8Kj+9XEl4k
m8gJC5PIJmZAV3GgGXMiJTws76idYWJn9ZMbKc4e1gVTDU1JPmahJLalCP4afzSz3oVY2PAh
vYULG6ox0DPtt6M68ps3G4ApJV1BQ4NETXowBpZbQXfhwe0bx0+YCIubOQ+bpk6dRp671/r1
68yJZchPOcF/npONKymJseL3Gn+SXVMqeDL8mqwxWX5KKCMxsaTSUyoqJfSTnbhDgo/TFBZG
kvIJYwsnU4+zf40vyoBrZHo6znVJ0ttZB5Y6pAyBlg3BmsxYlgFn0daS6T091TGiIPtjvtM8
pK7xqccZbJn5JKlskzxdWALOMXWnW0bzl0auZCfS9Jn0DKRnIEe7E876+s4qtc4io86mkATn
+RkyJEYYhjOpP1EUQuN3IqHkkosZZJo+P8QzkIP3eGd9K1QSWxf/zmHXOvrWW7bmGcn54n18
0FEDa7HCrX3+ed5bEKegv9m6MKPbAs6YPoPrwh4yoBbfifF0yJDDCmLbmJofNhmwQdrC2WVd
/sa3DzHpf7CPlrMZL2Xbdhqn//TTTwe7c8xOpzcGSWOmF5462MuQC1Azlr3Qnj2aoa9xo4YM
bsAuTI6YBO6EV4oFnJlUtGW3rl1eBLOMWSqDac/cQ+pHFgYG1WRfl+w6kjFI4yPj0OkGHywV
pO/+vs9ADma8iGdi0xk8brAQbHt1Gx/xsCFDnh78tLBxDm7cAZEo5Jm5TBuNiTt2wt17MN1e
TgXJMzmvubm279jBssdCPf+ZeTiNKRwaA8SRI5v7wWfylKmSJsGOuTDOWxzJPKZCljfH7nLo
8GEeYSbQ3Xt261b2LrbNKINDDBzzZsNcGwOMr6RMI4YNjwXv0Q8+19z7TnbpG+ZgxkOv0FLl
ypWHHfEiBw4YwIErzaOTeZ/IU7VqFeikyBfUrBlJVbx4cRlQgI/gvzZu2sixK5vlX2+9Fe+1
bNni9zf/XoIGPi7/eCCkypk4YeL9997L7ydjUpfOnSQO4Em//fbbpUtp2iTKJxkJq1P/ASuT
GdYRcJkERDxyNWrWBONgKBejoPOKFStyeERcFzOexpzCXTp37t2zl5Qt0Plc2AaZ1jk/aqyY
UxnPuNHrUwUKBlAIoAmpFXLxQ7s3b9rMDqxSpUpbt2yRlgfWkRe7dKmSXNIA7zKIyP8FMMX3
ChIpb7E2OpHoVnJleaxs88TCgXqSk9WqVMVpoDAEY+sYnl+2dGnJ0oOWSAWV/8cBNNOi2Fk8
Y9p0OZdopFHeruPHuKrlUwqN9QBXEVUFOHUK0AMUAwBaqiwyMGwm05+PzgzkVMYLMoQjWDiJ
FNHgVLBUgb4BxKLceBE8ql4E4GzcGD6LqQOhO1mhbNk5c2djHjpnzHivUB2rx4xH3EmJi9Pk
gcM2sqqCwsAHSwoowSOAYuu4BwBrGXXCvcSqdI0DYVq3ar1s6VLgKeBdQa7u2L5dlBxaQthp
U6P86j4ghe3btAnHVocA/JXzC8Y6zXgfHZYLT5qDGS+ghwkxsEOSqnSJkiG3PugwQL0DYGWM
B7m7dPESMqpl8xYeWA5Glkk4SRfWrVP3tde22+5RQbUXgikAh2pKTI0fO44SmPeJJwCa2rRt
K/BHviqRYJrhyZUrngvTh/F0G/FzhQoyTwtKCGhMEq91XIRAHjuBambZjhRqXjhpcN9rKSWZ
A7E/bLBpxkszHvDTtddee8Wtt96KQMPyHD6X1T7EYEDpJaWVLBkKmdTq2LEjbbN71279+/WX
MNOAYflBpaLkykuXCleV6hz1V6lUUeQBqcX0Iic09K3AH8hJqGKX4C6cIMEjeKRiA5C44FGY
Z+zo0WvWrpXpmX1EgmqAr9mz59jgMZPA4LvR3XfdBbIklTpjZteu3aZOnRKCaOSulKFdRoOn
nx7CCkqiijETmtCrZ69JEybojVjmV0gzXprxcgbjeU+AjIIjxYABXkbrwslTjPhEDd8A6HME
vNyxg1gTSCLOUkESRkvbQtZOqHzmRJdjV1vEkLpD5E6IA1Aoz0n7QDGjYbkRJKql9ObYLAKI
viqkJToOFWrs0BYtWoh7FZojHl24YOFCv8aZRU6wrEBy+mzdGoEYiTtgaE5C5wUZgTtu377D
lvKjRnbp583BqqaXl0jj+PgMGGL4NXm8VIdbuCq5PGkTqCGLkE8AK2d12WVpn3ptfIvTSbJS
73jmsC8vVSLNEu/PDORsxnt/5ih9l/QMXPIZyMGMd56wzOxTFm9YMyK7L4eNaxCA7wRAy/KY
voZ3ltRDPjtNnAk6Df0HFeCsKNN33WSee5CXnC4/9B3mYMbzbpYtWy6vUcI8iQUoOcj+/jQW
GGoPFkfuvR6Fk3+gL9l4hNvZN77TKGBKhYTbpkaPGYO2wWVgYqK0lpkg7ezP66HUalQ55OWX
N6uywJcYb1Zfj/JhZkOZAuLYKvOvvNMy5LxtsL1uFi39A525nH3zHMx4iKBZ0yZRfoTMj/JU
IcW/g7h2+elPwJSFp4XknD51GmMMt4GkfdH5zEC7ZDoyY/ZOB3R7zxmiJlPmRMaSk6nZrDM2
mUnLhEwDh5y5zTu9I+W3UEU5yOHTci8TZcrkw7UYJeTL3JfCo6m5lfp0MppED5gZER9+4tnv
3r0HV6dEZkp/GKp8M+r1hV8Dj4Vj7scK5cpivDNHmHoHNdNHuC87kDXLD2pNhoLVOZv8P7jR
52zGU3VNcishycePvQ2DIv+U5Hxy4xQvXkzCPLZEpsXVa9ZESTgkxoyqdUcVt9XiYsEXcCAB
GQKKQJfHjqmJB4epJDrz4yG5igUl7NoVYTJPnFAfWGQ6OSFHy062yrhouISqfnIlAlabJi5D
o0TOZoPRj58UFla7izMd54SMmu7omKFVOjC5H6XE4pZg3pT1QGIyFxJlADeJjUeGwlWrVovp
VoKPTz+OSY9YRfrAkOCAT9+v7iKdCd8GDKrjUAuJKVU6CZnzpE6RlcSA9+7Z7Xk5UdTc4TUJ
1SfNlXEaAyeK3oTnO3mQBfiNndJym65169dp76TBw52q1KM3hm+w1aefHhzVOr8Myhp/cOxz
4XfO2YwHrSIBifLWXTt3ARC55Za/cLUpaHjLLbeEBGFAm9Wj/MT1uRMgUVCpnLZ8dzhBklaV
2WSMlRcE/cFh+lUmr/vuuUeZO7Qr8xxwCWkg52yUDnDrVkWbpd9CjqNHjxoSZ/gy8T169ChX
tpwkKMDZfHTWAv4JiLCyZctyl1euVNG9otSA+/Yjbn6IRQsXkFdr1z7fpGkT2VflIDEGGACZ
nsmoqHH8oXzCl0n1JSFn+bJlIcsgUSdMGO8nydQsHIBplStXIb2hdv7yl7/ECQ5fhBZQh10e
Md6RO+64Q+Yy2ZnuvfdeTPXs0iUywEoPY7TyC4HLSFgGOOrCjRvWgwpUr1ZdAb1Vq1YpQKmu
rdybUVKTOnXAXC09JnbihPGm4p577sH55kHVctrs5bBJvnDy/+CufEfGy58/P8JN1TYutyk2
NimGZJImpmhTXG1y/vB3m0y5vgkjnAZvqZmVfuHCRSFXCroPBcf9BNglozMyIhlyP/jgnNmz
nh48qG3r1nLOyeEhPzSwGFHTplWrXj16Eq0YMs9jjxFTZGZAqBBxvPa41LF0Q/37RlXCBeMp
m4r96GalS5biMDR1SjHjH7FIdlM6DBMLU0ogG4l8hFguPEX4SUag4XFwEymsN6kyn3/hBWxg
n+avx1RqPGR0pWRKOEsiEbkyqamjkC9PHntXEDlZUlaufE6dR8147WU3mjZlqjLikXq5b7+R
h6TLBw7sl2aTDJ8xY6YM0PJhmgQ7OreQH0ViMnVhZROcOWM6AFDPnlFv1jWLVFrVvGDOzc54
NKCbbrrpiqpVqwL+XuaMR7ysWPEcCIsCvDRJ9U0RLoUQWIwWJKnrvLlzPYJ4BVlxwrMIsSPi
qIING9SXT5LWhIvgXYQSYUiJruCtmzRuBEs5eOBAVYXJrihT6vLl7dq0AcvEWoIhZJgO2fIk
DnJ56Pm1ba/Cdnbu2Im0UcnZmTgZbv0AZONFV80U89t0yfnpDFEmJ6SD9u3bcf1TFKFqMG3o
DbmHxKwYT0QFvVcaNfEWBq9SsfNMMmQUw4m9Wf26Uf4yCq+MmrVq1yarqakGuWH9Biq3NOna
k2x8/ThfAV05wmTgVrs43ItOThrj/HnPPEMaW18sBDLf1qsjT/spD+i83mbNmCFTU7euUW8k
/JLFZ2S/vmAS/GhemJ3xFLumpFwhg2/RokUvc8aT2hUpSAlesVx52zDYMcv2kbeOUNuwnxgc
ATgegUBApgwDTtLTGFRgo6mp2M+mS+o7mqS48pLFi8u3aeNmyS+YL7/U1IhVSnBKJjYr/ORT
UgOKbn/iscfJKM1syeS9kkIzlCUI9nr64fBhQ/2VcJrEK1tabfG3jTBUAnCJVJz6sUwApilR
4BKiiXFFmrAKRNCu3YapK3FG3bp09atr6caGR+IRxX169ZZkNrw2m668efJs2fKyXK6ygHk0
WDn1ekg8GjV0uASb4pjIbUH0+EfPAZ0zsP8AS0OZ0qVkE/NVOQcrl9mZPWumNcjKMmTQYJEZ
AjU8ZqMG9a1fJJ7UzoI8BF65pEXLlhL+Ofhoss3FP3V2xgscd0VAjl3mjCcv+nPLlrEcEHFY
TpSd1OLibiz79jlq7lj7baLwGIrv1bM3/VBouaXdvmh4DKSOFu+2bUNx+qqVq7ZqFSGbyTGp
pnUrSK9gwYKRyDp1Cn+iYDOO1iWTtSHs3iNKV96vbx85p7Foz+7dataoKREtD4fErOqJlyhW
nJa4bes2iE28JOxdks98efJaDkaNGvXE4483btzIMCSEJPEwHouFyKahQ4fRgXfu3GV7ZgXB
xpLwYlTWlyaNGotdAlUjOYkgkRlgop6XJJRJmtosV6xtWMECBUl+T6rAyNKlz9oysP2SY0aL
c+gyZUqXkb1X2maZKsUZCi+kJ9u7UoNpBzQFYVDuiJNZj9q0aknM6g3oVLSUxzd7xi+TvI3i
5bYBuXiWeH96yM54xB2hd4WXdPPNN1svE9673KYYKdOR6E5WcTF1NnUkwPoNG3x1nkyzq0G1
dkchpSSDJFMe6cQJwOgXWeTi2CI2TFXv4t4OImL9RKa/3XvYF0kbPUdugxMnXCjVioOouDYi
PfLWGzsjNKb5YZthtECpLIohyTnepvup0SF1vN5wkZa4RVJkmzSWHssERlq1ehWZaTCYnPSL
IKbHjslFaYemE4MJedfd2rVUSrfWf1zL6Di9kYWGePdePDg902aS0SXq8ODBuKzfgWich9/y
q0+cJ+aE/wkLJMPDa2Ud4WkwFXL1unVczTxqSWzqwSDdSD+GZ0rDjLH6CunwK65Oavq9P8T6
YbpLFsbzpq666ip/I8aTzJxp7rJlvGBbT/xRiVcqOWC0nD49Y2uXnAzaUXioxHCf5WSYlHM3
S9pkX7pwvs1bq1atK1aoGDaZqb2lKhFZ5jal2RkJocP55Eapw07tOXUkyeSkOvdSM9CkdpLl
eVMHnDEJmR7CZE6yDObDxBLvz7NkIZuE1yLGw3+0TRj/8CYuN4l37gkK/rdIvr2/nyj38/Hj
FHVxQ2SCeSNC3wXe9f6OMH23y2EGUhkvldEixvMRrHnfffflUMYLw34nDOR/a/ZjKGQiyoKa
+n6P4b/1bOl+L9kMpDJeqmqZwXgIiKWFvSXHSbxLNkPpjtIz8F+YgYTxmFEEnYeqmj6nGc8p
9pYs0ehn3aikT6ZnID0D72kGbEmYMJPd3BmM5wvrlp8lin1PnaYbp2cgPQPnmAGyDlvhvdQ2
pyVeOEvuPfLII1xAmDA9m+kZSM/AxcwAbrKvo2GmyrqsqmbqDYDI2Dldk2a/i5n39LUf5RmA
Z7jxxhs56pJ93bkkXvIblnMNZx9rJ6OLvR8P7Ed5HtPPnp6Bc89A7FuabadGZ7zyyiuFH2RR
L8+L8ZJGPA0MnsQl9lXqPv1Jz0B6Bs46A5REbILr8N5ZpVwq4/1/9BckHFTJneYAAAAASUVO
RK5CYII=
--------------010205090606080907080107--

--------------090205000708090207080204--

From trac+core@trac.tools.ietf.org  Thu Oct 10 08:41:24 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1C611E81DF for ; Thu, 10 Oct 2013 08:41:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.556
X-Spam-Level: 
X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSnr0V1JRPVT for ; Thu, 10 Oct 2013 08:41:23 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 3FCA321E808A for ; Thu, 10 Oct 2013 08:41:15 -0700 (PDT)
Received: from localhost ([127.0.0.1]:60021 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VUIMG-0006uG-Ge; Thu, 10 Oct 2013 17:41:00 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "core issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com
X-Trac-Project: core
Date: Thu, 10 Oct 2013 15:41:00 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/348
Message-ID: <060.11bf40787a78f9c198b5bb06d1ac519e@trac.tools.ietf.org>
X-Trac-Ticket-ID: 348
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: akbar.rahman@interdigital.com, angelo@castellani.net, esko.dijk@philips.com, salvatore.loreto@ericsson.com, tho@koanlogic.com
Resent-Message-Id: <20131010154116.3FCA321E808A@ietfa.amsl.com>
Resent-Date: Thu, 10 Oct 2013 08:41:15 -0700 (PDT)
Resent-From: trac+core@trac.tools.ietf.org
Cc: core@ietf.org
Subject: [core] #348: Corrections to URI template for default http-coap URI mapping
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: trac+core@trac.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Oct 2013 15:41:24 -0000

#348: Corrections to URI template for default http-coap URI mapping

 Corrections to URI template for default http-coap URI mapping required:
 current proposal in [1513] leaves some ambiguity.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-core-http-
  esko.dijk@philips.com  |  mapping@tools.ietf.org
     Type:  protocol     |     Status:  new
  defect                 |  Milestone:
 Priority:  major        |    Version:
Component:  http-        |   Keywords:
  mapping                |
 Severity:  -            |
-------------------------+-------------------------------------------------

Ticket URL: 
core 


From Akbar.Rahman@InterDigital.com  Thu Oct 10 20:39:17 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2FAA21F9339 for ; Thu, 10 Oct 2013 20:39:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.596
X-Spam-Level: 
X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.003,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhZtCZ9eRW3z for ; Thu, 10 Oct 2013 20:39:13 -0700 (PDT)
Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8669821F93FB for ; Thu, 10 Oct 2013 20:39:13 -0700 (PDT)
Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 10 Oct 2013 23:39:12 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Date: Thu, 10 Oct 2013 23:39:05 -0400
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: New Version Notification for draft-rahman-core-sleepy-nodes-do-we-need-00.txt
Thread-Index: Ac7GMr8zNyxAslFmQl6t9qCTzAWmpwAAAzXw
From: "Rahman, Akbar" 
To: "Carsten Bormann" , 
X-OriginalArrivalTime: 11 Oct 2013 03:39:12.0839 (UTC) FILETIME=[73C73570:01CEC633]
Subject: [core] FW: New Version Notification for draft-rahman-core-sleepy-nodes-do-we-need-00.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Oct 2013 03:39:17 -0000

SGkgQ2Fyc3RlbiAoYW5kIFdHKSwNCg0KDQpJIHdyb3RlIGEgc2hvcnQgZHJhZnQgYmFzZWQgb24g
dGhlIGZvbGxvd2luZyBxdWVzdGlvbiBmcm9tIElFVEYtODcgKEJlcmxpbik6DQoNCgkiU2hvdWxk
IHdlIGhhdmUgYSBDT1JFIGRlbGl2ZXJhYmxlIGZvciBDb0FQIHN1cHBvcnQgb2YgU2xlZXB5IE5v
ZGVzPyINCg0KCWh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9jb3JlL2N1cnJl
bnQvbXNnMDQ3NTAuaHRtbA0KDQoNCg0KQW55IGFuZCBhbGwgY29tbWVudHMgd2lsbCBiZSBtdWNo
IGFwcHJlY2lhdGVkLg0KDQoNCg0KQWtiYXINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N
CkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0Bp
ZXRmLm9yZ10gDQpTZW50OiBUaHVyc2RheSwgT2N0b2JlciAxMCwgMjAxMyAxMTozNCBQTQ0KVG86
IFJhaG1hbiwgQWtiYXI7IFJhaG1hbiwgQWtiYXINClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlm
aWNhdGlvbiBmb3JkcmFmdC1yYWhtYW4tY29yZS1zbGVlcHktbm9kZXMtZG8td2UtbmVlZC0wMC50
eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtcmFobWFuLWNvcmUtc2xlZXB5LW5v
ZGVzLWRvLXdlLW5lZWQtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5
IEFrYmFyIFJhaG1hbiBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVu
YW1lOgkgZHJhZnQtcmFobWFuLWNvcmUtc2xlZXB5LW5vZGVzLWRvLXdlLW5lZWQNClJldmlzaW9u
OgkgMDANClRpdGxlOgkJIFNsZWVweSBEZXZpY2VzOiBEbyB3ZSBuZWVkIHRvIFN1cHBvcnQgdGhl
bSBpbiBDT1JFPw0KQ3JlYXRpb24gZGF0ZToJIDIwMTMtMTAtMTENCkdyb3VwOgkJIEluZGl2aWR1
YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiA2DQpVUkw6ICAgICAgICAgICAgIGh0dHA6
Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXJhaG1hbi1jb3JlLXNsZWVweS1u
b2Rlcy1kby13ZS1uZWVkLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNr
ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJhaG1hbi1jb3JlLXNsZWVweS1ub2Rlcy1kby13ZS1uZWVk
DQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJhaG1h
bi1jb3JlLXNsZWVweS1ub2Rlcy1kby13ZS1uZWVkLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUaGlz
IGRvY3VtZW50IHN1bW1hcml6ZXMgdGhlIGRpc2N1c3Npb24gaW4gdGhlIENPUkUgV0cgcmVsYXRl
ZCB0byB0aGUNCiAgIHF1ZXN0aW9uIG9mIHdoZXRoZXIgc3VwcG9ydCBvZiBzbGVlcHkgZGV2aWNl
cyBpcyByZXF1aXJlZCBmb3IgdGhlDQogICBDb0FQIHByb3RvY29sLCBDT1JFIExpbmsgRm9ybWF0
LCBDT1JFIFJlc291cmNlIERpcmVjdG9yeSwgZXRjLiAgVGhlDQogICBvbmx5IGdvYWwgb2YgdGhp
cyBkb2N1bWVudCBpcyB0byB0cmlnZ2VyIGRpc2N1c3Npb25zIGluIHRoZSBDT1JFIFdHDQogICBz
byB0aGF0IGFsbCByZWxldmFudCBjb25zaWRlcmF0aW9ucyBmb3Igc2xlZXBpbmcgZGV2aWNlcyBh
cmUgdGFrZW4NCiAgIGludG8gYWNjb3VudC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0K
DQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9t
IHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRp
ZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJp
YXQNCg0K

From weigengyu@bupt.edu.cn  Thu Oct 10 23:26:53 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F3E11E8123 for ; Thu, 10 Oct 2013 23:26:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aAYLB8Kf9jK for ; Thu, 10 Oct 2013 23:26:49 -0700 (PDT)
Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id A978911E8131 for ; Thu, 10 Oct 2013 23:26:45 -0700 (PDT)
Received: from WeiGengyuPC (unknown [10.103.241.46]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id BDEDC19F3AE; Fri, 11 Oct 2013 14:26:41 +0800 (HKT)
Message-ID: 
From: "weigengyu" 
To: "Rahman, Akbar" 
References: 
In-Reply-To: 
Date: Fri, 11 Oct 2013 14:26:40 +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 fordraft-rahman-core-sleepy-nodes-do-we-need-00.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Oct 2013 06:26:53 -0000

Hi, Rahman,

My answer the question "Should we have a CORE deliverable for CoAP support 
of Sleepy Nodes?" is YES.

But I have some questions about the use cases.
According to "Sleepy Devices using CoAP - Requirements 
draft-dijk-core-sleepy-reqs-00"
the definitin of Sleeping/Asleep as following:
   Sleeping/Asleep  : A SEP being in a "sleeping state" i.e. its network 
interface is disconnected and a SEP is not able to send or receive messages.
So, a sleepy node should not start to communicate with other nodes.  The 
communication between sleepy nodes is not possible, that is given in 
"Problem statement and Use cases of Sleepy node in Constrained node networks 
draft-hong-lwig-sleepynode-problem-statement-00"

When a node is in sleeping state, it can receive, but it cannot send.
The sleeping node can be waken-up by a received message or timer expired 
event; therefore the node turns to be awake.
An alarming message may cause the sleepy node awake and then to give 
response.
The timer expired event may cause  the sleepy node awake and then to send 
heartbeat.
A node can send a message out only when it is awake.

Afterall, it is possible that the non-sleep node  initiates communication 
with a sleepy node. The sleep node is passive.
If the node in sleepy state wants to respond the message, it firstly turns 
to awake state.

regards,

Gengyu


-----原始邮件----- 
From: Rahman, Akbar
Sent: Friday, October 11, 2013 11:39 AM
To: Carsten Bormann ; core@ietf.org
Subject: [core] FW: New Version Notification 
fordraft-rahman-core-sleepy-nodes-do-we-need-00.txt

Hi Carsten (and WG),


I wrote a short draft based on the following question from IETF-87 (Berlin):

"Should we have a CORE deliverable for CoAP support of Sleepy Nodes?"

http://www.ietf.org/mail-archive/web/core/current/msg04750.html



Any and all comments will be much appreciated.



Akbar

-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Thursday, October 10, 2013 11:34 PM
To: Rahman, Akbar; Rahman, Akbar
Subject: New Version Notification 
fordraft-rahman-core-sleepy-nodes-do-we-need-00.txt


A new version of I-D, draft-rahman-core-sleepy-nodes-do-we-need-00.txt
has been successfully submitted by Akbar Rahman and posted to the IETF 
repository.

Filename: draft-rahman-core-sleepy-nodes-do-we-need
Revision: 00
Title: Sleepy Devices: Do we need to Support them in CORE?
Creation date: 2013-10-11
Group: Individual Submission
Number of pages: 6
URL: 
http://www.ietf.org/internet-drafts/draft-rahman-core-sleepy-nodes-do-we-need-00.txt
Status: 
http://datatracker.ietf.org/doc/draft-rahman-core-sleepy-nodes-do-we-need
Htmlized: 
http://tools.ietf.org/html/draft-rahman-core-sleepy-nodes-do-we-need-00


Abstract:
   This document summarizes the discussion in the CORE WG related to the
   question of whether support of sleepy devices is required for the
   CoAP protocol, CORE Link Format, CORE Resource Directory, etc.  The
   only goal of this document is to trigger discussions in the CORE WG
   so that all relevant considerations for sleeping devices are taken
   into account.




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 tho@koanlogic.com  Thu Oct 10 23:48:49 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F3A21E80A1 for ; Thu, 10 Oct 2013 23:48:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NsIBvyRY3crq for ; Thu, 10 Oct 2013 23:48:44 -0700 (PDT)
Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7227811E8123 for ; Thu, 10 Oct 2013 23:48:40 -0700 (PDT)
Received: by mail-lb0-f170.google.com with SMTP id w7so2996507lbi.15 for ; Thu, 10 Oct 2013 23:48:40 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1yS4lmeYlSUVEHHQnZ16OBGrpylucwcrNIrsbYInnY4=; b=Q+yw0fNgsEgPWeDRFCecbCNcyZJI2gyZam7u/iDGV+6dsEBnm4CUbDKK64cp/SZwTL ylsAiufh6KPTsjg/Yiub0PGYbP71ZJjXbbZGD0ZVnqpIivDCfWxuaED2JPHpy/8CtowJ mFC2PPGWuVmmrQMQLx8iFydjnjrgjMr4taq+uP8FTdwrSqWnsBB7XEkox7LJm+req3UW jGKGbKpnhzpcGUqiocXrOJHj9K/VbzdLizNv8jKMnq3VF+RjmjPJfIOqOQccok768lBA Ev35bMVnZOFQYyLxj4cVGzU3gCPru9MjSEm4wK/U5LB61G5SFgSvjrqYbBltS5ZqBoo/ sC5w==
X-Gm-Message-State: ALoCoQlm61cQKxLotNa2vD4ZW0XsR04RIry48gDtV5JaE0zPSqB8ZwU4ND4/r1MWOiVIqECbTHZ9
MIME-Version: 1.0
X-Received: by 10.112.14.3 with SMTP id l3mr15251044lbc.27.1381474119964; Thu, 10 Oct 2013 23:48:39 -0700 (PDT)
Received: by 10.114.21.4 with HTTP; Thu, 10 Oct 2013 23:48:39 -0700 (PDT)
X-Originating-IP: [92.16.149.95]
In-Reply-To: 
References: 
Date: Fri, 11 Oct 2013 07:48:39 +0100
Message-ID: 
From: Thomas Fossati 
To: "Rahman, Akbar" 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "core@ietf.org" 
Subject: Re: [core] FW: New Version Notification for draft-rahman-core-sleepy-nodes-do-we-need-00.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Oct 2013 06:48:49 -0000

Hi Akbar, thank you very much for this.

I think you are providing a really good service to the working group
in keeping the background discussion on this important topic alive.

Personally, I think that providing a set of in-protocol mechanisms (a
bunch of Options, basically) to tackle well known and understood
scenarios (as opposed to a fully fledged architecture to support
Sleepy nodes, which other SDOs are in a better position to provide) is
something that is perfectly in scope with CoAP goals and WG interest
and energy  -- as you sensed it back in August.

And yes, I'd have given you my +1 when you polled the mailing list
about this, if I weren't on holiday :-)

Cheers

On Fri, Oct 11, 2013 at 4:39 AM, Rahman, Akbar
 wrote:
> Hi Carsten (and WG),
>
>
> I wrote a short draft based on the following question from IETF-87 (Berlin):
>
>         "Should we have a CORE deliverable for CoAP support of Sleepy Nodes?"
>
>         http://www.ietf.org/mail-archive/web/core/current/msg04750.html
>
>
>
> Any and all comments will be much appreciated.
>
>
>
> Akbar
>
> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> Sent: Thursday, October 10, 2013 11:34 PM
> To: Rahman, Akbar; Rahman, Akbar
> Subject: New Version Notification fordraft-rahman-core-sleepy-nodes-do-we-need-00.txt
>
>
> A new version of I-D, draft-rahman-core-sleepy-nodes-do-we-need-00.txt
> has been successfully submitted by Akbar Rahman and posted to the IETF repository.
>
> Filename:        draft-rahman-core-sleepy-nodes-do-we-need
> Revision:        00
> Title:           Sleepy Devices: Do we need to Support them in CORE?
> Creation date:   2013-10-11
> Group:           Individual Submission
> Number of pages: 6
> URL:             http://www.ietf.org/internet-drafts/draft-rahman-core-sleepy-nodes-do-we-need-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-rahman-core-sleepy-nodes-do-we-need
> Htmlized:        http://tools.ietf.org/html/draft-rahman-core-sleepy-nodes-do-we-need-00
>
>
> Abstract:
>    This document summarizes the discussion in the CORE WG related to the
>    question of whether support of sleepy devices is required for the
>    CoAP protocol, CORE Link Format, CORE Resource Directory, etc.  The
>    only goal of this document is to trigger discussions in the CORE WG
>    so that all relevant considerations for sleeping devices are taken
>    into account.
>
>
>
>
> 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 trac+core@trac.tools.ietf.org  Fri Oct 11 01:19:34 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94CD721F9CB0 for ; Fri, 11 Oct 2013 01:19:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.562
X-Spam-Level: 
X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otFW8cxSyvT7 for ; Fri, 11 Oct 2013 01:19:34 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 1046E21F90A7 for ; Fri, 11 Oct 2013 01:19:33 -0700 (PDT)
Received: from localhost ([127.0.0.1]:46554 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VUXwV-0005iJ-2o; Fri, 11 Oct 2013 10:19:27 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "core issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com
X-Trac-Project: core
Date: Fri, 11 Oct 2013 08:19:27 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/348#comment:1
Message-ID: <075.a8539bbe966bcf2d2fb8f4bbd8ea79fd@trac.tools.ietf.org>
References: <060.11bf40787a78f9c198b5bb06d1ac519e@trac.tools.ietf.org>
X-Trac-Ticket-ID: 348
In-Reply-To: <060.11bf40787a78f9c198b5bb06d1ac519e@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: akbar.rahman@interdigital.com, angelo@castellani.net, esko.dijk@philips.com, salvatore.loreto@ericsson.com, tho@koanlogic.com
Resent-Message-Id: <20131011081934.1046E21F90A7@ietfa.amsl.com>
Resent-Date: Fri, 11 Oct 2013 01:19:33 -0700 (PDT)
Resent-From: trac+core@trac.tools.ietf.org
Cc: core@ietf.org
Subject: Re: [core] #348: Corrections to URI template for default http-coap URI mapping
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: trac+core@trac.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Oct 2013 08:19:34 -0000

#348: Corrections to URI template for default http-coap URI mapping

Changes (by esko.dijk@philips.com):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Fixed in [1514].

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-http-
  esko.dijk@philips.com  |  mapping@tools.ietf.org
     Type:  protocol     |      Status:  closed
  defect                 |   Milestone:
 Priority:  major        |     Version:
Component:  http-        |  Resolution:  fixed
  mapping                |
 Severity:  -            |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
core 


From trac+core@trac.tools.ietf.org  Fri Oct 11 01:32:58 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E06D221F9D23 for ; Fri, 11 Oct 2013 01:32:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.566
X-Spam-Level: 
X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltt7zNjzJojH for ; Fri, 11 Oct 2013 01:32:58 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 83AD021F9CA5 for ; Fri, 11 Oct 2013 01:32:51 -0700 (PDT)
Received: from localhost ([127.0.0.1]:47599 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VUY9L-0004L4-H9; Fri, 11 Oct 2013 10:32:43 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "core issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com
X-Trac-Project: core
Date: Fri, 11 Oct 2013 08:32:43 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/346#comment:2
Message-ID: <075.f37363dc4fde73b9ce766a0d6e32f78a@trac.tools.ietf.org>
References: <060.3b4321d40c10aa360522a7791cb8644c@trac.tools.ietf.org>
X-Trac-Ticket-ID: 346
In-Reply-To: <060.3b4321d40c10aa360522a7791cb8644c@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: akbar.rahman@interdigital.com, angelo@castellani.net, esko.dijk@philips.com, salvatore.loreto@ericsson.com, tho@koanlogic.com
Resent-Message-Id: <20131011083252.83AD021F9CA5@ietfa.amsl.com>
Resent-Date: Fri, 11 Oct 2013 01:32:51 -0700 (PDT)
Resent-From: trac+core@trac.tools.ietf.org
Cc: core@ietf.org
Subject: Re: [core] #346: Select solution for default HTTP-CoAP URI mapping
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: trac+core@trac.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Oct 2013 08:32:59 -0000

#346: Select solution for default HTTP-CoAP URI mapping

Changes (by esko.dijk@philips.com):

 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 After some discussion among the authors, a slight modification to the
 solution is proposed where it becomes possible to -in many cases- simply
 append the CoAP URI to a base HTTP URI part. Example; HC proxy origin and
 proxy base resource is:
   http://proxy.example.com/.well-known/core/

 CoAP URI to access is:
   coap://coapserv.example.com/foo/bar?a=3

 Full URI to request proxy to perform that coap request is obtained by just
 appending the 2nd to the 1st URI:
   http://proxy.example.com/.well-
 known/core/coap://coapserv.example.com/foo/bar?a=3

 only if IP-literals are used, the '[' and ']' in the CoAP URI authority
 need to be percent-encoded before appending.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-http-
  esko.dijk@philips.com  |  mapping@tools.ietf.org
     Type:  task         |      Status:  reopened
 Priority:  major        |   Milestone:
Component:  http-        |     Version:
  mapping                |  Resolution:
 Severity:  -            |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
core 


From esko.dijk@philips.com  Fri Oct 11 01:48:53 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81F1021E80D4 for ; Fri, 11 Oct 2013 01:48:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.533
X-Spam-Level: 
X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9VIJeaZ8Q4Ao for ; Fri, 11 Oct 2013 01:48:48 -0700 (PDT)
Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0185.outbound.messaging.microsoft.com [213.199.154.185]) by ietfa.amsl.com (Postfix) with ESMTP id D6EE121E80C1 for ; Fri, 11 Oct 2013 01:48:41 -0700 (PDT)
Received: from mail214-db8-R.bigfish.com (10.174.8.252) by DB8EHSOBE018.bigfish.com (10.174.4.81) with Microsoft SMTP Server id 14.1.225.22; Fri, 11 Oct 2013 08:48:40 +0000
Received: from mail214-db8 (localhost [127.0.0.1])	by mail214-db8-R.bigfish.com (Postfix) with ESMTP id D92C814035C; Fri, 11 Oct 2013 08:48:40 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI
X-SpamScore: -35
X-BigFish: VPS-35(zz217bI98dI15d6O9371I936eI542I1432I1418I11f6N9251I168aJdd85kzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de097h186068h8275bh8275dhz2dh2a8h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2184m1155h)
Received: from mail214-db8 (localhost.localdomain [127.0.0.1]) by mail214-db8 (MessageSwitch) id 1381481285572320_24972; Fri, 11 Oct 2013 08:48:05 +0000 (UTC)
Received: from DB8EHSMHS002.bigfish.com (unknown [10.174.8.236])	by mail214-db8.bigfish.com (Postfix) with ESMTP id 80B0E240238; Fri, 11 Oct 2013 08:48:05 +0000 (UTC)
Received: from mail.philips.com (157.55.7.222) by DB8EHSMHS002.bigfish.com (10.174.4.12) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 11 Oct 2013 08:48:05 +0000
Received: from 011-DB3MPN2-081.MGDPHG.emi.philips.com ([169.254.1.172]) by 011-DB3MMR1-002.MGDPHG.emi.philips.com ([10.128.28.52]) with mapi id 14.03.0146.002; Fri, 11 Oct 2013 08:48:04 +0000
From: "Dijk, Esko" 
To: Thomas Fossati , "Rahman, Akbar" 
Thread-Topic: [core] FW: New Version Notification for draft-rahman-core-sleepy-nodes-do-we-need-00.txt
Thread-Index: Ac7GMr8zNyxAslFmQl6t9qCTzAWmpwAAAzXwAAbHoIAAA+9dcA==
Date: Fri, 11 Oct 2013 08:48:04 +0000
Message-ID: <031DD135F9160444ABBE3B0C36CED618016F59E5@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: [83.85.136.144]
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%
X-FOPE-CONNECTOR: Id%0$Dn%INTERDIGITAL.COM$RO%1$TLS%0$FQDN%$TlsDn%
Cc: "core@ietf.org" 
Subject: Re: [core] FW: New Version Notification for	draft-rahman-core-sleepy-nodes-do-we-need-00.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Oct 2013 08:48:53 -0000

 >         "Should we have a CORE deliverable for CoAP support of Sleepy No=
des?"
Yes!  (motivation: existing WG documents do not provide the complete soluti=
on yet that is required at CoAP level)

> of in-protocol mechanisms (a bunch of Options, basically)
I don't fully agree; it could be one or more options that are needed; it co=
uld be perhaps done without new options.
The thing that is needed at least, in my opinion, is functionality like [I-=
D.vial-core-mirror-server].  (If needed I can motivate this further on the =
list with use cases.)

> (as opposed to a fully fledged architecture to support Sleepy nodes, whic=
h other SDOs are in a better position to provide)
Agree. I see mirror server as an example of a useful/required component, bu=
t it is not a full architecture yet. But any CoRE defined 'building block' =
should fit in such architectures.

Esko

-----Original Message-----
From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Tho=
mas Fossati
Sent: Friday, October 11, 2013 08:49
To: Rahman, Akbar
Cc: core@ietf.org
Subject: Re: [core] FW: New Version Notification for draft-rahman-core-slee=
py-nodes-do-we-need-00.txt

Hi Akbar, thank you very much for this.

I think you are providing a really good service to the working group in kee=
ping the background discussion on this important topic alive.

Personally, I think that providing a set of in-protocol mechanisms (a bunch=
 of Options, basically) to tackle well known and understood scenarios (as o=
pposed to a fully fledged architecture to support Sleepy nodes, which other=
 SDOs are in a better position to provide) is something that is perfectly i=
n scope with CoAP goals and WG interest and energy  -- as you sensed it bac=
k in August.

And yes, I'd have given you my +1 when you polled the mailing list about th=
is, if I weren't on holiday :-)

Cheers

On Fri, Oct 11, 2013 at 4:39 AM, Rahman, Akbar  wrote:
> Hi Carsten (and WG),
>
>
> I wrote a short draft based on the following question from IETF-87 (Berli=
n):
>
>         "Should we have a CORE deliverable for CoAP support of Sleepy Nod=
es?"
>
>
> http://www.ietf.org/mail-archive/web/core/current/msg04750.html
>
>
>
> Any and all comments will be much appreciated.
>
>
>
> Akbar
>
> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> Sent: Thursday, October 10, 2013 11:34 PM
> To: Rahman, Akbar; Rahman, Akbar
> Subject: New Version Notification
> fordraft-rahman-core-sleepy-nodes-do-we-need-00.txt
>
>
> A new version of I-D, draft-rahman-core-sleepy-nodes-do-we-need-00.txt
> has been successfully submitted by Akbar Rahman and posted to the IETF re=
pository.
>
> Filename:        draft-rahman-core-sleepy-nodes-do-we-need
> Revision:        00
> Title:           Sleepy Devices: Do we need to Support them in CORE?
> Creation date:   2013-10-11
> Group:           Individual Submission
> Number of pages: 6
> URL:             http://www.ietf.org/internet-drafts/draft-rahman-core-sl=
eepy-nodes-do-we-need-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-rahman-core-sleepy=
-nodes-do-we-need
> Htmlized:        http://tools.ietf.org/html/draft-rahman-core-sleepy-node=
s-do-we-need-00
>
>
> Abstract:
>    This document summarizes the discussion in the CORE WG related to the
>    question of whether support of sleepy devices is required for the
>    CoAP protocol, CORE Link Format, CORE Resource Directory, etc.  The
>    only goal of this document is to trigger discussions in the CORE WG
>    so that all relevant considerations for sleeping devices are taken
>    into account.
>
>
>
>
> Please note that it may take a couple of minutes from the time of submiss=
ion until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

________________________________
The information contained in this message may be confidential and legally p=
rotected under applicable law. The message is intended solely for the addre=
ssee(s). If you are not the intended recipient, you are hereby notified tha=
t any use, forwarding, dissemination, or reproduction of this message is st=
rictly prohibited and may be unlawful. If you are not the intended recipien=
t, please contact the sender by return e-mail and destroy all copies of the=
 original message.


From trac+core@trac.tools.ietf.org  Fri Oct 11 02:22:34 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82F0A21F9A70 for ; Fri, 11 Oct 2013 02:22:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.569
X-Spam-Level: 
X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuEzOcaAT75U for ; Fri, 11 Oct 2013 02:22:34 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9E421E8143 for ; Fri, 11 Oct 2013 02:22:26 -0700 (PDT)
Received: from localhost ([127.0.0.1]:51116 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VUYvG-0008NV-NU; Fri, 11 Oct 2013 11:22:14 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "core issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com
X-Trac-Project: core
Date: Fri, 11 Oct 2013 09:22:14 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/346#comment:3
Message-ID: <075.8b07d4ca30db24e93f6b649027046550@trac.tools.ietf.org>
References: <060.3b4321d40c10aa360522a7791cb8644c@trac.tools.ietf.org>
X-Trac-Ticket-ID: 346
In-Reply-To: <060.3b4321d40c10aa360522a7791cb8644c@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: akbar.rahman@interdigital.com, angelo@castellani.net, esko.dijk@philips.com, salvatore.loreto@ericsson.com, tho@koanlogic.com
Resent-Message-Id: <20131011092227.1D9E421E8143@ietfa.amsl.com>
Resent-Date: Fri, 11 Oct 2013 02:22:26 -0700 (PDT)
Resent-From: trac+core@trac.tools.ietf.org
Cc: core@ietf.org
Subject: Re: [core] #346: Select solution for default HTTP-CoAP URI mapping
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: trac+core@trac.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Oct 2013 09:22:34 -0000

#346: Select solution for default HTTP-CoAP URI mapping

Changes (by esko.dijk@philips.com):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 Done in [1515], to be incorporated in http-mapping-02 to solicit WG
 feedback on the new proposal.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-http-
  esko.dijk@philips.com  |  mapping@tools.ietf.org
     Type:  task         |      Status:  closed
 Priority:  major        |   Milestone:
Component:  http-        |     Version:
  mapping                |  Resolution:  fixed
 Severity:  -            |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
core 


From tho@koanlogic.com  Fri Oct 11 07:10:58 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5C4121F9E6C for ; Fri, 11 Oct 2013 07:10:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNUdHCln0UND for ; Fri, 11 Oct 2013 07:10:54 -0700 (PDT)
Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) by ietfa.amsl.com (Postfix) with ESMTP id 7618911E80E3 for ; Fri, 11 Oct 2013 07:10:25 -0700 (PDT)
Received: by mail-la0-f53.google.com with SMTP id el20so3407002lab.40 for ; Fri, 11 Oct 2013 07:10:24 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=2Hvc8Xe4fiDFTEdivS5ezcc2cnV59C28XGXkuTh6d6M=; b=GMNOUQlFuo02Eia9iB1IA93C1gw4Xp8N4X06CQPHCUumuYriMDuWussc1Qu3BFAzVp 1ot2DobdBYr1jjnopTu1y/HjU5W7YYqNTpk6OUXdzlnavXZHvDfRxkMSEYDFWn0MavmJ P3LHQk13fd/YykqoqpTBxp1BdTqEybMsofIRaLdS5VLySJiOEgQDTkq/GufWiTQSW8OK 8Xi1DQ2KRdVeztz8o8J2Bl8Hs+HIlI5NpkJOU0UkThfxjmBsR1l/6S7fo8MmEJ6VqfiR j3Qlsja3LwTM7+tsrHe2SmV1mcfyWvIzQgSOZdU4Wti4r+8xngWBUwLNiyGC0gPDekOD 0x3Q==
X-Gm-Message-State: ALoCoQmgRY8Z67LmDI4HSVbDHlVrBwwGeyIgfM/uEMuO/VzeYY34Gcy2pZisxTCikaMmlRrwYa5k
MIME-Version: 1.0
X-Received: by 10.152.44.225 with SMTP id h1mr16672968lam.15.1381500624049; Fri, 11 Oct 2013 07:10:24 -0700 (PDT)
Received: by 10.114.21.4 with HTTP; Fri, 11 Oct 2013 07:10:23 -0700 (PDT)
X-Originating-IP: [81.134.152.4]
Date: Fri, 11 Oct 2013 15:10:23 +0100
Message-ID: 
From: Thomas Fossati 
To: "core@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1
Subject: [core] multipart and geo I-Ds
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Oct 2013 14:10:59 -0000

Hello,

one fairly new I-D:
1) the "geo" link-format attribute:
  http://tools.ietf.org/html/draft-fossati-core-geo-link-format-attribute-00

and an older one updated:
2) multipart content format:
  http://tools.ietf.org/html/draft-fossati-core-multipart-ct-02

They are both pretty compact, and should not take more than 20 minutes
to review -- if you are interested of course.

As usual, any comment is welcome.

Cheers, Thomas.

From Akbar.Rahman@InterDigital.com  Fri Oct 11 21:39:00 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE8621E80B4 for ; Fri, 11 Oct 2013 21:39:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level: 
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1Ci33MzVLc6 for ; Fri, 11 Oct 2013 21:38:56 -0700 (PDT)
Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id ADFAE11E811D for ; Fri, 11 Oct 2013 21:38:55 -0700 (PDT)
Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675);  Sat, 12 Oct 2013 00:38:54 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Date: Sat, 12 Oct 2013 00:38:46 -0400
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [core] FW: New Version Notification fordraft-rahman-core-sleepy-nodes-do-we-need-00.txt
Thread-Index: Ac7GSvCAVgePf1pIRLqdX/KT/YhtvwAuR9zQ
References:  
From: "Rahman, Akbar" 
To: "weigengyu" 
X-OriginalArrivalTime: 12 Oct 2013 04:38:54.0718 (UTC) FILETIME=[F52851E0:01CEC704]
Cc: core@ietf.org
Subject: Re: [core] FW: New Version Notification fordraft-rahman-core-sleepy-nodes-do-we-need-00.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 12 Oct 2013 04:39:00 -0000

VGhhbmtzLCBHZW5neXUsIGZvciB5b3VyIHN1cHBvcnQgZm9yIHRoZSB0b3BpYyBvZiBTbGVlcHkg
Tm9kZXMuDQoNCkkgYWdyZWUgdGhhdCB3ZSBjYW4gaGF2ZSBkaWZmZXJlbnQgZGVmaW5pdGlvbnMg
b2Ygd2hhdCB3ZSBtZWFuIGZyb20gYSBDT1JFIHBlcnNwZWN0aXZlIGZvciBhIFNsZWVweSBOb2Rl
LiAgQXQgdGhpcyBwb2ludCAodW50aWwgd2UgYWRvcHQgYSBXRyBkZWxpdmVyYWJsZSBmb3IgdGhp
cyB0b3BpYykgb25lIGRlZmluaXRpb24gaXMganVzdCBhcyB2YWxpZCBhcyBhbm90aGVyLiAgSG93
ZXZlciwgaXQgaXMgYWxzbyBpbnRlcmVzdGluZyB0byBzZWUgd2hhdCBvdGhlciBXR3MgYXJlIGRv
aW5nLiAgU28gZm9yIGV4YW1wbGUsIGluIFJPTEwsIHRoZSBkZWZpbml0aW9uIGlzOg0KDQoNCmh0
dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcm9sbC10ZXJtaW5vbG9neS0xMw0K
DQoNCiAgIFNsZWVweSBOb2RlOiBBIHNsZWVweSBub2RlIGlzIGEgbm9kZSB0aGF0IG1heSBzb21l
dGltZXMgZ28gaW50byBhDQogICBzbGVlcCBtb2RlIChpLmUuICBnbyBpbnRvIGEgbG93IHBvd2Vy
IHN0YXRlIHRvIGNvbnNlcnZlIHBvd2VyKSBhbmQNCiAgIHRlbXBvcmFyaWx5IHN1c3BlbmQgcHJv
dG9jb2wgY29tbXVuaWNhdGlvbi4gIFdoZW4gbm8gaW4gYSBzbGVlcCBtb2RlLA0KICAgdGhlIHNs
ZWVweSBub2RlIGlzIGluIGEgZnVsbHkgcG93ZXJlZCBvbiBzdGF0ZSB3aGVyZSBpdCBoYXMgdGhl
DQogICBjYXBhYmlsaXR5IHRvIHBlcmZvcm0gY29tbXVuaWNhdGlvbi4NCg0KDQpBbmQgdGhpcyBS
T0xMIGRlZmluaXRpb24sIGF0IGxlYXN0LCBpcyBzaW1pbGFyIHRvIHRoZSBvbmUgZnJvbSBkcmFm
dC1kaWprLWNvcmUtc2xlZXB5LXJlcXMtMDANCg0KDQoNCkJlc3QgUmVnYXJkcywNCg0KDQpBa2Jh
cg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHdlaWdlbmd5dSBbbWFp
bHRvOndlaWdlbmd5dUBidXB0LmVkdS5jbl0gDQpTZW50OiBGcmlkYXksIE9jdG9iZXIgMTEsIDIw
MTMgMjoyNyBBTQ0KVG86IFJhaG1hbiwgQWtiYXINCkNjOiBjb3JlQGlldGYub3JnDQpTdWJqZWN0
OiBSZTogW2NvcmVdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yZHJhZnQtcmFobWFu
LWNvcmUtc2xlZXB5LW5vZGVzLWRvLXdlLW5lZWQtMDAudHh0DQoNCkhpLCBSYWhtYW4sDQoNCk15
IGFuc3dlciB0aGUgcXVlc3Rpb24gIlNob3VsZCB3ZSBoYXZlIGEgQ09SRSBkZWxpdmVyYWJsZSBm
b3IgQ29BUCBzdXBwb3J0IG9mIFNsZWVweSBOb2Rlcz8iIGlzIFlFUy4NCg0KQnV0IEkgaGF2ZSBz
b21lIHF1ZXN0aW9ucyBhYm91dCB0aGUgdXNlIGNhc2VzLg0KQWNjb3JkaW5nIHRvICJTbGVlcHkg
RGV2aWNlcyB1c2luZyBDb0FQIC0gUmVxdWlyZW1lbnRzIGRyYWZ0LWRpamstY29yZS1zbGVlcHkt
cmVxcy0wMCINCnRoZSBkZWZpbml0aW4gb2YgU2xlZXBpbmcvQXNsZWVwIGFzIGZvbGxvd2luZzoN
CiAgIFNsZWVwaW5nL0FzbGVlcCAgOiBBIFNFUCBiZWluZyBpbiBhICJzbGVlcGluZyBzdGF0ZSIg
aS5lLiBpdHMgbmV0d29yayBpbnRlcmZhY2UgaXMgZGlzY29ubmVjdGVkIGFuZCBhIFNFUCBpcyBu
b3QgYWJsZSB0byBzZW5kIG9yIHJlY2VpdmUgbWVzc2FnZXMuDQpTbywgYSBzbGVlcHkgbm9kZSBz
aG91bGQgbm90IHN0YXJ0IHRvIGNvbW11bmljYXRlIHdpdGggb3RoZXIgbm9kZXMuICBUaGUgY29t
bXVuaWNhdGlvbiBiZXR3ZWVuIHNsZWVweSBub2RlcyBpcyBub3QgcG9zc2libGUsIHRoYXQgaXMg
Z2l2ZW4gaW4gIlByb2JsZW0gc3RhdGVtZW50IGFuZCBVc2UgY2FzZXMgb2YgU2xlZXB5IG5vZGUg
aW4gQ29uc3RyYWluZWQgbm9kZSBuZXR3b3JrcyBkcmFmdC1ob25nLWx3aWctc2xlZXB5bm9kZS1w
cm9ibGVtLXN0YXRlbWVudC0wMCINCg0KV2hlbiBhIG5vZGUgaXMgaW4gc2xlZXBpbmcgc3RhdGUs
IGl0IGNhbiByZWNlaXZlLCBidXQgaXQgY2Fubm90IHNlbmQuDQpUaGUgc2xlZXBpbmcgbm9kZSBj
YW4gYmUgd2FrZW4tdXAgYnkgYSByZWNlaXZlZCBtZXNzYWdlIG9yIHRpbWVyIGV4cGlyZWQgZXZl
bnQ7IHRoZXJlZm9yZSB0aGUgbm9kZSB0dXJucyB0byBiZSBhd2FrZS4NCkFuIGFsYXJtaW5nIG1l
c3NhZ2UgbWF5IGNhdXNlIHRoZSBzbGVlcHkgbm9kZSBhd2FrZSBhbmQgdGhlbiB0byBnaXZlIHJl
c3BvbnNlLg0KVGhlIHRpbWVyIGV4cGlyZWQgZXZlbnQgbWF5IGNhdXNlICB0aGUgc2xlZXB5IG5v
ZGUgYXdha2UgYW5kIHRoZW4gdG8gc2VuZCBoZWFydGJlYXQuDQpBIG5vZGUgY2FuIHNlbmQgYSBt
ZXNzYWdlIG91dCBvbmx5IHdoZW4gaXQgaXMgYXdha2UuDQoNCkFmdGVyYWxsLCBpdCBpcyBwb3Nz
aWJsZSB0aGF0IHRoZSBub24tc2xlZXAgbm9kZSAgaW5pdGlhdGVzIGNvbW11bmljYXRpb24gd2l0
aCBhIHNsZWVweSBub2RlLiBUaGUgc2xlZXAgbm9kZSBpcyBwYXNzaXZlLg0KSWYgdGhlIG5vZGUg
aW4gc2xlZXB5IHN0YXRlIHdhbnRzIHRvIHJlc3BvbmQgdGhlIG1lc3NhZ2UsIGl0IGZpcnN0bHkg
dHVybnMgdG8gYXdha2Ugc3RhdGUuDQoNCnJlZ2FyZHMsDQoNCkdlbmd5dQ0KDQoNCi0tLS0t5Y6f
5aeL6YKu5Lu2LS0tLS0NCkZyb206IFJhaG1hbiwgQWtiYXINClNlbnQ6IEZyaWRheSwgT2N0b2Jl
ciAxMSwgMjAxMyAxMTozOSBBTQ0KVG86IENhcnN0ZW4gQm9ybWFubiA7IGNvcmVAaWV0Zi5vcmcN
ClN1YmplY3Q6IFtjb3JlXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcmRyYWZ0LXJh
aG1hbi1jb3JlLXNsZWVweS1ub2Rlcy1kby13ZS1uZWVkLTAwLnR4dA0KDQpIaSBDYXJzdGVuIChh
bmQgV0cpLA0KDQoNCkkgd3JvdGUgYSBzaG9ydCBkcmFmdCBiYXNlZCBvbiB0aGUgZm9sbG93aW5n
IHF1ZXN0aW9uIGZyb20gSUVURi04NyAoQmVybGluKToNCg0KIlNob3VsZCB3ZSBoYXZlIGEgQ09S
RSBkZWxpdmVyYWJsZSBmb3IgQ29BUCBzdXBwb3J0IG9mIFNsZWVweSBOb2Rlcz8iDQoNCmh0dHA6
Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9jb3JlL2N1cnJlbnQvbXNnMDQ3NTAuaHRt
bA0KDQoNCg0KQW55IGFuZCBhbGwgY29tbWVudHMgd2lsbCBiZSBtdWNoIGFwcHJlY2lhdGVkLg0K
DQoNCg0KQWtiYXINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0
LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NClNlbnQ6
IFRodXJzZGF5LCBPY3RvYmVyIDEwLCAyMDEzIDExOjM0IFBNDQpUbzogUmFobWFuLCBBa2Jhcjsg
UmFobWFuLCBBa2Jhcg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uDQpmb3JkcmFm
dC1yYWhtYW4tY29yZS1zbGVlcHktbm9kZXMtZG8td2UtbmVlZC0wMC50eHQNCg0KDQpBIG5ldyB2
ZXJzaW9uIG9mIEktRCwgZHJhZnQtcmFobWFuLWNvcmUtc2xlZXB5LW5vZGVzLWRvLXdlLW5lZWQt
MDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEFrYmFyIFJhaG1hbiBh
bmQgcG9zdGVkIHRvIHRoZSBJRVRGIA0KcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6IGRyYWZ0LXJh
aG1hbi1jb3JlLXNsZWVweS1ub2Rlcy1kby13ZS1uZWVkDQpSZXZpc2lvbjogMDANClRpdGxlOiBT
bGVlcHkgRGV2aWNlczogRG8gd2UgbmVlZCB0byBTdXBwb3J0IHRoZW0gaW4gQ09SRT8NCkNyZWF0
aW9uIGRhdGU6IDIwMTMtMTAtMTENCkdyb3VwOiBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJl
ciBvZiBwYWdlczogNg0KVVJMOiANCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz
L2RyYWZ0LXJhaG1hbi1jb3JlLXNsZWVweS1ub2Rlcy1kby13ZS1uZWVkLTAwLnR4dA0KU3RhdHVz
OiANCmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcmFobWFuLWNvcmUtc2xl
ZXB5LW5vZGVzLWRvLXdlLW5lZWQNCkh0bWxpemVkOiANCmh0dHA6Ly90b29scy5pZXRmLm9yZy9o
dG1sL2RyYWZ0LXJhaG1hbi1jb3JlLXNsZWVweS1ub2Rlcy1kby13ZS1uZWVkLTAwDQoNCg0KQWJz
dHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IHN1bW1hcml6ZXMgdGhlIGRpc2N1c3Npb24gaW4gdGhl
IENPUkUgV0cgcmVsYXRlZCB0byB0aGUNCiAgIHF1ZXN0aW9uIG9mIHdoZXRoZXIgc3VwcG9ydCBv
ZiBzbGVlcHkgZGV2aWNlcyBpcyByZXF1aXJlZCBmb3IgdGhlDQogICBDb0FQIHByb3RvY29sLCBD
T1JFIExpbmsgRm9ybWF0LCBDT1JFIFJlc291cmNlIERpcmVjdG9yeSwgZXRjLiAgVGhlDQogICBv
bmx5IGdvYWwgb2YgdGhpcyBkb2N1bWVudCBpcyB0byB0cmlnZ2VyIGRpc2N1c3Npb25zIGluIHRo
ZSBDT1JFIFdHDQogICBzbyB0aGF0IGFsbCByZWxldmFudCBjb25zaWRlcmF0aW9ucyBmb3Igc2xl
ZXBpbmcgZGV2aWNlcyBhcmUgdGFrZW4NCiAgIGludG8gYWNjb3VudC4NCg0KDQoNCg0KUGxlYXNl
IG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUg
b2Ygc3VibWlzc2lvbiANCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBh
dmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpjb3JlIG1haWxp
bmcgbGlzdA0KY29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9jb3JlIA0KDQo=

From Akbar.Rahman@InterDigital.com  Fri Oct 11 21:44:33 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB54211E812A for ; Fri, 11 Oct 2013 21:44:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSi8hZ9jXu0m for ; Fri, 11 Oct 2013 21:44:29 -0700 (PDT)
Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5C111E81AC for ; Fri, 11 Oct 2013 21:44:29 -0700 (PDT)
Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675);  Sat, 12 Oct 2013 00:44:27 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sat, 12 Oct 2013 00:44:19 -0400
Message-ID: 
In-Reply-To: <031DD135F9160444ABBE3B0C36CED618016F59E5@011-DB3MPN2-081.MGDPHG.emi.philips.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [core] FW: New Version Notification fordraft-rahman-core-sleepy-nodes-do-we-need-00.txt
Thread-Index: Ac7GMr8zNyxAslFmQl6t9qCTzAWmpwAAAzXwAAbHoIAAA+9dcAAp2LJQ
References:   <031DD135F9160444ABBE3B0C36CED618016F59E5@011-DB3MPN2-081.MGDPHG.emi.philips.com>
From: "Rahman, Akbar" 
To: "Dijk, Esko" , "Thomas Fossati" 
X-OriginalArrivalTime: 12 Oct 2013 04:44:27.0651 (UTC) FILETIME=[BB99DD30:01CEC705]
Cc: core@ietf.org
Subject: Re: [core] FW: New Version Notification fordraft-rahman-core-sleepy-nodes-do-we-need-00.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 12 Oct 2013 04:44:33 -0000

Hi Esko/Thomas,


First, thanks for adding your voices to the support of creating a CORE
deliverable for Sleepy Nodes.  That is definitely appreciated.

I agree that [I-D.vial-core-mirror-server] is a good starting point for
Sleepy Node support.  However, I made the following relevant observation
in my draft:


=09
http://tools.ietf.org/html/draft-rahman-core-sleepy-nodes-do-we-need-00#
section-5

	Another point to consider is that during WG discussions, the
CORE
   Mirror Server [I-D.vial-core-mirror-server]  is sometimes referred to
   as the "existing" solution for CORE Sleepy Node support.  However,
   this draft was never adopted as a WG draft.




Best Regards,

Akbar


-----Original Message-----
From: Dijk, Esko [mailto:esko.dijk@philips.com]=20
Sent: Friday, October 11, 2013 4:48 AM
To: Thomas Fossati; Rahman, Akbar
Cc: core@ietf.org
Subject: RE: [core] FW: New Version Notification
fordraft-rahman-core-sleepy-nodes-do-we-need-00.txt


 >         "Should we have a CORE deliverable for CoAP support of Sleepy
Nodes?"
Yes!  (motivation: existing WG documents do not provide the complete
solution yet that is required at CoAP level)

> of in-protocol mechanisms (a bunch of Options, basically)
I don't fully agree; it could be one or more options that are needed; it
could be perhaps done without new options.
The thing that is needed at least, in my opinion, is functionality like
[I-D.vial-core-mirror-server].  (If needed I can motivate this further
on the list with use cases.)

> (as opposed to a fully fledged architecture to support Sleepy nodes,
which other SDOs are in a better position to provide)
Agree. I see mirror server as an example of a useful/required component,
but it is not a full architecture yet. But any CoRE defined 'building
block' should fit in such architectures.

Esko

-----Original Message-----
From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of
Thomas Fossati
Sent: Friday, October 11, 2013 08:49
To: Rahman, Akbar
Cc: core@ietf.org
Subject: Re: [core] FW: New Version Notification for
draft-rahman-core-sleepy-nodes-do-we-need-00.txt

Hi Akbar, thank you very much for this.

I think you are providing a really good service to the working group in
keeping the background discussion on this important topic alive.

Personally, I think that providing a set of in-protocol mechanisms (a
bunch of Options, basically) to tackle well known and understood
scenarios (as opposed to a fully fledged architecture to support Sleepy
nodes, which other SDOs are in a better position to provide) is
something that is perfectly in scope with CoAP goals and WG interest and
energy  -- as you sensed it back in August.

And yes, I'd have given you my +1 when you polled the mailing list about
this, if I weren't on holiday :-)

Cheers

On Fri, Oct 11, 2013 at 4:39 AM, Rahman, Akbar
 wrote:
> Hi Carsten (and WG),
>
>
> I wrote a short draft based on the following question from IETF-87
(Berlin):
>
>         "Should we have a CORE deliverable for CoAP support of Sleepy
Nodes?"
>
>
> http://www.ietf.org/mail-archive/web/core/current/msg04750.html
>
>
>
> Any and all comments will be much appreciated.
>
>
>
> Akbar
>
> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> Sent: Thursday, October 10, 2013 11:34 PM
> To: Rahman, Akbar; Rahman, Akbar
> Subject: New Version Notification
> fordraft-rahman-core-sleepy-nodes-do-we-need-00.txt
>
>
> A new version of I-D, draft-rahman-core-sleepy-nodes-do-we-need-00.txt
> has been successfully submitted by Akbar Rahman and posted to the IETF
repository.
>
> Filename:        draft-rahman-core-sleepy-nodes-do-we-need
> Revision:        00
> Title:           Sleepy Devices: Do we need to Support them in CORE?
> Creation date:   2013-10-11
> Group:           Individual Submission
> Number of pages: 6
> URL:
http://www.ietf.org/internet-drafts/draft-rahman-core-sleepy-nodes-do-we
-need-00.txt
> Status:
http://datatracker.ietf.org/doc/draft-rahman-core-sleepy-nodes-do-we-nee
d
> Htmlized:
http://tools.ietf.org/html/draft-rahman-core-sleepy-nodes-do-we-need-00
>
>
> Abstract:
>    This document summarizes the discussion in the CORE WG related to
the
>    question of whether support of sleepy devices is required for the
>    CoAP protocol, CORE Link Format, CORE Resource Directory, etc.  The
>    only goal of this document is to trigger discussions in the CORE WG
>    so that all relevant considerations for sleeping devices are taken
>    into account.
>
>
>
>
> 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

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


From cabo@tzi.org  Fri Oct 11 23:56:07 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68DD021E80D0; Fri, 11 Oct 2013 23:56:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.861
X-Spam-Level: 
X-Spam-Status: No, score=-105.861 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhMvb2eThU+5; Fri, 11 Oct 2013 23:55:56 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 7114821F9FA5; Fri, 11 Oct 2013 23:55:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9C6tjQc003442; Sat, 12 Oct 2013 08:55:45 +0200 (CEST)
Received: from [192.168.217.105] (p54890CAC.dip0.t-ipconnect.de [84.137.12.172]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 87EA4D2E; Sat, 12 Oct 2013 08:55:44 +0200 (CEST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Carsten Bormann 
In-Reply-To: 
Date: Sat, 12 Oct 2013 08:55:43 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <8529DF4C-1952-4A98-A4FC-B29806FE02B4@tzi.org>
References:  
To: lwip@ietf.org, "core@ietf.org WG" , roll WG , 6lowpan@ietf.org, dtls-iot@ietf.org, "6lo@ietf.org WG" <6lo@ietf.org>,  "6tisch@ietf.org" <6tisch@ietf.org>
X-Mailer: Apple Mail (2.1510)
Subject: [core] Constrained Node/Network Cluster @ IETF88, "final" version
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 12 Oct 2013 06:56:07 -0000

On Oct 5, 2013, at 18:31, Carsten Bormann  wrote:

> A first draft version of the IETF88 agenda is out. [...]
> Here is my usual eclectic condensed agenda built from that. =20
> All times are PST (UTC-0800).

And here is the update based on the "final" agenda.
(Which is "final" only in that it will be committed to print; it still =
could change some more.)

Apart from room changes, the changes are:
1) The lwig/6tisch conflict was resolved; unfortunately the moved lwig =
now conflicts with perpass.
2) There will be no ROLL meeting in Vancouver.

Besides the official agenda, there will be unofficial ("hallway") =
meetings.
I have started to collect info on a Wiki page:

	http://trac.tools.ietf.org/wg/core/trac/wiki/hallway88

You can edit and add meetings there using your tools login.

Gr=FC=DFe, Carsten



MONDAY, November 4, 2013

0900-1130  Morning Session I
Georgia B	APP	appsawg	Applications Area Working Group WG - - =
Combined with APPAREA
Regency D	INT	6man	IPv6 Maintenance WG

1300-1430  Afternoon Session I
Regency B	SEC ***	dice	DTLS In Constrained Environments WG

1450-1720  Afternoon Session II
Georgia B	APP ***	core	Constrained RESTful Environments WG
Regency C	INT	intarea	Internet Area Working Group WG
Plaza C 	SEC	oauth	Web Authorization Protocol WG

1740-1940  Afternoon Session III
Regency A	APP	httpbis	Hypertext Transfer Protocol Bis WG
Regency D	OPS	v6ops	IPv6 Operations WG
Regency C	RTG	rtgarea	Routing Area Open Meeting

TUESDAY, November 5, 2013

0900-1130  Morning Session I
Georgia A	APP	httpbis	Hypertext Transfer Protocol Bis WG

1300-1400  Afternoon Session I
Plaza A 	APP	json	JavaScript Object Notation WG
Regency B	INT	its	Intelligent Transportation Systems BOF

1420-1550  Afternoon Session II
Georgia B	INT ***	6tisch	IPv6 over the TSCH mode of IEEE =
802.15.4e WG
Regency B	TSV	tsvwg	Transport Area Working Group WG

1610-1840  Afternoon Session III
Regency A	INT ***	6lo	IPv6 over Networks of =
Resource-constrained Nodes WG
Plaza A 	OPS	eman	Energy Management WG
Georgia A	SEC	tls	Transport Layer Security WG

WEDNESDAY, November 6, 2013

1300-1530  Afternoon Session I
Plaza C 	INT ***	lwig	Light-Weight Implementation Guidance WG
Regency C	OPS	v6ops	IPv6 Operations WG
Regency D	SEC	perpass	Handling Pervasive Monitoring in the =
IETF  BOF
Georgia B	TSV	rmcat	RTP Media Congestion Avoidance =
Techniques WG

THURSDAY, November 7, 2013

0900-1130  Morning Session I
Regency D	INT	homenet	Home Networking WG
Georgia A	SEC	jose	Javascript Object Signing and Encryption =
WG
Regency C	TSV	tsvarea	Transport Area Open Meeting

1300-1500  Afternoon Session I
Regency D	SEC	saag	Security Area Open Meeting

1520-1720  Afternoon Session II
Regency B	APP ***	core	Constrained RESTful Environments WG

FRIDAY, November 8, 2013

0900-1100  Morning Session I
Georgia B	SEC	httpauth	Hypertext Transfer Protocol =
Authentication WG
Regency B	TSV	tsvwg	Transport Area Working Group WG

1120-1220  Afternoon Session I
Regency D	INT	dnssdext	Extensions for Scalable DNS =
Service Discovery  WG

1230-1330  Afternoon Session II
Regency D	INT	dnssdext	Extensions for Scalable DNS =
Service Discovery  WG



From matteo.collina@gmail.com  Sat Oct 12 02:20:51 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F61B21E80AF for ; Sat, 12 Oct 2013 02:20:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDqIpGWctYWb for ; Sat, 12 Oct 2013 02:20:50 -0700 (PDT)
Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 149A821E8140 for ; Sat, 12 Oct 2013 02:20:47 -0700 (PDT)
Received: by mail-ie0-f169.google.com with SMTP id ar20so266991iec.14 for ; Sat, 12 Oct 2013 02:20:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=STWXrGqp2cKfSN6llZuIB5Hd9NHhIICsdlzIvLZHRn8=; b=YD/RDbYoE6Et/kYWNETCabRjds+Hb7qcowWbE44I4FSz8eEvMdk5CKcxaC4roA3KZR ofsMCD5KD0+u3gnIJv5TFyDR40SlV3n1X2ljc0LVI8oddZxJ2A9AKUpWCczNdUaysors 3TbQU5c1Cg7Hhb/ucp1AaMl2cllKBZuoZcKeEP5Oym8zegbqstdVOOK4Wd/WbGhw0WVF P1BSmX0g2VsiDjTcAgBs/179vTSy6Bir5jS8SvFQf9mNnnBYSkYKcxcyJo30K9eni2HZ pKrW5svKYOUjUUWdz0NE2bGWaJPOc++oRbmAXEV/+VkcoYRGs6HMwpDEIFSJbycHS+7y PE9A==
X-Received: by 10.42.110.147 with SMTP id q19mr13767171icp.6.1381569647331; Sat, 12 Oct 2013 02:20:47 -0700 (PDT)
MIME-Version: 1.0
Sender: matteo.collina@gmail.com
Received: by 10.42.98.205 with HTTP; Sat, 12 Oct 2013 02:20:27 -0700 (PDT)
From: Matteo Collina 
Date: Sat, 12 Oct 2013 11:20:27 +0200
X-Google-Sender-Auth: _hC9t632P_qSAdtzUF8tow5bYeY
Message-ID: 
To: core@ietf.org
Content-Type: multipart/alternative; boundary=20cf303bf4a00fcec904e887c0d8
Subject: [core] node-coap
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 12 Oct 2013 09:21:51 -0000

--20cf303bf4a00fcec904e887c0d8
Content-Type: text/plain; charset=ISO-8859-1

Hi Everyone,

My name is Matteo Collina and I am a Ph.D. Candidate at the University of
Bologna.
I am not sure if this is the right ML, but I would like to announce my
node-coap library, which is a CoAP library for node.js (supports coap-18
and coap-observe-10) in pure javascript.
I have also done a separate parser/generator of CoAP packets in Javascript
https://github.com/mcollina/coap-packet: it can be easily ported to the
browser if someone wants to work on a CoAP-over-WebSocket platform.

You can find them at http://npm.im/coap and http://npm.im/coap-packet,
respectively.
Any feedbacks, bugs, pull-requests or blog posts, are very welcome.

I also have a couple of questions:
1) is there an established practice for testing CoAP compatibility? I
tested it with Copper lightly and everything is fine, but I'd like to have
a formal approach on this.
2) from the spec it is not clear where is located the option number and
content format registries.

Cheers,

Matteo

--20cf303bf4a00fcec904e887c0d8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hi Everyone,=A0

My name is Matteo Colli=
na and I am a Ph.D. Candidate at the University of Bologna.
I am =
not sure if this is the right ML, but I would like to announce my node-coap=
 library, which is a CoAP library for node.js (supports coap-18 and coap-ob=
serve-10) in pure javascript.



I have also done a separate parser/generator of CoAP packets in Javasc=
ript https://github.com=
/mcollina/coap-packet: it can be easily ported to the browser if someon=
e wants to work on a CoAP-over-WebSocket platform.




You can find them at htt=
p://npm.im/coap and http://npm.im=
/coap-packet, respectively.
Any feedbacks, bugs, pull-request=
s or blog posts,=A0are very welcome.




I also have a couple of questions:
1) is ther=
e an established practice for testing CoAP compatibility? I tested it with =
Copper lightly and everything is fine, but I'd like to have a formal ap=
proach on this.



2) from the spec it is not clear where is located the option number an=
d content format registries.

Cheers,
Matteo


--20cf303bf4a00fcec904e887c0d8--

From cabo@tzi.org  Sat Oct 12 02:53:26 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A7921F9FAE for ; Sat, 12 Oct 2013 02:53:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.155
X-Spam-Level: 
X-Spam-Status: No, score=-106.155 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qn65uXB1pXae for ; Sat, 12 Oct 2013 02:53:22 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 65F8321F9CF1 for ; Sat, 12 Oct 2013 02:53:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9C9rE06011934; Sat, 12 Oct 2013 11:53:14 +0200 (CEST)
Received: from [192.168.217.105] (p54890F3E.dip0.t-ipconnect.de [84.137.15.62]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 26316D4E; Sat, 12 Oct 2013 11:53:14 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: 
Date: Sat, 12 Oct 2013 11:53:12 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <338D12E0-955A-4786-AB82-E1B17DD5CAA2@tzi.org>
References: 
To: Matteo Collina 
X-Mailer: Apple Mail (2.1510)
Cc: core@ietf.org
Subject: Re: [core] node-coap
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 12 Oct 2013 09:53:26 -0000

> You can find them at http://npm.im/coap and http://npm.im/coap-packet, =
respectively.

Great!

> I also have a couple of questions:
> 1) is there an established practice for testing CoAP compatibility? I =
tested it with Copper lightly and everything is fine, but I'd like to =
have a formal approach on this.

The next formal CoAP plugtest event ("CoAP#3") is run by ETSI in =
cooperation with IPSO and OMA on Nov 19-22 in Las Vegas.
The CoRE wiki=20

	http://trac.tools.ietf.org/wg/core/trac/wiki

is not in great shape but does contain a pointer:

	http://www.etsi.org/coap-oma-lightweight-m2m

If you have an implementation, you want to be there.

In preparation for the plugtest, there will be several test sites.
Still running from the previous plugtests is:

	http://coap.me

(updated to coap-18).  I expect to have some CoAP#3 tests there within a =
week or so.

> 2) from the spec it is not clear where is located the option number =
and content format registries.

They are all collected at

	=
http://www.iana.org/assignments/core-parameters/core-parameters.txt

or

	=
http://www.iana.org/assignments/core-parameters/core-parameters.xhtml

Thanks for those great questions!

Gr=FC=DFe, Carsten


From cabo@tzi.org  Sat Oct 12 03:21:52 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF3611E81B7 for ; Sat, 12 Oct 2013 03:21:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.157
X-Spam-Level: 
X-Spam-Status: No, score=-106.157 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWg+brgeAAdf for ; Sat, 12 Oct 2013 03:21:48 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id CD9D311E81F4 for ; Sat, 12 Oct 2013 03:21:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9CALZmn017939 for ; Sat, 12 Oct 2013 12:21:35 +0200 (CEST)
Received: from [192.168.217.105] (p54890F3E.dip0.t-ipconnect.de [84.137.15.62]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 188D8D56; Sat, 12 Oct 2013 12:21:35 +0200 (CEST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Carsten Bormann 
In-Reply-To: <338D12E0-955A-4786-AB82-E1B17DD5CAA2@tzi.org>
Date: Sat, 12 Oct 2013 12:21:33 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <9B091886-8BB5-4F1C-8B74-3B8AAB1EA5CD@tzi.org>
References:  <338D12E0-955A-4786-AB82-E1B17DD5CAA2@tzi.org>
To: "core@ietf.org WG" 
X-Mailer: Apple Mail (2.1510)
Subject: [core] CoRE wiki (Re:  node-coap)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 12 Oct 2013 10:21:53 -0000

On Oct 12, 2013, at 11:53, Carsten Bormann  wrote:

> The CoRE wiki=20
>=20
> 	http://trac.tools.ietf.org/wg/core/trac/wiki
>=20
> is not in great shape=20

I have fixed it up a little bit.

Since that URI is too long, I have also added a redirect from

	http://6lowapp.net

Please feel free to add information and make changes =
(http://en.wikipedia.org/wiki/WP:BB).

Gr=FC=DFe, Carsten


From hartke@tzi.org  Sat Oct 12 04:19:31 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF3EB21E8161 for ; Sat, 12 Oct 2013 04:19:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.627
X-Spam-Level: 
X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHpCK11RDZok for ; Sat, 12 Oct 2013 04:19:27 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 3741721E80E0 for ; Sat, 12 Oct 2013 04:19:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9CBJO4C000009 for ; Sat, 12 Oct 2013 13:19:24 +0200 (CEST)
Received: from mail-vb0-f50.google.com (mail-vb0-f50.google.com [209.85.212.50]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5509CD64 for ; Sat, 12 Oct 2013 13:19:24 +0200 (CEST)
Received: by mail-vb0-f50.google.com with SMTP id x14so3508092vbb.23 for ; Sat, 12 Oct 2013 04:19:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=pBRYeatLJ8Q8tBvBLRL6w+xWJiQRSuA2xP8tl8C0QCI=; b=cI3SvcTrGY/7m8+m+4M8v6hvu9OUCoyLx0s3rVHF8KQKsNZv701H9JiFjrJmsiqFDd tP7cZmtjWMruh7so6bM4SqpVHkKqCVr7H2ExRuyjtXMJ4LXwJS+QO9zL5Qed93m02BAs KQlgBxgJQNJQTYW2xxCarFs1Lq40LzqQZufk1xQhPM+wfMnWPsb5qSKKEY5aBnbw2tSI V/9GwQErIn1hIuxQqaC9tH2S/DSrIf9qHjjwo5+Q72SBpWlghorL56pdyhIhPN+NiqJv Glwox383h6NBfzh9ElwfIUFZltIZ0WteElgZjZkjv8chij027Fy9hKDGcOqF47MI0AtH CCSg==
X-Received: by 10.52.35.20 with SMTP id d20mr127396vdj.33.1381576762760; Sat, 12 Oct 2013 04:19:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.24.83 with HTTP; Sat, 12 Oct 2013 04:18:42 -0700 (PDT)
In-Reply-To: <338D12E0-955A-4786-AB82-E1B17DD5CAA2@tzi.org>
References:  <338D12E0-955A-4786-AB82-E1B17DD5CAA2@tzi.org>
From: Klaus Hartke 
Date: Sat, 12 Oct 2013 14:18:42 +0300
Message-ID: 
To: Carsten Bormann 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "core@ietf.org WG" 
Subject: Re: [core] node-coap
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 12 Oct 2013 11:19:31 -0000

Carsten Bormann wrote:
>> 2) from the spec it is not clear where is located the option number and content format registries.
>
> They are all collected at
>
>         http://www.iana.org/assignments/core-parameters/core-parameters.txt
>
> or
>
>         http://www.iana.org/assignments/core-parameters/core-parameters.xhtml

In addition to the official IANA registry, there's an unofficial
registry that also includes entries from drafts at various stages of
progress:

        http://svn.tools.ietf.org/svn/wg/core/registry.txt

Klaus

From internet-drafts@ietf.org  Sat Oct 12 05:19:06 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2773B11E821A; Sat, 12 Oct 2013 05:19:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.566
X-Spam-Level: 
X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUhdiq75V1-6; Sat, 12 Oct 2013 05:19:05 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD5C21F9D12; Sat, 12 Oct 2013 05:19:05 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.80.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131012121905.9641.33804.idtracker@ietfa.amsl.com>
Date: Sat, 12 Oct 2013 05:19:05 -0700
Cc: core@ietf.org
Subject: [core] I-D Action: draft-ietf-core-http-mapping-02.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 12 Oct 2013 12:19:06 -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           : Guidelines for HTTP-CoAP Mapping Implementations
	Author(s)       : Angelo P. Castellani
                          Salvatore Loreto
                          Akbar Rahman
                          Thomas Fossati
                          Esko Dijk
	Filename        : draft-ietf-core-http-mapping-02.txt
	Pages           : 19
	Date            : 2013-10-12

Abstract:
   This draft provides reference information for HTTP-CoAP protocol
   translation proxy implementors, focusing primarily on the reverse
   proxy case.  It details deployment options, defines a safe method for
   URI mapping, and provides a set of guidelines and considerations
   related to protocol translation.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-core-http-mapping-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-http-mapping-02


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From kovatsch@inf.ethz.ch  Sun Oct 13 12:49:50 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A993D21F84EF for ; Sun, 13 Oct 2013 12:49:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.184
X-Spam-Level: 
X-Spam-Status: No, score=-8.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLaLEn0S0t2E for ; Sun, 13 Oct 2013 12:49:44 -0700 (PDT)
Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3144521F99D5 for ; Sun, 13 Oct 2013 12:49:40 -0700 (PDT)
Received: from CAS11.d.ethz.ch (172.31.38.211) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.2.298.4; Sun, 13 Oct 2013 21:49:35 +0200
Received: from MBX210.d.ethz.ch ([fe80::ed77:7d47:9467:69a9]) by CAS11.d.ethz.ch ([fe80::ecc9:4e2d:b26b:1614%10]) with mapi id 14.02.0298.004; Sun, 13 Oct 2013 21:49:36 +0200
From: "Kovatsch  Matthias" 
To: core 
Thread-Topic: Open issues with -block
Thread-Index: Ac7IR6yg8vgk6cYgTsSTD2+Jveqayw==
Date: Sun, 13 Oct 2013 19:49:35 +0000
Message-ID: <55877B3AFB359744BA0F2140E36F52B515BE7760@MBX210.d.ethz.ch>
Accept-Language: en-US, de-CH
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [77.57.171.155]
Content-Type: multipart/alternative; boundary="_000_55877B3AFB359744BA0F2140E36F52B515BE7760MBX210dethzch_"
MIME-Version: 1.0
Cc: Lanter  Martin 
Subject: [core] Open issues with -block
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 13 Oct 2013 19:49:50 -0000

--_000_55877B3AFB359744BA0F2140E36F52B515BE7760MBX210dethzch_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear list



I still have some issues with blockwise transfers that I would like to disc=
uss:



1) Change of initiative to the server

As CoAP implementer for constrained devices, I am not happy about this solu=
tion, as it requires additional code for servers to manage the active trans=
mission of blocks (cf. Block2 in response to GET is handled differently). T=
he current solution can also not fulfill the in-order requirement for block=
s: Block2 #1 is transmitted piggybacked when acknowledging the last Block1 =
and Block2 #2 is transmitted right after as separate response. In this case=
, #1 and #2 can get reordered.



2) Combination with Observe

The change of initiative is currently also used when combining -block with =
-observe. This, however, burdens the server with quite a bit of house-keepi=
ng. A while ago, I proposed a different solution, where only the first bloc=
k is transmitted as notification and then the clients collect the remaining=
 blocks with normal GET requests (running the same code as for normal block=
wise GETs). This also fits nicely with the new token-based observe relation=
ships, as there is no risk of accidental cancelling.



3) Response codes for incomplete requests

Currently, servers have to respond to Block1 requests with a status code th=
ey cannot know until they received all blocks (especially, when using atomi=
c transfers). The best solution would be to respond with 1.00 Continue, but=
 this code range was not defined in the core draft. The second best thing w=
ould then be to assign a 2.xx Block Successful code.



A transmission without change of initiative would look like this:

   CLIENT                                                     SERVER
     |                                                              |
     | CON [MID=3D1234], POST, /soap, 1:0/1/128      ------>          |
     |                                                              |
     | <------   ACK [MID=3D1234], 2.xx Block Successful, 1:0/1/128   |
     |                                                              |
     | CON [MID=3D1235], POST, /soap, 1:1/1/128      ------>          |
     |                                                              |
     | <------   ACK [MID=3D1235], 2.xx Block Successful, 1:1/1/128   |
     |                                                              |
     | CON [MID=3D1236], POST, /soap, 1:2/0/128      ------>          |
     |                                                              |
     | <------   ACK [MID=3D1236], 2.01 Created, 2:0/1/128, 1:2/0/128 |
     |                                                              |
     | CON [MID=3D1237], POST, /soap, 2:1/0/128      ------>          |
     | (no payload, when Block2 is set)                             |
     | (could also do block size negotiation, requesting 2:0/0/64)  |
     |                                                              |
     | <------   ACK [MID=3D1237], 2.01 Created, 2:1/1/128            |
     |                                                              |
     | CON [MID=3D1238], POST, /soap, 2:2/0/128      ------>          |
     |                                                              |
     | <------   ACK [MID=3D1238], 2.01 Created, 2:2/1/128            |
     |                                                              |
     | CON [MID=3D1239], POST, /soap, 2:3/0/128      ------>          |
     |                                                              |
     | <------   ACK [MID=3D1239], 2.01 Created, 2:3/0/128            |



Was there anything speaking against this solution and I just forgot about i=
t?

Please discuss, especially, when you implemented Block1+Block2 POST and the=
 combination of -block with -observe.



Best regards

Matthias



--_000_55877B3AFB359744BA0F2140E36F52B515BE7760MBX210dethzch_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Dear list


 


I stil=
l have some issues with blockwise transfers that I would like to discuss:


&=
nbsp;


1) Cha=
nge of initiative to the server


As CoA=
P implementer for constrained devices, I am not happy about this solution, =
as it requires additional code for servers to manage the active transmissio=
n of blocks (cf. Block2 in response to
 GET is handled differently). The current solution can also not fulfill the=
 in-order requirement for blocks: Block2 #1 is transmitted piggybacked when=
 acknowledging the last Block1 and Block2 #2 is transmitted right after as =
separate response. In this case,
 #1 and #2 can get reordered.


&=
nbsp;


2) Com=
bination with Observe


The ch=
ange of initiative is currently also used when combining -block with -obser=
ve. This, however, burdens the server with quite a bit of house-keeping. A =
while ago, I proposed a different solution,
 where only the first block is transmitted as notification and then the cli=
ents collect the remaining blocks with normal GET requests (running the sam=
e code as for normal blockwise GETs). This also fits nicely with the new to=
ken-based observe relationships,
 as there is no risk of accidental cancelling. 


&=
nbsp;


3) Res=
ponse codes for incomplete requests


Curren=
tly, servers have to respond to Block1 requests with a status code they can=
not know until they received all blocks (especially, when using atomic tran=
sfers). The best solution would be to
 respond with 1.00 Continue, but this code range was not defined in the cor=
e draft. The second best thing would then be to assign a 2.xx Block Success=
ful code.


&=
nbsp;


A tran=
smission without change of initiative would look like this:


 


   CLI=
ENT            =
            &nb=
sp;            =
            &nb=
sp;   SERVER


  &nbs=
p;  |           =
;            &n=
bsp;            =
;            &n=
bsp;            =
; |


  &nbs=
p;  | CON [MID=3D1234], POST, /soap, 1:0/1/128    =
  ------>          |


  &nbs=
p;  |           =
;             &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;|


  &nbs=
p;  | <------   ACK [MID=3D1234], 2.xx Block Successful, =
1:0/1/128   |


  &nbs=
p;  |           =
;            &n=
bsp;            =
;            &n=
bsp;            =
; |


  &nbs=
p;  | CON [MID=3D1235], POST, /soap, 1:1/1/128    =
  ------>          |


  &nbs=
p;  |           =
;            &n=
bsp;            =
;            &n=
bsp;            =
; |


  &nbs=
p;  | <------   ACK [MID=3D1235], 2.xx Block Successful, =
1:1/1/128   |


  &nbs=
p;  |           =
;            &n=
bsp;            =
;            &n=
bsp;            =
; |


  &nbs=
p;  | CON [MID=3D1236], POST, /soap, 1:2/0/128    =
  ------>          |


  &nbs=
p;  |           =
;            &n=
bsp;            =
;            &n=
bsp;            =
; |


  &nbs=
p;  | <------   ACK [MID=3D1236], 2.01 Created, 2:0/1/128=
, 1:2/0/128 |


  &nbs=
p;  |           =
;            &n=
bsp;            =
;            &n=
bsp;            =
; |


  &nbs=
p;  | CON [MID=3D1237], POST, /soap, 2:1/0/128    =
  ------>          |


  &nbs=
p;  | (no payload, when Block2 is set)     &n=
bsp;            =
;           |<=
/span>


  &nbs=
p;  | (could also do block size negotiation, requesting 2:0/0/64) &nbs=
p;|


  &nbs=
p;  |           =
;            &n=
bsp;            =
;            &n=
bsp;            =
; |


  &nbs=
p;  | <------   ACK [MID=3D1237], 2.01 Created, 2:1/1/128=
            |


  &nbs=
p;  |           =
;            &n=
bsp;            =
;            &n=
bsp;            &nbs=
p;|


  &nbs=
p;  | CON [MID=3D1238], POST, /soap, 2:2/0/128    =
  ------>          |


  &nbs=
p;  |           =
;            &n=
bsp;            =
;            &n=
bsp;            =
; |


  &nbs=
p;  | <------   ACK [MID=3D1238], 2.01 Created, 2:2/1/128=
            |


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


  &nbs=
p;  | CON [MID=3D1239], POST, /soap, 2:3/0/128    =
  ------>          |


  &nbs=
p;  |           =
;            &n=
bsp;            =
;            &n=
bsp;            =
; |


  &nbs=
p;  | <------   ACK [MID=3D1239], 2.01 Created, 2:3/0/128=
            |


&=
nbsp;


Was th=
ere anything speaking against this solution and I just forgot about it?


Please=
 discuss, especially, when you implemented Block1+Block2 POST and the c=
ombination of –block with –observe.


&=
nbsp;


Best r=
egards


Matthi=
as


&=
nbsp;






--_000_55877B3AFB359744BA0F2140E36F52B515BE7760MBX210dethzch_--

From matteo.collina@gmail.com  Mon Oct 14 02:26:00 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD7421E8184 for ; Mon, 14 Oct 2013 02:25:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2+d46D6+xcv for ; Mon, 14 Oct 2013 02:25:58 -0700 (PDT)
Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 3D29421E8160 for ; Mon, 14 Oct 2013 02:24:06 -0700 (PDT)
Received: by mail-ie0-f177.google.com with SMTP id e14so8345659iej.8 for ; Mon, 14 Oct 2013 02:24:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=A5sxoK2fgAyiGFi5SFafsYF8ETLpyxFetw8TI6OKkCw=; b=h36LzpOAlSavnMKvj3PDxEGW9Im68R+Q+a1xtn6lP+S8ODpd6eqjIQ8fMoQcCI9hza vmz5NObhPSX8rPkCuGU/QXv6eCQtEtVk8lbn5XQ/ZcO2Oymia+8amCiU9O85vRw6barV Bk1rvoEKDp8D12EX4mOfSNXJL40H2jdF6z7ZeLdFcGRXEnEBd258gRlQThoSdAcgu/7k aGtN/UZxMbCH7qEn0PiXpfDzTzkqRRrEibV87jTUPfoXM1HVeYzXLGkAtJbf758V+6gt UCCZwcm5hAbNSHiSmLH1eqllYWBYjqbmVlwdwTCS0i9xpnH44Q7kG0ujkTy304eqZ6FI Nkew==
X-Received: by 10.50.73.135 with SMTP id l7mr6596961igv.60.1381742645737; Mon, 14 Oct 2013 02:24:05 -0700 (PDT)
MIME-Version: 1.0
Sender: matteo.collina@gmail.com
Received: by 10.42.98.205 with HTTP; Mon, 14 Oct 2013 02:23:45 -0700 (PDT)
In-Reply-To: 
References:  <338D12E0-955A-4786-AB82-E1B17DD5CAA2@tzi.org> 
From: Matteo Collina 
Date: Mon, 14 Oct 2013 11:23:45 +0200
X-Google-Sender-Auth: V7GY_Eg42AStB_2HTljQJq4u3kA
Message-ID: 
To: Klaus Hartke 
Content-Type: multipart/alternative; boundary=089e0129482c91fed804e8b007d9
Cc: "core@ietf.org WG" 
Subject: Re: [core] node-coap
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Oct 2013 09:26:00 -0000

--089e0129482c91fed804e8b007d9
Content-Type: text/plain; charset=ISO-8859-1

Thank you all for the informations, I will continue implementing the
missing bits of node-coap (mainly block).

Cheers,

Matteo

--089e0129482c91fed804e8b007d9
Content-Type: text/html; charset=ISO-8859-1


Thank you all for the informations, I will continue implementing the missing bits of node-coap (mainly block).

Cheers,



Matteo


--089e0129482c91fed804e8b007d9--

From weigengyu@bupt.edu.cn  Mon Oct 14 03:26:37 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A193421F9E96 for ; Mon, 14 Oct 2013 03:26:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvxNKsSpPEeR for ; Mon, 14 Oct 2013 03:26:31 -0700 (PDT)
Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id A2F1221E815F for ; Mon, 14 Oct 2013 03:12:59 -0700 (PDT)
Received: from WeiGengyuPC (unknown [10.103.241.46]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 0DE6A19F3A0; Mon, 14 Oct 2013 18:11:31 +0800 (HKT)
Message-ID: <7BE3D5EAF615441CA2C0A5157667FDCB@WeiGengyuPC>
From: "weigengyu" 
To: "Rahman, Akbar" 
References:   
In-Reply-To: 
Date: Mon, 14 Oct 2013 18:11:29 +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 fordraft-rahman-core-sleepy-nodes-do-we-need-00.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Oct 2013 10:26:37 -0000

Hi, Akbar,

I agree that one defintion of  sleepy node is required for the WG.

Because low power state is the most important means for the mobile teminal 
to have longer working time,
the sleepy node concept should be considered.

By ROLL, sleepy node has two mode: sleep mode and normal (awake) mode.
To my knowledge,  a communication node costs more power to send than to 
receive,
so three modes, i.e.  awake, dummy, and sleep mode might be flexible.

regards,

Gengyu

-----原始邮件----- 
From: Rahman, Akbar
Sent: Saturday, October 12, 2013 12:38 PM
To: weigengyu
Cc: core@ietf.org
Subject: RE: [core] FW: New Version Notification 
fordraft-rahman-core-sleepy-nodes-do-we-need-00.txt

Thanks, Gengyu, for your support for the topic of Sleepy Nodes.

I agree that we can have different definitions of what we mean from a CORE 
perspective for a Sleepy Node.  At this point (until we adopt a WG 
deliverable for this topic) one definition is just as valid as another. 
However, it is also interesting to see what other WGs are doing.  So for 
example, in ROLL, the definition is:


http://tools.ietf.org/html/draft-ietf-roll-terminology-13


   Sleepy Node: A sleepy node is a node that may sometimes go into a
   sleep mode (i.e.  go into a low power state to conserve power) and
   temporarily suspend protocol communication.  When no in a sleep mode,
   the sleepy node is in a fully powered on state where it has the
   capability to perform communication.


And this ROLL definition, at least, is similar to the one from 
draft-dijk-core-sleepy-reqs-00



Best Regards,


Akbar



-----Original Message-----
From: weigengyu [mailto:weigengyu@bupt.edu.cn]
Sent: Friday, October 11, 2013 2:27 AM
To: Rahman, Akbar
Cc: core@ietf.org
Subject: Re: [core] FW: New Version Notification 
fordraft-rahman-core-sleepy-nodes-do-we-need-00.txt

Hi, Rahman,

My answer the question "Should we have a CORE deliverable for CoAP support 
of Sleepy Nodes?" is YES.

But I have some questions about the use cases.
According to "Sleepy Devices using CoAP - Requirements 
draft-dijk-core-sleepy-reqs-00"
the definitin of Sleeping/Asleep as following:
   Sleeping/Asleep  : A SEP being in a "sleeping state" i.e. its network 
interface is disconnected and a SEP is not able to send or receive messages.
So, a sleepy node should not start to communicate with other nodes.  The 
communication between sleepy nodes is not possible, that is given in 
"Problem statement and Use cases of Sleepy node in Constrained node networks 
draft-hong-lwig-sleepynode-problem-statement-00"

When a node is in sleeping state, it can receive, but it cannot send.
The sleeping node can be waken-up by a received message or timer expired 
event; therefore the node turns to be awake.
An alarming message may cause the sleepy node awake and then to give 
response.
The timer expired event may cause  the sleepy node awake and then to send 
heartbeat.
A node can send a message out only when it is awake.

Afterall, it is possible that the non-sleep node  initiates communication 
with a sleepy node. The sleep node is passive.
If the node in sleepy state wants to respond the message, it firstly turns 
to awake state.

regards,

Gengyu


-----原始邮件-----
From: Rahman, Akbar
Sent: Friday, October 11, 2013 11:39 AM
To: Carsten Bormann ; core@ietf.org
Subject: [core] FW: New Version Notification 
fordraft-rahman-core-sleepy-nodes-do-we-need-00.txt

Hi Carsten (and WG),


I wrote a short draft based on the following question from IETF-87 (Berlin):

"Should we have a CORE deliverable for CoAP support of Sleepy Nodes?"

http://www.ietf.org/mail-archive/web/core/current/msg04750.html



Any and all comments will be much appreciated.



Akbar

-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Thursday, October 10, 2013 11:34 PM
To: Rahman, Akbar; Rahman, Akbar
Subject: New Version Notification
fordraft-rahman-core-sleepy-nodes-do-we-need-00.txt


A new version of I-D, draft-rahman-core-sleepy-nodes-do-we-need-00.txt
has been successfully submitted by Akbar Rahman and posted to the IETF
repository.

Filename: draft-rahman-core-sleepy-nodes-do-we-need
Revision: 00
Title: Sleepy Devices: Do we need to Support them in CORE?
Creation date: 2013-10-11
Group: Individual Submission
Number of pages: 6
URL:
http://www.ietf.org/internet-drafts/draft-rahman-core-sleepy-nodes-do-we-need-00.txt
Status:
http://datatracker.ietf.org/doc/draft-rahman-core-sleepy-nodes-do-we-need
Htmlized:
http://tools.ietf.org/html/draft-rahman-core-sleepy-nodes-do-we-need-00


Abstract:
   This document summarizes the discussion in the CORE WG related to the
   question of whether support of sleepy devices is required for the
   CoAP protocol, CORE Link Format, CORE Resource Directory, etc.  The
   only goal of this document is to trigger discussions in the CORE WG
   so that all relevant considerations for sleeping devices are taken
   into account.




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 trac+core@trac.tools.ietf.org  Mon Oct 14 04:37:52 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA0621E80A5 for ; Mon, 14 Oct 2013 04:37:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.422
X-Spam-Level: 
X-Spam-Status: No, score=-101.422 tagged_above=-999 required=5 tests=[AWL=-1.123, BAYES_00=-2.599, MANGLED_WRLDWD=2.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqhrqruyI4Cu for ; Mon, 14 Oct 2013 04:37:51 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 7C41A21F9BF3 for ; Mon, 14 Oct 2013 04:37:49 -0700 (PDT)
Received: from localhost ([127.0.0.1]:40072 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VVgT0-0001fh-H8; Mon, 14 Oct 2013 13:37:42 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "core issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com
X-Trac-Project: core
Date: Mon, 14 Oct 2013 11:37:42 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/349
Message-ID: <060.a104169a666a18c3559ef8c1349b3868@trac.tools.ietf.org>
X-Trac-Ticket-ID: 349
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: akbar.rahman@interdigital.com, angelo@castellani.net, esko.dijk@philips.com, salvatore.loreto@ericsson.com, tho@koanlogic.com
Resent-Message-Id: <20131014113750.7C41A21F9BF3@ietfa.amsl.com>
Resent-Date: Mon, 14 Oct 2013 04:37:49 -0700 (PDT)
Resent-From: trac+core@trac.tools.ietf.org
Cc: core@ietf.org
Subject: [core] #349: Can we use /.well-known/core for HTTP-CoAP mapping resource?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: trac+core@trac.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Oct 2013 11:37:52 -0000

#349: Can we use /.well-known/core for HTTP-CoAP mapping resource?

 On the use of /.well-known/core for HTTP-CoAP mapping resource. Looking at
 core-coap-18:
     The "coap" URI scheme supports the path prefix "/.well-known/"
     defined by [RFC5785] for "well-known locations" in the name-space of
     a host.  This enables discovery of policy or other information about
     a host ("site-wide metadata"), such as hosted resources (see
     Section 7).

 So, the main use case envisaged by CoAP seems to be the discovery of
 resources, which is not the way we are currently using it.

 Looking at RFC 5785 ("Appropriate Use of Well-Known URIs"):
     There are a number of possible ways that applications could use Well-
     known URIs.  However, in keeping with the Architecture of the World-
     Wide Web [W3C.REC-webarch-20041215], well-known URIs are not intended
     for general information retrieval or establishment of large URI
     namespaces on the Web.  Rather, they are designed to facilitate
     discovery of information on a site when it isn't practical
     to use other mechanisms;

 which confirms this view. Our proposed use in http-mapping-02 is clearly
 not discovery related.

 Possible resolutions of this issue are:
 1) Do it anyway (follow http-mapping-02), arguments are 'ease of use' and
 'avoid extra discovery step'
 2) Make discovery of the http-coap mapping entry point (resource) a first
 step in the process. This would be done e.g. by querying /.well-known/core
 for the resource type (rt) of the mapping function.

 In any case a resource type for http-coap mapping needs to be defined to
 allow the discovery-based approach 2) above.

 (Thanks to Angelo and Thomas for providing input on this ticket)

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-core-http-
  esko.dijk@philips.com  |  mapping@tools.ietf.org
     Type:  protocol     |     Status:  new
  defect                 |  Milestone:
 Priority:  major        |    Version:
Component:  http-        |   Keywords:
  mapping                |
 Severity:  -            |
-------------------------+-------------------------------------------------

Ticket URL: 
core 


From zach@sensinode.com  Mon Oct 14 09:15:08 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 858BD11E815A for ; Mon, 14 Oct 2013 09:15:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yedizwDB80gj for ; Mon, 14 Oct 2013 09:14:57 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 5E48121F9EB5 for ; Mon, 14 Oct 2013 09:14:55 -0700 (PDT)
Received: from zach-shelby.local.tld (74-61-154-122.sfo.clearwire-wmx.net [74.61.154.122] (may be forged)) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r9EGEPSF019471 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 14 Oct 2013 19:14:29 +0300
X-Authenticated-User: sensinodecom
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Zach Shelby 
In-Reply-To: 
Date: Mon, 14 Oct 2013 09:14:28 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   
To: "Rahman, Akbar" 
X-Mailer: Apple Mail (2.1508)
Cc: core@ietf.org
Subject: Re: [core] New Version Notification fordraft-rahman-core-sleepy-nodes-do-we-need-00.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Oct 2013 16:15:08 -0000

Hi,

I think "Sleepy Nodes" really misses the broader point. What we are =
really dealing with is a node with intermittent reachability, "I'll call =
you, don't call me". Sleeping might just be one reason why this happens, =
a NAT is another even more common one. And on cellular networks nodes =
typically come on the network just long enough to get their business =
done.=20

In the OMA Lightweight standard, the mechanism that uses CoAP to solve =
this problem was just called a "queue mode". This is in practice =
realised with a Proxy and an RD in the same box. An RD registration =
parameter is used to indicate that a node is in queue mode. =46rom there =
on the proxy queues all incoming requests to the node, which are =
released upon reception of a registration update request from the node. =
If the WG wants, this could fairly easily be documented in the Resource =
Directory draft maintaining compatibility with OMA Lightweight.=20

Although Mirror Server is a useful paradigm for some use cases (and we =
should eventually document it), I find it less useful as it limits the =
REST operations that can be performed.

Zach=20

On Oct 11, 2013, at 9:38 PM, "Rahman, Akbar" =
 wrote:

> Thanks, Gengyu, for your support for the topic of Sleepy Nodes.
>=20
> I agree that we can have different definitions of what we mean from a =
CORE perspective for a Sleepy Node.  At this point (until we adopt a WG =
deliverable for this topic) one definition is just as valid as another.  =
However, it is also interesting to see what other WGs are doing.  So for =
example, in ROLL, the definition is:
>=20
>=20
> http://tools.ietf.org/html/draft-ietf-roll-terminology-13
>=20
>=20
>   Sleepy Node: A sleepy node is a node that may sometimes go into a
>   sleep mode (i.e.  go into a low power state to conserve power) and
>   temporarily suspend protocol communication.  When no in a sleep =
mode,
>   the sleepy node is in a fully powered on state where it has the
>   capability to perform communication.
>=20
>=20
> And this ROLL definition, at least, is similar to the one from =
draft-dijk-core-sleepy-reqs-00
>=20
>=20
>=20
> Best Regards,
>=20
>=20
> Akbar
>=20
>=20
>=20
> -----Original Message-----
> From: weigengyu [mailto:weigengyu@bupt.edu.cn]=20
> Sent: Friday, October 11, 2013 2:27 AM
> To: Rahman, Akbar
> Cc: core@ietf.org
> Subject: Re: [core] FW: New Version Notification =
fordraft-rahman-core-sleepy-nodes-do-we-need-00.txt
>=20
> Hi, Rahman,
>=20
> My answer the question "Should we have a CORE deliverable for CoAP =
support of Sleepy Nodes?" is YES.
>=20
> But I have some questions about the use cases.
> According to "Sleepy Devices using CoAP - Requirements =
draft-dijk-core-sleepy-reqs-00"
> the definitin of Sleeping/Asleep as following:
>   Sleeping/Asleep  : A SEP being in a "sleeping state" i.e. its =
network interface is disconnected and a SEP is not able to send or =
receive messages.
> So, a sleepy node should not start to communicate with other nodes.  =
The communication between sleepy nodes is not possible, that is given in =
"Problem statement and Use cases of Sleepy node in Constrained node =
networks draft-hong-lwig-sleepynode-problem-statement-00"
>=20
> When a node is in sleeping state, it can receive, but it cannot send.
> The sleeping node can be waken-up by a received message or timer =
expired event; therefore the node turns to be awake.
> An alarming message may cause the sleepy node awake and then to give =
response.
> The timer expired event may cause  the sleepy node awake and then to =
send heartbeat.
> A node can send a message out only when it is awake.
>=20
> Afterall, it is possible that the non-sleep node  initiates =
communication with a sleepy node. The sleep node is passive.
> If the node in sleepy state wants to respond the message, it firstly =
turns to awake state.
>=20
> regards,
>=20
> Gengyu
>=20
>=20
> -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6-----
> From: Rahman, Akbar
> Sent: Friday, October 11, 2013 11:39 AM
> To: Carsten Bormann ; core@ietf.org
> Subject: [core] FW: New Version Notification =
fordraft-rahman-core-sleepy-nodes-do-we-need-00.txt
>=20
> Hi Carsten (and WG),
>=20
>=20
> I wrote a short draft based on the following question from IETF-87 =
(Berlin):
>=20
> "Should we have a CORE deliverable for CoAP support of Sleepy Nodes?"
>=20
> http://www.ietf.org/mail-archive/web/core/current/msg04750.html
>=20
>=20
>=20
> Any and all comments will be much appreciated.
>=20
>=20
>=20
> Akbar
>=20
> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> Sent: Thursday, October 10, 2013 11:34 PM
> To: Rahman, Akbar; Rahman, Akbar
> Subject: New Version Notification
> fordraft-rahman-core-sleepy-nodes-do-we-need-00.txt
>=20
>=20
> A new version of I-D, draft-rahman-core-sleepy-nodes-do-we-need-00.txt
> has been successfully submitted by Akbar Rahman and posted to the IETF=20=

> repository.
>=20
> Filename: draft-rahman-core-sleepy-nodes-do-we-need
> Revision: 00
> Title: Sleepy Devices: Do we need to Support them in CORE?
> Creation date: 2013-10-11
> Group: Individual Submission
> Number of pages: 6
> URL:=20
> =
http://www.ietf.org/internet-drafts/draft-rahman-core-sleepy-nodes-do-we-n=
eed-00.txt
> Status:=20
> =
http://datatracker.ietf.org/doc/draft-rahman-core-sleepy-nodes-do-we-need
> Htmlized:=20
> =
http://tools.ietf.org/html/draft-rahman-core-sleepy-nodes-do-we-need-00
>=20
>=20
> Abstract:
>   This document summarizes the discussion in the CORE WG related to =
the
>   question of whether support of sleepy devices is required for the
>   CoAP protocol, CORE Link Format, CORE Resource Directory, etc.  The
>   only goal of this document is to trigger discussions in the CORE WG
>   so that all relevant considerations for sleeping devices are taken
>   into account.
>=20
>=20
>=20
>=20
> Please note that it may take a couple of minutes from the time of =
submission=20
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> The IETF Secretariat
>=20
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core=20
>=20
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core

--=20
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com @SensinodeIoT
Mobile: +358 40 7796297
Twitter: @zach_shelby
LinkedIn: http://fi.linkedin.com/in/zachshelby
6LoWPAN Book: http://6lowpan.net





From internet-drafts@ietf.org  Tue Oct 15 02:54:14 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00E2921E80E7; Tue, 15 Oct 2013 02:54:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.587
X-Spam-Level: 
X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RL+8j7OUgtyo; Tue, 15 Oct 2013 02:54:13 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B846021E8109; Tue, 15 Oct 2013 02:54:10 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.80.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131015095410.2100.92494.idtracker@ietfa.amsl.com>
Date: Tue, 15 Oct 2013 02:54:10 -0700
Cc: core@ietf.org
Subject: [core] I-D Action: draft-ietf-core-observe-11.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Oct 2013 09:54:14 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Constrained RESTful Environments Working =
Group of the IETF.

	Title           : Observing Resources in CoAP
	Author(s)       : Klaus Hartke
	Filename        : draft-ietf-core-observe-11.txt
	Pages           : 31
	Date            : 2013-10-15

Abstract:
   CoAP is a RESTful application protocol for constrained nodes and
   networks.  The state of a resource on a CoAP server can change over
   time.  This document specifies a simple protocol extension for CoAP
   that enables CoAP clients to "observe" resources, i.e., to retrieve
   a representation of a resource and keep this representation updated
   by the server over a period of time.  The protocol follows a best-
   effort approach for sending new representations to clients and
   provides eventual consistency between the state observed by each
   client and the actual resource state at the server.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-core-observe

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-core-observe-11

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-observe-11


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 hartke@tzi.org  Tue Oct 15 02:57:09 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA1711E8175 for ; Tue, 15 Oct 2013 02:57:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.627
X-Spam-Level: 
X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eu78si3u1KyL for ; Tue, 15 Oct 2013 02:57:03 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 004B911E817D for ; Tue, 15 Oct 2013 02:56:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9F9usgu019116 for ; Tue, 15 Oct 2013 11:56:54 +0200 (CEST)
Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C4953A1F for ; Tue, 15 Oct 2013 11:56:53 +0200 (CEST)
Received: by mail-vc0-f174.google.com with SMTP id ie18so1023484vcb.5 for ; Tue, 15 Oct 2013 02:56:52 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=no/PwMOHmMQL2/HO38J5xSF5gaAgH+7jOssV2XylUlU=; b=TtWoH5QT+to0FpTvwEIrsg0JvvhAwWaO6ZLAYrztM9GL1G3cFAiP3ij48kAEom951v jYWq9fq37ICpgj6DNMHuauL7Qts081PowYO4LJ0daeaX3GdwO0lwEhWG+ydTdjE8zZP8 Q1eft08JUG3qc+V4Gz5gCfry4wvLyOMOd9TqX0RGTTgB9CmLWvLcBjOK157DNkZvgoWv BdNqy5YuCCKWq69QRS9rbjRt0f+vmudUUESZYvqLkV79IeN50UHYbM8qyA+hWIgbZWiI ReoIIEk1AIPT6mH2I6FtUsjEht3uQ48sev5RmzDg1cpTCS90rxMtuknuq40JdWPwBaXV /IzQ==
X-Received: by 10.52.22.110 with SMTP id c14mr105657vdf.28.1381831012356; Tue, 15 Oct 2013 02:56:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.24.83 with HTTP; Tue, 15 Oct 2013 02:56:12 -0700 (PDT)
In-Reply-To: <20131015095410.2100.92494.idtracker@ietfa.amsl.com>
References: <20131015095410.2100.92494.idtracker@ietfa.amsl.com>
From: Klaus Hartke 
Date: Tue, 15 Oct 2013 12:56:12 +0300
Message-ID: 
To: "core@ietf.org WG" 
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [core] I-D Action: draft-ietf-core-observe-11.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Oct 2013 09:57:09 -0000

draft-ietf-core-observe-11 is the latest in a long series of updates
that resulted from the numerous comments on both
draft-ietf-core-observe and draft-ietf-core-coap from the first WGLC.

I'm glad to report that this revision now has all remaining issues
resolved. (There is, of course, always room for improvement.) It can
be found at:

        http://tools.ietf.org/html/draft-ietf-core-observe-11

Diff from -10:

        http://www.ietf.org/rfcdiff?url2=draft-ietf-core-observe-11

Best regards,
Klaus

On 15 October 2013 12:54,   wrote:
>
> 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           : Observing Resources in CoAP
>         Author(s)       : Klaus Hartke
>         Filename        : draft-ietf-core-observe-11.txt
>         Pages           : 31
>         Date            : 2013-10-15
>
> Abstract:
>    CoAP is a RESTful application protocol for constrained nodes and
>    networks.  The state of a resource on a CoAP server can change over
>    time.  This document specifies a simple protocol extension for CoAP
>    that enables CoAP clients to "observe" resources, i.e., to retrieve
>    a representation of a resource and keep this representation updated
>    by the server over a period of time.  The protocol follows a best-
>    effort approach for sending new representations to clients and
>    provides eventual consistency between the state observed by each
>    client and the actual resource state at the server.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-core-observe
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-core-observe-11
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-core-observe-11
>
>
> 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 cabo@tzi.org  Tue Oct 15 03:46:17 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C97D11E81C9 for ; Tue, 15 Oct 2013 03:46:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.023
X-Spam-Level: 
X-Spam-Status: No, score=-106.023 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2lkOItLzVdD for ; Tue, 15 Oct 2013 03:46:06 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 7A83921F9E96 for ; Tue, 15 Oct 2013 03:45:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9FAjs9K024959 for ; Tue, 15 Oct 2013 12:45:54 +0200 (CEST)
Received: from [10.0.1.4] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id CCBBFA8B; Tue, 15 Oct 2013 12:45:54 +0200 (CEST)
From: Carsten Bormann 
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Date: Tue, 15 Oct 2013 12:45:54 +0200
To: "core@ietf.org WG" 
Message-Id: <5A6D74B4-3733-45D1-95B1-E838DADED234@tzi.org>
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
X-Mailer: Apple Mail (2.1510)
Subject: [core] =?utf-8?q?=F0=9F=94=94_WGLC_of_draft-ietf-core-observe-11?=
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Oct 2013 10:46:17 -0000

After this WG has focused on completing the base specification for a
while, it is time to finish the two complementing specifications,
-observe and -block.  -observe is first:

draft-ietf-core-observe-11 clears all remaining issues in the tracker.
Thanks go to Klaus for patiently addressing all those details.

This starts a second working group last call for -observe, ending on

	24:00 PDT on Tuesday, October 29, 2013.

Please start a new email thread for each major issues 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.

We did an IPR call on the first WGLC, but since that some time has =
elapsed:

If you are aware of any patent claims that might apply to systems that
implement these drafts, 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.

While everyone may still be a bit tired from completing core-coap (and
we are still waiting for the two missing references to go to the RFC
editor), it is important that we all go and review -observe as well.
The people that have participated heavily have read the draft so many
times that they have a hard time noticing what is wrong or missing
from them but fresh eyes can help.  We know that everyone has many
documents to read for the upcoming IETF, but we would like to try and
convince you that reading drafts that are in WGLC is probably more
important than many others.  Please help us get this right.

Gr=FC=DFe, Carsten


From stokcons@xs4all.nl  Tue Oct 15 04:49:34 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2523D11E8128 for ; Tue, 15 Oct 2013 04:49:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.154
X-Spam-Level: 
X-Spam-Status: No, score=-0.154 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybeZRySyI1QM for ; Tue, 15 Oct 2013 04:49:28 -0700 (PDT)
Received: from smtp-vbr5.xs4all.nl (smtp-vbr5.xs4all.nl [194.109.24.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4AA21F9AA8 for ; Tue, 15 Oct 2013 04:49:28 -0700 (PDT)
Received: from roundcube.xs4all.nl (roundcube11.xs4all.net [194.109.20.209]) by smtp-vbr5.xs4all.nl (8.13.8/8.13.8) with ESMTP id r9FBnQqi075628; Tue, 15 Oct 2013 13:49:26 +0200 (CEST) (envelope-from stokcons@xs4all.nl)
Received: from AMontpellier-654-1-218-197.w109-210.abo.wanadoo.fr ([109.210.93.197]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 15 Oct 2013 13:49:26 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Date: Tue, 15 Oct 2013 13:49:26 +0200
From: peter van der Stok 
To: Core , akbar rahman 
Organization: vanderstok consultancy
Mail-Reply-To: consultancy@vanderstok.org
Message-ID: <49802db7bb1d96cfccc488402a8bcc77@xs4all.nl>
X-Sender: stokcons@xs4all.nl (cBor3ab/hCu24+QIii+aaYcvmmMWo37g)
User-Agent: XS4ALL Webmail
X-Virus-Scanned: by XS4ALL Virus Scanner
Subject: [core] sleepy nodes
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: consultancy@vanderstok.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Oct 2013 11:49:34 -0000

Dear all,


reading the draft on the need for sleepy nodes by Akbar, I become more 
convinced that the subject is not right for IETF.
Already defining a sleepy node is fraught with application oriented 
aspects.
Taking the advice of Zach, that you only want to define a proxy leaves 
also many possibilities open, like:

Does the sleepy node communicate only with the proxy?
Can the sleepy node send to other nodes than the proxy via multicast or 
unicast?
Does the sleepy node need maintenance?
Is the sleepy node initialized at the factory and it never listens to 
any messages afterwards?
Or is there an initialization capability, eventually supported by a 
battery recharge.


I can go on and on like this, (for example on timing constraints) and 
none of the questions will get satisfactory unanimous answers.
Therefore, I remain with my conclusion that sleepy nodes are interesting 
but too much conditioned by application constraints to define a proxy 
approach that is generally applicable.

If anything needs to be done I still think that the "mirror server" 
draft is the best choice because I recognize the boundary conditions.
But the latter is a very application biased opinion.

Peter

-- 
Peter van der Stok
mailto: consultancy@vanderstok.org
www: www.vanderstok.org
tel NL: +31(0)492474673     F: +33(0)966015248

From wwwrun@rfc-editor.org  Tue Oct 15 06:27:37 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D305D11E81DA for ; Tue, 15 Oct 2013 06:27:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.453
X-Spam-Level: 
X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 093Jea29zZrj for ; Tue, 15 Oct 2013 06:27:37 -0700 (PDT)
Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 105E411E81E0 for ; Tue, 15 Oct 2013 06:27:37 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 78E42B1E049; Tue, 15 Oct 2013 06:19:30 -0700 (PDT)
To: zach@sensinode.com, barryleiba@computer.org, presnick@qti.qualcomm.com, cabo@tzi.org, andrewmcgr@google.com
From: RFC Errata System 
Message-Id: <20131015131930.78E42B1E049@rfc-editor.org>
Date: Tue, 15 Oct 2013 06:19:30 -0700 (PDT)
Cc: core@ietf.org, rfc-editor@rfc-editor.org
Subject: [core] [Editorial Errata Reported] RFC6690 (3751)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Oct 2013 13:27:38 -0000

The following errata report has been submitted for RFC6690,
"Constrained RESTful Environments (CoRE) Link Format".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6690&eid=3751

--------------------------------------
Type: Editorial
Reported by: Peter A. Bigot 

Section: 2

Original Text
-------------
   URI-Reference  = 
 

Corrected Text
--------------
   URI-reference  = 
 

Notes
-----
Although RFC5234 does specify that rule names are case-insensitive, URI-reference is "misspelled" URI-Reference throughout ABNF rules in section 2.  It is correct in the remainder of the text.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6690 (draft-ietf-core-link-format-14)
--------------------------------------
Title               : Constrained RESTful Environments (CoRE) Link Format
Publication Date    : August 2012
Author(s)           : Z. Shelby
Category            : PROPOSED STANDARD
Source              : Constrained RESTful Environments
Area                : Applications
Stream              : IETF
Verifying Party     : IESG

From Akbar.Rahman@InterDigital.com  Tue Oct 15 10:26:07 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC29811E8147 for ; Tue, 15 Oct 2013 10:26:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HWiF6RgHalp for ; Tue, 15 Oct 2013 10:26:04 -0700 (PDT)
Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id D453211E81F7 for ; Tue, 15 Oct 2013 10:26:02 -0700 (PDT)
Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 15 Oct 2013 13:26:02 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Date: Tue, 15 Oct 2013 13:26:01 -0400
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [core] New Version Notification fordraft-rahman-core-sleepy-nodes-do-we-need-00.txt
Thread-Index: Ac7I+JvDEJ5PJ6NhSAS947r3CQtjJgA0imCA
References:    
From: "Rahman, Akbar" 
To: "Zach Shelby" 
X-OriginalArrivalTime: 15 Oct 2013 17:26:02.0156 (UTC) FILETIME=[9EE33EC0:01CEC9CB]
Cc: core@ietf.org
Subject: Re: [core] New Version Notification fordraft-rahman-core-sleepy-nodes-do-we-need-00.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Oct 2013 17:26:07 -0000

SGkgWmFjaCwNCg0KDQpUaGFua3MgZm9yIHRoZSBmZWVkYmFjay4gIEkgZG8gc3VwcG9ydCB5b3Vy
IHN1Z2dlc3Rpb24gb2Y6DQoNCgkiVGhpcyBpcyBpbiBwcmFjdGljZSByZWFsaXNlZCB3aXRoIGEg
UHJveHkgYW5kIGFuIFJEIGluIHRoZSBzYW1lIGJveC4gQW4gUkQgcmVnaXN0cmF0aW9uIHBhcmFt
ZXRlciBpcyB1c2VkIHRvIGluZGljYXRlIHRoYXQgYSBub2RlIGlzIGluIHF1ZXVlIAltb2RlLiBG
cm9tIHRoZXJlIG9uIHRoZSBwcm94eSBxdWV1ZXMgYWxsIGluY29taW5nIHJlcXVlc3RzIHRvIHRo
ZSBub2RlLCB3aGljaCBhcmUgcmVsZWFzZWQgdXBvbiByZWNlcHRpb24gb2YgYSByZWdpc3RyYXRp
b24gdXBkYXRlIHJlcXVlc3QgZnJvbSB0aGUgCW5vZGUuIElmIHRoZSBXRyB3YW50cywgdGhpcyBj
b3VsZCBmYWlybHkgZWFzaWx5IGJlIGRvY3VtZW50ZWQgaW4gdGhlIFJlc291cmNlIERpcmVjdG9y
eSBkcmFmdCBtYWludGFpbmluZyBjb21wYXRpYmlsaXR5IHdpdGggT01BIExpZ2h0d2VpZ2h0LiIN
Cg0KDQpJIHRoaW5rIHRoaXMgd291bGQgYmUgYSBnb29kIGZpcnN0IHN0ZXAgdG8gc3VwcG9ydGlu
ZyB0aGVzZSB0eXBlIG9mICJpbnRlcm1pdHRlbnQgcmVhY2hhYmlsaXR5IiBub2Rlcy4gIEJ1IGl0
IHdvdWxkIHN0aWxsIGJlIHdvcnRoIGhhdmluZyBhIGRpc2N1c3Npb24gdG8gc2VlIGlmIHdlIG5l
ZWQgdG8gc3VwcG9ydCBtb3JlIGVsYWJvcmF0ZSBzb2x1dGlvbnMgbGlrZSB0aGUgTWlycm9yIFNl
cnZlci4gIFRoZSBhbnN3ZXIgY2FuIGFsd2F5cyBiZSAiTm8gKGF0IGxlYXN0IG5vdCBpbiBDT1JF
KSIuICBCdXQgdW50aWwgd2UgaGF2ZSB0aGUgZGlzY3Vzc2lvbiB3ZSBjYW5ub3QgcmVhbGx5IGNv
bmNsdWRlIHRoYXQuDQoNCg0KQmVzdCBSZWdhcmRzLA0KDQoNCkFrYmFyDQoNCg0KDQotLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogWmFjaCBTaGVsYnkgW21haWx0bzp6YWNoQHNlbnNp
bm9kZS5jb21dIA0KU2VudDogTW9uZGF5LCBPY3RvYmVyIDE0LCAyMDEzIDEyOjE0IFBNDQpUbzog
UmFobWFuLCBBa2Jhcg0KQ2M6IHdlaWdlbmd5dTsgY29yZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6
IFtjb3JlXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yZHJhZnQtcmFobWFuLWNvcmUtc2xl
ZXB5LW5vZGVzLWRvLXdlLW5lZWQtMDAudHh0DQoNCkhpLA0KDQpJIHRoaW5rICJTbGVlcHkgTm9k
ZXMiIHJlYWxseSBtaXNzZXMgdGhlIGJyb2FkZXIgcG9pbnQuIFdoYXQgd2UgYXJlIHJlYWxseSBk
ZWFsaW5nIHdpdGggaXMgYSBub2RlIHdpdGggaW50ZXJtaXR0ZW50IHJlYWNoYWJpbGl0eSwgIkkn
bGwgY2FsbCB5b3UsIGRvbid0IGNhbGwgbWUiLiBTbGVlcGluZyBtaWdodCBqdXN0IGJlIG9uZSBy
ZWFzb24gd2h5IHRoaXMgaGFwcGVucywgYSBOQVQgaXMgYW5vdGhlciBldmVuIG1vcmUgY29tbW9u
IG9uZS4gQW5kIG9uIGNlbGx1bGFyIG5ldHdvcmtzIG5vZGVzIHR5cGljYWxseSBjb21lIG9uIHRo
ZSBuZXR3b3JrIGp1c3QgbG9uZyBlbm91Z2ggdG8gZ2V0IHRoZWlyIGJ1c2luZXNzIGRvbmUuIA0K
DQpJbiB0aGUgT01BIExpZ2h0d2VpZ2h0IHN0YW5kYXJkLCB0aGUgbWVjaGFuaXNtIHRoYXQgdXNl
cyBDb0FQIHRvIHNvbHZlIHRoaXMgcHJvYmxlbSB3YXMganVzdCBjYWxsZWQgYSAicXVldWUgbW9k
ZSIuIFRoaXMgaXMgaW4gcHJhY3RpY2UgcmVhbGlzZWQgd2l0aCBhIFByb3h5IGFuZCBhbiBSRCBp
biB0aGUgc2FtZSBib3guIEFuIFJEIHJlZ2lzdHJhdGlvbiBwYXJhbWV0ZXIgaXMgdXNlZCB0byBp
bmRpY2F0ZSB0aGF0IGEgbm9kZSBpcyBpbiBxdWV1ZSBtb2RlLiBGcm9tIHRoZXJlIG9uIHRoZSBw
cm94eSBxdWV1ZXMgYWxsIGluY29taW5nIHJlcXVlc3RzIHRvIHRoZSBub2RlLCB3aGljaCBhcmUg
cmVsZWFzZWQgdXBvbiByZWNlcHRpb24gb2YgYSByZWdpc3RyYXRpb24gdXBkYXRlIHJlcXVlc3Qg
ZnJvbSB0aGUgbm9kZS4gSWYgdGhlIFdHIHdhbnRzLCB0aGlzIGNvdWxkIGZhaXJseSBlYXNpbHkg
YmUgZG9jdW1lbnRlZCBpbiB0aGUgUmVzb3VyY2UgRGlyZWN0b3J5IGRyYWZ0IG1haW50YWluaW5n
IGNvbXBhdGliaWxpdHkgd2l0aCBPTUEgTGlnaHR3ZWlnaHQuIA0KDQpBbHRob3VnaCBNaXJyb3Ig
U2VydmVyIGlzIGEgdXNlZnVsIHBhcmFkaWdtIGZvciBzb21lIHVzZSBjYXNlcyAoYW5kIHdlIHNo
b3VsZCBldmVudHVhbGx5IGRvY3VtZW50IGl0KSwgSSBmaW5kIGl0IGxlc3MgdXNlZnVsIGFzIGl0
IGxpbWl0cyB0aGUgUkVTVCBvcGVyYXRpb25zIHRoYXQgY2FuIGJlIHBlcmZvcm1lZC4NCg0KWmFj
aCANCg0KT24gT2N0IDExLCAyMDEzLCBhdCA5OjM4IFBNLCAiUmFobWFuLCBBa2JhciIgPEFrYmFy
LlJhaG1hbkBJbnRlckRpZ2l0YWwuY29tPiB3cm90ZToNCg0KPiBUaGFua3MsIEdlbmd5dSwgZm9y
IHlvdXIgc3VwcG9ydCBmb3IgdGhlIHRvcGljIG9mIFNsZWVweSBOb2Rlcy4NCj4gDQo+IEkgYWdy
ZWUgdGhhdCB3ZSBjYW4gaGF2ZSBkaWZmZXJlbnQgZGVmaW5pdGlvbnMgb2Ygd2hhdCB3ZSBtZWFu
IGZyb20gYSBDT1JFIHBlcnNwZWN0aXZlIGZvciBhIFNsZWVweSBOb2RlLiAgQXQgdGhpcyBwb2lu
dCAodW50aWwgd2UgYWRvcHQgYSBXRyBkZWxpdmVyYWJsZSBmb3IgdGhpcyB0b3BpYykgb25lIGRl
ZmluaXRpb24gaXMganVzdCBhcyB2YWxpZCBhcyBhbm90aGVyLiAgSG93ZXZlciwgaXQgaXMgYWxz
byBpbnRlcmVzdGluZyB0byBzZWUgd2hhdCBvdGhlciBXR3MgYXJlIGRvaW5nLiAgU28gZm9yIGV4
YW1wbGUsIGluIFJPTEwsIHRoZSBkZWZpbml0aW9uIGlzOg0KPiANCj4gDQo+IGh0dHA6Ly90b29s
cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcm9sbC10ZXJtaW5vbG9neS0xMw0KPiANCj4gDQo+
ICAgU2xlZXB5IE5vZGU6IEEgc2xlZXB5IG5vZGUgaXMgYSBub2RlIHRoYXQgbWF5IHNvbWV0aW1l
cyBnbyBpbnRvIGENCj4gICBzbGVlcCBtb2RlIChpLmUuICBnbyBpbnRvIGEgbG93IHBvd2VyIHN0
YXRlIHRvIGNvbnNlcnZlIHBvd2VyKSBhbmQNCj4gICB0ZW1wb3JhcmlseSBzdXNwZW5kIHByb3Rv
Y29sIGNvbW11bmljYXRpb24uICBXaGVuIG5vIGluIGEgc2xlZXAgbW9kZSwNCj4gICB0aGUgc2xl
ZXB5IG5vZGUgaXMgaW4gYSBmdWxseSBwb3dlcmVkIG9uIHN0YXRlIHdoZXJlIGl0IGhhcyB0aGUN
Cj4gICBjYXBhYmlsaXR5IHRvIHBlcmZvcm0gY29tbXVuaWNhdGlvbi4NCj4gDQo+IA0KPiBBbmQg
dGhpcyBST0xMIGRlZmluaXRpb24sIGF0IGxlYXN0LCBpcyBzaW1pbGFyIHRvIHRoZSBvbmUgZnJv
bSANCj4gZHJhZnQtZGlqay1jb3JlLXNsZWVweS1yZXFzLTAwDQo+IA0KPiANCj4gDQo+IEJlc3Qg
UmVnYXJkcywNCj4gDQo+IA0KPiBBa2Jhcg0KPiANCj4gDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1l
c3NhZ2UtLS0tLQ0KPiBGcm9tOiB3ZWlnZW5neXUgW21haWx0bzp3ZWlnZW5neXVAYnVwdC5lZHUu
Y25dDQo+IFNlbnQ6IEZyaWRheSwgT2N0b2JlciAxMSwgMjAxMyAyOjI3IEFNDQo+IFRvOiBSYWht
YW4sIEFrYmFyDQo+IENjOiBjb3JlQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbY29yZV0gRlc6
IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiANCj4gZm9yZHJhZnQtcmFobWFuLWNvcmUtc2xlZXB5
LW5vZGVzLWRvLXdlLW5lZWQtMDAudHh0DQo+IA0KPiBIaSwgUmFobWFuLA0KPiANCj4gTXkgYW5z
d2VyIHRoZSBxdWVzdGlvbiAiU2hvdWxkIHdlIGhhdmUgYSBDT1JFIGRlbGl2ZXJhYmxlIGZvciBD
b0FQIHN1cHBvcnQgb2YgU2xlZXB5IE5vZGVzPyIgaXMgWUVTLg0KPiANCj4gQnV0IEkgaGF2ZSBz
b21lIHF1ZXN0aW9ucyBhYm91dCB0aGUgdXNlIGNhc2VzLg0KPiBBY2NvcmRpbmcgdG8gIlNsZWVw
eSBEZXZpY2VzIHVzaW5nIENvQVAgLSBSZXF1aXJlbWVudHMgZHJhZnQtZGlqay1jb3JlLXNsZWVw
eS1yZXFzLTAwIg0KPiB0aGUgZGVmaW5pdGluIG9mIFNsZWVwaW5nL0FzbGVlcCBhcyBmb2xsb3dp
bmc6DQo+ICAgU2xlZXBpbmcvQXNsZWVwICA6IEEgU0VQIGJlaW5nIGluIGEgInNsZWVwaW5nIHN0
YXRlIiBpLmUuIGl0cyBuZXR3b3JrIGludGVyZmFjZSBpcyBkaXNjb25uZWN0ZWQgYW5kIGEgU0VQ
IGlzIG5vdCBhYmxlIHRvIHNlbmQgb3IgcmVjZWl2ZSBtZXNzYWdlcy4NCj4gU28sIGEgc2xlZXB5
IG5vZGUgc2hvdWxkIG5vdCBzdGFydCB0byBjb21tdW5pY2F0ZSB3aXRoIG90aGVyIG5vZGVzLiAg
VGhlIGNvbW11bmljYXRpb24gYmV0d2VlbiBzbGVlcHkgbm9kZXMgaXMgbm90IHBvc3NpYmxlLCB0
aGF0IGlzIGdpdmVuIGluICJQcm9ibGVtIHN0YXRlbWVudCBhbmQgVXNlIGNhc2VzIG9mIFNsZWVw
eSBub2RlIGluIENvbnN0cmFpbmVkIG5vZGUgbmV0d29ya3MgZHJhZnQtaG9uZy1sd2lnLXNsZWVw
eW5vZGUtcHJvYmxlbS1zdGF0ZW1lbnQtMDAiDQo+IA0KPiBXaGVuIGEgbm9kZSBpcyBpbiBzbGVl
cGluZyBzdGF0ZSwgaXQgY2FuIHJlY2VpdmUsIGJ1dCBpdCBjYW5ub3Qgc2VuZC4NCj4gVGhlIHNs
ZWVwaW5nIG5vZGUgY2FuIGJlIHdha2VuLXVwIGJ5IGEgcmVjZWl2ZWQgbWVzc2FnZSBvciB0aW1l
ciBleHBpcmVkIGV2ZW50OyB0aGVyZWZvcmUgdGhlIG5vZGUgdHVybnMgdG8gYmUgYXdha2UuDQo+
IEFuIGFsYXJtaW5nIG1lc3NhZ2UgbWF5IGNhdXNlIHRoZSBzbGVlcHkgbm9kZSBhd2FrZSBhbmQg
dGhlbiB0byBnaXZlIHJlc3BvbnNlLg0KPiBUaGUgdGltZXIgZXhwaXJlZCBldmVudCBtYXkgY2F1
c2UgIHRoZSBzbGVlcHkgbm9kZSBhd2FrZSBhbmQgdGhlbiB0byBzZW5kIGhlYXJ0YmVhdC4NCj4g
QSBub2RlIGNhbiBzZW5kIGEgbWVzc2FnZSBvdXQgb25seSB3aGVuIGl0IGlzIGF3YWtlLg0KPiAN
Cj4gQWZ0ZXJhbGwsIGl0IGlzIHBvc3NpYmxlIHRoYXQgdGhlIG5vbi1zbGVlcCBub2RlICBpbml0
aWF0ZXMgY29tbXVuaWNhdGlvbiB3aXRoIGEgc2xlZXB5IG5vZGUuIFRoZSBzbGVlcCBub2RlIGlz
IHBhc3NpdmUuDQo+IElmIHRoZSBub2RlIGluIHNsZWVweSBzdGF0ZSB3YW50cyB0byByZXNwb25k
IHRoZSBtZXNzYWdlLCBpdCBmaXJzdGx5IHR1cm5zIHRvIGF3YWtlIHN0YXRlLg0KPiANCj4gcmVn
YXJkcywNCj4gDQo+IEdlbmd5dQ0KPiANCj4gDQo+IC0tLS0t5Y6f5aeL6YKu5Lu2LS0tLS0NCj4g
RnJvbTogUmFobWFuLCBBa2Jhcg0KPiBTZW50OiBGcmlkYXksIE9jdG9iZXIgMTEsIDIwMTMgMTE6
MzkgQU0NCj4gVG86IENhcnN0ZW4gQm9ybWFubiA7IGNvcmVAaWV0Zi5vcmcNCj4gU3ViamVjdDog
W2NvcmVdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gDQo+IGZvcmRyYWZ0LXJhaG1hbi1j
b3JlLXNsZWVweS1ub2Rlcy1kby13ZS1uZWVkLTAwLnR4dA0KPiANCj4gSGkgQ2Fyc3RlbiAoYW5k
IFdHKSwNCj4gDQo+IA0KPiBJIHdyb3RlIGEgc2hvcnQgZHJhZnQgYmFzZWQgb24gdGhlIGZvbGxv
d2luZyBxdWVzdGlvbiBmcm9tIElFVEYtODcgKEJlcmxpbik6DQo+IA0KPiAiU2hvdWxkIHdlIGhh
dmUgYSBDT1JFIGRlbGl2ZXJhYmxlIGZvciBDb0FQIHN1cHBvcnQgb2YgU2xlZXB5IE5vZGVzPyIN
Cj4gDQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9jb3JlL2N1cnJlbnQv
bXNnMDQ3NTAuaHRtbA0KPiANCj4gDQo+IA0KPiBBbnkgYW5kIGFsbCBjb21tZW50cyB3aWxsIGJl
IG11Y2ggYXBwcmVjaWF0ZWQuDQo+IA0KPiANCj4gDQo+IEFrYmFyDQo+IA0KPiAtLS0tLU9yaWdp
bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0
bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDEw
LCAyMDEzIDExOjM0IFBNDQo+IFRvOiBSYWhtYW4sIEFrYmFyOyBSYWhtYW4sIEFrYmFyDQo+IFN1
YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbg0KPiBmb3JkcmFmdC1yYWhtYW4tY29yZS1z
bGVlcHktbm9kZXMtZG8td2UtbmVlZC0wMC50eHQNCj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9m
IEktRCwgZHJhZnQtcmFobWFuLWNvcmUtc2xlZXB5LW5vZGVzLWRvLXdlLW5lZWQtMDAudHh0DQo+
IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQWtiYXIgUmFobWFuIGFuZCBwb3N0
ZWQgdG8gdGhlIElFVEYgDQo+IHJlcG9zaXRvcnkuDQo+IA0KPiBGaWxlbmFtZTogZHJhZnQtcmFo
bWFuLWNvcmUtc2xlZXB5LW5vZGVzLWRvLXdlLW5lZWQNCj4gUmV2aXNpb246IDAwDQo+IFRpdGxl
OiBTbGVlcHkgRGV2aWNlczogRG8gd2UgbmVlZCB0byBTdXBwb3J0IHRoZW0gaW4gQ09SRT8NCj4g
Q3JlYXRpb24gZGF0ZTogMjAxMy0xMC0xMQ0KPiBHcm91cDogSW5kaXZpZHVhbCBTdWJtaXNzaW9u
DQo+IE51bWJlciBvZiBwYWdlczogNg0KPiBVUkw6IA0KPiBodHRwOi8vd3d3LmlldGYub3JnL2lu
dGVybmV0LWRyYWZ0cy9kcmFmdC1yYWhtYW4tY29yZS1zbGVlcHktbm9kZXMtZG8tDQo+IHdlLW5l
ZWQtMDAudHh0DQo+IFN0YXR1czogDQo+IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv
ZHJhZnQtcmFobWFuLWNvcmUtc2xlZXB5LW5vZGVzLWRvLXdlLW4NCj4gZWVkDQo+IEh0bWxpemVk
OiANCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmFobWFuLWNvcmUtc2xlZXB5
LW5vZGVzLWRvLXdlLW5lZWQtMA0KPiAwDQo+IA0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgVGhpcyBk
b2N1bWVudCBzdW1tYXJpemVzIHRoZSBkaXNjdXNzaW9uIGluIHRoZSBDT1JFIFdHIHJlbGF0ZWQg
dG8gdGhlDQo+ICAgcXVlc3Rpb24gb2Ygd2hldGhlciBzdXBwb3J0IG9mIHNsZWVweSBkZXZpY2Vz
IGlzIHJlcXVpcmVkIGZvciB0aGUNCj4gICBDb0FQIHByb3RvY29sLCBDT1JFIExpbmsgRm9ybWF0
LCBDT1JFIFJlc291cmNlIERpcmVjdG9yeSwgZXRjLiAgVGhlDQo+ICAgb25seSBnb2FsIG9mIHRo
aXMgZG9jdW1lbnQgaXMgdG8gdHJpZ2dlciBkaXNjdXNzaW9ucyBpbiB0aGUgQ09SRSBXRw0KPiAg
IHNvIHRoYXQgYWxsIHJlbGV2YW50IGNvbnNpZGVyYXRpb25zIGZvciBzbGVlcGluZyBkZXZpY2Vz
IGFyZSB0YWtlbg0KPiAgIGludG8gYWNjb3VudC4NCj4gDQo+IA0KPiANCj4gDQo+IFBsZWFzZSBu
b3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9m
IA0KPiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBh
dmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+IA0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0K
PiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g
Y29yZSBtYWlsaW5nIGxpc3QNCj4gY29yZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fDQo+IGNvcmUgbWFpbGluZyBsaXN0DQo+IGNvcmVAaWV0Zi5v
cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQoNCi0tDQpa
YWNoIFNoZWxieSwgQ2hpZWYgTmVyZCwgU2Vuc2lub2RlIEx0ZC4NCmh0dHA6Ly93d3cuc2Vuc2lu
b2RlLmNvbSBAU2Vuc2lub2RlSW9UDQpNb2JpbGU6ICszNTggNDAgNzc5NjI5Nw0KVHdpdHRlcjog
QHphY2hfc2hlbGJ5DQpMaW5rZWRJbjogaHR0cDovL2ZpLmxpbmtlZGluLmNvbS9pbi96YWNoc2hl
bGJ5DQo2TG9XUEFOIEJvb2s6IGh0dHA6Ly82bG93cGFuLm5ldA0KDQoNCg0KDQo=

From zach@sensinode.com  Tue Oct 15 11:13:34 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E46C11E81A1 for ; Tue, 15 Oct 2013 11:13:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzaECX1tGoZ5 for ; Tue, 15 Oct 2013 11:13:29 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFBB11E8183 for ; Tue, 15 Oct 2013 11:13:26 -0700 (PDT)
Received: from [10.0.0.50] ([69.199.251.65]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r9FID8NP013429 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 15 Oct 2013 21:13:10 +0300
X-Authenticated-User: sensinodecom
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Zach Shelby 
In-Reply-To: 
Date: Tue, 15 Oct 2013 11:13:09 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <73BC38E7-0464-4219-B314-9A57430F1C48@sensinode.com>
References:     
To: "Rahman, Akbar" 
X-Mailer: Apple Mail (2.1508)
Cc: core@ietf.org
Subject: Re: [core] New Version Notification fordraft-rahman-core-sleepy-nodes-do-we-need-00.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Oct 2013 18:13:34 -0000

On Oct 15, 2013, at 10:26 AM, "Rahman, Akbar" =
 wrote:

> 	"This is in practice realised with a Proxy and an RD in the same =
box. An RD registration parameter is used to indicate that a node is in =
queue 	mode. =46rom there on the proxy queues all incoming requests to =
the node, which are released upon reception of a registration update =
request from the 	node. If the WG wants, this could fairly easily =
be documented in the Resource Directory draft maintaining compatibility =
with OMA Lightweight."

And as Peter rightly points out, if you go to far you are into lots of =
application specific issues. The trick is if we can document the bare =
minimum of the protocol and interface mechanisms needed to support those =
different applications.=20

> I think this would be a good first step to supporting these type of =
"intermittent reachability" nodes.  Bu it would still be worth having a =
discussion to see if we need to support more elaborate solutions like =
the Mirror Server.  The answer can always be "No (at least not in =
CORE)".  But until we have the discussion we cannot really conclude =
that.

Personally I do think this is worth documenting Mirror Server in the WG, =
but I don't think it solves the (intermittently reachable node) problem =
broadly enough to be a generic solution. So we should slowly move this =
towards a WG document as we get other things done first, and as there =
are people really implementing and using it.=20

Zach

--=20
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com @SensinodeIoT
Mobile: +358 40 7796297
Twitter: @zach_shelby
LinkedIn: http://fi.linkedin.com/in/zachshelby
6LoWPAN Book: http://6lowpan.net





From weigengyu@bupt.edu.cn  Tue Oct 15 19:44:07 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762E011E822D for ; Tue, 15 Oct 2013 19:44:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.298
X-Spam-Level: 
X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=-1.299, BAYES_50=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VotGoJEqo7Ow for ; Tue, 15 Oct 2013 19:43:59 -0700 (PDT)
Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id D568811E8220 for ; Tue, 15 Oct 2013 19:43:57 -0700 (PDT)
Received: from WeiGengyuPC (unknown [10.103.241.46]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 9877319F383; Wed, 16 Oct 2013 10:43:53 +0800 (HKT)
Message-ID: <528D351A2E31436C8EF5786A5254BDFF@WeiGengyuPC>
From: "weigengyu" 
To: , "Core" , "akbar rahman" 
References: <49802db7bb1d96cfccc488402a8bcc77@xs4all.nl>
In-Reply-To: <49802db7bb1d96cfccc488402a8bcc77@xs4all.nl>
Date: Wed, 16 Oct 2013 10:43:52 +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] sleepy nodes
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Oct 2013 02:44:07 -0000

Hi, perter,

"Taking the advice of Zach, that you only want to define a proxy leaves
also many possibilities open, like: ...... "

Could you give further explanations about the proxy.
Is the proxy a resource constrained node?

Regards,

Gengyu

-----原始邮件----- 
From: peter van der Stok
Sent: Tuesday, October 15, 2013 7:49 PM
To: Core ; akbar rahman
Subject: [core] sleepy nodes


Dear all,


reading the draft on the need for sleepy nodes by Akbar, I become more
convinced that the subject is not right for IETF.
Already defining a sleepy node is fraught with application oriented
aspects.
Taking the advice of Zach, that you only want to define a proxy leaves
also many possibilities open, like:

Does the sleepy node communicate only with the proxy?
Can the sleepy node send to other nodes than the proxy via multicast or
unicast?
Does the sleepy node need maintenance?
Is the sleepy node initialized at the factory and it never listens to
any messages afterwards?
Or is there an initialization capability, eventually supported by a
battery recharge.


I can go on and on like this, (for example on timing constraints) and
none of the questions will get satisfactory unanimous answers.
Therefore, I remain with my conclusion that sleepy nodes are interesting
but too much conditioned by application constraints to define a proxy
approach that is generally applicable.

If anything needs to be done I still think that the "mirror server"
draft is the best choice because I recognize the boundary conditions.
But the latter is a very application biased opinion.

Peter

-- 
Peter van der Stok
mailto: consultancy@vanderstok.org
www: www.vanderstok.org
tel NL: +31(0)492474673     F: +33(0)966015248
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core 


From stokcons@xs4all.nl  Wed Oct 16 05:46:35 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F0711E81CE for ; Wed, 16 Oct 2013 05:46:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.154
X-Spam-Level: 
X-Spam-Status: No, score=-0.154 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EK7th6JsHWEJ for ; Wed, 16 Oct 2013 05:46:24 -0700 (PDT)
Received: from smtp-vbr13.xs4all.nl (smtp-vbr13.xs4all.nl [194.109.24.33]) by ietfa.amsl.com (Postfix) with ESMTP id 59D9011E81D6 for ; Wed, 16 Oct 2013 05:46:23 -0700 (PDT)
Received: from roundcube.xs4all.nl (roundcube4.xs4all.net [194.109.20.200]) by smtp-vbr13.xs4all.nl (8.13.8/8.13.8) with ESMTP id r9GCk3UY065177; Wed, 16 Oct 2013 14:46:05 +0200 (CEST) (envelope-from stokcons@xs4all.nl)
Received: from AMontpellier-654-1-109-86.w90-0.abo.wanadoo.fr ([90.0.84.86]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 16 Oct 2013 14:46:03 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Date: Wed, 16 Oct 2013 14:46:03 +0200
From: peter van der Stok 
To: weigengyu 
Organization: vanderstok consultancy
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <528D351A2E31436C8EF5786A5254BDFF@WeiGengyuPC>
References: <49802db7bb1d96cfccc488402a8bcc77@xs4all.nl> <528D351A2E31436C8EF5786A5254BDFF@WeiGengyuPC>
Message-ID: <69dffe621aa77d01e1cb94a1d6871cbc@xs4all.nl>
X-Sender: stokcons@xs4all.nl (e0aMqidY5NwU8BgZlxmyH+EKNxJh6Vt/)
User-Agent: XS4ALL Webmail
X-Virus-Scanned: by XS4ALL Virus Scanner
Cc: Core 
Subject: Re: [core] sleepy nodes
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: consultancy@vanderstok.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Oct 2013 12:46:35 -0000

Hi Gengyu,

Zach made a proposal what the proxy could look like.
For me the proxy probably is not "too much" resource constrained.
The Resource directory or the router may make an excellent host.
But I can also see manufacturers selling them in any form they like.

Greetings,

Peter


weigengyu schreef op 2013-10-16 04:43:
> Hi, perter,
> 
> "Taking the advice of Zach, that you only want to define a proxy leaves
> also many possibilities open, like: ...... "
> 
> Could you give further explanations about the proxy.
> Is the proxy a resource constrained node?
> 
> Regards,
> 
> Gengyu
> 
> -----原始邮件----- From: peter van der Stok
> Sent: Tuesday, October 15, 2013 7:49 PM
> To: Core ; akbar rahman
> Subject: [core] sleepy nodes
> 
> 
> Dear all,
> 
> 
> reading the draft on the need for sleepy nodes by Akbar, I become more
> convinced that the subject is not right for IETF.
> Already defining a sleepy node is fraught with application oriented
> aspects.
> Taking the advice of Zach, that you only want to define a proxy leaves
> also many possibilities open, like:
> 
> Does the sleepy node communicate only with the proxy?
> Can the sleepy node send to other nodes than the proxy via multicast or
> unicast?
> Does the sleepy node need maintenance?
> Is the sleepy node initialized at the factory and it never listens to
> any messages afterwards?
> Or is there an initialization capability, eventually supported by a
> battery recharge.
> 
> 
> I can go on and on like this, (for example on timing constraints) and
> none of the questions will get satisfactory unanimous answers.
> Therefore, I remain with my conclusion that sleepy nodes are 
> interesting
> but too much conditioned by application constraints to define a proxy
> approach that is generally applicable.
> 
> If anything needs to be done I still think that the "mirror server"
> draft is the best choice because I recognize the boundary conditions.
> But the latter is a very application biased opinion.
> 
> Peter

From Akbar.Rahman@InterDigital.com  Wed Oct 16 07:09:51 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67DF721F9EDA for ; Wed, 16 Oct 2013 07:09:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8LQj74qOFYA for ; Wed, 16 Oct 2013 07:09:46 -0700 (PDT)
Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 221DE21F9A7E for ; Wed, 16 Oct 2013 07:09:45 -0700 (PDT)
Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 16 Oct 2013 10:09:45 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Date: Wed, 16 Oct 2013 10:09:44 -0400
Message-ID: 
In-Reply-To: <5A6D74B4-3733-45D1-95B1-E838DADED234@tzi.org>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Some initial comments on WGLC of draft-ietf-core-observe-11
Thread-Index: Ac7Jk/8VQegDkuOPT3Gdgq0cAv0Y5QA4PLGw
References: <5A6D74B4-3733-45D1-95B1-E838DADED234@tzi.org>
From: "Rahman, Akbar" 
To: "Klaus Hartke" 
X-OriginalArrivalTime: 16 Oct 2013 14:09:45.0186 (UTC) FILETIME=[5DADFC20:01CECA79]
Cc: core@ietf.org
Subject: [core] Some initial comments on WGLC of draft-ietf-core-observe-11
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Oct 2013 14:09:51 -0000

SGkgS2xhdXMsDQoNCg0KVGhhbmtzIGZvciB0aGUgZ29vZCB3b3JrIG9uIHRoZSBvYnNlcnZlIGRy
YWZ0LiAgSW4gZ2VuZXJhbCwgSSBzdXBwb3J0IGFkdmFuY2luZyB0aGUgZHJhZnQuICBIb3dldmVy
LCBJIGRpZCAgaGF2ZSB0aGUgZm9sbG93aW5nIGNvbW1lbnRzL3F1ZXN0aW9uczoNCg0KDQoxKSBT
ZWN0aW9uIDMuNiAoQ2FuY2VsbGF0aW9uKQ0KLSBUaGUgcHJvY2VkdXJlIGZvciBjYW5jZWxsaW5n
IGZyb20gYSBjbGllbnQgcG9pbnQgb2YgdmlldyBzZWVtcyBvdmVybHkgY29tcGxleCBhbmQgaW5l
ZmZpY2llbnQuICBXaHkgY2FuJ3QgYSBSZXNldCBtZXNzYWdlIGZyb20gdGhlIGNsaWVudCBhbHdh
eXMgKFNIQUxMKSBmb3JjZSB0aGUgc2VydmVyIHRvIHN0b3Agc2VuZGluZyBub3RpZmljYXRpb25z
PyAgSS5FLiBEb24ndCBoYXZlIGRpZmZlcmVudCBjYXNlcyBmb3IgdGhlIGNvbmZpcm1hYmxlIGFu
ZCBub24tY29uZmlybWFibGUgbm90aWZpY2F0aW9uIGNhc2VzLiAgSXQgc2VlbXMgdmVyeSByaXNr
eSB0aGF0IGEgImNsaWVudCBtYXkgaGF2ZSB0byB3YWl0IGZvciBhIGNvbmZpcm1hYmxlIG5vdGlm
aWNhdGlvbiIuDQoNCi0gQWxzbyB3b3JkaW5nIGluIFNlY3Rpb24gMy42IHNlZW0gc29tZWhvdyBu
b3QgMTAwJSBhbGlnbmVkIHdpdGggdGhlIHRleHQgaW4gdGhlIGxhc3QgcGFyYWdyYXBoIG9mIFNl
Y3Rpb24gMS4yLg0KDQoNCjIpIFNlY3Rpb24gNiAoV2ViIExpbmtpbmcpDQotIFRoZSBjb21tZW50
IGluIHRoZSBzZWNvbmQgcGFyYWdyYXBoIHRoYXQgIm9icyIgc2hvdWxkIGhhdmUgImEgc3VpdGFi
bGUgZ3JhcGhpY2FsIHJlcHJlc2VudGF0aW9uIGluIGEgdXNlciBpbnRlcmZhY2UiIHdhcyBpbnRl
cmVzdGluZy4gIFRoaXMgaXMgdGhlIGZpcnN0IHRpbWUgdGhhdCBJIHJlY2FsbCBzZWVpbmcgdXNl
ciBncmFwaGljYWwgaW50ZXJmYWNlIHJlZmVyZW5jZXMgaW4gQ09SRSBkb2N1bWVudHMuICBJIGFt
IG5vdCBvYmplY3RpbmcgdG8gdGhpcywgYnV0IHdhcyB0aGVyZSBzb21lIHNwZWNpYWwgbW90aXZh
dGlvbiBmb3IgcHV0dGluZyBpdD8NCg0KDQoNCjMpIFNlY3Rpb24gNyAoU2VjdXJpdHkgQ29uc2lk
ZXJhdGlvbnMpDQotIFRoZSBmb2xsb3dpbmcgc2VudGVuY2Ugc2hvdWxkIGJlIHJlLXdvcmRlZCBm
b3IgY2xhcml0eTogIlRoZSBjb25zaWRlcmF0aW9ucyBhYm91dCBhbXBsaWZpY2F0aW9uIGF0dGFj
a3MgYXJlIHNvbWV3aGF0IGFtcGxpZmllZCAuLi4iDQoNCg0KDQpJIGFtIHN0aWxsIChyZS0pcmVh
ZGluZyB0aGUgZG9jdW1lbnQgYnV0IEkgdGhvdWdodCB0aGF0IEkgd291bGQgc2VuZCB5b3UgdGhl
c2UgaW5pdGlhbCBjb21tZW50cyBpbiB0aGUgaW50ZXJpbS4NCg0KDQoNCkJlc3QgUmVnYXJkLA0K
DQoNCkFrYmFyDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGNvcmUtYm91
bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m
IENhcnN0ZW4gQm9ybWFubg0KU2VudDogVHVlc2RheSwgT2N0b2JlciAxNSwgMjAxMyA2OjQ2IEFN
DQpUbzogY29yZUBpZXRmLm9yZyBXRw0KU3ViamVjdDogW2NvcmVdIPCflJQgV0dMQyBvZiBkcmFm
dC1pZXRmLWNvcmUtb2JzZXJ2ZS0xMQ0KDQpBZnRlciB0aGlzIFdHIGhhcyBmb2N1c2VkIG9uIGNv
bXBsZXRpbmcgdGhlIGJhc2Ugc3BlY2lmaWNhdGlvbiBmb3IgYSB3aGlsZSwgaXQgaXMgdGltZSB0
byBmaW5pc2ggdGhlIHR3byBjb21wbGVtZW50aW5nIHNwZWNpZmljYXRpb25zLCAtb2JzZXJ2ZSBh
bmQgLWJsb2NrLiAgLW9ic2VydmUgaXMgZmlyc3Q6DQoNCmRyYWZ0LWlldGYtY29yZS1vYnNlcnZl
LTExIGNsZWFycyBhbGwgcmVtYWluaW5nIGlzc3VlcyBpbiB0aGUgdHJhY2tlci4NClRoYW5rcyBn
byB0byBLbGF1cyBmb3IgcGF0aWVudGx5IGFkZHJlc3NpbmcgYWxsIHRob3NlIGRldGFpbHMuDQoN
ClRoaXMgc3RhcnRzIGEgc2Vjb25kIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGZvciAtb2JzZXJ2
ZSwgZW5kaW5nIG9uDQoNCgkyNDowMCBQRFQgb24gVHVlc2RheSwgT2N0b2JlciAyOSwgMjAxMy4N
Cg0KUGxlYXNlIHN0YXJ0IGEgbmV3IGVtYWlsIHRocmVhZCBmb3IgZWFjaCBtYWpvciBpc3N1ZXMg
dGhhdCB3aWxsIG5lZWQgZGlzY3Vzc2lvbiBhbmQgbWFrZSBzdXJlIHRoZSBzdWJqZWN0IGxpbmUg
aW5jbHVkZXMgdGhlIGRyYWZ0IG5hbWUgYW5kIHNvbWUgc29ydCBvZiBuYW1lIGZvciB0aGUgaXNz
dWUuIEZvciBtaW5vciBpc3N1ZXMgc3VjaCBhcyB0eXBvcyBhbmQgdGhpbmdzIHRoYXQgYXJlIG5v
dCBsaWtlbHkgdG8gbGVhZCB0byBtdWNoIGRpc2N1c3Npb24sIGl0IGlzIHByb2JhYmx5IGVhc2ll
ciB0byBncm91cCB0aGVtIGFsbCBpbiB0byBvbmUgZW1haWwgYnV0IGFnYWluLCBwbGVhc2UgbWFr
ZSBzdXJlIHRoZSBzdWJqZWN0IGxpbmUgaW5jbHVkZXMgdGhlIGRyYWZ0IG5hbWUuIElmIHlvdSBy
ZWFkIHRoZSBkcmFmdCBhbmQgdGhpbmsgaXQgbG9va3MgZmluZSwgcGxlYXNlIHNlbmQgYSBvbmUg
bGluZSBlbWFpbCB0byB0aGUgbGlzdCBvciB0byB0aGUgY2hhaXJzIGxldHRpbmcgdXMga25vdyB0
aGF0IHNvIHdlIGNhbiBnZXQgYSBmZWVsIG9mIGhvdyBicm9hZCB0aGUgcmV2aWV3IGhhcyBiZWVu
Lg0KDQpXZSBkaWQgYW4gSVBSIGNhbGwgb24gdGhlIGZpcnN0IFdHTEMsIGJ1dCBzaW5jZSB0aGF0
IHNvbWUgdGltZSBoYXMgZWxhcHNlZDoNCg0KSWYgeW91IGFyZSBhd2FyZSBvZiBhbnkgcGF0ZW50
IGNsYWltcyB0aGF0IG1pZ2h0IGFwcGx5IHRvIHN5c3RlbXMgdGhhdCBpbXBsZW1lbnQgdGhlc2Ug
ZHJhZnRzLCBwbGVhc2UgcmV2aWV3IEJDUCA3OCBhbmQgQkNQIDc5IGFuZCBtYWtlIGFueSBhcHBy
b3ByaWF0ZSBJUFIgZGVjbGFyYXRpb24uIElmIHlvdSBhcmUgbm90IHN1cmUgd2hldGhlciB5b3Ug
bmVlZCB0byBtYWtlIGEgZGVjbGFyYXRpb24gb3Igbm90LCBwbGVhc2UgdGFsayB0byB0aGUgY2hh
aXJzIGFuZCB3ZSB3aWxsIGhlbHAgZ2V0IHlvdSBpbiB0b3VjaCB3aXRoIHBlb3BsZSB0aGF0IGNh
biBwcm92aWRlIGFwcHJvcHJpYXRlIGFkdmljZS4NCg0KV2hpbGUgZXZlcnlvbmUgbWF5IHN0aWxs
IGJlIGEgYml0IHRpcmVkIGZyb20gY29tcGxldGluZyBjb3JlLWNvYXAgKGFuZCB3ZSBhcmUgc3Rp
bGwgd2FpdGluZyBmb3IgdGhlIHR3byBtaXNzaW5nIHJlZmVyZW5jZXMgdG8gZ28gdG8gdGhlIFJG
QyBlZGl0b3IpLCBpdCBpcyBpbXBvcnRhbnQgdGhhdCB3ZSBhbGwgZ28gYW5kIHJldmlldyAtb2Jz
ZXJ2ZSBhcyB3ZWxsLg0KVGhlIHBlb3BsZSB0aGF0IGhhdmUgcGFydGljaXBhdGVkIGhlYXZpbHkg
aGF2ZSByZWFkIHRoZSBkcmFmdCBzbyBtYW55IHRpbWVzIHRoYXQgdGhleSBoYXZlIGEgaGFyZCB0
aW1lIG5vdGljaW5nIHdoYXQgaXMgd3Jvbmcgb3IgbWlzc2luZyBmcm9tIHRoZW0gYnV0IGZyZXNo
IGV5ZXMgY2FuIGhlbHAuICBXZSBrbm93IHRoYXQgZXZlcnlvbmUgaGFzIG1hbnkgZG9jdW1lbnRz
IHRvIHJlYWQgZm9yIHRoZSB1cGNvbWluZyBJRVRGLCBidXQgd2Ugd291bGQgbGlrZSB0byB0cnkg
YW5kIGNvbnZpbmNlIHlvdSB0aGF0IHJlYWRpbmcgZHJhZnRzIHRoYXQgYXJlIGluIFdHTEMgaXMg
cHJvYmFibHkgbW9yZSBpbXBvcnRhbnQgdGhhbiBtYW55IG90aGVycy4gIFBsZWFzZSBoZWxwIHVz
IGdldCB0aGlzIHJpZ2h0Lg0KDQpHcsO8w59lLCBDYXJzdGVuDQoNCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpjb3JlIG1haWxpbmcgbGlzdA0KY29yZUBp
ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQo=

From salvatore.loreto@ericsson.com  Wed Oct 16 07:12:16 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CDDD11E81D1 for ; Wed, 16 Oct 2013 07:12:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Level: 
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSQFA01uLgjK for ; Wed, 16 Oct 2013 07:12:11 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id EBBB521F9CCA for ; Wed, 16 Oct 2013 07:12:10 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-18-525e9eb9601b
Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 77.0D.03802.9BE9E525; Wed, 16 Oct 2013 16:12:10 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.228]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0328.009; Wed, 16 Oct 2013 16:12:09 +0200
From: Salvatore Loreto 
To: "" 
Thread-Topic: [core] sleepy nodes
Thread-Index: AQHOyZyiCUd7/rJbB0KHqPWUMZQPUZn3PqaA
Date: Wed, 16 Oct 2013 14:12:09 +0000
Message-ID: <2B9B48179856DC4FA00C93C79EB7E64A2C5130@ESESSMB109.ericsson.se>
References: <49802db7bb1d96cfccc488402a8bcc77@xs4all.nl>
In-Reply-To: <49802db7bb1d96cfccc488402a8bcc77@xs4all.nl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+Jvje6ueXFBBtNOsVj8mtDEZPFo/yo2 i31v1zM7MHssWfKTyWPp9TZWjxMN29kDmKO4bFJSczLLUov07RK4Mvq3NrIVfBasONl8kamB cSVfFyMnh4SAicTpxaeYIGwxiQv31rN1MXJxCAkcZpS4dvsSC4SzhFFiRd83NpAqNgEziecP tzB3MXJwiAjYSzzscgUJMwu4SfQvPsQOEhYWUJC49Z4VJCwioCjRPmsFI4RtJLFw0newXSwC qhLvT/awgNi8At4Sl46fYQaxhQQsJBbtvgBmcwpYSjQu/w9mMwLd9v3UGiaIVeISt57Mh7pZ QGLJnvPMELaoxMvH/1ghbCWJRbc/Q9UbSLw/N58ZwraWOPdxCwuErS2xbOFrZogbBCVOznzC MoFRfBaSFbOQtM9C0j4LSfssJO0LGFlXMbLnJmbmpJcbbWIERtnBLb9VdzDeOSdyiFGag0VJ nPfDW+cgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYwW9tuEWQ9bXbN9ZfJqTUWvmfv2kPX3 WpsEv3062XqAJyQx6no7p7iYomGNX+c3jbxFTDH976XmyGgenG478UjWwv1XX/k5vn4qxj/1 qDRv0IPlD9yPNxVl2p2Z+eT+Cz8bx7b2oP5Znj86ueWvXVzJnpNVOfG8xIY76+d8/yU7Y3us s3GoxEUlluKMREMt5qLiRADcfcpagAIAAA==
Cc: Core 
Subject: Re: [core] sleepy nodes
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Oct 2013 14:12:16 -0000

Dear Peter,

not sure all you mentioned below are strictly application oriented aspects.

I still feel we lack in core some general mechanism to handle the case
(intermittent nodes it is really more general and better then sleeping one)=
  in an standard way=85
it can be as simple as the one defined in OMA lightweight standard
(i.e. a RD registration parameter used to indicate a node in a queue mode)

but at least we need a standard mechanism that let the client recognise "th=
e node is trying to reach
is not available=85" and how it should behave if it really want to contact =
it

Salvatore



On Oct 15, 2013, at 2:49 PM, peter van der Stok  wrote:

>=20
> Dear all,
>=20
>=20
> reading the draft on the need for sleepy nodes by Akbar, I become more co=
nvinced that the subject is not right for IETF.
> Already defining a sleepy node is fraught with application oriented aspec=
ts.
> Taking the advice of Zach, that you only want to define a proxy leaves al=
so many possibilities open, like:
>=20
> Does the sleepy node communicate only with the proxy?
> Can the sleepy node send to other nodes than the proxy via multicast or u=
nicast?
> Does the sleepy node need maintenance?
> Is the sleepy node initialized at the factory and it never listens to any=
 messages afterwards?
> Or is there an initialization capability, eventually supported by a batte=
ry recharge.
>=20
>=20
> I can go on and on like this, (for example on timing constraints) and non=
e of the questions will get satisfactory unanimous answers.
> Therefore, I remain with my conclusion that sleepy nodes are interesting =
but too much conditioned by application constraints to define a proxy appro=
ach that is generally applicable.
>=20
> If anything needs to be done I still think that the "mirror server" draft=
 is the best choice because I recognize the boundary conditions.
> But the latter is a very application biased opinion.
>=20
> Peter
>=20
> --=20
> Peter van der Stok
> mailto: consultancy@vanderstok.org
> www: www.vanderstok.org
> tel NL: +31(0)492474673     F: +33(0)966015248
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core


From stokcons@xs4all.nl  Wed Oct 16 08:24:47 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6030221F9DAF for ; Wed, 16 Oct 2013 08:24:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.154
X-Spam-Level: 
X-Spam-Status: No, score=-0.154 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oj8svpi+xeW for ; Wed, 16 Oct 2013 08:24:42 -0700 (PDT)
Received: from smtp-vbr2.xs4all.nl (smtp-vbr2.xs4all.nl [194.109.24.22]) by ietfa.amsl.com (Postfix) with ESMTP id 74B6521F9EDA for ; Wed, 16 Oct 2013 08:24:41 -0700 (PDT)
Received: from roundcube.xs4all.nl (roundcube4.xs4all.net [194.109.20.200]) by smtp-vbr2.xs4all.nl (8.13.8/8.13.8) with ESMTP id r9GFOYcE066176; Wed, 16 Oct 2013 17:24:34 +0200 (CEST) (envelope-from stokcons@xs4all.nl)
Received: from AMontpellier-654-1-109-86.w90-0.abo.wanadoo.fr ([90.0.84.86]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 16 Oct 2013 17:24:33 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Date: Wed, 16 Oct 2013 17:24:33 +0200
From: peter van der Stok 
To: Salvatore Loreto 
Organization: vanderstok consultancy
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <2B9B48179856DC4FA00C93C79EB7E64A2C5130@ESESSMB109.ericsson.se>
References: <49802db7bb1d96cfccc488402a8bcc77@xs4all.nl> <2B9B48179856DC4FA00C93C79EB7E64A2C5130@ESESSMB109.ericsson.se>
Message-ID: 
X-Sender: stokcons@xs4all.nl (AMNv4ob1Wykw8GcHG920mmvWh90NErxD)
User-Agent: XS4ALL Webmail
X-Virus-Scanned: by XS4ALL Virus Scanner
Cc: Core 
Subject: Re: [core] sleepy nodes
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: consultancy@vanderstok.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Oct 2013 15:24:47 -0000

Hi Salvatore,

with application oriented read also: manufacturer- or consortium of 
manufacturers oriented.

I see your point that it is useful to recognize during discovery that 
the device exists, has an IP address, but reacts funny.
On the other hand, one can decide to make the "intermittent node" 
invisible in the discovery process, and discover the proxies instead.
Next question, do we need to recognize that these are proxies?
I would argue that depends on the application and the way the proxy is 
constructed. It probably has to do with the validity of the returned 
values.
However, the "intermittent node" should not respond to any query, any 
time (be truly invisible) unless it is the proxy that queries it.

would that be reasonable?

Peter


Salvatore Loreto schreef op 2013-10-16 16:12:
> Dear Peter,
> 
> not sure all you mentioned below are strictly application oriented 
> aspects.
> 
> I still feel we lack in core some general mechanism to handle the case
> (intermittent nodes it is really more general and better then sleeping
> one)  in an standard way…
> it can be as simple as the one defined in OMA lightweight standard
> (i.e. a RD registration parameter used to indicate a node in a queue 
> mode)
> 
> but at least we need a standard mechanism that let the client
> recognise "the node is trying to reach
> is not available…" and how it should behave if it really want to 
> contact it
> 
> Salvatore
> 
> 
> 
> On Oct 15, 2013, at 2:49 PM, peter van der Stok  
> wrote:
> 
> 
> Dear all,
> 
> 
> reading the draft on the need for sleepy nodes by Akbar, I become more 
> convinced that the subject is not right for IETF.
> Already defining a sleepy node is fraught with application oriented 
> aspects.
> Taking the advice of Zach, that you only want to define a proxy leaves 
> also many possibilities open, like:
> 
> Does the sleepy node communicate only with the proxy?
> Can the sleepy node send to other nodes than the proxy via multicast or 
> unicast?
> Does the sleepy node need maintenance?
> Is the sleepy node initialized at the factory and it never listens to 
> any messages afterwards?
> Or is there an initialization capability, eventually supported by a 
> battery recharge.
> 
> 
> I can go on and on like this, (for example on timing constraints) and 
> none of the questions will get satisfactory unanimous answers.
> Therefore, I remain with my conclusion that sleepy nodes are 
> interesting but too much conditioned by application constraints to 
> define a proxy approach that is generally applicable.
> 
> If anything needs to be done I still think that the "mirror server" 
> draft is the best choice because I recognize the boundary conditions.
> But the latter is a very application biased opinion.
> 
> Peter
> 
> --
> Peter van der Stok
> mailto: consultancy@vanderstok.org
> www: www.vanderstok.org
> tel NL: +31(0)492474673     F: +33(0)966015248
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core

From hartke@tzi.org  Wed Oct 16 08:43:39 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB0E11E8315 for ; Wed, 16 Oct 2013 08:43:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.627
X-Spam-Level: 
X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLQfQ1kaVQvG for ; Wed, 16 Oct 2013 08:43:33 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 12F5B11E82D2 for ; Wed, 16 Oct 2013 08:43:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9GFhRQb014258 for ; Wed, 16 Oct 2013 17:43:27 +0200 (CEST)
Received: from mail-vb0-f51.google.com (mail-vb0-f51.google.com [209.85.212.51]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E4E3B4DE for ; Wed, 16 Oct 2013 17:43:26 +0200 (CEST)
Received: by mail-vb0-f51.google.com with SMTP id x16so455172vbf.10 for ; Wed, 16 Oct 2013 08:43:25 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=5dqJ4CNHvU2Pk+t9AazBoTkl6GRA/KEGb0+fS0rZ1Sk=; b=h2YkcsIrGsVMw6vmz+QoCZ7iBJvby97v6L2Aw+5ZghotEYAOAKmTZqXbxg1oaidLGJ H4o85RIIY/L2g9VxBAIxnLb9Ljs5Sa9fXliUi/9vH6TEsa+kVngCChypK4k2/TtuEnP+ e6ht+w9+9GNPuF2nsZSbkYsBhp6KU0409Q3jiK620aYNchu2fEzUNL0/0Wtdj0EP3ajc dFPoPDU05ZQcdMjavU6ILS6lTBsviSoYg1zzS6awZrV1IZ9QrRJ9Ozbgm2hZs3riJqaQ av5t9DeDexZg1EbMg8rKXdebUUBtTUPSxRrEATVwDnspfPl/XMDuszDdoz0sdTUVyOu1 iZYA==
X-Received: by 10.221.24.70 with SMTP id rd6mr26079vcb.42.1381938205587; Wed, 16 Oct 2013 08:43:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.24.83 with HTTP; Wed, 16 Oct 2013 08:42:45 -0700 (PDT)
In-Reply-To: 
References: <5A6D74B4-3733-45D1-95B1-E838DADED234@tzi.org> 
From: Klaus Hartke 
Date: Wed, 16 Oct 2013 18:42:45 +0300
Message-ID: 
To: "Rahman, Akbar" 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "core@ietf.org WG" 
Subject: Re: [core] Some initial comments on WGLC of draft-ietf-core-observe-11
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Oct 2013 15:43:39 -0000

Hi Akbar,

thanks a lot for your review.

> 1) Section 3.6 (Cancellation)
> - The procedure for cancelling from a client point of view seems overly c=
omplex and inefficient.  Why can't a Reset message from the client always (=
SHALL) force the server to stop sending notifications?  I.E. Don't have dif=
ferent cases for the confirmable and non-confirmable notification cases.  I=
t seems very risky that a "client may have to wait for a confirmable notifi=
cation".

CoAP initially didn't have support for reset messages in reply to
non-confirmable messages, so a client had to wait for a confirmable
message to tell the server that was no longer interested. This was
changed in observe-04/coap-09, but it requires the server to keep
track of the message IDs of the non-confirmable notifications that it
sends, which is something it didn't have to do before. So the
consensus at that time was to make this requirement OPTIONAL.

I see no strong need to change it to REQUIRED (a client MUST reject
every unwanted non-confirmable notification with a reset message; a
server MUST remember message IDs of non-confirmable notifications for
cancellation): When a reset message doesn't reach the server because
of message loss, the client has to reject notifications anyway until
the server stops sending. And an implementer of a client already
doesn't have to distinguish between confirmable and non-confirmable
notifications if he doesn't want to.

> 2) Section 6 (Web Linking)
> - The comment in the second paragraph that "obs" should have "a suitable =
graphical representation in a user interface" was interesting.  This is the=
 first time that I recall seeing user graphical interface references in COR=
E documents.  I am not objecting to this, but was there some special motiva=
tion for putting it?

Most clients know if they need a current resource representation over
a period time or not, so the "obs" attribute is mostly useful if the
client is an application-agnostic browser like Copper. So a graphical
representation in a user interface is basically the only known
use-case.

> 3) Section 7 (Security Considerations)
> - The following sentence should be re-worded for clarity: "The considerat=
ions about amplification attacks are somewhat amplified ..."

What do you propose?

> I am still (re-)reading the document but I thought that I would send you =
these initial comments in the interim.

I'm looking forward to further comments/questions from you :-)

Best regards,
Klaus

From zach@sensinode.com  Wed Oct 16 08:51:36 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D96E11E8138 for ; Wed, 16 Oct 2013 08:51:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBA-LAQxQ3U5 for ; Wed, 16 Oct 2013 08:51:32 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 70D6911E82C2 for ; Wed, 16 Oct 2013 08:51:18 -0700 (PDT)
Received: from [10.10.244.57] (68.65.65.187.static-ip.telepacific.net [68.65.65.187]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r9GFpBx1018115 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 Oct 2013 18:51:14 +0300
X-Authenticated-User: sensinodecom
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Zach Shelby 
In-Reply-To: 
Date: Wed, 16 Oct 2013 08:51:09 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <2F058691-1D87-4060-8FE9-EE8F9F0E90CB@sensinode.com>
References: <5A6D74B4-3733-45D1-95B1-E838DADED234@tzi.org>  
To: Klaus Hartke 
X-Mailer: Apple Mail (2.1508)
Cc: "core@ietf.org WG" 
Subject: Re: [core] Some initial comments on WGLC of draft-ietf-core-observe-11
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Oct 2013 15:51:36 -0000

On Oct 16, 2013, at 8:42 AM, Klaus Hartke  wrote:

>> 2) Section 6 (Web Linking)
>> - The comment in the second paragraph that "obs" should have "a =
suitable graphical representation in a user interface" was interesting.  =
This is the first time that I recall seeing user graphical interface =
references in CORE documents.  I am not objecting to this, but was there =
some special motivation for putting it?
>=20
> Most clients know if they need a current resource representation over
> a period time or not, so the "obs" attribute is mostly useful if the
> client is an application-agnostic browser like Copper. So a graphical
> representation in a user interface is basically the only known
> use-case.

Definitely is a use case, but not the only one. Even though a client may =
know that it needs to observe a resource, the "obs" attribute tells it =
that the resource is actually observable in the first place. Otherwise =
the client would operate by trial and error? There may be other =
functionality in a client that depends on knowing a priori which =
resources are observable before trying. But let's not waste time on this =
one - I do remember having this same conversation before :-) Could be =
enough to say "graphical representation or other client functionality" =
or something like that.

Zach=20

--=20
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com @SensinodeIoT
Mobile: +358 40 7796297
Twitter: @zach_shelby
LinkedIn: http://fi.linkedin.com/in/zachshelby
6LoWPAN Book: http://6lowpan.net





From hartke@tzi.org  Wed Oct 16 09:14:58 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86C8C11E831F for ; Wed, 16 Oct 2013 09:14:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.627
X-Spam-Level: 
X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqhcrkN4H7dn for ; Wed, 16 Oct 2013 09:14:52 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB9911E830F for ; Wed, 16 Oct 2013 09:14:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9GGEl9H014834 for ; Wed, 16 Oct 2013 18:14:47 +0200 (CEST)
Received: from mail-vb0-f50.google.com (mail-vb0-f50.google.com [209.85.212.50]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9F483513 for ; Wed, 16 Oct 2013 18:14:47 +0200 (CEST)
Received: by mail-vb0-f50.google.com with SMTP id x14so463107vbb.37 for ; Wed, 16 Oct 2013 09:14:46 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=HDZp10b/skqJifbjBG5awQKPZXjeewZBhmK38n2jWos=; b=iJ5Sgb8ydjYIIebkXIvUsuNiNRx/tGuJLhcUB2+PYo6RyOIw5yLMfMd2zJOrWw1qCY Xi2bQ6rRQ1vwCCaH8z+B4XAyT4clhtNVFfxLf8Sjt6ak3T58JpXS2mrz0AHasZZVhAw7 JaUb1905VFwaYcIzkUGqBmbvkie0Bo56YKYh4sF3IoPw4HtC/c7yokbdb+N7KiqBSXYO u2ykYq1kHfZUUQ9PFT+/XPGAL3KnS1FoDfW4f4Y1QAgJcIpplj6OFQ+Wn/qGyhQ2Afxk x8UFZdp+omcUGHccMOKyokMgplAEdNxy/3g4+LDJ3kU2+HrxeHRLhvUEtX89NjFMM4/I RCfA==
X-Received: by 10.221.40.10 with SMTP id to10mr2051560vcb.22.1381940086404; Wed, 16 Oct 2013 09:14:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.24.83 with HTTP; Wed, 16 Oct 2013 09:14:06 -0700 (PDT)
In-Reply-To: <2F058691-1D87-4060-8FE9-EE8F9F0E90CB@sensinode.com>
References: <5A6D74B4-3733-45D1-95B1-E838DADED234@tzi.org>   <2F058691-1D87-4060-8FE9-EE8F9F0E90CB@sensinode.com>
From: Klaus Hartke 
Date: Wed, 16 Oct 2013 19:14:06 +0300
Message-ID: 
To: Zach Shelby 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "core@ietf.org WG" 
Subject: Re: [core] Some initial comments on WGLC of draft-ietf-core-observe-11
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Oct 2013 16:14:59 -0000

Zach Shelby wrote:
> Definitely is a use case, but not the only one.

So what are other good examples that could be mentioned in the draft?

> Even though a client may know that it needs to observe a resource, the "obs" attribute tells it that the resource is actually observable in the first place.

Every resource is observable, the same way as every resource can be
polled. That's not an interesting property. The interesting question
is whether a client needs a current representation of a resource over
a period of time or not.

> Otherwise the client would operate by trial and error?

If a client needs a current representation of a resource over a period
of time, it sends a GET request with Observe Option and receives a
snapshot of the resource state. Then, either the server supports the
option and has enough room for the client in the list of observers, so
the client is automatically provided with current representations, or
the client sends another GET request with Observe Option when Max-Age
expires to check if the representation is still current.

There is no try. There is only the goal to have a current
representation of a resource over a period of time, and two mechanisms
to achieve it. Do or Do not.

Best regards,
Klaus

From Akbar.Rahman@InterDigital.com  Wed Oct 16 09:56:54 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 497F911E81DA for ; Wed, 16 Oct 2013 09:56:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIqB3MZRYKRA for ; Wed, 16 Oct 2013 09:56:47 -0700 (PDT)
Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2B12311E8127 for ; Wed, 16 Oct 2013 09:56:29 -0700 (PDT)
Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 16 Oct 2013 12:56:24 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 16 Oct 2013 12:56:23 -0400
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [core] Some initial comments on WGLC of draft-ietf-core-observe-11
Thread-Index: Ac7KhotmzqN48iCrQhWL7NnJlETBQAACN+vA
References: <5A6D74B4-3733-45D1-95B1-E838DADED234@tzi.org>  
From: "Rahman, Akbar" 
To: "Klaus Hartke" 
X-OriginalArrivalTime: 16 Oct 2013 16:56:24.0341 (UTC) FILETIME=[A5A3F450:01CECA90]
Cc: core@ietf.org
Subject: Re: [core] Some initial comments on WGLC of draft-ietf-core-observe-11
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Oct 2013 16:56:54 -0000

Hi Klaus,


For the comment:

>> 3) Section 7 (Security Considerations)
>> - The following sentence should be re-worded for clarity: "The
considerations about amplification attacks are somewhat amplified ..."

>What do you propose?


How about:

FROM:
-----
The considerations about amplification attacks are somewhat amplified
when observing resources.


TO:
---
Observing resources can dramatically increase the negative effects of
amplification attacks.  That is, not only can the response packet be
significantly larger than the request packet, but the nature of observe
causes many response packets to be generated.



Best Regards,


Akbar


-----Original Message-----
From: Klaus Hartke [mailto:hartke@tzi.org]=20
Sent: Wednesday, October 16, 2013 11:43 AM
To: Rahman, Akbar
Cc: core@ietf.org WG
Subject: Re: [core] Some initial comments on WGLC of
draft-ietf-core-observe-11

Hi Akbar,

thanks a lot for your review.

> 1) Section 3.6 (Cancellation)
> - The procedure for cancelling from a client point of view seems
overly complex and inefficient.  Why can't a Reset message from the
client always (SHALL) force the server to stop sending notifications?
I.E. Don't have different cases for the confirmable and non-confirmable
notification cases.  It seems very risky that a "client may have to wait
for a confirmable notification".

CoAP initially didn't have support for reset messages in reply to
non-confirmable messages, so a client had to wait for a confirmable
message to tell the server that was no longer interested. This was
changed in observe-04/coap-09, but it requires the server to keep track
of the message IDs of the non-confirmable notifications that it sends,
which is something it didn't have to do before. So the consensus at that
time was to make this requirement OPTIONAL.

I see no strong need to change it to REQUIRED (a client MUST reject
every unwanted non-confirmable notification with a reset message; a
server MUST remember message IDs of non-confirmable notifications for
cancellation): When a reset message doesn't reach the server because of
message loss, the client has to reject notifications anyway until the
server stops sending. And an implementer of a client already doesn't
have to distinguish between confirmable and non-confirmable
notifications if he doesn't want to.

> 2) Section 6 (Web Linking)
> - The comment in the second paragraph that "obs" should have "a
suitable graphical representation in a user interface" was interesting.
This is the first time that I recall seeing user graphical interface
references in CORE documents.  I am not objecting to this, but was there
some special motivation for putting it?

Most clients know if they need a current resource representation over a
period time or not, so the "obs" attribute is mostly useful if the
client is an application-agnostic browser like Copper. So a graphical
representation in a user interface is basically the only known use-case.

> 3) Section 7 (Security Considerations)
> - The following sentence should be re-worded for clarity: "The
considerations about amplification attacks are somewhat amplified ..."

What do you propose?

> I am still (re-)reading the document but I thought that I would send
you these initial comments in the interim.

I'm looking forward to further comments/questions from you :-)

Best regards,
Klaus

From Akbar.Rahman@InterDigital.com  Wed Oct 16 10:07:13 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF89111E822D for ; Wed, 16 Oct 2013 10:07:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1kWIm9qj7R8 for ; Wed, 16 Oct 2013 10:07:08 -0700 (PDT)
Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 958E911E82DE for ; Wed, 16 Oct 2013 10:06:35 -0700 (PDT)
Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 16 Oct 2013 13:06:35 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 16 Oct 2013 13:06:34 -0400
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [core] Some initial comments on WGLC of draft-ietf-core-observe-11
Thread-Index: Ac7KhotmzqN48iCrQhWL7NnJlETBQAACkM9Q
References: <5A6D74B4-3733-45D1-95B1-E838DADED234@tzi.org>  
From: "Rahman, Akbar" 
To: "Klaus Hartke" 
X-OriginalArrivalTime: 16 Oct 2013 17:06:35.0634 (UTC) FILETIME=[11FFDD20:01CECA92]
Cc: core@ietf.org
Subject: Re: [core] Some initial comments on WGLC of draft-ietf-core-observe-11
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Oct 2013 17:07:14 -0000

Hi Klaus,



Regarding my comment and your answer on section 3.6 (Cancellation).  My
main point was that it seems illogical that a constrained device cannot
always quickly prevent a server from sending it multiple (observe)
messages.   There may be historical reasons for how the Reset message
handling evolved but that shouldn't break the basic client-server
paradigm. =20

(I.E. Client is initiating the request and shouldn't have to continually
receive messages that it doesn't want.  It shouldn't be the server that
gets to decide when to stop.  The Observe handling shouldn't break the
basic client-server model.)


But my comment is more a principled one so please ignore it if the
mechanics of the solution is too cumbersome.



Akbar



-----Original Message-----
From: Klaus Hartke [mailto:hartke@tzi.org]=20
Sent: Wednesday, October 16, 2013 11:43 AM
To: Rahman, Akbar
Cc: core@ietf.org WG
Subject: Re: [core] Some initial comments on WGLC of
draft-ietf-core-observe-11

Hi Akbar,

thanks a lot for your review.

> 1) Section 3.6 (Cancellation)
> - The procedure for cancelling from a client point of view seems
overly complex and inefficient.  Why can't a Reset message from the
client always (SHALL) force the server to stop sending notifications?
I.E. Don't have different cases for the confirmable and non-confirmable
notification cases.  It seems very risky that a "client may have to wait
for a confirmable notification".

CoAP initially didn't have support for reset messages in reply to
non-confirmable messages, so a client had to wait for a confirmable
message to tell the server that was no longer interested. This was
changed in observe-04/coap-09, but it requires the server to keep track
of the message IDs of the non-confirmable notifications that it sends,
which is something it didn't have to do before. So the consensus at that
time was to make this requirement OPTIONAL.

I see no strong need to change it to REQUIRED (a client MUST reject
every unwanted non-confirmable notification with a reset message; a
server MUST remember message IDs of non-confirmable notifications for
cancellation): When a reset message doesn't reach the server because of
message loss, the client has to reject notifications anyway until the
server stops sending. And an implementer of a client already doesn't
have to distinguish between confirmable and non-confirmable
notifications if he doesn't want to.

> 2) Section 6 (Web Linking)
> - The comment in the second paragraph that "obs" should have "a
suitable graphical representation in a user interface" was interesting.
This is the first time that I recall seeing user graphical interface
references in CORE documents.  I am not objecting to this, but was there
some special motivation for putting it?

Most clients know if they need a current resource representation over a
period time or not, so the "obs" attribute is mostly useful if the
client is an application-agnostic browser like Copper. So a graphical
representation in a user interface is basically the only known use-case.

> 3) Section 7 (Security Considerations)
> - The following sentence should be re-worded for clarity: "The
considerations about amplification attacks are somewhat amplified ..."

What do you propose?

> I am still (re-)reading the document but I thought that I would send
you these initial comments in the interim.

I'm looking forward to further comments/questions from you :-)

Best regards,
Klaus

From pab@pabigot.com  Wed Oct 16 10:54:22 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF4611E82DE for ; Wed, 16 Oct 2013 10:54:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.222
X-Spam-Level: 
X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=0.377,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1B+CzqwLzmT for ; Wed, 16 Oct 2013 10:54:16 -0700 (PDT)
Received: from p3plsmtpa09-03.prod.phx3.secureserver.net (p3plsmtpa09-03.prod.phx3.secureserver.net [173.201.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id D4D1621F9E6D for ; Wed, 16 Oct 2013 10:54:15 -0700 (PDT)
Received: from [192.168.65.10] ([66.41.60.82]) by p3plsmtpa09-03.prod.phx3.secureserver.net with  id dtuC1m0011mTNtu01tuCJj; Wed, 16 Oct 2013 10:54:14 -0700
Message-ID: <525ED2C5.4030200@pabigot.com>
Date: Wed, 16 Oct 2013 12:54:13 -0500
From: "Peter A. Bigot" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: "Rahman, Akbar" ,  Klaus Hartke 
References: <5A6D74B4-3733-45D1-95B1-E838DADED234@tzi.org>		 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: core@ietf.org
Subject: Re: [core] Some initial comments on WGLC of draft-ietf-core-observe-11
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Oct 2013 17:54:22 -0000

I agree with Akbar that it's irritating that a client might get spammed 
by unwanted notifications for up to 24 hours with no way to tell the 
server to stop it.  However I also agree with Klaus that the text as 
written is the best that can be done without providing an explicit 
mechanism to say "shut up already".

Perhaps a solution would be to say that when the server receives a RST 
from an endpoint that participates in observe it SHOULD (or MAY) 
automatically send the next notification to that endpoint as confirmable 
for each resource observed by that endpoint, thus shortening the 
response cycle.

Just a thought; I don't want to defend this approach too much.  Even if 
it doesn't make it into the spec, I think an implementation would still 
be conformant if it did react that way.

Peter

On 10/16/2013 12:06 PM, Rahman, Akbar wrote:
> Hi Klaus,
>
>
>
> Regarding my comment and your answer on section 3.6 (Cancellation).  My
> main point was that it seems illogical that a constrained device cannot
> always quickly prevent a server from sending it multiple (observe)
> messages.   There may be historical reasons for how the Reset message
> handling evolved but that shouldn't break the basic client-server
> paradigm.
>
> (I.E. Client is initiating the request and shouldn't have to continually
> receive messages that it doesn't want.  It shouldn't be the server that
> gets to decide when to stop.  The Observe handling shouldn't break the
> basic client-server model.)
>
>
> But my comment is more a principled one so please ignore it if the
> mechanics of the solution is too cumbersome.
>
>
>
> Akbar
>
>
>
> -----Original Message-----
> From: Klaus Hartke [mailto:hartke@tzi.org]
> Sent: Wednesday, October 16, 2013 11:43 AM
> To: Rahman, Akbar
> Cc: core@ietf.org WG
> Subject: Re: [core] Some initial comments on WGLC of
> draft-ietf-core-observe-11
>
> Hi Akbar,
>
> thanks a lot for your review.
>
>> 1) Section 3.6 (Cancellation)
>> - The procedure for cancelling from a client point of view seems
> overly complex and inefficient.  Why can't a Reset message from the
> client always (SHALL) force the server to stop sending notifications?
> I.E. Don't have different cases for the confirmable and non-confirmable
> notification cases.  It seems very risky that a "client may have to wait
> for a confirmable notification".
>
> CoAP initially didn't have support for reset messages in reply to
> non-confirmable messages, so a client had to wait for a confirmable
> message to tell the server that was no longer interested. This was
> changed in observe-04/coap-09, but it requires the server to keep track
> of the message IDs of the non-confirmable notifications that it sends,
> which is something it didn't have to do before. So the consensus at that
> time was to make this requirement OPTIONAL.
>
> I see no strong need to change it to REQUIRED (a client MUST reject
> every unwanted non-confirmable notification with a reset message; a
> server MUST remember message IDs of non-confirmable notifications for
> cancellation): When a reset message doesn't reach the server because of
> message loss, the client has to reject notifications anyway until the
> server stops sending. And an implementer of a client already doesn't
> have to distinguish between confirmable and non-confirmable
> notifications if he doesn't want to.
>
>> 2) Section 6 (Web Linking)
>> - The comment in the second paragraph that "obs" should have "a
> suitable graphical representation in a user interface" was interesting.
> This is the first time that I recall seeing user graphical interface
> references in CORE documents.  I am not objecting to this, but was there
> some special motivation for putting it?
>
> Most clients know if they need a current resource representation over a
> period time or not, so the "obs" attribute is mostly useful if the
> client is an application-agnostic browser like Copper. So a graphical
> representation in a user interface is basically the only known use-case.
>
>> 3) Section 7 (Security Considerations)
>> - The following sentence should be re-worded for clarity: "The
> considerations about amplification attacks are somewhat amplified ..."
>
> What do you propose?
>
>> I am still (re-)reading the document but I thought that I would send
> you these initial comments in the interim.
>
> I'm looking forward to further comments/questions from you :-)
>
> Best regards,
> Klaus
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>


From pab@pabigot.com  Wed Oct 16 10:54:53 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB7D11E82F7 for ; Wed, 16 Oct 2013 10:54:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.276
X-Spam-Level: 
X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=0.323,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRvgG3shxtki for ; Wed, 16 Oct 2013 10:54:40 -0700 (PDT)
Received: from p3plsmtpa09-10.prod.phx3.secureserver.net (p3plsmtpa09-10.prod.phx3.secureserver.net [173.201.193.239]) by ietfa.amsl.com (Postfix) with ESMTP id 1B30311E82C1 for ; Wed, 16 Oct 2013 10:54:39 -0700 (PDT)
Received: from [192.168.65.10] ([66.41.60.82]) by p3plsmtpa09-10.prod.phx3.secureserver.net with  id dtuc1m00W1mTNtu01tudCQ; Wed, 16 Oct 2013 10:54:38 -0700
Message-ID: <525ED2DE.5050600@pabigot.com>
Date: Wed, 16 Oct 2013 12:54:38 -0500
From: "Peter A. Bigot" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: core 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [core] WGLC observe comment: notification supersedure
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Oct 2013 17:54:53 -0000

Although I raised this before, for WGLC I'm hoping for comments from
others.  One reviewer "dislike" and one author "like" is not much
of a consensus.

observe-11 section 4.5 adds a requirement that if the state of an
observed resource changes while a confirmable message has not been
acknowledged, the server MUST replace the content of the message for any
remaining retransmissions (superseding the previous message).

I believe this is an inappropriate expansion of functionality by a CoAP
protocol extension.  Here goes the argument:

CoAP (per coap-18) specifies the behavior of the protocol with respect
to message-layer (CON/NON/ACK/RST) and transaction-layer
(Request/Response) behavior.  The process for a confirmable message
transmission is well-defined, including a limited number of BEBO (binary
exponential back off) retransmissions.

coap-18 (section 4.2) permits a sender to stop retransmitting a
confirmable message in certain circumstances.

In section 5.10.5 coap-18 permits, but does not require, a sender to
modify an option value prior to retransmission if the message contains a
representation of a resource with strict tolerances on Max-Age.

Overall coap-18 describes how protocol extensions may specify new
options, as long as they obey critical/unsafe/no-cache-key standards,
and may define new request methods and response codes, so an implementer
can take that into account.

But there is nothing in base CoAP that suggests that other options or
content of a message may be changed prior to retransmission, or that
right-to-retransmit may be "donated" for the purposes of sending a new
message earlier than would normally be permitted by congestion control
(viz., upon acknowledgement or elapse of EXCHANGE_LIFETIME).

To meet the MUST requirement proposed by observe-11 4.5 an implementer
would have to provide an interface to the message layer that provides
supersedure functionality that is not envisioned by coap-18.

I believe it is inappropriate for an extension to require an implementer
to change the documented message-layer behavior of the base protocol in
order to support that extension.

To fix this I propose: Change step 3 in section 4.5 to something like:

    3.  If the entry is still in the list of observers, the server MAY
        replace the message with a new notification with a representation
        of the current resource state.  Should the resource have changed
        its state more than once in the meantime, the notifications for
        the intermediate states are silently skipped.

This does not obligate the implementation to support message
supersedure, as the current text does even if updates have no "strict 
tolerance" for timeliness for a particular resource.

It keeps the expectation that if a client fails to acknowledge a 
confirmable notification after BEBO completes all transmissions the 
client is removed from the list of observers.

And it allows the supersedure if the implementation chooses to support it.

Everybody wins?

Peter

From pab@pabigot.com  Wed Oct 16 10:55:12 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B42111E82E1 for ; Wed, 16 Oct 2013 10:55:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.317
X-Spam-Level: 
X-Spam-Status: No, score=-2.317 tagged_above=-999 required=5 tests=[AWL=0.283,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJMYrEfhEg1w for ; Wed, 16 Oct 2013 10:55:02 -0700 (PDT)
Received: from p3plsmtpa09-10.prod.phx3.secureserver.net (p3plsmtpa09-10.prod.phx3.secureserver.net [173.201.193.239]) by ietfa.amsl.com (Postfix) with ESMTP id 03B8B11E82F4 for ; Wed, 16 Oct 2013 10:54:41 -0700 (PDT)
Received: from [192.168.65.10] ([66.41.60.82]) by p3plsmtpa09-10.prod.phx3.secureserver.net with  id dtug1m00P1mTNtu01tuhCv; Wed, 16 Oct 2013 10:54:41 -0700
Message-ID: <525ED2E2.10300@pabigot.com>
Date: Wed, 16 Oct 2013 12:54:42 -0500
From: "Peter A. Bigot" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: core 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [core] WGLC observe comment: responsiveness to unacknowledged confirmable notifications
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Oct 2013 17:55:12 -0000

Several places in observe-11 state that a client's failure to
acknowledge a confirmable notification will cause the client to be
removed from the list of observers, but the timeliness of that result is
not clear: "after several transmission attempts" (section 1.2)
"eventually remove" (section 3.5).

Only the steps in section 4.5, which are conditional on the resource
changing while a notification is outstanding, specify that the client
should be dropped if a confirmable message remains unacknowledged after
its last retransmission ("last attempt to deliver a notification").

The timeliness of dropping the client should not depend on a resource
changing during the process of notification transmission.  Somewhere it
should be made clear that the client is dropped the first time it fails
to acknowledge a confirmable message within the EXCHANGE_LIFETIME, 
either by reworking the steps 4.5 to not be conditional or by putting 
the requirement somewhere else.

Peter

From salvatore.loreto@ericsson.com  Wed Oct 16 11:03:17 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA3811E813D for ; Wed, 16 Oct 2013 11:03:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Level: 
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9E76MQJyJq9 for ; Wed, 16 Oct 2013 11:03:12 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6EF21F9EDA for ; Wed, 16 Oct 2013 11:03:11 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-ed-525ed4de31db
Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 45.03.03802.ED4DE525; Wed, 16 Oct 2013 20:03:10 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.228]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0328.009; Wed, 16 Oct 2013 20:03:10 +0200
From: Salvatore Loreto 
To: "" 
Thread-Topic: [core] sleepy nodes
Thread-Index: AQHOyZyiCUd7/rJbB0KHqPWUMZQPUZn3PqaAgAAUOoCAACxSAA==
Date: Wed, 16 Oct 2013 18:03:09 +0000
Message-ID: <2B9B48179856DC4FA00C93C79EB7E64A2C56A2@ESESSMB109.ericsson.se>
References: <49802db7bb1d96cfccc488402a8bcc77@xs4all.nl> <2B9B48179856DC4FA00C93C79EB7E64A2C5130@ESESSMB109.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.148]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <4E78FE07B574FA4CA168DD713043787C@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+Jvje69K3FBBis3GFv8mtDEZPFo/yo2 i31v1zM7MHssWfKTyWPp9TZWjxMN29kDmKO4bFJSczLLUov07RK4Mi5d/cpScF2uom/SC7YG xoMSXYycHBICJhK72x4xQdhiEhfurWfrYuTiEBI4zCix9OcOKGcJo0T7p2uMIFVsAmYSzx9u Ye5i5OAQEbCXeNjlChJmFnCT6F98iB0kLCygIHHrPStIWERAUaJ91gpGCNtJYuapxcwgNouA qkTX1m8sIOW8At4SW6dkQmxaySgxtXEaG0gNp4ClxNWGThYQmxHotu+n1jBBrBKXuPVkPtTN AhJL9pxnhrBFJV4+/scKYStJNC55wgpRbyDx/tx8ZgjbWuLBwsMsELa2xLKFr8HivAKCEidn PmGZwCg+C8mKWUjaZyFpn4WkfRaS9gWMrKsY2XMTM3PSy402MQKj7OCW36o7GO+cEznEKM3B oiTO++Gtc5CQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGRmXXqA4JRUmueb9DE69IXsta0aWx /+jt+S9uL/4vNV8jco59zYG73ovNX+lH5pVK3NDa2lmrWdTxR8f8utIEJy3hy4wvUs9HPf9y SnBropGjZECHt9o81nnX/Z3TG57yVc3J5myJPtMh8sa+Z83VGzKKbuyaXq1mj9+47WY8o/A9 4cMHlacHlViKMxINtZiLihMB9CF0+oACAAA=
Cc: Core 
Subject: Re: [core] sleepy nodes
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Oct 2013 18:03:17 -0000

On Oct 16, 2013, at 6:24 PM, peter van der Stok 
 wrote:

> Hi Salvatore,
>=20
> with application oriented read also: manufacturer- or consortium of manuf=
acturers oriented.
>=20
> I see your point that it is useful to recognize during discovery that the=
 device exists, has an IP address, but reacts funny.
> On the other hand, one can decide to make the "intermittent node" invisib=
le in the discovery process, and discover the proxies instead.

> Next question, do we need to recognize that these are proxies?
> I would argue that depends on the application and the way the proxy is co=
nstructed. It probably has to do with the validity of the returned values.

exactly it should be at least possible to discriminate the fact that the re=
source you discovered is hosted by the proxy
but belong to some other node (i.e. the value you read on the node is not f=
resh etc.etc)

and also how you configure an intermittent node so that its resource can be=
 hosted by a Proxy, etc. etc.

The way you are describing Proxy appears to me more as a Server hosting a r=
esource that is updated by magic=20

> However, the "intermittent node" should not respond to any query, any tim=
e (be truly invisible) unless it is the proxy that queries it.
>=20
> would that be reasonable?

no an intermittent node is special only in the sense that is not reachable =
all the time (the reason can be different, it's sleeping, it is behind a NA=
T
etc) but for the rest it should be equal to the other sensors.

br
/Sal

>=20
> Peter
>=20
>=20
> Salvatore Loreto schreef op 2013-10-16 16:12:
>> Dear Peter,
>> not sure all you mentioned below are strictly application oriented aspec=
ts.
>> I still feel we lack in core some general mechanism to handle the case
>> (intermittent nodes it is really more general and better then sleeping
>> one)  in an standard way=85
>> it can be as simple as the one defined in OMA lightweight standard
>> (i.e. a RD registration parameter used to indicate a node in a queue mod=
e)
>> but at least we need a standard mechanism that let the client
>> recognise "the node is trying to reach
>> is not available=85" and how it should behave if it really want to conta=
ct it
>> Salvatore
>> On Oct 15, 2013, at 2:49 PM, peter van der Stok  wro=
te:
>> Dear all,
>> reading the draft on the need for sleepy nodes by Akbar, I become more c=
onvinced that the subject is not right for IETF.
>> Already defining a sleepy node is fraught with application oriented aspe=
cts.
>> Taking the advice of Zach, that you only want to define a proxy leaves a=
lso many possibilities open, like:
>> Does the sleepy node communicate only with the proxy?
>> Can the sleepy node send to other nodes than the proxy via multicast or =
unicast?
>> Does the sleepy node need maintenance?
>> Is the sleepy node initialized at the factory and it never listens to an=
y messages afterwards?
>> Or is there an initialization capability, eventually supported by a batt=
ery recharge.
>> I can go on and on like this, (for example on timing constraints) and no=
ne of the questions will get satisfactory unanimous answers.
>> Therefore, I remain with my conclusion that sleepy nodes are interesting=
 but too much conditioned by application constraints to define a proxy appr=
oach that is generally applicable.
>> If anything needs to be done I still think that the "mirror server" draf=
t is the best choice because I recognize the boundary conditions.
>> But the latter is a very application biased opinion.
>> Peter
>> --
>> Peter van der Stok
>> mailto: consultancy@vanderstok.org
>> www: www.vanderstok.org
>> tel NL: +31(0)492474673     F: +33(0)966015248
>> _______________________________________________
>> core mailing list
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core


From hartke@tzi.org  Wed Oct 16 11:14:32 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE6711E81A4 for ; Wed, 16 Oct 2013 11:14:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.627
X-Spam-Level: 
X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRXCEoXxX-Sf for ; Wed, 16 Oct 2013 11:14:27 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 5054011E814C for ; Wed, 16 Oct 2013 11:14:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9GIEM9R005048 for ; Wed, 16 Oct 2013 20:14:22 +0200 (CEST)
Received: from mail-ve0-f180.google.com (mail-ve0-f180.google.com [209.85.128.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 AFD815A0 for ; Wed, 16 Oct 2013 20:14:22 +0200 (CEST)
Received: by mail-ve0-f180.google.com with SMTP id db12so588240veb.25 for ; Wed, 16 Oct 2013 11:14:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=uXe7KhDJt3QfHdGc2DK+dA/TzIoCmqSlfj9BYnd2opA=; b=J2uQIYfB6dy2z7Z7B/wBGpfW1IgXMcLD570qglxabpVnVDFvsnBz6c6a8FiQnRXrpy 59xR6NiNh1KfwnWnvrDLXvrWUNRBinSuJugD8VXh5PfdxPP6svd5/R1nJi0mhF/siruc WDdsBb26PnbJfL7fwNP1vm3t5cLCI+Zbjje5I9BxmfXCGEoPVNWIlH/5i0+66F85wb1o gQbD2os34qzuLtqZx04lQtAkuW/hZUYddbsdIL7Rj3CYcGTtGVHq4XE4/duoiJrZId21 u4QQ3C+WpwVC1apoUgnvtyyjAMCKybBgsHBs23TZtgu+RyMURIE0E9Iid9OnRNtM1DJo EI5Q==
X-Received: by 10.58.54.69 with SMTP id h5mr43354vep.25.1381947261265; Wed, 16 Oct 2013 11:14:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.24.83 with HTTP; Wed, 16 Oct 2013 11:13:41 -0700 (PDT)
In-Reply-To: 
References: <5A6D74B4-3733-45D1-95B1-E838DADED234@tzi.org>   
From: Klaus Hartke 
Date: Wed, 16 Oct 2013 21:13:41 +0300
Message-ID: 
To: "Rahman, Akbar" 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "core@ietf.org WG" 
Subject: Re: [core] Some initial comments on WGLC of draft-ietf-core-observe-11
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Oct 2013 18:14:32 -0000

Akbar Rahman wrote:
> How about:
>
> FROM:
> -----
> The considerations about amplification attacks are somewhat amplified
> when observing resources.
>
>
> TO:
> ---
> Observing resources can dramatically increase the negative effects of
> amplification attacks.  That is, not only can the response packet be
> significantly larger than the request packet, but the nature of observe
> causes many response packets to be generated.

Fixed in SVN. 

Thanks!

- Klaus

From trac+core@trac.tools.ietf.org  Wed Oct 16 11:27:39 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3706C11E81A4 for ; Wed, 16 Oct 2013 11:27:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.478
X-Spam-Level: 
X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VI0v4vdiPSHh for ; Wed, 16 Oct 2013 11:27:38 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 651FF21F9C6A for ; Wed, 16 Oct 2013 11:27:38 -0700 (PDT)
Received: from localhost ([127.0.0.1]:47021 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VWVon-0006UM-0k; Wed, 16 Oct 2013 20:27:37 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "core issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-core-observe@tools.ietf.org, hartke@tzi.org
X-Trac-Project: core
Date: Wed, 16 Oct 2013 18:27:36 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/350
Message-ID: <053.2ad2cf6e1364761fb593a8a5b210864c@trac.tools.ietf.org>
X-Trac-Ticket-ID: 350
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-core-observe@tools.ietf.org, hartke@tzi.org, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: hartke@tzi.org
Resent-Message-Id: <20131016182738.651FF21F9C6A@ietfa.amsl.com>
Resent-Date: Wed, 16 Oct 2013 11:27:38 -0700 (PDT)
Resent-From: trac+core@trac.tools.ietf.org
Cc: core@ietf.org
Subject: [core]  #350: Unacknowledged confirmable notifications
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: trac+core@trac.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Oct 2013 18:27:39 -0000

#350: Unacknowledged confirmable notifications

 Peter A. Bigot notes:

 Several places in observe-11 state that a client's failure to acknowledge
 a confirmable notification will cause the client to be removed from the
 list of observers, but the timeliness of that result is not clear: "after
 several transmission attempts" (section 1.2) "eventually remove" (section
 3.5).

 Only the steps in section 4.5, which are conditional on the resource
 changing while a notification is outstanding, specify that the client
 should be dropped if a confirmable message remains unacknowledged after
 its last retransmission ("last attempt to deliver a notification").

 -> In section 4.5, make clear that the entry in the list of observers is
 removed if the client failed to acknowledge a confirmable notification
 before the last transmission attempt timed out, irrespective of whether
 the resource changes during the transmission process or not.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-core-
  hartke@tzi.org         |  observe@tools.ietf.org
     Type:  editorial    |     Status:  new
 Priority:  minor        |  Milestone:  post-WGLC-2
Component:  observe      |    Version:  observe-11
 Severity:  In WG Last   |   Keywords:
  Call                   |
-------------------------+-------------------------------------------------

Ticket URL: 
core 


From hartke@tzi.org  Wed Oct 16 11:39:04 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B62E411E82D2 for ; Wed, 16 Oct 2013 11:39:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.627
X-Spam-Level: 
X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tcBp58S1YkuL for ; Wed, 16 Oct 2013 11:39:00 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF1611E81E4 for ; Wed, 16 Oct 2013 11:38:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9GIcs40021000 for ; Wed, 16 Oct 2013 20:38:54 +0200 (CEST)
Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 630F95B1 for ; Wed, 16 Oct 2013 20:38:54 +0200 (CEST)
Received: by mail-vc0-f178.google.com with SMTP id lh4so580934vcb.37 for ; Wed, 16 Oct 2013 11:38:53 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=IbQpaTyN5rFhLpPMTTS/YtRzOlM7EnfY6XY/b0wHLZE=; b=D5Wwtc88ByJIZ1cADmh89IWSuAw6swU9nx7ehjDx0oh/X1oIPsGGWp8Tzq1pBSdPA2 SYryIWryAVIOlBXxkIR1Knk2oky9+gQxQ7pW+iWfLG0laJqNZ8SkrnYaQ/IZ+mFf/LKb dWFgVQGiDRY96GANgrbOPkRj3DHAukKNeGspO88YuLGis2t7N6FNDzVJJg9QS5Hhh8wP MyWcN4eN/f+Ttd9VyU8BNyi5NGPI4IBfIOZf2CoYMDxPmiIXXonEGZy6dnDyVNNu6sIH NlEEmd5SdqRP5dmXexNg68E/GoXwQaQnzf8LVa2amagqB+wjWqRP6ShIOmMhtvpPVf/p 2a+A==
X-Received: by 10.52.26.69 with SMTP id j5mr2894772vdg.21.1381948733136; Wed, 16 Oct 2013 11:38:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.24.83 with HTTP; Wed, 16 Oct 2013 11:38:12 -0700 (PDT)
In-Reply-To: <525ED2E2.10300@pabigot.com>
References: <525ED2E2.10300@pabigot.com>
From: Klaus Hartke 
Date: Wed, 16 Oct 2013 21:38:12 +0300
Message-ID: 
To: "Peter A. Bigot" 
Content-Type: text/plain; charset=ISO-8859-1
Cc: core 
Subject: Re: [core] WGLC observe comment: responsiveness to unacknowledged confirmable notifications
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Oct 2013 18:39:04 -0000

Hi Peter,

good catch. Section 4 of observe-11 indeed never states the
requirement to remove the client when the last transmission attempt
times out, as hinted at in the previous sections. I've opened ticket
#350 for this .

Best regards,
Klaus


On 16 October 2013 20:54, Peter A. Bigot  wrote:
> Several places in observe-11 state that a client's failure to
> acknowledge a confirmable notification will cause the client to be
> removed from the list of observers, but the timeliness of that result is
> not clear: "after several transmission attempts" (section 1.2)
> "eventually remove" (section 3.5).
>
> Only the steps in section 4.5, which are conditional on the resource
> changing while a notification is outstanding, specify that the client
> should be dropped if a confirmable message remains unacknowledged after
> its last retransmission ("last attempt to deliver a notification").
>
> The timeliness of dropping the client should not depend on a resource
> changing during the process of notification transmission.  Somewhere it
> should be made clear that the client is dropped the first time it fails
> to acknowledge a confirmable message within the EXCHANGE_LIFETIME, either by
> reworking the steps 4.5 to not be conditional or by putting the requirement
> somewhere else.
>
> Peter

From cabo@tzi.org  Wed Oct 16 12:12:07 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D01B11E81AF for ; Wed, 16 Oct 2013 12:12:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.165
X-Spam-Level: 
X-Spam-Status: No, score=-106.165 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSiYfHSY72jY for ; Wed, 16 Oct 2013 12:12:01 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id EB90D11E8136 for ; Wed, 16 Oct 2013 12:12:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9GJBw2O025783; Wed, 16 Oct 2013 21:11:58 +0200 (CEST)
Received: from [192.168.217.105] (p54891B93.dip0.t-ipconnect.de [84.137.27.147]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id AA5C95C1; Wed, 16 Oct 2013 21:11:57 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: 
Date: Wed, 16 Oct 2013 21:11:56 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <6D0D5F00-5A02-43D6-866C-6027777DA7FB@tzi.org>
References: <5A6D74B4-3733-45D1-95B1-E838DADED234@tzi.org>   
To: "Rahman, Akbar" 
X-Mailer: Apple Mail (2.1510)
Cc: core@ietf.org, Klaus Hartke 
Subject: Re: [core] Some initial comments on WGLC of draft-ietf-core-observe-11
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Oct 2013 19:12:07 -0000

On Oct 16, 2013, at 18:56, "Rahman, Akbar" =
 wrote:

> Observing resources can dramatically increase the negative effects of
> amplification attacks.  That is, not only can the response packet be
> significantly larger than the request packet, but the nature of =
observe
> causes many response packets to be generated.

Hmm.  That might be overstating it.
Or if that is not overstating it, maybe we don't pull enough stops.

As long as the server uses confirmable only, it will quickly learn about =
the disinterest of a spoofed "client".  So the amplification of the =
amplification will be on the order of MAX_RETRANSMIT.  This wouldn't =
justify this language.

On to Non-confirmable.  Here, with the current language:

-- we have the 24-hour limit (4.5).

-- we have the three-second limit (4.5), which however is phrased as a =
SHOULD.

So an attacker could spoof an observation relationship to a =
fast-changing resource F on S and get S to send 1/3 messages per second =
to C.  Since port numbers allow spoofing multiple clients at the same =
host, the actual limit is 2**16/3 messages per second per client host =
(for 2**16 attack packets).

The three-second limit is conditional on "If the server cannot maintain =
an RTT estimate for a client,".
If it can (advanced congestion control):

-- "The server SHOULD NOT send more than one non-confirmable =
notification
   per round-trip time (RTT) to a client on average." (I'm reading this =
as 1/RTT
   for all resources combined, but that may need to be made explicit.)

So an attacker that knows client C is observing slow-changing resource R =
on server S, which keeps an RTT estimator running, could spoof an =
observation relationship to a fast-changing resource F on S and, with a =
single attack packet, zap C at 1/RTT messages per second until the RTT =
estimator (run based on the notifications from R) tanks.

Of course nobody in their right mind would design a server this way, but =
we may need additional language explaining what we expect a server to do =
here.

Gr=FC=DFe, Carsten


From Akbar.Rahman@InterDigital.com  Wed Oct 16 12:36:06 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3E311E8181 for ; Wed, 16 Oct 2013 12:36:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdTtWinmWFKS for ; Wed, 16 Oct 2013 12:36:00 -0700 (PDT)
Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6722B11E81E0 for ; Wed, 16 Oct 2013 12:35:57 -0700 (PDT)
Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 16 Oct 2013 15:35:56 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 16 Oct 2013 15:35:55 -0400
Message-ID: 
In-Reply-To: <6D0D5F00-5A02-43D6-866C-6027777DA7FB@tzi.org>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [core] Some initial comments on WGLC of draft-ietf-core-observe-11
Thread-Index: Ac7Ko6to61VtSxkQRN+9g0R3MdnNlAAAymXA
References: <5A6D74B4-3733-45D1-95B1-E838DADED234@tzi.org>    <6D0D5F00-5A02-43D6-866C-6027777DA7FB@tzi.org>
From: "Rahman, Akbar" 
To: "Carsten Bormann" 
X-OriginalArrivalTime: 16 Oct 2013 19:35:56.0032 (UTC) FILETIME=[EED01800:01CECAA6]
Cc: core@ietf.org, Klaus Hartke 
Subject: Re: [core] Some initial comments on WGLC of draft-ietf-core-observe-11
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Oct 2013 19:36:06 -0000

> ... but we may need additional language explaining what we expect a =
server to do here.


Yes, definitely.



-----Original Message-----
From: Carsten Bormann [mailto:cabo@tzi.org]=20
Sent: Wednesday, October 16, 2013 3:12 PM
To: Rahman, Akbar
Cc: Klaus Hartke; core@ietf.org
Subject: Re: [core] Some initial comments on WGLC of =
draft-ietf-core-observe-11

On Oct 16, 2013, at 18:56, "Rahman, Akbar" =
 wrote:

> Observing resources can dramatically increase the negative effects of=20
> amplification attacks.  That is, not only can the response packet be=20
> significantly larger than the request packet, but the nature of=20
> observe causes many response packets to be generated.

Hmm.  That might be overstating it.
Or if that is not overstating it, maybe we don't pull enough stops.

As long as the server uses confirmable only, it will quickly learn about =
the disinterest of a spoofed "client".  So the amplification of the =
amplification will be on the order of MAX_RETRANSMIT.  This wouldn't =
justify this language.

On to Non-confirmable.  Here, with the current language:

-- we have the 24-hour limit (4.5).

-- we have the three-second limit (4.5), which however is phrased as a =
SHOULD.

So an attacker could spoof an observation relationship to a =
fast-changing resource F on S and get S to send 1/3 messages per second =
to C.  Since port numbers allow spoofing multiple clients at the same =
host, the actual limit is 2**16/3 messages per second per client host =
(for 2**16 attack packets).

The three-second limit is conditional on "If the server cannot maintain =
an RTT estimate for a client,".
If it can (advanced congestion control):

-- "The server SHOULD NOT send more than one non-confirmable =
notification
   per round-trip time (RTT) to a client on average." (I'm reading this =
as 1/RTT
   for all resources combined, but that may need to be made explicit.)

So an attacker that knows client C is observing slow-changing resource R =
on server S, which keeps an RTT estimator running, could spoof an =
observation relationship to a fast-changing resource F on S and, with a =
single attack packet, zap C at 1/RTT messages per second until the RTT =
estimator (run based on the notifications from R) tanks.

Of course nobody in their right mind would design a server this way, but =
we may need additional language explaining what we expect a server to do =
here.

Gr=FC=DFe, Carsten


From stokcons@xs4all.nl  Thu Oct 17 00:20:00 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F84021F9C1D for ; Thu, 17 Oct 2013 00:20:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.154
X-Spam-Level: 
X-Spam-Status: No, score=-0.154 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqTxt8zYuu91 for ; Thu, 17 Oct 2013 00:19:55 -0700 (PDT)
Received: from smtp-vbr14.xs4all.nl (smtp-vbr14.xs4all.nl [194.109.24.34]) by ietfa.amsl.com (Postfix) with ESMTP id BA70921F9EF6 for ; Thu, 17 Oct 2013 00:19:54 -0700 (PDT)
Received: from roundcube.xs4all.nl (roundcube8.xs4all.net [194.109.20.206]) by smtp-vbr14.xs4all.nl (8.13.8/8.13.8) with ESMTP id r9H7Jqvv096416; Thu, 17 Oct 2013 09:19:52 +0200 (CEST) (envelope-from stokcons@xs4all.nl)
Received: from AMontpellier-654-1-109-86.w90-0.abo.wanadoo.fr ([90.0.84.86]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 17 Oct 2013 09:19:52 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Date: Thu, 17 Oct 2013 09:19:52 +0200
From: peter van der Stok 
To: esko dijk , Core , akbar rahman 
Organization: vanderstok consultancy
Mail-Reply-To: consultancy@vanderstok.org
Message-ID: <2f971a2d5463c294e6e4dcf5610acc6d@xs4all.nl>
X-Sender: stokcons@xs4all.nl (YdMNUbgN75DvEuRLkz89YAo6Vu/50QmX)
User-Agent: XS4ALL Webmail
X-Virus-Scanned: by XS4ALL Virus Scanner
Subject: [core] group-comm draft
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: consultancy@vanderstok.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Oct 2013 07:20:00 -0000

Hi Esko and Akbar,

Recently I reread the group comm draft and came to reconsider the text 
of section 2.6.2.3. PUT Interface


The text:
"A (unicast) PUT with an empty array [] will delete all group
memberships from the endpoint. Note that it is not possible to
delete individual group memberships on an endpoint. (A DELETE
interface is not defined as the underlying resource should not be
removed even if it is empty)."

provides a means to remove all group membership entries in one go.
This should be made less radical in my opinion to support the partial 
removal of group memberships or the removal of one membership at the 
time.

Let me motivate this request.

During setting up of installations, many cabling and other errors are 
made.
Consequently, the behaviour of the network is not always as expected.
In such circumstances one can imagine the installer adding group members 
until break-down of the process.
In that case, the installer should like to remove one membership.
Removing all would lead to a lengthy re-entry of the earlier 
memberships.

Imagine this happening not once, but several times.

I hope I convinced you to reconsider the specification of section 
2.6.2.3.

Peter



-- 
Peter van der Stok
mailto: consultancy@vanderstok.org
www: www.vanderstok.org
tel NL: +31(0)492474673     F: +33(0)966015248

From esko.dijk@philips.com  Thu Oct 17 01:54:31 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68DF521F9CE3 for ; Thu, 17 Oct 2013 01:54:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.467
X-Spam-Level: 
X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[AWL=2.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhuNKDx8ec8d for ; Thu, 17 Oct 2013 01:54:27 -0700 (PDT)
Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe002.messaging.microsoft.com [207.46.163.25]) by ietfa.amsl.com (Postfix) with ESMTP id 10F9221F9E70 for ; Thu, 17 Oct 2013 01:54:25 -0700 (PDT)
Received: from mail73-co9-R.bigfish.com (10.236.132.242) by CO9EHSOBE002.bigfish.com (10.236.130.65) with Microsoft SMTP Server id 14.1.225.22; Thu, 17 Oct 2013 08:54:25 +0000
Received: from mail73-co9 (localhost [127.0.0.1])	by mail73-co9-R.bigfish.com (Postfix) with ESMTP id F1AE6600D3; Thu, 17 Oct 2013 08:54:24 +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: -29
X-BigFish: VPS-29(zzdb82h217bI98dI15d6O9371I542I9251Idd85kzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL17326ah8275dh1de097h186068h1954cbh8275bhz2dh2a8h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h1155h)
Received: from mail73-co9 (localhost.localdomain [127.0.0.1]) by mail73-co9 (MessageSwitch) id 1382000062770063_9309; Thu, 17 Oct 2013 08:54:22 +0000 (UTC)
Received: from CO9EHSMHS014.bigfish.com (unknown [10.236.132.252])	by mail73-co9.bigfish.com (Postfix) with ESMTP id B533E340075; Thu, 17 Oct 2013 08:54:22 +0000 (UTC)
Received: from mail.philips.com (157.55.7.222) by CO9EHSMHS014.bigfish.com (10.236.130.24) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 17 Oct 2013 08:54:21 +0000
Received: from 011-DB3MMR1-023.MGDPHG.emi.philips.com (10.128.28.107) by 011-DB3MMR1-011.MGDPHG.emi.philips.com (10.128.28.50) with Microsoft SMTP Server (TLS) id 14.3.146.2; Thu, 17 Oct 2013 08:53:47 +0000
Received: from 011-DB3MPN2-083.MGDPHG.emi.philips.com ([169.254.3.36]) by 011-DB3MMR1-023.MGDPHG.emi.philips.com ([fe80::e485:97aa:9b41:86e3%11]) with mapi id 14.03.0146.002; Thu, 17 Oct 2013 08:53:47 +0000
From: "Dijk, Esko" 
To: Zach Shelby , "Rahman, Akbar" 
Thread-Topic: [core] New Version Notification fordraft-rahman-core-sleepy-nodes-do-we-need-00.txt
Thread-Index: AQHOyPiSd4d26zqRvEGIWGEaq+LwzJn2BUuAgAANK4CAAoK+EA==
Date: Thu, 17 Oct 2013 08:53:46 +0000
Message-ID: <031DD135F9160444ABBE3B0C36CED618017190F7@011-DB3MPN2-083.MGDPHG.emi.philips.com>
References:      <73BC38E7-0464-4219-B314-9A57430F1C48@sensinode.com>
In-Reply-To: <73BC38E7-0464-4219-B314-9A57430F1C48@sensinode.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [194.171.252.106]
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%
X-FOPE-CONNECTOR: Id%0$Dn%INTERDIGITAL.COM$RO%1$TLS%0$FQDN%$TlsDn%
Cc: "core@ietf.org" 
Subject: Re: [core] New Version Notification	fordraft-rahman-core-sleepy-nodes-do-we-need-00.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Oct 2013 08:54:31 -0000

> The trick is if we can document the bare minimum of the protocol and inte=
rface mechanisms needed to support those different applications.
+1
In this light, using one mechanism to address "intermittent reachability" n=
odes that also covers the sleepy nodes space would be great.
There are slight differences in properties but these indeed may not matter =
for the CoRE mechanism used. (For example, for a mains-powered cellular M2M=
 node behind a NAT it could be not a problem to keep the GPRS connection 'a=
live' for 20 minutes when needed, or longer. For a power-harvesting device,=
 it may only have energy storage to enable its radio for 20 seconds after w=
hich it has to sleep again.)

In November I will check some proposals in CoRE so far against the requirem=
ents for sleepy devices (http://tools.ietf.org/html/draft-dijk-core-sleepy-=
reqs-00 ).
What I have so far is:

1. Mirror Server http://tools.ietf.org/html/draft-vial-core-mirror-server-0=
1

2. Resource Directory with built-in request queuing (specs OMA Lightweight =
M2M)

3. Publish Option http://tools.ietf.org/html/draft-fossati-core-publish-mon=
itor-options-01

4. RD based sleep tracking http://tools.ietf.org/html/draft-rahman-core-sle=
epy-04

Note that all above proposals are based on one fundamental assumption: the =
sleepy (or intermittent reachable) device needs to be a CoAP server. I.e. i=
t has resources that another node needs to access. And that assumption coul=
d be dropped, while still being able to design a solution to meet the requi=
rements I think. Though it may not be the prettiest solution.

Esko

-----Original Message-----
From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Zac=
h Shelby
Sent: Tuesday, October 15, 2013 20:13
To: Rahman, Akbar
Cc: core@ietf.org
Subject: Re: [core] New Version Notification fordraft-rahman-core-sleepy-no=
des-do-we-need-00.txt

On Oct 15, 2013, at 10:26 AM, "Rahman, Akbar"  wrote:

>       "This is in practice realised with a Proxy and an RD in the same bo=
x. An RD registration parameter is used to indicate that a node is in queue=
  mode. From there on the proxy queues all incoming requests to the node, w=
hich are released upon reception of a registration update request from the =
    node. If the WG wants, this could fairly easily be documented in the Re=
source Directory draft maintaining compatibility with OMA Lightweight."

And as Peter rightly points out, if you go to far you are into lots of appl=
ication specific issues. The trick is if we can document the bare minimum o=
f the protocol and interface mechanisms needed to support those different a=
pplications.

> I think this would be a good first step to supporting these type of "inte=
rmittent reachability" nodes.  Bu it would still be worth having a discussi=
on to see if we need to support more elaborate solutions like the Mirror Se=
rver.  The answer can always be "No (at least not in CORE)".  But until we =
have the discussion we cannot really conclude that.

Personally I do think this is worth documenting Mirror Server in the WG, bu=
t I don't think it solves the (intermittently reachable node) problem broad=
ly enough to be a generic solution. So we should slowly move this towards a=
 WG document as we get other things done first, and as there are people rea=
lly implementing and using it.

Zach

--
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com @SensinodeIoT
Mobile: +358 40 7796297
Twitter: @zach_shelby
LinkedIn: http://fi.linkedin.com/in/zachshelby
6LoWPAN Book: http://6lowpan.net




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

________________________________
The information contained in this message may be confidential and legally p=
rotected under applicable law. The message is intended solely for the addre=
ssee(s). If you are not the intended recipient, you are hereby notified tha=
t any use, forwarding, dissemination, or reproduction of this message is st=
rictly prohibited and may be unlawful. If you are not the intended recipien=
t, please contact the sender by return e-mail and destroy all copies of the=
 original message.


From stokcons@xs4all.nl  Thu Oct 17 02:50:04 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07A5221F9BC2 for ; Thu, 17 Oct 2013 02:50:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.154
X-Spam-Level: 
X-Spam-Status: No, score=-0.154 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRX+if3LbuWD for ; Thu, 17 Oct 2013 02:49:59 -0700 (PDT)
Received: from smtp-vbr5.xs4all.nl (smtp-vbr5.xs4all.nl [194.109.24.25]) by ietfa.amsl.com (Postfix) with ESMTP id 297CE11E815B for ; Thu, 17 Oct 2013 02:49:56 -0700 (PDT)
Received: from roundcube.xs4all.nl (roundcube8.xs4all.net [194.109.20.206]) by smtp-vbr5.xs4all.nl (8.13.8/8.13.8) with ESMTP id r9H9nt5b042597 for ; Thu, 17 Oct 2013 11:49:56 +0200 (CEST) (envelope-from stokcons@xs4all.nl)
Received: from AMontpellier-654-1-109-86.w90-0.abo.wanadoo.fr ([90.0.84.86]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 17 Oct 2013 11:49:55 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Date: Thu, 17 Oct 2013 11:49:55 +0200
From: peter van der Stok 
To: Core 
Organization: vanderstok consultancy
Mail-Reply-To: consultancy@vanderstok.org
Message-ID: <43a50821cc69963c3c83dd3239c26b00@xs4all.nl>
X-Sender: stokcons@xs4all.nl (HYFGrpKW5KuoXxTtaIVs6iNIDGlDcDzV)
User-Agent: XS4ALL Webmail
X-Virus-Scanned: by XS4ALL Virus Scanner
Subject: [core] Fwd: New Version Notification for draft-vanderstok-core-comi-01.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: consultancy@vanderstok.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Oct 2013 09:50:04 -0000

To Core wg members,


Bert Greevenbosch and I have submitted a new draft on access to MIBs via 
a CoAP interface.
We discuss a number of payload formats to investigate the consequences 
of the choice.
A later version should concentrate on 1 (at most 2) formats.

We are looking forward to comments

Bert and Peter

-------- Oorspronkelijke bericht --------
Onderwerp: New Version Notification for 
draft-vanderstok-core-comi-01.txt
Datum: 2013-10-17 11:45
Afzender: internet-drafts@ietf.org
Ontvanger: Peter van der Stok , Bert 
Greevenbosch , Peter Van der Stok 


A new version of I-D, draft-vanderstok-core-comi-01.txt
has been successfully submitted by Peter van der Stok and posted to the
IETF repository.

Filename:	 draft-vanderstok-core-comi
Revision:	 01
Title:		 CoAp Management Interfaces
Creation date:	 2013-10-17
Group:		 Individual Submission
Number of pages: 30
URL:             
http://www.ietf.org/internet-drafts/draft-vanderstok-core-comi-01.txt
Status:          
http://datatracker.ietf.org/doc/draft-vanderstok-core-comi
Htmlized:        
http://tools.ietf.org/html/draft-vanderstok-core-comi-01
Diff:            
http://www.ietf.org/rfcdiff?url2=draft-vanderstok-core-comi-01

Abstract:
The draft describes an interface based on CoAP to manage constrained
devices via MIBs.  The proposed integration of CoAP with SNMP reduces
the code- and application development complexity by accessing MIBs
via a standard CoAP server.  The payload of the MIB request is JSON,
CBOR or XML (EXI).  The mapping from SMI to XML, JSON and CBOR is
specified.

Note

Discussion and suggestions for improvement are requested, and should
be sent to core@ietf.org.




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

The IETF Secretariat

From hartke@tzi.org  Fri Oct 18 09:43:34 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B3C11E8288 for ; Fri, 18 Oct 2013 09:43:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.627
X-Spam-Level: 
X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVnc7SkDjDlX for ; Fri, 18 Oct 2013 09:43:29 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 28E3511E827D for ; Fri, 18 Oct 2013 09:43:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9IGhH55002361 for ; Fri, 18 Oct 2013 18:43:17 +0200 (CEST)
Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A6FB328E for ; Fri, 18 Oct 2013 18:43:17 +0200 (CEST)
Received: by mail-vc0-f181.google.com with SMTP id id10so562988vcb.12 for ; Fri, 18 Oct 2013 09:43:16 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=iJnoKYx2hrJJc8DapilppIAgFQS+7R3E7HUeTth+yGI=; b=G8J+86R3W+75FCc4cLQoVlb8U0H/jKFsm/rBvXnQaKUkFKmm/YxKoeR/n7kYATUuYA y0Gb7V7YTjl4eYannupV5lizuGKPilDNBTobjQVHi2RNGPoBydQrKKjTlby2QSa/2n2W x6zZhaDU5Gbb2ROfWgMQC/f1mS2baCK7TuXTdcOWxdzmX5CRlHeiRdR6c2AM4Fn40Lu4 dUxBNgUJPFqhAfCqmpUhLYVjL5bmpRqhD1pPoDoQpl8kTrkVrh76L/le0fYxPcDwPjkS UkBDqIg28xJqZYxxB+ewdKTtALsD5CMuOphdBQC6ptqyGSX9rJn48yqlQyIe64knCFsR KyOA==
X-Received: by 10.221.51.206 with SMTP id vj14mr2103995vcb.17.1382114596346; Fri, 18 Oct 2013 09:43:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.24.83 with HTTP; Fri, 18 Oct 2013 09:42:36 -0700 (PDT)
In-Reply-To: 
References: <5A6D74B4-3733-45D1-95B1-E838DADED234@tzi.org>   
From: Klaus Hartke 
Date: Fri, 18 Oct 2013 19:42:36 +0300
Message-ID: 
To: "Rahman, Akbar" 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "core@ietf.org WG" 
Subject: Re: [core] Some initial comments on WGLC of draft-ietf-core-observe-11
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Oct 2013 16:43:34 -0000

Hi Akbar,

> Regarding my comment and your answer on section 3.6 (Cancellation).  My
> main point was that it seems illogical that a constrained device cannot
> always quickly prevent a server from sending it multiple (observe)
> messages.   There may be historical reasons for how the Reset message
> handling evolved but that shouldn't break the basic client-server
> paradigm.
>
> (I.E. Client is initiating the request and shouldn't have to continually
> receive messages that it doesn't want.  It shouldn't be the server that
> gets to decide when to stop.  The Observe handling shouldn't break the
> basic client-server model.)
>
>
> But my comment is more a principled one so please ignore it if the
> mechanics of the solution is too cumbersome.

After thinking a bit further about it, changing the client side
wouldn't actually be cumbersome at all, because it doesn't really
change anything. The text in Section 3.6 could be simplified by
removing the distinction between confirmable and non-confirmable
notifications, and a note would be added saying that, due to potential
loss of Reset messages, the client may have to reject multiple
notifications until the server finally removes the entry from the list
of observers.

Requiring the server to remember the message IDs of non-confirmable
notifications needs some discussion, but it's doable as well if there
is enough support in the working group. I guess a constrained server
could always pretend that a Reset message in reply to a
non-confirmable notification was lost. In my CoAP implementation, the
server currently remembers the message ID of a non-confirmable
notification until it starts to transmit the next message to the
client. I believe Erbium and Californium do something similar(?).

If you're asking for cancellation such that the client can actively
cancel an observation instead of only reactively by rejecting
notifications, then the consensus so far was that reactive/"garbage
collection" approach works well enough. We can certainly revisit that
decision, provided that we can make a final decision soon. We need an
alternative cancellation mechanism for some transports anyway (see,
for example, Section 2.4 of [1]). Note that over UDP this would be in
addition to the current mechanism, not in place of it, so it wouldn't
exactly make the protocol simpler.

Best regards,
Klaus


[1] http://tools.ietf.org/html/draft-savolainen-core-coap-websockets-01#section-2.4

From hartke@tzi.org  Fri Oct 18 13:10:57 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2412D11E817B for ; Fri, 18 Oct 2013 13:10:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.627
X-Spam-Level: 
X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6BOkgO6iYdpk for ; Fri, 18 Oct 2013 13:10:51 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDE611E81F2 for ; Fri, 18 Oct 2013 13:10:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9IKAc9W018835 for ; Fri, 18 Oct 2013 22:10:38 +0200 (CEST)
Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 1F4292DF for ; Fri, 18 Oct 2013 22:10:38 +0200 (CEST)
Received: by mail-vc0-f177.google.com with SMTP id ib11so577603vcb.22 for ; Fri, 18 Oct 2013 13:10:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=NmV0IH8PVnb9PDuTATDsYNeh4t+4seWXEvPlnlH5WLw=; b=fjR6K/f/Oz+G7OIhZf6/lGR9n4IeR18xXFbNOFM/8AdsHBHUe0IytVgEUT7gcgv33E wxso05eH/xCaSYnwmWEAKO8ocZUEACMfkha2IVybU8SjTp2XwAm3NNWr8K9cF/KtabAP 1U4pQPKCkUyYpURtI6i7x+JiNeZDEYQ/yQpMfTd8+Cd7zcPUKVRuA+lU5QmwBrFEQexl uFnU+HggLJKbxUtyNzpjWYHZ/M7K3dppewhWz+WyZGNA0nI6kKHVi07EU4dC9SX99slu hJKCbogljcuogYRE1TpIeh7WA+V0WelvppTXZHRjoVL7ovJ9BT8lie5gHs4LeYNnN+dM XaaQ==
X-Received: by 10.52.157.232 with SMTP id wp8mr2811136vdb.4.1382127036546; Fri, 18 Oct 2013 13:10:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.24.83 with HTTP; Fri, 18 Oct 2013 13:09:56 -0700 (PDT)
In-Reply-To: 
References:   
From: Klaus Hartke 
Date: Fri, 18 Oct 2013 23:09:56 +0300
Message-ID: 
To: Abhijan Bhattacharyya 
Content-Type: text/plain; charset=ISO-8859-1
Cc: Arpan Pal , "core@ietf.org WG" 
Subject: Re: [core] Fw: New Version Notification for draft-tcs-coap-no-response-option-03.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Oct 2013 20:10:57 -0000

Hi Abhijan,

>> * How does it work across proxies?
>
> This option is presently NOT to be forwarded by proxies and hence no
> caching. We have explained this in the text below Table 1 in section 4.
> However, this issue can be kept as an open question for experts to comment
> on.

Not forwarding the No-Response option across proxies is probably okay,
although this limits the applicability of the option a bit.

However, caches can not only be located at proxies; they can also be
employed by clients and servers. So the draft should clearly describe
how the option interacts with caches.

>> * Regarding high-frequency/real-time updates: [...]
>
> Yes. What we mean is that this option gets rid of the dependency on
> the reverse path completely where possible. The application is free to
> choose the update rates according to the system being developed
> (abiding by the prescribed bounds).

So how does the No-Response option provide a higher throughput/less
latency compared to non-confirmable notifications when using
draft-ietf-core-observe?

For high-frequency updates it might be even better to use confirmable
messages, because the acknowledgement allows the sender to send the
next update immediately instead of in a fixed interval.

I would even suspect that confirmable messages actually help in the
reduction in network clogging, because the sender can actually assess
the network conditions and does not send blindly more and more traffic
into the network. Do you happen to have some measurements on the
impact of confirmable and non-confirmable messages on network
clogging?

>> * Is the option intended to be critical or elective?
> Elective. This was already mentioned in the draft. But not in the standard
> way of CoAP spec. We have modified the table format. please check Table 1.

The table shows a default value of 0; it should probably be 31 (all
bits set - no response suppressed). Apart from that it looks good.

Option number 22 is currently not in use. You could put that into the
draft to allow people to experiment with the No-Response option more
easily.

>> * How does a sender detect if it's sending its data to a recipient
>> that is long gone?
>
> Addressed these points. Please refer to the enhanced implementation note in
> section 4.1

How does the sender start sending again when the recipient actually
didn't go away permanently but there was a problem in the network
temporarily?

>> * Should a recipient be able to detect if consecutive messages were
>> reordered?
>
> Keeping this open. Would be good if we get some expert comments.

I'm asking you :-) What's your opinion?

Best regards,
Klaus

From Akbar.Rahman@InterDigital.com  Fri Oct 18 18:06:09 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00B0B11E8103 for ; Fri, 18 Oct 2013 18:06:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4s3OIGRKBXzv for ; Fri, 18 Oct 2013 18:06:03 -0700 (PDT)
Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 55AA011E8102 for ; Fri, 18 Oct 2013 18:05:59 -0700 (PDT)
Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 18 Oct 2013 21:05:58 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 18 Oct 2013 21:05:57 -0400
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [core] Some initial comments on WGLC of draft-ietf-core-observe-11
Thread-Index: Ac7MITsGZM7i4PsfQkq2GRZZC4YlCwARPfxQ
References: <5A6D74B4-3733-45D1-95B1-E838DADED234@tzi.org>    
From: "Rahman, Akbar" 
To: "Klaus Hartke" 
X-OriginalArrivalTime: 19 Oct 2013 01:05:58.0560 (UTC) FILETIME=[5EDD9200:01CECC67]
Cc: core@ietf.org
Subject: Re: [core] Some initial comments on WGLC of draft-ietf-core-observe-11
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 19 Oct 2013 01:06:09 -0000

Hi Klaus,


Thanks for taking the time to research my question.  My FEEDBACK is
embedded below.


/Akbar



-----Original Message-----
From: Klaus Hartke [mailto:hartke@tzi.org]=20
Sent: Friday, October 18, 2013 12:43 PM
To: Rahman, Akbar
Cc: core@ietf.org WG
Subject: Re: [core] Some initial comments on WGLC of
draft-ietf-core-observe-11

Hi Akbar,

> Regarding my comment and your answer on section 3.6 (Cancellation). =20
> My main point was that it seems illogical that a constrained device=20
> cannot always quickly prevent a server from sending it multiple
(observe)
> messages.   There may be historical reasons for how the Reset message
> handling evolved but that shouldn't break the basic client-server=20
> paradigm.
>
> (I.E. Client is initiating the request and shouldn't have to=20
> continually receive messages that it doesn't want.  It shouldn't be=20
> the server that gets to decide when to stop.  The Observe handling=20
> shouldn't break the basic client-server model.)
>
>
> But my comment is more a principled one so please ignore it if the=20
> mechanics of the solution is too cumbersome.

After thinking a bit further about it, changing the client side wouldn't
actually be cumbersome at all, because it doesn't really change
anything. The text in Section 3.6 could be simplified by removing the
distinction between confirmable and non-confirmable notifications, and a
note would be added saying that, due to potential loss of Reset
messages, the client may have to reject multiple notifications until the
server finally removes the entry from the list of observers.

AKBAR - THIS IS A NICE AND SIMPLE IMPROVEMENT, AND I SUPPORT IT.


Requiring the server to remember the message IDs of non-confirmable
notifications needs some discussion, but it's doable as well if there is
enough support in the working group. I guess a constrained server could
always pretend that a Reset message in reply to a non-confirmable
notification was lost. In my CoAP implementation, the server currently
remembers the message ID of a non-confirmable notification until it
starts to transmit the next message to the client. I believe Erbium and
Californium do something similar(?).

AKBAR - CAN WE JUST PUT IT AS AN IMPLEMENTATION NOTE THEN (AS A
SUGGESTION)?


If you're asking for cancellation such that the client can actively
cancel an observation instead of only reactively by rejecting
notifications, then the consensus so far was that reactive/"garbage
collection" approach works well enough. We can certainly revisit that
decision, provided that we can make a final decision soon. We need an
alternative cancellation mechanism for some transports anyway (see, for
example, Section 2.4 of [1]). Note that over UDP this would be in
addition to the current mechanism, not in place of it, so it wouldn't
exactly make the protocol simpler.

AKBAR - THIS WAS MY INITIAL WISH, BUT I DON'T WANT TO FORCE A DISRUPTIVE
CHANGE AT THIS TIME SINCE EVERYONE ELSE SEEMS OKAY WITH THE CURRENT
OPERATION.  IT SHOULD PROBABLY BE SOMETHING WE LOOK BACK AT WHEN WE
CONSIDER THE OTHER TRANSPORTS IN THE FUTURE.  SO LET'S JUST DROP THIS
ONE FOR NOW.


Best regards,
Klaus


[1]
http://tools.ietf.org/html/draft-savolainen-core-coap-websockets-01#sect
ion-2.4

From pab@pabigot.com  Sat Oct 19 05:12:19 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B21BD11E819E for ; Sat, 19 Oct 2013 05:12:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.348
X-Spam-Level: 
X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[AWL=0.251,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5yg6g9KKojT for ; Sat, 19 Oct 2013 05:12:14 -0700 (PDT)
Received: from p3plsmtpa09-04.prod.phx3.secureserver.net (p3plsmtpa09-04.prod.phx3.secureserver.net [173.201.193.233]) by ietfa.amsl.com (Postfix) with ESMTP id D09D111E81A9 for ; Sat, 19 Oct 2013 05:12:11 -0700 (PDT)
Received: from [192.168.65.10] ([66.41.60.82]) by p3plsmtpa09-04.prod.phx3.secureserver.net with  id f0C91m00K1mTNtu010CA8F; Sat, 19 Oct 2013 05:12:11 -0700
Message-ID: <5262771D.2080000@pabigot.com>
Date: Sat, 19 Oct 2013 07:12:13 -0500
From: "Peter A. Bigot" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: core 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [core] fixing block option names
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 19 Oct 2013 12:12:19 -0000

I see block-12 says something about an upcoming "grand rewrite".
Would anybody else support a massive rename, viz:

Block1 -> Request-Block
Block2 -> Response-Block
Size1 -> Request-Size
Size2 -> Response-Size

No semantic change, just eliminate the opacity from the option names so
they more clearly reflect their function.  That request- and
response-related options can both appear in both requests and responses
in both descriptive and control roles adds enough confusion without
compounding it by having to remember "1 is the first message which is a
request and 2 is the second message which is a response".

Peter

From cabo@tzi.org  Sat Oct 19 05:30:04 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD1811E81A6 for ; Sat, 19 Oct 2013 05:30:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.341
X-Spam-Level: 
X-Spam-Status: No, score=-104.341 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2NKUEvwgeYm for ; Sat, 19 Oct 2013 05:29:58 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 29E7F11E813A for ; Sat, 19 Oct 2013 05:29:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9JCTsmj012665; Sat, 19 Oct 2013 14:29:54 +0200 (CEST)
Received: from [172.20.10.5] (ip-2-203-46-172.web.vodafone.de [2.203.46.172]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 846BF3DF; Sat, 19 Oct 2013 14:29:54 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: <5262771D.2080000@pabigot.com>
Date: Sat, 19 Oct 2013 14:29:53 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <8B89DA6E-0993-42CD-905B-2C20303945DC@tzi.org>
References: <5262771D.2080000@pabigot.com>
To: "Peter A. Bigot" 
X-Mailer: Apple Mail (2.1510)
Cc: core 
Subject: Re: [core] fixing block option names
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 19 Oct 2013 12:30:04 -0000

I'm indeed readying block-13, with the changes suggested by Matthias =
Kovatsch, in particular closing #211, #253.
(The major change is that this will get rid of the concept of initiative =
change.)

> Block1 -> Request-Block
> Block2 -> Response-Block
> Size1 -> Request-Size
> Size2 -> Response-Size

We occasionally have discussed this, and it was this discussion that =
arrived at the current names.

I'll follow what the WG wants to do here, but have to point out that the =
name Size1 is already stuck in the approved soon-to-be-RFC*) =
draft-ietf-core-coap.

Gr=FC=DFe, Carsten

*) The two missrefs the RFC editor is waiting for are:
draft-ietf-tls-oob-pubkey (post IETF last call; new version received =
today; IESG State: Waiting for Writeup)
draft-mcgrew-tls-aes-ccm-ecc (post IETF last call; IESG State: IESG =
Evaluation; On agenda of 2013-10-24 IESG telechat)


From tho@koanlogic.com  Sat Oct 19 06:12:51 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 241BB11E81CF for ; Sat, 19 Oct 2013 06:12:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.76
X-Spam-Level: 
X-Spam-Status: No, score=-0.76 tagged_above=-999 required=5 tests=[AWL=-0.309,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_ILLEGAL_IP=1.908,  RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCdcrCE+5VtO for ; Sat, 19 Oct 2013 06:12:45 -0700 (PDT)
Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) by ietfa.amsl.com (Postfix) with ESMTP id 12DF511E81A9 for ; Sat, 19 Oct 2013 06:12:44 -0700 (PDT)
Received: by mail-lb0-f179.google.com with SMTP id p9so3961361lbv.24 for ; Sat, 19 Oct 2013 06:12:43 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=s7yvDgvheIMzy2S+frck2g3r/ldce91eq2vIAbjAdV0=; b=QjCeY0j2I8rHLRmj+li0Bu15W3y8mXttK6R+5NpjcgLJ5V7syc7HMlCmm13yiPZGNG z0SUjfIFncFNwoTI9i2UxRSDXDmcBLsqd4Hm+fWufmCayAviIibwSkolv+kKSAo9KR4z 5ytSKtUTnr7TK+JzosZzSj+ZKvv43eKknn85LHuoKpZ4NNBmaUs4SAst2VDwQT0JNL8N u/QOFbGtzg2QJtt6OSiSjr9j6zl1PR2jXRjKQq8AHqdjZrVzalrUh5W7jvobElwcTpDo DHl5wC4KUsoO4g8O/Lk5KsWAqDvKFvzMjeMqWzb6MUF2KqqYkuNoU3tpeWjH1x/uJQWx 886A==
X-Gm-Message-State: ALoCoQna9TwLJU/FUg8QxiBpnNW84s0YGJgvBJYpehJRIHr7xP9Wowwt9bERAnB49VJD9Hz04Suy
MIME-Version: 1.0
X-Received: by 10.152.171.72 with SMTP id as8mr5225934lac.33.1382188363826; Sat, 19 Oct 2013 06:12:43 -0700 (PDT)
Received: by 10.114.21.4 with HTTP; Sat, 19 Oct 2013 06:12:43 -0700 (PDT)
X-Originating-IP: [2.96.105.112]
In-Reply-To: <5262771D.2080000@pabigot.com>
References: <5262771D.2080000@pabigot.com>
Date: Sat, 19 Oct 2013 14:12:43 +0100
Message-ID: 
From: Thomas Fossati 
To: "Peter A. Bigot" 
Content-Type: text/plain; charset=ISO-8859-1
Cc: core 
Subject: Re: [core] fixing block option names
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 19 Oct 2013 13:12:51 -0000

On Sat, Oct 19, 2013 at 1:12 PM, Peter A. Bigot  wrote:
> I see block-12 says something about an upcoming "grand rewrite".
> Would anybody else support a massive rename, viz:
>
> Block1 -> Request-Block
> Block2 -> Response-Block
> Size1 -> Request-Size
> Size2 -> Response-Size

+1

(missrefs resolution timing permitting)

From pab@pabigot.com  Sat Oct 19 20:13:41 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF4A11E8339 for ; Sat, 19 Oct 2013 20:13:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.373
X-Spam-Level: 
X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=0.226,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jw+WMjLRgsPI for ; Sat, 19 Oct 2013 20:13:35 -0700 (PDT)
Received: from p3plsmtpa09-10.prod.phx3.secureserver.net (p3plsmtpa09-10.prod.phx3.secureserver.net [173.201.193.239]) by ietfa.amsl.com (Postfix) with ESMTP id 5724C11E8143 for ; Sat, 19 Oct 2013 20:13:35 -0700 (PDT)
Received: from [192.168.65.10] ([66.41.60.82]) by p3plsmtpa09-10.prod.phx3.secureserver.net with  id fFDZ1m00F1mTNtu01FDahS; Sat, 19 Oct 2013 20:13:34 -0700
Message-ID: <52634A61.30800@pabigot.com>
Date: Sat, 19 Oct 2013 22:13:37 -0500
From: "Peter A. Bigot" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: core 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [core] block transfer cancellation
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Oct 2013 03:13:41 -0000

If an endpoint involved in a block transfer as sender or receiver needs
to cancel the transmission, how can this be done?

Consider a request with a block-transmitted payload, during transfer of
which the client determines that the request needs to be aborted.  The
server has already received part of the information.  The client can
simply fail to transfer the remainder, but because each message-level
fragment was completed no existing timeouts apply to tell the server to
give up expecting any of the remainder.  When can the server discard
pending material?

 From the other direction, if the sender is using confirmable messages
the recipient may reject one of the blocks.  I can't find text in
block-12 that requires the sender to abort transmission of the remainder
of the blocks.

The same issue exists for responses, assuming server-initiated is not
completely removed as the resolution of #253.  (I found Matthias' recent
comments on this, but no discussion with a clear description of what
will be incorporated into the rewrite).

Note that only for observe notifications is it required that block
transfers be confirmable, so if a receiver rejects a non-confirmable
block fragment there is no obligation for the server to react (following
observe where only rejecting a confirmable notification is guaranteed
to stop future notifications).

Peter

From pab@pabigot.com  Sat Oct 19 20:13:45 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A66D11E833C for ; Sat, 19 Oct 2013 20:13:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.394
X-Spam-Level: 
X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[AWL=0.205,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5rrKxT+7YLf for ; Sat, 19 Oct 2013 20:13:39 -0700 (PDT)
Received: from p3plsmtpa09-06.prod.phx3.secureserver.net (p3plsmtpa09-06.prod.phx3.secureserver.net [173.201.193.235]) by ietfa.amsl.com (Postfix) with ESMTP id 3B35611E8335 for ; Sat, 19 Oct 2013 20:13:36 -0700 (PDT)
Received: from [192.168.65.10] ([66.41.60.82]) by p3plsmtpa09-06.prod.phx3.secureserver.net with  id fFDa1m0031mTNtu01FDa2o; Sat, 19 Oct 2013 20:13:35 -0700
Message-ID: <52634A62.4060805@pabigot.com>
Date: Sat, 19 Oct 2013 22:13:38 -0500
From: "Peter A. Bigot" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: core 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [core] block transfer option interpretation and consistency
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Oct 2013 03:13:45 -0000

When a request or response is fragmented using the block options, how
are other options to be interpreted?

The only discussion I find is with respect to ETag.  The client MUST
detect that the ETag for one block is different from another, and work
to get a complete body constructed from fragments with the same Etag.

What requirements are placed on the presence and value-consistency of
other options?  Does the complete set of options need to be repeated for
each fragment?  2.4 implies this is the case for client-initiated
response collection, but client-initiated requests are not addressed.

What if the value of an option changes over different blocks, as would
happen if a representation with strict tolerances for Max-Age is
transferred in blocks?  From which fragment is the value used to
determine the freshness of the representation taken?

Related to this: block-12 section 2.4 has:

    ...  To minimize the resulting
    inefficiency, the server MAY cache the current value of a
    representation for an ongoing sequence of requests.  (The server may
    identify the sequence by the combination of the requesting end-point
    and the URI being the same in each block-wise request.)

This is the only text that describes how individual fragments are to be
recognized and associated with a specific request or response.  Should
it not also require that the token be the same?

Peter

From trac+core@trac.tools.ietf.org  Sun Oct 20 00:57:51 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3638E11E8364 for ; Sun, 20 Oct 2013 00:57:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.487
X-Spam-Level: 
X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8iaUP+mqYcx for ; Sun, 20 Oct 2013 00:57:50 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id BFFD411E835D for ; Sun, 20 Oct 2013 00:57:48 -0700 (PDT)
Received: from localhost ([127.0.0.1]:53301 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VXntI-0005ib-O1; Sun, 20 Oct 2013 09:57:36 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "core issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-core-block@tools.ietf.org, hartke@tzi.org, cabo@tzi.org
X-Trac-Project: core
Date: Sun, 20 Oct 2013 07:57:36 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/211#comment:2
Message-ID: <066.29944fbe1d4be5701f86027ac41b8bdd@trac.tools.ietf.org>
References: <051.1e6287ce725552ffe1353c663f4c2d17@trac.tools.ietf.org>
X-Trac-Ticket-ID: 211
In-Reply-To: <051.1e6287ce725552ffe1353c663f4c2d17@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-core-block@tools.ietf.org, hartke@tzi.org, cabo@tzi.org, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: cabo@tzi.org, zach@sensinode.com
Resent-Message-Id: <20131020075749.BFFD411E835D@ietfa.amsl.com>
Resent-Date: Sun, 20 Oct 2013 00:57:48 -0700 (PDT)
Resent-From: trac+core@trac.tools.ietf.org
Cc: core@ietf.org
Subject: Re: [core] #211: Signal provisional responses (atomic Block1) in the response code
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: trac+core@trac.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Oct 2013 07:57:51 -0000

#211: Signal provisional responses (atomic Block1) in the response code


Comment (by cabo@tzi.org):

 Fixed in -13 by introducing "2.31 Continue".
 Question 2 has been solved by keeping the M bit in its previous role, it
 is therefore now a redundant expression of 2.31.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-
  cabo@tzi.org           |  block@tools.ietf.org
     Type:  protocol     |      Status:  new
  defect                 |   Milestone:  post-WGLC-1
 Priority:  major        |     Version:  block-08
Component:  block        |  Resolution:
 Severity:  In WG Last   |
  Call                   |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
core 


From trac+core@trac.tools.ietf.org  Sun Oct 20 01:03:57 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D736D11E8360 for ; Sun, 20 Oct 2013 01:03:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.495
X-Spam-Level: 
X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofDx1MRiF3hy for ; Sun, 20 Oct 2013 01:03:57 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 4175511E8186 for ; Sun, 20 Oct 2013 01:03:57 -0700 (PDT)
Received: from localhost ([127.0.0.1]:53704 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VXnzO-0001W0-K6; Sun, 20 Oct 2013 10:03:54 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "core issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-core-block@tools.ietf.org, cabo@tzi.org
X-Trac-Project: core
Date: Sun, 20 Oct 2013 08:03:54 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/253#comment:1
Message-ID: <066.1b3055856ee057e4167d170a8df8ecd4@trac.tools.ietf.org>
References: <051.6211cf307a6c1c0ca7695e53d5349711@trac.tools.ietf.org>
X-Trac-Ticket-ID: 253
In-Reply-To: <051.6211cf307a6c1c0ca7695e53d5349711@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-core-block@tools.ietf.org, cabo@tzi.org, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: cabo@tzi.org, zach@sensinode.com
Resent-Message-Id: <20131020080357.4175511E8186@ietfa.amsl.com>
Resent-Date: Sun, 20 Oct 2013 01:03:57 -0700 (PDT)
Resent-From: trac+core@trac.tools.ietf.org
Cc: core@ietf.org
Subject: Re: [core] #253: Block2 vs. Initiative (Don't call us, we'll call you)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: trac+core@trac.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Oct 2013 08:03:58 -0000

#253: Block2 vs. Initiative (Don't call us, we'll call you)


Comment (by cabo@tzi.org):

 Covered in -13 by removing the concept of initiative.
 Observe now only notifies the first block (the client has to pick up the
 rest independently and correlate using the ETag), and in a Block1
 transfer, the client uses requests with Block2 and non-zero NUM to gather
 the rest of the response.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-
  cabo@tzi.org           |  block@tools.ietf.org
     Type:  protocol     |      Status:  new
  enhancement            |   Milestone:  post-WGLC-1
 Priority:  major        |     Version:  block-10
Component:  block        |  Resolution:
 Severity:  Active WG    |
  Document               |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
core 


From trac+core@trac.tools.ietf.org  Sun Oct 20 01:20:33 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66A8D11E8192 for ; Sun, 20 Oct 2013 01:20:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.502
X-Spam-Level: 
X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SgjKtNmkYnR for ; Sun, 20 Oct 2013 01:20:31 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id C639311E8374 for ; Sun, 20 Oct 2013 01:20:26 -0700 (PDT)
Received: from localhost ([127.0.0.1]:54940 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VXoFL-0001Yn-1t; Sun, 20 Oct 2013 10:20:23 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "core issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-core-block@tools.ietf.org, cabo@tzi.org
X-Trac-Project: core
Date: Sun, 20 Oct 2013 08:20:23 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/335#comment:1
Message-ID: <075.5866816ae6ea7163e90ad3f04feeafe2@trac.tools.ietf.org>
References: <060.a89fd11f3a5fe25a8ffdd6322c4b34c4@trac.tools.ietf.org>
X-Trac-Ticket-ID: 335
In-Reply-To: <060.a89fd11f3a5fe25a8ffdd6322c4b34c4@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-core-block@tools.ietf.org, cabo@tzi.org, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: cabo@tzi.org, zach@sensinode.com
Resent-Message-Id: <20131020082026.C639311E8374@ietfa.amsl.com>
Resent-Date: Sun, 20 Oct 2013 01:20:26 -0700 (PDT)
Resent-From: trac+core@trac.tools.ietf.org
Cc: core@ietf.org
Subject: Re: [core] #335: multicast usage of core-block to be specified
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: trac+core@trac.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Oct 2013 08:20:33 -0000

#335: multicast usage of core-block to be specified

Changes (by cabo@tzi.org):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Addressed in -13 by new section 2.8.
 We only discuss Block2(NUM = 0) for GET.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-
  esko.dijk@philips.com  |  block@tools.ietf.org
     Type:  protocol     |      Status:  closed
  enhancement            |   Milestone:
 Priority:  major        |     Version:
Component:  block        |  Resolution:  fixed
 Severity:  -            |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
core 


From trac+core@trac.tools.ietf.org  Sun Oct 20 01:21:37 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 709CE11E8371 for ; Sun, 20 Oct 2013 01:21:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.508
X-Spam-Level: 
X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vy8AYmLph8U for ; Sun, 20 Oct 2013 01:21:36 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 77CE911E8370 for ; Sun, 20 Oct 2013 01:21:36 -0700 (PDT)
Received: from localhost ([127.0.0.1]:54987 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VXoGO-0000Ty-5a; Sun, 20 Oct 2013 10:21:28 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "core issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-core-block@tools.ietf.org, hartke@tzi.org, cabo@tzi.org
X-Trac-Project: core
Date: Sun, 20 Oct 2013 08:21:28 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/211#comment:3
Message-ID: <066.c6fc0732420d2c14f58131ede9e1d867@trac.tools.ietf.org>
References: <051.1e6287ce725552ffe1353c663f4c2d17@trac.tools.ietf.org>
X-Trac-Ticket-ID: 211
In-Reply-To: <051.1e6287ce725552ffe1353c663f4c2d17@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-core-block@tools.ietf.org, hartke@tzi.org, cabo@tzi.org, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: cabo@tzi.org, zach@sensinode.com
Resent-Message-Id: <20131020082136.77CE911E8370@ietfa.amsl.com>
Resent-Date: Sun, 20 Oct 2013 01:21:36 -0700 (PDT)
Resent-From: trac+core@trac.tools.ietf.org
Cc: core@ietf.org
Subject: Re: [core] #211: Signal provisional responses (atomic Block1) in the response code
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: trac+core@trac.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Oct 2013 08:21:37 -0000

#211: Signal provisional responses (atomic Block1) in the response code

Changes (by cabo@tzi.org):

 * status:  new => closed
 * resolution:   => fixed


-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-
  cabo@tzi.org           |  block@tools.ietf.org
     Type:  protocol     |      Status:  closed
  defect                 |   Milestone:  post-WGLC-1
 Priority:  major        |     Version:  block-08
Component:  block        |  Resolution:  fixed
 Severity:  In WG Last   |
  Call                   |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
core 


From trac+core@trac.tools.ietf.org  Sun Oct 20 01:21:48 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0875A11E8376 for ; Sun, 20 Oct 2013 01:21:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.514
X-Spam-Level: 
X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fpJm6-z2B7b for ; Sun, 20 Oct 2013 01:21:46 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id BFCB611E8378 for ; Sun, 20 Oct 2013 01:21:41 -0700 (PDT)
Received: from localhost ([127.0.0.1]:54992 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VXoGa-0005AJ-Pe; Sun, 20 Oct 2013 10:21:40 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "core issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-core-block@tools.ietf.org, cabo@tzi.org
X-Trac-Project: core
Date: Sun, 20 Oct 2013 08:21:40 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/253#comment:2
Message-ID: <066.fa3c573b3236fb053f49b4accf9d9721@trac.tools.ietf.org>
References: <051.6211cf307a6c1c0ca7695e53d5349711@trac.tools.ietf.org>
X-Trac-Ticket-ID: 253
In-Reply-To: <051.6211cf307a6c1c0ca7695e53d5349711@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-core-block@tools.ietf.org, cabo@tzi.org, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: cabo@tzi.org, zach@sensinode.com
Resent-Message-Id: <20131020082141.BFCB611E8378@ietfa.amsl.com>
Resent-Date: Sun, 20 Oct 2013 01:21:41 -0700 (PDT)
Resent-From: trac+core@trac.tools.ietf.org
Cc: core@ietf.org
Subject: Re: [core] #253: Block2 vs. Initiative (Don't call us, we'll call you)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: trac+core@trac.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Oct 2013 08:21:48 -0000

#253: Block2 vs. Initiative (Don't call us, we'll call you)

Changes (by cabo@tzi.org):

 * status:  new => closed
 * resolution:   => fixed


-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-
  cabo@tzi.org           |  block@tools.ietf.org
     Type:  protocol     |      Status:  closed
  enhancement            |   Milestone:  post-WGLC-1
 Priority:  major        |     Version:  block-10
Component:  block        |  Resolution:  fixed
 Severity:  Active WG    |
  Document               |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
core 


From trac+core@trac.tools.ietf.org  Sun Oct 20 01:37:12 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D866111E8190 for ; Sun, 20 Oct 2013 01:37:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.518
X-Spam-Level: 
X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROO9vrz6DQoK for ; Sun, 20 Oct 2013 01:37:11 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 4171C11E8379 for ; Sun, 20 Oct 2013 01:37:07 -0700 (PDT)
Received: from localhost ([127.0.0.1]:56427 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VXoVV-0007tG-MZ; Sun, 20 Oct 2013 10:37:05 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "core issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-core-block@tools.ietf.org, cabo@tzi.org
X-Trac-Project: core
Date: Sun, 20 Oct 2013 08:37:05 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/334#comment:1
Message-ID: <074.4bab3436df1a0a4b083c0447d48f4387@trac.tools.ietf.org>
References: <059.81d71d56fda0c3256a7adc71ea711349@trac.tools.ietf.org>
X-Trac-Ticket-ID: 334
In-Reply-To: <059.81d71d56fda0c3256a7adc71ea711349@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-core-block@tools.ietf.org, cabo@tzi.org, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: cabo@tzi.org, zach@sensinode.com
Resent-Message-Id: <20131020083708.4171C11E8379@ietfa.amsl.com>
Resent-Date: Sun, 20 Oct 2013 01:37:07 -0700 (PDT)
Resent-From: trac+core@trac.tools.ietf.org
Cc: core@ietf.org
Subject: Re: [core] #334: MUST for in-order block transfer
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: trac+core@trac.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Oct 2013 08:37:13 -0000

#334: MUST for in-order block transfer

Changes (by cabo@tzi.org):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Covered in -13: Clarify that a server can send 4.08 for out-of-order
 request blocks, and admonish clients that don't want that to happen to
 send blocks in order.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-
  kovatsch@inf.ethz.ch   |  block@tools.ietf.org
     Type:  protocol     |      Status:  closed
  enhancement            |   Milestone:  post-WGLC-1
 Priority:  major        |     Version:
Component:  block        |  Resolution:  fixed
 Severity:  In WG Last   |
  Call                   |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
core 


From internet-drafts@ietf.org  Sun Oct 20 01:54:34 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3055411E8385; Sun, 20 Oct 2013 01:54:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.561
X-Spam-Level: 
X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7pbWMLm-bcZ; Sun, 20 Oct 2013 01:54:33 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B653D11E837B; Sun, 20 Oct 2013 01:54:33 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.80.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131020085433.22779.77044.idtracker@ietfa.amsl.com>
Date: Sun, 20 Oct 2013 01:54:33 -0700
Cc: core@ietf.org
Subject: [core] I-D Action: draft-ietf-core-block-13.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Oct 2013 08:54:34 -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           : Blockwise transfers in CoAP
	Author(s)       : Carsten Bormann
                          Zach Shelby
	Filename        : draft-ietf-core-block-13.txt
	Pages           : 28
	Date            : 2013-10-20

Abstract:
   CoAP is a RESTful transfer protocol for constrained nodes and
   networks.  Basic CoAP messages work well for the small payloads we
   expect from temperature sensors, light switches, and similar
   building-automation devices.  Occasionally, however, applications
   will need to transfer larger payloads -- for instance, for
   firmware updates.  With HTTP, TCP does the grunt work of slicing
   large payloads up into multiple packets and ensuring that they all
   arrive and are handled in the right order.

   CoAP is based on datagram transports such as UDP or DTLS, which
   limits the maximum size of resource representations that can be
   transferred without too much fragmentation.  Although UDP supports
   larger payloads through IP fragmentation, it is limited to 64 KiB
   and, more importantly, doesn't really work well for constrained
   applications and networks.

   Instead of relying on IP fragmentation, this specification extends
   basic CoAP with a pair of "Block" options, for transferring multiple
   blocks of information from a resource representation in multiple
   request-response pairs.  In many important cases, the Block options
   enable a server to be truly stateless: the server can handle each
   block transfer separately, with no need for a connection setup or
   other server-side memory of previous block transfers.

   In summary, the Block options provide a minimal way to transfer
   larger representations in a block-wise fashion.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-core-block

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-core-block-13

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-block-13


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From cabo@tzi.org  Sun Oct 20 01:55:30 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE8921F9F20 for ; Sun, 20 Oct 2013 01:55:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Level: 
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzKTDw4l6Yav for ; Sun, 20 Oct 2013 01:55:24 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 0B15C11E8270 for ; Sun, 20 Oct 2013 01:55:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9K8tBgt006842; Sun, 20 Oct 2013 10:55:11 +0200 (CEST)
Received: from [172.20.10.8] (ip-109-47-150-194.web.vodafone.de [109.47.150.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id F1E4850F; Sun, 20 Oct 2013 10:55:10 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: <52634A61.30800@pabigot.com>
Date: Sun, 20 Oct 2013 10:55:09 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <1F85B516-38AD-4268-86AC-4A51DB613B8E@tzi.org>
References: <52634A61.30800@pabigot.com>
To: "Peter A. Bigot" 
X-Mailer: Apple Mail (2.1510)
Cc: core 
Subject: [core] block-13 (Re:  block transfer cancellation)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Oct 2013 08:55:30 -0000

On Oct 20, 2013, at 05:13, "Peter A. Bigot"  wrote:

> (I found Matthias' recent
> comments on this, but no discussion with a clear description of what
> will be incorporated into the rewrite).

Indeed, this is difficult to discuss further without text to look at.
I have submitted -13 so we have a common reference of how these comments =
will be resolved.

Gr=FC=DFe, Carsten


From pab@pabigot.com  Sun Oct 20 10:44:41 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B87DF11E822D for ; Sun, 20 Oct 2013 10:44:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.411
X-Spam-Level: 
X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.188,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwFnd--bxXVU for ; Sun, 20 Oct 2013 10:44:33 -0700 (PDT)
Received: from p3plsmtpa09-07.prod.phx3.secureserver.net (p3plsmtpa09-07.prod.phx3.secureserver.net [173.201.193.236]) by ietfa.amsl.com (Postfix) with ESMTP id 57EAE11E8228 for ; Sun, 20 Oct 2013 10:44:32 -0700 (PDT)
Received: from [192.168.65.10] ([66.41.60.82]) by p3plsmtpa09-07.prod.phx3.secureserver.net with  id fVkV1m0071mTNtu01VkVNo; Sun, 20 Oct 2013 10:44:31 -0700
Message-ID: <52641681.80706@pabigot.com>
Date: Sun, 20 Oct 2013 12:44:33 -0500
From: "Peter A. Bigot" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Carsten Bormann 
References: <52634A61.30800@pabigot.com> <1F85B516-38AD-4268-86AC-4A51DB613B8E@tzi.org>
In-Reply-To: <1F85B516-38AD-4268-86AC-4A51DB613B8E@tzi.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: core 
Subject: Re: [core] block-13 (Re:  block transfer cancellation)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Oct 2013 17:44:41 -0000

On 10/20/2013 03:55 AM, Carsten Bormann wrote:
> On Oct 20, 2013, at 05:13, "Peter A. Bigot"  wrote:
>
>> (I found Matthias' recent
>> comments on this, but no discussion with a clear description of what
>> will be incorporated into the rewrite).
>
> Indeed, this is difficult to discuss further without text to look at.
> I have submitted -13 so we have a common reference of how these comments will be resolved.

Thanks; this does appear to remove server initiated transfers, so part
of one of my questions is moot, but the bulk of the issues I raised are
still open for discussion.

Specific comments:

block-13 section 2.5 has:

    ...  (Note that a 4.13 response to a
    request that does not employ Block1 is a hint for the client to try
    sending Block1, and a 4.13 response with a smaller SZX in its Block1
    option than requested is a hint to try a smaller SZX.)

This implies Block1 may appear in a 4.13 response, which I don't think
is the intent.  I think it's meant to be more like:

    ...  (Note that a 4.13 response to a
    request that does not employ Block1 is a hint for the client to try
    sending Block1.  As described in [I-D.ietf-core-coap] the 4.13
    response SHOULD include a Size1 option to help the client select
    an acceptable SZX for the Block1 option.)

Two issues with 2.7 which has:

    continues to send requests similar to the requests in the Block1
    phase, bute leaves out the Block1 options and includes a Block2
    request option with non-zero NUM.

s/bute/but/

    Block2 transfers that retrieve the response body for a request that
    used Block1 MUST be performed in sequential order.

Why is this requirement restricted to responses where the request used
Block1?  Is it reasonable to allow non-sequential order if the request
did not carry a large representation, but the response does?  Perhaps:

    Block2 transfers that retrieve the response body MUST be performed
    in sequential order.

and move it to the discussion of Block2 rather than the section that
discusses combining Block1 with Block2.

Or, if the intent is to allow non-sequential order, is the server
required to support such requests, or does it need a 4.09 Response
Entity Incomplete to tell the client it insists on in-order transfer?
(I'm thinking here of a case where it's easy to incrementally produce
the response representation, but expensive to randomly access pieces of
it, e.g. if it's compressed or encrypted.)

A general comment:

As discussed in an earlier email, [I-D.ietf-core-coap] generically
imposes strict requirements on which options may appear in which
requests and responses, though it does not rigorously define the
specifics.  block-13 appears to define two new response codes: 2.31
(Continue) and 4.08 (Request Entity Incomplete).  The introduction of
these new codes is deep within 2.5 "Using the Block1 Option", and their
introduction is not apparent from the table of contents.

It would be helpful to future readers of CoAP extension RFCs if each new
option, request method, and response code was documented in a subsection
of its own, paralleling the structure of [I-D.ietf-core-coap], and
providing complete information regarding appearance in requests and
responses, repeatability, etc.  This should be done so that the
introduction of these new options/codes is visible in the index, and so
an implementer can locate the relevant information without having to do
a text search through the document.  Something like:

2. Options
2.1. Block1
2.2. Block2
2.3. Size1
2.4. Size2
2.5 ... interactions
3. Response Code Definitions
3.1. 2.31 Continue
3.2. 4.08 Request Entity Incomplete

I understand this would require some significant document restructuring
so it may be too late for block.

Peter

From cabo@tzi.org  Sun Oct 20 15:23:01 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 299E411E82A2 for ; Sun, 20 Oct 2013 15:23:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.199
X-Spam-Level: 
X-Spam-Status: No, score=-106.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLDxXmcUheax for ; Sun, 20 Oct 2013 15:22:55 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 2C50311E82B0 for ; Sun, 20 Oct 2013 15:22:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9KMMo34027974; Mon, 21 Oct 2013 00:22:50 +0200 (CEST)
Received: from [192.168.217.105] (p548907BF.dip0.t-ipconnect.de [84.137.7.191]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4B2FE6C2; Mon, 21 Oct 2013 00:22:50 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: <52641681.80706@pabigot.com>
Date: Mon, 21 Oct 2013 00:22:48 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <35BF58AA-DA40-4A7F-89FC-C32101AF6F76@tzi.org>
References: <52634A61.30800@pabigot.com> <1F85B516-38AD-4268-86AC-4A51DB613B8E@tzi.org> <52641681.80706@pabigot.com>
To: "Peter A. Bigot" 
X-Mailer: Apple Mail (2.1510)
Cc: core 
Subject: Re: [core] block-13 (Re:  block transfer cancellation)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Oct 2013 22:23:01 -0000

Hi Peter,

thanks for the quick review of -13.

> block-13 section 2.5 has:
>=20
>   ...  (Note that a 4.13 response to a
>   request that does not employ Block1 is a hint for the client to try
>   sending Block1, and a 4.13 response with a smaller SZX in its Block1
>   option than requested is a hint to try a smaller SZX.)
>=20
> This implies Block1 may appear in a 4.13 response, which I don't think
> is the intent. =20

That actually *is* the intent ("control usage").
(This is about SZX, not total size of the request body, which would be =
indicated in the Size1 option.)

(Thanks for the editorial fix.)

>   Block2 transfers that retrieve the response body for a request that
>   used Block1 MUST be performed in sequential order.
>=20
> Why is this requirement restricted to responses where the request used
> Block1?  Is it reasonable to allow non-sequential order if the request
> did not carry a large representation, but the response does?  Perhaps:
>=20
>   Block2 transfers that retrieve the response body MUST be performed
>   in sequential order.

All Block2 transfers retrieve the response body.
There are good reasons to leave out the MUST for Block2/GET.
I do think it is appropriate to extend the MUST for Block2/all requests =
that involve request bodies.

> Or, if the intent is to allow non-sequential order, is the server
> required to support such requests, or does it need a 4.09 Response
> Entity Incomplete to tell the client it insists on in-order transfer?
> (I'm thinking here of a case where it's easy to incrementally produce
> the response representation, but expensive to randomly access pieces =
of
> it, e.g. if it's compressed or encrypted.)

Good point; we don't have a defined error code for that yet.
While the server can always send a 4.00, something more specific would =
be useful.
(Similarly, we don't have a good way to indicate that the client's block =
number has overshot the size of the representation.
This can happen even with sequential access in case of dynamically =
changing representations.)

We need to work on the Block2 error codes.

> A general comment:
>=20
> As discussed in an earlier email, [I-D.ietf-core-coap] generically
> imposes strict requirements on which options may appear in which
> requests and responses, though it does not rigorously define the
> specifics.  block-13 appears to define two new response codes: 2.31
> (Continue) and 4.08 (Request Entity Incomplete). =20

Yes, that list is in section 6.  See below.

> The introduction of
> these new codes is deep within 2.5 "Using the Block1 Option", and =
their
> introduction is not apparent from the table of contents.
>=20
> It would be helpful to future readers of CoAP extension RFCs if each =
new
> option, request method, and response code was documented in a =
subsection
> of its own, paralleling the structure of [I-D.ietf-core-coap], and
> providing complete information regarding appearance in requests and
> responses, repeatability, etc.  This should be done so that the
> introduction of these new options/codes is visible in the index, and =
so
> an implementer can locate the relevant information without having to =
do
> a text search through the document.  Something like:
>=20
> 2. Options
> 2.1. Block1
> 2.2. Block2
> 2.3. Size1
> 2.4. Size2
> 2.5 ... interactions
> 3. Response Code Definitions
> 3.1. 2.31 Continue
> 3.2. 4.08 Request Entity Incomplete

That doesn't work very well, because you can't define the meaning of the =
options without mentioning response codes.

I don't mind restructuring the text at all (even though I'm not sure =
after the recent simplifications that we still need the "grand rewrite") =
but it should not make the text harder to read for the sole purpose of =
making the table of contents more immediately accessible -- most people =
do know how to search in documents at this point.

But I do like the idea of giving the response codes a subsection of =
their own.
Also, we can make the table of contents more directly useful:

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Block-wise transfers  . . . . . . . . . . . . . . . . . . . .   4
     2.1.  The Block2 and Block1 Options . . . . . . . . . . . . . .   5
     2.2.  Structure of a Block Option . . . . . . . . . . . . . . .   6
     2.3.  Block Options in Requests and Responses . . . . . . . . .   8
     2.4.  Using the Block2 Option . . . . . . . . . . . . . . . . .   9
     2.5.  Using the Block1 Option . . . . . . . . . . . . . . . . .  11
     2.6.  Combining Blockwise Transfers with the Observe Option . .  12
     2.7.  Combining Block1 and Block2 . . . . . . . . . . . . . . .  13
     2.8.  Combining Block2 with Multicast . . . . . . . . . . . . .  13
     2.9.  Additional Response Codes . . . . . . . . . . . . . . . .  13
       2.9.1.  2.31 Continue . . . . . . . . . . . . . . . . . . . .  13
       2.9.2.  4.08 Request Entity Incomplete  . . . . . . . . . . .  13
   3.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  14
     3.1.  Block2 Examples . . . . . . . . . . . . . . . . . . . . .  14
     3.2.  Block1 Examples . . . . . . . . . . . . . . . . . . . . .  17
     3.3.  Combining Block1 and Block2 . . . . . . . . . . . . . . .  19
     3.4.  Combining Observe and Block2  . . . . . . . . . . . . . .  20
   4.  The Size2 and Size1 Options . . . . . . . . . . . . . . . . .  23
   5.  HTTP Mapping Considerations . . . . . . . . . . . . . . . . .  24
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  26
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  27
     7.1.  Mitigating Resource Exhaustion Attacks  . . . . . . . . .  27
     7.2.  Mitigating Amplification Attacks  . . . . . . . . . . . .  28
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  28
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  29
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  29
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  29
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  29

I propose adding a section 2.9 that reads like this:

2.9.  Additional Response Codes

   Two response codes are defined by this specification beyond those
   already defined in [I-D.ietf-core-coap].

2.9.1.  2.31 Continue

   This success status code indicates that the transfer of this block of
   the request body was successful and that the serve encourages sending
   further blocks, but that a final outcome of the whole block-wise
   request cannot yet be determined.  No payload is returned with this
   response code.

2.9.2.  4.08 Request Entity Incomplete

   This client error status code indicates that the server has not
   received the blocks of the request body that it needs to proceed.
   The client has not sent all blocks, not sent them in the order
   required by the server, or has sent them long enough ago that the
   server has already discarded them.


Gr=FC=DFe, Carsten


From pab@pabigot.com  Sun Oct 20 19:27:30 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9A8111E845A for ; Sun, 20 Oct 2013 19:27:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.425
X-Spam-Level: 
X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.174,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCnSUUagflvm for ; Sun, 20 Oct 2013 19:27:24 -0700 (PDT)
Received: from p3plsmtpa09-02.prod.phx3.secureserver.net (p3plsmtpa09-02.prod.phx3.secureserver.net [173.201.193.231]) by ietfa.amsl.com (Postfix) with ESMTP id BBC5F11E8102 for ; Sun, 20 Oct 2013 19:27:24 -0700 (PDT)
Received: from [192.168.65.10] ([66.41.60.82]) by p3plsmtpa09-02.prod.phx3.secureserver.net with  id feTL1m0051mTNtu01eTMAL; Sun, 20 Oct 2013 19:27:24 -0700
Message-ID: <5264910D.8000500@pabigot.com>
Date: Sun, 20 Oct 2013 21:27:25 -0500
From: "Peter A. Bigot" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Carsten Bormann 
References: <52634A61.30800@pabigot.com> <1F85B516-38AD-4268-86AC-4A51DB613B8E@tzi.org> <52641681.80706@pabigot.com> <35BF58AA-DA40-4A7F-89FC-C32101AF6F76@tzi.org>
In-Reply-To: <35BF58AA-DA40-4A7F-89FC-C32101AF6F76@tzi.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: core 
Subject: Re: [core] block-13 (Re:  block transfer cancellation)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 02:27:30 -0000

On 10/20/2013 05:22 PM, Carsten Bormann wrote:
>> block-13 section 2.5 has:
>>
>>   ...  (Note that a 4.13 response to a
>>   request that does not employ Block1 is a hint for the client to try
>>   sending Block1, and a 4.13 response with a smaller SZX in its Block1
>>   option than requested is a hint to try a smaller SZX.)
>>
>> This implies Block1 may appear in a 4.13 response, which I don't think
>> is the intent.
>
> That actually *is* the intent ("control usage").
> (This is about SZX, not total size of the request body, which would be indicated in the Size1 option.)

That makes sense.  I'm still hung up by the very clear requirements in 
coap-18 section 5.4 that options not explicitly defined for response 
codes are disallowed.

So this means Block1 is defined for 4.13 as a mechanism to convey to the 
client the (maximum?) SZX value the server would accept in another 
request.  And that only the SZX portion of the option value is defined 
and the M and NUM fields should be zero, perhaps.

>
> (Thanks for the editorial fix.)
>
>>   Block2 transfers that retrieve the response body for a request that
>>   used Block1 MUST be performed in sequential order.
>>
>> Why is this requirement restricted to responses where the request used
>> Block1?  Is it reasonable to allow non-sequential order if the request
>> did not carry a large representation, but the response does?  Perhaps:
>>
>>   Block2 transfers that retrieve the response body MUST be performed
>>   in sequential order.
>
> All Block2 transfers retrieve the response body.

Indeed; again Response-Block as the option name might reduce confusion.

> There are good reasons to leave out the MUST for Block2/GET.

An informational note explaining what those might be would be helpful, 
e.g. if the intent is to allow access to subresource content (not just 
out-of-order, but selective retrieval).  It should also make clear 
whether the recipient is required to support this practice, and if it 
does not how it informs the sender.

> I do think it is appropriate to extend the MUST for Block2/all requests that involve request bodies.

I don't understand this statement unless you mean the text as written is 
what you intended.  It would be worth documenting why this is an 
appropriate restriction that is not appropriate when request bodies 
aren't transferred in blocks.

In general one thing that frequently throws me in these documents is 
where a MUST/SHOULD statement is made for a special case but the 
expected or permitted behavior in the general case, or parallel special 
cases, lacks similar clarity.  A clear general rule of "Block transfers 
MUST be made in sequential order" or "Block transfers MAY be made in 
arbitrary and incomplete order" (whichever it is), applying to both 
Block1 and Block2, would be helpful.  Then follow that with deviations 
from the special rule (perhaps noting explicitly what they deviate from 
and the reasoning that supports the deviation).

> We need to work on the Block2 error codes.

I hope they could be rolled up into one or two 4.xx codes, e.g. 4.08 
Block Violation with a diagnostic payload as explanation.  There are 
only 32 codes possible and spending more than one or two on diagnostics 
on any particular feature is going to use them up quickly.

Just throwing this out: maybe an error code "Option Use Violation". 
Could support a payload holding the encoded option(s) that were not 
acceptable, though this would have to have a content format and 
therefore could not be a diagnostic payload.  The bad options could be 
transferred in an opaque BadOption option instead but that's getting 
pretty meta.

> But I do like the idea of giving the response codes a subsection of their own.
> Also, we can make the table of contents more directly useful:
>
>     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
>     2.  Block-wise transfers  . . . . . . . . . . . . . . . . . . . .   4
>       2.1.  The Block2 and Block1 Options . . . . . . . . . . . . . .   5
>       2.2.  Structure of a Block Option . . . . . . . . . . . . . . .   6
>       2.3.  Block Options in Requests and Responses . . . . . . . . .   8
>       2.4.  Using the Block2 Option . . . . . . . . . . . . . . . . .   9
>       2.5.  Using the Block1 Option . . . . . . . . . . . . . . . . .  11
>       2.6.  Combining Blockwise Transfers with the Observe Option . .  12
>       2.7.  Combining Block1 and Block2 . . . . . . . . . . . . . . .  13
>       2.8.  Combining Block2 with Multicast . . . . . . . . . . . . .  13
>       2.9.  Additional Response Codes . . . . . . . . . . . . . . . .  13
>         2.9.1.  2.31 Continue . . . . . . . . . . . . . . . . . . . .  13
>         2.9.2.  4.08 Request Entity Incomplete  . . . . . . . . . . .  13
>     3.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  14
>       3.1.  Block2 Examples . . . . . . . . . . . . . . . . . . . . .  14
>       3.2.  Block1 Examples . . . . . . . . . . . . . . . . . . . . .  17
>       3.3.  Combining Block1 and Block2 . . . . . . . . . . . . . . .  19
>       3.4.  Combining Observe and Block2  . . . . . . . . . . . . . .  20
>     4.  The Size2 and Size1 Options . . . . . . . . . . . . . . . . .  23
>     5.  HTTP Mapping Considerations . . . . . . . . . . . . . . . . .  24
>     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  26
>     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  27
>       7.1.  Mitigating Resource Exhaustion Attacks  . . . . . . . . .  27
>       7.2.  Mitigating Amplification Attacks  . . . . . . . . . . . .  28
>     8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  28
>     9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  29
>       9.1.  Normative References  . . . . . . . . . . . . . . . . . .  29
>       9.2.  Informative References  . . . . . . . . . . . . . . . . .  29
>     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  29

This would go a long way to making things easier for the way I use IETF 
documents, which is to navigate to the RFC's HTML tools page and follow 
links from the index to the details of what I'm trying to clarify.  I 
also like to have links to the standard definition in API documentation, 
which also works if there's an index entry.

>
> I propose adding a section 2.9 that reads like this:
>
> 2.9.  Additional Response Codes
>
>     Two response codes are defined by this specification beyond those
>     already defined in [I-D.ietf-core-coap].
>
> 2.9.1.  2.31 Continue
>
>     This success status code indicates that the transfer of this block of
>     the request body was successful and that the serve encourages sending
>     further blocks, but that a final outcome of the whole block-wise
>     request cannot yet be determined.  No payload is returned with this
>     response code.
>
> 2.9.2.  4.08 Request Entity Incomplete
>
>     This client error status code indicates that the server has not
>     received the blocks of the request body that it needs to proceed.
>     The client has not sent all blocks, not sent them in the order
>     required by the server, or has sent them long enough ago that the
>     server has already discarded them.

Ignoring whether 4.08 should be generalized to cover other block 
protocol violations, I like this.  Per coap-18 section 5.4 I'd like it 
even more if 2.9.1 and 2.9.2 were explicit about which of Size1, Size2, 
Block1, and Block2 are defined for each response.  (I believe the 
proposed text is adequately explicit for coap-18's requirement in 
section 5.5 about whether payloads are permitted, since 4.xx has a 
general rule allowing diagnostic payloads.)

Peter

From zach@sensinode.com  Sun Oct 20 20:12:08 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA1D11E846C for ; Sun, 20 Oct 2013 20:12:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDQX9JUaPpWj for ; Sun, 20 Oct 2013 20:12:04 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 5E84011E8329 for ; Sun, 20 Oct 2013 20:12:03 -0700 (PDT)
Received: from [10.0.0.4] (c-50-131-146-123.hsd1.ca.comcast.net [50.131.146.123]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r9L3Bt34002180 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 21 Oct 2013 06:11:58 +0300
X-Authenticated-User: sensinodecom
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Zach Shelby 
In-Reply-To: <525ED2DE.5050600@pabigot.com>
Date: Fri, 18 Oct 2013 14:41:37 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <525ED2DE.5050600@pabigot.com>
To: "Peter A. Bigot" 
X-Mailer: Apple Mail (2.1510)
Cc: core 
Subject: Re: [core] WGLC observe comment: notification supersedure
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 03:12:08 -0000

Peter,

I think you're making a completely reasonable suggestion here. +1.

Zach

On Oct 16, 2013, at 10:54 AM, Peter A. Bigot  wrote:

> To fix this I propose: Change step 3 in section 4.5 to something like:
>=20
>   3.  If the entry is still in the list of observers, the server MAY
>       replace the message with a new notification with a =
representation
>       of the current resource state.  Should the resource have changed
>       its state more than once in the meantime, the notifications for
>       the intermediate states are silently skipped.
>=20
> This does not obligate the implementation to support message
> supersedure, as the current text does even if updates have no "strict =
tolerance" for timeliness for a particular resource.
>=20
> It keeps the expectation that if a client fails to acknowledge a =
confirmable notification after BEBO completes all transmissions the =
client is removed from the list of observers.
>=20
> And it allows the supersedure if the implementation chooses to support =
it.
>=20
> Everybody wins?

--=20
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com @SensinodeIoT
Mobile: +358 40 7796297
Twitter: @zach_shelby
LinkedIn: http://fi.linkedin.com/in/zachshelby
6LoWPAN Book: http://6lowpan.net





From trac+core@trac.tools.ietf.org  Sun Oct 20 23:24:35 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAFE311E84BA for ; Sun, 20 Oct 2013 23:24:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.523
X-Spam-Level: 
X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJ8QL25UQdOc for ; Sun, 20 Oct 2013 23:24:34 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id B652321F9C6C for ; Sun, 20 Oct 2013 23:24:30 -0700 (PDT)
Received: from localhost ([127.0.0.1]:52172 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VY8uY-0007Aq-Q4; Mon, 21 Oct 2013 08:24:18 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "core issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com
X-Trac-Project: core
Date: Mon, 21 Oct 2013 06:24:18 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/351
Message-ID: <060.156e5840ec396f3f53cc63b4448e19dd@trac.tools.ietf.org>
X-Trac-Ticket-ID: 351
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: akbar.rahman@interdigital.com, angelo@castellani.net, esko.dijk@philips.com, salvatore.loreto@ericsson.com, tho@koanlogic.com
Resent-Message-Id: <20131021062430.B652321F9C6C@ietfa.amsl.com>
Resent-Date: Sun, 20 Oct 2013 23:24:30 -0700 (PDT)
Resent-From: trac+core@trac.tools.ietf.org
Cc: core@ietf.org
Subject: [core] #351: Add security implications of proposed default HC URI mapping
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: trac+core@trac.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 06:24:36 -0000

#351: Add security implications of proposed default HC URI mapping

 Add security implications of proposed default HC URI mapping:
 We may want to take into consideration the security/privacy implications
 of exposing the HC proxy function to the public, especially given the URI
 format that we are proposing which exposes details on the internal
 network.

 Proposal: add a section 8.3 to the Security Considerations.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-core-http-
  esko.dijk@philips.com  |  mapping@tools.ietf.org
     Type:  task         |     Status:  new
 Priority:  major        |  Milestone:
Component:  http-        |    Version:
  mapping                |   Keywords:
 Severity:  -            |
-------------------------+-------------------------------------------------

Ticket URL: 
core 


From prvs=99918f243=abhijan.bhattacharyya@tcs.com  Mon Oct 21 02:43:25 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007F211E84FC for ; Mon, 21 Oct 2013 02:43:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.077
X-Spam-Level: 
X-Spam-Status: No, score=-6.077 tagged_above=-999 required=5 tests=[AWL=0.521,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvot78bZKhkh for ; Mon, 21 Oct 2013 02:42:56 -0700 (PDT)
Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7BF11E8503 for ; Mon, 21 Oct 2013 02:39:57 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.93,537,1378837800"; d="scan'208";a="462518113"
Received: from INKOLSALDLPMTA1.india.tcs.com (unknown [127.0.0.1]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id 6FCEFDAC12; Mon, 21 Oct 2013 15:09:43 +0530 (IST)
Received: from InKolM02.tcs.com (unknown [172.18.18.104]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id 35762DAC02; Mon, 21 Oct 2013 15:09:43 +0530 (IST)
In-Reply-To: 
References:    
To: Klaus Hartke 
MIME-Version: 1.0
X-KeepSent: 2FAD1FB5:2FE3B8B8-65257C0B:0035018C; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010
From: Abhijan Bhattacharyya 
Message-ID: 
Date: Mon, 21 Oct 2013 15:09:42 +0530
X-MIMETrack: Serialize by Notes Server on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 10/21/2013 15:09:42, Serialize complete at 10/21/2013 15:09:42, Serialize by Router on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 10/21/2013 15:09:42
Content-Type: multipart/alternative; boundary="=_alternative 0035115565257C0B_="
Cc: Arpan Pal , "core@ietf.org WG" 
Subject: Re: [core] Fw: New Version Notification for draft-tcs-coap-no-response-option-03.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 09:43:26 -0000

This is a multipart message in MIME format.
--=_alternative 0035115565257C0B_=
Content-Type: text/plain; charset="US-ASCII"

Hi Klaus,


>>> * How does it work across proxies?
>>
>> This option is presently NOT to be forwarded by proxies and hence
>no
>> caching. We have explained this in the text below Table 1 in
>section 4.
>> However, this issue can be kept as an open question for experts to
>comment
>> on.
>
>Not forwarding the No-Response option across proxies is probably
>okay,
>although this limits the applicability of the option a bit.
>
>However, caches can not only be located at proxies; they can also be
>employed by clients and servers. So the draft should clearly describe
>how the option interacts with caches.
>
==================================
Probably there wont be too much effect so far as response caching is 
concerned for cases when the cache is located in the end-point. If the 
option is used in its original form, i.e., no response with 0 then 
obviously response caching is immaterial. If used with response filtering 
(borrowing your suggestion!) then for success we are any way not going to 
cache the responses. The 2.05 response does not arise as this option is 
not applicable for GET.


>>> * Regarding high-frequency/real-time updates: [...]
>>
>> Yes. What we mean is that this option gets rid of the dependency on
>> the reverse path completely where possible. The application is free
>to
>> choose the update rates according to the system being developed
>> (abiding by the prescribed bounds).
>
>So how does the No-Response option provide a higher throughput/less
>latency compared to non-confirmable notifications when using
>draft-ietf-core-observe?
>
=======================================
Well, this option is originally conceived for suppressing all the 
responses. Suppress everything then client is freed of all closed loop 
constrains (other than the suggested interval which may be customized if 
the system allows). Now, one more point to be re-emphasized (as already 
mentioned in the latest version of the draft) is that while comparing with 
observe probably we need to consider the fact that this option just 
provides  a low cost request/response type exchange (where there can only 
be requests and optionally filtered or no response) for typical 
applications where the application compromises for a better trade-off. 
There may be scenarios where designing the infrastructure with this kind 
of compromised approach may be acceptable as a bit simpler way to do just 
the desirable. 'Observe' has a much greater spectrum and is indeed an 
elegant solution. But sometimes simple stuffs just befits in the groove 
enough to get the system going. May be we should look into the solution 
from that aspect! :)


>For high-frequency updates it might be even better to use confirmable
>messages, because the acknowledgement allows the sender to send the
>next update immediately instead of in a fixed interval.
>
>I would even suspect that confirmable messages actually help in the
>reduction in network clogging, because the sender can actually assess
>the network conditions and does not send blindly more and more
>traffic
>into the network. Do you happen to have some measurements on the
>impact of confirmable and non-confirmable messages on network
>clogging?
>
=====================================
The proposed option is a result of experiments on field trials and 
emulated environments over several man-months. We have provided some hints 
of the deployment while describing the 1st use case. We can surely share 
the experimental setups and few results once we get an opportunity to 
present in the Vancouver meeting. 

Firstly, the update interval requirement may not necessarily be decided by 
the client. It can, under many circumstances, be defined by the use case. 
For example, in our case the requirements were to be provided by the 
engineers developing the algorithms for running analytics at the back end. 
It was like "how frequent samples do I need and how much loss in samples 
can I tolerate to run the XYZ analytics".

Secondly, the  CON mode was not good enough. We examined the message 
flights for each updates through packet captures. In practice, there were 
situations where we suffered from duplicated transmissions due to the 
delayed arrivals of ACKs piggybacked with responses. 



>>> * Is the option intended to be critical or elective?
>> Elective. This was already mentioned in the draft. But not in the
>standard
>> way of CoAP spec. We have modified the table format. please check
>Table 1.
>
>The table shows a default value of 0; it should probably be 31 (all
>bits set - no response suppressed). Apart from that it looks good.
>
=================================
Thanks. But we would like to stick to 0 as the default with the assumption 
that if one decides to introduce this option in the request message then 
probably the intention is to suppress responses (assuming 'suppress all' 
is the usual wish). A default of 0 would be desirable then in the usual 
case. But if we get a consensus on keeping all open then we can always do 
that. Not really a big deal.


>Option number 22 is currently not in use. You could put that into the
>draft to allow people to experiment with the No-Response option more
>easily.
>
=================================
Thanks for the suggestion. Will propose that in the meeting.


>>> * How does a sender detect if it's sending its data to a recipient
>>> that is long gone?
>>
>> Addressed these points. Please refer to the enhanced implementation
>note in
>> section 4.1
>
>How does the sender start sending again when the recipient actually
>didn't go away permanently but there was a problem in the network
>temporarily?
>
=================================
Well, is it not the similar situation when we browse for a given site get 
some responses like 'Server busy' or 'The website is temporary 
unavailable', etc. and then we retry using some personalized heuristic 
interval? :) May be application developer can do something like that here 
also. Only thing is that the retry should have all the responses open.

>>> * Should a recipient be able to detect if consecutive messages
>were
>>> reordered?
>>
>> Keeping this open. Would be good if we get some expert comments.
>
>I'm asking you :-) What's your opinion?
=================================
Would it be very different than the usual NON PUT/POST cases? Bit confused 
on that really! :(


Finally, thanks for such detail observations. Conversations like this are 
indeed of immense help in the learning curve of an "IETF-newbie". :)


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



From:
Klaus Hartke 
To:
Abhijan Bhattacharyya 
Cc:
Arpan Pal , "core@ietf.org WG" 
Date:
10/19/2013 01:40 AM
Subject:
Re: [core] Fw: New Version Notification for 
draft-tcs-coap-no-response-option-03.txt



Hi Abhijan,

>> * How does it work across proxies?
>
> This option is presently NOT to be forwarded by proxies and hence no
> caching. We have explained this in the text below Table 1 in section 4.
> However, this issue can be kept as an open question for experts to 
comment
> on.

Not forwarding the No-Response option across proxies is probably okay,
although this limits the applicability of the option a bit.

However, caches can not only be located at proxies; they can also be
employed by clients and servers. So the draft should clearly describe
how the option interacts with caches.

>> * Regarding high-frequency/real-time updates: [...]
>
> Yes. What we mean is that this option gets rid of the dependency on
> the reverse path completely where possible. The application is free to
> choose the update rates according to the system being developed
> (abiding by the prescribed bounds).

So how does the No-Response option provide a higher throughput/less
latency compared to non-confirmable notifications when using
draft-ietf-core-observe?

For high-frequency updates it might be even better to use confirmable
messages, because the acknowledgement allows the sender to send the
next update immediately instead of in a fixed interval.

I would even suspect that confirmable messages actually help in the
reduction in network clogging, because the sender can actually assess
the network conditions and does not send blindly more and more traffic
into the network. Do you happen to have some measurements on the
impact of confirmable and non-confirmable messages on network
clogging?

>> * Is the option intended to be critical or elective?
> Elective. This was already mentioned in the draft. But not in the 
standard
> way of CoAP spec. We have modified the table format. please check Table 
1.

The table shows a default value of 0; it should probably be 31 (all
bits set - no response suppressed). Apart from that it looks good.

Option number 22 is currently not in use. You could put that into the
draft to allow people to experiment with the No-Response option more
easily.

>> * How does a sender detect if it's sending its data to a recipient
>> that is long gone?
>
> Addressed these points. Please refer to the enhanced implementation note 
in
> section 4.1

How does the sender start sending again when the recipient actually
didn't go away permanently but there was a problem in the network
temporarily?

>> * Should a recipient be able to detect if consecutive messages were
>> reordered?
>
> Keeping this open. Would be good if we get some expert comments.

I'm asking you :-) What's your opinion?

Best regards,
Klaus


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



--=_alternative 0035115565257C0B_=
Content-Type: text/html; charset="US-ASCII"

Hi Klaus,





>>> * How does
it work across proxies?

>>

>> This option is presently NOT to be forwarded by proxies and hence

>no

>> caching. We have explained this in the text below Table 1 in

>section 4.

>> However, this issue can be kept as an open question for experts
to

>comment

>> on.

>

>Not forwarding the No-Response option across proxies is probably

>okay,

>although this limits the applicability of the option a bit.

>

>However, caches can not only be located at proxies; they can also be

>employed by clients and servers. So the draft should clearly describe

>how the option interacts with caches.

>

==================================

Probably there wont be too much effect
so far as response caching is concerned for cases when the cache is located
in the end-point. If the option is used in its original form, i.e., no
response with 0 then obviously response caching is immaterial. If used
with response filtering (borrowing your suggestion!) then for success we
are any way not going to  cache the responses.
The 2.05 response does not arise
as this option is not applicable for GET.





>>> * Regarding high-frequency/real-time updates: [...]

>>

>> Yes. What we mean is that this option gets rid of the dependency
on

>> the reverse path completely where possible. The application is
free

>to

>> choose the update rates according to the system being developed

>> (abiding by the prescribed bounds).

>

>So how does the No-Response option provide a higher throughput/less

>latency compared to non-confirmable notifications when using

>draft-ietf-core-observe?

>

=======================================

Well, this option is originally conceived
for suppressing all the responses. Suppress everything then client is freed
of all closed loop constrains (other than the suggested interval which
may be customized if the system allows). Now, one more point to be re-emphasized
(as already mentioned in the latest version of the draft) is that while
comparing with observe probably we need to consider the fact that this
option just provides  a low cost request/response type exchange (where
there can only be requests and optionally filtered or no response) for
typical applications where the application compromises for a better trade-off.
There may be scenarios where designing the infrastructure with this kind
of compromised approach may be acceptable as a bit simpler way to do just
the desirable. 'Observe' has a much greater spectrum and is indeed an elegant
solution. But sometimes simple stuffs just befits in the groove enough
to get the system going. May be we should look into the solution from that
aspect! :)





>For high-frequency updates it might be even better to use confirmable

>messages, because the acknowledgement allows the sender to send the

>next update immediately instead of in a fixed interval.

>

>I would even suspect that confirmable messages actually help in the

>reduction in network clogging, because the sender can actually assess

>the network conditions and does not send blindly more and more

>traffic

>into the network. Do you happen to have some measurements on the

>impact of confirmable and non-confirmable messages on network

>clogging?

>

=====================================

The proposed option is a result of experiments
on field trials and emulated environments over several man-months. We have
provided some hints of the deployment while describing the 1st use case.
We can surely share the experimental setups and few results once we get
an opportunity to present in the Vancouver meeting. 



Firstly, the update interval requirement
may not necessarily be decided by the client. It can, under many circumstances,
be defined by the use case. For example, in our case the requirements were
to be provided by the engineers developing the algorithms for running analytics
at the back end. It was like "how frequent samples do I need and how
much loss in samples can I tolerate to run the XYZ analytics".



Secondly, the  CON mode was not
good enough. We examined the message flights for each updates through packet
captures. In practice, there were situations where we suffered from duplicated
transmissions due to the delayed arrivals of ACKs piggybacked with responses.








>>> * Is the option intended to be critical or elective?

>> Elective. This was already mentioned in the draft. But not in
the

>standard

>> way of CoAP spec. We have modified the table format. please check

>Table 1.

>

>The table shows a default value of 0; it should probably be 31 (all

>bits set - no response suppressed). Apart from that it looks good.

>

=================================

Thanks. But we would like to stick to
0 as the default with the assumption that if one decides to introduce this
option in the request message then probably the intention is to suppress
responses (assuming 'suppress all' is the usual wish). A default of 0 would
be desirable then in the usual case. But if we get a consensus on keeping
all open then we can always do that. Not really a big deal.





>Option number 22 is currently not in use. You could put that into the

>draft to allow people to experiment with the No-Response option more

>easily.

>

=================================

Thanks for the suggestion. Will propose
that in the meeting.





>>> * How does a sender detect if it's sending its data to a recipient

>>> that is long gone?

>>

>> Addressed these points. Please refer to the enhanced implementation

>note in

>> section 4.1

>

>How does the sender start sending again when the recipient actually

>didn't go away permanently but there was a problem in the network

>temporarily?

>

=================================

Well, is it not the similar situation
when we browse for a given site get some responses like 'Server busy' or
'The website is temporary unavailable', etc. and then we retry using some
personalized heuristic interval? :) May be application developer can do
something like that here also. Only thing is that the retry should have
all the responses open.



>>> * Should a recipient be able to detect if consecutive messages

>were

>>> reordered?

>>

>> Keeping this open. Would be good if we get some expert comments.

>

>I'm asking you :-) What's your opinion?

=================================

Would it be very different than the
usual NON PUT/POST cases? Bit confused on that really! :(





Finally, thanks for such detail observations. Conversations like this are
indeed of immense help in the learning curve of an "IETF-newbie".
:)





Regards

Abhijan Bhattacharyya

Associate Consultant

Scientist, Innovation Lab, Kolkata, India

Tata Consultancy Services Limited

Mailto: abhijan.bhattacharyya@tcs.com

Website: http://www.tcs.com

____________________________________________

Experience certainty.        IT Services

                
       Business Solutions

                
       Consulting

____________________________________________










From:
Klaus Hartke <hartke@tzi.org>


To:
Abhijan Bhattacharyya <abhijan.bhattacharyya@tcs.com>


Cc:
Arpan Pal <arpan.pal@tcs.com>,
"core@ietf.org WG" <core@ietf.org>


Date:
10/19/2013 01:40 AM


Subject:
Re: [core] Fw: New Version Notification
for draft-tcs-coap-no-response-option-03.txt










Hi Abhijan,



>> * How does it work across proxies?

>

> This option is presently NOT to be forwarded by proxies and hence
no

> caching. We have explained this in the text below Table 1 in section
4.

> However, this issue can be kept as an open question for experts to
comment

> on.



Not forwarding the No-Response option across proxies is probably okay,

although this limits the applicability of the option a bit.



However, caches can not only be located at proxies; they can also be

employed by clients and servers. So the draft should clearly describe

how the option interacts with caches.



>> * Regarding high-frequency/real-time updates: [...]

>

> Yes. What we mean is that this option gets rid of the dependency on

> the reverse path completely where possible. The application is free
to

> choose the update rates according to the system being developed

> (abiding by the prescribed bounds).



So how does the No-Response option provide a higher throughput/less

latency compared to non-confirmable notifications when using

draft-ietf-core-observe?



For high-frequency updates it might be even better to use confirmable

messages, because the acknowledgement allows the sender to send the

next update immediately instead of in a fixed interval.



I would even suspect that confirmable messages actually help in the

reduction in network clogging, because the sender can actually assess

the network conditions and does not send blindly more and more traffic

into the network. Do you happen to have some measurements on the

impact of confirmable and non-confirmable messages on network

clogging?



>> * Is the option intended to be critical or elective?

> Elective. This was already mentioned in the draft. But not in the
standard

> way of CoAP spec. We have modified the table format. please check
Table 1.



The table shows a default value of 0; it should probably be 31 (all

bits set - no response suppressed). Apart from that it looks good.



Option number 22 is currently not in use. You could put that into the

draft to allow people to experiment with the No-Response option more

easily.



>> * How does a sender detect if it's sending its data to a recipient

>> that is long gone?

>

> Addressed these points. Please refer to the enhanced implementation
note in

> section 4.1



How does the sender start sending again when the recipient actually

didn't go away permanently but there was a problem in the network

temporarily?



>> * Should a recipient be able to detect if consecutive messages
were

>> reordered?

>

> Keeping this open. Would be good if we get some expert comments.



I'm asking you :-) What's your opinion?



Best regards,

Klaus





=====-----=====-----=====

Notice: The information contained in this e-mail

message and/or attachments to it may contain 

confidential or privileged information. If you are 

not the intended recipient, any dissemination, use, 

review, distribution, printing or copying of the 

information contained in this e-mail message 

and/or attachments to it are strictly prohibited. If 

you have received this communication in error, 

please notify us by reply e-mail or telephone and 

immediately and permanently delete the message 

and any attachments. Thank you




--=_alternative 0035115565257C0B_=--


From tho@koanlogic.com  Mon Oct 21 04:48:33 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB00C21F9E52 for ; Mon, 21 Oct 2013 04:48:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ev4y+eYF1U6 for ; Mon, 21 Oct 2013 04:48:26 -0700 (PDT)
Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5E111E84AE for ; Mon, 21 Oct 2013 04:46:27 -0700 (PDT)
Received: by mail-lb0-f175.google.com with SMTP id z5so597923lbh.20 for ; Mon, 21 Oct 2013 04:46:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5UfoeblnP7drkaP0y56zIry0euoIwtl9vJrX0k1o0JA=; b=N06E8azYjGxxweNKnnyR7uUZCBpSbDk2gVonN6sIVFHzhwXsHxlfH8t2Ehtkf7ks1S +T6HgUeXanQgASJDUwKmv9Sp5IKf72ji9Goo/yqrBRLTMU8diQ08/51/KRyFnuYS0U2x rpre3cTFLXzfMxTprgIbbUYuDsVg0O61FZn82iBRseKQm1IJ0x3ySpmXhkMjZW4VYs6s s9HCfb4LwDB6Yzfcpsx4dqcue5c/UZqZYrwo0Em3JTKBsthZQ9MUTdKlMlH+hD2bxTdT hddLUfNTyOIYk65MJqTKL/QO3LseQeW1w3jHS2uAL8mfRp7OLn7i0zjvjB0i9OIwPP7T d4ug==
X-Gm-Message-State: ALoCoQm9IvOabZeqFlhAkdm9WWU/M4CRHxSY3nOtGHzGMP7NcR9aQT/Pt8DkIO0snC1O8hx16PeY
MIME-Version: 1.0
X-Received: by 10.152.3.165 with SMTP id d5mr985643lad.53.1382355986034; Mon, 21 Oct 2013 04:46:26 -0700 (PDT)
Received: by 10.114.21.4 with HTTP; Mon, 21 Oct 2013 04:46:25 -0700 (PDT)
X-Originating-IP: [81.134.152.4]
In-Reply-To: <525ED2DE.5050600@pabigot.com>
References: <525ED2DE.5050600@pabigot.com>
Date: Mon, 21 Oct 2013 12:46:25 +0100
Message-ID: 
From: Thomas Fossati 
To: "Peter A. Bigot" 
Content-Type: text/plain; charset=ISO-8859-1
Cc: core 
Subject: Re: [core] WGLC observe comment: notification supersedure
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 11:48:33 -0000

On Wed, Oct 16, 2013 at 6:54 PM, Peter A. Bigot  wrote:
> To fix this I propose: Change step 3 in section 4.5 to something like:
>
>    3.  If the entry is still in the list of observers, the server MAY
>        replace the message with a new notification with a representation
>        of the current resource state.  Should the resource have changed
>        its state more than once in the meantime, the notifications for
>        the intermediate states are silently skipped.

+1

From pab@pabigot.com  Mon Oct 21 05:01:22 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8A511E819F for ; Mon, 21 Oct 2013 05:01:20 -0700 (PDT)
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=[AWL=0.161,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5dfnVRmJqhx for ; Mon, 21 Oct 2013 05:01:14 -0700 (PDT)
Received: from p3plsmtpa09-05.prod.phx3.secureserver.net (p3plsmtpa09-05.prod.phx3.secureserver.net [173.201.193.234]) by ietfa.amsl.com (Postfix) with ESMTP id 52FA411E83A0 for ; Mon, 21 Oct 2013 05:01:08 -0700 (PDT)
Received: from [192.168.65.10] ([66.41.60.82]) by p3plsmtpa09-05.prod.phx3.secureserver.net with  id fo161m00V1mTNtu01o16SC; Mon, 21 Oct 2013 05:01:07 -0700
Message-ID: <52651787.4050209@pabigot.com>
Date: Mon, 21 Oct 2013 07:01:11 -0500
From: "Peter A. Bigot" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: core 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [core] option numbers greater than 65535
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 12:01:22 -0000

Nothing in coap-18 that I can see prevents a message from carrying an
option with a number greater than 65535, though options above 65804 may
need to be reached in steps.  This was observed by Mykyta Yevstifeyev in
message 1521 (which also cites a relevant MUST requirement in RFC5226),
but at a time when fenceposting still existed and there was a more
effective practical upper bound.

Did I miss something?  If not, is this worthy of a clarification or
erratum?  I believe some current implementations will mask off higher
bits in this case, so option number 65550 would be misinterpreted as a
Max-Age option.

I'd rather not add support for higher numbers into CoAPy, but if the
specification doesn't prohibit them I'll need to do that.

Peter

From cabo@tzi.org  Mon Oct 21 05:52:58 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D458A11E81B1 for ; Mon, 21 Oct 2013 05:52:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.2
X-Spam-Level: 
X-Spam-Status: No, score=-106.2 tagged_above=-999 required=5 tests=[AWL=0.049,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJpVQzxyWEjh for ; Mon, 21 Oct 2013 05:52:51 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 6577411E80E7 for ; Mon, 21 Oct 2013 05:52:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9LCqfxT025034; Mon, 21 Oct 2013 14:52:41 +0200 (CEST)
Received: from [192.168.217.105] (p54891075.dip0.t-ipconnect.de [84.137.16.117]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 7FA7DBA0; Mon, 21 Oct 2013 14:52:41 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Content-Type: text/plain; charset=utf-8
From: Carsten Bormann 
In-Reply-To: <52651787.4050209@pabigot.com>
Date: Mon, 21 Oct 2013 14:52:40 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <1C1A46E2-4F1A-494D-9377-9B9CDA7C84AA@tzi.org>
References: <52651787.4050209@pabigot.com>
To: "Peter A. Bigot" 
X-Mailer: Apple Mail (2.1510)
Cc: core 
Subject: Re: [core] option numbers greater than 65535
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 12:52:59 -0000

On Oct 21, 2013, at 14:01, "Peter A. Bigot"  wrote:

> Nothing in coap-18 that I can see prevents a message from carrying an
> option with a number greater than 65535, though options above 65804 =
may
> need to be reached in steps. =20

Right, the delta encoding does not (cannot) prevent expressing numbers > =
16 bit.

The CoAP Option Number Registry only provides policy for option numbers =
=E2=89=A4 65535.

So there is no good way to use an option number =E2=89=A5 2**16.

I'd say you can use 16-bit unsigneds to represent option numbers inside =
an implementation,=20
and you can happily 4.02 (Bad Option) on any message containing one that =
decodes to =E2=89=A5 2**16.
(Technically, you could keep and interpret the low order bits to =
distinguish critical from elective etc., but I don't see a good reason =
why.)

> I believe some current implementations will mask off higher
> bits in this case, so option number 65550 would be misinterpreted as a
> Max-Age option.

My advice to a receiver would be not to do that.
My advice to a sender would be not to rely on the receivers' correctness =
in this case (but then I wouldn't know to rely on that for what =
purpose...).

Matthias: is there a good place in draft-kovatsch-lwig-coap where we can =
discuss these things?
Or should this collected wisdom go into the core roadmap (RFC 4815 =
style)?

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


From salvatore.loreto@ericsson.com  Mon Oct 21 06:18:07 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A65011E85CB for ; Mon, 21 Oct 2013 06:18:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.869
X-Spam-Level: 
X-Spam-Status: No, score=-104.869 tagged_above=-999 required=5 tests=[AWL=-2.270, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9ffHqgsu1CN for ; Mon, 21 Oct 2013 06:18:02 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5567A11E83B3 for ; Mon, 21 Oct 2013 06:15:26 -0700 (PDT)
X-AuditID: c1b4fb38-b7fcf8e0000062b8-a1-526528e9f013
Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 26.6E.25272.9E825625; Mon, 21 Oct 2013 15:15:22 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.209]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0328.009; Mon, 21 Oct 2013 15:15:18 +0200
From: Salvatore Loreto 
To: "Rahman, Akbar" 
Thread-Topic: [core] Some initial comments on WGLC of draft-ietf-core-observe-11
Thread-Index: AQHOzl+Wuq2kUf9Sb0+Ao5b+45UvtA==
Date: Mon, 21 Oct 2013 13:15:18 +0000
Message-ID: <2B9B48179856DC4FA00C93C79EB7E64A2DB33D@ESESSMB109.ericsson.se>
References: <5A6D74B4-3733-45D1-95B1-E838DADED234@tzi.org>     
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.149]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <6E79DF4B6507374BACBF025E46CED871@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+Jvje4rjdQggzNbBS1+TWhistj3dj2z xbbJr5gcmD2WLPnJ5LH0ehurx7RFmQHMUVw2Kak5mWWpRfp2CVwZq949ZSu4I1axbcUHpgbG LUJdjJwcEgImEt13NrJC2GISF+6tZ+ti5OIQEjjKKPH4zDQmkISQwBJGif+XEkFsNgEziecP tzCD2CICxhKXJhxk6WLk4GAWcJG4eE8QJCwsECgx4VA3M0hYRCBI4vzjGghTT2LrfmWQChYB VYlHl++wgNi8At4Sb3/OY4bY2scsMWPLRXaQBKeAj8T3BxfYQGxGoNO+n1oDdg2zgLjErSfz mSBOFpBYsuc8M4QtKvHy8T+oV5Qk1h7ezgJRryOxYPcnNgjbWuLYgxmMELa2xLKFr5khjhCU ODnzCcsERvFZSFbMQtI+C0n7LCTts5C0L2BkXcXIUZxanJSbbmSwiREYYwe3/LbYwXj5r80h RmkOFiVx3o9vnYOEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MM414kts33cn27LIpfd5sN65 ZbYi6xbPdjnaVfH9v2jmCZFfn6TKd/ffur/jqE/xBcOtnhmt81d832l27npvK9eNF18X7s3Z /CjK81r3ZpWHy+W23DJtDrjA/nPF5cMyehr1zLnmLyZwpKT9vmLVovPJJGNJWVrTH4WqN71y Ii+Olqp9PxOmf0GJpTgj0VCLuag4EQC7fHFUfwIAAA==
Cc: "" , Klaus Hartke 
Subject: Re: [core] Some initial comments on WGLC of	draft-ietf-core-observe-11
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 13:18:07 -0000

Hi Klaus

one comment in line

/Salvatore

On Oct 19, 2013, at 4:05 AM, "Rahman, Akbar"  wrote:

>>=20
>=20
> After thinking a bit further about it, changing the client side wouldn't
> actually be cumbersome at all, because it doesn't really change
> anything. The text in Section 3.6 could be simplified by removing the
> distinction between confirmable and non-confirmable notifications, and a
> note would be added saying that, due to potential loss of Reset
> messages, the client may have to reject multiple notifications until the
> server finally removes the entry from the list of observers.
>=20
> AKBAR - THIS IS A NICE AND SIMPLE IMPROVEMENT, AND I SUPPORT IT.
>=20
>=20
> Requiring the server to remember the message IDs of non-confirmable
> notifications needs some discussion, but it's doable as well if there is
> enough support in the working group. I guess a constrained server could
> always pretend that a Reset message in reply to a non-confirmable
> notification was lost. In my CoAP implementation, the server currently
> remembers the message ID of a non-confirmable notification until it
> starts to transmit the next message to the client. I believe Erbium and
> Californium do something similar(?).
>=20
> AKBAR - CAN WE JUST PUT IT AS AN IMPLEMENTATION NOTE THEN (AS A
> SUGGESTION)?

[Salvatore] what if the server that receives a reset from a client for an n=
on-confirmable notification
just set itself to send all the next notifications run to that client in a =
confirmable way?
that should even easier to implement that remember the message ID of a non-=
confirmable notification
..


>=20
>=20
> If you're asking for cancellation such that the client can actively
> cancel an observation instead of only reactively by rejecting
> notifications, then the consensus so far was that reactive/"garbage
> collection" approach works well enough. We can certainly revisit that
> decision, provided that we can make a final decision soon. We need an
> alternative cancellation mechanism for some transports anyway (see, for
> example, Section 2.4 of [1]). Note that over UDP this would be in
> addition to the current mechanism, not in place of it, so it wouldn't
> exactly make the protocol simpler.
>=20
> AKBAR - THIS WAS MY INITIAL WISH, BUT I DON'T WANT TO FORCE A DISRUPTIVE
> CHANGE AT THIS TIME SINCE EVERYONE ELSE SEEMS OKAY WITH THE CURRENT
> OPERATION.  IT SHOULD PROBABLY BE SOMETHING WE LOOK BACK AT WHEN WE
> CONSIDER THE OTHER TRANSPORTS IN THE FUTURE.  SO LET'S JUST DROP THIS
> ONE FOR NOW.
>=20
>=20
> Best regards,
> Klaus
>=20
>=20
> [1]
> http://tools.ietf.org/html/draft-savolainen-core-coap-websockets-01#sect
> ion-2.4
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core


From salvatore.loreto@ericsson.com  Mon Oct 21 06:18:52 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8810F11E859D for ; Mon, 21 Oct 2013 06:18:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.49
X-Spam-Level: 
X-Spam-Status: No, score=-104.49 tagged_above=-999 required=5 tests=[AWL=-1.892, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVCq-Q4iqfjU for ; Mon, 21 Oct 2013 06:18:46 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id E7D2711E859B for ; Mon, 21 Oct 2013 06:16:18 -0700 (PDT)
X-AuditID: c1b4fb38-b7fcf8e0000062b8-a6-52652921f623
Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id FA.9E.25272.12925625; Mon, 21 Oct 2013 15:16:18 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.209]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0328.009; Mon, 21 Oct 2013 15:16:17 +0200
From: Salvatore Loreto 
To: "core@ietf.org WG" 
Thread-Topic: core-observe-11 wglc review
Thread-Index: AQHOzl+530GHLun9HE+3ebGSYX3xnw==
Date: Mon, 21 Oct 2013 13:16:17 +0000
Message-ID: <2B9B48179856DC4FA00C93C79EB7E64A2DB34C@ESESSMB109.ericsson.se>
References: <5A6D74B4-3733-45D1-95B1-E838DADED234@tzi.org>
In-Reply-To: <5A6D74B4-3733-45D1-95B1-E838DADED234@tzi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: multipart/alternative; boundary="_000_2B9B48179856DC4FA00C93C79EB7E64A2DB34CESESSMB109ericsso_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUyM+Jvja6SZmqQwZSzLBb73q5ndmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxoWPh1gL9uRXTJx/i62B8VhUFyMnh4SAicSMDcvZIWwxiQv3 1rN1MXJxCAkcZZRYcu4slLOEUeLMzXVsIFVsAmYSzx9uYQaxRQTUJFonvQKLCwuoSLSsW8IG EdeU2DmnBapGT+LczN9gG1gEVCWmTL/DBGLzCnhLzDv2GswWErCSmPH+MVg9p4C1xJFbZ8Fs RqCLvp9aA1bDLCAucevJfCaISwUkluw5zwxhi0q8fPyPFcJWklh0+zNUfb7EmdYFLBC7BCVO znzCMoFRZBaSUbOQlM1CUgYRN5B4f24+M4StLbFs4WsoW19i45ezjBC2tUTvok3syGoWMHKs YuQoTi1Oyk03MtjECIyhg1t+W+xgvPzX5hCjNAeLkjjvx7fOQUIC6YklqdmpqQWpRfFFpTmp xYcYmTg4pRoY1fYXetRqCXXvUK36FuPzfap04OTqm39XNH6tKTa6nRh+kOn/rp+JAo3fhVb+ tXymeWn6Jj8/sU0MbHoOxhNOHOxJ3Mf978vMGxpd72SNzgh7n7bkE/17qiTC468an9WdPLfd oj7X9ycxvVc1UVJJyrj1n/34sxk7FAsm3C1ku3zD0Yr5Uo2GEktxRqKhFnNRcSIA+LHMX28C AAA=
Subject: [core] core-observe-11 wglc review
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 13:18:53 -0000

--_000_2B9B48179856DC4FA00C93C79EB7E64A2DB34CESESSMB109ericsso_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi there,

I have read the draft and I have the following comments

br
/Salvatore

1)
Section 1.1


   The model of REST is that of a client exchanging representations of

   resources with a server, where a representation captures the current

   or intended state of a resource and the server is the definitive

   source for representations of the resources in its namespace.

I would suggest to change

s/the server is the definitive source for representations of the resources =
in its namespace./
  the server is the authority for representations of the resources in its n=
amespace.

aligned to RFC3986 e 6454

by the way in other part of the document it is referred as authority

for example in section 1.3




A CoAP server is the authority for determining

2) Section 2. The Observer option


   The list entry consists of the client

   endpoint and the token specified by the client in the request.

it is not clear if the client endpoint + token is an unique key or not.
It should be clear!

3)

   The Observe Option is not part of the cache-key: a cacheable response

   obtained with an Observe Option in the request can be used to satisfy

   a request without an Observe Option, and vice versa.  When a stored

   response that includes an Observe Option is used to satisfy a normal

   GET request, the option MUST be removed before the response is

   returned to the client.

which is the purpose to store the Observe Option in the cache?

4) Section 3.1


A client therefore MUST aggregate requests where possible, and MUST

   NOT register more than once for the same target resource.

what happens if the client does?
This actually can easily be used for a DoS attack


5) general comment about Caching=85
Why we have almost the same text in 3.3 and in 4.3 and subsections?


6) Section 3.3.1

  Additionally,

   the client SHOULD wait for a random amount of time between 5 and 15

   seconds to avoid synchronicity with other clients.

it is not clear that the wait time is supposed to be counted from the momen=
t the
content become stale (time> max-age)

7) 3.3.2 Validation

    this paragraph is not Observe specific, it is just a general rule
    I guess (not remember really) that the same text is already in the core=
-coap spec

8) Transmission
    Why we have almost the same text in 3.5 and in 4.5 and subsections?


Editorial comments

1) Section 1.3
pag 6 the third bullet has an "and/or" too much

   o  , which changes its

      state based on the client-specified parameter value: every second

      to the current temperature reading if the temperature exceeds the

      threshold, or to "OK" when the reading drops below; and/or






On Oct 15, 2013, at 1:45 PM, Carsten Bormann > wrote:

After this WG has focused on completing the base specification for a
while, it is time to finish the two complementing specifications,
-observe and -block.  -observe is first:

draft-ietf-core-observe-11 clears all remaining issues in the tracker.
Thanks go to Klaus for patiently addressing all those details.

This starts a second working group last call for -observe, ending on

24:00 PDT on Tuesday, October 29, 2013.

Please start a new email thread for each major issues 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.

We did an IPR call on the first WGLC, but since that some time has elapsed:

If you are aware of any patent claims that might apply to systems that
implement these drafts, 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.

While everyone may still be a bit tired from completing core-coap (and
we are still waiting for the two missing references to go to the RFC
editor), it is important that we all go and review -observe as well.
The people that have participated heavily have read the draft so many
times that they have a hard time noticing what is wrong or missing
from them but fresh eyes can help.  We know that everyone has many
documents to read for the upcoming IETF, but we would like to try and
convince you that reading drafts that are in WGLC is probably more
important than many others.  Please help us get this right.

Gr=FC=DFe, Carsten

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


--_000_2B9B48179856DC4FA00C93C79EB7E64A2DB34CESESSMB109ericsso_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







Hi there,







I have read the draft and I have the following comments







br


/Salvatore







1)




Section 1.1









   The model of REST is that of a client exchanging =
representations of






   resources with a server, where a representation c=
aptures the current






   or intended state of a resource and the server is=
 the definitive






   source for representations of the resources in it=
s namespace.






I would suggest to change









s/the server is the definitive source for representations of the =
resources in its namespace./


  the server is the authority for representations of the res=
ources in its namespace.







aligned to RFC3986 e 6454







by the way in other part of the document it is referred as authority






for example in section 1.3









	

A CoAP server is the authority for determining 













2) Section 2. The Observer option













   The list entry consists of the client






   endpoint and the token specified by the client in=
 the request.













it is not clear if the client endpoint + token is an unique key or=
 not. 


It should be clear!











3) 






   The Observe Option is not part of the cache-key: =
a cacheable response






   obtained with an Observe Option in the request ca=
n be used to satisfy






   a request without an Observe Option, and vice ver=
sa.  When a stored






   response that includes an Observe Option is used =
to satisfy a normal






   GET request, the option MUST be removed before th=
e response is






   returned to the client.













which is the purpose to store the Observe Option in the cache?









4) Section 3.1











A client therefore MUST aggregate requests where pos=
sible, and MUST






   NOT register more than once for the same target r=
esource. 













what happens if the client does?


This actually can easily be used for a DoS attack 














5) general comment about Caching=85 




Why we have almost the same text in 3.3 and in 4.3 and subsections?













6) Section 3.3.1






  Additionally,






   the client SHOULD wait for a random amount of tim=
e between 5 and 15






   seconds to avoid synchronicity with other clients=
.






it is not clear that the wait time is supposed to be counted from the =
moment the




content become stale (time> max-age)









7) 3.3.2 Validation







    this paragraph is not Observe specific, it is just a gen=
eral rule


    I guess (not remember really) that the same text is alre=
ady in the core-coap spec









8) Transmission


    Why we have almost the same text in 3.5 and in 4.5 and s=
ubsections?














Editorial comments







1) Section 1.3




pag 6 the third bullet has an "and/or" too much


   o  <coap://server/temperature/critical?above=3D45>, whic=
h changes its


      state based on the client-specified parameter =
value: every second


      to the current temperature reading if the temp=
erature exceeds the


      threshold, or to "OK" when the readi=
ng drops below; and/or









 





















On Oct 15, 2013, at 1:45 PM, Carsten Bormann <cabo@tzi.org> wrote:




After this WG has focused on completing the base =
specification for a

while, it is time to finish the two complementing specifications,

-observe and -block.  -observe is first:



draft-ietf-core-observe-11 clears all remaining issues in the tracker.

Thanks go to Klaus for patiently addressing all those details.



This starts a second working group last call for -observe, ending on



24:00 PDT o=
n Tuesday, October 29, 2013.



Please start a new email thread for each major issues 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.



We did an IPR call on the first WGLC, but since that some time has elapsed:=




If you are aware of any patent claims that might apply to systems that

implement these drafts, 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.



While everyone may still be a bit tired from completing core-coap (and

we are still waiting for the two missing references to go to the RFC

editor), it is important that we all go and review -observe as well.

The people that have participated heavily have read the draft so many

times that they have a hard time noticing what is wrong or missing

from them but fresh eyes can help.  We know that everyone has many

documents to read for the upcoming IETF, but we would like to try and

convince you that reading drafts that are in WGLC is probably more

important than many others.  Please help us get this right.



Gr=FC=DFe, Carsten



_______________________________________________

core mailing list

core@ietf.org

https://www.ietf.org/mailman/listinfo/core










--_000_2B9B48179856DC4FA00C93C79EB7E64A2DB34CESESSMB109ericsso_--

From pab@pabigot.com  Mon Oct 21 06:49:34 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4155D11E8569 for ; Mon, 21 Oct 2013 06:49:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level: 
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bukPknGF-Pc for ; Mon, 21 Oct 2013 06:49:28 -0700 (PDT)
Received: from p3plsmtpa09-04.prod.phx3.secureserver.net (p3plsmtpa09-04.prod.phx3.secureserver.net [173.201.193.233]) by ietfa.amsl.com (Postfix) with ESMTP id E30EB11E8563 for ; Mon, 21 Oct 2013 06:49:19 -0700 (PDT)
Received: from [192.168.65.10] ([66.41.60.82]) by p3plsmtpa09-04.prod.phx3.secureserver.net with  id fppD1m00K1mTNtu01ppEBn; Mon, 21 Oct 2013 06:49:19 -0700
Message-ID: <526530DE.1020509@pabigot.com>
Date: Mon, 21 Oct 2013 08:49:18 -0500
From: "Peter A. Bigot" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Carsten Bormann 
References: <52651787.4050209@pabigot.com> <1C1A46E2-4F1A-494D-9377-9B9CDA7C84AA@tzi.org>
In-Reply-To: <1C1A46E2-4F1A-494D-9377-9B9CDA7C84AA@tzi.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: core 
Subject: Re: [core] option numbers greater than 65535
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 13:49:34 -0000

On 10/21/2013 07:52 AM, Carsten Bormann wrote:
> On Oct 21, 2013, at 14:01, "Peter A. Bigot"  wrote:
>
>> Nothing in coap-18 that I can see prevents a message from carrying an
>> option with a number greater than 65535, though options above 65804 may
>> need to be reached in steps.
>
> Right, the delta encoding does not (cannot) prevent expressing numbers > 16 bit.
>
> The CoAP Option Number Registry only provides policy for option numbers ≤ 65535.
>
> So there is no good way to use an option number ≥ 2**16.
>
> I'd say you can use 16-bit unsigneds to represent option numbers inside an implementation,
> and you can happily 4.02 (Bad Option) on any message containing one that decodes to ≥ 2**16.
> (Technically, you could keep and interpret the low order bits to distinguish critical from elective etc., but I don't see a good reason why.)
>

I don't like this approach for a couple reasons.

First, a specification should clearly answer any implementer's "What if
I do this?" questions without requiring a search for intent in the
working group's list archives or any draft or even published "best
practices" documents.  If this can't be resolved in coap-xx before it
becomes an RFC, it needs to be an erratum which can be found by direct
link from the IETF RFC pages.

Second, using 4.02 unnecessarily crosses a layer boundary.  That a "big
option" (one with a number above 65535) is even expressible is due to a
weakness in message encoding, and it should be diagnosed at the message
(CON/NON/ACK/RST) layer not at the REST transaction (request/response)
layer, just as messages with unrecognized critical options are rejected.

What I propose is that the following text resolve this:

    The Option Number MUST be a value in the range 0..65535, although the
    delta encoding permits representations of larger numbers.  Endpoints
    MUST NOT send messages with larger option numbers.  Endpoints MUST
    reject any message with a larger option number.

That probably belongs somewhere around 3.1, but maybe 4.1 or 12.2.  The
last MUST could be a SHOULD, if the IETF model of "undefined behavior"
is like the C language: that the implementation can do whatever it wants
(including masking off high bits of option numbers) if it's fed
something that it was not supposed to be fed.

This text should clearly convey to the implementer the expectations of
the protocol.  If it doesn't, let's refine it.

Peter

From ludwig@sics.se  Mon Oct 21 07:19:16 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27B3511E85C0 for ; Mon, 21 Oct 2013 07:19:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwhnZVBiHI+N for ; Mon, 21 Oct 2013 07:19:11 -0700 (PDT)
Received: from fsmsg2.sics.se (fsmsg2.sics.se [IPv6:2001:6b0:3a:1:250:56ff:fea9:52ad]) by ietfa.amsl.com (Postfix) with ESMTP id 2528111E857F for ; Mon, 21 Oct 2013 07:19:00 -0700 (PDT)
Received: from pps.filterd (fsmsg2 [127.0.0.1]) by fsmsg2.sics.se (8.14.5/8.14.5) with SMTP id r9LE5EKO031372 for ; Mon, 21 Oct 2013 16:18:59 +0200
Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by fsmsg2.sics.se with ESMTP id 1fmxpe0x5a-1 for ; Mon, 21 Oct 2013 16:18:58 +0200
Received: from [192.168.0.103] (unknown [85.235.11.178]) (Authenticated sender: ludwig@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 139B740116 for ; Mon, 21 Oct 2013 16:18:59 +0200 (CEST)
Message-ID: <526537D2.90803@sics.se>
Date: Mon, 21 Oct 2013 16:18:58 +0200
From: Ludwig Seitz 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: core 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070104030702000600040207"
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-10-21_01:2013-10-21, 2013-10-21, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1310210052
Subject: [core] Fwd: New Version Notification for draft-seitz-core-security-modes-00.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 14:19:16 -0000

This is a cryptographically signed message in MIME format.

--------------ms070104030702000600040207
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Dear all,

please find the the notification of our draft submission below. It=20
introduces two new security modes for CoAP over DTLS with the goal to=20
reduce the need for provisioning keys to the constrained devices.

Regards,

Ludwig Seitz

-------- Original Message --------
Subject: New Version Notification for draft-seitz-core-security-modes-00.=
txt
Date: Mon, 21 Oct 2013 07:11:49 -0700
From: internet-drafts@ietf.org
To: Ludwig Seitz , Goeran Selander=20
, Goran Selander 


A new version of I-D, draft-seitz-core-security-modes-00.txt
has been successfully submitted by Ludwig Seitz and posted to the
IETF repository.

Filename:	 draft-seitz-core-security-modes
Revision:	 00
Title:		 Additional Security Modes for CoAP
Creation date:	 2013-10-21
Group:		 Individual Submission
Number of pages: 14
URL:=20
http://www.ietf.org/internet-drafts/draft-seitz-core-security-modes-00.tx=
t
Status:=20
http://datatracker.ietf.org/doc/draft-seitz-core-security-modes
Htmlized:=20
http://tools.ietf.org/html/draft-seitz-core-security-modes-00


Abstract:
    The CoAP draft defines how to use DTLS as security mechanism.  In
    order to establish which nodes are trusted to initiate a DTLS session=

    with a device, the following security modes are defined: NoSec,
    PreSharedKey, RawPublicKey, and Certificate.  These modes require
    either to provision a list of keys of trusted clients, or to handle
    heavyweight certificates.  This memo proposes two intermediate
    security modes involving a trusted third party that are very similar
    to PreSharedKey and RawPublicKey respectively, but which do not
    require out-of-band provisioning of client keys to the device.


=20



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

The IETF Secretariat

--=20
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelev=E4gen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se


--------------ms070104030702000600040207
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMVDCC
BhgwggUAoAMCAQICAwW1izANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl
IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh
dGUgQ2xpZW50IENBMB4XDTEzMDExNTAyMDUwNloXDTE0MDExNTE0Mzc0OFowODEXMBUGA1UE
AwwObHVkd2lnQHNpY3Muc2UxHTAbBgkqhkiG9w0BCQEWDmx1ZHdpZ0BzaWNzLnNlMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqm5Fq+vazAJCxhLsrE6yZ4Fcjf22HECMhhoH
QAVWMuk61UnFAxiiKnsGb2iRrw9fFD2ZZP+VVKiojuMaNzlnyrULh84UwJhmkm6Ab2olLQ4x
XZqNDvFe7djMtMMgqD8Erf35WuK8mrRjqHPX/imDEw4Ub6XvL5+rnhBKQozCm5FoIHOcol5H
EbAO+F4XZA3pgQFyUWpWGlyIMZ3na9fkCBspupWZ68ytytxgB0poqbqJMSZtge6bkP/gZo6e
dnbAydjkSkqHHGbpKzMJVI12TyJlJTN70Zg/OF4EMgcwN0tmJvrNqhH3oXlkKkTWk94ojP8M
J3eQv6del7mB1tJcuwIDAQABo4IC1DCCAtAwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTAO/qDJzu5Icr9AFUhmI3z
qGMpbjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAZBgNVHREEEjAQgQ5sdWR3
aWdAc2ljcy5zZTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsG
AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcC
AjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj
ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0
aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5
aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0
YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzAB
hi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB
BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50
LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN
AQELBQADggEBADhtqCPIvc8t6La1swQso5U7FF3Is5txWrQWPzcttJMyPo1LzdNT/jHEKF93
nOqiKm50NISmDFkBSxKOTTYPFJ4thgFcTZf+K57ucvxL/c+MLj3PlmCMNmtciCa8gxpldYz4
aob7CT02KQZvX+yGUmOTdHkoLd9FaxRq0ei43EAxjGIsU7vliaAoKCSO0pRsdtSrOYNV3fSd
ZB6xd8KBjAJsC8P/Q2BfeMT5+fJPvX5pfj8h+qyGkJCPx2RHhkf5tSIrnOAoYkvrUZFk1JJx
H+v1KrX2QRCu3fx7L9D3S1QNSCD3d3nDcM2sXdtGg6/KynBtw31O4YqQWgU9XQp+NoYwggY0
MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEw
MjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh
cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu
ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll
bnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+
ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0d
Lep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiU
fsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5Dp
IpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuC
YKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/
MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0j
BBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUFBzAB
hhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0
YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nm
c2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRw
Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3
LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9
eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukD
FUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyi
kfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8Cnykh
ExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b
970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCD
z+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqA
SfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076khXO7cNb
BIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8J7GCUBth
HSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRXun0NbeY+
UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEW
MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm
aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy
bWVkaWF0ZSBDbGllbnQgQ0ECAwW1izAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJ
KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzEwMjExNDE4NThaMCMGCSqGSIb3DQEJBDEW
BBRx4Vg7xk/6Kho7wojn4TsZQgxn5jBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL
BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA
MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV
BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh
bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h
cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBbWLMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB
jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy
ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz
IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMFtYswDQYJKoZIhvcNAQEBBQAE
ggEAn2UaJZbEv/bSHArnUbu2doTPH2B6CVq2HVFMguxxUkuVKcn1YMynljVQGNwib1sZBj5G
HIVGYNlykNMIKne6tCstZGRm1uWUj4nNaOZdG028/2hRWp3oN/j1WCKul0k3RT9618upww1x
5wODE9v9o5UDz6uqLqEM3dqKIYD2fPDTQQoRXrYQgzllx5WbHlpwEgSisaoQ85xq6XHdWhu1
Hkwblr3lw69Q815RpqPeJY+c3WYdZSaJNVj3rPQ6IDxLhtrqbyPWTU0kghVfcBH0U+5K+fjQ
IFFaPtPur2MIYi6EQhdykqJGLwcrPQSMk82ZBywSh8akS4HJ3jhC/T5oAgAAAAAAAA==
--------------ms070104030702000600040207--

From ludwig@sics.se  Mon Oct 21 07:22:33 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79B021E808D for ; Mon, 21 Oct 2013 07:22:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8-XY66+jZMC for ; Mon, 21 Oct 2013 07:22:28 -0700 (PDT)
Received: from fsmsg2.sics.se (fsmsg2.sics.se [IPv6:2001:6b0:3a:1:250:56ff:fea9:52ad]) by ietfa.amsl.com (Postfix) with ESMTP id 609AF11E83EE for ; Mon, 21 Oct 2013 07:21:50 -0700 (PDT)
Received: from pps.filterd (fsmsg2 [127.0.0.1]) by fsmsg2.sics.se (8.14.5/8.14.5) with SMTP id r9LE7qNI000860 for ; Mon, 21 Oct 2013 16:21:49 +0200
Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by fsmsg2.sics.se with ESMTP id 1fmxpe0xd8-1 for ; Mon, 21 Oct 2013 16:21:49 +0200
Received: from [192.168.0.103] (unknown [85.235.11.178]) (Authenticated sender: ludwig@sics.se) by letter.sics.se (Postfix) with ESMTPSA id D3B3040116 for ; Mon, 21 Oct 2013 16:21:48 +0200 (CEST)
Message-ID: <5265387C.50104@sics.se>
Date: Mon, 21 Oct 2013 16:21:48 +0200
From: Ludwig Seitz 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: core 
References: <20131021141421.29521.67533.idtracker@ietfa.amsl.com>
In-Reply-To: <20131021141421.29521.67533.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20131021141421.29521.67533.idtracker@ietfa.amsl.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070303030509040403050103"
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-10-21_01:2013-10-21, 2013-10-21, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1310210052
Subject: [core] Fwd: New Version Notification for draft-selander-core-access-control-01.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 14:22:33 -0000

This is a cryptographically signed message in MIME format.

--------------ms070303030509040403050103
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Dear all,

please find the notification of our updated access control draft=20
submission below. We have shortened it significantly and started to=20
align it with draft-gerdes-core-dcaf-authorize (work in progress).

We are looking forward to any comments.

Regards,

Ludwig Seitz

-------- Original Message --------
Subject: New Version Notification for=20
draft-selander-core-access-control-01.txt
Date: Mon, 21 Oct 2013 07:14:21 -0700
From: internet-drafts@ietf.org
To: Ludwig Seitz , Goeran Selander=20
, Mohit Sethi , =

Goran Selander 


A new version of I-D, draft-selander-core-access-control-01.txt
has been successfully submitted by Goeran Selander and posted to the
IETF repository.

Filename:	 draft-selander-core-access-control
Revision:	 01
Title:		 Access Control Framework for Constrained Environments
Creation date:	 2013-10-21
Group:		 Individual Submission
Number of pages: 20
URL:=20
http://www.ietf.org/internet-drafts/draft-selander-core-access-control-01=
=2Etxt
Status:=20
http://datatracker.ietf.org/doc/draft-selander-core-access-control
Htmlized:=20
http://tools.ietf.org/html/draft-selander-core-access-control-01
Diff:=20
http://www.ietf.org/rfcdiff?url2=3Ddraft-selander-core-access-control-01

Abstract:
    The Constrained Application Protocol (CoAP) is a light-weight web
    transfer protocol designed to be used in constrained nodes and
    constrained networks.  Communication security support for CoAP,
    including authentication, encryption, integrity protection, is
    specified by means of a DTLS binding for CoAP, but authorization and
    access control are not described in detail.

    This document describes a generic and dynamic access control
    framework suitable for constrained environments e.g. using CoAP.  The=

    framework builds on standards and well known paradigms for access
    control, externalizing authorization decision making to unconstrained=

    nodes while performing authorization decision enforcement and
    verification of local conditions in constrained devices.


=20



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

The IETF Secretariat





--------------ms070303030509040403050103
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMVDCC
BhgwggUAoAMCAQICAwW1izANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl
IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh
dGUgQ2xpZW50IENBMB4XDTEzMDExNTAyMDUwNloXDTE0MDExNTE0Mzc0OFowODEXMBUGA1UE
AwwObHVkd2lnQHNpY3Muc2UxHTAbBgkqhkiG9w0BCQEWDmx1ZHdpZ0BzaWNzLnNlMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqm5Fq+vazAJCxhLsrE6yZ4Fcjf22HECMhhoH
QAVWMuk61UnFAxiiKnsGb2iRrw9fFD2ZZP+VVKiojuMaNzlnyrULh84UwJhmkm6Ab2olLQ4x
XZqNDvFe7djMtMMgqD8Erf35WuK8mrRjqHPX/imDEw4Ub6XvL5+rnhBKQozCm5FoIHOcol5H
EbAO+F4XZA3pgQFyUWpWGlyIMZ3na9fkCBspupWZ68ytytxgB0poqbqJMSZtge6bkP/gZo6e
dnbAydjkSkqHHGbpKzMJVI12TyJlJTN70Zg/OF4EMgcwN0tmJvrNqhH3oXlkKkTWk94ojP8M
J3eQv6del7mB1tJcuwIDAQABo4IC1DCCAtAwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTAO/qDJzu5Icr9AFUhmI3z
qGMpbjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAZBgNVHREEEjAQgQ5sdWR3
aWdAc2ljcy5zZTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsG
AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcC
AjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj
ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0
aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5
aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0
YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzAB
hi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB
BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50
LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN
AQELBQADggEBADhtqCPIvc8t6La1swQso5U7FF3Is5txWrQWPzcttJMyPo1LzdNT/jHEKF93
nOqiKm50NISmDFkBSxKOTTYPFJ4thgFcTZf+K57ucvxL/c+MLj3PlmCMNmtciCa8gxpldYz4
aob7CT02KQZvX+yGUmOTdHkoLd9FaxRq0ei43EAxjGIsU7vliaAoKCSO0pRsdtSrOYNV3fSd
ZB6xd8KBjAJsC8P/Q2BfeMT5+fJPvX5pfj8h+qyGkJCPx2RHhkf5tSIrnOAoYkvrUZFk1JJx
H+v1KrX2QRCu3fx7L9D3S1QNSCD3d3nDcM2sXdtGg6/KynBtw31O4YqQWgU9XQp+NoYwggY0
MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEw
MjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh
cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu
ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll
bnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+
ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0d
Lep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiU
fsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5Dp
IpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuC
YKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/
MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0j
BBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUFBzAB
hhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0
YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nm
c2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRw
Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3
LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9
eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukD
FUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyi
kfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8Cnykh
ExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b
970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCD
z+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqA
SfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076khXO7cNb
BIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8J7GCUBth
HSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRXun0NbeY+
UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEW
MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm
aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy
bWVkaWF0ZSBDbGllbnQgQ0ECAwW1izAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJ
KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzEwMjExNDIxNDhaMCMGCSqGSIb3DQEJBDEW
BBTkju7CDHkZAWvXH6N/DbDp/mNs7jBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL
BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA
MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV
BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh
bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h
cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBbWLMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB
jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy
ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz
IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMFtYswDQYJKoZIhvcNAQEBBQAE
ggEAcKH/WwqTsyQJOAel9MmzLCIFKaboeP24Zn0vlbyp2WCU7kkgCkGg7ODO7N14+oiaoPkL
Eo9pc/UiaK9z3CY8XSe48YOt5kN7gUBjjfdAVaITeaiCx5XNxxMLJoxH48bAk9HdrCSDp4/O
feY/j7n8fHmj1siVsgEtfAz8v6qWQ7I2Bj4D2BmaF0mXlajaduYhZ2CrbKlxkrNKAbGU5srt
jQAb3aP9817KhgeG5tF5ur0qv2EyKY583DFnc7hrD3rzClO8lhJOaCR0gs+4FqHmdxp/iYc2
Tp2htmH3q5VI9PFn40RZJGWhaLKy0C8BZnOjVRWLbX7KwqmKY2tiUevPegAAAAAAAA==
--------------ms070303030509040403050103--

From weigengyu@bupt.edu.cn  Mon Oct 21 07:26:15 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF7511E85C8 for ; Mon, 21 Oct 2013 07:26:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fHjRBAzMY5V for ; Mon, 21 Oct 2013 07:26:10 -0700 (PDT)
Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id CFD4711E83F4 for ; Mon, 21 Oct 2013 07:25:38 -0700 (PDT)
Received: from WeiGengyuPC (unknown [222.131.14.226]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 5FD3B19F3C3; Mon, 21 Oct 2013 22:25:20 +0800 (HKT)
Message-ID: <02AFD76FE0324C62A1B25EAECB3F5ADD@WeiGengyuPC>
From: "weigengyu" 
To: "Klaus Hartke" 
References: <20131015095410.2100.92494.idtracker@ietfa.amsl.com> 
In-Reply-To: 
Date: Mon, 21 Oct 2013 22:25:17 +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] I-D Action: draft-ietf-core-observe-11.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 14:26:15 -0000

Hi， Klaus，

I have question about "1.2 protocol overview"

" A client remains on the list of observers as long as the server can
  determine the client's continued interest in the resource.  The
  interest is determined from the client's acknowledgement of
  notifications sent in confirmable CoAP messages by the server: If the
  client actively rejects a notification or if the transmission of a
  notification times out after several transmission attempts, then the
  client is assumed to be no longer interested and it is removed from
  the list of observers."

After the client sent a request to the server,
the server will determine the interest of the client from each 
acknowledgement of notification.

Is it possible or rational that the client explicitly tells the server about 
times or duration for the server to send notifications.
Such information should include in the request message.


Regards,

Gengyu

-----原始邮件----- 
From: Klaus Hartke
Sent: Tuesday, October 15, 2013 5:56 PM
To: core@ietf.org WG
Subject: Re: [core] I-D Action: draft-ietf-core-observe-11.txt

draft-ietf-core-observe-11 is the latest in a long series of updates
that resulted from the numerous comments on both
draft-ietf-core-observe and draft-ietf-core-coap from the first WGLC.

I'm glad to report that this revision now has all remaining issues
resolved. (There is, of course, always room for improvement.) It can
be found at:

        http://tools.ietf.org/html/draft-ietf-core-observe-11

Diff from -10:

        http://www.ietf.org/rfcdiff?url2=draft-ietf-core-observe-11

Best regards,
Klaus

On 15 October 2013 12:54,   wrote:
>
> 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           : Observing Resources in CoAP
>         Author(s)       : Klaus Hartke
>         Filename        : draft-ietf-core-observe-11.txt
>         Pages           : 31
>         Date            : 2013-10-15
>
> Abstract:
>    CoAP is a RESTful application protocol for constrained nodes and
>    networks.  The state of a resource on a CoAP server can change over
>    time.  This document specifies a simple protocol extension for CoAP
>    that enables CoAP clients to "observe" resources, i.e., to retrieve
>    a representation of a resource and keep this representation updated
>    by the server over a period of time.  The protocol follows a best-
>    effort approach for sending new representations to clients and
>    provides eventual consistency between the state observed by each
>    client and the actual resource state at the server.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-core-observe
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-core-observe-11
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-core-observe-11
>
>
> Please note that it may take a couple of minutes from the time of 
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core 


From cabo@tzi.org  Mon Oct 21 07:31:25 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E375911E8574 for ; Mon, 21 Oct 2013 07:31:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.201
X-Spam-Level: 
X-Spam-Status: No, score=-106.201 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fE56U7ESmi9U for ; Mon, 21 Oct 2013 07:31:19 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9E511E8591 for ; Mon, 21 Oct 2013 07:30:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9LEU8pG010843; Mon, 21 Oct 2013 16:30:08 +0200 (CEST)
Received: from [192.168.217.105] (p54891075.dip0.t-ipconnect.de [84.137.16.117]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4923BC95; Mon, 21 Oct 2013 16:30:08 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
X-Priority: 3
In-Reply-To: <02AFD76FE0324C62A1B25EAECB3F5ADD@WeiGengyuPC>
Date: Mon, 21 Oct 2013 16:30:07 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20131015095410.2100.92494.idtracker@ietfa.amsl.com>  <02AFD76FE0324C62A1B25EAECB3F5ADD@WeiGengyuPC>
To: "weigengyu" 
X-Mailer: Apple Mail (2.1510)
Cc: core@ietf.org, Klaus Hartke 
Subject: Re: [core] I-D Action: draft-ietf-core-observe-11.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 14:31:25 -0000

On Oct 21, 2013, at 16:25, "weigengyu"  wrote:

> Is it possible or rational that the client explicitly tells the server =
about times or duration for the server to send notifications.
> Such information should include in the request message.

I'm not Klaus, but maybe I can answer this:

We used to have a lifetime in a request for an observation relationship.

People implementing this told us they never knew what to put in there.

It turns out that it is very rare in our world to be interested in =
status updates for, say, 60 minutes.  Much more often, you are =
interested, or you aren't.
So we removed the lifetime concept.

Gr=FC=DFe, Carsten


From cabo@tzi.org  Mon Oct 21 07:33:12 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C04D11E8599 for ; Mon, 21 Oct 2013 07:33:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.202
X-Spam-Level: 
X-Spam-Status: No, score=-106.202 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yl4zm1TTRz14 for ; Mon, 21 Oct 2013 07:32:57 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id DD9AD11E8606 for ; Mon, 21 Oct 2013 07:32:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9LEWSTO014861; Mon, 21 Oct 2013 16:32:28 +0200 (CEST)
Received: from [192.168.217.105] (p54891075.dip0.t-ipconnect.de [84.137.16.117]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id ACEC3C9B; Mon, 21 Oct 2013 16:32:27 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: <526530DE.1020509@pabigot.com>
Date: Mon, 21 Oct 2013 16:32:26 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <01CF56C9-02CC-4465-8577-EFD456E95A95@tzi.org>
References: <52651787.4050209@pabigot.com> <1C1A46E2-4F1A-494D-9377-9B9CDA7C84AA@tzi.org> <526530DE.1020509@pabigot.com>
To: "Peter A. Bigot" 
X-Mailer: Apple Mail (2.1510)
Cc: core 
Subject: Re: [core] option numbers greater than 65535
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 14:33:12 -0000

> First, a specification should clearly answer any implementer's "What =
if
> I do this?" questions without requiring a search for intent in the
> working group's list archives or any draft or even published "best
> practices" documents. =20

Yes.  It also should be less than a thousand pages.
More important, it needs to be *done* at some point.
We reached that point with the core spec 2013-07-15.

Data point: People have been able to build the web with a document as =
precise as RFC 2616.
Only now, 15 years later, do we pick up the loose ends and try to write =
up httpbis (approximately doubling the number of pages).

I'm not saying having a perfect specification would be undesirable, it's =
just that perfection here is empirically uncorrelated with the quality =
of the interoperability.

> If this can't be resolved in coap-xx before it
> becomes an RFC, it needs to be an erratum which can be found by direct
> link from the IETF RFC pages.

This point is unlikely to ever cause interoperability issues, so it =
doesn't seem to have very high priority.

For documenting things like this, I think that RFC 4815 style documents =
work better than lists of errata.  Let's discuss in Vancouver how we =
want to handle this phase.
(As another data point, HTTP went from 2068 to 2616 within 2.5 years.  =
We could do a respin of the spec after a couple of years of experience, =
too.  At a cost of several hundred thousands of dollars of engineer =
time, so that respin should be worth it.)

> Second, using 4.02 unnecessarily crosses a layer boundary.  That a =
"big
> option" (one with a number above 65535) is even expressible is due to =
a
> weakness in message encoding, and it should be diagnosed at the =
message
> (CON/NON/ACK/RST) layer not at the REST transaction (request/response)
> layer, just as messages with unrecognized critical options are =
rejected.

I'm not sure I understand this point:

   o  Unrecognized options of class "critical" that occur in a
      Confirmable request MUST cause the return of a 4.02 (Bad Option)
      response. =20

(5.4.1.  Yes, in other cases the message is rejected. =20
But I was talking about the most prominent case here.)

> What I propose is that the following text resolve this:
>=20
>   The Option Number MUST be a value in the range 0..65535, although =
the
>   delta encoding permits representations of larger numbers.  Endpoints
>   MUST NOT send messages with larger option numbers.  Endpoints MUST
>   reject any message with a larger option number.

Well, that latter "MUST" heaps another requirement on the receiver that =
costs money but that nobody will benefit from.

> That probably belongs somewhere around 3.1, but maybe 4.1 or 12.2.  =
The
> last MUST could be a SHOULD, if the IETF model of "undefined behavior"
> is like the C language: that the implementation can do whatever it =
wants
> (including masking off high bits of option numbers) if it's fed
> something that it was not supposed to be fed.
>=20
> This text should clearly convey to the implementer the expectations of
> the protocol.  If it doesn't, let's refine it.

I'd rather spend time refining observe, block (thank you for your recent =
suggestions on these), congestion control, CoRE AA, ...

Gr=FC=DFe, Carsten


From trac+core@trac.tools.ietf.org  Mon Oct 21 08:28:31 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4F1311E8520 for ; Mon, 21 Oct 2013 08:28:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.526
X-Spam-Level: 
X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30+A+Lh5hY-n for ; Mon, 21 Oct 2013 08:28:31 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id CA04B11E85CB for ; Mon, 21 Oct 2013 08:28:19 -0700 (PDT)
Received: from localhost ([127.0.0.1]:46939 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VYHP0-0002Lx-FU; Mon, 21 Oct 2013 17:28:18 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "core issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-core-observe@tools.ietf.org, hartke@tzi.org
X-Trac-Project: core
Date: Mon, 21 Oct 2013 15:28:18 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/352
Message-ID: <053.fe40688961e0f7400fbc9d728b382546@trac.tools.ietf.org>
X-Trac-Ticket-ID: 352
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-core-observe@tools.ietf.org, hartke@tzi.org, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: hartke@tzi.org
Resent-Message-Id: <20131021152819.CA04B11E85CB@ietfa.amsl.com>
Resent-Date: Mon, 21 Oct 2013 08:28:19 -0700 (PDT)
Resent-From: trac+core@trac.tools.ietf.org
Cc: core@ietf.org
Subject: [core]  #352: Simplify Cancellation text
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: trac+core@trac.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 15:28:32 -0000

#352: Simplify Cancellation text

 The text in Section 3.6 can be simplified a bit by removing the
 distinction between confirmable and non-confirmable notifications. A note
 should be added saying that, due to potential loss of Reset messages, the
 client may have to reject multiple notifications until the server finally
 removes the entry from the list of observers.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-core-
  hartke@tzi.org         |  observe@tools.ietf.org
     Type:  editorial    |     Status:  new
 Priority:  minor        |  Milestone:  post-WGLC-2
Component:  observe      |    Version:  observe-11
 Severity:  In WG Last   |   Keywords:
  Call                   |
-------------------------+-------------------------------------------------

Ticket URL: 
core 


From hartke@tzi.org  Mon Oct 21 08:34:22 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0431D11E85FF for ; Mon, 21 Oct 2013 08:34:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.627
X-Spam-Level: 
X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGwm+Y24VQaQ for ; Mon, 21 Oct 2013 08:34:17 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id C3C9811E8617 for ; Mon, 21 Oct 2013 08:33:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9LFXSVq015945 for ; Mon, 21 Oct 2013 17:33:28 +0200 (CEST)
Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41508D12 for ; Mon, 21 Oct 2013 17:33:28 +0200 (CEST)
Received: by mail-vb0-f54.google.com with SMTP id q14so4215876vbe.13 for ; Mon, 21 Oct 2013 08:33:25 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jITxXRZaoarG6AD919LV0ZdWSMtWbGXO42LTujJ1I2M=; b=J3UR9ovF5ozwknNIzrnodQcZyKc+JoaprdtWDgOOvbbHD90uWKhp30PHVCTldDX681 jUKZktnEmyHNk/BYpnDraMh/MYO7LTrdektZ0pSBa864mobPijPrAr91KpqVFEyk16lA 2OFcpBPDEio4mw8yZZ4Hhc98uUTkSZJqA1mg+KR742lSG1zkglvvVlQgLlyzuEWxkjaH xSYsvw9svG7QILS/6hdBDUCodHW1hrK0YVaxcG+GnRcN4Hl39opfV3Ao0bAtCMb+f7hl 4Q2DhiZm7l5Lb/aZ2rK2WriS+7s/btKuDpWTkBBifVhBE3QOvs0Nq1QZwSNFRPkDfkaY Rl9Q==
X-Received: by 10.52.65.136 with SMTP id x8mr1258636vds.23.1382369605100; Mon, 21 Oct 2013 08:33:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.24.83 with HTTP; Mon, 21 Oct 2013 08:32:45 -0700 (PDT)
In-Reply-To: 
References: <5A6D74B4-3733-45D1-95B1-E838DADED234@tzi.org>     
From: Klaus Hartke 
Date: Mon, 21 Oct 2013 18:32:45 +0300
Message-ID: 
To: "Rahman, Akbar" 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "core@ietf.org WG" 
Subject: Re: [core] Some initial comments on WGLC of draft-ietf-core-observe-11
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 15:34:22 -0000

Akbar Rahman wrote:
> After thinking a bit further about it, changing the client side wouldn't
> actually be cumbersome at all, because it doesn't really change
> anything. The text in Section 3.6 could be simplified by removing the
> distinction between confirmable and non-confirmable notifications, and a
> note would be added saying that, due to potential loss of Reset
> messages, the client may have to reject multiple notifications until the
> server finally removes the entry from the list of observers.
>
> AKBAR - THIS IS A NICE AND SIMPLE IMPROVEMENT, AND I SUPPORT IT.

I've created ticket #352 [1]. Of course, this can be further discussed
if other people want to chime in.

Best regards,
Klaus

[1] http://trac.tools.ietf.org/wg/core/trac/ticket/352

From weigengyu@bupt.edu.cn  Mon Oct 21 08:40:56 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C3E11E85BB for ; Mon, 21 Oct 2013 08:40:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajRp2qKK5BuG for ; Mon, 21 Oct 2013 08:40:48 -0700 (PDT)
Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6C04811E85F7 for ; Mon, 21 Oct 2013 08:39:31 -0700 (PDT)
Received: from WeiGengyuPC (unknown [222.131.14.226]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 75F0919F397; Mon, 21 Oct 2013 23:39:30 +0800 (HKT)
Message-ID: <09529BBB901543E090E231E11E8F9174@WeiGengyuPC>
From: "weigengyu" 
To: "Carsten Bormann" 
References: <20131015095410.2100.92494.idtracker@ietfa.amsl.com>  <02AFD76FE0324C62A1B25EAECB3F5ADD@WeiGengyuPC> 
In-Reply-To: 
Date: Mon, 21 Oct 2013 23:39:27 +0800
Organization: BUPT
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; 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, Klaus Hartke 
Subject: Re: [core] I-D Action: draft-ietf-core-observe-11.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 15:40:56 -0000

Hi, Carster,

> We used to have a lifetime in a request for an observation relationship.

The information sent from the client is the detailed requirement by times or 
dutation.
It has no relations to the lifetime or status of client or server.

> People implementing this told us they never knew what to put in there.
Different implementations will meet different requirements.
We have experince for the healthcare implementations.
There kinds of sensors, i.e. electriccadio, blood sugar, and respirator, 
connecting to smart phone by blooth,
and then through the 3G network, data are tranmitted to a dedicated server 
in the Internet.

When people want to get the data from the server (sensor) , he should know 
that.
Such requirements are clear and mostly pre-defined.

> It turns out that it is very rare in our world to be interested in status 
> updates for, say, 60 minutes.  Much more often, you are interested, or you 
> aren't.
> So we removed the lifetime concept.

There are no sematics for the client to change status.
There is only one condition for the server to stop sending.  That is couter 
or timer.
In the current draft,  counter and timers are also used in the protocol for 
RETRANSMISSION or after sending notifications.

The information will change the server the same means as the protocol had.

regards,

Gengyu

From: Carsten Bormann
Sent: Monday, October 21, 2013 10:30 PM
To: weigengyu
Cc: Klaus Hartke ; core@ietf.org
Subject: Re: [core] I-D Action: draft-ietf-core-observe-11.txt

On Oct 21, 2013, at 16:25, "weigengyu"  wrote:

> Is it possible or rational that the client explicitly tells the server 
> about times or duration for the server to send notifications.
> Such information should include in the request message.

I'm not Klaus, but maybe I can answer this:

We used to have a lifetime in a request for an observation relationship.

People implementing this told us they never knew what to put in there.

It turns out that it is very rare in our world to be interested in status 
updates for, say, 60 minutes.  Much more often, you are interested, or you 
aren't.
So we removed the lifetime concept.

Gre, Carsten


From pab@pabigot.com  Mon Oct 21 08:44:21 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C2011E85D8 for ; Mon, 21 Oct 2013 08:44:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.458
X-Spam-Level: 
X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Q0KQ+G1ornH for ; Mon, 21 Oct 2013 08:44:16 -0700 (PDT)
Received: from p3plsmtpa09-08.prod.phx3.secureserver.net (p3plsmtpa09-08.prod.phx3.secureserver.net [173.201.193.237]) by ietfa.amsl.com (Postfix) with ESMTP id F1E8011E857A for ; Mon, 21 Oct 2013 08:40:54 -0700 (PDT)
Received: from [192.168.65.10] ([66.41.60.82]) by p3plsmtpa09-08.prod.phx3.secureserver.net with  id frgr1m00C1mTNtu01rgrs9; Mon, 21 Oct 2013 08:40:54 -0700
Message-ID: <52654B08.8020007@pabigot.com>
Date: Mon, 21 Oct 2013 10:40:56 -0500
From: "Peter A. Bigot" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Carsten Bormann 
References: <52651787.4050209@pabigot.com> <1C1A46E2-4F1A-494D-9377-9B9CDA7C84AA@tzi.org> <526530DE.1020509@pabigot.com> <01CF56C9-02CC-4465-8577-EFD456E95A95@tzi.org>
In-Reply-To: <01CF56C9-02CC-4465-8577-EFD456E95A95@tzi.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: core 
Subject: Re: [core] option numbers greater than 65535
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 15:44:22 -0000

On 10/21/2013 09:32 AM, Carsten Bormann wrote:
> Data point: People have been able to build the web with a document as
> precise as RFC 2616. Only now, 15 years later, do we pick up the
> loose ends and try to write up httpbis (approximately doubling the
> number of pages).
>
> I'm not saying having a perfect specification would be undesirable,
> it's just that perfection here is empirically uncorrelated with the
> quality of the interoperability.

HTTP pre-dates RFC2616 by at least eight years that included huge
amounts of field deployment and interoperability.  CoAP is attempting to
define a specification based on (I'm guessing) a dozen or so coordinated
implementations being used in test environments.  RFC2616 leveraged
vastly more implementation experience and produced a document that is
far more precise than CoAP.

I'm not saying CoAP needs to be perfect from the start.  I'm saying we
need to help its adoption by accepting and addressing its flaws clearly
and visibly.  Doing that will help justify (or not) a future re-spin,
once there's actual field experience with interoperable systems that use it.

>> If this can't be resolved in coap-xx before it becomes an RFC, it
>> needs to be an erratum which can be found by direct link from the
>> IETF RFC pages.
>
> This point is unlikely to ever cause interoperability issues, so it
> doesn't seem to have very high priority.

No point arguing about hypotheticals.  If I'm still dabbling in CoAP
when the RFC comes out I'll report it as a technical erratum then so
future implementers are at least made aware of the potential issue.

> For documenting things like this, I think that RFC 4815 style
> documents work better than lists of errata.  Let's discuss in
> Vancouver how we want to handle this phase.

FWIW I won't be at Vancouver; my CoAP work is unfunded so travel isn't
an option.

>> Second, using 4.02 unnecessarily crosses a layer boundary.  That a
>> "big option" (one with a number above 65535) is even expressible is
>> due to a weakness in message encoding, and it should be diagnosed
>> at the message (CON/NON/ACK/RST) layer not at the REST transaction
>> (request/response) layer, just as messages with unrecognized
>> critical options are rejected.
>
> I'm not sure I understand this point:
>
> o  Unrecognized options of class "critical" that occur in a
> Confirmable request MUST cause the return of a 4.02 (Bad Option)
> response.
>
> (5.4.1.  Yes, in other cases the message is rejected. But I was
> talking about the most prominent case here.)

OK, I can see that.  My search located the second clause:

    o  Unrecognized options of class "critical" that occur in a Non-
       confirmable message MUST cause the message to be rejected
       (Section 4.3).

and with wishful thinking I assumed that message-level errors would be
treated consistently.  The message-layer/transaction-layer distinction
is even weaker than I'd thought.

I have a very difficult time coming up with a mental model of how CoAP
is supposed to work, given how much of it is defined in terms of
behavior in specific cases instead of core rules.  The resulting
complexity of interactions between observe/block/groupcomm when mixing
message-layer and transaction-layer choices and expectations is huge.

Peter

From hartke@tzi.org  Mon Oct 21 08:45:12 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C4211E85CC for ; Mon, 21 Oct 2013 08:45:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.627
X-Spam-Level: 
X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgvH4LpRo9kG for ; Mon, 21 Oct 2013 08:45:04 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 2ABED11E8659 for ; Mon, 21 Oct 2013 08:42:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9LFg0KX003210 for ; Mon, 21 Oct 2013 17:42:00 +0200 (CEST)
Received: from mail-vb0-f43.google.com (mail-vb0-f43.google.com [209.85.212.43]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 37653D1C for ; Mon, 21 Oct 2013 17:42:00 +0200 (CEST)
Received: by mail-vb0-f43.google.com with SMTP id g10so1881475vbg.16 for ; Mon, 21 Oct 2013 08:41:58 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Tdrh/MFIOI/4hWsq5S3SmrAUVCGKDJv8S+NKfb1/6/Q=; b=gwP+Fn9vo7y8D22DNi6tk1bPLTBG6hYoOPZVyVrHLHEjmGXh6m+ecVaenEAfK2vBW7 e1od4xqXo7nJOggWdR7MmDS5cYV4HnwSr+viVlO/5p7F/bbmy2pdQcZayOQQZwQL/VAQ fgE+91qSutIunH8U6zeFnTTstJYcjhoTeOqiyLFi0oQR2RDBDFFr92wdikdNXjgG+J8h Q5KSfjBRq2Bzzqu3xdzH9Cfc8TC5EHDNXUjvqEHzaFgsxbK6YCQWgRZLvN41DC/VonVw UprCr3FPoAw7gf9A5upIorTyjDUVigjFdmyXL+hsnZWmSAD+sxIn78rJBVr3doE2yho6 ZDHA==
X-Received: by 10.52.165.131 with SMTP id yy3mr1241818vdb.25.1382370118913; Mon, 21 Oct 2013 08:41:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.24.83 with HTTP; Mon, 21 Oct 2013 08:41:18 -0700 (PDT)
In-Reply-To: <2B9B48179856DC4FA00C93C79EB7E64A2DB33D@ESESSMB109.ericsson.se>
References: <5A6D74B4-3733-45D1-95B1-E838DADED234@tzi.org>      <2B9B48179856DC4FA00C93C79EB7E64A2DB33D@ESESSMB109.ericsson.se>
From: Klaus Hartke 
Date: Mon, 21 Oct 2013 18:41:18 +0300
Message-ID: 
To: Salvatore Loreto 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "" 
Subject: Re: [core] Some initial comments on WGLC of draft-ietf-core-observe-11
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 15:45:12 -0000

Hi Salvatore, Akbar,

>> Requiring the server to remember the message IDs of non-confirmable
>> notifications needs some discussion, but it's doable as well if there is
>> enough support in the working group. I guess a constrained server could
>> always pretend that a Reset message in reply to a non-confirmable
>> notification was lost.
>>
>> AKBAR - CAN WE JUST PUT IT AS AN IMPLEMENTATION NOTE THEN (AS A
>> SUGGESTION)?
>
> [Salvatore] what if the server that receives a reset from a client for an non-confirmable notification
> just set itself to send all the next notifications run to that client in a confirmable way?
> that should even easier to implement that remember the message ID of a non-confirmable notification

Sounds good. Are these implementation techniques something that should
be documented in draft-ietf-core-observe, or would perhaps a better
place be LWIG?

Best regards,
Klaus

From esko.dijk@philips.com  Mon Oct 21 08:57:46 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB81711E865B for ; Mon, 21 Oct 2013 08:57:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.853
X-Spam-Level: 
X-Spam-Status: No, score=-2.853 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvvt5NgKwhyH for ; Mon, 21 Oct 2013 08:57:29 -0700 (PDT)
Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id B1D9511E81A2 for ; Mon, 21 Oct 2013 08:56:04 -0700 (PDT)
Received: from mail24-co1-R.bigfish.com (10.243.78.252) by CO1EHSOBE004.bigfish.com (10.243.66.67) with Microsoft SMTP Server id 14.1.225.22; Mon, 21 Oct 2013 15:56:03 +0000
Received: from mail24-co1 (localhost [127.0.0.1])	by mail24-co1-R.bigfish.com (Postfix) with ESMTP id 5F4C070011C	for ; Mon, 21 Oct 2013 15:56:03 +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: -11
X-BigFish: VPS-11(zz217bI15d6Oc85fh9251I1db9Mdd85kzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz18c673hz2dh2a8h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1bceh1fb3h1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h20f0h1155h)
Received: from mail24-co1 (localhost.localdomain [127.0.0.1]) by mail24-co1 (MessageSwitch) id 1382370960827572_30000; Mon, 21 Oct 2013 15:56:00 +0000 (UTC)
Received: from CO1EHSMHS003.bigfish.com (unknown [10.243.78.233])	by mail24-co1.bigfish.com (Postfix) with ESMTP id C7144600031	for ; Mon, 21 Oct 2013 15:56:00 +0000 (UTC)
Received: from mail.philips.com (157.55.7.222) by CO1EHSMHS003.bigfish.com (10.243.66.13) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 21 Oct 2013 15:56:00 +0000
Received: from 011-DB3MMR1-015.MGDPHG.emi.philips.com (10.128.28.99) by 011-DB3MMR1-006.MGDPHG.emi.philips.com (10.128.28.56) with Microsoft SMTP Server (TLS) id 14.3.146.2; Mon, 21 Oct 2013 15:55:56 +0000
Received: from 011-DB3MPN2-083.MGDPHG.emi.philips.com ([169.254.3.36]) by 011-DB3MMR1-015.MGDPHG.emi.philips.com ([10.128.28.99]) with mapi id 14.03.0146.002; Mon, 21 Oct 2013 15:55:56 +0000
From: "Dijk, Esko" 
To: "core (core@ietf.org)" 
Thread-Topic: WGLC draft-ietf-core-observe-11: support for pre-configured observers ?
Thread-Index: Ac7Obh27ZDRwc2TBQg6X4cmYut8XOw==
Date: Mon, 21 Oct 2013 15:55:55 +0000
Message-ID: <031DD135F9160444ABBE3B0C36CED6180171AFE5@011-DB3MPN2-083.MGDPHG.emi.philips.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [188.207.104.150]
Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED6180171AFE5011DB3MPN2083MG_"
MIME-Version: 1.0
X-OriginatorOrg: philips.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Subject: [core] WGLC draft-ietf-core-observe-11: support for pre-configured observers ?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 15:57:47 -0000

--_000_031DD135F9160444ABBE3B0C36CED6180171AFE5011DB3MPN2083MG_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear all,

Just a thought. I was wondering if observe would also support pre-configure=
d observers. With that I mean a server is preconfigured to send to send cha=
nge notifications for a specific resource to a specific preset CoAP endpoin=
t (client). One could also call it a persistent observe relationship; if th=
e CoAP server reboots it continues sending the observe notifications.

This could be of interest for sleepy device / intermittent connectivity use=
 cases, where it was previously noted that contacting the sleepy endpoint t=
o do the first part (registration) would likely fail. Was it ever considere=
d? Are there immediate reasons why this wouldn't work? (e.g. inability of c=
lient to re-register once it has been un-registered from notifications)

Esko


________________________________
The information contained in this message may be confidential and legally p=
rotected under applicable law. The message is intended solely for the addre=
ssee(s). If you are not the intended recipient, you are hereby notified tha=
t any use, forwarding, dissemination, or reproduction of this message is st=
rictly prohibited and may be unlawful. If you are not the intended recipien=
t, please contact the sender by return e-mail and destroy all copies of the=
 original message.

--_000_031DD135F9160444ABBE3B0C36CED6180171AFE5011DB3MPN2083MG_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable










Dear all,


 


Just a thought. I was wondering if observe would als=
o support pre-configured observers. With that I mean a server is preconfigu=
red to send to send change notifications for a specific resource to a speci=
fic preset CoAP endpoint (client).
 One could also call it a persistent observe relationship; if the CoAP serv=
er reboots it continues sending the observe notifications.


 


This could be of interest for sleepy device / interm=
ittent connectivity use cases, where it was previously noted that contactin=
g the sleepy endpoint to do the first part (registration) would likely fail=
. Was it ever considered? Are there
 immediate reasons why this wouldn’t work? (e.g. inability of client =
to re-register once it has been un-registered from notifications)


 


Esko


 







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





--_000_031DD135F9160444ABBE3B0C36CED6180171AFE5011DB3MPN2083MG_--

From kovatsch@inf.ethz.ch  Mon Oct 21 09:13:27 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E03711E85A4 for ; Mon, 21 Oct 2013 09:13:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5ITDdU+3us4 for ; Mon, 21 Oct 2013 09:13:21 -0700 (PDT)
Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id E0B6711E81AB for ; Mon, 21 Oct 2013 09:12:51 -0700 (PDT)
Received: from CAS12.d.ethz.ch (172.31.38.212) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.2.298.4; Mon, 21 Oct 2013 18:12:48 +0200
Received: from MBX210.d.ethz.ch ([fe80::ed77:7d47:9467:69a9]) by CAS12.d.ethz.ch ([fe80::7861:4ecb:7c42:cad4%10]) with mapi id 14.02.0298.004; Mon, 21 Oct 2013 18:12:49 +0200
From: "Kovatsch  Matthias" 
To: "Dijk, Esko" , "core (core@ietf.org)" 
Thread-Topic: [core] WGLC draft-ietf-core-observe-11: support for pre-configured observers ?
Thread-Index: Ac7Obh27ZDRwc2TBQg6X4cmYut8XOwACZ8HQ
Date: Mon, 21 Oct 2013 16:12:48 +0000
Message-ID: <55877B3AFB359744BA0F2140E36F52B515C07F27@MBX210.d.ethz.ch>
References: <031DD135F9160444ABBE3B0C36CED6180171AFE5@011-DB3MPN2-083.MGDPHG.emi.philips.com>
In-Reply-To: <031DD135F9160444ABBE3B0C36CED6180171AFE5@011-DB3MPN2-083.MGDPHG.emi.philips.com>
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: multipart/alternative; boundary="_000_55877B3AFB359744BA0F2140E36F52B515C07F27MBX210dethzch_"
MIME-Version: 1.0
Subject: Re: [core] WGLC draft-ietf-core-observe-11: support for pre-configured observers ?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 16:13:27 -0000

--_000_55877B3AFB359744BA0F2140E36F52B515C07F27MBX210dethzch_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear Esko

Do we need special support for that?
If the client implementation is prepared for this, it will just work.
If it is not, it will reject the notifications or the garbage collection wi=
ll take care.

May a short separate informational document is useful to tell people about =
this possibility and maybe some best practices (although I cannot think abo=
ut many different ways to do this..).
I while ago I thought about this to get rid of the client role in servers t=
o register with an RD.

Ciao
Matthias



From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Dij=
k, Esko
Sent: Montag, 21. Oktober 2013 17:56
To: core (core@ietf.org)
Subject: [core] WGLC draft-ietf-core-observe-11: support for pre-configured=
 observers ?

Dear all,

Just a thought. I was wondering if observe would also support pre-configure=
d observers. With that I mean a server is preconfigured to send to send cha=
nge notifications for a specific resource to a specific preset CoAP endpoin=
t (client). One could also call it a persistent observe relationship; if th=
e CoAP server reboots it continues sending the observe notifications.

This could be of interest for sleepy device / intermittent connectivity use=
 cases, where it was previously noted that contacting the sleepy endpoint t=
o do the first part (registration) would likely fail. Was it ever considere=
d? Are there immediate reasons why this wouldn't work? (e.g. inability of c=
lient to re-register once it has been un-registered from notifications)

Esko


________________________________
The information contained in this message may be confidential and legally p=
rotected under applicable law. The message is intended solely for the addre=
ssee(s). If you are not the intended recipient, you are hereby notified tha=
t any use, forwarding, dissemination, or reproduction of this message is st=
rictly prohibited and may be unlawful. If you are not the intended recipien=
t, please contact the sender by return e-mail and destroy all copies of the=
 original message.

--_000_55877B3AFB359744BA0F2140E36F52B515C07F27MBX210dethzch_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Dear Esko


 


Do we need special sup=
port for that?


If the client implemen=
tation is prepared for this, it will just work.


If it is not, it will =
reject the notifications or the garbage collection will take care.


 


May a short separate i=
nformational document is useful to tell people about this possibility and m=
aybe some best practices (although I cannot think about many different ways=
 to do this..).


I while ago I thought =
about this to get rid of the client role in servers to register with an RD.=



 


Ciao=



Matthias


 


 


 








From: core-bou=
nces@ietf.org [mailto:core-bounces@ietf.org]
On Behalf Of Dijk, Esko

Sent: Montag, 21. Oktober 2013 17:56

To: core (core@ietf.org)

Subject: [core] WGLC draft-ietf-core-observe-11: support for pre-con=
figured observers ?






 




Dear all,


 


Just a thought. I was wondering if observe would als=
o support pre-configured observers. With that I mean a server is preconfigu=
red to send to send change notifications for a specific resource to a speci=
fic preset CoAP endpoint (client).
 One could also call it a persistent observe relationship; if the CoAP serv=
er reboots it continues sending the observe notifications.


 


This could be of interest for sleepy device / interm=
ittent connectivity use cases, where it was previously noted that contactin=
g the sleepy endpoint to do the first part (registration) would likely fail=
. Was it ever considered? Are there
 immediate reasons why this wouldn’t work? (e.g. inability of client =
to re-register once it has been un-registered from notifications)


 


Esko


 




 








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








--_000_55877B3AFB359744BA0F2140E36F52B515C07F27MBX210dethzch_--

From hartke@tzi.org  Mon Oct 21 09:50:06 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A79A11E8604 for ; Mon, 21 Oct 2013 09:50:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.627
X-Spam-Level: 
X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BraEdXshV-a0 for ; Mon, 21 Oct 2013 09:50:01 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 0E79911E85D8 for ; Mon, 21 Oct 2013 09:49:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9LGnTXx016791 for ; Mon, 21 Oct 2013 18:49:29 +0200 (CEST)
Received: from mail-ve0-f169.google.com (mail-ve0-f169.google.com [209.85.128.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id AE437D6D for ; Mon, 21 Oct 2013 18:49:29 +0200 (CEST)
Received: by mail-ve0-f169.google.com with SMTP id oy12so4633816veb.28 for ; Mon, 21 Oct 2013 09:49:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=ItwyNd3ejjT5WgLgpiRiKgLnjmjAZ/6WCaFASBnRZNw=; b=YGQtDtlq6li26PT1SNOx6HbHuORO7x3e+oWFrIf3ufJQ3tr4SLmqYjFB9OBnP38Vvg nwlozMg/TTA7mSWy6K/k8jzSnr7VWW3n7qvHkueB/aQHKnNSLwqt1hp437kH8VPJTNiB 27VlJ8r5iIXj9b+jaD0qnwb5oWoVbpVCsR5vr+2JG/o9QJXMc5pqITbB6M15/dyXj8EP hqEcjY5Z2XyVc4NV1RwtBqAD+sk4HbcOueK0nOM42XHP8Uqwjlk18Rl53R6n/T5PdMU4 ZPHmkjk76ORg96fJnG3oHKa8tfmI9WHHeGU5r18AmYtR7rydPxz80ooJWe30Zzq2ubsc eIkQ==
X-Received: by 10.58.168.205 with SMTP id zy13mr1740311veb.19.1382374168469; Mon, 21 Oct 2013 09:49:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.24.83 with HTTP; Mon, 21 Oct 2013 09:48:48 -0700 (PDT)
In-Reply-To: <031DD135F9160444ABBE3B0C36CED6180171AFE5@011-DB3MPN2-083.MGDPHG.emi.philips.com>
References: <031DD135F9160444ABBE3B0C36CED6180171AFE5@011-DB3MPN2-083.MGDPHG.emi.philips.com>
From: Klaus Hartke 
Date: Mon, 21 Oct 2013 19:48:48 +0300
Message-ID: 
To: "Dijk, Esko" 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: "core \(core@ietf.org\)" 
Subject: Re: [core] WGLC draft-ietf-core-observe-11: support for pre-configured observers ?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 16:50:06 -0000

Hi Esko,

there are indeed multiple cases where the goal is in principle
synchronize the state at one or more nodes to a "master state" (this
is what draft-ietf-core-observe provides) but the registration
mechanism defined in draft-ietf-core-observe doesn't really work.

Examples that have come up in discussions and drafts are:

- Synchronizing the state at each member of a multicast group to a
master state. (-groupcomm)

- Synchronizing the state at some mirror server to the master state at
a sleepy sensor node. (-mirror-server)

- Synchronizing the state at a single server in the cloud to the
master state at a constrained node. (-no-response-option)

- IIRC, Zach had some use-case where he wanted to send notifications
to a different node than the one registering.

So, yes, it makes a lot of sense to consider alternative registration
mechanisms, such as a static list of pre-configured observers as you
propose. This is on my list of next steps after
draft-ietf-core-observe is finished.

Technically, it should be trivially possible to send unsolicited
notifications to a client (or intermediary in the role of the client)
if the client can infer the all necessary context from the token.
There are some security concerns that need to solved first. (For
example, registering a multicast group as an observer was proposed at
IETF78 in 2010 but was shot down due to amplification issues.)

Best regards,
Klaus


On 21 October 2013 18:55, Dijk, Esko  wrote:
> Dear all,
>
>
>
> Just a thought. I was wondering if observe would also support pre-configu=
red
> observers. With that I mean a server is preconfigured to send to send cha=
nge
> notifications for a specific resource to a specific preset CoAP endpoint
> (client). One could also call it a persistent observe relationship; if th=
e
> CoAP server reboots it continues sending the observe notifications.
>
>
>
> This could be of interest for sleepy device / intermittent connectivity u=
se
> cases, where it was previously noted that contacting the sleepy endpoint =
to
> do the first part (registration) would likely fail. Was it ever considere=
d?
> Are there immediate reasons why this wouldn=92t work? (e.g. inability of
> client to re-register once it has been un-registered from notifications)
>
>
>
> Esko
>
>
>
>
> ________________________________
> The information contained in this message may be confidential and legally
> protected under applicable law. The message is intended solely for the
> addressee(s). If you are not the intended recipient, you are hereby notif=
ied
> 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 cop=
ies
> of the original message.
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>

From kovatsch@inf.ethz.ch  Mon Oct 21 09:50:35 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8648E11E85C8 for ; Mon, 21 Oct 2013 09:50:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.599
X-Spam-Level: 
X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fq-sVCBSnknr for ; Mon, 21 Oct 2013 09:50:29 -0700 (PDT)
Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) by ietfa.amsl.com (Postfix) with ESMTP id 44E3811E864A for ; Mon, 21 Oct 2013 09:50:01 -0700 (PDT)
Received: from CAS10.d.ethz.ch (172.31.38.210) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.2.298.4; Mon, 21 Oct 2013 18:49:56 +0200
Received: from MBX210.d.ethz.ch ([fe80::ed77:7d47:9467:69a9]) by CAS10.d.ethz.ch ([fe80::cce:fc66:7b56:a06a%10]) with mapi id 14.02.0298.004; Mon, 21 Oct 2013 18:49:56 +0200
From: "Kovatsch  Matthias" 
To: "core (core@ietf.org)" 
Thread-Topic: WGLC draft-ietf-core-observe-11: Token lifetime
Thread-Index: Ac7OeIxzKqmgUA+MQbqe7NP5P8AmQg==
Date: Mon, 21 Oct 2013 16:49:56 +0000
Message-ID: <55877B3AFB359744BA0F2140E36F52B515C07FBA@MBX210.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] WGLC draft-ietf-core-observe-11: Token lifetime
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 16:50:35 -0000

Dear list

With Observe, it becomes hard to decide when a Token can be re-used for a n=
ew request. The client extended the meaning of a Token to the server it sub=
scribes with. The server will continue to use this Token until it removes t=
he Observe relationship. Problem is, the client does not know when this wil=
l happen, since there is only garbage collection and no definite cancellati=
on. An off-line discussion with Klaus also indicated that the client cannot=
 expect the Token to be free again, when it RSTed a CON notification.

When a client is no longer interested in notifications, it can simply forge=
t about the Observe relationship. However, it must somehow store the Token =
in a list of wasted ones, it is not allowed to re-use. Do we need a sophist=
icated time-based mechanism like for MIDs? Or is there a good way to give t=
he full control of the Token back to the client?

A confirmed cancellation would also help with this issue...

Ciao
Matthias


From kovatsch@inf.ethz.ch  Mon Oct 21 09:50:43 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBF111E81ED for ; Mon, 21 Oct 2013 09:50:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.598
X-Spam-Level: 
X-Spam-Status: No, score=-7.598 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wv6xYvOdYTyP for ; Mon, 21 Oct 2013 09:50:36 -0700 (PDT)
Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) by ietfa.amsl.com (Postfix) with ESMTP id 1841711E8604 for ; Mon, 21 Oct 2013 09:50:06 -0700 (PDT)
Received: from CAS11.d.ethz.ch (172.31.38.211) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.2.298.4; Mon, 21 Oct 2013 18:50:05 +0200
Received: from MBX210.d.ethz.ch ([fe80::ed77:7d47:9467:69a9]) by CAS11.d.ethz.ch ([fe80::ecc9:4e2d:b26b:1614%10]) with mapi id 14.02.0298.004; Mon, 21 Oct 2013 18:50:05 +0200
From: "Kovatsch  Matthias" 
To: "core (core@ietf.org)" 
Thread-Topic: WGLC draft-ietf-core-observe-11: Re-registration and cacellation
Thread-Index: Ac7Oe+BdxvyuVz5ER1iHZstZM2OKXw==
Date: Mon, 21 Oct 2013 16:50:05 +0000
Message-ID: <55877B3AFB359744BA0F2140E36F52B515C07FC3@MBX210.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: multipart/alternative; boundary="_000_55877B3AFB359744BA0F2140E36F52B515C07FC3MBX210dethzch_"
MIME-Version: 1.0
Subject: [core] WGLC draft-ietf-core-observe-11: Re-registration and cacellation
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 16:50:43 -0000

--_000_55877B3AFB359744BA0F2140E36F52B515C07FC3MBX210dethzch_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear list

I was wondering what should happen, when a client sends a GET with the Toke=
n used in an Observe relationship (like for re-registration), but without t=
he Observe option. It is not disallowed AFAIK, so what should the server do=
? As I did not have any problem with the old cancellation via GET, I would =
now expect similar behavior.

I also see no point in constructing a new mechanism for cancellation that d=
oes not use GET. Observe was fully and transparently built on top of GET (i=
.e., no OBSERVE method or similar), so why not keep it this way? I think, i=
t would be interesting to discuss at least the options for a cancellation m=
echanism different from GET at this point.

Ciao
Matthias


--_000_55877B3AFB359744BA0F2140E36F52B515C07FC3MBX210dethzch_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Dear list


 


I was wondering what should happen, when a client se=
nds a GET with the Token used in an Observe relationship (like for re-regis=
tration), but without the Observe option. It is not disallowed AFAIK, so wh=
at should the server do? As I did
 not have any problem with the old cancellation via GET, I would now expect=
 similar behavior.


 


I also see no point in constructing a new mechanism =
for cancellation that does not use GET. Observe was fully and transparently=
 built on top of GET (i.e., no OBSERVE method or similar), so why not keep =
it this way? I think, it would be
 interesting to discuss at least the options for a cancellation mechanism d=
ifferent from GET at this point.


 


Ciao


Matthias


 






--_000_55877B3AFB359744BA0F2140E36F52B515C07FC3MBX210dethzch_--

From pab@pabigot.com  Mon Oct 21 10:02:53 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05DB11E81ED for ; Mon, 21 Oct 2013 10:02:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.466
X-Spam-Level: 
X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3+Gad8EuSKi for ; Mon, 21 Oct 2013 10:02:48 -0700 (PDT)
Received: from p3plsmtpa09-06.prod.phx3.secureserver.net (p3plsmtpa09-06.prod.phx3.secureserver.net [173.201.193.235]) by ietfa.amsl.com (Postfix) with ESMTP id 2D63B11E822F for ; Mon, 21 Oct 2013 10:02:34 -0700 (PDT)
Received: from [192.168.65.10] ([66.41.60.82]) by p3plsmtpa09-06.prod.phx3.secureserver.net with  id ft2V1m00C1mTNtu01t2Wcl; Mon, 21 Oct 2013 10:02:30 -0700
Message-ID: <52655E2A.7050501@pabigot.com>
Date: Mon, 21 Oct 2013 12:02:34 -0500
From: "Peter A. Bigot" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: core@ietf.org
References: <031DD135F9160444ABBE3B0C36CED6180171AFE5@011-DB3MPN2-083.MGDPHG.emi.philips.com> <55877B3AFB359744BA0F2140E36F52B515C07F27@MBX210.d.ethz.ch>
In-Reply-To: <55877B3AFB359744BA0F2140E36F52B515C07F27@MBX210.d.ethz.ch>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [core] WGLC draft-ietf-core-observe-11: support for pre-configured observers ?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 17:02:54 -0000

On 10/21/2013 11:12 AM, Kovatsch Matthias wrote:
> Dear Esko
>
> Do we need special support for that?

Only if a request is expected to be part of a REST transaction.

If not, this just works, and a CoAP transaction consists of zero or one 
requests to which there are zero or more (cf. observe) responses from 
one or more (cf. groupcomm) servers.  Each of these requests or 
responses is in turn comprised of one or more (cf. block) messages which 
themselves are requests and responses, where the responses are 
aggregated in some way to produce the overall response(s).

This would be a useful extension.

Peter


From tho@koanlogic.com  Mon Oct 21 11:17:31 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7B811E848C for ; Mon, 21 Oct 2013 11:17:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.677
X-Spam-Level: 
X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgdbwqvD1Ryf for ; Mon, 21 Oct 2013 11:17:25 -0700 (PDT)
Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) by ietfa.amsl.com (Postfix) with ESMTP id EAFD511E8483 for ; Mon, 21 Oct 2013 11:17:23 -0700 (PDT)
Received: by mail-lb0-f181.google.com with SMTP id x18so3861919lbi.26 for ; Mon, 21 Oct 2013 11:17:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ksy8pFhc1nr/gH86Ga1nHZEdat1NogsrBFXuQxKQKDk=; b=cXVAw6DgRyMWTF/I5qnTLK0oguMTqgY9pYNxCuarjLxYEFGXjNoOg9UQorwGAR81fv mhzVMvlLnO4YojdLartGf50YMcvFCGmNca1BecOTYttxlxUsso6BuNcPaiiBUPqT2EMb KGxwTbDlnvmVXEZXb2sk1sZZr8aJAfdm6t+WA0NW/wzqCXhZIWYorz3NX3ocqW8c0NbJ V9VjCxXy6ytLVboR0gPruOzHbkGwEwMt7KupY8cpbsIXINbY0aIB5eRa0e58o54DKQEE XNMLGU+UzIWvh1Hmtk3RWENPx1uDzWfKpPeJGWafOOALvpGiPTGbDyJL2aM7KOsRiP5k ZMaw==
X-Gm-Message-State: ALoCoQlIySpYxfj+67eR16KD5LeniQ/+a3IscS8RVwFvjFjRGjUWIDEmf2HlTsiOLeRoAEdIcXuu
MIME-Version: 1.0
X-Received: by 10.152.22.198 with SMTP id g6mr14553579laf.5.1382379442693; Mon, 21 Oct 2013 11:17:22 -0700 (PDT)
Received: by 10.114.21.4 with HTTP; Mon, 21 Oct 2013 11:17:22 -0700 (PDT)
X-Originating-IP: [92.20.243.57]
In-Reply-To: 
References: <031DD135F9160444ABBE3B0C36CED6180171AFE5@011-DB3MPN2-083.MGDPHG.emi.philips.com> 
Date: Mon, 21 Oct 2013 19:17:22 +0100
Message-ID: 
From: Thomas Fossati 
To: Klaus Hartke 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "core \(core@ietf.org\)" 
Subject: Re: [core] WGLC draft-ietf-core-observe-11: support for pre-configured observers ?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 18:17:31 -0000

On Mon, Oct 21, 2013 at 5:48 PM, Klaus Hartke  wrote:
> - IIRC, Zach had some use-case where he wanted to send notifications
> to a different node than the one registering.

Then what Esko proposes would be just a Server self-request with a
different observer than the registering node.

From Akbar.Rahman@InterDigital.com  Mon Oct 21 13:01:15 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83DEA11E8273 for ; Mon, 21 Oct 2013 13:01:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPY84PRBx-gP for ; Mon, 21 Oct 2013 13:01:10 -0700 (PDT)
Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 306F911E8761 for ; Mon, 21 Oct 2013 12:59:55 -0700 (PDT)
Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 21 Oct 2013 15:59:55 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 21 Oct 2013 15:59:53 -0400
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [core] Some initial comments on WGLC of draft-ietf-core-observe-11
Thread-Index: Ac7OdCxjLbkcQpIPRZK6TWxwfeQZ4wAI4CdQ
References: <5A6D74B4-3733-45D1-95B1-E838DADED234@tzi.org>      <2B9B48179856DC4FA00C93C79EB7E64A2DB33D@ESESSMB109.ericsson.se> 
From: "Rahman, Akbar" 
To: "Klaus Hartke" 
X-OriginalArrivalTime: 21 Oct 2013 19:59:55.0158 (UTC) FILETIME=[1CAA0B60:01CECE98]
Cc: core@ietf.org
Subject: Re: [core] Some initial comments on WGLC of draft-ietf-core-observe-11
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 20:01:15 -0000

Hi Klaus,

My vote would be to put it in draft-ietf-core-observe (following the
esteemed example of core-coap-18 which has about a dozen such
implementation notes).


Akbar=20

-----Original Message-----
From: Klaus Hartke [mailto:hartke@tzi.org]=20
Sent: Monday, October 21, 2013 11:41 AM
To: Salvatore Loreto
Cc: Rahman, Akbar; 
Subject: Re: [core] Some initial comments on WGLC of
draft-ietf-core-observe-11

Hi Salvatore, Akbar,

>> Requiring the server to remember the message IDs of non-confirmable=20
>> notifications needs some discussion, but it's doable as well if there

>> is enough support in the working group. I guess a constrained server=20
>> could always pretend that a Reset message in reply to a=20
>> non-confirmable notification was lost.
>>
>> AKBAR - CAN WE JUST PUT IT AS AN IMPLEMENTATION NOTE THEN (AS A=20
>> SUGGESTION)?
>
> [Salvatore] what if the server that receives a reset from a client for

> an non-confirmable notification just set itself to send all the next
notifications run to that client in a confirmable way?
> that should even easier to implement that remember the message ID of a

> non-confirmable notification

Sounds good. Are these implementation techniques something that should
be documented in draft-ietf-core-observe, or would perhaps a better
place be LWIG?

Best regards,
Klaus

From trac+core@trac.tools.ietf.org  Mon Oct 21 13:21:33 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D0311E81FF for ; Mon, 21 Oct 2013 13:21:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.53
X-Spam-Level: 
X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5DGbvVjJMno for ; Mon, 21 Oct 2013 13:21:33 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 63C1A11E81E1 for ; Mon, 21 Oct 2013 13:21:19 -0700 (PDT)
Received: from localhost ([127.0.0.1]:49373 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VYLyP-0008GE-81; Mon, 21 Oct 2013 22:21:09 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "core issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com
X-Trac-Project: core
Date: Mon, 21 Oct 2013 20:21:09 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/349#comment:1
Message-ID: <075.9731884734fdc1a0e6fe614411ba3491@trac.tools.ietf.org>
References: <060.a104169a666a18c3559ef8c1349b3868@trac.tools.ietf.org>
X-Trac-Ticket-ID: 349
In-Reply-To: <060.a104169a666a18c3559ef8c1349b3868@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: akbar.rahman@interdigital.com, angelo@castellani.net, esko.dijk@philips.com, salvatore.loreto@ericsson.com, tho@koanlogic.com
Resent-Message-Id: <20131021202119.63C1A11E81E1@ietfa.amsl.com>
Resent-Date: Mon, 21 Oct 2013 13:21:19 -0700 (PDT)
Resent-From: trac+core@trac.tools.ietf.org
Cc: core@ietf.org
Subject: Re: [core] #349: Can we use /.well-known/core for HTTP-CoAP mapping resource?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: trac+core@trac.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 20:21:33 -0000

#349: Can we use /.well-known/core for HTTP-CoAP mapping resource?


Comment (by esko.dijk@philips.com):

 Current proposal is to move the HC proxy resource (function set) out of
 the /.well-known space which is reserved for discovery purposes.
 We can show all examples in this I-D using the base HTTP resource:
 /hc
 where any implementers may use this same base URI or another one of
 choice.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-http-
  esko.dijk@philips.com  |  mapping@tools.ietf.org
     Type:  protocol     |      Status:  new
  defect                 |   Milestone:
 Priority:  major        |     Version:
Component:  http-        |  Resolution:
  mapping                |
 Severity:  -            |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
core 


From internet-drafts@ietf.org  Mon Oct 21 14:23:57 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D067411E8453; Mon, 21 Oct 2013 14:23:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.568
X-Spam-Level: 
X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1u-cWK-bCMY; Mon, 21 Oct 2013 14:23:57 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 197DF11E8416; Mon, 21 Oct 2013 14:23:57 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.80.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131021212357.32482.4556.idtracker@ietfa.amsl.com>
Date: Mon, 21 Oct 2013 14:23:57 -0700
Cc: core@ietf.org
Subject: [core] I-D Action: draft-ietf-core-block-14.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 21:23:57 -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           : Blockwise transfers in CoAP
	Author(s)       : Carsten Bormann
                          Zach Shelby
	Filename        : draft-ietf-core-block-14.txt
	Pages           : 31
	Date            : 2013-10-21

Abstract:
   CoAP is a RESTful transfer protocol for constrained nodes and
   networks.  Basic CoAP messages work well for the small payloads we
   expect from temperature sensors, light switches, and similar
   building-automation devices.  Occasionally, however, applications
   will need to transfer larger payloads -- for instance, for
   firmware updates.  With HTTP, TCP does the grunt work of slicing
   large payloads up into multiple packets and ensuring that they all
   arrive and are handled in the right order.

   CoAP is based on datagram transports such as UDP or DTLS, which
   limits the maximum size of resource representations that can be
   transferred without too much fragmentation.  Although UDP supports
   larger payloads through IP fragmentation, it is limited to 64 KiB
   and, more importantly, doesn't really work well for constrained
   applications and networks.

   Instead of relying on IP fragmentation, this specification extends
   basic CoAP with a pair of "Block" options, for transferring multiple
   blocks of information from a resource representation in multiple
   request-response pairs.  In many important cases, the Block options
   enable a server to be truly stateless: the server can handle each
   block transfer separately, with no need for a connection setup or
   other server-side memory of previous block transfers.

   In summary, the Block options provide a minimal way to transfer
   larger representations in a block-wise fashion.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-core-block

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-core-block-14

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-block-14


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From gerdes@tzi.de  Mon Oct 21 16:02:59 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE3F11E87AF for ; Mon, 21 Oct 2013 16:02:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7SVKKFVVUTq for ; Mon, 21 Oct 2013 16:02:54 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 86EA011E87A4 for ; Mon, 21 Oct 2013 16:02:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9LN2NBk007092 for ; Tue, 22 Oct 2013 01:02:23 +0200 (CEST)
Received: from [192.168.1.146] (p57A7C6F9.dip0.t-ipconnect.de [87.167.198.249]) (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 63B7FE95 for ; Tue, 22 Oct 2013 01:02:23 +0200 (CEST)
Message-ID: <5265B27E.3090001@tzi.de>
Date: Tue, 22 Oct 2013 01:02:22 +0200
From: Stefanie Gerdes 
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: "core@ietf.org" 
References: <20131021225132.32534.28140.idtracker@ietfa.amsl.com>
In-Reply-To: <20131021225132.32534.28140.idtracker@ietfa.amsl.com>
X-Enigmail-Version: 1.5.2
X-Forwarded-Message-Id: <20131021225132.32534.28140.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [core] Fwd: I-D Action: draft-gerdes-core-dcaf-authorize-01.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 23:02:59 -0000

Dear all,

we have submitted a new version of DCAF. The main changes are some
clarifications and introduction of implicit authorization. Comments are
welcome.

Best regards,
Steffi


-------- Original Message --------
Subject: I-D Action: draft-gerdes-core-dcaf-authorize-01.txt
Date: Mon, 21 Oct 2013 15:51:32 -0700
From: internet-drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title           : Delegated CoAP Authentication and Authorization
Framework (DCAF)
	Author(s)       : Stefanie Gerdes
                          Olaf Bergmann
                          Carsten Bormann
	Filename        : draft-gerdes-core-dcaf-authorize-01.txt
	Pages           : 36
	Date            : 2013-10-21

Abstract:
   This specification defines a protocol for delegating client
   authentication and authorization in a constrained environment for
   establishing a Datagram Transport Layer Security (DTLS) channel
   between resource-constrained nodes.  The protocol relies on DTLS to
   transfer authorization information and shared secrets for symmetric
   cryptography between entities in a constrained network.  A resource-
   constrained node can use this protocol to delegate authentication of
   communication peers and management of authorization information to a
   trusted host with less severe limitations regarding processing power
   and memory.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-gerdes-core-dcaf-authorize

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-gerdes-core-dcaf-authorize-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-gerdes-core-dcaf-authorize-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/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt




From bilhanan.silverajan@tut.fi  Mon Oct 21 23:12:31 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1516511E8174 for ; Mon, 21 Oct 2013 23:12:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.98
X-Spam-Level: 
X-Spam-Status: No, score=-5.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIulOoCyRbuM for ; Mon, 21 Oct 2013 23:12:26 -0700 (PDT)
Received: from mail.cs.tut.fi (mail.cs.tut.fi [130.230.4.42]) by ietfa.amsl.com (Postfix) with SMTP id 0DE5111E815B for ; Mon, 21 Oct 2013 23:12:18 -0700 (PDT)
Received: from amavis2.cs.tut.fi (amavis2.cs.tut.fi [130.230.4.70]) by mail.cs.tut.fi (Postfix) with ESMTP id 30B1593 for ; Tue, 22 Oct 2013 09:12:17 +0300 (EEST)
Received: from mail.cs.tut.fi ([130.230.4.42]) by amavis2.cs.tut.fi (amavis2.cs.tut.fi [130.230.4.70]) (amavisd-maia, port 10024) with ESMTP id 06224-45 for ; Tue, 22 Oct 2013 09:12:16 +0300 (EEST)
Received: from [192.168.252.241] (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 6A9A591 for ; Tue, 22 Oct 2013 09:12:16 +0300 (EEST)
Message-ID: <5266173F.8050707@tut.fi>
Date: Tue, 22 Oct 2013 09:12:15 +0300
From: Bill Silverajan 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: core@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Maia Mailguard 1.0.2
Subject: [core] New Version: CoAP with Alternative Transports
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Oct 2013 06:12:31 -0000

Good morning,

We uploaded a new version of 
draft-silverajan-core-coap-alternative-transports that's retrievable from:

http://datatracker.ietf.org/doc/draft-silverajan-core-coap-alternative-transports/

Since the discussions which arose at the Berlin meeting, the most 
significant changes made to the document have been outlining the various 
ways that CoAP URIs can express alternative transport information and 
identifiers.

These are described in Sections 2.1 to 2.3, and each URI format has its 
own benefits and drawbacks.

The aim is to present these and proceed to eliminate all but one format. 
This then forms the basis for the URIs in the alternate transport drafts 
(WebSockets, SMS, TCP, and others in future).

Any and all comments are more than welcome, thanks.

Regards,
Bill

-- 
| Bilhanan Silverajan                       Tel: +358 (0)40 849 0757  |
| Tampere University of Technology, Finland                           |

From mehmet.ersue@nsn.com  Tue Oct 22 00:26:54 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F3E11E8327; Tue, 22 Oct 2013 00:26:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.165
X-Spam-Level: 
X-Spam-Status: No, score=-106.165 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUaTdeotcy9c; Tue, 22 Oct 2013 00:26:50 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 97B7A11E8355; Tue, 22 Oct 2013 00:26:49 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r9M7Qlnl001188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 22 Oct 2013 09:26:47 +0200
Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r9M7Qlw0020432 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Oct 2013 09:26:47 +0200
Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 22 Oct 2013 09:26:47 +0200
Received: from DEMUMBX005.nsn-intra.net ([169.254.5.164]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0123.003; Tue, 22 Oct 2013 09:26:46 +0200
From: "Ersue, Mehmet (NSN - DE/Munich)" 
To: "coman@ietf.org" , "lwip@ietf.org" , "core@ietf.org" , "6lo@ietf.org" <6lo@ietf.org>
Thread-Topic: draft-opsawg-ersue-coman-*-00
Thread-Index: Ac7OlqYtF57/mMmbQ2uDVQpY5NHw2QAWxt+g
Date: Tue, 22 Oct 2013 07:26:46 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.99]
Content-Type: multipart/mixed; boundary="_005_E4DE949E6CE3E34993A2FF8AE79131F81CFF9DDEMUMBX005nsnintr_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 20160
X-purgate-ID: 151667::1382426807-00004A43-A310E959/0-0/0-0
Subject: [core] FW: draft-opsawg-ersue-coman-*-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Oct 2013 07:26:54 -0000

--_005_E4DE949E6CE3E34993A2FF8AE79131F81CFF9DDEMUMBX005nsnintr_
Content-Type: multipart/alternative;
	boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F81CFF9DDEMUMBX005nsnintr_"

--_000_E4DE949E6CE3E34993A2FF8AE79131F81CFF9DDEMUMBX005nsnintr_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

FYI

Mehmet

From: ext Ersue, Mehmet (NSN - DE/Munich) [mailto:mehmet.ersue@nsn.com]
Sent: Monday, October 21, 2013 9:49 PM
To: opsawg@ietf.org
Cc: ops-chairs@tools.ietf.org
Subject: draft-opsawg-ersue-coman-*-00

Hi All,

we submitted following two drafts by dividing the original Coman draft draf=
t-ersue-constrained-mgmt-03 into two parts:

Filename:        draft-opsawg-ersue-coman-probstate-reqs
Title:           Management of Networks with Constrained Devices: Problem S=
tatement and Requirements
Htmlized:        http://tools.ietf.org/html/draft-opsawg-ersue-coman-probst=
ate-reqs-00

Filename:        draft-opsawg-ersue-coman-use-cases
Title:           Management of Networks with Constrained Devices: Use Cases
Htmlized:       http://tools.ietf.org/html/draft-opsawg-ersue-coman-use-cas=
es-00

We also asked OPSAWG chairs for a time slot to introduce the drafts and dis=
cuss issues.

We would appreciate your comments and a discussion on these drafts.
Please send your comments to the OPSAWG maillist.

Regards,
Mehmet




--_000_E4DE949E6CE3E34993A2FF8AE79131F81CFF9DDEMUMBX005nsnintr_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











FYI


 




Mehmet





 






From: ext Ersu=
e, Mehmet (NSN - DE/Munich) [mailto:mehmet.ersue@nsn.com]


Sent: Monday, October 21, 2013 9:49 PM

To: opsawg@ietf.org

Cc: ops-chairs@tools.ietf.org

Subject: draft-opsawg-ersue-coman-*-00






 




Hi All,






 






we submitted following two drafts by di=
viding the original Coman draft
draft-ersue-constrained-mgm=
t-03 into two parts:






 






Filename:     =
   draft-opsawg-ersue-coman-probstate-reqs






Title:     &nb=
sp;     Management of Networks with Constrained Devices=
: Problem Statement and Requirements







 






Filename:     =
   draft-opsawg-ersue-coman-use-cases






Title:     &nb=
sp;     Management of Networks with Constrained Devices=
: Use Cases







 






We also asked OPSAWG chairs for a time =
slot to introduce the drafts and discuss issues.






 






We would appreciate your comments and a=
 discussion on these drafts.






Please send your comments to the OPSAWG=
 maillist.






 






Regards,


Mehmet







 






 






 








--_000_E4DE949E6CE3E34993A2FF8AE79131F81CFF9DDEMUMBX005nsnintr_--

--_005_E4DE949E6CE3E34993A2FF8AE79131F81CFF9DDEMUMBX005nsnintr_
Content-Type: message/rfc822
Content-Disposition: attachment;
	creation-date="Mon, 21 Oct 2013 19:49:27 GMT";
	modification-date="Mon, 21 Oct 2013 19:49:27 GMT"
Content-ID: 

Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by
 DEMUHTC007.nsn-intra.net (10.159.42.38) with Microsoft SMTP Server (TLS) id
 14.3.123.3; Mon, 21 Oct 2013 20:54:17 +0200
Received: from demuprx016.emea.nsn-intra.net (10.159.42.124) by
 DEMUHTC006.nsn-intra.net (10.159.42.37) with Microsoft SMTP Server (TLS) id
 14.3.123.3; Mon, 21 Oct 2013 20:54:16 +0200
Received: from mumrelp001.nsn-inter.net (mumrelp001.nsn-inter.net
 [93.183.13.135])	by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11)
 with ESMTP id r9LIsGLt013181	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA
 bits=256 verify=OK)	for ; Mon, 21 Oct 2013 20:54:16
 +0200
Received: from mail.ietf.org (mail.ietf.org [12.22.58.30])	by
 mumrelp001.nsn-inter.net (8.13.8/8.13.8) with ESMTP id r9LIsGtO015396	for
 ; Mon, 21 Oct 2013 20:54:16 +0200
Received: from localhost (localhost [127.0.0.1])	by ietfa.amsl.com (Postfix)
 with ESMTP id 85EAB11E8238;	Mon, 21 Oct 2013 11:54:15 -0700 (PDT)
Received: from mail.ietf.org ([12.22.58.30])	by localhost (ietfa.amsl.com
 [127.0.0.1]) (amavisd-new, port 10024)	with ESMTP id dF1g3msh2mBQ; Mon, 21
 Oct 2013 11:54:13 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1])	by ietfa.amsl.com
 (Postfix) with ESMTP id E9DFD11E840D;	Mon, 21 Oct 2013 11:54:08 -0700 (PDT)
From: "ext internet-drafts@ietf.org" 
To: Dan Romascanu , Juergen Schoenwaelder
	, "Ersue, Mehmet (NSN - DE/Munich)"
	
Subject: New Version Notification for
	draft-opsawg-ersue-coman-probstate-reqs-00.txt
Thread-Topic: New Version Notification for
	draft-opsawg-ersue-coman-probstate-reqs-00.txt
Thread-Index: AQHOzo7xgMDHISK6VE++bt9ABi2s3Q==
Date: Mon, 21 Oct 2013 18:54:08 +0000
Message-ID: <20131021185408.32548.16277.idtracker@ietfa.amsl.com>
Content-Language: en-US
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-AuthSource: DEMUHTC006.nsn-intra.net
X-MS-Has-Attach: 
X-Auto-Response-Suppress: All
X-MS-TNEF-Correlator: 
x-purgate-id: 151667::1382381656-00005789-530842F7/0-0/0-0
x-purgate-ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
x-purgate: This mail is considered clean (visit http://www.eleven.de for
 further information)
x-purgate-size: 1175
x-purgate-type: clean
x-virus-scanned: amavisd-new at amsl.com
auto-submitted: auto-generated
x-scanned-by: MIMEDefang 2.71 on 93.183.13.135
Content-Type: text/plain; charset="utf-8"
Content-ID: <3F5AC62326FFE44697C3BD694A3B2368@internal.nsn.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0

DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtb3BzYXdnLWVyc3VlLWNvbWFuLXByb2JzdGF0
ZS1yZXFzLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBNZWhtZXQg
RXJzdWUgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6ICAg
ICAgICBkcmFmdC1vcHNhd2ctZXJzdWUtY29tYW4tcHJvYnN0YXRlLXJlcXMNClJldmlzaW9uOiAg
ICAgICAgMDANClRpdGxlOiAgICAgICAgICAgTWFuYWdlbWVudCBvZiBOZXR3b3JrcyB3aXRoIENv
bnN0cmFpbmVkIERldmljZXM6IFByb2JsZW0gU3RhdGVtZW50IGFuZCBSZXF1aXJlbWVudHMNCkNy
ZWF0aW9uIGRhdGU6ICAgMjAxMy0xMC0yMQ0KR3JvdXA6ICAgICAgICAgICBJbmRpdmlkdWFsIFN1
Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogNTYNClVSTDogICAgICAgICAgICAgaHR0cDovL3d3
dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtb3BzYXdnLWVyc3VlLWNvbWFuLXByb2Jz
dGF0ZS1yZXFzLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0
Zi5vcmcvZG9jL2RyYWZ0LW9wc2F3Zy1lcnN1ZS1jb21hbi1wcm9ic3RhdGUtcmVxcw0KSHRtbGl6
ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1vcHNhd2ctZXJzdWUt
Y29tYW4tcHJvYnN0YXRlLXJlcXMtMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQg
cHJvdmlkZXMgYSBwcm9ibGVtIHN0YXRlbWVudCwgZGVwbG95bWVudCBhbmQgbWFuYWdlbWVudA0K
ICAgdG9wb2xvZ3kgb3B0aW9ucyBhcyB3ZWxsIGFzIHRoZSByZXF1aXJlbWVudHMgZm9yIHRoZSBt
YW5hZ2VtZW50IG9mDQogICBuZXR3b3JrcyB3aGVyZSBjb25zdHJhaW5lZCBkZXZpY2VzIGFyZSBp
bnZvbHZlZC4NCg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBv
ZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVk
IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhl
IElFVEYgU2VjcmV0YXJpYXQNCg0K

--_005_E4DE949E6CE3E34993A2FF8AE79131F81CFF9DDEMUMBX005nsnintr_
Content-Type: message/rfc822
Content-Disposition: attachment;
	creation-date="Mon, 21 Oct 2013 19:49:28 GMT";
	modification-date="Mon, 21 Oct 2013 19:49:28 GMT"
Content-ID: <5BB3535A3401FE4D9F71C9FF967FB1E9@internal.nsn.com>

Received: from DEMUHTC010.nsn-intra.net (10.159.42.41) by
 DEMUHTC007.nsn-intra.net (10.159.42.38) with Microsoft SMTP Server (TLS) id
 14.3.123.3; Mon, 21 Oct 2013 20:55:41 +0200
Received: from demuprx017.emea.nsn-intra.net (10.159.42.97) by
 DEMUHTC010.nsn-intra.net (10.159.42.41) with Microsoft SMTP Server (TLS) id
 14.3.123.3; Mon, 21 Oct 2013 20:55:41 +0200
Received: from demumfd002.nsn-inter.net (DEMUMFD002 [93.183.12.31])	by
 demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id
 r9LItfsZ005813	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256
 verify=OK)	for ; Mon, 21 Oct 2013 20:55:41 +0200
Received: from mail.ietf.org (mail.ietf.org [12.22.58.30])	by
 demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id
 r9LIteO0003660	for ; Mon, 21 Oct 2013 20:55:40 +0200
Received: from localhost (localhost [127.0.0.1])	by ietfa.amsl.com (Postfix)
 with ESMTP id 0974D11E861C;	Mon, 21 Oct 2013 11:55:40 -0700 (PDT)
Received: from mail.ietf.org ([12.22.58.30])	by localhost (ietfa.amsl.com
 [127.0.0.1]) (amavisd-new, port 10024)	with ESMTP id wovqHH-a08U9; Mon, 21
 Oct 2013 11:55:39 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1])	by ietfa.amsl.com
 (Postfix) with ESMTP id 2DD7F11E856E;	Mon, 21 Oct 2013 11:55:10 -0700 (PDT)
From: "ext internet-drafts@ietf.org" 
To: Dan Romascanu , Juergen Schoenwaelder
	, "Ersue, Mehmet (NSN - DE/Munich)"
	
Subject: New Version Notification for
 draft-opsawg-ersue-coman-use-cases-00.txt
Thread-Topic: New Version Notification for
 draft-opsawg-ersue-coman-use-cases-00.txt
Thread-Index: AQHOzo8jFGmhc5H0FkCR10dedIYG3Q==
Date: Mon, 21 Oct 2013 18:55:10 +0000
Message-ID: <20131021185510.32482.68231.idtracker@ietfa.amsl.com>
Content-Language: en-US
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-AuthSource: DEMUHTC010.nsn-intra.net
X-MS-Has-Attach: 
X-Auto-Response-Suppress: All
X-MS-TNEF-Correlator: 
x-purgate-id: 151667::1382381741-00005753-F1DC8E4D/0-0/0-0
x-purgate-ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
x-purgate: This mail is considered clean (visit http://www.eleven.de for
 further information)
x-purgate-size: 1215
x-purgate-type: clean
x-virus-scanned: amavisd-new at amsl.com
auto-submitted: auto-generated
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0

DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtb3BzYXdnLWVyc3VlLWNvbWFuLXVzZS1jYXNl
cy0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTWVobWV0IEVyc3Vl
IGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOiAgICAgICAg
ZHJhZnQtb3BzYXdnLWVyc3VlLWNvbWFuLXVzZS1jYXNlcw0KUmV2aXNpb246ICAgICAgICAwMA0K
VGl0bGU6ICAgICAgICAgICBNYW5hZ2VtZW50IG9mIE5ldHdvcmtzIHdpdGggQ29uc3RyYWluZWQg
RGV2aWNlczogVXNlIENhc2VzDQpDcmVhdGlvbiBkYXRlOiAgIDIwMTMtMTAtMjENCkdyb3VwOiAg
ICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDMzDQpVUkw6
ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW9w
c2F3Zy1lcnN1ZS1jb21hbi11c2UtY2FzZXMtMDAudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6
Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtb3BzYXdnLWVyc3VlLWNvbWFuLXVzZS1j
YXNlcw0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1v
cHNhd2ctZXJzdWUtY29tYW4tdXNlLWNhc2VzLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRv
Y3VtZW50IGRpc2N1c3NlcyB0aGUgdXNlIGNhc2VzIGNvbmNlcm5pbmcgdGhlIG1hbmFnZW1lbnQg
b2YNCiAgIG5ldHdvcmtzLCB3aGVyZSBjb25zdHJhaW5lZCBkZXZpY2VzIGFyZSBpbnZvbHZlZC4g
IEEgcHJvYmxlbQ0KICAgc3RhdGVtZW50LCBkZXBsb3ltZW50IG9wdGlvbnMgYW5kIHRoZSByZXF1
aXJlbWVudHMgb24gdGhlIG5ldHdvcmtzDQogICB3aXRoIGNvbnN0cmFpbmVkIGRldmljZXMgY2Fu
IGJlIGZvdW5kIGluIHRoZSBjb21wYW5pb24gZG9jdW1lbnQgW0NPTS0NCiAgIFJFUV0uDQoNCg0K
DQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9t
IHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBk
aWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFy
aWF0DQoNCg==

--_005_E4DE949E6CE3E34993A2FF8AE79131F81CFF9DDEMUMBX005nsnintr_--

From Akbar.Rahman@InterDigital.com  Tue Oct 22 11:05:17 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E0311E819C for ; Tue, 22 Oct 2013 11:05:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zn-YfwQfluYz for ; Tue, 22 Oct 2013 11:05:12 -0700 (PDT)
Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id AAD9611E810C for ; Tue, 22 Oct 2013 11:04:26 -0700 (PDT)
Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 22 Oct 2013 13:58:04 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CECF50.4155380A"
Date: Tue, 22 Oct 2013 13:58:02 -0400
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Question on draft-fossati-core-publish-option-02
Thread-Index: Ac7PUECHeBPc9DGrS9u1bsfuFq4DmA==
From: "Rahman, Akbar" 
To: "Thomas Fossati" 
X-OriginalArrivalTime: 22 Oct 2013 17:58:04.0780 (UTC) FILETIME=[41C0A2C0:01CECF50]
Cc: core@ietf.org
Subject: [core] Question on draft-fossati-core-publish-option-02
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Oct 2013 18:05:17 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CECF50.4155380A
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Thomas,

=20

=20

Thanks for your interesting draft
(http://tools.ietf.org/html/draft-fossati-core-publish-option-02).  I
have one fundamental question.  How is a client directed synchronously
to go towards the delegated Endpoint?  In other words, suppose a client
had a priori (e.g. at provisioning or startup) obtained the URI of the
SEP for the resource that it was interested in.  Your I-D is very clear
on how the SEP can delegate a resource to a delegated Endpoint.  But how
would the client, in a synchronous manner, know that the resource is no
longer at the SEP but to go instead to the delegated Endpoint? =20

=20

=20

(I did see your Section 3, Discovery, but this to me seemed to be
somehow a specific use case and not a general approach.  Apologies if I
missed something obvious.)

=20

=20

=20

Best Regards,

=20

=20

Akbar

=20

=20

=20


------_=_NextPart_001_01CECF50.4155380A
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi =
Thomas,
 
 
Thanks for =
your interesting draft (=
http://tools.ietf.org/html/draft-fossati-core-publish-option-02).&nbs=
p; I have one fundamental question.  How is a client directed =
synchronously to go towards the delegated Endpoint?  In other =
words, suppose a client had a priori (e.g. at provisioning or startup) =
obtained the URI of the SEP for the resource that it was interested =
in.  Your I-D is very clear on how the SEP can delegate a resource =
to a delegated Endpoint.  But how would the client, in a =
synchronous manner, know that the resource is no longer at the SEP but =
to go instead to the delegated Endpoint?  
 
 
(I did see =
your Section 3, Discovery, but this to me seemed to be somehow a =
specific use case and not a general approach.  Apologies if I =
missed something obvious.)
 
 
 
Best =
Regards,
 
 
Akbar
 
 
 

------_=_NextPart_001_01CECF50.4155380A--

From trac+core@trac.tools.ietf.org  Tue Oct 22 13:30:54 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A62A11E8122 for ; Tue, 22 Oct 2013 13:30:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.533
X-Spam-Level: 
X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkF0vgqmbHfx for ; Tue, 22 Oct 2013 13:30:50 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 107F211E822E for ; Tue, 22 Oct 2013 13:30:49 -0700 (PDT)
Received: from localhost ([127.0.0.1]:41088 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VYibI-0006jv-OD; Tue, 22 Oct 2013 22:30:48 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "core issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-core-observe@tools.ietf.org, hartke@tzi.org
X-Trac-Project: core
Date: Tue, 22 Oct 2013 20:30:48 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/353
Message-ID: <053.6289ad1c79b4f5eb01d1331c40ff098f@trac.tools.ietf.org>
X-Trac-Ticket-ID: 353
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-core-observe@tools.ietf.org, hartke@tzi.org, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: hartke@tzi.org
Resent-Message-Id: <20131022203050.107F211E822E@ietfa.amsl.com>
Resent-Date: Tue, 22 Oct 2013 13:30:49 -0700 (PDT)
Resent-From: trac+core@trac.tools.ietf.org
Cc: core@ietf.org
Subject: [core]  #353: Simplify Reset Handling text
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: trac+core@trac.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Oct 2013 20:30:54 -0000

#353: Simplify Reset Handling text

 The current text in Section 4.5 says:

   If a client rejects a confirmable notification with a
   Reset message, the client is no longer interested and the server MUST
   remove the associated entry from the list of observers.  If the
   client rejects a non-confirmable notification, the server MAY remove
   the entry from the list of observers as well.  (It is expected that
   the server does remove the entry if it has the information available
   that is needed to match the Reset message to the non-confirmable
   notification, but the server is not required to keep this
   information.)

 The text can be simplified a bit by turning the "MAY" into a "MUST" (which
 allows to remove the distinction between confirmable and non-confirmable,
 and to remove the text in parentheses). An implementation note should then
 be added as follows:

 - Implementing this means that a server needs to remember the message IDs
 of non-confirmable messages.
 - However, a constrained server could always pretend that a Reset message
 in reply to a non-confirmable notification was lost.
 - If a server does this, the server should set itself to send all
 following notifications to that client in confirmable messages.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-core-
  hartke@tzi.org         |  observe@tools.ietf.org
     Type:  editorial    |     Status:  new
 Priority:  minor        |  Milestone:  post-WGLC-2
Component:  observe      |    Version:  observe-11
 Severity:  In WG Last   |   Keywords:
  Call                   |
-------------------------+-------------------------------------------------

Ticket URL: 
core 


From tho@koanlogic.com  Tue Oct 22 13:59:10 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2468011E81EB for ; Tue, 22 Oct 2013 13:59:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdWMYhFg37+E for ; Tue, 22 Oct 2013 13:59:04 -0700 (PDT)
Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5CC11E81F2 for ; Tue, 22 Oct 2013 13:59:01 -0700 (PDT)
Received: by mail-la0-f54.google.com with SMTP id gx14so3324278lab.41 for ; Tue, 22 Oct 2013 13:59:00 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=n3W6QIC45EAXy7hOCKAd51vmZuOlx6NngexIyj/LXXo=; b=jKcoy+d5KMVqso6WCvbNiYk6BBUCu845Pw+xnmnr2xmnk1wIVMbcdSNJokrZ0CUrTs afvA05+tjygyzcwMChX/u9L306oK0Yvzlumnau1YY7jEKaBg1kv0HY/Pvem6oObPlm9x P5QEk5SYP6MLhEx4YJXNjcIxQztICTk78Xc2Nt9T38ymR4MqPknBKoGkBQGZw922ug0j 9VY2M/QDYYQQ4VuUmROwRu6aEx5M0mzO4H5Bh5yXtv+MK23n4PPVJw3xC/Bdoq7pJpt3 UHILVVno7c82O2pjBbeZKAd3sus5h7OEBWwTUU/81qVydEI8e7Gi4lcQhU98m3svmWlT fa9w==
X-Gm-Message-State: ALoCoQkjYNTuvtLooOdzZBi3n+FzE4wSmaR414A8jCQQsEKRrkAtcszVsxXGMiW/8YFNosj+HVtX
MIME-Version: 1.0
X-Received: by 10.112.136.195 with SMTP id qc3mr129935lbb.55.1382475540213; Tue, 22 Oct 2013 13:59:00 -0700 (PDT)
Received: by 10.114.21.4 with HTTP; Tue, 22 Oct 2013 13:59:00 -0700 (PDT)
X-Originating-IP: [89.243.219.188]
In-Reply-To: 
References: 
Date: Tue, 22 Oct 2013 21:59:00 +0100
Message-ID: 
From: Thomas Fossati 
To: "Rahman, Akbar" 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "core@ietf.org" 
Subject: Re: [core] Question on draft-fossati-core-publish-option-02
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Oct 2013 20:59:10 -0000

Thank you Akbar for taking the time to review it.

As far as your question:

On Tue, Oct 22, 2013 at 6:58 PM, Rahman, Akbar
 wrote:
> How is a client directed synchronously to go
> towards the delegated Endpoint?  In other words, suppose a client had a
> priori (e.g. at provisioning or startup) obtained the URI of the SEP for the
> resource that it was interested in.

This is a great example, and one which we've not documented in the
current I-D but should have been (next round!).

In this case, I would expect the client doing an href query to the
(multicast) /.well-known/core interface:

REQ: GET /.well-known/core?href=coap://sleepy.example.org/res

and get the following response back from the delegated Proxy (or from
another endpoint who happens to have this information):

RES: 2.05 Content
;
  anchor="coap://proxy.example.org/";
  rel="proxies"

which tells the client that coap://proxy.example.org "proxies" the
requested resource, so that it can then issue its Proxy-URI request
for that resource to said proxy.

> Your I-D is very clear on how the SEP
> can delegate a resource to a delegated Endpoint.  But how would the client,
> in a synchronous manner, know that the resource is no longer at the SEP but
> to go instead to the delegated Endpoint?

I hope my previous example is clear enough.  If you are not satisfied,
please shout :-)

> (I did see your Section 3, Discovery, but this to me seemed to be somehow a
> specific use case and not a general approach.  Apologies if I missed
> something obvious.)

Well, the intention is to make it a general approach, it should not
look like an ad hoc solution :-)

We set an explicit design constraint to reuse the discovery model of
RFC6690 as much as possible -- in line with our aim at providing a
fully "in-protocol" solution to the sleepy problem.
To make RFC6690 a building block that also supports the
sleepy/intermittent scenario, we had to bring in the "proxies" link
relation, that works around some semantic and syntactic limitation of
the "hosts" relation.  Using this new thing, the proxy not only hands
off packets around, but also participates into discovery, by
advertising resources that may be "hidden" to the other side of a CoAP
network.

Cheers

From trac+core@trac.tools.ietf.org  Tue Oct 22 22:49:47 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549FA11E82E3 for ; Tue, 22 Oct 2013 22:49:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.536
X-Spam-Level: 
X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCCAXwa24oLR for ; Tue, 22 Oct 2013 22:49:46 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id B669C11E8149 for ; Tue, 22 Oct 2013 22:49:45 -0700 (PDT)
Received: from localhost ([127.0.0.1]:60743 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VYrK9-0006u6-Bl; Wed, 23 Oct 2013 07:49:41 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "core issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com
X-Trac-Project: core
Date: Wed, 23 Oct 2013 05:49:41 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/354
Message-ID: <060.28d199cdef36507776dfc929478c735c@trac.tools.ietf.org>
X-Trac-Ticket-ID: 354
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com
Resent-Message-Id: <20131023054946.B669C11E8149@ietfa.amsl.com>
Resent-Date: Tue, 22 Oct 2013 22:49:45 -0700 (PDT)
Resent-From: trac+core@trac.tools.ietf.org
Cc: core@ietf.org
Subject: [core] #354: Group configuration API should enable deletion of individual group memberships
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: trac+core@trac.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Oct 2013 05:49:47 -0000

#354: Group configuration API should enable deletion of individual group
memberships

 Review input from Peter, Carsten and others was that preferably the group
 configuration API in section 2.6.2 should enable deletion of individual
 group memberships. This allows configuration and reconfiguration of a CoAP
 server by potentially multiple configuring endpoints (e.g. a commissioning
 tool and a back-end application).

 To accomplish this, some changes are needed in the defined media type
 "application/coap-group+json" and also in the REST interaction with the
 group configuration resource.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-core-
  esko.dijk@philips.com  |  groupcomm@tools.ietf.org
     Type:  protocol     |     Status:  new
  enhancement            |  Milestone:
 Priority:  major        |    Version:
Component:  groupcomm    |   Keywords:
 Severity:  -            |
-------------------------+-------------------------------------------------

Ticket URL: 
core 


From trac+core@trac.tools.ietf.org  Tue Oct 22 22:53:51 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 958C911E813B for ; Tue, 22 Oct 2013 22:53:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.389
X-Spam-Level: 
X-Spam-Status: No, score=-101.389 tagged_above=-999 required=5 tests=[AWL=-1.090, BAYES_00=-2.599, MANGLED_NAIL=2.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ine8giT80b4 for ; Tue, 22 Oct 2013 22:53:51 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5E111E82ED for ; Tue, 22 Oct 2013 22:53:49 -0700 (PDT)
Received: from localhost ([127.0.0.1]:33117 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VYrO6-0007KC-Rd; Wed, 23 Oct 2013 07:53:46 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "core issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com
X-Trac-Project: core
Date: Wed, 23 Oct 2013 05:53:46 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/354#comment:1
Message-ID: <075.8e1a8c831d8c71bcf0f8b706204c4d30@trac.tools.ietf.org>
References: <060.28d199cdef36507776dfc929478c735c@trac.tools.ietf.org>
X-Trac-Ticket-ID: 354
In-Reply-To: <060.28d199cdef36507776dfc929478c735c@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com
Resent-Message-Id: <20131023055350.2E5E111E82ED@ietfa.amsl.com>
Resent-Date: Tue, 22 Oct 2013 22:53:49 -0700 (PDT)
Resent-From: trac+core@trac.tools.ietf.org
Cc: core@ietf.org
Subject: Re: [core] #354: Group configuration API should enable deletion of individual group memberships
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: trac+core@trac.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Oct 2013 05:53:51 -0000

#354: Group configuration API should enable deletion of individual group
memberships


Comment (by esko.dijk@philips.com):

 A sketch of a possible solution is defined below.

 == General ==
 All below interactions:  Configuring CoAP client -> CoAP server to be
 configured with group membership

 == Creating a new multicast group membership on CoAP server ==
    Method:  POST
    URI Template:  /{+gp}
    URI Template Variables:
          gp - Group Configuration Function Set path (mandatory).  This is
 the path of
          the Group Configuration Function Set.  A server SHOULD use the
 value "coap-group"
          for this variable whenever possible.

 Example:
 Req: POST /coap-group (Content-Format: application/coap-group+json)
 { "n": "All-Devices.floor1.west.bldg6.example.com","a":
 "[ff15::4200:f7fe:ed37:abcd]:4567" }
 Res: 2.01 Created   Location: /coap-group/12

 The returned Location-URI is of format /{+gp}/{index} where 'index' SHOULD
 be a string of
 1 or 2 alphanumerical characters.

 == Deletion of specific group membership ==
    Method:  DELETE
    URI Template:  /{+location}
    URI Template Variables:
          location - This is the Location path returned by the CoAP server
 as a result of a
          successful registration.

 Example:
 Req: DELETE /coap-group/12
 Res: 2.02 Deleted

 == Reading a specific group membership ==
    Method:  GET
    URI Template 1:  /{+location}
    URI Template 2:  /{+gp}/{index}
    URI Template Variables:
          location - This is the Location path returned by the CoAP server
 as a result of a
          successful group creation.
          index - This is the group index which can be retrieved from the
 JSON payload when doing
           a GET /coap-group (see below 'Reading all group memberships')

 Example:
 Req: GET /coap-group/12
 Res: 2.05 Content (Content-Format: application/coap-group+json)
 {"n":"All-
 Devices.floor1.west.bldg6.example.com","a":"[ff15::4200:f7fe:ed37:abcd]:4567"}

 == Reading all group memberships ==
 Each group is assigned an index which is used as a JSON key for the group
 membership object.
 Example:
 Req: GET /coap-group
 Res: 2.05 Content (Content-Format: application/coap-group+json)
    { "8":{ "a": "[ff15::4200:f7fe:ed37:14ca]" },
      "11":{ "n": "floor1.west.bldg6.example.com","a":
 "[ff15::4200:f7fe:ed37:25cb]" },
      "12":{ "n": "All-Devices.floor1.west.bldg6.example.com","a":
 "[ff15::4200:f7fe:ed37:abcd]:4567" }
    }

 Note: the returned IPv6 address may be a different string from the one
 originally submitted, due to different choices in IPv6 string
 representation formatting that may be allowed for the same address.

 == Updating a specific group membership ==
         Method: PUT
         URI Template 1: /{+location}
         URI Template 2: /{+gp}/{index}

 Example - name and port change
 Req: PUT /coap-group/12
 {"n":"All-My-
 Devices.floor1.west.bldg6.example.com","a":"[ff15::4200:f7fe:ed37:abcd]"}
 Res: 2.04 Changed

 == Writing (and replacing) all group memberships in one operation ==
         Method: PUT
         URI Template: /{+gp}

 Example - replacing with two new groups
 Req: PUT /coap-group
    { "1":{ "a": "[ff15::4200:f7fe:ed37:1234]" },
      "2":{ "a": "[ff15::4200:f7fe:ed37:5678]" }
    }
 Res: 2.04 Changed

 Example - clearing all group memberships
 Req: PUT /coap-group
    {}
 Res: 2.04 Changed

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-
  esko.dijk@philips.com  |  groupcomm@tools.ietf.org
     Type:  protocol     |      Status:  new
  enhancement            |   Milestone:
 Priority:  major        |     Version:
Component:  groupcomm    |  Resolution:
 Severity:  -            |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
core 


From Akbar.Rahman@InterDigital.com  Wed Oct 23 10:27:07 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5653C11E8481 for ; Wed, 23 Oct 2013 10:27:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KaihrdPS0XGh for ; Wed, 23 Oct 2013 10:27:02 -0700 (PDT)
Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 395D411E8202 for ; Wed, 23 Oct 2013 10:27:00 -0700 (PDT)
Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 23 Oct 2013 13:26:56 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 23 Oct 2013 13:26:55 -0400
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Question on draft-fossati-core-publish-option-02
Thread-Index: Ac7PaZvpo0I/epzZRO2ii/gOUgIV6wAqtzLg
References:  
From: "Rahman, Akbar" 
To: "Thomas Fossati" 
X-OriginalArrivalTime: 23 Oct 2013 17:26:56.0139 (UTC) FILETIME=[125E65B0:01CED015]
Cc: core@ietf.org
Subject: Re: [core] Question on draft-fossati-core-publish-option-02
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Oct 2013 17:27:07 -0000

Hi Thomas,


Thanks for the detailed and useful clarification.  The only open
question in my mind is what happens if the delegated proxy happens to be
not link local and not site local?  Does this mean that then a global
multicast href query would need to be attempted by the client?


/Akbar



-----Original Message-----
From: Thomas Fossati [mailto:tho@koanlogic.com]=20
Sent: Tuesday, October 22, 2013 4:59 PM
To: Rahman, Akbar
Cc: core@ietf.org
Subject: Re: Question on draft-fossati-core-publish-option-02

Thank you Akbar for taking the time to review it.

As far as your question:

On Tue, Oct 22, 2013 at 6:58 PM, Rahman, Akbar
 wrote:
> How is a client directed synchronously to go towards the delegated=20
> Endpoint?  In other words, suppose a client had a priori (e.g. at=20
> provisioning or startup) obtained the URI of the SEP for the resource=20
> that it was interested in.

This is a great example, and one which we've not documented in the
current I-D but should have been (next round!).

In this case, I would expect the client doing an href query to the
(multicast) /.well-known/core interface:

REQ: GET /.well-known/core?href=3Dcoap://sleepy.example.org/res

and get the following response back from the delegated Proxy (or from
another endpoint who happens to have this information):

RES: 2.05 Content
;
  anchor=3D"coap://proxy.example.org/";
  rel=3D"proxies"

which tells the client that coap://proxy.example.org "proxies" the
requested resource, so that it can then issue its Proxy-URI request for
that resource to said proxy.

> Your I-D is very clear on how the SEP
> can delegate a resource to a delegated Endpoint.  But how would the=20
> client, in a synchronous manner, know that the resource is no longer=20
> at the SEP but to go instead to the delegated Endpoint?

I hope my previous example is clear enough.  If you are not satisfied,
please shout :-)

> (I did see your Section 3, Discovery, but this to me seemed to be=20
> somehow a specific use case and not a general approach.  Apologies if=20
> I missed something obvious.)

Well, the intention is to make it a general approach, it should not look
like an ad hoc solution :-)

We set an explicit design constraint to reuse the discovery model of
RFC6690 as much as possible -- in line with our aim at providing a fully
"in-protocol" solution to the sleepy problem.
To make RFC6690 a building block that also supports the
sleepy/intermittent scenario, we had to bring in the "proxies" link
relation, that works around some semantic and syntactic limitation of
the "hosts" relation.  Using this new thing, the proxy not only hands
off packets around, but also participates into discovery, by advertising
resources that may be "hidden" to the other side of a CoAP network.

Cheers

From tho@koanlogic.com  Wed Oct 23 14:00:56 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0457A11E8122 for ; Wed, 23 Oct 2013 14:00:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.914
X-Spam-Level: 
X-Spam-Status: No, score=-0.914 tagged_above=-999 required=5 tests=[AWL=0.155,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_ILLEGAL_IP=1.908,  RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ItuueqIc+urL for ; Wed, 23 Oct 2013 14:00:50 -0700 (PDT)
Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) by ietfa.amsl.com (Postfix) with ESMTP id DCCE711E825E for ; Wed, 23 Oct 2013 14:00:47 -0700 (PDT)
Received: by mail-la0-f53.google.com with SMTP id eo20so1174912lab.12 for ; Wed, 23 Oct 2013 14:00:46 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zHQhmwuy1EdlqtTQKStxjh7iD03u5iynOlbenzDtXss=; b=MFj5IkM3V3JDqOFVUajQOtkffB4v/dF5KwC9rcxpR2sBBI95sdWI4oJ2A0Tn5EbUTz 7kSWWKxkIXSMipkVvteDcmC9SgG1AJJRRc2XjOhyJiIGEDZ8aiSk22I7KE1kLHzdd5ET RL2CoZ5lP3OognAYTP7i+1pimAOK2AgaGtViaLe9QhnvGIQy1ebjXMPLDij3eNLt5CKS 129Owulbty/kY/3y8XXWqiqlDTIidwt7lZd1z7TWi7lWwCmMeYhSBFb+MEaYt3FcaDjx mWcGqiQgQobM19FLJGRU8EkvpF8AmICI+BGlgm38QgoZ8weNZcDqiZPtRBbKkW5Sa6NQ JyFA==
X-Gm-Message-State: ALoCoQnDkZhFSfSorGYO+hsBE9q5c5hWyiRCXcnkIKVMJMh0/TLgwvHPDKEY3/Rq751q8BfqFfE3
MIME-Version: 1.0
X-Received: by 10.152.120.228 with SMTP id lf4mr204099lab.44.1382562046669; Wed, 23 Oct 2013 14:00:46 -0700 (PDT)
Received: by 10.114.21.4 with HTTP; Wed, 23 Oct 2013 14:00:46 -0700 (PDT)
X-Originating-IP: [2.96.100.215]
In-Reply-To: 
References:   
Date: Wed, 23 Oct 2013 22:00:46 +0100
Message-ID: 
From: Thomas Fossati 
To: "Rahman, Akbar" 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "core@ietf.org" 
Subject: Re: [core] Question on draft-fossati-core-publish-option-02
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Oct 2013 21:00:56 -0000

Hi Akbar,

On Wed, Oct 23, 2013 at 6:26 PM, Rahman, Akbar
 wrote:
> Thanks for the detailed and useful clarification.  The only open
> question in my mind is what happens if the delegated proxy happens to be
> not link local and not site local?  Does this mean that then a global
> multicast href query would need to be attempted by the client?

Are we going to register any global scope addresses for CoAP?  From
what I read is in coap-18, it looks like the IANA request will cover
link and site local addresses only.  (As one of the editors of
groupcomm you sure know better than me: could you clarify this point
please?)

Anyway, in cases where the multicast query is too expensive, or not
possible, I'd reckon the Client should be pre-configured to either:

- make Proxy-URI requests straight to the delegated Proxy, or
- ask a rendez-vous point (e.g. a RD) where Proxies can publish links
of the resources they explicitly proxy for.


BTW, a nice thing about the 'proxies' relation is that it can be used
by a set of mutually trusted and co-operating Proxy nodes to exchange
information about the resources that they made accessible/reachable to
other nodes:

P1 requests /.well-known/core?rel=proxies to P2, obtaining the list of
resources that are visible to P2.  P1 can then update its "resource
routing" table adding P2 as next-hop for said resources.  Viceversa,
P2 could query P1 to create the other slice of the map.

Cheers.

From Akbar.Rahman@InterDigital.com  Wed Oct 23 14:11:58 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A18EA11E81F9 for ; Wed, 23 Oct 2013 14:11:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuCr+X6q8yqu for ; Wed, 23 Oct 2013 14:11:54 -0700 (PDT)
Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5EDE411E8122 for ; Wed, 23 Oct 2013 14:11:54 -0700 (PDT)
Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 23 Oct 2013 17:11:53 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 23 Oct 2013 17:11:51 -0400
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Question on draft-fossati-core-publish-option-02
Thread-Index: Ac7QMwK013sF6QoST4CnU3h0LVLcUAAAKbBg
References:  
From: "Rahman, Akbar" 
To: "Thomas Fossati" 
X-OriginalArrivalTime: 23 Oct 2013 21:11:53.0819 (UTC) FILETIME=[7F9CEAB0:01CED034]
Cc: core@ietf.org
Subject: Re: [core] Question on draft-fossati-core-publish-option-02
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Oct 2013 21:11:58 -0000

Hi Thomas,


>Are we going to register any global scope addresses for CoAP?  From
what I read is in coap-18, it looks like the IANA request will cover
link and site >local addresses only.  (As one of the editors of
groupcomm you sure know better than me: could you clarify this point
>please?)


Sorry if my original question was a bit vague.  But to answer your
question.  You are correct that CoAP-18 does not specify global scope
for IPv6 multicast, but for IPv4 it says the following which I
understand to be the IPv4 equivalent of global scope address.


   http://tools.ietf.org/html/draft-ietf-core-coap-18#section-12.8

   IPv4  -- "All CoAP Nodes" address [TBD1], from the IPv4 Multicast
      Address Space Registry.  As the address is used for discovery that
      may span beyond a single network, it should come from the
      Internetwork Control Block (224.0.1.x, RFC 5771).



What we have in Groupcommis:

  http://tools.ietf.org/html/draft-ietf-core-groupcomm-16#section-2.8


  A client should use CoAP multicast with the smallest possible
      multicast scope that fulfills the application needs.  As an
      example, site-local scope is always preferred over global scope IP
      multicast if this fulfills the application needs.



/Akbar



-----Original Message-----
From: Thomas Fossati [mailto:tho@koanlogic.com]=20
Sent: Wednesday, October 23, 2013 5:01 PM
To: Rahman, Akbar
Cc: core@ietf.org
Subject: Re: Question on draft-fossati-core-publish-option-02

Hi Akbar,

On Wed, Oct 23, 2013 at 6:26 PM, Rahman, Akbar
 wrote:
> Thanks for the detailed and useful clarification.  The only open=20
> question in my mind is what happens if the delegated proxy happens to=20
> be not link local and not site local?  Does this mean that then a=20
> global multicast href query would need to be attempted by the client?

Are we going to register any global scope addresses for CoAP?  From what
I read is in coap-18, it looks like the IANA request will cover link and
site local addresses only.  (As one of the editors of groupcomm you sure
know better than me: could you clarify this point
please?)

Anyway, in cases where the multicast query is too expensive, or not
possible, I'd reckon the Client should be pre-configured to either:

- make Proxy-URI requests straight to the delegated Proxy, or
- ask a rendez-vous point (e.g. a RD) where Proxies can publish links of
the resources they explicitly proxy for.


BTW, a nice thing about the 'proxies' relation is that it can be used by
a set of mutually trusted and co-operating Proxy nodes to exchange
information about the resources that they made accessible/reachable to
other nodes:

P1 requests /.well-known/core?rel=3Dproxies to P2, obtaining the list of
resources that are visible to P2.  P1 can then update its "resource
routing" table adding P2 as next-hop for said resources.  Viceversa,
P2 could query P1 to create the other slice of the map.

Cheers.

From cabo@tzi.org  Wed Oct 23 14:34:35 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E3711E8205 for ; Wed, 23 Oct 2013 14:34:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.204
X-Spam-Level: 
X-Spam-Status: No, score=-106.204 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQHaiEmxxXTm for ; Wed, 23 Oct 2013 14:34:30 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id DB76311E821E for ; Wed, 23 Oct 2013 14:34:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9NLYFBB005417; Wed, 23 Oct 2013 23:34:15 +0200 (CEST)
Received: from [192.168.217.105] (p54892037.dip0.t-ipconnect.de [84.137.32.55]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 0F190DD5; Wed, 23 Oct 2013 23:34:14 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: 
Date: Wed, 23 Oct 2013 23:34:13 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <24898C3C-FF0F-4031-A4AB-3D08A658D83A@tzi.org>
References:    
To: Thomas Fossati 
X-Mailer: Apple Mail (2.1816)
Cc: "core@ietf.org" 
Subject: Re: [core] Question on draft-fossati-core-publish-option-02
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Oct 2013 21:34:35 -0000

On 23 Oct 2013, at 23:00, Thomas Fossati  wrote:

> Are we going to register any global scope addresses for CoAP? =20

=
http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xh=
tml

Internetwork Control Block (224.0.1.0 - 224.0.1.255 (224.0.1/24))

224.0.1.187	All CoAP Nodes	[RFC-ietf-core-coap-18]	2013-07-25

and

=
http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-ad=
dresses.xhtml

Variable Scope Multicast Addresses

FF0X:0:0:0:0:0:0:FD	All CoAP Nodes	[RFC-ietf-core-coap-18]	=
2013-07-25

Gr=FC=DFe, Carsten


From tho@koanlogic.com  Wed Oct 23 14:43:52 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6220411E8272 for ; Wed, 23 Oct 2013 14:43:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.966
X-Spam-Level: 
X-Spam-Status: No, score=-0.966 tagged_above=-999 required=5 tests=[AWL=0.103,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_ILLEGAL_IP=1.908,  RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHzx+4rhlXMb for ; Wed, 23 Oct 2013 14:43:46 -0700 (PDT)
Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) by ietfa.amsl.com (Postfix) with ESMTP id 43AF911E824F for ; Wed, 23 Oct 2013 14:43:46 -0700 (PDT)
Received: by mail-la0-f52.google.com with SMTP id eh20so1206854lab.11 for ; Wed, 23 Oct 2013 14:43:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=w0L6qV52/8wy/aDmXRQzGTc+Mv3yWsX2eu/rB0OBDQ8=; b=Zrx2QOf5qUytQdoIeTOz/p3GJQlcsLDlGUdlAOwqJcDH9Wu3ShyjU9VXAFbGkCMhJZ cSqb85wamGilcIalRQKT2rqi5zNhtrspSnzX7XpW2Rix4U6jbBjWLmzKcuM99l4v4bZ0 AbKWvr1tieMt5pK1zBxfxVfC6lGcU4hKuhgjLrPlW7kUeNkU+zwNTO2DdzYIPnO7d0dc PXo8I7e/rdN+JgZ9xj6RjWZgkfimEn/1jXsWbJbDUoWP+l9TKB1bYcUaZ884zvMj19VF QDyXR98zGV7aXCmaz0bkB0PEqnCOQ7a87Ai85E4vOjjl2L15u+X07K/GAPO7ll7lQ5nH qqiA==
X-Gm-Message-State: ALoCoQl0oS6TXH3s8wQJu40aqK+e2t0tvkK/6UFKlei/C2gqeMgd8urOS80EjKlIebEH9YnMxPu+
MIME-Version: 1.0
X-Received: by 10.112.64.36 with SMTP id l4mr3608054lbs.15.1382564625008; Wed, 23 Oct 2013 14:43:45 -0700 (PDT)
Received: by 10.114.21.4 with HTTP; Wed, 23 Oct 2013 14:43:44 -0700 (PDT)
X-Originating-IP: [2.96.100.215]
In-Reply-To: 
References:     
Date: Wed, 23 Oct 2013 22:43:44 +0100
Message-ID: 
From: Thomas Fossati 
To: "Rahman, Akbar" 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "core@ietf.org" 
Subject: Re: [core] Question on draft-fossati-core-publish-option-02
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Oct 2013 21:43:52 -0000

Akbar,

On Wed, Oct 23, 2013 at 10:11 PM, Rahman, Akbar
 wrote:
> You are correct that CoAP-18 does not specify global scope
> for IPv6 multicast, but for IPv4 it says the following which I
> understand to be the IPv4 equivalent of global scope address.

you are right, it's 224.0.1.187 btw -- just checked with IANA :-)

So, to get back to your original question: if the physical medium is
multicast friendly, then in principle the global href query could be a
plausible way to discover the Proxy.  Since one only node is supposed
to respond (i.e. the one explicitly delegated by the SEP), this is not
going to flood the requester.

Does it look sensible to you?

From gerdes@tzi.de  Thu Oct 24 04:10:29 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7314711E831C for ; Thu, 24 Oct 2013 04:10:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.249
X-Spam-Level: 
X-Spam-Status: No, score=-8.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osNDM3VI25sF for ; Thu, 24 Oct 2013 04:10:22 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 26AAB11E830F for ; Thu, 24 Oct 2013 04:10:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9OB83NN011247; Thu, 24 Oct 2013 13:08:03 +0200 (CEST)
Received: from [134.102.7.152] (unknown [134.102.7.152]) (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 5DB8113B; Thu, 24 Oct 2013 13:08:02 +0200 (CEST)
Message-ID: <5268FF91.7050301@tzi.de>
Date: Thu, 24 Oct 2013 13:08:01 +0200
From: Stefanie Gerdes 
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: "core@ietf.org" 
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: [core] Invitation to Core-AA Meeting on Sunday 3rd Nov
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 11:10:29 -0000

Dear all,

We would like to invite you to the CoAP Authentication and Authorisation
(AA) informal meeting in Vancouver, which will take place on Sunday
afternoon starting at 12:15. Room information will follow and be
available on site.

There are several proposals on the table that aim at providing AA for
CoAP. One of the goals of the meeting is to compare these proposals and
their individual advantages.

But before such a comparison can take place, it is important to
synchronise the terms and to find a common understanding of what we want
to achieve. The use case discussion will cater for this.

The tentative schedule is as follows:

Roll call (20 min)
Introduction
   Technical introduction (10 min)
   Use cases (30 min)
   Solutions (50 min)
Technical discussion (60 min)
   Use cases and requirements
   Solutions
Way forward (20 min)

Carsten is collecting one slide per attendee for the roll call. Details
will follow.

We look forward to seeing you on Sunday 3 November in Vancouver!

Best regards,
Steffi and Bert


-- 
Stefanie Gerdes			Tel: +49 421 218 63906
TZI Universität Bremen		E-Mail: gerdes@tzi.de
Bibliothekstr. 1, MZH 5150
28359 Bremen, Germany


From pab@pabigot.com  Thu Oct 24 05:39:15 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4066A11E831E for ; Thu, 24 Oct 2013 05:39:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.473
X-Spam-Level: 
X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87yaExIi01aX for ; Thu, 24 Oct 2013 05:39:09 -0700 (PDT)
Received: from p3plsmtpa08-03.prod.phx3.secureserver.net (p3plsmtpa08-03.prod.phx3.secureserver.net [173.201.193.104]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5C911E8256 for ; Thu, 24 Oct 2013 05:39:02 -0700 (PDT)
Received: from [192.168.65.10] ([66.41.60.82]) by p3plsmtpa08-03.prod.phx3.secureserver.net with  id h0ew1m0021mTNtu010ewpL; Thu, 24 Oct 2013 05:39:00 -0700
Message-ID: <526914E1.2040906@pabigot.com>
Date: Thu, 24 Oct 2013 07:38:57 -0500
From: "Peter A. Bigot" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: core@ietf.org
References: <55877B3AFB359744BA0F2140E36F52B515C07FBA@MBX210.d.ethz.ch>
In-Reply-To: <55877B3AFB359744BA0F2140E36F52B515C07FBA@MBX210.d.ethz.ch>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [core] WGLC draft-ietf-core-observe-11: Token lifetime
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 12:39:15 -0000

On 10/21/2013 11:49 AM, Kovatsch Matthias wrote:
> Dear list
>
> With Observe, it becomes hard to decide when a Token can be re-used
> for a new request. The client extended the meaning of a Token to the
> server it subscribes with. The server will continue to use this Token
> until it removes the Observe relationship. Problem is, the client
> does not know when this will happen, since there is only garbage
> collection and no definite cancellation. An off-line discussion with
> Klaus also indicated that the client cannot expect the Token to be
> free again, when it RSTed a CON notification.

Why not?  Is this because the RST might be lost?  Doesn't step 2 in
section 4.5 require the server to drop the observation in any situation
where it is not acknowledged by the final retransmission, in which case
the client can assume the server has completed the transaction
(releasing the token) at most EXCHANGE_LIFETIME after the client
received the first CON notification message?  Step 3 starts with "If the
entry is still in the list of observers", suggesting that the removal is
immediate.

> When a client is no longer interested in notifications, it can simply
> forget about the Observe relationship. However, it must somehow store
> the Token in a list of wasted ones, it is not allowed to re-use. Do
> we need a sophisticated time-based mechanism like for MIDs? Or is
> there a good way to give the full control of the Token back to the
> client?
>
> A confirmed cancellation would also help with this issue...

I agree this is a significant weak point.  I think it should be
addressed in a wider context of what a REST transaction means in CoAP.
If that can be answered, then we know what the token lifetime is and
don't have to come up with ad hoc rules that apply only to observe.

Peter

From pab@pabigot.com  Thu Oct 24 05:39:16 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7442F11E8256 for ; Thu, 24 Oct 2013 05:39:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.48
X-Spam-Level: 
X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cv-qau-BBY-N for ; Thu, 24 Oct 2013 05:39:10 -0700 (PDT)
Received: from p3plsmtpa08-05.prod.phx3.secureserver.net (p3plsmtpa08-05.prod.phx3.secureserver.net [173.201.193.106]) by ietfa.amsl.com (Postfix) with ESMTP id EF91B11E815E for ; Thu, 24 Oct 2013 05:39:04 -0700 (PDT)
Received: from [192.168.65.10] ([66.41.60.82]) by p3plsmtpa08-05.prod.phx3.secureserver.net with  id h0f11m00m1mTNtu010f2kn; Thu, 24 Oct 2013 05:39:02 -0700
Message-ID: <526914E7.6040700@pabigot.com>
Date: Thu, 24 Oct 2013 07:39:03 -0500
From: "Peter A. Bigot" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: core 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [core] Stepping back: what is a CoAP REST transaction?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 12:39:16 -0000

When trying to understand a specification I find it most useful to start
with the underlying domain model of the problem it addresses.  I do this
by identifying key concepts and operations that compose to more complex
concepts and operations until the whole system can be approached at
different levels of abstraction.

For example, a CoAP endpoint is, to a first approximation, is a triple
of an IP address, a port, and a security context.  Messages are
transmitted from a source endpoint to a destination endpoint.

A CoAP message is pretty well defined, though its taxonomy is missing
some layers.  Request messages and response messages are also fairly
clear: they are simply messages with codes in specific classes.

But what is a REST transaction in the eyes of this protocol?  What are
its constituent elements, the events that transition it through the
stages of its lifecycle, and the limits on what it can express?

For CoAP-18 in isolation the answer clearly has something to do with a
request message and a response message which are coupled by a token, but
even in base CoAP a REST request is not a request message and a REST
response is not a response message.  Message retransmissions,
piggy-backed versus separate responses, and message duplication and
rejection all add complexity to the concept of a REST transaction.

Even if CoAP-18 could be taken as providing an operational definition of
a REST transaction, this stops working once observe, block, and
groupcomm remove constraints along orthogonal axes.  Observe introduces
a sequence of responses to one request.  Block introduces fragmented
requests and responses.  At one point groupcomm introduced multiple
responses that must be aggregated in some way to form the response.
(Here confusion comes in part from the lack of an underlying model for a
resource with a URI that uses a multicast address in its authority,
a construct that should be discussed in a wider community than CoAP.)

Recent issues raised here have included how to reliably cancel an
observe transaction and how to detect and resolve errors within the
block transfer of a request or response.  The answers would be informed
by a clear model of exactly what a REST transaction is within CoAP.
Done at the right level of abstraction this allows reasoning about what
new proposed capabilities mean by comparison to simpler and better
understood capabilities.

If the working group has such a model that is used to drive evolution of
new capabilities, I have been unable to extract it from the current
drafts.  To help CoAP be adopted by people other than those who are
actively developing it in parallel with their implementations to whom
the answers to "what does this mean" are obvious, this really needs to
be addressed.

If there is no such model, the consequence is ad hoc solutions to common
problems.  The resulting complexity is a serious impediment to adoption
of CoAP by anybody who doesn't have three years of sunk costs to justify
the necessary effort.

Peter

From cabo@tzi.org  Thu Oct 24 06:07:49 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E39AF11E830C for ; Thu, 24 Oct 2013 06:07:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.174
X-Spam-Level: 
X-Spam-Status: No, score=-106.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfTix8kSD7X6 for ; Thu, 24 Oct 2013 06:07:44 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 3240511E8193 for ; Thu, 24 Oct 2013 06:07:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9OD7bDj013940; Thu, 24 Oct 2013 15:07:37 +0200 (CEST)
Received: from [10.0.1.4] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6BB9B272; Thu, 24 Oct 2013 15:07:37 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann 
In-Reply-To: <526914E7.6040700@pabigot.com>
Date: Thu, 24 Oct 2013 15:07:36 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <23B98F85-16CC-450D-979C-1AD9F170F667@tzi.org>
References: <526914E7.6040700@pabigot.com>
To: "Peter A. Bigot" 
X-Mailer: Apple Mail (2.1816)
Cc: core 
Subject: Re: [core] Stepping back: what is a CoAP REST transaction?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 13:07:50 -0000

Hi Peter,

thanks for trying to step out from all that dazzling detail and getting =
a bigger picture.

Indeed, a base CoAP exchange (a word that I prefer over the loaded word =
=93transaction=94 here) is a pair of request and response messages.  The =
fact that they may need to be retransmitted or might be duplicated in =
the network is handled at the message layer and no longer is of interest =
at the request/response layer.

Observe extends the exchange by notifications, which can come as =
additional responses to the original GET request.  The cancel discussion =
is really about how to tear down such an extended exchange without =
creating lots more mechanism just for that.  (Since we already are using =
the token as a handle on the extended exchange to renew it, maybe we =
want to use that for proactive teardown.  But maybe the current reactive =
teardown is good enough.)

Block uses the exchange abstraction and layers essentially the same =
abstraction again on top of it, where the latter allows larger bodies =
than the base CoAP protocol (or UDP messages of comfortable sizes) do.

The groupcomm issue is indeed interesting; in my mind it works best by =
considering the multicast request a solicitation to begin an exchange, =
which instantiates once in each peer sending a response.  So in the end, =
you have many exchanges (each of which might be continued in a Block2 =
blockwise transfer).  But that is something that maybe is in the eye of =
the beholder =97 the protocol does not have to dictate the =
implementation model.  We certainly haven=92t completed discussing this.

The above discussion becomes really interesting once you add proxies to =
the picture.
The HTTP model of a proxy fits very well with the base CoAP protocol.
Observation relationship (extended exchanges) not defined beyond proxies =
=97 observing a proxy may cause that to establish an observation =
relationship at the next hop, or it may not.  Inversely, a proxy may =
decide to observe a resource if it detects significant interest in it by =
its clients.
Block is also intended to implementable hop-by-hop, but a simple =
CoAP-CoAP proxy may even be able to hand through each of the blocks =
without keeping the state.
Proxying group communication is something we don=92t really know how to =
do very well yet (section 2.9 of groupcomm).

Thanks again =97 asking questions like these on the list is really =
useful. =20
We may want to document more of this bigger picture in documents such as =
the CoRE roadmap.

Gr=FC=DFe, Carsten


From Akbar.Rahman@InterDigital.com  Thu Oct 24 20:26:03 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADC2F11E8188 for ; Thu, 24 Oct 2013 20:26:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7o3duvsyfgH for ; Thu, 24 Oct 2013 20:25:57 -0700 (PDT)
Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id A30B211E81A4 for ; Thu, 24 Oct 2013 20:25:56 -0700 (PDT)
Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 24 Oct 2013 23:25:55 -0400
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Thu, 24 Oct 2013 23:25:46 -0400
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Question on draft-fossati-core-publish-option-02
Thread-Index: Ac7QOQMgrc/0ThdLQ7KcCsMtUvgzqAA+CcUg
References:  
From: "Rahman, Akbar" 
To: "Thomas Fossati" 
X-OriginalArrivalTime: 25 Oct 2013 03:25:55.0051 (UTC) FILETIME=[EA0AEBB0:01CED131]
Cc: core@ietf.org
Subject: Re: [core] Question on draft-fossati-core-publish-option-02
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2013 03:26:03 -0000

Yes, but any scheme that generates frequent global scope multicast
requests is not a good thing even if only one node will respond (i.e.
because the multicast request traffic is still going out and taking
bandwidth and being read by all members of that global multicast group
even if only one node ultimately responds).



-----Original Message-----
From: Thomas Fossati [mailto:tho@koanlogic.com]=20
Sent: Wednesday, October 23, 2013 5:44 PM
To: Rahman, Akbar
Cc: core@ietf.org
Subject: Re: Question on draft-fossati-core-publish-option-02

Akbar,

On Wed, Oct 23, 2013 at 10:11 PM, Rahman, Akbar
 wrote:
> You are correct that CoAP-18 does not specify global scope for IPv6=20
> multicast, but for IPv4 it says the following which I understand to be

> the IPv4 equivalent of global scope address.

you are right, it's 224.0.1.187 btw -- just checked with IANA :-)

So, to get back to your original question: if the physical medium is
multicast friendly, then in principle the global href query could be a
plausible way to discover the Proxy.  Since one only node is supposed to
respond (i.e. the one explicitly delegated by the SEP), this is not
going to flood the requester.

Does it look sensible to you?

From kovatsch@inf.ethz.ch  Fri Oct 25 06:21:01 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AAB111E83F3 for ; Fri, 25 Oct 2013 06:21:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXY9jtl6HJbb for ; Fri, 25 Oct 2013 06:20:55 -0700 (PDT)
Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6C67A11E82CA for ; Fri, 25 Oct 2013 06:20:55 -0700 (PDT)
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.2.298.4; Fri, 25 Oct 2013 15:20:45 +0200
Received: from MBX210.d.ethz.ch ([fe80::ed77:7d47:9467:69a9]) by CAS20.d.ethz.ch ([fe80::2cd8:4907:7776:c56d%10]) with mapi id 14.02.0298.004; Fri, 25 Oct 2013 15:20:53 +0200
From: "Kovatsch  Matthias" 
To: "Peter A. Bigot" , "core@ietf.org" 
Thread-Topic: [core] WGLC draft-ietf-core-observe-11: Token lifetime
Thread-Index: Ac7OeIxzKqmgUA+MQbqe7NP5P8AmQgCLLGiAADbHfsA=
Date: Fri, 25 Oct 2013 13:20:53 +0000
Message-ID: <55877B3AFB359744BA0F2140E36F52B515C21C80@MBX210.d.ethz.ch>
References: <55877B3AFB359744BA0F2140E36F52B515C07FBA@MBX210.d.ethz.ch> <526914E1.2040906@pabigot.com>
In-Reply-To: <526914E1.2040906@pabigot.com>
Accept-Language: en-US, de-CH
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [88.209.34.29]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [core] WGLC draft-ietf-core-observe-11: Token lifetime
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2013 13:21:01 -0000

> > With Observe, it becomes hard to decide when a Token can be re-used
> > for a new request. The client extended the meaning of a Token to the
> > server it subscribes with. The server will continue to use this Token
> > until it removes the Observe relationship. Problem is, the client does
> > not know when this will happen, since there is only garbage collection
> > and no definite cancellation. An off-line discussion with Klaus also
> > indicated that the client cannot expect the Token to be free again,
> > when it RSTed a CON notification.
>=20
> Why not?  Is this because the RST might be lost?  Doesn't step 2 in secti=
on 4.5
> require the server to drop the observation in any situation where it is n=
ot
> acknowledged by the final retransmission, in which case the client can
> assume the server has completed the transaction (releasing the token) at
> most EXCHANGE_LIFETIME after the client received the first CON notificati=
on
> message?  Step 3 starts with "If the entry is still in the list of observ=
ers",
> suggesting that the removal is immediate.

You would need to add these timing requirements to the Token. The client ne=
eds an EXCHANGE_LIFETIME timeout before reusing the Token, instead of freei=
ng it along with rejecting the notification.

From pab@pabigot.com  Fri Oct 25 06:33:56 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A733811E8322 for ; Fri, 25 Oct 2013 06:33:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.486
X-Spam-Level: 
X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LuKTso12yyAb for ; Fri, 25 Oct 2013 06:33:50 -0700 (PDT)
Received: from p3plsmtpa11-07.prod.phx3.secureserver.net (p3plsmtpa11-07.prod.phx3.secureserver.net [68.178.252.108]) by ietfa.amsl.com (Postfix) with ESMTP id D337511E8192 for ; Fri, 25 Oct 2013 06:33:50 -0700 (PDT)
Received: from [192.168.65.10] ([66.41.60.82]) by p3plsmtpa11-07.prod.phx3.secureserver.net with  id hRZo1m0011mTNtu01RZou4; Fri, 25 Oct 2013 06:33:49 -0700
Message-ID: <526A733C.9050606@pabigot.com>
Date: Fri, 25 Oct 2013 08:33:48 -0500
From: "Peter A. Bigot" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Kovatsch Matthias , "core@ietf.org" 
References: <55877B3AFB359744BA0F2140E36F52B515C07FBA@MBX210.d.ethz.ch> <526914E1.2040906@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C21C80@MBX210.d.ethz.ch>
In-Reply-To: <55877B3AFB359744BA0F2140E36F52B515C21C80@MBX210.d.ethz.ch>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [core] WGLC draft-ietf-core-observe-11: Token lifetime
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2013 13:33:56 -0000

On 10/25/2013 08:20 AM, Kovatsch Matthias wrote:
>>> With Observe, it becomes hard to decide when a Token can be
>>> re-used for a new request. The client extended the meaning of a
>>> Token to the server it subscribes with. The server will continue
>>> to use this Token until it removes the Observe relationship.
>>> Problem is, the client does not know when this will happen, since
>>> there is only garbage collection and no definite cancellation. An
>>> off-line discussion with Klaus also indicated that the client
>>> cannot expect the Token to be free again, when it RSTed a CON
>>> notification.
>>
>> Why not?  Is this because the RST might be lost?  Doesn't step 2 in
>> section 4.5 require the server to drop the observation in any
>> situation where it is not acknowledged by the final retransmission,
>> in which case the client can assume the server has completed the
>> transaction (releasing the token) at most EXCHANGE_LIFETIME after
>> the client received the first CON notification message?  Step 3
>> starts with "If the entry is still in the list of observers",
>> suggesting that the removal is immediate.
>
> You would need to add these timing requirements to the Token. The
> client needs an EXCHANGE_LIFETIME timeout before reusing the Token,
> instead of freeing it along with rejecting the notification.

OK, but we agree this does work, right?  I thought you/Klaus were 
implying the client could never take control of the token back after 
using it in an observe transaction.

I think the delay requirement is already there since the client can't 
know that the RST made it through, or which notification retransmission 
it got (so it has to be conservative in estimating how much longer the 
server might still treat the transaction as active).  It'd be nice if 
such derived requirements were made explicit, but CoAP specifications 
don't usually do that.

Peter

From kovatsch@inf.ethz.ch  Fri Oct 25 06:49:40 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF5311E81A5 for ; Fri, 25 Oct 2013 06:49:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSee9MxLeBxQ for ; Fri, 25 Oct 2013 06:49:34 -0700 (PDT)
Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id D9DF811E830F for ; Fri, 25 Oct 2013 06:49:26 -0700 (PDT)
Received: from CAS12.d.ethz.ch (172.31.38.212) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.2.298.4; Fri, 25 Oct 2013 15:49:07 +0200
Received: from MBX210.d.ethz.ch ([fe80::ed77:7d47:9467:69a9]) by CAS12.d.ethz.ch ([fe80::7861:4ecb:7c42:cad4%10]) with mapi id 14.02.0298.004; Fri, 25 Oct 2013 15:49:15 +0200
From: "Kovatsch  Matthias" 
To: "Peter A. Bigot" , "core@ietf.org" 
Thread-Topic: [core] WGLC draft-ietf-core-observe-11: Token lifetime
Thread-Index: Ac7OeIxzKqmgUA+MQbqe7NP5P8AmQgCLLGiAADbHfsD//+tsAP//3Z9Q
Date: Fri, 25 Oct 2013 13:49:15 +0000
Message-ID: <55877B3AFB359744BA0F2140E36F52B515C22D83@MBX210.d.ethz.ch>
References: <55877B3AFB359744BA0F2140E36F52B515C07FBA@MBX210.d.ethz.ch> <526914E1.2040906@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C21C80@MBX210.d.ethz.ch> <526A733C.9050606@pabigot.com>
In-Reply-To: <526A733C.9050606@pabigot.com>
Accept-Language: en-US, de-CH
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [88.209.34.29]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [core] WGLC draft-ietf-core-observe-11: Token lifetime
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2013 13:49:40 -0000

> OK, but we agree this does work, right?  I thought you/Klaus were implyin=
g
> the client could never take control of the token back after using it in a=
n
> observe transaction.

Well, I still believe we have a problem without an active cancellation, sin=
ce the server starts to take control of the Token and the client cannot cla=
im it back.

> I think the delay requirement is already there since the client can't kno=
w that
> the RST made it through, or which notification retransmission it got (so =
it has
> to be conservative in estimating how much longer the server might still t=
reat
> the transaction as active).  It'd be nice if such derived requirements we=
re
> made explicit, but CoAP specifications don't usually do that.

Retransmissions are filtered through the MID, thus a client can re-use the =
Token instantly. I see the Token exclusively on the request/response layer.=
 When the client receives a response to a request with the same Token, this=
 exchange is completed and the Token free again (all in line with Carsten's=
 mail). Thus, my question, how the server should treat a new request with t=
his Token, when it still has it in its relationship store. I would say the =
server is slave to the client, just like when mirroring the Token for norma=
l requests: The server has to update the Observe relationship entries accor=
ding to the request (i.e., remove it, if no Observe option, update the obse=
rved resource when the path differs, etc.).

Ciao
Matthias


From pab@pabigot.com  Fri Oct 25 07:23:37 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 115AA11E821D for ; Fri, 25 Oct 2013 07:23:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.491
X-Spam-Level: 
X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08jVJdQ3-HyL for ; Fri, 25 Oct 2013 07:23:31 -0700 (PDT)
Received: from p3plsmtpa11-10.prod.phx3.secureserver.net (p3plsmtpa11-10.prod.phx3.secureserver.net [68.178.252.111]) by ietfa.amsl.com (Postfix) with ESMTP id 33C2011E81BB for ; Fri, 25 Oct 2013 07:23:31 -0700 (PDT)
Received: from [192.168.65.10] ([66.41.60.82]) by p3plsmtpa11-10.prod.phx3.secureserver.net with  id hSPS1m00G1mTNtu01SPSfZ; Fri, 25 Oct 2013 07:23:30 -0700
Message-ID: <526A7EDE.9040307@pabigot.com>
Date: Fri, 25 Oct 2013 09:23:26 -0500
From: "Peter A. Bigot" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Kovatsch Matthias , "core@ietf.org" 
References: <55877B3AFB359744BA0F2140E36F52B515C07FBA@MBX210.d.ethz.ch> <526914E1.2040906@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C21C80@MBX210.d.ethz.ch> <526A733C.9050606@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C22D83@MBX210.d.ethz.ch>
In-Reply-To: <55877B3AFB359744BA0F2140E36F52B515C22D83@MBX210.d.ethz.ch>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [core] WGLC draft-ietf-core-observe-11: Token lifetime
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2013 14:23:37 -0000

On 10/25/2013 08:49 AM, Kovatsch Matthias wrote:
>> OK, but we agree this does work, right?  I thought you/Klaus were
>> implying the client could never take control of the token back
>> after using it in an observe transaction.
>
> Well, I still believe we have a problem without an active
> cancellation, since the server starts to take control of the Token
> and the client cannot claim it back.

Maybe we don't agree.  I think the client can claim it back as soon as 
it knows the "exchange"/"transaction" is complete, which is when the 
server has sent a confirmable notification and failed to receive an 
acknowledgement of it after all required retransmission 
(EXCHANGE_LIFETIME seconds).  I do think the process by which this is 
done is currently inadequate as the client can't initiate it, and may 
fail to detect it has happened, but it does exist; see below.

>> I think the delay requirement is already there since the client
>> can't know that the RST made it through, or which notification
>> retransmission it got (so it has to be conservative in estimating
>> how much longer the server might still treat the transaction as
>> active).  It'd be nice if such derived requirements were made
>> explicit, but CoAP specifications don't usually do that.
>
> Retransmissions are filtered through the MID, thus a client can
> re-use the Token instantly. I see the Token exclusively on the
> request/response layer. When the client receives a response to a
> request with the same Token, this exchange is completed and the Token
> free again (all in line with Carsten's mail).

Here's where I dislike Carsten's use of "exchange", which is fine in 
base CoAP for one request with one response but does not scale to either 
observe or block.

I think an "(observe) transaction" (to the server) comprises a client 
endpoint, a set of Uri-* options, and a token (other cache-key options 
may be present but I don't think they should identify the observe 
transaction, but rather be parameters to it).

The observe transaction begins when the client does the original GET 
with Observe and a specific Token.  It ends when the server completes 
sending the last response associated with that original GET: immediately 
if the server responds without an Observe token, or when the server 
removes the subscription from the list of observers.  Without your 
proposal (which I support, see below) that removal can only be 
influenced by the client when the server sends a confirmable 
notification, which can take up to 24 hours.  But if the client does 
receive such a notification it can ensure the transaction ends, and it 
can know an upper bound on how long it will be before the server has to 
completed it.  (Assuming it knows the server's EXCHANGE_LIFETIME.)

(And assuming the server is not entitled to self-create observers 
without an explicit request; otherwise it might start up again after a 
power cycle.)

  Thus, my question, how
> the server should treat a new request with this Token, when it still
> has it in its relationship store. I would say the server is slave to
> the client, just like when mirroring the Token for normal requests:
> The server has to update the Observe relationship entries according
> to the request (i.e., remove it, if no Observe option, update the
> observed resource when the path differs, etc.).

Yes: in my view a GET with the same Token and Uri-* options results in a 
modification of the existing transaction: renewing it if Observe is 
present, cancelling it if Observe is absent, potentially changing 
characteristics in other situations (e.g., if a cache-key option value 
changes).

Peter

From kovatsch@inf.ethz.ch  Fri Oct 25 08:18:00 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 527D711E818E for ; Fri, 25 Oct 2013 08:18:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3FaqWok5Wjh for ; Fri, 25 Oct 2013 08:17:54 -0700 (PDT)
Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1E421F9E8D for ; Fri, 25 Oct 2013 08:17:42 -0700 (PDT)
Received: from CAS21.d.ethz.ch (172.31.51.111) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.2.298.4; Fri, 25 Oct 2013 17:17:32 +0200
Received: from MBX210.d.ethz.ch ([fe80::ed77:7d47:9467:69a9]) by CAS21.d.ethz.ch ([fe80::55ba:c4a5:d8a7:ab62%10]) with mapi id 14.02.0298.004; Fri, 25 Oct 2013 17:17:40 +0200
From: "Kovatsch  Matthias" 
To: "Peter A. Bigot" , "core@ietf.org" 
Thread-Topic: [core] WGLC draft-ietf-core-observe-11: Token lifetime
Thread-Index: Ac7OeIxzKqmgUA+MQbqe7NP5P8AmQgCLLGiAADbHfsD//+tsAP//3Z9QgAAwPwD//9SXwA==
Date: Fri, 25 Oct 2013 15:17:40 +0000
Message-ID: <55877B3AFB359744BA0F2140E36F52B515C22F4C@MBX210.d.ethz.ch>
References: <55877B3AFB359744BA0F2140E36F52B515C07FBA@MBX210.d.ethz.ch> <526914E1.2040906@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C21C80@MBX210.d.ethz.ch> <526A733C.9050606@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C22D83@MBX210.d.ethz.ch> <526A7EDE.9040307@pabigot.com>
In-Reply-To: <526A7EDE.9040307@pabigot.com>
Accept-Language: en-US, de-CH
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [88.209.34.29]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [core] WGLC draft-ietf-core-observe-11: Token lifetime
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2013 15:18:00 -0000

I think we talk about the same things and agree:

A CoAP exchange/transaction is active from the first request (the might be =
re-registration) until the last response (e.g., an error response without O=
bserve option). Thus, the Token is in use as long as the Observe relationsh=
ip exists. Even if the server reboots and forgets about it, the client cons=
iders it active until the Max-Age mechanism kicks in and refreshes or detec=
ts the loss of the relationship.

The exchange is also complete and the Token freed when a CON notification i=
s rejected. Thanks to the MID deduplication even right after sending the fi=
rst RST and not only after EXCHANGE_LIFETIME seconds.

But there is a problem that the client has to wait for this CON notificatio=
n and cannot trigger it. Thus, we should have a client-initiated cancellati=
on as well.

It is logical that a requests with a Token already in use is part of and mo=
difies the corresponding exchange/transaction. Thus, we need to clarify for=
 Observe what happens when the client sends a different request to the serv=
er using the same Token. I am in favor of:
- re-registration if with Observe option
- cancellation if without Observe option
- cancellation and new relationship if with Observe option, but with a diff=
erent URI (the client has to sort out his mess...).

There were some objections that cancelling with a GET and thus retrieving a=
 representation the client is not interested in anymore would not make sens=
e. However, I see Observe built on top of GET, so we have an easy fallback =
to a normal GET in case the server does not support Observe. Thus, everythi=
ng can/should happen through GET.

I hope I summarized comprehensibly :)
Ciao
Matthias


> -----Original Message-----
> From: Peter A. Bigot [mailto:pab@pabigot.com]
> Sent: Freitag, 25. Oktober 2013 16:23
> To: Kovatsch Matthias; core@ietf.org
> Subject: Re: [core] WGLC draft-ietf-core-observe-11: Token lifetime
>=20
> On 10/25/2013 08:49 AM, Kovatsch Matthias wrote:
> >> OK, but we agree this does work, right?  I thought you/Klaus were
> >> implying the client could never take control of the token back after
> >> using it in an observe transaction.
> >
> > Well, I still believe we have a problem without an active
> > cancellation, since the server starts to take control of the Token and
> > the client cannot claim it back.
>=20
> Maybe we don't agree.  I think the client can claim it back as soon as it=
 knows
> the "exchange"/"transaction" is complete, which is when the server has se=
nt
> a confirmable notification and failed to receive an acknowledgement of it
> after all required retransmission (EXCHANGE_LIFETIME seconds).  I do thin=
k
> the process by which this is done is currently inadequate as the client c=
an't
> initiate it, and may fail to detect it has happened, but it does exist; s=
ee
> below.
>=20
> >> I think the delay requirement is already there since the client can't
> >> know that the RST made it through, or which notification
> >> retransmission it got (so it has to be conservative in estimating how
> >> much longer the server might still treat the transaction as active).
> >> It'd be nice if such derived requirements were made explicit, but
> >> CoAP specifications don't usually do that.
> >
> > Retransmissions are filtered through the MID, thus a client can re-use
> > the Token instantly. I see the Token exclusively on the
> > request/response layer. When the client receives a response to a
> > request with the same Token, this exchange is completed and the Token
> > free again (all in line with Carsten's mail).
>=20
> Here's where I dislike Carsten's use of "exchange", which is fine in base=
 CoAP
> for one request with one response but does not scale to either observe or
> block.
>=20
> I think an "(observe) transaction" (to the server) comprises a client end=
point,
> a set of Uri-* options, and a token (other cache-key options may be prese=
nt
> but I don't think they should identify the observe transaction, but rathe=
r be
> parameters to it).
>=20
> The observe transaction begins when the client does the original GET with
> Observe and a specific Token.  It ends when the server completes sending
> the last response associated with that original GET: immediately if the s=
erver
> responds without an Observe token, or when the server removes the
> subscription from the list of observers.  Without your proposal (which I
> support, see below) that removal can only be influenced by the client whe=
n
> the server sends a confirmable notification, which can take up to 24 hour=
s.
> But if the client does receive such a notification it can ensure the tran=
saction
> ends, and it can know an upper bound on how long it will be before the
> server has to completed it.  (Assuming it knows the server's
> EXCHANGE_LIFETIME.)
>=20
> (And assuming the server is not entitled to self-create observers without=
 an
> explicit request; otherwise it might start up again after a power cycle.)
>=20
>   Thus, my question, how
> > the server should treat a new request with this Token, when it still
> > has it in its relationship store. I would say the server is slave to
> > the client, just like when mirroring the Token for normal requests:
> > The server has to update the Observe relationship entries according to
> > the request (i.e., remove it, if no Observe option, update the
> > observed resource when the path differs, etc.).
>=20
> Yes: in my view a GET with the same Token and Uri-* options results in a
> modification of the existing transaction: renewing it if Observe is prese=
nt,
> cancelling it if Observe is absent, potentially changing characteristics =
in other
> situations (e.g., if a cache-key option value changes).
>=20
> Peter

From tho@koanlogic.com  Fri Oct 25 08:41:07 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 791F811E8217 for ; Fri, 25 Oct 2013 08:41:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SIqN9eNukhZ for ; Fri, 25 Oct 2013 08:41:01 -0700 (PDT)
Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by ietfa.amsl.com (Postfix) with ESMTP id 070DA11E818E for ; Fri, 25 Oct 2013 08:41:00 -0700 (PDT)
Received: by mail-lb0-f170.google.com with SMTP id u14so888337lbd.15 for ; Fri, 25 Oct 2013 08:40:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RpM+TRubTXMbdheilyHOGR4l5e0TQUi2fDHWq0uUgKc=; b=bXyjtjKPF74YR6VfoWMYkIaE9v/lpDfEexcBF1U4MhOUi04dp5tXSotQSM79YlA0Ly W1Qb5amJeZ0OnKu0Ua5eml3MXyRbTcR9IoAidEev7o2A6VRVB2V6NuUzZhDluzN11L2I jvUBT/fhMN4vbTdu3QZsMmcyRXFhepL84W+HaTuhpaucKe6uupYJ52212dce9Yp2Y4Pm hrEKlv/kSGR7N7q2HADW8rnFkiceZBqRVbDt54BhEaqfEqiiXI1oGK1b1qfQC6+yXcSi /By2TMJaKaFN9pybhLYVltJBmH2DlagveCCQvjC9khec/yt4ls5CeiVv4g7udS6Ftx1C RVog==
X-Gm-Message-State: ALoCoQmON5p1d7pChqppSRVSQovx9XFPXzoROleQuahRFFe6j1cVNtp/a+fwXqWluFWA5YbCk6oo
MIME-Version: 1.0
X-Received: by 10.152.45.42 with SMTP id j10mr4685188lam.15.1382715659852; Fri, 25 Oct 2013 08:40:59 -0700 (PDT)
Received: by 10.114.21.4 with HTTP; Fri, 25 Oct 2013 08:40:59 -0700 (PDT)
X-Originating-IP: [81.134.152.4]
In-Reply-To: 
References:       
Date: Fri, 25 Oct 2013 16:40:59 +0100
Message-ID: 
From: Thomas Fossati 
To: "Rahman, Akbar" 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "core@ietf.org" 
Subject: Re: [core] Question on draft-fossati-core-publish-option-02
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2013 15:41:07 -0000

Hi Akbar,

On Fri, Oct 25, 2013 at 4:25 AM, Rahman, Akbar
 wrote:
> Yes, but any scheme that generates frequent global scope multicast
> requests is not a good thing even if only one node will respond (i.e.
> because the multicast request traffic is still going out and taking
> bandwidth and being read by all members of that global multicast group
> even if only one node ultimately responds).

of course you are right, and I would not suggest this as a best practice indeed.

As I said earlier, there are at least two safer options to attempt
before falling back to a globally scoped multicast query:
1) pre-configure the client with the delegated proxy address and make
the Proxy-URI request straight away;
2) pre-configure the client with the address of an endpoint (RD,
proxy, etc.) that can respond to unicast "proxies" requests about the
SEP, get the delegated proxy address, and produce the Proxy-URI
request.

Cheers

From pab@pabigot.com  Fri Oct 25 08:50:17 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 224F711E8155 for ; Fri, 25 Oct 2013 08:50:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.496
X-Spam-Level: 
X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NEWGOH33qfi for ; Fri, 25 Oct 2013 08:50:11 -0700 (PDT)
Received: from p3plsmtpa11-09.prod.phx3.secureserver.net (p3plsmtpa11-09.prod.phx3.secureserver.net [68.178.252.110]) by ietfa.amsl.com (Postfix) with ESMTP id 23B2D11E832A for ; Fri, 25 Oct 2013 08:50:03 -0700 (PDT)
Received: from [192.168.65.10] ([66.41.60.82]) by p3plsmtpa11-09.prod.phx3.secureserver.net with  id hTpo1m00C1mTNtu01TppVB; Fri, 25 Oct 2013 08:49:56 -0700
Message-ID: <526A931D.5090600@pabigot.com>
Date: Fri, 25 Oct 2013 10:49:49 -0500
From: "Peter A. Bigot" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Kovatsch Matthias , "core@ietf.org" 
References: <55877B3AFB359744BA0F2140E36F52B515C07FBA@MBX210.d.ethz.ch> <526914E1.2040906@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C21C80@MBX210.d.ethz.ch> <526A733C.9050606@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C22D83@MBX210.d.ethz.ch> <526A7EDE.9040307@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C22F4C@MBX210.d.ethz.ch>
In-Reply-To: <55877B3AFB359744BA0F2140E36F52B515C22F4C@MBX210.d.ethz.ch>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [core] WGLC draft-ietf-core-observe-11: Token lifetime
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2013 15:50:17 -0000

On 10/25/2013 10:17 AM, Kovatsch Matthias wrote:
> I think we talk about the same things and agree:
>
> A CoAP exchange/transaction is active from the first request (the
> might be re-registration) until the last response (e.g., an error
> response without Observe option). Thus, the Token is in use as long
> as the Observe relationship exists. Even if the server reboots and
> forgets about it, the client considers it active until the Max-Age
> mechanism kicks in and refreshes or detects the loss of the
> relationship.

Yes.

And in this case the server considers it active until something happens 
to cancel it, even if the client reboots and starts re-using the token.

> The exchange is also complete and the Token freed when a CON
> notification is rejected. Thanks to the MID deduplication even right
> after sending the first RST and not only after EXCHANGE_LIFETIME
> seconds.

Meh; maybe.  If the RST is lost the server might send the message again. 
  If the client implements deduplication (it's not required to), perhaps 
it's ok for the client to have already initiated a different transaction 
with the same Token.  Though if NSTART > 1 (or the network re-orders 
packets) there might be a NON notification with the same token still in 
the pipeline.

It might work, but it's pretty confusing and not obviously robust.  This 
is part of why I think we need a more refined concept of transaction and 
the generic steps that can be taken by a client or server to cancel one 
if necessary.  We should not be trying to address this solely from the 
perspective of observe.

>
> But there is a problem that the client has to wait for this CON
> notification and cannot trigger it. Thus, we should have a
> client-initiated cancellation as well.

I agree.

> It is logical that a requests with a Token already in use is part of
> and modifies the corresponding exchange/transaction. Thus, we need to
> clarify for Observe what happens when the client sends a different
> request to the server using the same Token. I am in favor of:

> - re-registration if with Observe option

Yes.

> - cancellation if without Observe option

Yes.

Note that with block notifications where only the first fragment appears 
as part of the observe transaction, we have not clearly addressed the 
mechanism by which a client initiates the block transfer to obtain the 
value associated with that particular notification, as it cannot include 
the corresponding Observe value in the request.  Perhaps it can't 
guarantee this (absent use of ETag).

> - cancellation and new relationship if with Observe option, but with a different URI (the client has to sort out his
> mess...).

Yes, but only because from the server perspective this is what would 
happen if the client rebooted, so there's server mess to be sorted out 
as well: in progress notification transmissions, etc.

Otherwise this is improper as it combines the cancellation of the first 
transaction with the creation of a new transaction.  Best to keep those 
concepts separate and say the client SHOULD cancel the previous 
transaction before re-using the same token in a new (observe or 
non-observe) transaction, as there may be a delay required before all 
parties can agree that a transaction has been cancelled.

>
> There were some objections that cancelling with a GET and thus
> retrieving a representation the client is not interested in anymore
> would not make sense. However, I see Observe built on top of GET, so
> we have an easy fallback to a normal GET in case the server does not
> support Observe. Thus, everything can/should happen through GET.

A few weeks ago we all agreed that GET with If-Match-None could serve as 
a HEAD that excluded a payload.  It would be good if this would be 
consistent with cancellation.

>
> I hope I summarized comprehensibly :) Ciao Matthias

I think so, if my replies don't reveal a misunderstanding on my part.

Peter

>
>
>> -----Original Message----- From: Peter A. Bigot
>> [mailto:pab@pabigot.com] Sent: Freitag, 25. Oktober 2013 16:23 To:
>> Kovatsch Matthias; core@ietf.org Subject: Re: [core] WGLC
>> draft-ietf-core-observe-11: Token lifetime
>>
>> On 10/25/2013 08:49 AM, Kovatsch Matthias wrote:
>>>> OK, but we agree this does work, right?  I thought you/Klaus
>>>> were implying the client could never take control of the token
>>>> back after using it in an observe transaction.
>>>
>>> Well, I still believe we have a problem without an active
>>> cancellation, since the server starts to take control of the
>>> Token and the client cannot claim it back.
>>
>> Maybe we don't agree.  I think the client can claim it back as soon
>> as it knows the "exchange"/"transaction" is complete, which is when
>> the server has sent a confirmable notification and failed to
>> receive an acknowledgement of it after all required retransmission
>> (EXCHANGE_LIFETIME seconds).  I do think the process by which this
>> is done is currently inadequate as the client can't initiate it,
>> and may fail to detect it has happened, but it does exist; see
>> below.
>>
>>>> I think the delay requirement is already there since the client
>>>> can't know that the RST made it through, or which notification
>>>> retransmission it got (so it has to be conservative in
>>>> estimating how much longer the server might still treat the
>>>> transaction as active). It'd be nice if such derived
>>>> requirements were made explicit, but CoAP specifications don't
>>>> usually do that.
>>>
>>> Retransmissions are filtered through the MID, thus a client can
>>> re-use the Token instantly. I see the Token exclusively on the
>>> request/response layer. When the client receives a response to a
>>> request with the same Token, this exchange is completed and the
>>> Token free again (all in line with Carsten's mail).
>>
>> Here's where I dislike Carsten's use of "exchange", which is fine
>> in base CoAP for one request with one response but does not scale
>> to either observe or block.
>>
>> I think an "(observe) transaction" (to the server) comprises a
>> client endpoint, a set of Uri-* options, and a token (other
>> cache-key options may be present but I don't think they should
>> identify the observe transaction, but rather be parameters to it).
>>
>> The observe transaction begins when the client does the original
>> GET with Observe and a specific Token.  It ends when the server
>> completes sending the last response associated with that original
>> GET: immediately if the server responds without an Observe token,
>> or when the server removes the subscription from the list of
>> observers.  Without your proposal (which I support, see below) that
>> removal can only be influenced by the client when the server sends
>> a confirmable notification, which can take up to 24 hours. But if
>> the client does receive such a notification it can ensure the
>> transaction ends, and it can know an upper bound on how long it
>> will be before the server has to completed it.  (Assuming it knows
>> the server's EXCHANGE_LIFETIME.)
>>
>> (And assuming the server is not entitled to self-create observers
>> without an explicit request; otherwise it might start up again
>> after a power cycle.)
>>
>> Thus, my question, how
>>> the server should treat a new request with this Token, when it
>>> still has it in its relationship store. I would say the server is
>>> slave to the client, just like when mirroring the Token for
>>> normal requests: The server has to update the Observe
>>> relationship entries according to the request (i.e., remove it,
>>> if no Observe option, update the observed resource when the path
>>> differs, etc.).
>>
>> Yes: in my view a GET with the same Token and Uri-* options results
>> in a modification of the existing transaction: renewing it if
>> Observe is present, cancelling it if Observe is absent, potentially
>> changing characteristics in other situations (e.g., if a cache-key
>> option value changes).
>>
>> Peter
>


From kovatsch@inf.ethz.ch  Fri Oct 25 09:06:33 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8C3F11E834C for ; Fri, 25 Oct 2013 09:06:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.599
X-Spam-Level: 
X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iehSRxZCZx5 for ; Fri, 25 Oct 2013 09:06:27 -0700 (PDT)
Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) by ietfa.amsl.com (Postfix) with ESMTP id A11B711E833E for ; Fri, 25 Oct 2013 09:06:26 -0700 (PDT)
Received: from CAS10.d.ethz.ch (172.31.38.210) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.2.298.4; Fri, 25 Oct 2013 18:06:16 +0200
Received: from MBX210.d.ethz.ch ([fe80::ed77:7d47:9467:69a9]) by CAS10.d.ethz.ch ([fe80::cce:fc66:7b56:a06a%10]) with mapi id 14.02.0298.004; Fri, 25 Oct 2013 18:06:19 +0200
From: "Kovatsch  Matthias" 
To: "Peter A. Bigot" , "core@ietf.org" 
Thread-Topic: [core] WGLC draft-ietf-core-observe-11: Token lifetime
Thread-Index: Ac7OeIxzKqmgUA+MQbqe7NP5P8AmQgCLLGiAADbHfsD//+tsAP//3Z9QgAAwPwD//9SXwIAAQ4uA///dUIA=
Date: Fri, 25 Oct 2013 16:06:19 +0000
Message-ID: <55877B3AFB359744BA0F2140E36F52B515C2316D@MBX210.d.ethz.ch>
References: <55877B3AFB359744BA0F2140E36F52B515C07FBA@MBX210.d.ethz.ch> <526914E1.2040906@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C21C80@MBX210.d.ethz.ch> <526A733C.9050606@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C22D83@MBX210.d.ethz.ch> <526A7EDE.9040307@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C22F4C@MBX210.d.ethz.ch> <526A931D.5090600@pabigot.com>
In-Reply-To: <526A931D.5090600@pabigot.com>
Accept-Language: en-US, de-CH
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [88.209.34.29]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [core] WGLC draft-ietf-core-observe-11: Token lifetime
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2013 16:06:34 -0000

> > The exchange is also complete and the Token freed when a CON
> > notification is rejected. Thanks to the MID deduplication even right
> > after sending the first RST and not only after EXCHANGE_LIFETIME
> > seconds.
>=20
> Meh; maybe.  If the RST is lost the server might send the message again.
>   If the client implements deduplication (it's not required to), perhaps =
it's ok
> for the client to have already initiated a different transaction with the=
 same
> Token.  Though if NSTART > 1 (or the network re-orders
> packets) there might be a NON notification with the same token still in t=
he
> pipeline.

Okay, NON notifications with re-ordering are obviously a problem and we mig=
ht need a cool-down time of NON_LIFETIME. This could be relaxed with a prop=
er Token generator (I am not advocating re-using the same Token for everyth=
ing, just that re-using should not break anything or that there are proper =
rules). A client without de-duplication should definitely put more effort i=
nto the choosing of Tokens. Tokens do not replace MID de-duplication, thoug=
h!

[...]

> Note that with block notifications where only the first fragment appears =
as
> part of the observe transaction, we have not clearly addressed the
> mechanism by which a client initiates the block transfer to obtain the va=
lue
> associated with that particular notification, as it cannot include the
> corresponding Observe value in the request.  Perhaps it can't guarantee t=
his
> (absent use of ETag).

This is a general problem of -block. I think the resource must implement th=
is correctly, hence provide an ETag. Only if it knows that it does not chan=
ge frequently, it might omit the ETag.

> > - cancellation and new relationship if with Observe option, but with a
> > different URI (the client has to sort out his mess...).
>=20
> Yes, but only because from the server perspective this is what would happ=
en
> if the client rebooted, so there's server mess to be sorted out as well: =
in
> progress notification transmissions, etc.
>=20
> Otherwise this is improper as it combines the cancellation of the first
> transaction with the creation of a new transaction.  Best to keep those
> concepts separate and say the client SHOULD cancel the previous transacti=
on
> before re-using the same token in a new (observe or
> non-observe) transaction, as there may be a delay required before all par=
ties
> can agree that a transaction has been cancelled.

Indeed, the client should not (probably MUST NOT) do this. But there must b=
e a defined behavior at the server in case the client does lose its state.

> A few weeks ago we all agreed that GET with If-Match-None could serve as =
a
> HEAD that excluded a payload.  It would be good if this would be consiste=
nt
> with cancellation.

Sounds good for this case.

Thanks for the discussion
Matthias



From pab@pabigot.com  Fri Oct 25 11:42:10 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C95811E81B4 for ; Fri, 25 Oct 2013 11:42:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.501
X-Spam-Level: 
X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQb9j0Seklfw for ; Fri, 25 Oct 2013 11:42:04 -0700 (PDT)
Received: from p3plsmtpa11-01.prod.phx3.secureserver.net (p3plsmtpa11-01.prod.phx3.secureserver.net [68.178.252.102]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA2E11E81B2 for ; Fri, 25 Oct 2013 11:42:01 -0700 (PDT)
Received: from [192.168.65.10] ([66.41.60.82]) by p3plsmtpa11-01.prod.phx3.secureserver.net with  id hWfq1m0021mTNtu01WfrJX; Fri, 25 Oct 2013 11:39:55 -0700
Message-ID: <526ABAF6.50602@pabigot.com>
Date: Fri, 25 Oct 2013 13:39:50 -0500
From: "Peter A. Bigot" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Kovatsch Matthias , "core@ietf.org" 
References: <55877B3AFB359744BA0F2140E36F52B515C07FBA@MBX210.d.ethz.ch> <526914E1.2040906@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C21C80@MBX210.d.ethz.ch> <526A733C.9050606@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C22D83@MBX210.d.ethz.ch> <526A7EDE.9040307@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C22F4C@MBX210.d.ethz.ch> <526A931D.5090600@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C2316D@MBX210.d.ethz.ch>
In-Reply-To: <55877B3AFB359744BA0F2140E36F52B515C2316D@MBX210.d.ethz.ch>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [core] WGLC draft-ietf-core-observe-11: Token lifetime
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2013 18:42:10 -0000

On 10/25/2013 11:06 AM, Kovatsch Matthias wrote:
>>> The exchange is also complete and the Token freed when a CON
>>> notification is rejected. Thanks to the MID deduplication even
>>> right after sending the first RST and not only after
>>> EXCHANGE_LIFETIME seconds.
>>
>> Meh; maybe.  If the RST is lost the server might send the message
>> again. If the client implements deduplication (it's not required
>> to), perhaps it's ok for the client to have already initiated a
>> different transaction with the same Token.  Though if NSTART > 1
>> (or the network re-orders packets) there might be a NON
>> notification with the same token still in the pipeline.
>
> Okay, NON notifications with re-ordering are obviously a problem and
> we might need a cool-down time of NON_LIFETIME. This could be relaxed
> with a proper Token generator (I am not advocating re-using the same
> Token for everything, just that re-using should not break anything or
> that there are proper rules). A client without de-duplication should
> definitely put more effort into the choosing of Tokens. Tokens do not
> replace MID de-duplication, though!

No, they have nothing to do with MID de-duplication.

I suspect you're thinking of something here that I haven't understood, 
because I still don't see the relevance of MID de-duplication to this 
problem.  Unless it is that you mean the client can re-use the token 
immediately after the RST because any subsequent re-transmissions from 
the server (due to lost RST) would have the same MID and therefore be 
dropped by the client's message layer, so would not propagate up to the 
transaction layer where the client could mis-associate it with a 
previous transaction.  In this special case perhaps you could assume the 
part of the client that generates the token is aware of whether its 
message layer implements deduplication for the previous use of the 
token, though I wouldn't like to make that assumption that myself (I'm 
pretty strong on decoupling implementation features).

If that's what you meant, note that observe's message supersedure 
feature interferes with this dependence of MID de-duplication: if the 
RST to the first retransmission was lost and the resource value has 
changed, the server is currently permitted to send a new message (with a 
new message ID and new representation) in a subsequent retransmission. 
The client would need to be able to detect this and send another RST for 
that message, and so on until the last retransmission completes.

So again: it's much simpler to go with a general concept of "cancelled 
transaction" and specify how all parties can identify the time at which 
it's known there are no outstanding messages related to that 
transaction, so it is safe to re-use the token for a new transaction 
regardless of the method, options, etc. involved with the original or 
replacement transactions.

>> Note that with block notifications where only the first fragment
>> appears as part of the observe transaction, we have not clearly
>> addressed the mechanism by which a client initiates the block
>> transfer to obtain the value associated with that particular
>> notification, as it cannot include the corresponding Observe value
>> in the request.  Perhaps it can't guarantee this (absent use of
>> ETag).
>
> This is a general problem of -block. I think the resource must
> implement this correctly, hence provide an ETag. Only if it knows
> that it does not change frequently, it might omit the ETag.

If the resource is both large and not simply one of a small set of 
potential results, there may not be an ETag associated with the 
representation.

>>> - cancellation and new relationship if with Observe option, but
>>> with a different URI (the client has to sort out his mess...).
>>
>> Yes, but only because from the server perspective this is what
>> would happen if the client rebooted, so there's server mess to be
>> sorted out as well: in progress notification transmissions, etc.
>>
>> Otherwise this is improper as it combines the cancellation of the
>> first transaction with the creation of a new transaction.  Best to
>> keep those concepts separate and say the client SHOULD cancel the
>> previous transaction before re-using the same token in a new
>> (observe or non-observe) transaction, as there may be a delay
>> required before all parties can agree that a transaction has been
>> cancelled.
>
> Indeed, the client should not (probably MUST NOT) do this. But there
> must be a defined behavior at the server in case the client does lose
> its state.

Absolutely.  Again, true for block, groupcomm, observe, and any 
situation where a transaction comprises multiple exchanges (see my 
response to Carsten for terminology here).

>> A few weeks ago we all agreed that GET with If-Match-None could
>> serve as a HEAD that excluded a payload.  It would be good if this
>> would be consistent with cancellation.
>
> Sounds good for this case.

Somebody needs to dig into the details and make sure it works out, though.

Peter

From hartke@tzi.org  Fri Oct 25 12:55:23 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB64311E8191 for ; Fri, 25 Oct 2013 12:55:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.627
X-Spam-Level: 
X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALnjfEyXjgDs for ; Fri, 25 Oct 2013 12:55:11 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD3411E8137 for ; Fri, 25 Oct 2013 12:55:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9PJt2X5002165 for ; Fri, 25 Oct 2013 21:55:03 +0200 (CEST)
Received: from mail-ve0-f171.google.com (mail-ve0-f171.google.com [209.85.128.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 85D77B4D for ; Fri, 25 Oct 2013 21:55:02 +0200 (CEST)
Received: by mail-ve0-f171.google.com with SMTP id pa12so2720872veb.30 for ; Fri, 25 Oct 2013 12:55:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=6GhbW08UFkfptP701JJmLGtywTgeE8G4/485vjByJm4=; b=Bw7FdzyUSCpGO5HW9k6M1/PlborKvzqyGFzeD9C8z1AdYBCKKr7YmI3KjbL4i4+RVf 7VGsa+YWb36D2Ez1nWOy8cY4oIgWWjhqAihaYTnf28DT05PvGXJ6pLjIwzm8/JlYqkuR BtpUTl54xIPn9VbtsnUP1CUBkGCfoi6KW4/g6VbofLZnbAubCLSKMx92znQlBNWjB0DH EfbApaZbe8l0Ae6uvl7oeuLNd/anYBwT6zJe1tQjUQlVpQer5wS/9qXQbpdQ0K/hZkMa 0+VjgIX11DGvoOk7sI4Tlsjr9eBySHyGQZEzSydaRYvJJY/UL3pnJuro9/jCyGuGsGEo 3xTA==
X-Received: by 10.58.218.161 with SMTP id ph1mr651348vec.40.1382730901107; Fri, 25 Oct 2013 12:55:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.102.100 with HTTP; Fri, 25 Oct 2013 12:54:21 -0700 (PDT)
In-Reply-To: <526ABAF6.50602@pabigot.com>
References: <55877B3AFB359744BA0F2140E36F52B515C07FBA@MBX210.d.ethz.ch> <526914E1.2040906@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C21C80@MBX210.d.ethz.ch> <526A733C.9050606@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C22D83@MBX210.d.ethz.ch> <526A7EDE.9040307@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C22F4C@MBX210.d.ethz.ch> <526A931D.5090600@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C2316D@MBX210.d.ethz.ch> <526ABAF6.50602@pabigot.com>
From: Klaus Hartke 
Date: Fri, 25 Oct 2013 22:54:21 +0300
Message-ID: 
To: "Peter A. Bigot" 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "core@ietf.org" 
Subject: Re: [core] WGLC draft-ietf-core-observe-11: Token lifetime
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2013 19:55:23 -0000

Peter A. Bigot wrote:
>>> A few weeks ago we all agreed that GET with If-Match-None could
>>> serve as a HEAD that excluded a payload.  It would be good if this
>>> would be consistent with cancellation.
>>
>> Sounds good for this case.
>
> Somebody needs to dig into the details and make sure it works out, though.

If I understand you two correctly, the idea is use a GET request with
the token of an ongoing observation and an If-Match-None option, but
without an Observe option, as a mechanism for a client to proactively
cancel an observation.

Besides it's pretty weird if a client has to ask a server "Please give
me a current representation of this resource. But without the
representation please. Oh, and, btw, I'm not interested in this
resource." when it actually wants to say "Hey! I'm not interested in
this resource any longer. Please cancel any further notifications.",
there is at least one case where this would be harmful: If the client
is observing the resource through an intermediary, the intermediary
might not have a current representation of the resource when the
request arrives. The server would then have to contact the origin
server (possibly through more intermediaries) just to get the current
representation that the client doesn't want but still requests. This
may even involve several lengthy separate responses if the origin
server cannot produce a current representation immediately.

Overloading the GET method with any semantics other than "Please give
me a current representation of this resource [and keep it updated over
time]." is a way in the wrong direction.

Best regards,
Klaus

From hartke@tzi.org  Fri Oct 25 13:33:54 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358C611E81E0 for ; Fri, 25 Oct 2013 13:33:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.627
X-Spam-Level: 
X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ns1YEGor0XHo for ; Fri, 25 Oct 2013 13:33:48 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id C116E11E8152 for ; Fri, 25 Oct 2013 13:33:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9PKXjdN018439 for ; Fri, 25 Oct 2013 22:33:45 +0200 (CEST)
Received: from mail-ve0-f181.google.com (mail-ve0-f181.google.com [209.85.128.181]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E3788B58 for ; Fri, 25 Oct 2013 22:33:44 +0200 (CEST)
Received: by mail-ve0-f181.google.com with SMTP id jz11so3071737veb.40 for ; Fri, 25 Oct 2013 13:33:43 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=59LJFOrWlkMSHWqonm0EPe2QTGmqGBL0nU0yW8lA+80=; b=O9SwaFrhwgj+b44UpslqNucJUgWbWwIMd5A2wjle4+cpN7HFtComMV4kS1Ayagx2RQ FdN6/1mFZ2VYtcTXOWbHI9BSohMWTHYcc7S7oT0HdkB5qzvc5eW7ts2DTmbF+dfvOqh6 FrBg/oBu4baZEQAFh86LlOla8E4zUH07yVSJnEDUZ7BROP0CGsvjMxJaiQaxP3skJtX2 tpgbYQ7h9T1ZUzCUZqbiU2+R0P6N4bwGpVvFvL7AqFWAa0FJqHc+cc7iSgY3WmyNk7UM AuTesQ0nOQkn91mEGxntBPAPE0PQzFgrxvloPjCTwHsOukNI82vaA3VR/gquejHZ0nSu Octg==
X-Received: by 10.220.16.73 with SMTP id n9mr5467506vca.24.1382733223415; Fri, 25 Oct 2013 13:33:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.102.100 with HTTP; Fri, 25 Oct 2013 13:33:03 -0700 (PDT)
In-Reply-To: 
References: <525ED2DE.5050600@pabigot.com> 
From: Klaus Hartke 
Date: Fri, 25 Oct 2013 23:33:03 +0300
Message-ID: 
To: core 
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [core] WGLC observe comment: notification supersedure
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2013 20:33:54 -0000

> Peter A. Bigot wrote:
>> To fix this I propose: Change step 3 in section 4.5 to something like:
>>
>>    3.  If the entry is still in the list of observers, the server MAY
>>        replace the message with a new notification with a representation
>>        of the current resource state.  Should the resource have changed
>>        its state more than once in the meantime, the notifications for
>>        the intermediate states are silently skipped.

So the idea is to slightly relax the requirement to let a client see
the new state after a state change as soon as possible, but not to
dispose the goal of eventual consistency.

To be clear, this means the options are as follows:

Current (paraphrased):

   If a server generates a new notification while the transmission
   process for a previous notification is still active, then the
   server aborts the transmission process for the old notification
   (but not before the current transmission attempt completes) and
   starts a new transmission process for the new notification (but
   with the retransmission counter and retransmission timer of the
   aborted process instead of the default values).

Invalid change:

   If a server generates a new notification while the transmission
   process for a previous notification is still active, then the
   server has the choice between the following two options:

   - It aborts the transmission process for the old notification
     (but not before the current transmission attempt completes)
     and starts a new transmission process for the new notification
     (but with the retransmission counter and retransmission timer
     of the aborted process instead of the default values).

   or

   - It silently ignores the new notification.

Possible change:

   If a server generates a new notification while the transmission
   process for a previous notification is still active, then the
   server has the choice between the following two options:

   - It aborts the transmission process for the old notification
     (but not before the current transmission attempt completes)
     and starts a new transmission process for the new notification
     (but with the retransmission counter and retransmission timer
     of the aborted process instead of the default values).

   or

   - It waits for the transmission process for the old notification
     to complete. If the transmission process completed successfully,
     it starts a new transmission process for the new notification
     (with default values).

I'm not overly convinced that we gain much from this change, but if it
eases the implementation for some people I wouldn't oppose it.

Best regards,
Klaus

From pab@pabigot.com  Fri Oct 25 15:51:26 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D36AD21F9DD5 for ; Fri, 25 Oct 2013 15:51:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.505
X-Spam-Level: 
X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8qdL8VEXxrR for ; Fri, 25 Oct 2013 15:51:21 -0700 (PDT)
Received: from p3plsmtpa11-05.prod.phx3.secureserver.net (p3plsmtpa11-05.prod.phx3.secureserver.net [68.178.252.106]) by ietfa.amsl.com (Postfix) with ESMTP id 6E82511E8181 for ; Fri, 25 Oct 2013 15:51:19 -0700 (PDT)
Received: from [192.168.65.10] ([66.41.60.82]) by p3plsmtpa11-05.prod.phx3.secureserver.net with  id harH1m00A1mTNtu01arH2t; Fri, 25 Oct 2013 15:51:18 -0700
Message-ID: <526AF5E6.20601@pabigot.com>
Date: Fri, 25 Oct 2013 17:51:18 -0500
From: "Peter A. Bigot" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: core@ietf.org
References: <525ED2DE.5050600@pabigot.com>	 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [core] WGLC observe comment: notification supersedure
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2013 22:51:26 -0000

On 10/25/2013 03:33 PM, Klaus Hartke wrote:
>> Peter A. Bigot wrote:
>>> To fix this I propose: Change step 3 in section 4.5 to something like:
>>>
>>>    3.  If the entry is still in the list of observers, the server MAY
>>>        replace the message with a new notification with a representation
>>>        of the current resource state.  Should the resource have changed
>>>        its state more than once in the meantime, the notifications for
>>>        the intermediate states are silently skipped.
>
> So the idea is to slightly relax the requirement to let a client see
> the new state after a state change as soon as possible, but not to
> dispose the goal of eventual consistency.

No.  It's to relax the requirement that all implementations of observe 
consider it "possible" to supersede an in-progress confirmable 
transmission with a new message that takes over remaining 
rights-to-retransmit.

>
> To be clear, this means the options are as follows:
>
> Current (paraphrased):
>
>     If a server generates a new notification while the transmission
>     process for a previous notification is still active, then the
>     server aborts the transmission process for the old notification
>     (but not before the current transmission attempt completes) and
>     starts a new transmission process for the new notification (but
>     with the retransmission counter and retransmission timer of the
>     aborted process instead of the default values).
>
> Invalid change:
>
[...]
>
>     - It silently ignores the new notification.
>
> Possible change:
>
[...]
>
>     - It waits for the transmission process for the old notification
>       to complete. If the transmission process completed successfully,
>       it starts a new transmission process for the new notification
>       (with default values).

The difference is only in the case where supersedure is not supported. 
Summarizing, the "invalid" one overspecifies by unnecessarily 
introducing "ignores the new notification", while the "possible" one 
overspecifies by explicitly requiring immediate transmission of the 
updated representation after the previous notification completes.  We 
can eliminate the overspecification by relying on more fundamental 
principles.

When I look at observe-11 there is no clear description of timeliness 
requirements for updates under observe.  "As soon as possible" is not a 
requirement: it's a guiding principle which is in direct conflict with 
principles related to limiting message traffic.  "Every change MUST be 
provided as a notification" would be a requirement, but it's not in the 
text (IMO the protocol overview in section 1.2 doesn't specify 
requirements).  If that's what you want, let's add it, then figure out 
if it makes sense.  (What if the resource is updated 100 times per second?)

Then let's see the argument that says observe's timeliness requirements 
are so strong they require that supersedure be a "possible" technique at 
all.  Supersedure now appears to interfere with one use of MID 
deduplication, unless I misunderstood Matthias' dependence on it in the 
token lifetime discussion.  This is one of those things that happen when 
the model of how the message layer works lacks a consensus understanding.

But assume the requirements do clearly state that every change has to 
produce a notification, and assume supersedure is worth accepting as an 
option within the model of what a CoAP message/exchange/transaction is. 
  We still don't need your "possible" rule as an explicit special case. 
  Just describe the functional behavior of observe by saying that each 
change to the resource conceptually adds a potential notification to a 
queue, and the observe infrastructure must transmit or discard the 
notifications in a manner consistent with (a) the balance between 
timeliness and congestion requirements, and (b) availability of 
supersedure as a message-layer transmission optimization.  Once you've 
done that, treating this as a special case is unnecessary.

In fact, I think if the text I proposed as a compromise is accepted then 
the entire conditional:

      If a server generates a new notification while the transmission
      process for a previous notification is still active....

can disappear and the steps at the end of 4.5 become a straightforward 
description of how the observe server transmits notifications whether 
there is or is not a change to the resource during that process.

That's a lot simpler to understand than having detailed instructions for 
a special case, and leaving the reader to try to figure out exactly what 
differences it might have from the less clearly described common case.

Peter


From pab@pabigot.com  Fri Oct 25 17:34:30 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAD8B11E818F for ; Fri, 25 Oct 2013 17:34:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.509
X-Spam-Level: 
X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSbZ-990qEa3 for ; Fri, 25 Oct 2013 17:34:25 -0700 (PDT)
Received: from p3plsmtpa11-10.prod.phx3.secureserver.net (p3plsmtpa11-10.prod.phx3.secureserver.net [68.178.252.111]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8B911E81F9 for ; Fri, 25 Oct 2013 17:34:23 -0700 (PDT)
Received: from [192.168.65.10] ([66.41.60.82]) by p3plsmtpa11-10.prod.phx3.secureserver.net with  id hcaL1m0011mTNtu01caLNT; Fri, 25 Oct 2013 17:34:22 -0700
Message-ID: <526B0E0C.7020801@pabigot.com>
Date: Fri, 25 Oct 2013 19:34:20 -0500
From: "Peter A. Bigot" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Klaus Hartke 
References: <55877B3AFB359744BA0F2140E36F52B515C07FBA@MBX210.d.ethz.ch> <526914E1.2040906@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C21C80@MBX210.d.ethz.ch> <526A733C.9050606@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C22D83@MBX210.d.ethz.ch> <526A7EDE.9040307@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C22F4C@MBX210.d.ethz.ch> <526A931D.5090600@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C2316D@MBX210.d.ethz.ch> <526ABAF6.50602@pabigot.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "core@ietf.org" 
Subject: Re: [core] WGLC draft-ietf-core-observe-11: Token lifetime
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 26 Oct 2013 00:34:31 -0000

On 10/25/2013 02:54 PM, Klaus Hartke wrote:
> Peter A. Bigot wrote:
>>>> A few weeks ago we all agreed that GET with If-Match-None could
>>>> serve as a HEAD that excluded a payload.  It would be good if this
>>>> would be consistent with cancellation.
>>>
>>> Sounds good for this case.
>>
>> Somebody needs to dig into the details and make sure it works out, though.
>
> If I understand you two correctly, the idea is use a GET request with
> the token of an ongoing observation and an If-Match-None option, but
> without an Observe option, as a mechanism for a client to proactively
> cancel an observation.

No.

The idea is use a GET request with the token of an ongoing observation 
but without an Observe option as a mechanism for a client to proactively 
cancel an observation.  Parallel to the way you use GET with an Observe 
option to create an observation associated with a token.

I just said that if somebody's knickers are in a twist about potentially 
receiving a representation that they don't want, they might be able to 
use an existing approach that inhibits the payload in a response to GET 
independently of other side-effects: viz, add an If-Match-None option. 
If you want the payload, or don't care about it, don't add If-Match-None.

In short, we're just defining useful semantics for a situation observe 
currently leaves under-specified.

Peter


From Akbar.Rahman@InterDigital.com  Fri Oct 25 18:58:00 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C92A11E8245 for ; Fri, 25 Oct 2013 18:58:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71Jmr-tNW0Yy for ; Fri, 25 Oct 2013 18:57:44 -0700 (PDT)
Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8E25C11E8228 for ; Fri, 25 Oct 2013 18:57:43 -0700 (PDT)
Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 25 Oct 2013 21:57:42 -0400
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Fri, 25 Oct 2013 21:57:41 -0400
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Question on draft-fossati-core-publish-option-02
Thread-Index: Ac7RmKsfBqSw2dfzSiyOzO1piHyxlQAVhMRw
References:  
From: "Rahman, Akbar" 
To: "Thomas Fossati" 
X-OriginalArrivalTime: 26 Oct 2013 01:57:42.0756 (UTC) FILETIME=[C2008A40:01CED1EE]
Cc: core@ietf.org
Subject: Re: [core] Question on draft-fossati-core-publish-option-02
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 26 Oct 2013 01:58:00 -0000

+1

-----Original Message-----
From: Thomas Fossati [mailto:tho@koanlogic.com]=20
Sent: Friday, October 25, 2013 11:41 AM
To: Rahman, Akbar
Cc: core@ietf.org
Subject: Re: Question on draft-fossati-core-publish-option-02

Hi Akbar,

On Fri, Oct 25, 2013 at 4:25 AM, Rahman, Akbar
 wrote:
> Yes, but any scheme that generates frequent global scope multicast=20
> requests is not a good thing even if only one node will respond (i.e.
> because the multicast request traffic is still going out and taking=20
> bandwidth and being read by all members of that global multicast group

> even if only one node ultimately responds).

of course you are right, and I would not suggest this as a best practice
indeed.

As I said earlier, there are at least two safer options to attempt
before falling back to a globally scoped multicast query:
1) pre-configure the client with the delegated proxy address and make
the Proxy-URI request straight away;
2) pre-configure the client with the address of an endpoint (RD, proxy,
etc.) that can respond to unicast "proxies" requests about the SEP, get
the delegated proxy address, and produce the Proxy-URI request.

Cheers

From hartke@tzi.org  Fri Oct 25 19:22:05 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7ED11E80E8 for ; Fri, 25 Oct 2013 19:22:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.627
X-Spam-Level: 
X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAuc96aDm6lI for ; Fri, 25 Oct 2013 19:21:59 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 11A8311E8114 for ; Fri, 25 Oct 2013 19:21:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9Q2LuFr002690 for ; Sat, 26 Oct 2013 04:21:56 +0200 (CEST)
Received: from mail-vb0-f45.google.com (mail-vb0-f45.google.com [209.85.212.45]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E9DF4B8D for ; Sat, 26 Oct 2013 04:21:55 +0200 (CEST)
Received: by mail-vb0-f45.google.com with SMTP id p6so1960053vbe.4 for ; Fri, 25 Oct 2013 19:21:54 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=4uR6HbQn0FQg45UwEDbhCI96QkWvqe70RNeo+ncNb+8=; b=g/aKX0Cpe+4uCn+zBVh82bVY5J8TzWjhjRAqIyAKs2BQMRfORNxkgxpdou8vPUd0oN 9iQHOb3fNjFyUee01f0vHyIYhphdqAz1WvIamTOXtODD30JiO3MRVnBtsrojngBS20/H RxldDMACMlpzCSIB1sZieIZbshs8WY62IZ71cUIETriVMPP/Z06J6prT3QLew019MchX 6l71ZErw1i1O4EKLqe56t9ifBUN1h4nH+6km9mwTnNNEuMeU7I4mBS6ELHNOBiuRcseZ 90dkEx78kqmt8PO0RB4U1wu+uce3YM/GoZt+uIVl7J/crbD3tqAIpqtiyZ3VZZwE3q2w S4gg==
X-Received: by 10.58.181.230 with SMTP id dz6mr489089vec.35.1382754114392; Fri, 25 Oct 2013 19:21:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.102.100 with HTTP; Fri, 25 Oct 2013 19:21:14 -0700 (PDT)
In-Reply-To: <526B0E0C.7020801@pabigot.com>
References: <55877B3AFB359744BA0F2140E36F52B515C07FBA@MBX210.d.ethz.ch> <526914E1.2040906@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C21C80@MBX210.d.ethz.ch> <526A733C.9050606@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C22D83@MBX210.d.ethz.ch> <526A7EDE.9040307@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C22F4C@MBX210.d.ethz.ch> <526A931D.5090600@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C2316D@MBX210.d.ethz.ch> <526ABAF6.50602@pabigot.com>  <526B0E0C.7020801@pabigot.com>
From: Klaus Hartke 
Date: Sat, 26 Oct 2013 05:21:14 +0300
Message-ID: 
To: "Peter A. Bigot" 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "core@ietf.org" 
Subject: Re: [core] WGLC draft-ietf-core-observe-11: Token lifetime
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 26 Oct 2013 02:22:05 -0000

Peter A. Bigot wrote:
>> If I understand you two correctly, the idea is use a GET request with
>> the token of an ongoing observation and an If-Match-None option, but
>> without an Observe option, as a mechanism for a client to proactively
>> cancel an observation.
>
> No.

The rest of my mail applies regardless of whether If-None-Match is used or not.

Observing a resource is an activity between two hops. And unless the
next hop is the origin server, cancelling the activity should not
require contacting the origin server.

Klaus

From kovatsch@inf.ethz.ch  Sat Oct 26 04:01:29 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1317121F9F97 for ; Sat, 26 Oct 2013 04:01:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.099
X-Spam-Level: 
X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAwxjsTxiXSm for ; Sat, 26 Oct 2013 04:01:23 -0700 (PDT)
Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1C06011E8177 for ; Sat, 26 Oct 2013 04:01:21 -0700 (PDT)
Received: from CAS21.d.ethz.ch (172.31.51.111) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.2.298.4; Sat, 26 Oct 2013 13:01:08 +0200
Received: from MBX210.d.ethz.ch ([fe80::ed77:7d47:9467:69a9]) by CAS21.d.ethz.ch ([fe80::55ba:c4a5:d8a7:ab62%10]) with mapi id 14.02.0298.004; Sat, 26 Oct 2013 13:01:17 +0200
From: "Kovatsch  Matthias" 
To: "Peter A. Bigot" , "core@ietf.org" 
Thread-Topic: [core] WGLC draft-ietf-core-observe-11: Token lifetime
Thread-Index: Ac7OeIxzKqmgUA+MQbqe7NP5P8AmQgCLLGiAADbHfsD//+tsAP//3Z9QgAAwPwD//9SXwIAAQ4uA///dUIAACkYpAP/+0Pkg
Date: Sat, 26 Oct 2013 11:01:17 +0000
Message-ID: <55877B3AFB359744BA0F2140E36F52B515C26BFF@MBX210.d.ethz.ch>
References: <55877B3AFB359744BA0F2140E36F52B515C07FBA@MBX210.d.ethz.ch> <526914E1.2040906@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C21C80@MBX210.d.ethz.ch> <526A733C.9050606@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C22D83@MBX210.d.ethz.ch> <526A7EDE.9040307@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C22F4C@MBX210.d.ethz.ch> <526A931D.5090600@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C2316D@MBX210.d.ethz.ch> <526ABAF6.50602@pabigot.com>
In-Reply-To: <526ABAF6.50602@pabigot.com>
Accept-Language: en-US, de-CH
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [88.209.34.29]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [core] WGLC draft-ietf-core-observe-11: Token lifetime
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 26 Oct 2013 11:01:29 -0000

> If that's what you meant, note that observe's message supersedure feature
> interferes with this dependence of MID de-duplication: if the RST to the =
first
> retransmission was lost and the resource value has changed, the server is
> currently permitted to send a new message (with a new message ID and new
> representation) in a subsequent retransmission.

Nope, the server must re-use ongoing CON notifications for further changes =
and must await its outcome before sending new notifications with a new MID =
(4.5. Transmission). However, this requirement is not as clear anymore in o=
bserve-11, I think.

Ciao
Matthias


From kovatsch@inf.ethz.ch  Sat Oct 26 04:18:44 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A36511E815F for ; Sat, 26 Oct 2013 04:18:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.199
X-Spam-Level: 
X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVw5HmK0SFPc for ; Sat, 26 Oct 2013 04:18:38 -0700 (PDT)
Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id F368811E8112 for ; Sat, 26 Oct 2013 04:18:37 -0700 (PDT)
Received: from CAS12.d.ethz.ch (172.31.38.212) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.2.298.4; Sat, 26 Oct 2013 13:18:27 +0200
Received: from MBX210.d.ethz.ch ([fe80::ed77:7d47:9467:69a9]) by CAS12.d.ethz.ch ([fe80::7861:4ecb:7c42:cad4%10]) with mapi id 14.02.0298.004; Sat, 26 Oct 2013 13:18:37 +0200
From: "Kovatsch  Matthias" 
To: Klaus Hartke , "Peter A. Bigot" 
Thread-Topic: [core] WGLC draft-ietf-core-observe-11: Token lifetime
Thread-Index: Ac7OeIxzKqmgUA+MQbqe7NP5P8AmQgCLLGiAADbHfsD//+tsAP//3Z9QgAAwPwD//9SXwIAAQ4uA///dUIAACkYpAAACmjuAAAnHPwAAA7vCAP//TFdg
Date: Sat, 26 Oct 2013 11:18:36 +0000
Message-ID: <55877B3AFB359744BA0F2140E36F52B515C26C6C@MBX210.d.ethz.ch>
References: <55877B3AFB359744BA0F2140E36F52B515C07FBA@MBX210.d.ethz.ch> <526914E1.2040906@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C21C80@MBX210.d.ethz.ch> <526A733C.9050606@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C22D83@MBX210.d.ethz.ch> <526A7EDE.9040307@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C22F4C@MBX210.d.ethz.ch> <526A931D.5090600@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C2316D@MBX210.d.ethz.ch> <526ABAF6.50602@pabigot.com>  <526B0E0C.7020801@pabigot.com> 
In-Reply-To: 
Accept-Language: en-US, de-CH
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [88.209.34.29]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "core@ietf.org" 
Subject: Re: [core] WGLC draft-ietf-core-observe-11: Token lifetime
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 26 Oct 2013 11:18:44 -0000

> The rest of my mail applies regardless of whether If-None-Match is used o=
r
> not.
>=20
> Observing a resource is an activity between two hops. And unless the next
> hop is the origin server, cancelling the activity should not require cont=
acting
> the origin server.

But then I do not understand why Observe was built as option on top of GET =
in the first place when "overloading" the method is the wrong direction and=
 there are such problems along intermediaries. Then a new method (or two fo=
r cancellation as well) might have been better? An OBSERVE method could the=
n could also have a payload to configure the observe relationship, which co=
uld also ease bindings for M2M standards that build on CoAP.

I do not see the problem of retrieving one more representation compared to =
continued notifications for the next 24 hours...

Ciao
Matthias


From cabo@tzi.org  Sat Oct 26 04:29:19 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F4F11E8232 for ; Sat, 26 Oct 2013 04:29:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.207
X-Spam-Level: 
X-Spam-Status: No, score=-106.207 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Pw55-CfhwGt for ; Sat, 26 Oct 2013 04:29:13 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1922B21F9FAE for ; Sat, 26 Oct 2013 04:29:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9QBTAQk014659; Sat, 26 Oct 2013 13:29:10 +0200 (CEST)
Received: from [192.168.217.105] (p54892A8D.dip0.t-ipconnect.de [84.137.42.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6FF4CBFB; Sat, 26 Oct 2013 13:29:09 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann 
In-Reply-To: <55877B3AFB359744BA0F2140E36F52B515C26C6C@MBX210.d.ethz.ch>
Date: Sat, 26 Oct 2013 13:29:06 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <55877B3AFB359744BA0F2140E36F52B515C07FBA@MBX210.d.ethz.ch> <526914E1.2040906@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C21C80@MBX210.d.ethz.ch> <526A733C.9050606@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C22D83@MBX210.d.ethz.ch> <526A7EDE.9040307@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C22F4C@MBX210.d.ethz.ch> <526A931D.5090600@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C2316D@MBX210.d.ethz.ch> <526ABAF6.50602@pabigot.com>  <526B0E0C.7020801@pabigot.com>  <55877B3AFB359744BA0F2140E36F52B515C26C6C@MBX210.d.ethz.ch>
To: Kovatsch Matthias 
X-Mailer: Apple Mail (2.1816)
Cc: "core@ietf.org" 
Subject: Re: [core] WGLC draft-ietf-core-observe-11: Token lifetime
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 26 Oct 2013 11:29:19 -0000

On 26 Oct 2013, at 13:18, Kovatsch Matthias  =
wrote:

> But then I do not understand why Observe was built as option on top of =
GET in the first place

You know that, but just to answer the question for the potential benefit =
of others on the list:

Observe is an =93Option=94 in the true sense of the word.
You ask a server for a representation, and add =93by the way, it would =
be nice if you could keep me posted on updates=94.
The server can consent (send back an Observe option in the response) or =
ignore.
(Observe is elective, so servers that don=92t know about Observe will =
automatically choose to ignore).

All this works well because when you start an observation, you are =
really interested in the representation.
(Now I do know some use cases where you *are* only interested in changes =
to the representation, the =93edge-triggered=94 case.  It is a matter of =
REST API design to turn edge-triggered into level-triggered.)

> I do not see the problem of retrieving one more representation =
compared to continued notifications for the next 24 hours...

It is indeed probably more of a cognitive-dissonance than a real-world =
problem.
If-No-Match just isn=92t strong enough to get rid of this side effect, =
and the whole point here is we don=92t want to invent another option (or =
option value).  Or maybe we do (but that should be well justified).

Gr=FC=DFe, Carsten


From kovatsch@inf.ethz.ch  Sat Oct 26 04:35:39 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD2A11E826D for ; Sat, 26 Oct 2013 04:35:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.266
X-Spam-Level: 
X-Spam-Status: No, score=-10.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qoIOfiGsZYmA for ; Sat, 26 Oct 2013 04:35:25 -0700 (PDT)
Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1C811E8232 for ; Sat, 26 Oct 2013 04:35:22 -0700 (PDT)
Received: from CAS12.d.ethz.ch (172.31.38.212) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.2.298.4; Sat, 26 Oct 2013 13:35:11 +0200
Received: from MBX210.d.ethz.ch ([fe80::ed77:7d47:9467:69a9]) by CAS12.d.ethz.ch ([fe80::7861:4ecb:7c42:cad4%10]) with mapi id 14.02.0298.004; Sat, 26 Oct 2013 13:35:21 +0200
From: "Kovatsch  Matthias" 
To: Carsten Bormann 
Thread-Topic: [core] WGLC draft-ietf-core-observe-11: Token lifetime
Thread-Index: Ac7OeIxzKqmgUA+MQbqe7NP5P8AmQgCLLGiAADbHfsD//+tsAP//3Z9QgAAwPwD//9SXwIAAQ4uA///dUIAACkYpAAACmjuAAAnHPwAAA7vCAP//TFdg//6zRAD//UQEkA==
Date: Sat, 26 Oct 2013 11:35:20 +0000
Message-ID: <55877B3AFB359744BA0F2140E36F52B515C26CE4@MBX210.d.ethz.ch>
References: <55877B3AFB359744BA0F2140E36F52B515C07FBA@MBX210.d.ethz.ch> <526914E1.2040906@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C21C80@MBX210.d.ethz.ch> <526A733C.9050606@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C22D83@MBX210.d.ethz.ch> <526A7EDE.9040307@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C22F4C@MBX210.d.ethz.ch> <526A931D.5090600@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C2316D@MBX210.d.ethz.ch> <526ABAF6.50602@pabigot.com>  <526B0E0C.7020801@pabigot.com>  <55877B3AFB359744BA0F2140E36F52B515C26C6C@MBX210.d.ethz.ch> 
In-Reply-To: 
Accept-Language: en-US, de-CH
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [88.209.34.29]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "core@ietf.org" 
Subject: Re: [core] WGLC draft-ietf-core-observe-11: Token lifetime
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 26 Oct 2013 11:35:39 -0000

> > But then I do not understand why Observe was built as option on top of
> GET in the first place
>=20
> You know that, but just to answer the question for the potential benefit =
of
> others on the list:

Yes, sorry, please excuse this unexplained rhetorical question.
I am just confused by this radical conclusion about overloading GET at this=
 stage of the document.

Ciao
Matthias


From cabo@tzi.org  Sat Oct 26 04:36:34 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1D6C11E8258 for ; Sat, 26 Oct 2013 04:36:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.208
X-Spam-Level: 
X-Spam-Status: No, score=-106.208 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WuatFXH5-ySf for ; Sat, 26 Oct 2013 04:36:23 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADFF21F9EF0 for ; Sat, 26 Oct 2013 04:36:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9QBaDKw028763; Sat, 26 Oct 2013 13:36:13 +0200 (CEST)
Received: from [192.168.217.105] (p54892A8D.dip0.t-ipconnect.de [84.137.42.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 764EBC00; Sat, 26 Oct 2013 13:36:12 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann 
In-Reply-To: <55877B3AFB359744BA0F2140E36F52B515C07FBA@MBX210.d.ethz.ch>
Date: Sat, 26 Oct 2013 13:36:10 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <98DE6454-5785-45D6-8D9E-18038F77BF4B@tzi.org>
References: <55877B3AFB359744BA0F2140E36F52B515C07FBA@MBX210.d.ethz.ch>
To: Kovatsch Matthias 
X-Mailer: Apple Mail (2.1816)
Cc: "core \(core@ietf.org\)" 
Subject: Re: [core] WGLC draft-ietf-core-observe-11: Token lifetime
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 26 Oct 2013 11:36:34 -0000

On 21 Oct 2013, at 18:49, Kovatsch Matthias  =
wrote:

> When a client is no longer interested in notifications, it can simply =
forget about the Observe relationship. However, it must somehow store =
the Token in a list of wasted ones, it is not allowed to re-use. Do we =
need a sophisticated time-based mechanism like for MIDs? Or is there a =
good way to give the full control of the Token back to the client?

The current discussion seems to be about whether we want to actively =
encourage client to modify the exchange identified by an active token =
(here: cancel the observation).

I=92m also interested in the original question: What do we have to say =
about the server experiencing a client (inadvertently or intentionally =97=
 the server can=92t find that out) using an active token for a new =
exchange?
(Where newness is measured in any difference in method, cache-key =
options, or payload.)

1) Do we place any explicit requirements on the server here?

2) Are these requirements powerful enough to make reuse of active tokens =
a generally acceptable technique?  (Of course, this will only ever be =
useful if the client does not need the response or can disambiguate it =
between the old and the new exchange.)

Gr=FC=DFe, Carsten


From pab@pabigot.com  Sat Oct 26 05:01:19 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE9411E817A for ; Sat, 26 Oct 2013 05:01:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.512
X-Spam-Level: 
X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJQqIQHZg3Nm for ; Sat, 26 Oct 2013 05:01:14 -0700 (PDT)
Received: from p3plsmtpa11-05.prod.phx3.secureserver.net (p3plsmtpa11-05.prod.phx3.secureserver.net [68.178.252.106]) by ietfa.amsl.com (Postfix) with ESMTP id C9C2411E812D for ; Sat, 26 Oct 2013 05:01:10 -0700 (PDT)
Received: from [192.168.65.10] ([66.41.60.82]) by p3plsmtpa11-05.prod.phx3.secureserver.net with  id ho181m00g1mTNtu01o19uX; Sat, 26 Oct 2013 05:01:10 -0700
Message-ID: <526BAF05.502@pabigot.com>
Date: Sat, 26 Oct 2013 07:01:09 -0500
From: "Peter A. Bigot" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Kovatsch Matthias , core 
References: <55877B3AFB359744BA0F2140E36F52B515C07FBA@MBX210.d.ethz.ch> <526914E1.2040906@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C21C80@MBX210.d.ethz.ch> <526A733C.9050606@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C22D83@MBX210.d.ethz.ch> <526A7EDE.9040307@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C22F4C@MBX210.d.ethz.ch> <526A931D.5090600@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C2316D@MBX210.d.ethz.ch> <526ABAF6.50602@pabigot.com> <55877B3AFB359744BA0F2140E36F52B515C26BFF@MBX210.d.ethz.ch>
In-Reply-To: <55877B3AFB359744BA0F2140E36F52B515C26BFF@MBX210.d.ethz.ch>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [core] WGLC draft-ietf-core-observe-11: Token lifetime
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 26 Oct 2013 12:01:19 -0000

On 10/26/2013 06:01 AM, Kovatsch Matthias wrote:
>> If that's what you meant, note that observe's message supersedure
>> feature interferes with this dependence of MID de-duplication: if
>> the RST to the first retransmission was lost and the resource value
>> has changed, the server is currently permitted to send a new
>> message (with a new message ID and new representation) in a
>> subsequent retransmission.
>
> Nope, the server must re-use ongoing CON notifications for further
> changes and must await its outcome before sending new notifications
> with a new MID (4.5. Transmission). However, this requirement is not
> as clear anymore in observe-11, I think.

Ah.  I guess that makes sense.  In the huge exchange culminating in 
http://www.ietf.org/mail-archive/web/core/current/msg04871.html I 
thought the conclusion was the MID did have to change when new data was 
transmitted.  Apparently my "obvious choice" (MID must change) was the 
wrong choice: going back and re-reading Carsten's mail that I was 
replying to, I guess he was hinting that this is a situation where it 
doesn't matter whether the client receives the new or old notification, 
so it's ok to re-use the MID for new content.

And yet again my concept of a confirmable message doesn't hold up to 
what CoAP wants to do with it.

Peter

From kovatsch@inf.ethz.ch  Sun Oct 27 05:50:10 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EEF311E8126 for ; Sun, 27 Oct 2013 05:50:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.313
X-Spam-Level: 
X-Spam-Status: No, score=-10.313 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2KrODRnWE84 for ; Sun, 27 Oct 2013 05:50:05 -0700 (PDT)
Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id D29FF11E817E for ; Sun, 27 Oct 2013 05:50:04 -0700 (PDT)
Received: from CAS11.d.ethz.ch (172.31.38.211) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.2.298.4; Sun, 27 Oct 2013 13:49:48 +0100
Received: from MBX210.d.ethz.ch ([fe80::ed77:7d47:9467:69a9]) by CAS11.d.ethz.ch ([fe80::ecc9:4e2d:b26b:1614%10]) with mapi id 14.02.0298.004; Sun, 27 Oct 2013 13:50:00 +0100
From: "Kovatsch  Matthias" 
To: "Peter A. Bigot" , "core@ietf.org" 
Thread-Topic: [core] WGLC observe comment: notification supersedure
Thread-Index: AQHOypjlFU9bbnQLnUeGxU2PSSLsK5n+756AgAbcd4CAACagAIACkelg
Date: Sun, 27 Oct 2013 12:49:59 +0000
Message-ID: <55877B3AFB359744BA0F2140E36F52B515C27CC9@MBX210.d.ethz.ch>
References: <525ED2DE.5050600@pabigot.com>   <526AF5E6.20601@pabigot.com>
In-Reply-To: <526AF5E6.20601@pabigot.com>
Accept-Language: en-US, de-CH
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [88.209.34.29]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [core] WGLC observe comment: notification supersedure
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 27 Oct 2013 12:50:10 -0000

When the implementation complies with the eventual consistency and stores a=
ll new or the latest notification in a queue for subsequent transmission, i=
t is a feasible option.

+1

However, I would then add the text on queuing to get the eventual consisten=
cy right, maybe as implementation note.

Ciao
Matthias

> -----Original Message-----
> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of
> Peter A. Bigot
> Sent: Samstag, 26. Oktober 2013 00:51
> To: core@ietf.org
> Subject: Re: [core] WGLC observe comment: notification supersedure
>=20
> On 10/25/2013 03:33 PM, Klaus Hartke wrote:
> >> Peter A. Bigot wrote:
> >>> To fix this I propose: Change step 3 in section 4.5 to something like=
:
> >>>
> >>>    3.  If the entry is still in the list of observers, the server MAY
> >>>        replace the message with a new notification with a representat=
ion
> >>>        of the current resource state.  Should the resource have chang=
ed
> >>>        its state more than once in the meantime, the notifications fo=
r
> >>>        the intermediate states are silently skipped.
> >
> > So the idea is to slightly relax the requirement to let a client see
> > the new state after a state change as soon as possible, but not to
> > dispose the goal of eventual consistency.
>=20
> No.  It's to relax the requirement that all implementations of observe
> consider it "possible" to supersede an in-progress confirmable transmissi=
on
> with a new message that takes over remaining rights-to-retransmit.
>=20
> >
> > To be clear, this means the options are as follows:
> >
> > Current (paraphrased):
> >
> >     If a server generates a new notification while the transmission
> >     process for a previous notification is still active, then the
> >     server aborts the transmission process for the old notification
> >     (but not before the current transmission attempt completes) and
> >     starts a new transmission process for the new notification (but
> >     with the retransmission counter and retransmission timer of the
> >     aborted process instead of the default values).
> >
> > Invalid change:
> >
> [...]
> >
> >     - It silently ignores the new notification.
> >
> > Possible change:
> >
> [...]
> >
> >     - It waits for the transmission process for the old notification
> >       to complete. If the transmission process completed successfully,
> >       it starts a new transmission process for the new notification
> >       (with default values).
>=20
> The difference is only in the case where supersedure is not supported.
> Summarizing, the "invalid" one overspecifies by unnecessarily introducing
> "ignores the new notification", while the "possible" one overspecifies by
> explicitly requiring immediate transmission of the updated representation
> after the previous notification completes.  We can eliminate the
> overspecification by relying on more fundamental principles.
>=20
> When I look at observe-11 there is no clear description of timeliness
> requirements for updates under observe.  "As soon as possible" is not a
> requirement: it's a guiding principle which is in direct conflict with pr=
inciples
> related to limiting message traffic.  "Every change MUST be provided as a
> notification" would be a requirement, but it's not in the text (IMO the
> protocol overview in section 1.2 doesn't specify requirements).  If that'=
s what
> you want, let's add it, then figure out if it makes sense.  (What if the =
resource
> is updated 100 times per second?)
>=20
> Then let's see the argument that says observe's timeliness requirements a=
re
> so strong they require that supersedure be a "possible" technique at all.
> Supersedure now appears to interfere with one use of MID deduplication,
> unless I misunderstood Matthias' dependence on it in the token lifetime
> discussion.  This is one of those things that happen when the model of ho=
w
> the message layer works lacks a consensus understanding.
>=20
> But assume the requirements do clearly state that every change has to
> produce a notification, and assume supersedure is worth accepting as an
> option within the model of what a CoAP message/exchange/transaction is.
>   We still don't need your "possible" rule as an explicit special case.
>   Just describe the functional behavior of observe by saying that each ch=
ange
> to the resource conceptually adds a potential notification to a queue, an=
d the
> observe infrastructure must transmit or discard the notifications in a ma=
nner
> consistent with (a) the balance between timeliness and congestion
> requirements, and (b) availability of supersedure as a message-layer
> transmission optimization.  Once you've done that, treating this as a spe=
cial
> case is unnecessary.
>=20
> In fact, I think if the text I proposed as a compromise is accepted then =
the
> entire conditional:
>=20
>       If a server generates a new notification while the transmission
>       process for a previous notification is still active....
>=20
> can disappear and the steps at the end of 4.5 become a straightforward
> description of how the observe server transmits notifications whether the=
re
> is or is not a change to the resource during that process.
>=20
> That's a lot simpler to understand than having detailed instructions for =
a
> special case, and leaving the reader to try to figure out exactly what
> differences it might have from the less clearly described common case.
>=20
> Peter
>=20
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core

From kovatsch@inf.ethz.ch  Sun Oct 27 06:34:46 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 147B311E8232 for ; Sun, 27 Oct 2013 06:34:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.349
X-Spam-Level: 
X-Spam-Status: No, score=-8.349 tagged_above=-999 required=5 tests=[AWL=-1.750, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngHJPv1wG-b7 for ; Sun, 27 Oct 2013 06:34:40 -0700 (PDT)
Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) by ietfa.amsl.com (Postfix) with ESMTP id B67F811E81D5 for ; Sun, 27 Oct 2013 06:34:37 -0700 (PDT)
Received: from CAS11.d.ethz.ch (172.31.38.211) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.2.298.4; Sun, 27 Oct 2013 14:34:29 +0100
Received: from MBX210.d.ethz.ch ([fe80::ed77:7d47:9467:69a9]) by CAS11.d.ethz.ch ([fe80::ecc9:4e2d:b26b:1614%10]) with mapi id 14.02.0298.004; Sun, 27 Oct 2013 14:34:34 +0100
From: "Kovatsch  Matthias" 
To: "core@ietf.org" 
Thread-Topic: WGLC observe comment: notification transmission
Thread-Index: Ac7TEx5xavqwJuDdQGCtXltPTJYjCA==
Date: Sun, 27 Oct 2013 13:34:33 +0000
Message-ID: <55877B3AFB359744BA0F2140E36F52B515C27D36@MBX210.d.ethz.ch>
Accept-Language: en-US, de-CH
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [88.209.34.29]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "'Klaus Hartke \(hartke@tzi.org\)'" 
Subject: [core] WGLC observe comment: notification transmission
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 27 Oct 2013 13:34:46 -0000

Dear list

During the discussion on supersedure, I noticed that step 1 is written for =
CON and NON notifications, the remaining steps only apply for CON (2: rejec=
ted NON notifications are not required to remove a client from the list of =
observers; 3: supersedure makes only sense for CON; 4: retransmissions do n=
ot apply for NONs).

Step 4 of 4.5. implicitly requires to send the new notification as CON when=
 the change occurred during an ongoing CON transmission. For eventual consi=
stency this makes sense, but I am not sure whether this was explicitly inte=
nded. Should we maybe make it clearer and also state that the MID must be p=
reserved for supersedure (currently only retransmission count and timeout a=
re mentioned)? My proposed text (draft):

   2.  If a Confirmable transmission is rejected or the transmission was
       the last attempt to deliver a notification, the server MUST remove
       the associated entry from the list of observers of the observed
       resource. If a Non-confirmable transmission is rejected, the server
       MAY remove the associated entry.

[BTW: What happened to removing all entries of a client, if a CON transmiss=
ion times out completely?]

    3.  If the entry is still in the list of observers, the server MAY
       update a Confirmable notification with the new representation
       of the current resource state and corresponding sequence
       number.  Should the resource have changed its state more
       than once in the meantime, the notifications for the
       intermediate states are silently skipped.

   4.  If the completed transmission attempt timed out, increment the
       retransmission counter and double the timeout, but keep the MID
       for the new transmission as described in Section 4.2 of RFC XXXX
       [I-D.ietf-core-coap].

   5. If a Confirmable transmission was acknowledged, send the new
       resource state as new Confirmable notification [with reinitialized
       retransmission counter and timeout.]

Ciao
Matthias

From pab@pabigot.com  Sun Oct 27 09:07:33 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD35421E80D8 for ; Sun, 27 Oct 2013 09:07:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.515
X-Spam-Level: 
X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ax4lgfd8e7fP for ; Sun, 27 Oct 2013 09:07:29 -0700 (PDT)
Received: from p3plsmtpa09-04.prod.phx3.secureserver.net (p3plsmtpa09-04.prod.phx3.secureserver.net [173.201.193.233]) by ietfa.amsl.com (Postfix) with ESMTP id F412721E80CD for ; Sun, 27 Oct 2013 09:07:25 -0700 (PDT)
Received: from [192.168.65.10] ([66.41.60.82]) by p3plsmtpa09-04.prod.phx3.secureserver.net with  id iG7A1m00J1mTNtu01G7BZW; Sun, 27 Oct 2013 09:07:12 -0700
Message-ID: <526D3A2E.4070604@pabigot.com>
Date: Sun, 27 Oct 2013 11:07:10 -0500
From: "Peter A. Bigot" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: core 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [core] Message supersedure as a domain concept
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 27 Oct 2013 16:07:33 -0000

This is all architecture-level discussion related to the topics in:

* http://www.ietf.org/mail-archive/web/core/current/msg04938.html
* http://www.ietf.org/mail-archive/web/core/current/msg04990.html
* http://www.ietf.org/mail-archive/web/core/current/msg05037.html

Its purpose is to explain how CoAP led me down the garden path, and to
identify inconsistency in what "message supersedure" might mean.  Here
we go:

Many network stacks that use an unreliable underlying transport include
a reliability layer.  The concept is that an upper layer submits a
message and a lower layer transmits it multiple times until the
recipient confirms receipt or a timeout is reached or something else
stops the retransmissions.

CoAP calls this a "confirmable message".  In its simplest form a message
of type CON with a specific Message ID (MID) is transmitted to a
destination endpoint up to 1+MAX_RETRANSMIT times with binary
exponential backoff (BEBO) until a message of type ACK or RST with the
same MID is received from the destination endpoint.

The naive reader will see all this as consistent with the expected
behavior of a reliability layer, and will proceed assuming s/he
understands what a confirmable message is.

The first deviation from expectation comes in section 5.10.5 of coap-18,
discussing management of the Max-Age option value:

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

Let's go back and clarify terms (some of these I'm creating on the fly
because CoAP doesn't distinguish them).

* A "(CoAP) message transmission" is the act of sending a CoAP message
   of type CON or NON.  This message has a source-defined message ID
   (MID), which is a 16-bit integral value.  The "message transmission"
   event occurs once for each message, regardless of CON or NON type
   (yes, once for CON messages: keep reading).

* A "(CoAP) message reply" is a CoAP message of type ACK or RST.  A CoAP
   message of type CON may evoke a reply of type ACK or RST; a CoAP
   message of type NON may evoke a reply of type RST.  In both cases, the
   MID of the reply is the same as the MID of the message that evoked the
   reply.  Neither ACK nor RST may evoke replies themselves.  A CoAP
   message transmission should evoke at most one CoAP message reply.

* A "transport layer transmission" is the act of submitting to the
   transport layer (UDP in this case) a block of data that is to be
   conveyed to a destination endpoint (IP address + port).  Messages of
   type NON, ACK, and RST normally have exactly one transport layer
   transmission (an exception occurs for reply messages under
   deduplication rules).  Messages of type CON may involve up to
   1+MAX_RETRANSMIT transport layer transmissions, terminating when the
   timeout of the last transmission completes or a reply message is
   received.

Back to the deviation.  When an upper layer submits a message to be
delivered reliably in most network stacks, the expectation is that any
lower-layer retransmissions are indistinguishable, i.e. the same bits
are transmitted each time (ignoring transport layer envelopes).  But
5.10.5 suggests that a transport layer retransmission of a confirmable
message containing a Max-Age option may have changed the value of that
option.

Cognitive dissonance.  What to do?

Answer: Appeal to the model of what a confirmable message is.  Naively,
it conveys some data.  But what we want it to convey is *information*.
Max-Age is an integral value that denotes an absolute time by providing
an offset, in seconds, from the time the message was created (as
estimated by the time it was sent, as estimated by the time it was
received).  So what 5.10.5 does is require the reliability layer to
change the *data* in the retransmitted message so that the *information*
(the absolute time) is unchanged.

Excellent: this makes sense, and is obviously the right thing to do.
(That it's optional and only applies to messages for resources with
strict tolerances on Max-Age is an inconsistency, but too late to do
anything about that now.  That it requires the reliability layer to be
able to recognize and mutate Max-Age options within the message content
is only slightly messy.)

Now we come to observe, which proposes that under certain circumstances
the entire representation of a resource, along with the Observe option
value, must be changed prior to transport layer retransmission of a
confirmable message.

Conceptually, what does this mean?  Technically, how is it done?

There are at least two approaches.

* One, which is what I believe is intended, says we should interpret the
   information conveyed by a response that includes the Observe option as
   "the current representation of the observed resource".  This allows us
   to replace the option value and the payload while retaining the same
   message ID and Token, without violating the concept of what a
   confirmable message means.

* The other, which is what I thought Klaus meant until Matthias
   corrected me, says that we cancel the previous confirmable message and
   replace it with a brand new notification message with its own message
   ID.  The new message then is granted the unused BEBO
   right-to-transmits from the cancelled message (because congestion
   requirements would normally prevent further transmissions to the
   endpoint until the original BEBO expired, since they are not relaxed
   by the act of cancelling a message).

Both these concepts need further refinement, but for my purposes here
they should be clear enough.  These are different techniques, and before
one is used in a CoAP specification it should have a distinct name and a
clear definition.

The latter is what I meant by "message supersedure" in all my previous
discussions: MID x is superseded by MID y (x != y) in terms of the BEBO
retransmission process and congestion control for the destination
endpoint.  It is a general technique that would not be restricted to
observe: it might also apply, for example, if the upper layers cancelled
the transmission, but the lower layers had other messages to be
transmitted to the same endpoint.  The superseding message need not have
any relation to the superseded message in terms of purpose: all it does
is advance the time at which a message is transmitted to a given
endpoint, at (potentially) a cost to the number of retransmissions.
Whether this is a good thing or not is another question.

But the term "message supersedure" might also be applied to the first
approach: The payload and some (all?) option values, but not the Token,
Code, or MID of the message may be replaced in retransmissions.  This
too might be a general technique, (e.g. if Max-Age reduces to zero in
non-observe responses).

The overall point remains: observe introduces a (IMO bizarre)
manipulation of what most readers would consider immutable message
content.  CoAP lacks the domain concepts to interpret that manipulation,
the precise terminology to describe how it is to be implemented, and the
generalizations that would lift the concept from being defined only
under deeply specific circumstances.

Peter

From pab@pabigot.com  Sun Oct 27 09:15:42 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44CF811E8182 for ; Sun, 27 Oct 2013 09:15:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.518
X-Spam-Level: 
X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFsgZq1Pset5 for ; Sun, 27 Oct 2013 09:15:35 -0700 (PDT)
Received: from p3plsmtpa09-10.prod.phx3.secureserver.net (p3plsmtpa09-10.prod.phx3.secureserver.net [173.201.193.239]) by ietfa.amsl.com (Postfix) with ESMTP id BAEC311E8294 for ; Sun, 27 Oct 2013 09:15:35 -0700 (PDT)
Received: from [192.168.65.10] ([66.41.60.82]) by p3plsmtpa09-10.prod.phx3.secureserver.net with  id iGFZ1m0021mTNtu01GFZsY; Sun, 27 Oct 2013 09:15:34 -0700
Message-ID: <526D3C25.6030106@pabigot.com>
Date: Sun, 27 Oct 2013 11:15:33 -0500
From: "Peter A. Bigot" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: core@ietf.org
References: <55877B3AFB359744BA0F2140E36F52B515C27D36@MBX210.d.ethz.ch>
In-Reply-To: <55877B3AFB359744BA0F2140E36F52B515C27D36@MBX210.d.ethz.ch>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [core] WGLC observe comment: notification transmission
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 27 Oct 2013 16:15:42 -0000

On 10/27/2013 08:34 AM, Kovatsch Matthias wrote:
> Dear list
>
> During the discussion on supersedure, I noticed that step 1 is
> written for CON and NON notifications, the remaining steps only apply
> for CON (2: rejected NON notifications are not required to remove a
> client from the list of observers; 3: supersedure makes only sense
> for CON; 4: retransmissions do not apply for NONs).

I'd like to pause here and note that "supersedure" as I have been using 
the term didn't mean what you mean in this topic.  I've started new 
topic to expose that question.

>
> Step 4 of 4.5. implicitly requires to send the new notification as
> CON when the change occurred during an ongoing CON transmission. For
> eventual consistency this makes sense, but I am not sure whether this
> was explicitly intended. Should we maybe make it clearer and also
> state that the MID must be preserved for supersedure (currently only
> retransmission count and timeout are mentioned)? My proposed text
> (draft):
>
> 2.  If a Confirmable transmission is rejected or the transmission
> was the last attempt to deliver a notification, the server MUST
> remove the associated entry from the list of observers of the
> observed resource. If a Non-confirmable transmission is rejected, the
> server MAY remove the associated entry.
>
> [BTW: What happened to removing all entries of a client, if a CON
> transmission times out completely?]

A little more precision would fix this.  Technically, the "list of 
observers" contains "observers" (which are defined as clients, which are 
destination endpoints for notifications), not entries (which don't have 
a distinct name but presumably associate a token with the client).  The 
"list of observers" is itself attached to a specific resource.

It is unclear whether failure to deliver a notification for one resource 
to a specific client should affect other resources.  Absent anything 
explicit, I would expect it would not.  (Keep in mind that unless things 
change the requirements imposed by step 2 only apply to notifications 
where the resource changes during transmission, which one would expect 
to be a rare case.)

>
> 3.  If the entry is still in the list of observers, the server MAY
> update a Confirmable notification with the new representation of the
> current resource state and corresponding sequence number.  Should the
> resource have changed its state more than once in the meantime, the
> notifications for the intermediate states are silently skipped.
>
> 4.  If the completed transmission attempt timed out, increment the
> retransmission counter and double the timeout, but keep the MID for
> the new transmission as described in Section 4.2 of RFC XXXX
> [I-D.ietf-core-coap].

IMO this, along with the bracketed and incomplete gloss in step 5, is 
repeating details, which risks inconsistency.  Instead it should 
incorporate the required behavior by reference to existing concepts like 
what a message is and what confirmable transmission of it is.  But I'm 
just going to back away from that aspect of the discussion now.

>
> 5. If a Confirmable transmission was acknowledged, send the new
> resource state as new Confirmable notification [with reinitialized
> retransmission counter and timeout.]
>
> Ciao Matthias _______________________________________________ core
> mailing list core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>


From hartke@tzi.org  Sun Oct 27 10:20:12 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED74211E81B0 for ; Sun, 27 Oct 2013 10:20:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.627
X-Spam-Level: 
X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8dGHNJZtV8r for ; Sun, 27 Oct 2013 10:20:07 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 5189A11E81A1 for ; Sun, 27 Oct 2013 10:20:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9RHK360029562 for ; Sun, 27 Oct 2013 18:20:03 +0100 (CET)
Received: from mail-vb0-f42.google.com (mail-vb0-f42.google.com [209.85.212.42]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A4FEEDFD for ; Sun, 27 Oct 2013 18:20:02 +0100 (CET)
Received: by mail-vb0-f42.google.com with SMTP id p14so2541530vbm.15 for ; Sun, 27 Oct 2013 10:20:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tpRcozx84OSjVH8AIMF7cf2X23QB+06QcTI+YFQJ578=; b=M5BB0+U+c4fkMqQCeaHBOZJxB5YpIh4yNWRsjE5LiUmx0VG5l+dLeeKFy6QG2zggdG 0DOKybmHOhFcvbKUspfjQDdqs2s5C+cmT6sHWqOTlnqRJ8eDqfemfSYNKhe0AEZJwxym t53SY2pAnutD/x6Rz/NYyvCk2AEJOwKFdCM5wm0kwJic2TbR6/qsKPnVOUfXp0ICezPb vYxKp3yNSRxMxVNBD7mMWZpoOAwq/ppuGZNvuXztURqAyHDEvegjanmrA1c03bUY6JnX asDsPc9ZhxF7UZLe1GTeO1FamMXSXOkcPH+bNhATskey4nUC8cDQab7s/u/V8ilIWX24 7v6A==
X-Received: by 10.220.196.66 with SMTP id ef2mr10353557vcb.7.1382894401269; Sun, 27 Oct 2013 10:20:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.102.100 with HTTP; Sun, 27 Oct 2013 10:19:21 -0700 (PDT)
In-Reply-To: <526D3A2E.4070604@pabigot.com>
References: <526D3A2E.4070604@pabigot.com>
From: Klaus Hartke 
Date: Sun, 27 Oct 2013 19:19:21 +0200
Message-ID: 
To: "Peter A. Bigot" 
Content-Type: text/plain; charset=ISO-8859-1
Cc: core 
Subject: Re: [core] Message supersedure as a domain concept
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 27 Oct 2013 17:20:13 -0000

Peter A. Bigot wrote:
> Let's go back and clarify terms (some of these I'm creating on the fly
> because CoAP doesn't distinguish them).
>
> * A "(CoAP) message transmission" is the act of sending a CoAP message
>   of type CON or NON.  This message has a source-defined message ID
>   (MID), which is a 16-bit integral value.  The "message transmission"
>   event occurs once for each message, regardless of CON or NON type
>   (yes, once for CON messages: keep reading).
>
> * A "(CoAP) message reply" is a CoAP message of type ACK or RST.  A CoAP
>   message of type CON may evoke a reply of type ACK or RST; a CoAP
>   message of type NON may evoke a reply of type RST.  In both cases, the
>   MID of the reply is the same as the MID of the message that evoked the
>   reply.  Neither ACK nor RST may evoke replies themselves.  A CoAP
>   message transmission should evoke at most one CoAP message reply.
>
> * A "transport layer transmission" is the act of submitting to the
>   transport layer (UDP in this case) a block of data that is to be
>   conveyed to a destination endpoint (IP address + port).  Messages of
>   type NON, ACK, and RST normally have exactly one transport layer
>   transmission (an exception occurs for reply messages under
>   deduplication rules).  Messages of type CON may involve up to
>   1+MAX_RETRANSMIT transport layer transmissions, terminating when the
>   timeout of the last transmission completes or a reply message is
>   received.

Huge +1.

> Back to the deviation.  When an upper layer submits a message to be
> delivered reliably in most network stacks, the expectation is that any
> lower-layer retransmissions are indistinguishable, i.e. the same bits
> are transmitted each time (ignoring transport layer envelopes).  But
> 5.10.5 suggests that a transport layer retransmission of a confirmable
> message containing a Max-Age option may have changed the value of that
> option.
>
> Cognitive dissonance.  What to do?
>
> Answer: Appeal to the model of what a confirmable message is.  Naively,
> it conveys some data.  But what we want it to convey is *information*.
> Max-Age is an integral value that denotes an absolute time by providing
> an offset, in seconds, from the time the message was created (as
> estimated by the time it was sent, as estimated by the time it was
> received).  So what 5.10.5 does is require the reliability layer to
> change the *data* in the retransmitted message so that the *information*
> (the absolute time) is unchanged.

+1

> Now we come to observe, which proposes that under certain circumstances
> the entire representation of a resource, along with the Observe option
> value, must be changed prior to transport layer retransmission of a
> confirmable message.

More precisely, when a resource changes its state, the representation
of that state changes.

The purpose of -observe is to let a client interested in the resource
always have a representation of the latest resource state. (This is
not perfectly possible because of network latency and message loss,
but the idea is to have client and server constantly work towards this
goal, limited by congestion control.)

So -observe proposes that, after a state change, a server starts
working towards getting the new representation to the client and stops
working on getting the old representation to the client.

> Conceptually, what does this mean?  Technically, how is it done?
>
> There are at least two approaches.

Indeed. The second approach is what -observe currently aims to describe:

> * [...] we cancel the previous confirmable message and
>   replace it with a brand new notification message with its own message
>   ID.  The new message then is granted the unused BEBO
>   right-to-transmits from the cancelled message (because congestion
>   requirements would normally prevent further transmissions to the
>   endpoint until the original BEBO expired, since they are not relaxed
>   by the act of cancelling a message).

This is what I mean, including that the new notification message has
its own message ID.

On the first approach:

> * One, which is what I believe is intended, says we should interpret the
>   information conveyed by a response that includes the Observe option as
>   "the current representation of the observed resource".  This allows us
>   to replace the option value and the payload while retaining the same
>   message ID and Token, without violating the concept of what a
>   confirmable message means.

I don't think that retaining the same message ID works. If the client
implements deduplication based on the message ID, then it would reject
the new representation as duplicate when it already received an old
representation with the same message ID but the acknowledgement to the
server was lost.

So the server has to replace the payload, the Observe option, the
Max-Age option, potentially the ETag option, the response code
(2.05/2.03/4.xx/5.xx), etc., and can retain only the token and the
Content-Format option.

I agree that this manipulation of a message in transmission (CoAP
message transmission) is quite bizarre. That's why I prefer to think
in terms of the other approach.

> The latter is what I meant by "message supersedure" in all my previous
> discussions: MID x is superseded by MID y (x != y) in terms of the BEBO
> retransmission process and congestion control for the destination
> endpoint. It is a general technique that would not be restricted to
> observe: it might also apply, for example, if the upper layers cancelled
> the transmission, but the lower layers had other messages to be
> transmitted to the same endpoint.  The superseding message need not have
> any relation to the superseded message in terms of purpose: all it does
> is advance the time at which a message is transmitted to a given
> endpoint, at (potentially) a cost to the number of retransmissions.

+1

Klaus

From cabo@tzi.org  Sun Oct 27 10:25:28 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 648F111E8295 for ; Sun, 27 Oct 2013 10:25:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.21
X-Spam-Level: 
X-Spam-Status: No, score=-106.21 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbytItnwpfNZ for ; Sun, 27 Oct 2013 10:25:18 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 022FE11E81A1 for ; Sun, 27 Oct 2013 10:25:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9RHP6BY009867; Sun, 27 Oct 2013 18:25:06 +0100 (CET)
Received: from [192.168.217.105] (p54891816.dip0.t-ipconnect.de [84.137.24.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 68B6AE02; Sun, 27 Oct 2013 18:25:05 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: 
Date: Sun, 27 Oct 2013 18:25:02 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <526D3A2E.4070604@pabigot.com> 
To: Klaus Hartke 
X-Mailer: Apple Mail (2.1816)
Cc: core 
Subject: Re: [core] Message supersedure as a domain concept
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 27 Oct 2013 17:25:28 -0000

On 27 Oct 2013, at 18:19, Klaus Hartke  wrote:

> I don't think that retaining the same message ID works. If the client
> implements deduplication based on the message ID, then it would reject
> the new representation as duplicate when it already received an old
> representation with the same message ID but the acknowledgement to the
> server was lost.

Worse: If the server receives an ACK, it does not know whether that =
acknowledges the old or the new state.  To maintain eventual =
consistency, it has to continue notifying the new state.

Gr=FC=DFe, Carsten


From pab@pabigot.com  Sun Oct 27 13:24:50 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA0811E82AA for ; Sun, 27 Oct 2013 13:24:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.521
X-Spam-Level: 
X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEavgJvoNreE for ; Sun, 27 Oct 2013 13:24:43 -0700 (PDT)
Received: from p3plsmtpa09-07.prod.phx3.secureserver.net (p3plsmtpa09-07.prod.phx3.secureserver.net [173.201.193.236]) by ietfa.amsl.com (Postfix) with ESMTP id 7F55311E8198 for ; Sun, 27 Oct 2013 13:24:43 -0700 (PDT)
Received: from [192.168.65.10] ([66.41.60.82]) by p3plsmtpa09-07.prod.phx3.secureserver.net with  id iLQf1m00N1mTNtu01LQguh; Sun, 27 Oct 2013 13:24:43 -0700
Message-ID: <526D7687.7070208@pabigot.com>
Date: Sun, 27 Oct 2013 15:24:39 -0500
From: "Peter A. Bigot" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Klaus Hartke 
References: <526D3A2E.4070604@pabigot.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: core 
Subject: Re: [core] Message supersedure as a domain concept
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 27 Oct 2013 20:24:50 -0000

On 10/27/2013 12:19 PM, Klaus Hartke wrote:
> Huge +1.

Thanks.

>> Now we come to observe, which proposes that under certain circumstances
>> the entire representation of a resource, along with the Observe option
>> value, must be changed prior to transport layer retransmission of a
>> confirmable message.
>
> More precisely, when a resource changes its state, the representation
> of that state changes.

I'm gonna nitpick here and say no, just because we're trying to be
really precise.

Requests and responses (not messages) carry resource representations,
but the representation belongs to the request or response, not to the
resource.  When the state (value) of a resource changes (internally or
by receiving a request that carries a representation) the representation
(encoding) *almost certainly, but not necessarily,* changes.  Consider a
content format that represents the resource by its SHA1 hash code.

Further, a representation that resides outside the resource (e.g., in a
pending notification) does not change.  If that were allowed we'd have
to figure out how to track down and replace those representations.  This
would be another way to model my first (wrong) alternative
interpretation of -observe, but is really messy.

The distinction makes no difference to the rest of your response, but it
is important to keep very clear that the resource state and its
representation are not the same thing or even in one-to-one
correspondence.

Therefore, to satisfy the expectations of -observe, what we say is when
the resource changes we SHOULD/MUST cancel all previous notifications
(if any), and MUST initiate the transmission of new notification for
each active observation transaction.

Further, the second notification MAY/MUST *supersede* (reference
definition) a cancelled notification.

(Slashes here separate design alternatives.)  (I do not think we should
try detect the really special case where the resource state changed but
the representation did not.)

As for the rest: With a little effort we could define message rejection
from the perspective of the sender of a confirmable message (can't do it
for non-confirmable message transmission for reasons I won't get into),
what cancellation of a confirmable message means, and how rejection
propagates to cancellation of higher-order entities like exchanges and
transactions.  Should also document the restrictions on when message
supersedure is appropriate (for observe it's a good technique; for other
situations it's not).  A couple more steps and we could define the
behavior of observe quite clearly in terms of more primitive concepts,
eliminating detailed steps and special cases.

Peter


From Akbar.Rahman@InterDigital.com  Sun Oct 27 13:37:13 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B8411E8198 for ; Sun, 27 Oct 2013 13:37:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-YrjCB3OCke for ; Sun, 27 Oct 2013 13:37:08 -0700 (PDT)
Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id C33DD11E81AB for ; Sun, 27 Oct 2013 13:37:03 -0700 (PDT)
Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675);  Sun, 27 Oct 2013 16:37:01 -0400
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Sun, 27 Oct 2013 16:36:56 -0400
Message-ID: 
In-Reply-To: <526D7687.7070208@pabigot.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [core] Message supersedure as a domain concept
Thread-Index: Ac7TUsj46UmlVJ0NTwqVACunZJ5N5QAAVdYQ
References: <526D3A2E.4070604@pabigot.com> <526D7687.7070208@pabigot.com>
From: "Rahman, Akbar" 
To: "Peter A. Bigot" , "Klaus Hartke" 
X-OriginalArrivalTime: 27 Oct 2013 20:37:01.0179 (UTC) FILETIME=[49F464B0:01CED354]
Cc: core 
Subject: Re: [core] Message supersedure as a domain concept
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 27 Oct 2013 20:37:13 -0000

Hi Peter/Klaus,


Thanks for the good definitions.  I found them extremely useful.  One =
na=EFve question.  Will these definitions be affected if DTLS is running =
underneath CoAP?


Akbar



-----Original Message-----
From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of =
Peter A. Bigot
Sent: Sunday, October 27, 2013 4:25 PM
To: Klaus Hartke
Cc: core
Subject: Re: [core] Message supersedure as a domain concept

On 10/27/2013 12:19 PM, Klaus Hartke wrote:
> Huge +1.

Thanks.

>> Now we come to observe, which proposes that under certain=20
>> circumstances the entire representation of a resource, along with the =

>> Observe option value, must be changed prior to transport layer=20
>> retransmission of a confirmable message.
>
> More precisely, when a resource changes its state, the representation=20
> of that state changes.

I'm gonna nitpick here and say no, just because we're trying to be =
really precise.

Requests and responses (not messages) carry resource representations, =
but the representation belongs to the request or response, not to the =
resource.  When the state (value) of a resource changes (internally or =
by receiving a request that carries a representation) the representation
(encoding) *almost certainly, but not necessarily,* changes.  Consider a =
content format that represents the resource by its SHA1 hash code.

Further, a representation that resides outside the resource (e.g., in a =
pending notification) does not change.  If that were allowed we'd have =
to figure out how to track down and replace those representations.  This =
would be another way to model my first (wrong) alternative =
interpretation of -observe, but is really messy.

The distinction makes no difference to the rest of your response, but it =
is important to keep very clear that the resource state and its =
representation are not the same thing or even in one-to-one =
correspondence.

Therefore, to satisfy the expectations of -observe, what we say is when =
the resource changes we SHOULD/MUST cancel all previous notifications =
(if any), and MUST initiate the transmission of new notification for =
each active observation transaction.

Further, the second notification MAY/MUST *supersede* (reference
definition) a cancelled notification.

(Slashes here separate design alternatives.)  (I do not think we should =
try detect the really special case where the resource state changed but =
the representation did not.)

As for the rest: With a little effort we could define message rejection =
from the perspective of the sender of a confirmable message (can't do it =
for non-confirmable message transmission for reasons I won't get into), =
what cancellation of a confirmable message means, and how rejection =
propagates to cancellation of higher-order entities like exchanges and =
transactions.  Should also document the restrictions on when message =
supersedure is appropriate (for observe it's a good technique; for other =
situations it's not).  A couple more steps and we could define the =
behavior of observe quite clearly in terms of more primitive concepts, =
eliminating detailed steps and special cases.

Peter

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

From pab@pabigot.com  Sun Oct 27 13:42:25 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 749EA11E82B2 for ; Sun, 27 Oct 2013 13:42:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Level: 
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDmAUotUpKmk for ; Sun, 27 Oct 2013 13:42:19 -0700 (PDT)
Received: from p3plsmtpa09-05.prod.phx3.secureserver.net (p3plsmtpa09-05.prod.phx3.secureserver.net [173.201.193.234]) by ietfa.amsl.com (Postfix) with ESMTP id DE60B11E82AA for ; Sun, 27 Oct 2013 13:42:16 -0700 (PDT)
Received: from [192.168.65.10] ([66.41.60.82]) by p3plsmtpa09-05.prod.phx3.secureserver.net with  id iLiD1m00F1mTNtu01LiEqD; Sun, 27 Oct 2013 13:42:16 -0700
Message-ID: <526D7AA5.7060904@pabigot.com>
Date: Sun, 27 Oct 2013 15:42:13 -0500
From: "Peter A. Bigot" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: "Rahman, Akbar" ,  Klaus Hartke 
References: <526D3A2E.4070604@pabigot.com> <526D7687.7070208@pabigot.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: core 
Subject: Re: [core] Message supersedure as a domain concept
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 27 Oct 2013 20:42:25 -0000

On 10/27/2013 03:36 PM, Rahman, Akbar wrote:
> Hi Peter/Klaus,
>
> Thanks for the good definitions.  I found them extremely useful.  One
> nave question.  Will these definitions be affected if DTLS is
> running underneath CoAP?

I haven't looked at the DTLS interface for CoAP, but from my perspective 
they MUST NOT be affected.  If they are, they (or the DTLS abstraction 
for CoAP) need to be fixed.  I would expect DTLS to be a transport-layer 
wrapper; at most, it might introduce a new mechanism by which a message 
is rejected.

Again, though: haven't researched it, can't say for sure.

Peter

From kovatsch@inf.ethz.ch  Sun Oct 27 14:16:22 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD4511E82C4 for ; Sun, 27 Oct 2013 14:16:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.155
X-Spam-Level: 
X-Spam-Status: No, score=-8.155 tagged_above=-999 required=5 tests=[AWL=-1.556, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4nX2BYMzZzF for ; Sun, 27 Oct 2013 14:16:15 -0700 (PDT)
Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) by ietfa.amsl.com (Postfix) with ESMTP id 7778811E82C2 for ; Sun, 27 Oct 2013 14:16:13 -0700 (PDT)
Received: from CAS11.d.ethz.ch (172.31.38.211) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.2.298.4; Sun, 27 Oct 2013 22:16:06 +0100
Received: from MBX210.d.ethz.ch ([fe80::ed77:7d47:9467:69a9]) by CAS11.d.ethz.ch ([fe80::ecc9:4e2d:b26b:1614%10]) with mapi id 14.02.0298.004; Sun, 27 Oct 2013 22:16:11 +0100
From: "Kovatsch  Matthias" 
To: Carsten Bormann , Klaus Hartke 
Thread-Topic: [core] Message supersedure as a domain concept
Thread-Index: AQHO0y7MLCecoH3MyUq/Ln6mDBB8ZJoIujiAgAABlgCAAEAIcA==
Date: Sun, 27 Oct 2013 21:16:10 +0000
Message-ID: <55877B3AFB359744BA0F2140E36F52B515C292A9@MBX210.d.ethz.ch>
References: <526D3A2E.4070604@pabigot.com>  
In-Reply-To: 
Accept-Language: en-US, de-CH
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [88.209.34.29]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: core 
Subject: Re: [core] Message supersedure as a domain concept
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 27 Oct 2013 21:16:22 -0000

> > I don't think that retaining the same message ID works. If the client
> > implements deduplication based on the message ID, then it would reject
> > the new representation as duplicate when it already received an old
> > representation with the same message ID but the acknowledgement to
> the
> > server was lost.

Just to clarify: The deduplication mechanism must send the same reply as fo=
r the first message. An endpoint cannot reject a message that it previously=
 acknowledged and successfully forwarded to the application.

> Worse: If the server receives an ACK, it does not know whether that
> acknowledges the old or the new state.  To maintain eventual consistency,=
 it
> has to continue notifying the new state.

Okay, then we need not only clear text on the MID (only the long discussion=
 revealed what is actually intended), but figure out how to solve the Token=
 lifetime (when is it in use by any party) issue. Honestly, I lost track ab=
out the current status here with all the excursions...

My notes:
- A Token is in use until the (final) matching response is received
- For Groupcomm this is hard to decide; practically, we need NON_LIFETIME h=
ere
- Observe even extends the scope of the Token towards the server and the To=
ken is active until both client and server have consensus on a Observe canc=
ellation
- With Observe the client even loses sovereignty over the Token, since it d=
epends on the server to send a CON notification for cancellation
- Since a RST can get lost, the Token must be considered in use for EXCHANG=
E_LIFETIME after rejecting a CON notification

Ciao
Matthias


From pab@pabigot.com  Sun Oct 27 17:07:44 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F8311E82DA for ; Sun, 27 Oct 2013 17:07:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.526
X-Spam-Level: 
X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+iwk3F6HPQn for ; Sun, 27 Oct 2013 17:07:33 -0700 (PDT)
Received: from p3plsmtpa09-05.prod.phx3.secureserver.net (p3plsmtpa09-05.prod.phx3.secureserver.net [173.201.193.234]) by ietfa.amsl.com (Postfix) with ESMTP id C74C911E82D8 for ; Sun, 27 Oct 2013 17:07:23 -0700 (PDT)
Received: from [192.168.65.10] ([66.41.60.82]) by p3plsmtpa09-05.prod.phx3.secureserver.net with  id iQ7M1m0081mTNtu01Q7MWP; Sun, 27 Oct 2013 17:07:22 -0700
Message-ID: <526DAAB9.3010702@pabigot.com>
Date: Sun, 27 Oct 2013 19:07:21 -0500
From: "Peter A. Bigot" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: core@ietf.org
References: <526D3A2E.4070604@pabigot.com>		 <55877B3AFB359744BA0F2140E36F52B515C292A9@MBX210.d.ethz.ch>
In-Reply-To: <55877B3AFB359744BA0F2140E36F52B515C292A9@MBX210.d.ethz.ch>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [core] Message supersedure as a domain concept
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Oct 2013 00:07:44 -0000

> My notes:
> - A Token is in use until the (final) matching response is received
> - For Groupcomm this is hard to decide; practically, we need NON_LIFETIME here
> - Observe even extends the scope of the Token towards the server and the Token is active until both client and server have consensus on a Observe cancellation
> - With Observe the client even loses sovereignty over the Token, since it depends on the server to send a CON notification for cancellation
> - Since a RST can get lost, the Token must be considered in use for EXCHANGE_LIFETIME after rejecting a CON notification

Let's approach token lifetime from a different direction.

Assume client C establishes observe relations with two resources R1 and
R2 hosted by server S, using tokens T1 and T2.  Then assume client C
resets, losing all knowledge of the state of its connections with S.  It
needs to re-establish the observe relations.  How does it do so without
responses from previous observations being mis-interpreted?

Consider that without some sort of constraint it might re-establish the
relationship with the tokens swapped so T2 is used for R1 and T1 for R2.
In that case, each time either R1 or R2 changes two notifications would
be sent, one for each token.  There is nothing inherent about the
subsequent exchanges that would allow the client to detect the problem.
Is the server obliged to diagnose this?

One solution would be to require that the client reserve unique tokens
for any observe relationship it might establish.  Is this reasonable?

Peter

From Bert.Greevenbosch@huawei.com  Sun Oct 27 17:17:42 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0C611E82E3 for ; Sun, 27 Oct 2013 17:17:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2eYOPvj2rq4U for ; Sun, 27 Oct 2013 17:17:38 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9A08B11E82DF for ; Sun, 27 Oct 2013 17:17:37 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZN80599; Mon, 28 Oct 2013 00:17:33 +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; Mon, 28 Oct 2013 00:17:19 +0000
Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 28 Oct 2013 00:17:32 +0000
Received: from szxeml558-mbx.china.huawei.com ([169.254.7.217]) by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.03.0146.000; Mon, 28 Oct 2013 08:17:24 +0800
From: Bert Greevenbosch 
To: Juergen Schoenwaelder 
Thread-Topic: Reponse to comments on CoMI
Thread-Index: AQHO03MTUqfbFpvRxESMcfhzsb1JrQ==
Date: Mon, 28 Oct 2013 00:17:23 +0000
Message-ID: <46A1DF3F04371240B504290A071B4DB63D952C37@szxeml558-mbx.china.huawei.com>
References:  <525BC2E0.9060500@cisco.com> <20131014101332.GD21123@elstar.local> <525D4721.6020501@cisco.com>  <0485D1EA-BEA1-4F54-9A88-74B209D57490@tzi.org>  <2d4d1eb8aa0649e53175098d5c2087ad@xs4all.nl> <20131017103905.GF31344@elstar.local>
In-Reply-To: <20131017103905.GF31344@elstar.local>
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 WG" 
Subject: [core] Reponse to comments on CoMI
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Oct 2013 00:17:42 -0000

Hi Juergen,

Thanks a lot for your comments. They are very helpful.

Peter and I have discussed them, and please find our response inline.

Best regards,
Bert


On Thu, Oct 17, 2013 at 11:53:28AM +0200, peter van der Stok wrote:
> >
> > Bert Greevenbosch and I have submitted a new draft on access to MIBs
> > via a CoAP interface.
> > We discuss a number of payload formats to investigate the
> > consequences of the choice.
> > A later version should concentrate on 1 (at most 2) formats.
> >
>=20
> A couple of quick comments:
>=20
> - Take a look at RFC 4088. In particular, you need to deal with
>   contexts to comply to the SNMP framework and you need to deal with
>   descriptors not necessarily being unique.

That is why we can specify the OID in the link format, and allow direct spe=
cification in JSON and CBOR of OID instead of descriptors too. The link for=
mat fixes the association between descriptor and OID.

Also we return (possibly multiple) information when multiple descriptors co=
rrespond with the specified descriptor.

> - The JSON type mapping is a bit too simplistic (e.g. what you render
>   as a string and what you ship as base64 encoded value in case of
>   JSON should likely depend on the type definition and not be
>   hardwired).

I think we could use information from the SMI type definition, similar as i=
n regular SNMP. However in CoMI we have not mandated availability of the SM=
I definition to the managing entity.

Originally, we had a "tuple" JSON definition in our draft, which allowed sp=
ecifying SMI type as well, however, for simplicity, we removed it. Conseque=
ntly, it is hard to distinguish objects from the type e.g. between a counte=
r, TimeTicks and an integer without secondary information from e.g. the SMI=
 definition or hint in the name of the variable.

Indeed omitting the Base64 encoding may make sense in some cases, e.g. when=
 the OCTET-STRING contains human-readable text.

But what counts is that the value is correctly transmitted, the type puts r=
estrictions on the variable values, but these values are already guaranteed=
 at the end points where the MIB and its type is known.

> - It might make sense to look what you get by taking a MIB module and
>   applying RFC 6643 to it. This gives you an XML serialization fully
>   defined today. And when you apply the JSON serialization of YANG,
>   currently defined in , you also
>   get a JSON serialization. The 6LoWPAN and RPL MIB modules have
>   examples of such serializations included I think.

We have thought about this aspect, but naively it seems complex to do this =
tandem coding
  =20
MIB -  YANG/XML -  JSON.

On the other hand, the examples in

   http://tools.ietf.org/id/draft-schoenw-6lowpan-mib-03.txt
   http://tools.ietf.org/id/draft-sehgal-roll-rpl-mib-06.txt

look quite nice, and are not that distant from our own solution. We will pu=
t some more time in investigating this.

> - Since counters are having discontinuity indicatores (defaulting to
>   sysUpTime), you need to provide primitives that allow you to
>   retrieve data from different branches of the OID number space.

We do have some problems understanding this remark.

Do you mean:
1)	going through oid space as specified for bulk transport and as suggested=
 in RFC 4088 with the suffixes to the oid specification?
2)	specifying multiple MIB variables as specified with snmp (oid, value) pa=
ir, which permits the inclusion of sysUpTime in every request. The latter w=
e support in section 3.2.2
3)	or something else?.

> - The SNMP framework has security and access control built into it.
>   It will be necessary at some point in time to explain how CoAP
>   access to MIB data relates to this - or if this is at least
>   conceptually a complete independent side channel to access the data
>   without access control at all. If its not a side channel, you need
>   to discuss how a securityName etc is provided for SNMP's access
>   control model to function.

This depends on CoRE authentication and authorisation. I think it is a bit =
too early to resolve now, but it needs to be resolved some day (as part of =
CoMI v1) for sure.

> Well, the security part is likely not yet that important. ;-)
>=20
> I do not want to sound in any way negative. I appreciate that someone
> is working on this. I am actually trying to provide help. ;-)
>=20
> /js

From wasilak@gmail.com  Mon Oct 28 02:05:31 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E434E11E8236 for ; Mon, 28 Oct 2013 02:05:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5UAaB43OXKu for ; Mon, 28 Oct 2013 02:05:27 -0700 (PDT)
Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 6175911E8106 for ; Mon, 28 Oct 2013 02:05:24 -0700 (PDT)
Received: by mail-wg0-f49.google.com with SMTP id x12so6150406wgg.28 for ; Mon, 28 Oct 2013 02:05:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XLvRz7jETSTF98SQ6Z7S8gKyYWBM2HYgjEo9wRsmdgM=; b=A6UUi9Xa3/DgEGakFJZ/6MWKygJvtF97ZMxmoNcgawCl6jNxMOOfy7GRRxeMIXAXZM PVJWkCqwWZ7jaZZr5NHQ0uZWYjXAjxR7EMP3XTMnvVpbmU4dLQNHKkU2cNiUpBx8tE9Y 3nERaU4+nC6zdB1xv8Rj0ZiXeprJw5HD/jDefT1lhcKH/Uk6HWlsKU1RbwMwPxM4cpRd eU0kBgnkCaQeY9ORNm40x6dwSedoFMR75r2JcI99oaiJUjqQG2xV+2tS4xocy+hDmfrv UslhkJBX5EfMInJBlY68QsM6jqLG4XemCWgPTeibjZYQz67kbYAR4ALSh/cdayJoqIMr TzSA==
MIME-Version: 1.0
X-Received: by 10.194.19.5 with SMTP id a5mr893279wje.48.1382951121728; Mon, 28 Oct 2013 02:05:21 -0700 (PDT)
Received: by 10.217.119.70 with HTTP; Mon, 28 Oct 2013 02:05:21 -0700 (PDT)
In-Reply-To: <526DAAB9.3010702@pabigot.com>
References: <526D3A2E.4070604@pabigot.com>   <55877B3AFB359744BA0F2140E36F52B515C292A9@MBX210.d.ethz.ch> <526DAAB9.3010702@pabigot.com>
Date: Mon, 28 Oct 2013 10:05:21 +0100
Message-ID: 
From: Maciej Wasilak 
To: "Peter A. Bigot" 
Content-Type: multipart/alternative; boundary=047d7b450a0e5a40ef04e9c96656
Cc: core WG 
Subject: Re: [core] Message supersedure as a domain concept
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Oct 2013 09:05:31 -0000

--047d7b450a0e5a40ef04e9c96656
Content-Type: text/plain; charset=UTF-8

> Consider that without some sort of constraint it might re-establish the
> relationship with the tokens swapped so T2 is used for R1 and T1 for R2.
> In that case, each time either R1 or R2 changes two notifications would
> be sent, one for each token.  There is nothing inherent about the
> subsequent exchanges that would allow the client to detect the problem.
> Is the server obliged to diagnose this?
>
> One solution would be to require that the client reserve unique tokens
> for any observe relationship it might establish.  Is this reasonable?
>

One solution is to key entries in the list of observers on server by a
tuple (uri_path, client_endpoint) - as it is currently with blockwise
transfers. New request from the same client to the same resource would
overwrite the old one.

Maciek

--047d7b450a0e5a40ef04e9c96656
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=


Consider that without some sort of constraint it might re-establish the

relationship with the tokens swapped so T2 is used for R1 and T1 for R2.
In that case, each time either R1 or R2 changes two notifications would

be sent, one for each token. =C2=A0There is nothing inherent about the

subsequent exchanges that would allow the client to detect the problem.

Is the server obliged to diagnose this?



One solution would be to require that the client reserve unique tokens

for any observe relationship it might establish. =C2=A0Is this reasonable?<=
span class=3D"HOEnZb">



One s=
olution is to key entries in the list of observers on server by a tuple (ur=
i_path, client_endpoint) - as it is currently with blockwise transfers. New=
 request from the same client to the same resource would overwrite the old =
one. 


Maciek


--047d7b450a0e5a40ef04e9c96656--

From hartke@tzi.org  Mon Oct 28 03:58:50 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74F6B21F9D65 for ; Mon, 28 Oct 2013 03:58:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.627
X-Spam-Level: 
X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-N5XYmAbvYJ for ; Mon, 28 Oct 2013 03:58:44 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 9522711E8163 for ; Mon, 28 Oct 2013 03:58:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9SAwaJr001609 for ; Mon, 28 Oct 2013 11:58:36 +0100 (CET)
Received: from mail-vb0-f51.google.com (mail-vb0-f51.google.com [209.85.212.51]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 8B271160 for ; Mon, 28 Oct 2013 11:58:36 +0100 (CET)
Received: by mail-vb0-f51.google.com with SMTP id x16so5139581vbf.24 for ; Mon, 28 Oct 2013 03:58:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=PuDNgcVTLb8hAJwUrasZlWr46fAaO44CY3ADa74/aPM=; b=ZlTpWA581AQekgipa4LFuzPDgbdOr3nLv8PF1wPf5gVA18vRRjvnKLe9D1YINtdOEh YSxjz+RPsU1Dwx+o3Fmb9eTiKmddMkZ7NJ+n66g6YH0LD4f3lybaPApBhuY0GmBNfEm6 CCILKhIRgMVXLzMfGOmCx1Glu5P2hOkE0ccZ9e63rQAChz5X7cNxhbEP0t/PIet9CgYH C/Y3eGpnhCyEoGs68mEhCGfd9ntFVCcq0aVzvlXcW/O9gQUeKWDP3uo1/VfjGvQH+D01 wN7D0v0crmrZZrRkSyhxDYflJ5K4glXA5eIChYKqni1hpYsQgjpJ/XVTNmo+Od4sFIrN 75kA==
X-Received: by 10.52.100.202 with SMTP id fa10mr10934724vdb.0.1382957915196; Mon, 28 Oct 2013 03:58:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.102.100 with HTTP; Mon, 28 Oct 2013 03:57:55 -0700 (PDT)
In-Reply-To: <526DAAB9.3010702@pabigot.com>
References: <526D3A2E.4070604@pabigot.com>   <55877B3AFB359744BA0F2140E36F52B515C292A9@MBX210.d.ethz.ch> <526DAAB9.3010702@pabigot.com>
From: Klaus Hartke 
Date: Mon, 28 Oct 2013 12:57:55 +0200
Message-ID: 
To: "Peter A. Bigot" 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "core@ietf.org WG" 
Subject: Re: [core] Message supersedure as a domain concept
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Oct 2013 10:58:50 -0000

Peter A. Bigot wrote:
> Assume client C establishes observe relations with two resources R1 and
> R2 hosted by server S, using tokens T1 and T2.  Then assume client C
> resets, losing all knowledge of the state of its connections with S.  It
> needs to re-establish the observe relations.  How does it do so without
> responses from previous observations being mis-interpreted?
>
> Consider that without some sort of constraint it might re-establish the
> relationship with the tokens swapped so T2 is used for R1 and T1 for R2.
> In that case, each time either R1 or R2 changes two notifications would
> be sent, one for each token.  There is nothing inherent about the
> subsequent exchanges that would allow the client to detect the problem.
> Is the server obliged to diagnose this?

Assume we have the following sequence of events:

1. S has (C,T1) in the list of observers of R1, and (C,T2) in the list
of observers of R2.
2. C resets, losing all knowledge of tokens previously used.
3. C sends requests to re-establish observations with the tokens
swapped so T2 is used for R1 and T1 for R2.
4. The state of R1 changes and the server sends a notification to C with T1.
5. C receives the notification and believes it is a notification for R2.
6. S receives C's requests and informs C with some kind of error
messages that T1 and T2 are still in use.
-or-
6. S receives C's requests and cancels the existing observations and
creates new observations.

It doesn't really matter what the server does in step 6, because the
mishap already occurred in step 5.

This is, by the way, not specific to -observe:

0. C makes a GET/POST/PUT/DELETE request with token T3.
1. S receives the request and returns an empty Acknowledgement.
2. C resets, losing all knowledge of tokens previously used.
3. C makes a new, unrelated request with the same token T3.
4. The processing of the request from step 0 completes and the server
sends a separate response to C with T3.
5. C receives the separate response and believes it is the response for step 3.
6. S receives C's request from step 3, and so on.

The question is, when does this actually happen?

If we use CoAP over DTLS or WebSockets, then all responses are
returned over the same connection as the request, and all tokens are
local to the connection. When a client resets, it creates a new
connection. So any token from a previous connection can be freely
reused.

If we use CoAP over UDP, then -coap recommends the client to use a
non-trivial, randomized token with at least 32 bits of randomness for
each new request. It's also a good idea to randomize the client port
number when a client resets. So, while not impossible, it's quite
unlikely that a client accidentally makes a request from the same port
with a token that is still in use.

Klaus

From pab@pabigot.com  Mon Oct 28 04:43:08 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13C3A11E8242 for ; Mon, 28 Oct 2013 04:43:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.528
X-Spam-Level: 
X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pER8L5Ic8od7 for ; Mon, 28 Oct 2013 04:43:02 -0700 (PDT)
Received: from p3plsmtpa09-04.prod.phx3.secureserver.net (p3plsmtpa09-04.prod.phx3.secureserver.net [173.201.193.233]) by ietfa.amsl.com (Postfix) with ESMTP id E75DB21F9DAD for ; Mon, 28 Oct 2013 04:42:54 -0700 (PDT)
Received: from [192.168.65.10] ([66.41.60.82]) by p3plsmtpa09-04.prod.phx3.secureserver.net with  id ibip1m00H1mTNtu01bip24; Mon, 28 Oct 2013 04:42:50 -0700
Message-ID: <526E4DB9.4020501@pabigot.com>
Date: Mon, 28 Oct 2013 06:42:49 -0500
From: "Peter A. Bigot" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Maciej Wasilak 
References: <526D3A2E.4070604@pabigot.com>			<55877B3AFB359744BA0F2140E36F52B515C292A9@MBX210.d.ethz.ch>	<526DAAB9.3010702@pabigot.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: core WG 
Subject: Re: [core] Message supersedure as a domain concept
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Oct 2013 11:43:08 -0000

On 10/28/2013 04:05 AM, Maciej Wasilak wrote:
>
>     Consider that without some sort of constraint it might re-establish the
>     relationship with the tokens swapped so T2 is used for R1 and T1 for R2.
>     In that case, each time either R1 or R2 changes two notifications would
>     be sent, one for each token.  There is nothing inherent about the
>     subsequent exchanges that would allow the client to detect the problem.
>     Is the server obliged to diagnose this?
>
>     One solution would be to require that the client reserve unique tokens
>     for any observe relationship it might establish.  Is this reasonable?
>
>
> One solution is to key entries in the list of observers on server by a
> tuple (uri_path, client_endpoint) - as it is currently with blockwise
> transfers. New request from the same client to the same resource would
> overwrite the old one.

Could work.  This inhibits a client from observing the same resource 
with distinct Content-Format options, which might be desirable.

Peter

From pab@pabigot.com  Mon Oct 28 04:58:24 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE1611E824A for ; Mon, 28 Oct 2013 04:58:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.531
X-Spam-Level: 
X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFnCMv+BYhTz for ; Mon, 28 Oct 2013 04:58:18 -0700 (PDT)
Received: from p3plsmtpa09-04.prod.phx3.secureserver.net (p3plsmtpa09-04.prod.phx3.secureserver.net [173.201.193.233]) by ietfa.amsl.com (Postfix) with ESMTP id B8CEE11E8144 for ; Mon, 28 Oct 2013 04:58:13 -0700 (PDT)
Received: from [192.168.65.10] ([66.41.60.82]) by p3plsmtpa09-04.prod.phx3.secureserver.net with  id ibyB1m00T1mTNtu01byCSV; Mon, 28 Oct 2013 04:58:13 -0700
Message-ID: <526E5154.7060307@pabigot.com>
Date: Mon, 28 Oct 2013 06:58:12 -0500
From: "Peter A. Bigot" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Klaus Hartke 
References: <526D3A2E.4070604@pabigot.com>   <55877B3AFB359744BA0F2140E36F52B515C292A9@MBX210.d.ethz.ch> <526DAAB9.3010702@pabigot.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "core@ietf.org WG" 
Subject: Re: [core] Message supersedure as a domain concept
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Oct 2013 11:58:24 -0000

On 10/28/2013 05:57 AM, Klaus Hartke wrote:
> If we use CoAP over DTLS or WebSockets, then all responses are
> returned over the same connection as the request, and all tokens are
> local to the connection. When a client resets, it creates a new
> connection. So any token from a previous connection can be freely
> reused.

This is a good point, but CoAP doesn't require use of these techniques 
so all they do is provide a robust solution in a special case.  The 
protocol-level general case remains.

> If we use CoAP over UDP, then -coap recommends the client to use a
> non-trivial, randomized token with at least 32 bits of randomness for
> each new request. It's also a good idea to randomize the client port
> number when a client resets. So, while not impossible, it's quite
> unlikely that a client accidentally makes a request from the same port
> with a token that is still in use.

Token randomization is discussed only in terms of security; if I don't 
care whether somebody sees the temperature and humidity in my 
greenhouse, I probably wouldn't bother with it, especially if I don't 
have a good source of randomness in the first couple seconds after my 
MCU powers up.

I don't think randomizing the client port number is explicitly 
recommended, and besides I'd probably use the same socket as both client 
and server so the source port will generally be 5683.

If the best we can do is "probably won't happen", that's fine.

Though then we don't get any help understanding what token lifetime 
should be.  My point in raising the question was that a client reset is 
one of the things that causes the token lifetime to end from the 
client's perspective while servers may still be using it.  It happens 
with and without observe, as you note, so it's a general issue; it's 
just worse with observe because it's ongoing, and observe is one place 
where it might be possible to have the client cancel it.

Peter

From cabo@tzi.org  Mon Oct 28 05:42:38 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61AD011E8254 for ; Mon, 28 Oct 2013 05:42:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.211
X-Spam-Level: 
X-Spam-Status: No, score=-106.211 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jI8iAxP3lES7 for ; Mon, 28 Oct 2013 05:42:32 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 34ADF11E8110 for ; Mon, 28 Oct 2013 05:42:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9SCgSD4000579; Mon, 28 Oct 2013 13:42:28 +0100 (CET)
Received: from [192.168.217.105] (p54891CC7.dip0.t-ipconnect.de [84.137.28.199]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4689C255; Mon, 28 Oct 2013 13:42:27 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann 
In-Reply-To: <526E5154.7060307@pabigot.com>
Date: Mon, 28 Oct 2013 13:42:25 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <5EB59DC7-3E11-4258-A85A-B63808DF3500@tzi.org>
References: <526D3A2E.4070604@pabigot.com>   <55877B3AFB359744BA0F2140E36F52B515C292A9@MBX210.d.ethz.ch> <526DAAB9.3010702@pabigot.com>  <526E5154.7060307@pabigot.com>
To: "Peter A. Bigot" 
X-Mailer: Apple Mail (2.1816)
Cc: "core@ietf.org WG" , Klaus Hartke 
Subject: Re: [core] Message supersedure as a domain concept
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Oct 2013 12:42:38 -0000

On 28 Oct 2013, at 12:58, Peter A. Bigot  wrote:

> Token randomization is discussed only in terms of security;

Indeed.  If the security objectives are met in some other way, using the =
same (e.g., empty) token until it is kept busy by an empty ACK (separate =
response) or an observation relationship is a quite viable strategy.

> I don't think randomizing the client port number is explicitly =
recommended, and besides I'd probably use the same socket as both client =
and server so the source port will generally be 5683.

I imagine many constrained implementations will do something simple like =
this.

(It is probably a good idea to combine token randomness with some client =
port randomness in powerful clients.  But we don=92t have to go to the =
lengths DNS clients do these days.)

> Though then we don't get any help understanding what token lifetime =
should be. =20

We need to write this up; my plan was to have some of that in =
draft-kovatsch-lwig-coap.
The discussion here seems to show that we probably have to add some =
requirements on the server to make the rules really useful.

Gr=FC=DFe, Carsten


From pab@pabigot.com  Mon Oct 28 09:14:50 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B27EF11E827C for ; Mon, 28 Oct 2013 09:14:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.533
X-Spam-Level: 
X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JW4BA-W-213 for ; Mon, 28 Oct 2013 09:14:44 -0700 (PDT)
Received: from p3plsmtpa09-08.prod.phx3.secureserver.net (p3plsmtpa09-08.prod.phx3.secureserver.net [173.201.193.237]) by ietfa.amsl.com (Postfix) with ESMTP id 87A5111E818A for ; Mon, 28 Oct 2013 09:14:43 -0700 (PDT)
Received: from [192.168.65.10] ([66.41.60.82]) by p3plsmtpa09-08.prod.phx3.secureserver.net with  id igEg1m00R1mTNtu01gEhJw; Mon, 28 Oct 2013 09:14:42 -0700
Message-ID: <526E8D71.4080007@pabigot.com>
Date: Mon, 28 Oct 2013 11:14:41 -0500
From: "Peter A. Bigot" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: core 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [core] MAX_TRANSMIT_WAIT vs EXCHANGE_LIFETIME
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Oct 2013 16:14:50 -0000

coap-18 section 4.8.2 has:

    o  MAX_TRANSMIT_WAIT is the maximum time from the first transmission
       of a Confirmable message to the time when the sender gives up on
       receiving an acknowledgement or reset.

    o  EXCHANGE_LIFETIME is the time from starting to send a Confirmable
       message to the time when an acknowledgement is no longer expected,
       i.e.  message layer information about the message exchange can be
       purged.

I'm not able to grasp the difference between these two concepts.  I
understand there are two calculations (elided) that produce a different
number, but not why each description supports a different calculation.
(The difference appears to be that EXCHANGE_LIFETIME takes into account
MAX_LATENCY while MAX_TRANSMIT_WAIT assumes the reply message
transmission takes zero time, but that makes MAX_TRANSMIT_WAIT an
unrealistic and useless number.)

It would make some sense if (using my nomenclature), MAX_TRANSMIT_WAIT
was the time in which a reply message (ACK/RST) must be received while
EXCHANGE_LIFETIME relaxes this to support an implicit acknowledgment
inferred from other information such as a response message.  But the
explicit reference to "message layer information can be purged" suggests
this isn't what was intended.

Clarification, please?  Should MAX_TRANSMIT_WAIT just be ignored as
useless?  It seems to serve no role in the protocol.

(Context: I'm trying to figure out how long the sender of a confirmable
or non-confirmable message must wait before being able to commit to the
success or failure of the transmission, as defined by the senders best
guess as to whether the recipient accepted or rejected the message.  It
appears this is not defined.)

Peter


From j.schoenwaelder@jacobs-university.de  Mon Oct 28 09:51:49 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBBB21E80B5 for ; Mon, 28 Oct 2013 09:51:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.222
X-Spam-Level: 
X-Spam-Status: No, score=-103.222 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHWYDr-+E4t1 for ; Mon, 28 Oct 2013 09:51:45 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 64F9B21E8056 for ; Mon, 28 Oct 2013 09:51:10 -0700 (PDT)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 938AD2008A; Mon, 28 Oct 2013 17:51:09 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id OpNlkhgOBe5c; Mon, 28 Oct 2013 17:51:09 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 23D262007F; Mon, 28 Oct 2013 17:51:09 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 84D0E2913174; Mon, 28 Oct 2013 17:51:03 +0100 (CET)
Date: Mon, 28 Oct 2013 17:51:02 +0100
From: Juergen Schoenwaelder 
To: Bert Greevenbosch 
Message-ID: <20131028165102.GA48502@elstar.local>
Mail-Followup-To: Bert Greevenbosch , "consultancy@vanderstok.org" , "core@ietf.org WG" 
References:  <525BC2E0.9060500@cisco.com> <20131014101332.GD21123@elstar.local> <525D4721.6020501@cisco.com>  <0485D1EA-BEA1-4F54-9A88-74B209D57490@tzi.org>  <2d4d1eb8aa0649e53175098d5c2087ad@xs4all.nl> <20131017103905.GF31344@elstar.local> <46A1DF3F04371240B504290A071B4DB63D952C37@szxeml558-mbx.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <46A1DF3F04371240B504290A071B4DB63D952C37@szxeml558-mbx.china.huawei.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "core@ietf.org WG" 
Subject: Re: [core] Reponse to comments on CoMI
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Oct 2013 16:51:49 -0000

On Mon, Oct 28, 2013 at 12:17:23AM +0000, Bert Greevenbosch wrote:
> Hi Juergen,
> 
> Thanks a lot for your comments. They are very helpful.
> 
> Peter and I have discussed them, and please find our response inline.
> 
> Best regards,
> Bert
> 
> 
> On Thu, Oct 17, 2013 at 11:53:28AM +0200, peter van der Stok wrote:
> > >
> > > Bert Greevenbosch and I have submitted a new draft on access to MIBs
> > > via a CoAP interface.
> > > We discuss a number of payload formats to investigate the
> > > consequences of the choice.
> > > A later version should concentrate on 1 (at most 2) formats.
> > >
> > 
> > A couple of quick comments:
> > 
> > - Take a look at RFC 4088. In particular, you need to deal with
> >   contexts to comply to the SNMP framework and you need to deal with
> >   descriptors not necessarily being unique.
> 
> That is why we can specify the OID in the link format, and allow direct specification in JSON and CBOR of OID instead of descriptors too. The link format fixes the association between descriptor and OID.
> 
> Also we return (possibly multiple) information when multiple descriptors correspond with the specified descriptor.

I likely do not understand. An example might help me, in particular
when it comes to non default SNMP contexts.
 
> > - The JSON type mapping is a bit too simplistic (e.g. what you render
> >   as a string and what you ship as base64 encoded value in case of
> >   JSON should likely depend on the type definition and not be
> >   hardwired).
> 
> I think we could use information from the SMI type definition, similar as in regular SNMP. However in CoMI we have not mandated availability of the SMI definition to the managing entity.
> 
> Originally, we had a "tuple" JSON definition in our draft, which allowed specifying SMI type as well, however, for simplicity, we removed it. Consequently, it is hard to distinguish objects from the type e.g. between a counter, TimeTicks and an integer without secondary information from e.g. the SMI definition or hint in the name of the variable.
> 
> Indeed omitting the Base64 encoding may make sense in some cases, e.g. when the OCTET-STRING contains human-readable text.
> 
> But what counts is that the value is correctly transmitted, the type puts restrictions on the variable values, but these values are already guaranteed at the end points where the MIB and its type is known.

You need to have clear rules. Right now, you use string notation for
some OCTET STRINGS (e.g. udpEndpointLocalAddress) while the table says
Base64 encoded string.

> > - It might make sense to look what you get by taking a MIB module and
> >   applying RFC 6643 to it. This gives you an XML serialization fully
> >   defined today. And when you apply the JSON serialization of YANG,
> >   currently defined in , you also
> >   get a JSON serialization. The 6LoWPAN and RPL MIB modules have
> >   examples of such serializations included I think.
> 
> We have thought about this aspect, but naively it seems complex to do this tandem coding
>    
> MIB -  YANG/XML -  JSON.
> 
> On the other hand, the examples in
> 
>    http://tools.ietf.org/id/draft-schoenw-6lowpan-mib-03.txt
>    http://tools.ietf.org/id/draft-sehgal-roll-rpl-mib-06.txt
> 
> look quite nice, and are not that distant from our own solution. We will put some more time in investigating this.

There is no 'tandem coding' (or more precisely I do not know what this
phrase means).

> > - Since counters are having discontinuity indicatores (defaulting to
> >   sysUpTime), you need to provide primitives that allow you to
> >   retrieve data from different branches of the OID number space.
> 
> We do have some problems understanding this remark.
> 
> Do you mean:
> 1)	going through oid space as specified for bulk transport and as suggested in RFC 4088 with the suffixes to the oid specification?
> 2)	specifying multiple MIB variables as specified with snmp (oid, value) pair, which permits the inclusion of sysUpTime in every request. The latter we support in section 3.2.2
> 3)	or something else?.

Section 3.2.2 _might_ cover this.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From cabo@tzi.org  Mon Oct 28 10:04:42 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63E1211E8187 for ; Mon, 28 Oct 2013 10:04:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.212
X-Spam-Level: 
X-Spam-Status: No, score=-106.212 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpargR4UIZcx for ; Mon, 28 Oct 2013 10:04:36 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id B268D11E8232 for ; Mon, 28 Oct 2013 10:04:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9SH4WJ1009565; Mon, 28 Oct 2013 18:04:32 +0100 (CET)
Received: from [192.168.217.105] (p54891CC7.dip0.t-ipconnect.de [84.137.28.199]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 42C1A490; Mon, 28 Oct 2013 18:04:32 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann 
In-Reply-To: <526E8D71.4080007@pabigot.com>
Date: Mon, 28 Oct 2013 18:04:29 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <668E99A0-5E2B-418E-AA4D-045479233F9A@tzi.org>
References: <526E8D71.4080007@pabigot.com>
To: "Peter A. Bigot" 
X-Mailer: Apple Mail (2.1816)
Cc: core 
Subject: Re: [core] MAX_TRANSMIT_WAIT vs EXCHANGE_LIFETIME
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Oct 2013 17:04:42 -0000

On 28 Oct 2013, at 17:14, Peter A. Bigot  wrote:

> coap-18 section 4.8.2 has:
>=20
>   o  MAX_TRANSMIT_WAIT is the maximum time from the first transmission
>      of a Confirmable message to the time when the sender gives up on
>      receiving an acknowledgement or reset.

This is when the initiator gives up on the exchange.
(Of course, if you are patient, you can give up later.
But the responder can=92t rely on that.)

>   o  EXCHANGE_LIFETIME is the time from starting to send a Confirmable
>      message to the time when an acknowledgement is no longer =
expected,
>      i.e.  message layer information about the message exchange can be
>      purged.

This is when the initiator can reuse the Message-ID, and the responder =
can forget all knowledge about it.

For protocol safety, this is a much longer time.
MAX_LATENCY (which is related to TCP=92s MSL) was chosen as a reasonably =
safe upper bound, not as the desired operational characteristics of =
networks that you want to run CoAP in.

> (Context: I'm trying to figure out how long the sender of a =
confirmable
> or non-confirmable message must wait before being able to commit to =
the
> success or failure of the transmission,

That is MAX_TRANSMIT_WAIT.

> as defined by the senders best
> guess as to whether the recipient accepted or rejected the message. =20=


What do you mean by =93rejected the message=94?
(4.2: "rejecting a Confirmable message is effected by sending a
   matching Reset message and otherwise ignoring it.=94)

Gr=FC=DFe, Carsten


From pab@pabigot.com  Mon Oct 28 10:48:59 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0294D11E8191 for ; Mon, 28 Oct 2013 10:48:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.534
X-Spam-Level: 
X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxIEt5dVg-3W for ; Mon, 28 Oct 2013 10:48:54 -0700 (PDT)
Received: from p3plsmtpa09-06.prod.phx3.secureserver.net (p3plsmtpa09-06.prod.phx3.secureserver.net [173.201.193.235]) by ietfa.amsl.com (Postfix) with ESMTP id 2135011E828B for ; Mon, 28 Oct 2013 10:48:45 -0700 (PDT)
Received: from [192.168.65.10] ([66.41.60.82]) by p3plsmtpa09-06.prod.phx3.secureserver.net with  id ihog1m00A1mTNtu01hogqQ; Mon, 28 Oct 2013 10:48:44 -0700
Message-ID: <526EA379.4040203@pabigot.com>
Date: Mon, 28 Oct 2013 12:48:41 -0500
From: "Peter A. Bigot" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Carsten Bormann 
References: <526E8D71.4080007@pabigot.com> <668E99A0-5E2B-418E-AA4D-045479233F9A@tzi.org>
In-Reply-To: <668E99A0-5E2B-418E-AA4D-045479233F9A@tzi.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Cc: core 
Subject: Re: [core] MAX_TRANSMIT_WAIT vs EXCHANGE_LIFETIME
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Oct 2013 17:48:59 -0000

On 10/28/2013 12:04 PM, Carsten Bormann wrote:
>
> On 28 Oct 2013, at 17:14, Peter A. Bigot  wrote:
>
>> coap-18 section 4.8.2 has:
>>
>>   o  MAX_TRANSMIT_WAIT is the maximum time from the first transmission
>>      of a Confirmable message to the time when the sender gives up on
>>      receiving an acknowledgement or reset.
>
> This is when the initiator gives up on the exchange.
> (Of course, if you are patient, you can give up later.
> But the responder cant rely on that.)
>
>>   o  EXCHANGE_LIFETIME is the time from starting to send a Confirmable
>>      message to the time when an acknowledgement is no longer expected,
>>      i.e.  message layer information about the message exchange can be
>>      purged.
>
> This is when the initiator can reuse the Message-ID, and the responder can forget all knowledge about it.

Eh; ok, but the difference doesn't seem useful.  I don't see how the 
initiator can establish a deadline for an acknowledgement that does not 
take into account latency (unless MAX_LATENCY somehow does not apply to 
ACK/RST messages, and the 100 seconds is solely for sender network stack 
delays).  Not if the receiver does have to account for latency, given 
that from its perspective the transmission/reply duration is shorter.

Let's not waste more time on this part.

>> (Context: I'm trying to figure out how long the sender of a confirmable
>> or non-confirmable message must wait before being able to commit to the
>> success or failure of the transmission,
>
> That is MAX_TRANSMIT_WAIT.

For confirmable messages, yes.  The issue I'm confronting is that 
non-confirmable messages can also be rejected by the receiver 
transmitting a RST, and there is no corresponding discussion of how long 
the sender should wait to see if that happens.  Following the argument 
for MAX_TRANSMIT_WAIT I guess that'd be ACK_TIMEOUT or 
ACK_TIMEOUT*ACK_RANDOM_FACTOR, but the text does not address using those 
parameters for non-confirmable messages.

>> as defined by the senders best
>> guess as to whether the recipient accepted or rejected the message.
>
> What do you mean by rejected the message?
> (4.2: "rejecting a Confirmable message is effected by sending a
>     matching Reset message and otherwise ignoring it.)

Rejecting a non-confirmable message may involve sending a RST, it's just 
not required in that case.

But, yes, that's what I mean by rejection.  The issue here is that CoAP 
defines message rejection only from the perspective of the receiver, and 
only for CON does that rejection require an externally visible stimulus 
(RST back to the sender).  Even when the receiver does send a RST that 
reply may not be received by the sender.

There needs to be a corresponding assessment from the perspective of the 
sender: I'm calling this "success/failure" of the transmission 
(contrasted with "accept/reject" for receiver perspective).  As 
specified, the sender can only determine whether the message was 
accepted or rejected under some circumstances (when it receives an ACK 
or RST reply, for example).  In other cases, it has to make an assumption.

If you take the position that, from the sender's perspective, a 
confirmable message transmission fails unless it succeeds, and success 
can be detected only if an ACK (or some other positive assurance of 
acceptance) is visible to the sender within EXCHANGE_LIFETIME (or 
MAX_TRANSMIT_WAIT), it is possible for the sender to treat the 
transmission as failed while the receiver treated it as accepted.

(A similar but even messier situation exists for non-confirmable 
messages, as suggested above, though there the default is something like 
"a non-confirmable transmission is successful unless it fails", and 
there's no deadline for when you say that it didn't fail.)

Success or failure of individual message transmissions, in turn, affects 
whether an exchange or transaction is perceived as active or aborted, 
and hence whether an endpoint must retain state associated with the 
transaction and other currently under-specified situations.

For example, at least one point I raised in 
http://www.ietf.org/mail-archive/web/core/current/msg04955.html 
regarding whether a block transfer is still active remains unaddressed.

Peter

From pab@pabigot.com  Mon Oct 28 15:43:55 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2709C21E80E9 for ; Mon, 28 Oct 2013 15:43:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.536
X-Spam-Level: 
X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bn6l0D873+lj for ; Mon, 28 Oct 2013 15:43:45 -0700 (PDT)
Received: from p3plsmtpa09-08.prod.phx3.secureserver.net (p3plsmtpa09-08.prod.phx3.secureserver.net [173.201.193.237]) by ietfa.amsl.com (Postfix) with ESMTP id 4C33A21F9E0B for ; Mon, 28 Oct 2013 15:42:57 -0700 (PDT)
Received: from [192.168.65.10] ([66.41.60.82]) by p3plsmtpa09-08.prod.phx3.secureserver.net with  id imit1m00E1mTNtu01miuXY; Mon, 28 Oct 2013 15:42:56 -0700
Message-ID: <526EE86E.70309@pabigot.com>
Date: Mon, 28 Oct 2013 17:42:54 -0500
From: "Peter A. Bigot" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Carsten Bormann 
References: <526E8D71.4080007@pabigot.com>	<668E99A0-5E2B-418E-AA4D-045479233F9A@tzi.org> <526EA379.4040203@pabigot.com>
In-Reply-To: <526EA379.4040203@pabigot.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Cc: core 
Subject: Re: [core] MAX_TRANSMIT_WAIT vs EXCHANGE_LIFETIME
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Oct 2013 22:43:55 -0000

[Missed list on first reply; thunderbird is weird]

On 10/28/2013 12:48 PM, Peter A. Bigot wrote:
> On 10/28/2013 12:04 PM, Carsten Bormann wrote:
>>> (Context: I'm trying to figure out how long the sender of a confirmable
>>> or non-confirmable message must wait before being able to commit to the
>>> success or failure of the transmission,
>>
>> That is MAX_TRANSMIT_WAIT.

Assuming one can't commit to a decision about success/failure for
transmission of an outstanding message, per coap-18 section 4.7 the
answer's actually EXCHANGE_LIFETIME for confirmable request messages.
For confirmable non-request messages it's still MAX_TRANSMIT_WAIT.  For
non-confirmable messages it's undefined (explicitly for request
messages per 4.7, implicitly for non-request messages).

Peter


From pab@pabigot.com  Tue Oct 29 04:39:53 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA1921E8125 for ; Tue, 29 Oct 2013 04:39:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.538
X-Spam-Level: 
X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F33rdCj0XBeT for ; Tue, 29 Oct 2013 04:39:47 -0700 (PDT)
Received: from p3plsmtpa09-02.prod.phx3.secureserver.net (p3plsmtpa09-02.prod.phx3.secureserver.net [173.201.193.231]) by ietfa.amsl.com (Postfix) with ESMTP id 5792711E8149 for ; Tue, 29 Oct 2013 04:39:42 -0700 (PDT)
Received: from [192.168.65.10] ([66.41.60.82]) by p3plsmtpa09-02.prod.phx3.secureserver.net with  id izfU1m00D1mTNtu01zfUN1; Tue, 29 Oct 2013 04:39:31 -0700
Message-ID: <526F9E71.8060305@pabigot.com>
Date: Tue, 29 Oct 2013 06:39:29 -0500
From: "Peter A. Bigot" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Klaus Hartke 
References: <526D3A2E.4070604@pabigot.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: core 
Subject: Re: [core] Message supersedure as a domain concept
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 29 Oct 2013 11:39:54 -0000

On 10/27/2013 12:19 PM, Klaus Hartke wrote:
> Peter A. Bigot wrote:
>> * [...] we cancel the previous confirmable message and
>>   replace it with a brand new notification message with its own message
>>   ID.  The new message then is granted the unused BEBO
>>   right-to-transmits from the cancelled message (because congestion
>>   requirements would normally prevent further transmissions to the
>>   endpoint until the original BEBO expired, since they are not relaxed
>>   by the act of cancelling a message).
>
> This is what I mean, including that the new notification message has
> its own message ID.

OK, let's drill down.

At a high level what this does is circumvent the requirements of coap-18
section 4.7 which say that only NSTART outstanding interactions can be
active.  A confirmable message transmission is outstanding at the
message layer if an ACK is still expected.  (In this context we're
talking about observe transmitting responses so the message is never
outstanding at the transaction layer.)

That the sender no longer cares about the reply/response (because the
send is "cancelled") does not affect whether it should still expect an
ACK, because cancellation is not visible to the receiver.

The implication here is that if the sender cancels a confirmable
transmission, as long as the original message remains outstanding no new
messages may be sent until the original BEBO state expires at
MAX_TRANSMIT_WAIT after the first transport layer transmission.  (Assume
for now that NSTART=1, otherwise this gets messier.)

What message supersedure does is allow remaining BEBO-authorized
transmission to be donated to new messages, shortening this delay.

Under default transmission parameters, as many as five distinct messages
(with unique message IDs) may be transmitted when supersedure is
allowed.

Question: What happens if an ACK or RST is received within
MAX_TRANSMIT_WAIT seconds but is for a message that was cancelled?  Had
supersedure not been invoked, that message is no longer outstanding (at
the message layer), so a new message transmission could begin
immediately.

Note that -observe uses failure of the confirmable notification as the
cue to drop the observation relationship at the server.  Assume message
supersedure occurred, and the notification that was last transmitted was
never acknowledged but late arrival provides an ack for a previous
notification, within the required MAX_TRANSMIT_WAIT.  Is the server
entitled to drop the observation relationship in this case, given that
the client is clearly still interested?  Or does it have to track all
(up to 1+MAX_RETRANSMIT) message IDs that were transmitted to avert this
case?

Peter


From pab@pabigot.com  Tue Oct 29 05:22:15 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2106711E81E3 for ; Tue, 29 Oct 2013 05:22:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.54
X-Spam-Level: 
X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-qtHksHUwP1 for ; Tue, 29 Oct 2013 05:22:10 -0700 (PDT)
Received: from p3plsmtpa09-06.prod.phx3.secureserver.net (p3plsmtpa09-06.prod.phx3.secureserver.net [173.201.193.235]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0AA11E8171 for ; Tue, 29 Oct 2013 05:22:09 -0700 (PDT)
Received: from [192.168.65.10] ([66.41.60.82]) by p3plsmtpa09-06.prod.phx3.secureserver.net with  id j0N71m0071mTNtu010N8q4; Tue, 29 Oct 2013 05:22:09 -0700
Message-ID: <526FA870.4040406@pabigot.com>
Date: Tue, 29 Oct 2013 07:22:08 -0500
From: "Peter A. Bigot" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: core 
References: <526ABAFA.7030602@pabigot.com>
In-Reply-To: <526ABAFA.7030602@pabigot.com>
X-Forwarded-Message-Id: <526ABAFA.7030602@pabigot.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [core] Stepping back: what is a CoAP REST transaction?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 29 Oct 2013 12:22:15 -0000

This doesn't show up in the archives; since it's a basis for what I did 
in http://www.ietf.org/mail-archive/web/core/current/msg05038.html I 
thought it worth making a second attempt.

-------- Original Message --------
Subject: Re: [core] Stepping back: what is a CoAP REST transaction?
Date: Fri, 25 Oct 2013 13:39:54 -0500
From: Peter A. Bigot 
To: Carsten Bormann 
CC: core 

As I hinted in my response to Matthias regarding canceling observe
transactions, I don't think this really answers the question: it's too
high-level and vague.  Nor does it convince me that the domain concepts
drive the specification, rather than being documented in an attempt to
support the decisions made for a particular situation.

Here's the sort of questions I think should be answerable by reference
to RFCs or working documents, either because they describe entities that
are intrinsically important to the domain because they provide names for
things that are manipulated to support the domain concepts:

What is the name for a CON or NON message identified by the sender
through a specific message ID?  I don't know; but I do call the ACK or
RST that such a message may invoke the "reply" to whatever that message
is.

What is the name for the process of sending a CON or NON message with a
request code and receiving a message with a response code either
piggy-backed on the reply or as a separate message?  (Or, receiving a
rejection of the request message.)  This, I think, could acceptably be
called an "exchange".

What is the name for the process of sending a request (not message)
identified by a the client through a specific Token and receiving (zero
or more) responses (not messages) also identified by the token?  This,
I think, is a "transaction".

What is the impact on a transaction involving multiple exchanges if a
message in an exchange evokes RST as a reply?

What is the impact on a transaction involving multiple exchanges if a
message in an exchange is rejected (this is NOT necessarily the same
thing)?

What is the impact on a transaction involving multiple exchanges if one
(but not all) of the exchanges evokes an error response?

What does it mean to cancel a transaction?  How is this initiated by a
by client or server?  How is the cancellation confirmed or synchronized
among endpoints participating in the transaction?


Regarding groupcomm, as I said back in 2010 I think what a URI with
a multicast authority means should not be defined by CoAP: the concept
has generic applicability and should be agreed upon by everybody who
uses URIs.  Your perception that a GET using such a URI initiates
multiple simultaneous transactions is one approach.  From a REST
perspective, it could have others.  Two obvious interpretations are:

* The resource identified is distributed, and its constituent
    representations must be aggregated in some fashion to form the
    representation of the resource as a whole;

* The resource identified is replicated, and (assuming consistency) any
    holder of the resource may respond to a read, and all must be involved
    in a write.

The interpretation really needs to be determined by the specific
resource.  I haven't kept up with groupcomm's plans since my comments on
this issue back in 2010, but certainly GET is not the only method that
could be applied to such a resource, so the concept really needs to be
well-defined for other operations too.

Peter

On 10/24/2013 08:07 AM, Carsten Bormann wrote:
> Hi Peter,
>
> thanks for trying to step out from all that dazzling detail and getting a bigger picture.
>
> Indeed, a base CoAP exchange (a word that I prefer over the loaded word transaction here) is a pair of request and response messages.  The fact that they may need to be retransmitted or might be duplicated in the network is handled at the message layer and no longer is of interest at the request/response layer.
>
> Observe extends the exchange by notifications, which can come as additional responses to the original GET request.  The cancel discussion is really about how to tear down such an extended exchange without creating lots more mechanism just for that.  (Since we already are using the token as a handle on the extended exchange to renew it, maybe we want to use that for proactive teardown.  But maybe the current reactive teardown is good enough.)
>
> Block uses the exchange abstraction and layers essentially the same abstraction again on top of it, where the latter allows larger bodies than the base CoAP protocol (or UDP messages of comfortable sizes) do.
>
> The groupcomm issue is indeed interesting; in my mind it works best by considering the multicast request a solicitation to begin an exchange, which instantiates once in each peer sending a response.  So in the end, you have many exchanges (each of which might be continued in a Block2 blockwise transfer).  But that is something that maybe is in the eye of the beholder  the protocol does not have to dictate the implementation model.  We certainly havent completed discussing this.
>
> The above discussion becomes really interesting once you add proxies to the picture.
> The HTTP model of a proxy fits very well with the base CoAP protocol.
> Observation relationship (extended exchanges) not defined beyond proxies  observing a proxy may cause that to establish an observation relationship at the next hop, or it may not.  Inversely, a proxy may decide to observe a resource if it detects significant interest in it by its clients.
> Block is also intended to implementable hop-by-hop, but a simple CoAP-CoAP proxy may even be able to hand through each of the blocks without keeping the state.
> Proxying group communication is something we dont really know how to do very well yet (section 2.9 of groupcomm).
>
> Thanks again  asking questions like these on the list is really useful.
> We may want to document more of this bigger picture in documents such as the CoRE roadmap.
>
> Gre, Carsten
>




From pab@pabigot.com  Tue Oct 29 08:04:04 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AACA111E8277 for ; Tue, 29 Oct 2013 08:04:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.541
X-Spam-Level: 
X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhhjuXP-LPCD for ; Tue, 29 Oct 2013 08:03:58 -0700 (PDT)
Received: from p3plsmtpa09-05.prod.phx3.secureserver.net (p3plsmtpa09-05.prod.phx3.secureserver.net [173.201.193.234]) by ietfa.amsl.com (Postfix) with ESMTP id 8A83921E8136 for ; Tue, 29 Oct 2013 08:03:55 -0700 (PDT)
Received: from [192.168.65.10] ([66.41.60.82]) by p3plsmtpa09-05.prod.phx3.secureserver.net with  id j33t1m00S1mTNtu0133usn; Tue, 29 Oct 2013 08:03:54 -0700
Message-ID: <526FCE5A.1030300@pabigot.com>
Date: Tue, 29 Oct 2013 10:03:54 -0500
From: "Peter A. Bigot" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: core 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [core] Clarification on PROBING_RATE
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 29 Oct 2013 15:04:04 -0000

coap-18 section 4.7 mandates that the average data rate to an endpoint
that does not respond must not exceed PROBING_RATE bytes per second.

It's not entirely clear, but I suspect the intent here is that
constraint like NSTART only applies to clients transmitting request
messages to servers, though I also expect it to apply to observe servers
sending response messages.

The number of bytes transmitted can only be estimated by the number of
bytes provided to the transport layer to be sent to the destination: it
does not include transport-, link-, phy-, or other overhead.  Right?

If endpoint A sends a confirmable message to endpoint B and that message
is not acknowledged in any way, but endpoint B does send unrelated
messages to endpoint A, can we consider B considered to have "responded"
to A's messages?  I think the text as written only allows "No".

Over what period is this average calculated?  A confirmable request
message of at least 19 bytes when sent with default transmission
parameters exceeds PROBING_RATE for the entire MAX_TRANSMIT_WAIT.  I
expect the intent is that the PROBING_RATE limit does not apply during
this period.

I'm interpreting the required operational behavior to be equivalent to
maintaining a counter of bytes sent to the endpoint (SENT_BYTES), which
is reset to zero each time the endpoint "responds" (at time
RESPONSE_MARK, also maintained).  Then the effect of 4.7 is to add a
gating function such that (absent unspecified optimizations) no further
(request) transmissions to the endpoint are allowed until:

    (SENT_BYTES / (now - RESPONSE_MARK)) <= PROBING_RATE

The impact of this requirement is pretty large; e.g. if a single
exchange for a block transfer with 1024-byte payloads does not produce a
response, technically no further (request) messages can be transmitted
to the destination for well over an hour.

From trac+core@trac.tools.ietf.org  Tue Oct 29 20:56:59 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C66011E8320 for ; Tue, 29 Oct 2013 20:56:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.495
X-Spam-Level: 
X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84ntarWkTZzH for ; Tue, 29 Oct 2013 20:56:53 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 40F5311E8202 for ; Tue, 29 Oct 2013 20:56:44 -0700 (PDT)
Received: from localhost ([127.0.0.1]:46830 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VbMtf-0001nt-72; Wed, 30 Oct 2013 04:56:43 +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-observe@tools.ietf.org, hartke@tzi.org
X-Trac-Project: core
Date: Wed, 30 Oct 2013 03:56:43 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/352#comment:1
Message-ID: <068.019076de622f17d61bea8ce0e921f4af@trac.tools.ietf.org>
References: <053.fe40688961e0f7400fbc9d728b382546@trac.tools.ietf.org>
X-Trac-Ticket-ID: 352
In-Reply-To: <053.fe40688961e0f7400fbc9d728b382546@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-core-observe@tools.ietf.org, hartke@tzi.org, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: hartke@tzi.org
Resent-Message-Id: <20131030035644.40F5311E8202@ietfa.amsl.com>
Resent-Date: Tue, 29 Oct 2013 20:56:44 -0700 (PDT)
Resent-From: trac+core@trac.tools.ietf.org
Cc: core@ietf.org
Subject: Re: [core] #352: Simplify Cancellation text
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: trac+core@trac.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 03:56:59 -0000

#352: Simplify Cancellation text

Changes (by hartke@tzi.org):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Done in observe-12.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-
  hartke@tzi.org         |  observe@tools.ietf.org
     Type:  editorial    |      Status:  closed
 Priority:  minor        |   Milestone:  post-WGLC-2
Component:  observe      |     Version:  observe-11
 Severity:  In WG Last   |  Resolution:  fixed
  Call                   |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
core 


From trac+core@trac.tools.ietf.org  Tue Oct 29 20:56:59 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D329A11E8320 for ; Tue, 29 Oct 2013 20:56:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.499
X-Spam-Level: 
X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOQtMdHgN6bN for ; Tue, 29 Oct 2013 20:56:59 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id E7A7B11E81CB for ; Tue, 29 Oct 2013 20:56:53 -0700 (PDT)
Received: from localhost ([127.0.0.1]:46840 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VbMto-0001oi-0X; Wed, 30 Oct 2013 04:56:52 +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-observe@tools.ietf.org, hartke@tzi.org
X-Trac-Project: core
Date: Wed, 30 Oct 2013 03:56:51 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/353#comment:1
Message-ID: <068.038449a4d8d8f8ef14fe44c14253fb50@trac.tools.ietf.org>
References: <053.6289ad1c79b4f5eb01d1331c40ff098f@trac.tools.ietf.org>
X-Trac-Ticket-ID: 353
In-Reply-To: <053.6289ad1c79b4f5eb01d1331c40ff098f@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-core-observe@tools.ietf.org, hartke@tzi.org, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: hartke@tzi.org
Resent-Message-Id: <20131030035653.E7A7B11E81CB@ietfa.amsl.com>
Resent-Date: Tue, 29 Oct 2013 20:56:53 -0700 (PDT)
Resent-From: trac+core@trac.tools.ietf.org
Cc: core@ietf.org
Subject: Re: [core] #353: Simplify Reset Handling text
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: trac+core@trac.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 03:57:00 -0000

#353: Simplify Reset Handling text

Changes (by hartke@tzi.org):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Done in observe-12.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-
  hartke@tzi.org         |  observe@tools.ietf.org
     Type:  editorial    |      Status:  closed
 Priority:  minor        |   Milestone:  post-WGLC-2
Component:  observe      |     Version:  observe-11
 Severity:  In WG Last   |  Resolution:  fixed
  Call                   |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
core 


From trac+core@trac.tools.ietf.org  Tue Oct 29 21:08:03 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2854A11E8326 for ; Tue, 29 Oct 2013 21:08:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.503
X-Spam-Level: 
X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQLfHeF9ADoy for ; Tue, 29 Oct 2013 21:08:01 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0E811E8327 for ; Tue, 29 Oct 2013 21:07:47 -0700 (PDT)
Received: from localhost ([127.0.0.1]:47666 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VbN4M-0006IF-2a; Wed, 30 Oct 2013 05:07:46 +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-observe@tools.ietf.org, hartke@tzi.org
X-Trac-Project: core
Date: Wed, 30 Oct 2013 04:07:46 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/350#comment:1
Message-ID: <068.eebc4ed64e50380986b37678a2bf189c@trac.tools.ietf.org>
References: <053.2ad2cf6e1364761fb593a8a5b210864c@trac.tools.ietf.org>
X-Trac-Ticket-ID: 350
In-Reply-To: <053.2ad2cf6e1364761fb593a8a5b210864c@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-core-observe@tools.ietf.org, hartke@tzi.org, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: hartke@tzi.org
Resent-Message-Id: <20131030040748.3D0E811E8327@ietfa.amsl.com>
Resent-Date: Tue, 29 Oct 2013 21:07:47 -0700 (PDT)
Resent-From: trac+core@trac.tools.ietf.org
Cc: core@ietf.org
Subject: Re: [core] #350: Unacknowledged confirmable notifications
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: trac+core@trac.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 04:08:03 -0000

#350: Unacknowledged confirmable notifications

Changes (by hartke@tzi.org):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Done in observe-12.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-
  hartke@tzi.org         |  observe@tools.ietf.org
     Type:  editorial    |      Status:  closed
 Priority:  minor        |   Milestone:  post-WGLC-2
Component:  observe      |     Version:  observe-11
 Severity:  In WG Last   |  Resolution:  fixed
  Call                   |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
core 


From weigengyu@bupt.edu.cn  Tue Oct 29 22:16:50 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0BC811E820C for ; Tue, 29 Oct 2013 22:16:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.865
X-Spam-Level: 
X-Spam-Status: No, score=-0.865 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_50=0.001, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BO6miyEzm99d for ; Tue, 29 Oct 2013 22:16:45 -0700 (PDT)
Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCF011E8213 for ; Tue, 29 Oct 2013 22:16:43 -0700 (PDT)
Received: from WeiGengyuPC (unknown [10.103.241.46]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 1C62119F397 for ; Wed, 30 Oct 2013 13:16:39 +0800 (HKT)
Message-ID: <4A54A329B0344783BEC65C6F250E7FF5@WeiGengyuPC>
From: "weigengyu" 
To: 
References: <5A6D74B4-3733-45D1-95B1-E838DADED234@tzi.org> <2B9B48179856DC4FA00C93C79EB7E64A2DB33D@ESESSMB109.ericsson.se>
In-Reply-To: <2B9B48179856DC4FA00C93C79EB7E64A2DB33D@ESESSMB109.ericsson.se>
Date: Wed, 30 Oct 2013 13:16:38 +0800
Organization: BUPT
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
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] Some initial comments on WGLC of draft-ietf-core-observe-11
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 05:16:51 -0000

Hi, all, 

I have a question on  "2. The Observe Option" 

"The Observe Option, when present in a request, extends the GET method
so it does not only retrieve a current representation of the target
resource, but also requests the server to add a new entry to the list
of observers of the resource. The list entry consists of the client
endpoint and the token specified by the client in the request.

The value of the Observe Option in a request MUST be empty on
transmission and MUST be ignored on reception. " 

Why the Observe Option in a request MUST be empty ? 

It can be empty for the simplest request. 
And it can convey more information if being used. 

regards, 

Gengyu 

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

From hartke@tzi.org  Tue Oct 29 22:23:12 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A61811E80FE for ; Tue, 29 Oct 2013 22:23:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.627
X-Spam-Level: 
X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xr2WSuIxAZSO for ; Tue, 29 Oct 2013 22:23:06 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 349B811E80E6 for ; Tue, 29 Oct 2013 22:23:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9U5N0lS008252 for ; Wed, 30 Oct 2013 06:23:00 +0100 (CET)
Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id F11C4E39 for ; Wed, 30 Oct 2013 06:22:59 +0100 (CET)
Received: by mail-vc0-f171.google.com with SMTP id ik5so590371vcb.30 for ; Tue, 29 Oct 2013 22:22:58 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=RCKG9PNwSh8BKMAGjPE3V98wiBd1cp8CpYcsUtvDjIo=; b=c33TlJ8gmd+rykJWfIUwu+BTPnh0tEpKG2iAPsA2aEjdwNvEdHoVtoJGlh+F75Y5A3 f9QmoAFY4N8LRCEhG9zDBG+HTaykjKxqTiSpGZ+WlQHpuMQOUdWXTNww21S6vMoFSUYl PoBsYgRJBVPxkBrHoReVwhvWxTaEXRL4DJp7nQbiXNU8B9ZqADWCgc8yfatuuvpW3Bv3 YxUJjIgayWhtFLW8/DUdfFovMJTvIQKCA/JsBU0uj5oPHQg2OTB/9UGyvYv7T/mhHW6s NsYs1ValqoN5lLWsrXTlA4DnFO6QBtehSrxm68BYXQcEH0N9Vl4l8uFqBURjiRjIWeZS L17g==
X-Received: by 10.220.86.69 with SMTP id r5mr1851195vcl.9.1383110578449; Tue, 29 Oct 2013 22:22:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.102.100 with HTTP; Tue, 29 Oct 2013 22:22:18 -0700 (PDT)
In-Reply-To: <2B9B48179856DC4FA00C93C79EB7E64A2DB34C@ESESSMB109.ericsson.se>
References: <5A6D74B4-3733-45D1-95B1-E838DADED234@tzi.org> <2B9B48179856DC4FA00C93C79EB7E64A2DB34C@ESESSMB109.ericsson.se>
From: Klaus Hartke 
Date: Wed, 30 Oct 2013 07:22:18 +0200
Message-ID: 
To: Salvatore Loreto 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: "core@ietf.org WG" 
Subject: Re: [core] core-observe-11 wglc review
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 05:23:12 -0000

Hi Salvatore,

thanks a lot for your review and sorry for the delayed response.

> 1)
> I would suggest to change
>
> s/the server is the definitive source for representations of the resource=
s
> in its namespace./
>   the server is the authority for representations of the resources in its
> namespace.

Fixed in SVN.

> 2) Section 2. The Observer option
>
>    The list entry consists of the client
>    endpoint and the token specified by the client in the request.
>
> it is not clear if the client endpoint + token is an unique key or not.
> It should be clear!

The text in section 4.1 says that

   If an entry with a matching endpoint/token pair is already
   present in the list [of observers of a resource] [...], the
   server MUST NOT add a new entry but MUST replace or
   update the existing one.

>From this follows that there are never two entries with the same
client endpoint and request token in the list of observers of a
resource.

How much of this needs to said in section 2?

> 3)
> which is the purpose to store the Observe Option in the cache?

It doesn't really matter if an implementation keeps the Observe option
when storing a notification in a cache or not. What's important is
that a response returned in reply to a GET request without an Observe
option does not include an Observe option as well. The only situation
where this could happen is when the server keeps the Observe option in
a notification and uses the notification to satisfy a GET request
without an Observe option.

> 4) Section 3.1
>    A client [...] MUST NOT register more than once
>    for the same target resource.
>
> what happens if the client does?

The client receives the same notifications multiple times, which
unnecessarily wastes both the server's and the client's resources. It
also leads to a slot in the list of observers being occupied that
could otherwise be used by another client. The server is not required
to detect a violation of this requirement, though.

Should this be mentioned in the draft?

> This actually can easily be used for a DoS attack

Can you expand on this?

Should it be mentioned in the Security Considerations?

> 5) general comment about Caching=85
>
> Why we have almost the same text in 3.3 and in 4.3 and subsections?
>
> 8) Transmission
>     Why we have almost the same text in 3.5 and in 4.5 and subsections?

Until draft-ietf-core-observe-03, there was only one section that
contained the requirements for both client and server. This made the
text a bit difficult to read, so the whole document was split in
observe-04. In general, one section now contains the requirements for
one side, and the other section gives a short summary what the other
side can expect (and vice versa). As long as both sections are
consistent, I see no harm in a bit of redundancy.

> 6) Section 3.3.1
>
>   Additionally,
>    the client SHOULD wait for a random amount of time between 5 and 15
>    seconds to avoid synchronicity with other clients.
>
> it is not clear that the wait time is supposed to be counted from the mom=
ent
> the content become stale (time> max-age)

Fixed in SVN.

> 7) 3.3.2 Validation
>
>     this paragraph is not Observe specific, it is just a general rule
>     I guess (not remember really) that the same text is already in the
>     core-coap spec

It may not be entirely obvious that validation can be used in
conjunction with resource observation. So this section and section
4.3.2 provide a short summary of what's in draft-ietf-core-coap and
point out a few observation-specific details. For example, section
4.3.2 makes it clear (or hopefully clear enough) that a server can
only return a 2.03 (Valid) response if the ETag matches one of the
ETags in the request, and cannot return such a response if the ETag
just matches the ETag of a previous notification it sent.

> Editorial comments
>
> 1) Section 1.3
> pag 6 the third bullet has an "and/or" too much

Fixed in SVN.

Best regards,
Klaus

From hartke@tzi.org  Tue Oct 29 22:30:10 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABCA121E80E3 for ; Tue, 29 Oct 2013 22:30:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.627
X-Spam-Level: 
X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tG9wAxxaB20d for ; Tue, 29 Oct 2013 22:30:04 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id D6B6E11E820C for ; Tue, 29 Oct 2013 22:29:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9U5TpPa019881 for ; Wed, 30 Oct 2013 06:29:51 +0100 (CET)
Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 17821E3D for ; Wed, 30 Oct 2013 06:29:50 +0100 (CET)
Received: by mail-vc0-f178.google.com with SMTP id ie18so605295vcb.9 for ; Tue, 29 Oct 2013 22:29:49 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=mbAdXtt4uKUXGe0v3TBj7yWsdB/jpGOS1+LMd8gxA0I=; b=TY149u5Zt49ipH/hmNJfFX4nbVVTr3oVKiDGBJL9v8Qn2xfkdO0LCDfsLWX+xTO3pu QZflcaxaEic/gB8DAJJHt6y244re1HP9+X6D40uJt3r/ixIRV/RbkTAoVtzLnjsysIW1 +BtiwfUnT6yW1WXwukaohD6RiuaM6kn6yjzU/vomoUvzK3hOOyAc9ZaPNkpfTmz/tP7e BUziMgxI7KqnRL/8SunbA8iKnVhBiKx/Hf3Yo3J7H3d5x/T5v9hix44tT0A3nfXa8TsG GYXIhqyJh2jzrgMEQ+zSyS/Kvbq8WVu1Jdm21RdF/Fa8lj+9u3b79YKzHN9Z8yu+EhZ/ CqRQ==
X-Received: by 10.220.144.18 with SMTP id x18mr1863232vcu.15.1383110989803; Tue, 29 Oct 2013 22:29:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.102.100 with HTTP; Tue, 29 Oct 2013 22:29:09 -0700 (PDT)
In-Reply-To: <4A54A329B0344783BEC65C6F250E7FF5@WeiGengyuPC>
References: <5A6D74B4-3733-45D1-95B1-E838DADED234@tzi.org>      <2B9B48179856DC4FA00C93C79EB7E64A2DB33D@ESESSMB109.ericsson.se> <4A54A329B0344783BEC65C6F250E7FF5@WeiGengyuPC>
From: Klaus Hartke 
Date: Wed, 30 Oct 2013 07:29:09 +0200
Message-ID: 
To: weigengyu 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "core@ietf.org WG" 
Subject: Re: [core] Some initial comments on WGLC of draft-ietf-core-observe-11
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 05:30:10 -0000

weigengyu wrote:
> "The value of the Observe Option in a request MUST be empty on
> transmission and MUST be ignored on reception. "
>
> Why the Observe Option in a request MUST be empty ?
> It can be empty for the simplest request. And it can convey more information
> if being used.

draft-ietf-core-observe currently defines no information that could be
used as a value of the Observe Option. So, to preserve the opportunity
to define such information later, the current version of the protocol
requires that the option value is empty.

Best regards,
Klaus

From hartke@tzi.org  Tue Oct 29 23:24:40 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83BB821E8125 for ; Tue, 29 Oct 2013 23:24:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.627
X-Spam-Level: 
X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hem+efJG-Fb for ; Tue, 29 Oct 2013 23:24:28 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id EA37621E80DB for ; Tue, 29 Oct 2013 23:24:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9U6OOBn007372 for ; Wed, 30 Oct 2013 07:24:24 +0100 (CET)
Received: from mail-vb0-f43.google.com (mail-vb0-f43.google.com [209.85.212.43]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id ED6E8E4C for ; Wed, 30 Oct 2013 07:24:23 +0100 (CET)
Received: by mail-vb0-f43.google.com with SMTP id g10so591703vbg.16 for ; Tue, 29 Oct 2013 23:24:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zgCwzhxzBYgAjRda/FOW2fXXFJ0h1PaQPNbzuGf8yyI=; b=aBiJNpgTc2ETC95lZlneXDJ8wLO2N7bM9R521EtFvZuiCbg21ObmkyTqlQ/9pyZi9P +qNw2hFiCK1sx1eVktHMgT7QYqj5OB78KTWFSoI6ampbfpt3XWsgZr+ggk/y0Ch3nJ+Y IhCIbIsw6VSH/Qls3MKPXKm047rVJsOTQTeIrFTRw12cgLA7RQyN8ENfRhNT+8m5ARzg 7sUr79xxyAUX+iQKp/UAqxNoys7KaL5N0KnVhnD2f+n49zTusxw+gAO8+Ez+WdYfO7XI F+KNvlQ65Yns/I7Hlll0QCQRX73Ggfdi+yrX6PvQ4rGsLSbK0GSADZGRwzwwGchaUPZ8 enrQ==
X-Received: by 10.220.144.80 with SMTP id y16mr2025506vcu.4.1383114262586; Tue, 29 Oct 2013 23:24:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.102.100 with HTTP; Tue, 29 Oct 2013 23:23:42 -0700 (PDT)
In-Reply-To: <526D7687.7070208@pabigot.com>
References: <526D3A2E.4070604@pabigot.com>  <526D7687.7070208@pabigot.com>
From: Klaus Hartke 
Date: Wed, 30 Oct 2013 08:23:42 +0200
Message-ID: 
To: "Peter A. Bigot" 
Content-Type: text/plain; charset=ISO-8859-1
Cc: core 
Subject: Re: [core] Message supersedure as a domain concept
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 06:24:40 -0000

Peter A. Bigot wrote:
> Therefore, to satisfy the expectations of -observe, what we say is when
> the resource changes we SHOULD/MUST cancel all previous notifications
> (if any), and MUST initiate the transmission of new notification for
> each active observation transaction. Further, the second notification
> MAY/MUST *supersede* (reference definition) a cancelled notification.

You can't really start a new notification transmission (CoAP message
transmission) while a previous notification transmission is still
active when NSTART=1.

So either you wait until no previous transmission is active, or you
cancel the active transmission and initiate the new transmission when
the retransmission timer fires with the unused BEBO right-to-transmits
from the cancelled transmission.

Klaus

From hartke@tzi.org  Tue Oct 29 23:29:12 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDB6821F9FB0 for ; Tue, 29 Oct 2013 23:29:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.627
X-Spam-Level: 
X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKZj+JUwLZZ0 for ; Tue, 29 Oct 2013 23:29:07 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id CA17B21F9FA7 for ; Tue, 29 Oct 2013 23:29:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9U6T0wn015988 for ; Wed, 30 Oct 2013 07:29:00 +0100 (CET)
Received: from mail-ve0-f175.google.com (mail-ve0-f175.google.com [209.85.128.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 7FE0EE50 for ; Wed, 30 Oct 2013 07:29:00 +0100 (CET)
Received: by mail-ve0-f175.google.com with SMTP id jz11so664167veb.34 for ; Tue, 29 Oct 2013 23:28:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QxWg3hmlG26Zg2e2YHaKB+pDy0JYZBaCdG83bBDi1q4=; b=WAPVBedltcTzaJGRbwnjFtZUO/od25jYt0lFqcdhFFPvrknWhOaz5v76qAnKnLfb2t 8ztSGB91h/P5bYKjpxnmKhv+96dlyYrKJD5NFo+yU/1oBrwjHSto04byQzD6IL2vh/bi N8rN8m6m9/uxVcWwYmdugPMbI9Bve+sDcetYBjypdZUqpMDThECq7aZYATNb1rjhiXHZ jXTM4qkA2wqiVcMuf4fxc3UM/qd5xV4eirj/nAb/JSI7MVEqS2GZBTspfoKyRmm6KO+V L8h/lbNxRK5sul0UXyLB5rJMMNjKm3wuJDc6Lx9dnPvpToif91x6p5yu3CJ+N+ctGzEr cu2g==
X-Received: by 10.220.183.199 with SMTP id ch7mr394059vcb.27.1383114539247; Tue, 29 Oct 2013 23:28:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.102.100 with HTTP; Tue, 29 Oct 2013 23:28:19 -0700 (PDT)
In-Reply-To: <526F9E71.8060305@pabigot.com>
References: <526D3A2E.4070604@pabigot.com>  <526F9E71.8060305@pabigot.com>
From: Klaus Hartke 
Date: Wed, 30 Oct 2013 08:28:19 +0200
Message-ID: 
To: "Peter A. Bigot" 
Content-Type: text/plain; charset=ISO-8859-1
Cc: core 
Subject: Re: [core] Message supersedure as a domain concept
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 06:29:13 -0000

Peter A. Bigot wrote:
> At a high level what this does is circumvent the requirements of coap-18
> section 4.7 which say that only NSTART outstanding interactions can be
> active.

Section 4.7 of draft-ietf-core-coap-18 says that

   *Clients* (including proxies) MUST
   strictly limit the number of simultaneous outstanding interactions
   that they maintain to a given server (including proxies) to NSTART.

It seems it's up to draft-ietf-core-observe to define congestion
control for servers.

So -observe-11 follows -coap-18 here and says that

   The server MUST limit the number of confirmable notifications for
   which an acknowledgement has not been received from a client yet to
   NSTART (1 by default).

I'm not sure if -observe needs to circumvent itself :-)

But it is indeed the intention that -observe-11 modifies the algorithm
specified in section 4.2 of coap-18 such that a server can start
working towards getting the representation of a new resource state to
a client sooner.

> Under default transmission parameters, as many as five distinct messages
> (with unique message IDs) may be transmitted when supersedure is
> allowed.
>
> Question: What happens if an ACK or RST is received within
> MAX_TRANSMIT_WAIT seconds but is for a message that was cancelled?  Had
> supersedure not been invoked, that message is no longer outstanding (at
> the message layer), so a new message transmission could begin
> immediately.

If it's an ACK, then it just confirms that the client is interested in
further notifications. Sending a further notification is what the
server already did. So I'd say everything is fine if the server just
ignores the ACK.

To properly handle RSTs, a server in principle would need to remember
the message IDs of all notification it sends for 2*MAX_LATENCY after
the transport layer transmission. That may be a bit impractical
though...

> Note that -observe uses failure of the confirmable notification as the
> cue to drop the observation relationship at the server.  Assume message
> supersedure occurred, and the notification that was last transmitted was
> never acknowledged but late arrival provides an ack for a previous
> notification, within the required MAX_TRANSMIT_WAIT.  Is the server
> entitled to drop the observation relationship in this case, given that
> the client is clearly still interested?  Or does it have to track all
> (up to 1+MAX_RETRANSMIT) message IDs that were transmitted to avert this
> case?

Since the server tries to get the representation of the latest
resource state to the client, and the ACK doesn't acknowledge the
latest notification, the server would retransmit the latest
notification when the retransmission timer fires. If there are no
retransmissions left, then the observation is dropped. The late
arrival of an ACK for a previous notification does not cut short the
retransmission timer or reset the retransmission counter.

Klaus

From pab@pabigot.com  Wed Oct 30 04:11:00 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0ACA11E810F for ; Wed, 30 Oct 2013 04:11:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.542
X-Spam-Level: 
X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZomZnJW6z7g for ; Wed, 30 Oct 2013 04:10:55 -0700 (PDT)
Received: from p3plsmtpa09-02.prod.phx3.secureserver.net (p3plsmtpa09-02.prod.phx3.secureserver.net [173.201.193.231]) by ietfa.amsl.com (Postfix) with ESMTP id EEE6B11E8151 for ; Wed, 30 Oct 2013 04:10:51 -0700 (PDT)
Received: from [192.168.65.10] ([66.41.60.82]) by p3plsmtpa09-02.prod.phx3.secureserver.net with  id jPAp1m00U1mTNtu01PAqHB; Wed, 30 Oct 2013 04:10:50 -0700
Message-ID: <5270E93B.4070209@pabigot.com>
Date: Wed, 30 Oct 2013 06:10:51 -0500
From: "Peter A. Bigot" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Klaus Hartke 
References: <526D3A2E.4070604@pabigot.com>  <526F9E71.8060305@pabigot.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: core 
Subject: Re: [core] Message supersedure as a domain concept
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 11:11:01 -0000

On 10/30/2013 01:28 AM, Klaus Hartke wrote:
> I'm not sure if -observe needs to circumvent itself :-)

Huh?

Oh, never mind.  Failure to communicate, not worth wasting more time.

> Since the server tries to get the representation of the latest
> resource state to the client, and the ACK doesn't acknowledge the
> latest notification, the server would retransmit the latest
> notification when the retransmission timer fires. If there are no
> retransmissions left, then the observation is dropped. The late
> arrival of an ACK for a previous notification does not cut short the
> retransmission timer or reset the retransmission counter.

Right.  So here we have a case where the server would drop the 
observation because supersedure occurred, when it would not have done so 
had supersedure not occurred.  Net result is loss of information as a 
consequence of trying to game the system.

If that works for you, ok.

FWIW: Having defined precisely what cancellation would have to mean in 
the context of other CoAP requirements, my conclusion is that a clear 
and consistent definition of supersedure is difficult and results in 
undesirable behavior.  Which is what my intuition told me when this 
whole mess started.

Peter

From weigengyu@bupt.edu.cn  Wed Oct 30 19:59:44 2013
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9666B11E8246 for ; Wed, 30 Oct 2013 19:59:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.019
X-Spam-Level: 
X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_20=-0.74, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHk6WVbnRDqD for ; Wed, 30 Oct 2013 19:59:30 -0700 (PDT)
Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id C8E9D11E82F8 for ; Wed, 30 Oct 2013 19:59:28 -0700 (PDT)
Received: from WeiGengyuPC (unknown [10.103.241.46]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id BF6A119F3A1; Thu, 31 Oct 2013 10:59:24 +0800 (HKT)
Message-ID: <996BCBC692A74B988D4894BBD6D72516@WeiGengyuPC>
From: "weigengyu" 
To: "Klaus Hartke" 
References: <5A6D74B4-3733-45D1-95B1-E838DADED234@tzi.org>      <2B9B48179856DC4FA00C93C79EB7E64A2DB33D@ESESSMB109.ericsson.se> <4A54A329B0344783BEC65C6F250E7FF5@WeiGengyuPC>  <76A862C4943D425A88FB3B9639F84589@WeiGengyuPC> 
In-Reply-To: 
Date: Thu, 31 Oct 2013 10:59:23 +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] Some initial comments on WGLC of draft-ietf-core-observe-11
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Oct 2013 02:59:45 -0000

Hi，Claus，

Thank you for your answers.
And the mail is CCed to the mailing list.

>>  Then the intermediary polls the next hop or polls the other next hop?
> I'm not sure which other hop you mean, but the intermediary polls the next 
> hop.

What I want to ask is that the intermeidiary has only one the next hop, or 
has some next hops (neighbors).
If there is only one next hop, it is assumed that the chain formed by 
intermediaries between the  client and the server is a single chain.

Then,question about Observe Option and Polling.
In the core-observe-11,
" In a response, the Observe Option identifies the message as a
notification. This implies that the server has added the client to
the list of observers and that it will notify the client of changes
to the resource state. "

If an response is without  the Observe Option, what does it implicitly or 
explicitly tell "the client" ?
Probably the draft means that the response message identifies
(1) it is a notification containing the server's current value (maybe 
cached);
(2) the server has NOT added the client to the list of observers, and that 
it will NOT notify further.

The POLLING is required because notifications will not actively send out to 
"the client".

The response without the Observe Option may come from the original server or 
from a intermediary.
After it can get "the response without the Observe Option",
the original client will proactively send request of GET, but it may  get a 
cached value within a intermediary.
The POLLING frequency of the intermediary will affect the value of response,
the value may not represents the server's change instantly, or the 
up-to-date value of the original client request.

I guess, wether the cach mechanism could be suspended in this case or the 
original client has to tolerance the delay.

And if there are two or more intermediaries,
the intermediary of most near to the original server send the response 
without the Observe Option,
and the following intermediarie should send the response without the Observe 
Option too untile to the original client.
Polling messages may occure between intermediaries.
Without clear objective, the Polling messages between intermediaries are 
useless.

regards,

gengyu

Network Technology Center,
School of Computer,
Beijing University of Posts & Telecommunications

-----原始邮件----- 
From: Klaus Hartke
Sent: Thursday, October 31, 2013 3:38 AM
To: weigengyu
Subject: Re: [core] Some initial comments on WGLC of 
draft-ietf-core-observe-11

Hi Gengyu,

thank you for your excellent questions. (Why didn't you send them to
the mailing list?)

> Does the draft mean "the next hop does not response" or "the next hop
> returns a response without an Observe Option"?

The draft means "the next hop returns a response without an Observe
Option". I will clarify this in the next update of the draft.

> Then the intermediary polls the next hop or polls the other next hop?

I'm not sure which other hop you mean, but the intermediary polls the next 
hop.

> Because the intermediary does not understand the applicatoin semantics
> according to core-CoAP-18, how often to poll is unclear.

draft-ietf-core-coap-18 and draft-ietf-core-observe-11 indeed state no
explicit requirements on polling.

It depends a bit on the client (or intermediary in the role of the
client) how often it needs to poll to make sure it has a fresh
representation of the target resource. As long as the client has a
fresh representation, there is probably little need to poll the next
hop. So the following recommendations from section 3.3.1 of
draft-ietf-core-observe-11 could be applied to polling as well:

   It is RECOMMENDED
   that the client does not issue the request while it still has a fresh
   notification/response for the resource in its cache.  Additionally,
   the client SHOULD wait for a random amount of time between 5 and 15
   seconds to avoid synchronicity with other clients.

Best regards,
Klaus